The lack of soft forks is due to a lack of interest— not a lack of process
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 in time.
Yes, the rate of soft forks has slowed down significantly over the years, the last one having been Taproot in 2021. But it seems this has more to do with a lack of interest in the potential upgrades that’ve been proposed since then, rather than it being due to the lack of a good process for deploying protocol upgrades. (Although that is not exactly a solved problem either.)
Bitcoin Core developers are generally funded on a no-strings-attached basis or outright volunteers, meaning they’re not required to work on any specific part of the codebase. As such, their time and energy will be dedicated to whatever they find most interesting or important to work on. So far, that hasn’t really been any of the soft fork proposals: the various covenant-style opcodes aren’t unequivocally perceived to offer the type of groundbreaking use cases that deserve prioritization, and while Drivechains sound great in theory, their major downside is still that miners can ultimately 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 skillset (admittedly not a very low bar) can always deploy a soft fork through an alternative client, even as a user activated soft fork (UASF). Yet, despite some rumblings from time to time, no one has done this yet.
I suspect this is at least in part because the proponents of these soft forks aren’t convinced a UASF would actually be successful. And if a UASF wouldn’t be successful, maybe the upgrade is not worth doing in the first place…
This article is a Take. Opinions expressed are entirely the author’s and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
