What a Bitcoin white book was right, wrong and we still do not know

Joseph Bonneau is an assistant professor at New York University and coauthor of "Bitcoin and Cryptocurrency Technologies", a popular textbook.

This piece of exclusive opinion is part of CoinDesk "Bitcoin at 10: The Satoshi White Paper"series.

---

Bitcoin's white paper was rightly recognized as one of the most original and influential computer records in history.

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

But it's worth taking a critical look at the paper (and the original design of Bitcoin for things that are not explicitly mentioned in the document) and asking: how much did the paper work? How wrong was it? And how much of the paper do not know the answer yet?

That bitcoin is right

In a sense, this is the most difficult category to evaluate.

One brand of a truly successful idea is that people forget how people have looked at the world before the idea arrived. Many of Bitcoin's most fundamental contributions seem quite obvious in hindsight, but they were not at all at the time.

It's easy to forget that cryptocurrency was a reserve for most of the 2000s. After the failure of many attempts in the 90's to build a functioning system (largely using the ideas outlined by David Chaum over the years & # 39; 80), few articles were published in the area. Many simply believed that there was no viable market for a non-state currency.

Before Bitcoin, decentralized systems constituted a research area active in the 2000s (often conceived as peer-to-peer networks) and research on anonymity was coming (with the development of Tor).

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

1. Provide incentives for miners. One of Bitcoin's major contributions is providing incentives for miners through inflation and taxes, making the system difficult to attack. This model has generally been successful and it is fair to say that few have seen it arrive. Many P2P systems in the pre-Bitcoin that offered open participation (anyone can handle a node) were afflicted by Sybil attacks and incentive problems.
2. Simplified payment verification. The division into Bitcoin between complete nodes and light nodes (or SPVs) proved to be quite powerful and the block structure incorporated in Bitcoin made this not only possible, but a natural way of seeing the system. Bitcoin's UTXO design also made it quite simple.
3. Support for scripting. Although limited, support for Bitcoin scripts (not covered in the white paper) allowed us to use several useful features such as multi-sig accounts and payment networks. It was wise to imagine a system that supports more than simple payments.
4. Recognition of long-term incentives. There is no evidence that Satoshi expected to see mines of mines or industrial scale mines in the white paper. But the document includes a very careful line on the risks of centralization: "[an attacker] he should find it more profitable to play according to the rules, rules that favor him with more new coins than all the others combined, rather than weaken the system and the validity of his wealth. "Despite a large number of theoretical attacks by miners written since then No one has been seriously attempted in practice, Satoshi has recognized a powerful principle, that miners have long-term incentives not to attack because they are invested in the health of the ecosystem.

What bitcoin was wrong

We will ignore some curious features in retrospect in the early versions of the bitcoin code, such as the pay-to-IP-address and an integrated e-commerce system, which has never seen the light of day.

But there are some characteristics of Bitcoin that appear "wrong" in the sense that no system built today will repeat them.

• 1. ECDSA. While this signature algorithm was a much better choice than, for example, at RSA, it is less than EC-Schnorr on all accounts. Most likely, Satoshi simply did not know about this option (a legacy of software patents on Schnorr). Today, it would be obvious to use Schnorr, if not a more advanced signature scheme such as BLS.
  2. Malleability of transactions This unintentional problem has led to headaches for features such as payment networks as well as making the attack famous on the mountain. Gox. Today, a prudent design uses something along the lines of the segregated witness to ensure that transaction IDs are unique and predictable.
  3. Functionality since it was added. Clearly, it was an error not to include popular features such as pay-to-script-hash (P2SH) and check-locktime-verify, which were later added by softforks.
  4. Limited divisibility of coins. Bitcoin has a limit of 21 million bitcoins, but more importantly, it has a limit of about 2 ^ 52 satoshi as an atomic unit. This would never have been enough if Bitcoin had become the only payment system on Earth, leaving less than one million units per person. This is not enough to capture both daily transactions (even rounded to the equivalent of one-tenths of a dollar) and also large holdings. It would be quite economical to expand this with a few more bits.
  5. Blocks in a simple chain. Given the amount of a "blockchain" keyword it has become important to note that putting blocks in a linear chain is an oversight that makes it expensive to verify that an old blockchain at the current head in an ultra-light client. Bitcoin correctly enters transactions into a tree, so why not the blocks themselves? A jump list would be another important improvement. It is interesting to note that the Certificate Transparency project (designed independently by Bitcoin in the same era) does it well and inserts each update into a tree, while a few Bitcoin successors have moved away from the linear chain design.
  6. No state commitment. Bitcoin miners trace the system status as an unspent transaction output set (UTXO). But this is not engaged in any block and must be imputed by history. This makes it rather difficult for light customers to confirm what the current status is. It would be easy enough to add a UTXO commitment to each block and many later systems (such as Ethereum) run a version of this.
  7. Simplistic attack analysis. The Bitcoin white paper dedicates a relatively large amount of space (about a quarter of the text) to the analysis of the possibilities that a miner with less than 51% of mining power successfully succeeds in throwing a fork and becoming lucky. The subsequent analysis identified many other attack vectors (such as selfish extraction) and this analysis seems rather dated.
  8. One-CPU-one-vote. Satoshi described Bitcoin as a system in which most participants would be miners using their CPUs. This has not been the case for many years as the mining sector is dominated by dedicated hardware. While it is questionable whether this is a good or bad development – it is certainly not what was included in the original white paper.

What we still do not know

1. SHA-256 puzzle. The use of Bitcoins of hash-based computational puzzles ("proof-of-work") was one of the most active topics of discussion. Consume too much energy? Do ASICs encourage centralization? Do puzzles designed for GPU-based mining or storage-bound mining activities produce better incentives at lower costs? In the end the test of the game will win?
2. Block size and other parameter limits. To say the least, the block limit of 1 MB was a source of debate, as well as the 10-minute interval between blocks. Many follow-up systems seemed to thrive on larger or more frequent blocks. Will Bitcoin's conservative design prove to be wise in the long run?
3. L & # 39; anonymity. The topics outlined in the Bitcoin white paper that provides anonymity because only public keys are published are now known to be rather incomplete due to the development of the transaction chart analysis. Systems like Confidential Transactions, Monero or Zcash offer more cryptographic privacy. On the other hand, many schemes compatible with previous versions have been proposed to obfuscate the Bitcoin blockchain activity by mixing. Is anonymity an important feature that requires integrated support that Bitcoin has overlooked?
4. Inflation. Bitcoin's project seeks to avoid inflation, but many economists have pointed out that it is in fact deflationary, since in the end coins can only come out of circulation when the keys are lost (or coins are intentionally rendered non-expendable through transactions "proof of burn"). Zero inflation actually requires a small amount of new currency issues just to keep up with lost coins. If this was a mistake in Bitcoin, we might not realize it for many years as inflation is slowly running out.
5. The transition to transaction fees. Bitcoin coded hardcoded a slow transition to reward miners primarily from inflation to reward them primarily via transaction fees. No one really knows how it will end, but some research suggests that this could cause significant instability in the post-inflation world.
6. Limited programmability. Bitcoin has imposed strict limits on its programmability to keep transactions easy (and predictable in terms of cost) to be verified. The Ethereum project has suggested a significant demand for a richer programming model, although it introduces further scaling problems. Will Bitcoin be hampered in the long run by its weaker programming model?

Printed circuit via Shutterstock

The leader in blockchain news, CoinDesk is a point of reference that is committed to the highest journalistic standards and adheres to a strict set of editorial policies. CoinDesk is an independent operating subsidiary of the Digital Currency Group, which invests in criptovalute and blockchain startups.