There are many consensus change proposals for bitcoin on the table right now. They all have good motivations, whether it’s expanding UTXO ownership or making self-custody more manageable. I won’t repeat them here, you probably already know them. Some have been actively developed for years.
The last two such changes to have been successfully made to Bitcoin, Segwit and Taproot, were massive motor-lift style implementations riddled with drama. There have been minor changes in Bitcoin’s past, such as the introduction of block times, but for some reason the last two have been kitchen affairs.
The reality that many bitcoin engineers don’t often talk about is that until Taproot, bitcoin consensus development more or less operated under a benevolent dictatorship model. Leadership of the project passed from Satoshi to Gavin and… well, I’ll stop naming names.
Core developers will probably object to this characterization, but deep down we all know that, to a first-order approximation, it’s basically true. The “last word” and big ideas were implicitly approved by one man, or perhaps by a small oligarchy of wizened autistics.
In many ways, there is nothing wrong with this: most (all?) major open source projects operate in a similar way with fairly clear leadership structures. They often have benevolent dictators who simply “call the shots” in times of major ambiguity. Everyone knows Guido and Linus and the Christian guy sqlite.
Bitcoin is aesthetically averse to this, but the reality, whether we like it or not, is that this is how it worked until about 2021.
Given that, there are three factors that create the CONSENSUS ENigma that Bitcoin faces right now:
(1) The old benevolent dictators (or the upper-caste oligarchy) have abdicated their power, leaving a vacuum that shifts the project from a “conventional mode of operation” to a “novel, never before tried” mode: a attempt at some kind of supposedly meritocratic lack of leadership.
This change is in addition to the fact that
(2) the possible design space for improvements and aspects of interest in bitcoin is wide open at the moment. Do you want vaults? Or more L2? What about the summaries? Or how about a generic computational tool like CAT? Or should we combine the generic elements with applications (CTV + VAULT) to make sure they actually work?
The problem is that these are all valid opinions. They all have merit, both in terms of what to focus on and how to get to the end goal. There really is no clear, “correct” design pattern.
(3) One last factor that makes this situation poisonous is that faithfully pursuing, developing, building, and “doing the work” of submitting a proposal REALLY IS TIME-CONSUMING AND MIND-MELTING.
Putting together the demos, specifications, implementation, and “marketing” material is a long task that requires years of experience with Core to accomplish.
I was paid well to do this full time for years, and the process left me disgusted with the dysfunction and very little desire to continue contributing. I think this is a common feeling.
A related myth is that companies will do something similar to help the process. The idea of companies relying on potential forks is pretty ridiculous. Most bitcoin companies have a huge backlog, are struggling to survive, and basically have no one dedicated to R&D. They find it quite difficult to integrate features that really succeed.
Many of those with R&D budgets are shit factories that don’t care about bitcoin-specific updates.
I’ve worked for some of the few companies that care about bitcoin and have the money for this kind of R&D, and even then the resources aren’t enough to build a serious product demo on 1 of N speculative softforks that may never happen. happen.
—
This type of situation is why human systems develop leadership hierarchies. Generally, to make progress in a situation like this, someone has to be in a position to say “okay, after due consideration, we’re doing X.”
Of course, what makes this seem intractable is that Bitcoin mythology dictates (rightly) that clear leadership hierarchies are the way to ultimately end the Federal Reserve.
Of course, bitcoin can never change significantly (“ossify”) again. But at this point that almost certainly resigns you to yet another financial product that can only be accessed with the benefit of a large institution.
If we accept that Bitcoin should probably continue to tighten its rules to achieve more and better features, but that we should go “slow and steady”, I think that has problems too.
Because another factor that isn’t talked about is that as the price of bitcoin rises and nation-states start buying in size, the rules will be harder to change. Therefore, inaction (not deciding) is actually a very important decision.
I don’t know how this is resolved.
—
There’s another uncomfortable topic I want to touch on: where power really lies.
The current mechanism for changing bitcoin depends on what the core developers will merge. Of course, this is not an official policy, but it is an unwanted reality.
Other less technically savvy players (like miners and exchanges) have to choose some indicator to pay attention to that tells them what changes are safe and when they will occur. They have little ability or interest to evaluate these things for themselves or do the development necessary to resolve them.
My Core colleagues will bristle at this characterization. They will say “we are just janitors! we simply merge what has consensus! And they are not being disingenuous in saying that. But they also do not recognize that historically this is how consensus changes have operated.
This is something that everyone semi-consciously knows but doesn’t really want to possess.
Having core developers say “yes” and clicking merge has been a necessary precursor all along. And right now none of the Core developers are paying attention to the soft fork conversations; somewhat understandable, there is a lot to do in bitcoin.
But let’s be honest, much of the work being done on Core has been secondary to making bitcoin.
Mempool’s work is interesting, but anyway the whole model is more or less upside down because it is based on altruism. For-profit darkpools and accelerators seem inevitable to me, although that could be argued. Much of the mempool work relies on Lightning support, which obviously won’t solve the scaling problem.
Sure, encrypted P2P connections are great, but what’s the point if we can’t get on-chain ownership to a level beyond essentially requiring the use of an exchange, ecash mint, sidechain, or some other trusted third party?
My main complaint is that Core has developed an ivory tower mentality that more or less mocks people who seek long-term consensus instead of trying to tackle difficult problems.
And that could cause Bitcoin to fail to reach its potential.
—
I don’t know what the solution to all this is. What I do know is that self-custody is totally stressful and basically impossible for casual users, and what I do know is that bitcoin in its current form won’t reach bi-monthly volume for even 10% of the US, and much less for the majority of the world.
People who don’t recognize this and who want to spend critical time and energy wallowing in the mud of coming up with the perfect CTV remix are making a fateful decision.
Most of the long-active and fully specified fork proposals are totally fine and would conceptually be great additions to bitcoin.
Heck, a higher block size is probably safe given features like compactblocks and assumeutxo and eventually utreexo. But that’s another post for another day.
—
I’ve been going back and forth about writing a post like this, because I have no concrete prescriptions or recommendations. I guess I can only hope that bringing up these uncomfortable observations is a distant precursor to moving forward in expanding self-custody.
All of these opinions have probably been expressed by @JeremyRubin years ago on his blog. I’m just tired of biting my tongue.
Thanks to @rot13maxi and @MsHodl for comments on drafts of this.
This is a guest post by James O’Beirne. The opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
