How Much Should Bitcoin Change?
The debate on innovation versus ossification of the Bitcoin protocol.
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. It can allow new use cases for Bitcoin that were unavailable before, but with those new use cases also comes a larger attack surface.
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. Let me give both sides and then offer my hot take.
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: “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, which allow restrictions on Bitcoin UTXOs. There are 7 or so major proposals outstanding, and they range in functionality and purpose. Some of these introduce new opcodes into Bitcoin script that would allow for narrow use cases to emerge (like OP_Vault), while others are more general that would enable covenants but also a wider array of programs on Bitcoin (like OP_CAT). The consensus has not yet been formed on which of the covenant proposals are best, if any.
Layer 2 innovations on Bitcoin add an additional twist. You might think that Layer 2s would have no impact on the underlying protocol. But if a Layer 2 grows in usage and influence, then it will attract a social community that will advocate for altering the protocol, or portions of it, to better adapt to that Layer 2. This is what has already happened with the Lightning Network. Transaction malleability was always theoretically a problem with Bitcoin, but it wasn't until the Lightning Network that it became apparent to everyone, which led to SegWit resolving malleability by creating the witness data structure. I expect this trend to continue, where innovations on Layer 2 and Layer 3 technologies on top of Bitcoin will inevitably impact the base layer protocol in some way.
My View
Let me end where I started: the question of whether to change Bitcoin is not binary but a matter of degree. I lie between the ossifiers and the innovators, but closer to the ossifiers. Here are my reasons.
First, the history of innovation shows that constraints on a problem have a way of inspiring rather than crushing innovation. This may seem paradoxical, but many of society's great innovations emerged out of a constrained environment, such as the automobile, the transistor, the personal computer, ARPANET, etc. Constraints have a way of focusing the mind to deliver a solution. In Bitcoin, for years people thought sidechains were necessary for an innovation like prediction markets on Bitcoin. However, a recent development called BitVM shows that prediction markets may be possible even without a separate sidechain. So, I don't believe that removing constraints on Bitcoin is necessary for innovation, as the current history has already shown.
Second, innovation has both upside potential and downside risk. No core developer (on record) predicted ordinals and inscriptions, and so too could no developer predict the innovations of tomorrow that would come with expanding Bitcoin's programmability. Sometimes the voice of innovation, prominent in Bitcoin developer meetups like the Austin BitDevs, only considers the upside and not the downsides. So, let's be cautiously optimistic about these innovations and know that there are benefits as well as costs.
Third, the current and most convincing use case of Bitcoin, a scarce digital store of value, is still very much in the early stages and needs no changes to the protocol. Perhaps the biggest and most exciting development in Bitcoin overall is the transfer of legacy financial assets to the Bitcoin network. The ETFs were just step one. Wealth and asset managers are step two, and then large institutional investors like pension funds and sovereign wealth funds. As institutional attention to Bitcoin grows, this will have a bigger impact on price and adoption than any amount of new programmability will provide. This transfer, in my view, will occur slowly over time, and it is important not to disrupt it.
And as that transfer of value from analog to digital takes place, it will ultimately drive new use cases themselves. Sovereign wealth funds may have demand for new technologies on top of Bitcoin that we cannot imagine now, and the financial impacts would be large. And this is a better playbook for innovation anyway: to let the needs of users drive development, rather than the reverse. So let's let the digital scarcity thesis play out, and innovate above — not on — the base layer.