What Bitcoin's White Paper Got Right, Wrong and What We Still Don't Know
Bitcoin's white paper has its flaws, too.
Oct 30, 2018 at 8:00 a.m. UTC
:format(webp)/cloudfront-us-east-1.images.arcpublishing.com/coindeskuat/3O2AL44EDZEFPDBM6BTTGYHDC4.jpg)
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.
It has launched a billion-dollar industry and thousands of follow-up papers.
But it's worth turning a critical eye on the paper (and elements of the original Bitcoin design omitted from the paper) to ask what did the paper get right? What did it get wrong? And what questions do we still not know the answer to?
What Bitcoin got right
This may be the hardest category to compile.
One mark of a truly successful idea is that we forget how people thought about the world before that idea came around. Many of the most fundamental contributions of Bitcoin seem obvious only in hindsight.
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 described as peer-to-peer networks) and anonymity research was coming into its own (with the development of Tor and other systems).
But these were not seen as necessary features for a payment system. What did Bitcoin contribute?
- Incentives for miners. One of Bitcoin's core contributions is providing incentives for miners via inflation and fees. 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 other problems. There were many attempts to incentivize honest participation, but prior to Bitcoin no system quite got it to work.
- Light clients. Bitcoin's support for both full nodes and light (or SPV) nodes has proven quite powerful, and the block structure embedded into Bitcoin has made it not just possible but natural to implement a light client.
- Scripting. While limited, Bitcoin's scripting support (not discussed at all in the white paper) has enabled several useful features like multi-signature accounts and payment networks. It was wise to envision a system supporting more than simple payments.
- Recognizing long-term incentives. Satoshi didn't anticipate industrial-scale mining or mining pools, at least not 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 several features of Bitcoin that appear "wrong" in that no system built today should repeat them.
- ECDSA. While this signature algorithm was a far better choice than, say, RSA, it is inferior to EC-Schnorr in all aspects. Most likely Satoshi simply didn't know about this option (a legacy of software patents around Schnorr). Today, it would be clearly advantageous to use Schnorr instead given its support for threshold signing, if not a more advanced signature scheme such as BLS.
- Transaction malleability. This unintentional issue has led to headaches for protocols 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 (SegWit) to ensure transaction hashes are non-malleable.
- 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.
- 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. If Bitcoin were to really become Earth's only payment system, this would provide 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 have been quite cheap to expand this with a few dozen extra bits such that divisibility would never be an issue.
- 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 for an ultra-lightweight client to verify that an old block is included in the current chain. 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.
- No state commitments. Bitcoin miners all 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 hard for light clients to confirm what the current state is and if the transaction has been spent. 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.
- 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 dated.
- 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 ASIC mining is a good or bad development-it's certainly not what was pitched in the original white paper.
STORY CONTINUES BELOW
What we still don't know
- 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?
- The block size and other parameter limits. To say the least, the 1 MB block limit has been a source of debate, as has been (to a lesser extent) the 10-minute interval between blocks. Many follow-up systems have thrived with larger or more frequent blocks. Is Bitcoin's conservative design going to prove wise in the long run?
- Anonymity. The arguments sketched in the white paper about Bitcoin providing anonymity as only public keys are posted are now known to be 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 a critical feature requiring built-in support that Bitcoin overlooked?
- 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 when 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 currency. If this was a mistake in Bitcoin, we may not realize it for many years as inflation is slowly wound down.
- The switch to transaction fees. Bitcoin hardcoded a slow transition from rewarding miners primarily by inflation to rewarding them primarily via transaction fees. Nobody knows how this will play out but some research suggests that this may cause significant instability in the post-inflation world.
- Limited programmability. Bitcoin imposed severe limits on its programmability to keep transactions easy (and predictable in cost) to verify. The Ethereum project has demonstrated significant demand for a richer programming model, though its model introduces additional scaling concerns. Will Bitcoin be handicapped in the long run by its weaker programming model?
Arial maze via Shutterstock
:format(webp)/downloads.coindesk.com/arc/failsafe/user/1x1.png)