Over the past month a number of VCs including Chris Dixon and Fred Wilson use the term “the blockchain” in reference to Bitcoin, as if it is the one and only blockchain.1

There are empirically, many blockchains around.  Some of them do not involve proof-of-work, some of them are not even cryptocurrencies.  Yet despite this, Dixon blocked Greg Slepak on Twitter (creator of okTurtles and DNSChain) for pointing that out just a couple weeks ago.

But before getting into the weeds, it is worth reflecting on the history of both virtual currencies and cryptocurrencies prior to Bitcoin.

The past

Below are several notable projects that pre-date the most well-known magic internet commodity.

• DigiCash (1990)
• e-gold (1996)
• WebMoney (1998)
• PayPal (1998) “Bitcoin is the opposite of PayPal, in the sense that it actually succeeded in creating a currency.”  — Peter Thiel
• Beenz (1998)
• Flooz (1999)
• Liberty Reserve (2006)
• Frequent flyer points / loyalty programs
• WoW gold, Linden Dollars, Nintendo Points, Microsoft Points

According to an excellent article written a couple years ago by Gwern Branwen:

Bitcoin involves no major intellectual breakthroughs, so Satoshi need have no credentials in cryptography or be anything but a self-taught programmer! Satoshi published his whitepaper May 2009, but if you look at the cryptography that makes up Bitcoin, they can basically be divided into:

• Public key cryptography
• Cryptographic signatures
• Cryptographic hash functions
• Hash chain used for proof-of-work
  • Hash tree
  • Bit gold
• cryptographic time-stamps
• resilient peer-to-peer networks

And what were the technological developments, tools and libraries that spearheaded those pieces?  According to Branwen:

• 2001: SHA-256 finalized
• 1999-present: Byzantine fault tolerance (PBFT etc.)
• 1999-present: P2P networks (excluding early networks like Usenet or FidoNet; MojoNation & BitTorrent, Napster, Gnutella, eDonkey, Freenet, i2p etc.)
• 1998: Wei Dai, B-money
• 1997: HashCash; 1998: Nick Szabo, Bit Gold; ~2000: MojoNation/BitTorrent; ~2001-2003, Karma, etc
• 1992-1993: Proof-of-work for spam
• 1991: cryptographic timestamps
• 1980: public key cryptography
• 1979: Hash tree

Other prior art can be found in The Ecology of Computation from Huberman.2 One open question for permissionless systems is whether or not a blockchain is a blockchain if it is neither proof-of-work-based or proof-of-stake-based (“Cow system” in Bram Cohen’s terminology).  But that’s a topic for another post.

The present

About two weeks ago, /r/bitcoin learned that Bitcoin was not the creator of all this fundamental technology.  That indeed, there were over 30 years of academic corpus that cumulatively created the system we now call “a blockchain,” in this case, Nakamoto consensus.  And this has spawned a sundry of other experiments and projects that have since been kickstarted.

For example:

• CoinMarketCap currently tracks 592 cryptocurrencies / 59 assets
• CoinGecko tracks 225 cryptocurrencies/assets
• Ray Dillinger’s “Necronomicon” includes over 100 dead altcoins
• Map of Coins is currently tracking 686 derivatives of various cryptocurrencies; this includes all hashing functions (e.g., scrypt, X11, X13) and includes existing and defunct chains
• These are just publicly known blockchains and there are likely dozens if not hundreds of private trials, proof of concepts in academia, institutions and from hobbyists (e.g., Citibank announced in July 2015 that it was testing out three blockchains with a “Citicoin” to better understand use-cases)

So it appears that there are more than one in the wild.

Yet, a couple weeks ago Fred Wilson wrote that:

If you think of the blockchain as an open source, peer to peer, massively distributed database, then it makes sense for the transaction processing infrastructure for it to evolve from individuals to large global corporations. Some of these miners will be dedicated for profit miners and some of them will be corporations who are mining to insure the integrity of the network and the systems they rely on that are running on it. Banks and brokerage firms are the obvious first movers in the second category.

He later clarified in the comments and means the Bitcoin blockchain, not others.

One quibble is that transaction processing is not clearly defined relative to hashing.  Today, bitcoin transactions are actually processed by very small, non-powerful computers (even a Raspberry Pi).

What about the pictures with entire rooms filled with computers?  Why does it cost so much to run a hashing farm then?

Because of the actual workhorse of the network: ASICs designed to generate proofs-of-work.  These hashing systems do not do any transaction processing, in fact, they cannot even run a Bitcoin client on them.3

Tangentially William Mougayar, investor and author, stated the following in the AVC thread:

Only trick is that mining is not cheap initially, and the majority is done in China. It presents an interesting energy challenge: you need lots of electricity to run the computers, but also to keep them cool. So, if you’re using solar you still need to cool them. And if you put them in cool climates like near the north pole, there is no solar. Someone needs to solve that equation.

Mining cannot be made “cheaper” otherwise the network becomes cheaper to attack.

In fact, as Bram Cohen mentioned last week, “energy efficient” proofs-of-works is a contradiction in terms.

Thus, there is no “equation to solve.”  In the long run, miners will bid up the marginal costs to which they equal the marginal value (MC=MV) of a bitcoin in the long run.  We see this empirically, there is no free lunch.  If hashing chips somehow became 50% more efficient, hashing farms just add 50% more of them — this ratcheting effect is called the Red Queen effect and this historically happens in a private seigniorage system just as it does in proof-of-work cryptocurrencies.4

As shown in the chart above, hashrate follows price; the amount of resources expended (for proof-of-work) is directly proportional to market value of a POW token.

Furthermore, in terms of Wilson’s prediction that banks will begin mining: what benefit do banks have for participating in the mining process?  If they own bitcoins, perhaps it “gives them a seat at the table.”  But if they do not own any, it provides no utility for them.

Why?  What problem does mining solve for organizations such as banks?  Or to put another way: what utility does proof-of-work provide a bank that knows its customers, staff and transaction processors?5

Permissioned Permissionlessness, BINO-style

One goal and innovation for Bitcoin was anonymous/pseudonymous consensus which comes with a large requirement through trade-offs: mining costs and block reorganization risk.

To quote Section 1 of the Nakamoto whitepaper regarding the transaction costs of the current method of moving value and conducting commerce:

These costs and payment uncertainties can be avoided in person by using physical currency, but no mechanism exists to make payments over a communications channel without a trusted party

Thus:

• Bitcoin was designed with anonymous consensus to resist censorship by governments and other trusted third parties.
• If you are running a ledger between known parties who abide by government regulations, there is no reason to pay that censorship-resistance cost.  Full stop.

Today several startups and VC funds have (un)intentionally turned an expensive permissionless system into a hydra, a gated permissioned network without the full benefits of either.  Consequently, through this mutation, some of these entities have also turned a bearer asset into a registered asset with the full costs of both.

For instance, it is currently not possible to build a censorship-resistant cash system on top of a permissioned ledger (due to the KYC requirements) yet this is basically what has attempted with many venture funded wallets such as Coinbase.

The end result: Bitcoin in name only (BINO).  In which a permissionless network is (attempted to be) turned into a permissioned network.  It bears mentioning that companies such as Peernova and Blockstack are not trying to compete with Bitcoin — they are not trying to build censorship-resistant cash.

While financial institutions can indeed download a client and send tokens around, Bitcoin was purposefully designed not to interface with financial intermediaries as it was modeled on the assumption that no one can be trusted and that parties within the network are unknown.  Therefore if parties transacting on the network are both known and trusted, then there probably is no reason to use Bitcoin-based proof-of-work.  Instead, there are other ways to secure transactions on a shared, replicated ledger.

Ask the experts

I reached out to several experts unaffiliated with Bitcoin itself to find out what the characteristics of a blockchain were in their view.

Ian Grigg has spent twenty years working in the cryptocurrency field and is the author of the Financial Cryptography blog as well as the Ricardian Contract and most recently the “Nakamoto signature.”  Below are his thoughts:

As far as *history* is concerned, it looks like just about every individual component of Bitcoin was theorised before 2009.  The last thing that I’d thought was new was the notion of a shared open repository of transactions, but it seems Eric Hughes actually proposed it in the 1990s.  And of course Todd Boyle was banging the triple entry drum in the late 1990s.

Bitcoin has no monopoly on any term except bitcoin and BTC as far as I can see. The big question is really between permissioned and permissionless ledger designs.

If you go for a permissioned ledger, then you can do some more analysis and also reduce the need for the consensus signing to be complicated. At the base level, just one signatory might be enough, or some M of N scheme. But we don’t need the full nuclear PoW-enfused Nakamoto Signature.

But also, the same analysis says we don’t need a block. What’s a block? It’s a batch of transactions that the ‘center’ works on to make them so. But if we’ve got permissioned access, and we’ve reduced the signing to some well-defined set, why not go for RTGS and then we haven’t got a block.

The block in the blockchain exists because of the demands of the networking problem – with a network of N people all arguing over multiple documents, we know it can’t be done in less than a second for a small group and less than 10 seconds for a large group. So to get the scaling up, we *have to make a block* or batch of *many* transactions so we can fit the consensus algorithm over enough tx to make it worthwhile.

Therefore the block, the Nakamoto Signature, PoW and the incentive structure all go together. That’s the blockchain.

Zaki Manian, co-founder of SKUChain and all around Bay-area crypto guru:

Cryptography is interesting right now because the primitives have matured and pre-cryptographic systems are becoming less and less robust.

Commitment schemes are widely used in cryptography. Nakamoto signatures (if Adam Back wants to concede the naming rights) are the thermodynamic commitment to a set of values. A conventional signature in attributable commitment.

A cryptocurrency is an application of a ledger. A distributed ledger needs to syndicate the order of stored transaction. There is a lot of value to syndicating and independently validating the commitments to interested parties. Generalized Byzantine Agreement, n-of-m signatures and transaction syndication decrease the discretion in the operating of systems. Ultimately, discretion is a source of fragility. I think Ian’s reference to RTGS is somewhat disingenuous. Systems with a closed set of interacting parties aren’t particularly helpful. Open participation systems are fundamentally different.

There don’t seem to be any settle lines between the properties of permissioned and permission-less systems. We have both and time will tell.

Pavel Kravchenko, formerly chief cryptographer at Stellar, now chief cryptographer at Tembusu Systems:

I’ve seen the discussion, it seems rather political and emotional. Since the term blockchain is not clearly defined people tend to argue. To make everything clear I would start from security model – who is the adversary, what security assumptions we are making, what is the cost of a particular attack etc. For now (still very early days of crypto-finane) using blockchain as a common word for such variety of conditions is acceptable for me.

Vlad Zamfir, who has helped spearhead the cryptoeconomics field alongside others at Ethereum (such as Vitalik).  In his view:

“Blockchains” are a class of consensus protocols (hence why I like to pedantically refer to them as blockchain-based consensus protocols).  They are not necessarily ledgers, although blocks always do contain ordered logs.

These logs need not be transactions – although we can call them transactions if we want, and so you can call it a ledger if you want – it’s just misleading.

Blockchains are characterized by the fact that they have a fork-choice rule – that they choose between competing histories of events.

Traditional consensus protocols don’t do this, so they don’t need to chain their blocks – for them numbering is sufficient.

Economic consensus protocols contain a ledger in their consensus state, in which digital assets are defined – assets who are used to make byzantine faults expensive.

It is much less misleading to refer to this class of protocols as ledgers, than to blockchains generally speaking – although it is still misleading.

You can make an economic consensus protocol that lets people play chess. It would have a ledger, but it wouldn’t be fair to call it a distributed ledger – it’s a distributed chess server.

Economic consensus allows for public consensus, which acts as a (crappy) public computer.

Public consensus protocols have no “permissioned” management of the computers that make up this crappy public computer.

Non-public consensus protocols have “permissioned” management of these computers.

I think the main thing that is consistently lacking from these discussions is the fact that you can have permissioned control of the state of a public consensus protocol without “permissioning” the validator set.

Robert Sams, co-founder of Clearmatics who has done a lot of the intellectual heavy lifting on the “permissioned ledger” world (I believe he first coined the term in public), thinks that:

If I were to guess, I’d say that the block chain design will eventually yield to a different structure (eg tree chains). It’s the chaining that’s key, not the particular object of consensus (although how the former works is parasitic on the latter).

I think Szabo’s use of “block chain” rather than “blockchain” is more than a question of style. Out of habit I still merge adjective and noun like most people, but it’s misleading and discourages people from thinking about it analytically.

I tell you though, the one expression that really gets on my nerves is “the blockchain” used in contexts like “the blockchain can solve problem X”. Compound the confusion with the definite article. As if there’s only one (like “the internet”). And even when the context assumes a specific protocol, “the” subconsciously draws attention away from the attacker’s fork, disagreements over protocol changes and hard forks.

Anyway this debate with people talking up their Bitcoin book and treating innovation outside its “ecosystem” as apostasy is tiresome and idle.

Christopher Allen, who has had a storied career in this space including co-authoring the TLS standard:

I certainly was an early banner waiver — I did some consulting work with Xanadu, and later for very early Digicash. At various points in the growth of SSL both First Virtual and PGP tried to acquire my company. When I saw Nick’s “First Monday” article the day it came out, as it immediately clicked a number of different puzzle pieces that I’d not quite put together into one place. I immediately started using the term smart contracts and was telling my investors, and later Certicom, that this is what we really should be doing (maybe because I was getting tired of battles in SSL/TLS standards when that wasn’t what Consensus Development had been really founded to solve).

However, in the end, I don’t think any thing I did actually went anywhere, either technically or as a business, other than maybe getting some other technologists interested. So in the end I’m more of a witness to the birth of these technologies than a creator.

History in this area is distorted by software patents — there are a number of innovative approaches that would be scrapped because of awareness of litigious patent holders. I distinctly remember when I first heard about some innovative hash chain ideas that a number of us wanted to use hash trees with it, but we couldn’t figure out how to avoid the 1979 Merkle Hash Tree patent whose base patent wouldn’t expire until ’96, as well as some other subsidiary hash tree and time stamp patents that wouldn’t expire until early 2000s.

As I recall, at the time were we all trying to inspired solve the micropayment problem. Digicash had used cryptography for larger-sized cash transactions, whereas First Virtual, Cybercash and others were focused on securing the ledger side and needed larger transaction fees and thus larger amounts of money to function. To scale down we were all looking at hash chain ideas from Lamport’s S/KEY from the late 80’s and distributed transactional ledgers from X/Open’s DTP from the early 90s as inspirations. DEC introduced Millicent during this period, and I distinctly remember people saying “this will not work, it requires consumers to hold keys in a electronic wallet”. On the cryptographic hash side of this problem Adam Back did Hashcash, Rivest and his crew introduced PayWord and Micromint. On the transaction side CMU introduced NetBill.

Nick Szabo wrote using hashes for post-unforgeable transaction logs in his original smart contract paper in ’97, in which he referred to Surety’s work (and they held the Merkle hash tree and other time signature patents), but in that original paper he did not look at Proof of Work at all. It was another year before he, Wei Dai, and Hal Finney started talking about using proof-of-work as a possible foundational element for smart contracts. I remember some discussions over beer in Palo Alto circa ’99 with Nick after I became CTO of Certicom about creating dedicated proof-of-work secure hardware that would create tokens that could be used as an underlying basis for his smart contract ideas. This was interesting to Certicom as we had very good connections into cryptographic hardware industry, and I recommended that we should hire him. Nick eventually joined Certicom, but by that point they had cancelled my advanced cryptography group to raise profits in order to go public in the US (causing me to resign), and then later ceased all work in that area when the markets fell in 2001.

I truly believe that would could have had cryptographic smart contracts by ’04 if Certicom had not focused on short-profits (see Solution #3 at bottom of this post for my thoughts back in 2004 after a 3-year non-compete and NDA)…

What is required, I believe, is a major paradigm shift. We need to leave the whole business of fear behind and instead embrace a new model: using cryptography to enable business rather than to prevent harm. We need to add value by making it possible to do profitable business in ways that are impossible today. There are, fortunately, many cryptographic opportunities, if we only consider them.

Cryptography can be used to make business processes faster and more efficient. With tools derived from cryptography, executives can delegate more efficiently and introduce better checks and balances. They can implement improved decision systems. Entrepreneurs can create improved auction systems. Nick Szabo is one of the few developers who has really investigated this area, through his work on Smart Contracts. He has suggested ways to create digital bearer certificates, and has contemplated some interesting secure auctioning techniques and even digital liens. Expanding upon his possibilities we can view the ultimate Smart Contract as a sort of Smart Property. Why not form a corporation on the fly with digital stock certificates, allow it to engage in its creative work, then pay out its investors and workers and dissolve? With new security paradigms, this is all possible.

When I first heard about Bitcoin, I saw it as having clearly two different parts. First was a mix of old ideas about unforgeable transaction logs using hash trees combined into blocks connected by hash chains. This clearly is the “blockchain”. But in order for this blockchain to function, it needed timestamping, for which fortunately all the patents had expired. The second essential part of Bitcoin was through a proof-of-work system to timestamp the blocks, which clearly was based on Back’s HashCash rather than the way transactions were timestamped in Szabo’s BitGold implementation. I have to admit, when I first saw it I didn’t really see much in Bitcoin that was innovative — but did appreciate how it combined a number of older ideas into one place. I did not predict its success, but thought it was an interesting experiment and that might lead to a more elegant solution. (BTW, IMHO Bitcoin became successful more because of how it leveraged cypherpunk memes and their incentives to participate in order to bootstrap the ecosystem rather than because of any particularly elegant or orginal cryptographic ideas).

In my head, Bitcoin consists of blocks of cryptographic transactional ledgers chained together, plus one particular approach to time-stamping this block chain that uses proof-of-work method of consensus. I’ve always thought of blockchain and mining as separate innovations.

To support this separation for your article, I have one more quote to offer you from Nick Szabo:

Instead of my automated market to account for the fact that the difficulty of puzzles can often radically change based on hardware improvements and cryptographic breakthroughs (i.e. discovering algorithms that can solve proofs-of-work faster), and the unpredictability of demand, Nakamoto designed a Byzantine-agreed algorithm adjusting the difficulty of puzzles. I can’t decide whether this aspect of Bitcoin is more feature or more bug, but it does make it simpler.

As to your question of when the community first started using the word consensus, I am not sure. The cryptographic company I founded in 1988 that eventually created the reference implementation of SSL 3.0 and offered the first TLS 1.0 toolkits was named “Consensus Development” so my memory is distorted. To me, the essential problem has always been how to solve consensus. I may have first read it about it in “The Ecology of Computation” published in 1988 which predicted many distributed computational approaches that are only becoming possible today, which mentions among other things such concepts as Distributed Scheduling Protocols, Byzantine Fault-Tolerance, Computational Auctions, etc. But I also heard it from various science fiction books of the period, so that is why I named my company after it.

The future

What about tokens?

Virtual tokens may only be required for permissionless ledgers – where validators are unknown and untrusted – in order to prevent spam and incentivize the creation of proofs-of-work.  In contrast, if parties are known and trusted – such as a permissioned ledger – there are other historically different mechanisms (e.g., contracts, legal accountability) to secure a network without the use of a virtual token. 6

Is everything still too early or lack an actual sustainable use-case?

Maybe not.  It may be the case, as Richard Brown recently pointed out, that for financial institutions looking to use shared, replicated ledgers, utility could be derived from mundane areas, such as balance sheets.  And you don’t necessarily need a Tom Sawyer botnet to protect that.

What attracts or repels use-cases then?

• Folk law: “Anything that needs censorship-resistance will gravitate towards censorship-resistant systems.”
• Sams’ law: “Anything that doesn’t need censorship-resistance will gravitate towards non censorship-resistant systems.”

Many financial institutions (which is just one group looking at shared, replicated ledgers) are currently focused on: fulfilling compliance requirements, reducing cost centers, downscaling branching and implementing digital channels.  None of this requires censorship-resistance.  Obviously there are many other types of organizations looking at this technology from other angles and perhaps they do indeed find censorship-resistance of use.

In conclusion, as copiously noted above, blockchains are a wider technology than just the type employed by Bitcoin and includes permissioned ledgers.  It bears mentioning that “permissioned” validators are not really a new idea either: four years ago Ben Laurie independently called them “mintettes” and Sarah Meiklejohn discussed them in her new paper as well.

Endnotes

1. See The financial cloud from Adam Ludwin [↩]
2. Thanks to Christopher Allen for pointing this out. [↩]
3. See The myth of a cheaper Bitcoin network: a note about transaction processing, currency conversion and Bitcoinland [↩]
4. See Bitcoins: Made in China [↩]
5. Why would banks want to use a communal ledger, validated by pseudonomyous pools whom are not privy to a terms of service or contractual obligation with? See Needing a token to operate a distributed ledger is a red herring and No, Bitcoin is not the future of securities settlement [↩]
6. See also Needing a token to operate a distributed ledger is a red herring and Consensus-as-a-service [↩]