The Great Bitcoin Debate: Innovation vs. Ossification

The big debate right now among Bitcoin developers is this: How much should the Bitcoin protocol change? All software, Bitcoin included, must evolve

Visual representation of Bitcoin cryptocurrency. /Getty Images Plus

LONDON, ENGLAND - MAY 30: In this photo illustration, a visual representation of Bitcoin ... [+] cryptocurrency is pictured on May 30, 2021 in London, England. Bitcoin is a decentralised digital currency, which has been in use since 2009. (Photo illustration by Edward Smith/Getty Images)

The big debate right now among Bitcoin developers is this: How much should the Bitcoin protocol change? All software, Bitcoin included, must evolve over time as users, networks, and use cases evolve. The question is not binary, but a matter of degree.

Bitcoin has always been in a state of change, sometimes more than others. Perhaps the most radical changes occurred in the early years, when Satoshi changed the block size limit and the functionality of the Bitcoin scripting language in major ways. Now that Satoshi is gone, it is up to the core developers to reach a consensus on which changes to adopt moving forward, and this can be a contentious issue.

There are a cadre of changes that are without controversy, namely, the changes that improve the security of the network with almost no foreseeable resource or opportunity costs. The best example of this is p2pkh, the use of hashing of public keys. When Bitcoin started, a Bitcoin address was a public key, a point on Bitcoin's elliptic curve. To pay to that address, you would pay to that public key. After p2pkh, the Bitcoin address became the hash of a public key, which is more secure because the public key passes through the hashing algorithm SHA-256. If an attacker were to break Bitcoin’s elliptic curve digital signature algorithm (ECDSA), it would still need to break SHA-256 in order to recover the private key that secures those bitcoins. Adding an extra hash operation is computationally trivial, and so no one protested p2pkh.

But other improvements are not so innocuous. The last upgrade, Taproot, dramatically increased the transactional complexity and privacy of Bitcoin transactions. But it also opened the door to new use cases that I do not believe the core developers would have anticipated, like ordinals and inscriptions. Any major change that widens the functionality of Bitcoin has both upside potential and downside risk.

This is probably why Satoshi probably disabled some of the early opcodes in Bitcoin to constrain the Bitcoin scripting language deliberately. When the digital object is money, the incentives for attacks are high, and so it makes sense to limit Bitcoin's programmability to limit the attack surface. At the same time, new functionality can attract new users.

This question of whether and how to modify the protocol is, in my view, the most important question in Bitcoin development today, and possibly in the future. So, here's the skinny on the debate.

The case for innovation

The case for innovation comes from those who want to expand Bitcoin’s scripting language to include a wide array of programs and smart contracts. These contracts are possible on other blockchains like Ethereum, and the innovators want to bring that functionality to Bitcoin, the world's most secure network. However, there are other more conservative and traditional Bitcoiners who also believe that expanding the financial use cases of Bitcoin in the future will require more programmability and flexibility in scripting. This was part of the motivation for Taproot to allow for higher dimensional financial contracts on Bitcoin.

Some of the motivation for innovation comes from the desire to create and tinker, which is a part of software developer culture writ large (perhaps apparent more outside of Bitcoin than within). But there's another justification often given for protocol innovation: Bitcoin doesn't have enough usage today, so the protocol needs to attract new users. These new users will have new use cases, requiring new functionality in Bitcoin programming. It's impossible to predict these use cases in advance, but it is possible to expand Bitcoin’s scripting to allow for these in the future.

The case for ossification

The ossifiers believe that the only innovation that Bitcoin needs is greater security. For example, relay messages between Bitcoin nodes today are unencrypted. And so, encrypting these messages would be computationally cheap and increase security. But anything beyond that would only increase the attack surface of Bitcoin, which could lead to downside risks that could upset the stability of the network and its use as a store of value.

If Bitcoin truly is to attract trillions of dollars of economic value in the next few decades, the chief objective should be stability and security, not innovation and experimentation. In fact, it is precisely the predictable and unchanging money supply of Bitcoin that distinguishes Bitcoin from central banks, which constantly change the fiat money supply at will. The flag of the ossifiers is “If it ain't broke, don't fix it,” and the vast majority of Bitcoin’s innovations happened in version 0.1 that Satoshi wrote.

The debate today

This debate takes form today most notably in the proposal for covenants,