The Consensus Conundrum

By Finance News On Nov 15, 2024

A lot of consensus-change proposals for bitcoin are on the table at the moment. All of them have good motivations, whether it’s scaling UTXO ownership or making self-custody more tractable. I won’t rehash them here, you’re probably already familiar. Some have been actively developed for years.

The past two such changes that have been made to bitcoin successfully, Segwit and Taproot, were massive engine-lift-style deployments fraught with drama. There have been smaller changes in bitcoin’s past, like the introduction of locktimes, but for some reason the last two have been kitchen sink affairs.

The reality not often talked about by many bitcoin engineers is that up until Taproot, bitcoin’s consensus development was more or less operating under a benevolent dictatorship model. Project leadership went from Satoshi to Gavin to… well, I’ll stop naming names.

Core developers will likely quibble with this characterization, but we all know deep down that to a first order approximation that it’s basically true. The “final say” and big ideas were implicitly signed off on by one guy, or maybe a small oligarchy of wizened autists.

In many ways there’s really nothing wrong with this – most (all?) major open source projects operate similarly with pretty clear leadership structures. Oftentimes they have benevolent dictators who just “make the call” in times of high-dimensional ambiguity. Everyone knows Guido and Linus and the based Christian sqlite guy.

Bitcoin is aesthetically loath to this but the reality, whether we like it or not, is that this is how it worked up until about 2021.

Given that, there are three factors that create the CONSENSUS CONUNDRUM facing bitcoin right now:

(1) The old benevolent dictators (or high-caste oligarchy) have abdicated their power, leaving a vacuum that shifts the project from “conventional mode of operation” to “novel, never-before-tried” mode: an attempt at some kind of supposedly meritocratic leaderlessness.

This change is coupled with the fact that

(2) the possible design space for improvements and things to care about in bitcoin is wide open at this point. Do you want vaults? Or more L2s? What about rollups? Or how about a generic computational tool like CAT? Or should we bundle the generic things with applications (CTV + VAULT) to make sure they really work?

The problem is that all of these are valid opinions. They all have merit, both in terms of what to focus on and how to get to the end goal. There really isn’t a clear “correct” design pattern.

(3) A final factor that makes this situation poisonous is that faithfully pursuing, fleshing out, building, “doing the work” of presenting a proposal IS REALLY REALLY TIME CONSUMPTIVE AND MIND MELTING.

Getting the demos, specs, implementation, and “marketing” material together is a long grind that takes years of experience with Core to even approach.

I was well paid to do this fulltime for years, and the process left me disgusted with the…