As I explained in A take Two weeks ago, I think the threat (or promise, depending on your perspective) of protocol ossification is somewhat exaggerated, at least at this point.
Yes, the rate of soft forks has slowed considerably over the years, the last being a taproot in 2021. But that seems to have more to do with a lack of interest in the potential upgrades that have since been proposed, rather than a lack of a good process for deploying protocol upgrades. (This isn’t exactly a solved problem, though.)
Bitcoin Core developers are usually funded on a no-strings-attached basis or directly on volunteers, meaning they are not required to work on a specific part of the codebase. Thus, their time and energy will be devoted to what they find most interesting or important to work on. So far, it’s not really one of the soft fork proposals: different covenant-style opcodes is not understood to offer the type of clearly based use cases that deserve preference, and while Drivechain Sounds great in theory, their main downside is still that miners can eventually steal coins from them.
But even if Bitcoin Core developers aren’t interested, that doesn’t mean it’s impossible to upgrade Bitcoin. For better or worse, anyone with the right skills (supposedly not very low bar) can always deploy a soft fork through an alternative client, even in the form of a user activated soft fork (UASF). Yet no one has yet done so despite rumblings from time to time.
I suspect this is at least in part because proponents of these soft forks are not convinced that a UASF would actually succeed. And if a UASF isn’t successful, maybe the upgrade isn’t worth doing in the first place…
This article is a take. The views expressed are solely those of the author and do not necessarily reflect the views of BTC Inc or Bitcoin Magazine.
