The relentlessly increasing challenge of moving Bitcoin forward.
Bitcoin has been operating fairly smoothly for 14 years at this point, but like most of us, it doesn’t look quite the same as it did in 2009. As Bitcoin
However, this has begun to create a new challenge known as ossification. It’s a well-known principle, but it is one that stands to have major implications for Bitcoin and its users.
Ossification Explained
Ossification refers to the general tendency for protocols to become increasingly difficult to upgrade as they grow in adoption. As new protocol features are integrated, they become part of the “language” that is used for machines to speak to each other. This can then cause things to break if protocol updates are introduced that aren’t compatible with the protocol rules that are already in use, because it’s quite difficult to coordinate updates across a large distributed set of machines. Due to this risk of breaking the ability for machines to communicate, developers eventually stop proposing changes and the protocol effectively crystallizes.
A prime example of this is the well-documented ossification of the Transmission Control Protocol. TCP is one of the primary protocols used to handle traffic on the internet, and almost all web applications are built on top of it. What’s more, many of these services apply additional architecture built on top of TCP. This is why it is so hard to change the protocol without serious risk of “breaking” large swaths of the internet. This has also led to an internet that has a significant number of broken data paths but no easy way to fix them. Solutions to this situation have been proposed, such as QUIC, but the issue is ongoing and needs active management to address.
What Bitcoin Ossification Looks Like
Unsurprisingly, this issue also rears its ugly head for the Bitcoin protocol. In the beginning, relatively few people were running the nodes that connect to each other to form the network. Upgrades, in the form of Bitcoin Improvement Proposals, were easy enough to implement, as the community was small and largely on the same page.
Bitcoin has a very rich history of upgrades from both BIPs and bug fixes, but in recent years they have been fewer and further between. The two most recent protocol upgrades were SegWit and Taproot. This isn’t the article for discussing the merits of these forks, only to observe that SegWit was released in 2017 and took over two years to reach 50% adoption. Even Taproot, which was released well over a year ago, has only recently broken through 10% adoption. Point being: it can take quite a while for even a moderately sized network to adopt changes.
This highlights the problem at hand with Bitcoin’s governance model and how it is affecting ossification. Because the ecosystem evolves by “rough consensus and running code,” every node operator is an independent player on the network. Progress at the base protocol layer only occurs where there is broad agreement across bitcoiners on what “forward progress” actually looks like. This is by design, as it also makes it incredibly difficult for harmful changes to be adopted. But as this base swells, it becomes exponentially harder for consensus on changes to be reached, as well as for update deployments to actually occur.
Built into the very logic and incentives Bitcoin leverages, the primary motivation for using it is economic. The only reason most users would want to change the protocol is if they understand how the changes add significant value; otherwise, it just
As the user population has grown, there are a lot more people who don’t really understand as much about the code, but they know it’s securing their money. When they hear about a change being made, it triggers worries that their funds may be put at risk. The only way to counter this is through good education for the community, but then there are some who spread misinformation either intentionally or because they’re just uninformed. This is the cornerstone of the situation we see with Bitcoin and why it is becoming increasingly difficult to make progress.
Bitcoin Shouldn’t Stop Evolving
Innovation will continue to occur in Bitcoin; it’s just a question of where that innovation will be implemented. New developments are happening all the time that are pushing even more traffic and data onto the network. Perhaps most notably, the recent creation of Ordinals, which are essentially NFTs built on top of the Bitcoin network. Furthermore, there’s no shortage of suggestions that have been put forward for improving the protocol. These include Covenants, which are effectively a mechanism to enforce conditions on future Bitcoin transactions and could have massive implications for network security, fund recovery, and the creation of vaults. There’s also been talk of Drivechains, which would implement permissionless pegged sidechains for Bitcoin and have been described by some as the “altcoin killer,” under the assumption that Bitcoin with sidechains would encourage experimentation to be linked to Bitcoin as opposed to folks launching competing networks. Technically, Bitcoin already has federated sidechains being developed, such as the Liquid Network and Rootstock.
There are even upgrades that are absolutely essential if Bitcoin is to keep operating, such as addressing the issue with how block timestamps are stored, which likely requires a hard fork to rectify. Left unchecked, this would see the network completely stop producing new blocks at a height of 5,101,541 (though, admittedly, this is over 80 years away.)
Bitcoin culture tends to shun hard forks, but the very question of whether or not Bitcoin has hard forked in the past is a tricky one. I’d argue that it is, in fact, possible to (very carefully and conservatively) make hard-forking changes to Bitcoin that still preserve its inviolable properties.
Even if this inevitable problem didn’t exist, one fundamental truth stays the same: unmaintained code rots. It’s time to ask some pretty important questions about what is really happening here, what it means for Bitcoin’s future, and whether there is anything to be done about it.
The Risks of Ossification
Bitcoiners should take a hard look at the risks that come with letting Bitcoin ossify. Think about the block timestamp bug that won’t be a problem for 80 years. If it isn’t addressed in some way before the network is too ossified to change, then Bitcoin will simply stop working. The world won’t want to build the global economy on a network that is going to break at a known point in time. While this problem is slightly rhetorical — as a solution will almost certainly be found — it also clearly can’t be ignored forever.
To really drive that point home, remember, ossification is a side effect of growth, not an explicit decision unto itself. There is no way to really know when we’ve gone too far until newly proposed changes simply cease to gain any traction. Now, the real problems of ossification become clear: once we cross an invisible line in the future, Bitcoin will be “set” as it is, with no more updates practically possible.
Before this happens, developers and users need to think about what Bitcoin’s ultimate code base should look like. We can see from past debates surrounding things like the SegWit fork that bitcoiners are both divided and passionate about many issues, and there’s almost certainly no answer to this question that everyone will agree on. This is, of course, part of the problem driving ossification in the first place.
What could go wrong with an ossified protocol? I keep coming back to the history of SMTP - the protocol used for email. As I wrote extensively in this post, the protocol itself essentially ossified in the 1990s before email was 20 years old. What followed was a series of small but compounding changes that occurred outside of the protocol, creating greater and greater amounts of centralization in the network.
The point is as follows: if a protocol is ossified and new problems arise, the solutions can not be applied at the protocol layer. This opens the door to more dangerous solutions being implemented outside of the protocol, essentially creating an unwritten set of protocol rules that can effectively render the original protocol unusable.
Is it Too Late?
This brings us to the obvious question: is Bitcoin already ossified? Hopefully not, but let’s entertain the notion. The fact that there has been so much divisiveness around what is best for global adoption, or what “Satoshi’s vision” truly was, could make for a pretty effective case that we are already past the event horizon on this one. That’s apparently the view of blockchain developer David Vorick and many others across Crypto Twitter. This philosophy assumes there are already too many different voices and existing interconnected applications for Bitcoin to change significantly.
Is this view fair? On the one hand, the Taproot update was successfully deployed in late 2021, which wasn’t very long ago. Surely we didn’t just ossify in the last 18 months? I’d note that protocol developers resorted to using a slightly controversial update process known as “Speedy Trial,” with debate over the most minuscule of activation parameter options, showing that they were still a bit shell-shocked from the contentious SegWit fork in 2017. Along a similar vein, I’ve noticed a pattern that protocol developers who are making Bitcoin Improvement Proposals are often stating that they are not proposing activation parameters - once again showing a reluctance to trigger controversy.
The discussion is ongoing. There isn’t an obvious answer as to whether Bitcoin already is, or when it should be ossified. Only one thing is certain in my mind: if we stop trying to improve Bitcoin, it will most certainly ossify.
Despite this conundrum, decisions do need to be made. In effect, every possible choice evokes a “fear of the unknown” in the community, but ignoring the issue and doing nothing definitely does not protect us from the unknown. Changes always come with risks, but the inability to evolve to address problems is also fraught with danger. Considering that the Bitcoin network is worth hundreds of billions of dollars, this is no time to act like a deer in headlights.
Bitcoin Development is Far from Finished
The important thing to do now is to keep moving, keep experimenting, and keep talking. It was heartening to see the “Bitcoin Inquisition” project launch recently, with the explicit goal of exploring different ways to activate protocol changes.
For example, while it would require another fork and likely another round of argument, implementing Drivechains or Validity Rollups would not only improve overall network speed and capacity but would also allow developers to test out various solutions in a way that keeps the underlying base layer safe. This should massively speed up development time and thus fight against the looming ossification threat.
Similarly, a protocol change that enables channel factories would greatly boost Bitcoin’s scalability as it would allow many people who share a Lightning Network channel, further reducing fees for those users and increasing the throughput at which we could onboard people to Lightning.
Alternatively, developers could upgrade Bitcoin to support specific features at the consensus level. By enabling more complex features in the base protocol, higher-level applications wouldn’t need to have the same level of complexity to achieve the desired functionality. A great example here would be vaults, which are technically possible with today’s protocol, but are quite brittle, unwieldy, and not user or developer friendly.
I believe the debate over ossification is only beginning. Hopefully, those who care enough to participate in protocol discussions will see that there are still plenty of paths forward for which the risks of making certain protocol changes are greatly outweighed by the potential rewards.
