There are many consensus amendment proposals for Bitcoin on the table right now. They all have good motivations, whether it’s scaling UTXO ownership or making self-control more manageable. I won’t repeat them here, you probably already know them. Some have been actively developed for years.
The past two such changes successfully made to bitcoin, Segwit and Taproot, were massive engine-lift style implementations full of drama. There have been smaller changes in bitcoin’s past, such as the introduction of locktimes, but for some reason the last two were kitchen sink cases.
The reality that many Bitcoin engineers don’t often talk about is that Bitcoin’s consensus development up until Taproot more or less operated under a benevolent dictatorship model. Project leadership went from Satoshi to Gavin to… well, I’ll stop naming names.
Core developers will probably quibble over this characterization, but we all know deep down that it’s basically true. The “last word” and the big ideas were implicitly signed by one man, or perhaps by a small oligarchy of wizened autistics.
In many ways there’s actually nothing wrong with this; most (all?) major open source projects work the same way with fairly clear leadership structures. Often they have benevolent dictators who simply ‘make the call’ in times of high-dimensional ambiguity. Everyone knows Guido and Linus and the Christian sqlite man.
Bitcoin hates this aesthetically, but the reality, whether we like it or not, is that this is how it worked until about 2021.
Considering that there are currently three factors creating the CONSENSUS CONUNDRUM that bitcoin is facing:
(1) The old benevolent dictators (or the high caste oligarchy) have abdicated their power, creating a vacuum that shifts the project from a “conventional mode of operation” to a “new, never tried before” mode: an attempt at some kind of supposedly meritocratic leaderlessness.
This change is accompanied by the fact that
(2) the possible design space for improvements and things to worry about in bitcoin is wide open at this point. Do you want safes? Or more L2s? What about roll-ups? Or how about a generic computer tool like CAT? Or should we bundle the generic stuff 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 achieve the end goal. There isn’t really a clear “correct” design pattern.
(3) A final factor that makes this situation toxic is that faithfully pursuing, developing, building, and “doing the work” of presenting a proposal REALLY REALLY TAKES TIME AND MELTS THE MIND.
Getting the demos, specs, implementation and ‘marketing’ materials together is a long job that takes years of experience with Core to even approach.
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 contribute further. I think this is a common feeling.
A related myth is that companies will do something similar to aid the process. The idea that companies will build on future forks is pretty laughable. Most Bitcoin companies are massively behind schedule, struggling to survive, and essentially have no one dedicated to R&D. They have enough trouble integrating functions that actually make it.
Many of those who do have budgets for R&D are shitcoin factories that don’t care about bitcoin-specific upgrades.
I’ve worked for some of the rare 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 top of 1 of the N speculative soft forks that may never come . to happen.
—
These types of situations are why human systems develop leadership hierarchies. Generally speaking, to make progress in a situation like this, someone needs to be in a position to say, “Okay, after some careful thought, we’ll do X.”
What makes this seem intractable, of course, is that Bitcoin mythology (rightly) dictates that clear leadership hierarchies determine how, at the limit, you end up at the Fed.
Certainly, Bitcoin simply can never change again in a meaningful way (“ossify”). But at this point it is almost certainly left to become yet another financial product that can only be accessed with the benefit of a major institution.
If you admit that Bitcoin should probably continue to tighten its rules for more and better functionality, but that we should take it ‘slow and steady’, I think there are problems with that too.
Another factor not talked about is that as the price of Bitcoin rises and nation states start buying in volume, the rules will become harder to change. Not acting – not deciding – is therefore in fact a decision with very serious consequences.
I don’t know how this will be resolved.
—
There’s another uncomfortable topic I want to discuss: where the power actually lies.
The current mechanism for changing Bitcoin depends on what Core developers will put together. This is obviously not official policy, but it is the unintended reality.
Other, less tech-savvy actors (such as miners and exchanges) should choose an indicator to pay attention to that tells them which changes are safe and when they are coming. They have little ability or interest to judge these things for themselves, or do the development necessary to figure them out.
My Core colleagues will be angry at this characterization. They will say, “We are just janitors! we just merge what has consensus!” And they are not insincere when they say so. But they also don’t recognize that historically: that’s how consensus changes have worked.
This is something that everyone semi-consciously knows, but doesn’t really want to possess.
Core developers saying “yes” and clicking merge have been a necessary precursor every time. And right now none of the Core developers are paying attention to the soft fork conversations – somewhat understandably, there’s a lot going on in bitcoin.
But let’s be honest: a lot of the work happening in Core has been more or less secondary to the realization of bitcoin.
Mempool’s work is interesting, but the whole model is more or less turned upside down because it is based on altruism. Dark pools and for-profit accelerators seem inevitable to me, although that could be argued. A lot of the mempool work is rooted in Lightning support, which quite clearly won’t solve the scaling problem.
Sure, encrypted P2P connections are great, but what’s the point if we can’t bring on-chain ownership to a level beyond using an exchange platform, ecash mint, sidechain or any other trusted third party ?
My main complaint is that Core has developed an ivory tower mentality that more or less makes a mockery of people who pursue longer-term consensus issues rather than actually trying to deal with the hard problems.
And that could lead to bitcoin not reaching its potential.
—
I don’t know what the solution to all this is. I know that self-custody is completely nerve-wracking and effectively out of the question for regular users, and I also know that Bitcoin in its current form won’t scale to bi-monthly volume for even 10% of the US, let alone most of the US . the world.
The people who don’t recognize this, and who want to spend critical time and energy wallowing in the mud of imagining the perfect CTV remix, are making a fateful choice.
Most of the long-standing, fully specified fork proposals active today are perfectly fine, and conceptually they would be great additions to Bitcoin.
Probably a larger block size is safe, considering features like compactblocks and supposeutxo and eventually utreexo. But that’s another post for another day.
—
I’ve gone back and forth about writing a post like this because I don’t have any concrete prescriptions or recommendations. I guess I can only hope that bringing up these uncomfortable observations is a distant precursor to making progress in scaling self-control.
All these opinions were probably expressed by @JeremyRubin years ago on his blog. I’m tired of biting my tongue.
Thanks @rot13maxi And @MsHodl for feedback 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.