What Bitcoin’s White Paper Got Right, Wrong and What We Still Don’t Know

Oct 30, 2018 at 08:00 UTC

Joseph Bonneau is an assistant professor at New York University and co-author of “Bitcoin and Cryptocurrency Technologies,” a popular textbook. 

This exclusive opinion piece is part of CoinDesk’s “Bitcoin at 10: The Satoshi White Paper” series.

The Bitcoin white paper has been, rightfully, recognized as one of the most original and influential computer science papers in history.

We all know how it has launched a $1 billion industry and thousands of follow-up research papers.

But it’s worth turning a critical eye on the paper (and original Bitcoin design for things not mentioned explicitly in the paper) and asking: how much did the paper get right? How much did it get wrong? And how much of the paper do we still not know the answer to?

What Bitcoin got right

In a sense, this is the hardest category to assess.

One mark of a truly successful idea is that it people forget how people looked at the world before that idea came around. Many of the most fundamental contributions of Bitcoin seem somewhat obvious in hindsight, but were not at all at the time.

It’s easy to forget that cryptocurrency was a research backwater for most of the 2000s. After the failure of many attempts in the 1990s to build a working system (largely using the ideas outlined by David Chaum in the 1980s), few papers were published in the area. Many simply believed there was no viable market for a non-state currency.

Prior to Bitcoin, decentralized systems were an active research area in the 2000s (often couched as peer-to-peer networks) and anonymity research was coming into its own (with the development of Tor).

But these were not seen as necessary features for a payment system.

1. Providing incentives for miners. One of Bitcoin’s core contributions is providing incentives for miners via inflation and fees, making the system hard to attack. This model has generally been successful and it’s fair to say few saw it coming. Many P2P systems in the pre-Bitcoin era that offered open participation (anybody can run a node) were plagued by Sybil attacks and incentive problems.
2. Simplified payment verification. The division in Bitcoin between full nodes and light (or SPV) nodes has proven quite powerful, and the block structure embedded into Bitcoin has made this not just possible but a natural way of viewing the system. Bitcoin’s UTXO design has also made this quite straightforward.
3. Support for scripting. While limited, Bitcoin’s scripting support (not discussed at all in the white paper) has enabled several useful features like multi-sig accounts and payment networks. It was wise to envision a system supporting more than simple payments.
4. Recognizing long-term incentives. There’s no evidence that Satoshi expected to see industrial-scale mining or mining pools in the white paper. But the paper does include a very prescient line about the risks of centralization: “[an attacker] ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth.” Despite a large number of theoretical attacks by miners being written about since, none have been seriously attempted in practice. Satoshi recognized a powerful principle, that miners have long-term incentives not to attack since they are invested in health of the ecosystem.

What Bitcoin got wrong

We’ll ignore some quaint-in-retrospect features in early versions of the bitcoin code, such as pay-to-IP-address and a built-in e-commerce system, that never saw the light of day.

But there are a few features of Bitcoin that appear “wrong” in that no system built today would repeat them.

• 1. ECDSA. While this signature algorithm was a far better choice than, say, RSA, it is inferior to EC-Schnorr on all accounts. Most likely Satoshi simply didn’t know about this option (a legacy of software patents around Schnorr). Today, it would be obvious to use Schnorr instead, if not a more advanced signature scheme such as BLS.
  2. Transaction malleability. This unintentional issue has led to headaches for features such as payment networks as well as famously enabling the attack on Mt. Gox. Today a prudent design would use something along the lines of segregated witness to ensure transaction IDs are unique and predictable.
  3. Features since added. Quite obviously, it was a mistake not to include popular features such as pay-to-script-hash (P2SH) and check-locktime-verify, which have been added since by soft forks.
  4. Limited divisibility of coins. Bitcoin has a limit of 21 million bitcoins, but more importantly, it has a limit of about 2^52 satoshis as the atomic unit. This was never going to be enough if Bitcoin were to really become Earth’s only payment system, leaving fewer than a million units per human being. This isn’t nearly enough to capture both day-to-day transactions (even rounded to the equivalent of tenths of a dollar) and also large holdings. It would be quite cheap to expand this with a few extra bits.
  5. Blocks in a simple chain. Given how much of a buzzword “blockchain” has become it’s worth noting that putting blocks in a linear chain is an oversight that makes it costly to verify that an old blockchains to the current head in an ultra-lightweight client. Bitcoin correctly puts transactions into a tree, so why not the blocks themselves? A skip list would be another major improvement. Interestingly, the Certificate Transparency project (designed independently of Bitcoin in the same era) gets it right and puts each update into a tree, while few successors to Bitcoin have strayed from the linear chain design.
  6. No state commitments. Bitcoin miners track the system state as the set of unspent transaction outputs (UTXOs). But this is not committed to each block and must be imputed from history. This makes it quite hard for light clients to confirm what the current state is. It would be quite easy to add a UTXO commitment to each block and many subsequent systems (such as Ethereum) do a version of this.
  7. Simplistic attack analysis. The Bitcoin white paper devotes a relatively large amount of space (about a quarter of the text) to analyzing the chances of a miner with less than 51% mining power successfully launching a fork by getting lucky. Subsequent analysis has identified many other attack vectors (such as selfish mining) and this analysis now looks quite dated.
  8. One-CPU-one-vote. Satoshi described Bitcoin as a system where most participants would be miners using their CPUs. This has not been the case for many years now as mining is dominated by dedicated hardware. While it’s debatable if this is a good or bad development-it’s certainly not what was pitched in the original white paper.

What we still don’t know

1. SHA-256 puzzles. Bitcoin’s use of hash-based computational puzzles (“proof-of-work”) has been one of the most active topics of debate. Does it consume too much energy? Do ASICs encourage centralization? Would puzzles designed for GPU-based mining or storage-bounded mining produce better incentives at lower cost? Will proof-of-stake eventually win out?
2. The block size and other parameter limits. To say the least, the 1 MB block limit has been a source of debate, so has the 10-minute interval between blocks. Many follow-up systems have seemed to thrive with larger or more frequent blocks. Is Bitcoin’s conservative design going to prove wise in the long run?
3. Anonymity. The arguments sketched in the white paper about Bitcoin providing anonymity as only public keys are posted are now known to be quite incomplete due to the development of transaction-graph analysis. Systems such as Confidential Transactions, Monero or Zcash offer stronger cryptographic privacy. On the other hand, many backwards-compatible schemes have been proposed to obfuscate activity on the Bitcoin blockchain by mixing. Is anonymity an important feature requiring built-in support that Bitcoin overlooked?
4. Inflation. Bitcoin’s design seeks to avoid inflation, but many economists have pointed out it is actually deflationary, as eventually coins can only exit circulation as keys are lost (or coins are intentionally made unspendable via “proof-of-burn” transactions). Zero inflation actually requires a small amount of new currency issuance just to keep pace with lost coins. If this was a mistake in Bitcoin though, we may not realize it for many years as inflation is slowly wound down.
5. The switch to transaction fees. Bitcoin hardcoded a slow transition from rewarding miners primarily by inflation to rewarding them primarily via transaction fees. Nobody really knows how this will play out but some research suggests that this may cause significant instability in the post-inflation world.
6. Limited programmability. Bitcoin imposed severe limits on its programmability to keep transactions easy (and predictable in cost) to verify. The Ethereum project has suggested significant demand for a richer programming model, though they introduce additional scaling concerns. Will Bitcoin be handicapped in the long run by its weaker programming model?

Circuit board via Shutterstock 

The leader in blockchain news, CoinDesk is a media outlet that strives for the highest journalistic standards and abides by a strict set of editorial policies. CoinDesk is an independent operating subsidiary of Digital Currency Group, which invests in cryptocurrencies and blockchain startups.