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.

It has launched a billions of dollars industry and thousands of follow-up documents.

But is it worthwhile to throw a critical look on the paper (and the elements of the original Bitcoin drawing omitted from the paper) to ask what did the right paper do? What was wrong? And to which questions do we still do not know the answer?

That bitcoin is right

This could be the most difficult category to complete.

One brand of a truly successful idea is that we forget how people thought of the world before that idea came. Many of Bitcoin's most fundamental contributions seem obvious only afterwards.

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.

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

But these were not seen as necessary features for a payment system. What did Bitcoin contribute?

1. Incentives for miners. One of Bitcoin's major contributions is providing incentives for miners through inflation and taxes. 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 era that offered open participation (anyone can execute a node) were afflicted by Sybil attacks and other problems. There were many attempts to encourage honest participation, but before Bitcoin no system succeeded in making it work.
2. Clear customers. Bitcoin support for complete nodes and light nodes (or SPVs) proved to be quite powerful and the block structure incorporated in Bitcoin made it not only possible but natural to implement a lightweight client.
3. Scripting. Although limited, Bitcoin scripting support (not covered in the white paper) has enabled several useful features such as multi-signing accounts and payment networks. It was wise to imagine a system that supports more than simple payments.
4. Recognition of long-term incentives. Satoshi did not provide mining or mining pools on an industrial scale, at least not in the white paper. But the document includes a very careful line on the risks of centralization: "[an attacker] it should find it more profitable to play according to the rules, rules that favor it with more new coins than all the others combined, rather than weaken the system and the validity of its wealth. "Despite a large number of theoretical attacks by miners written since No one has been seriously attempted in practice, and Satoshi has recognized a powerful principle: 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 several Bitcoin features that appear "wrong" in the sense that no system built today should repeat them.

• 1. ECDSA. While this signature algorithm was a much better choice than, for example, RSA, it is inferior to EC-Schnorr in all aspects. Most likely, Satoshi simply did not know about this option (a legacy of software patents on Schnorr). Today, it would be clearly advantageous to use Schnorr, given its support for the threshold signature, if not a more advanced signature scheme such as BLS.
  2. Malleability of transactions This unintentional problem has led to headaches for protocols such as payment networks as well as notably allowing the attack on the mountain. Gox. Today, a prudent design would use something along the lines of the segregated witness (SegWit) to ensure that transaction hashes are not malleable.
  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. If Bitcoin really does become the only payment system on Earth, this would provide less than a 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 have been cheap enough to expand this with a few dozen extra bits so that divisibility would never be a problem.
  5. Blocks in a simple chain. Given the amount of a "blockchain" keyword it has become important to note that putting blocks in a straight chain is an oversight that makes it expensive for an ultra-light client to verify that an old block is included in the current chain. 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. The Bitcoin miners all track 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 difficult for light customers to confirm what the current status is and whether the transaction has been spent. 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 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 ASIC extraction 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 was (to a lesser extent) the 10-minute interval between blocks. Many follow-up systems have thrived with 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 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 a critical 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 "proof of burn" transactions). Zero inflation actually requires a small amount of new currency issues just to keep up with the lost currency. 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 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 shown significant demand for a richer programming model, although its model introduces further scaling problems. Will Bitcoin be hampered in the long run by its weaker programming model?

Arial labyrinth through Shutterstock