There are a lot of agreed-upon change proposals for Bitcoin on the table right now. They all have good motives, whether it’s expanding UTXO ownership or making self-control easier. I won’t repeat it here, you’re probably already familiar. Some of them have been actively developed for years.
The last two changes to Bitcoin that were successfully made, Segwit and Taproot, were massive leverage-style deployments fraught with drama. There have been smaller changes in Bitcoin’s past, such as the introduction of lock times, but for some reason the last two changes have been kitchen sink affairs.
The fact that many Bitcoin engineers don’t talk about much is that until Taproot, Bitcoin’s consensus development more or less operated under a benevolent dictatorship model. Project leadership moved from Satoshi to Gavin to… well, I’ll stop naming names.
Core developers would likely object to this characterization, but we all know deep down that this is fundamentally true. The “final word” and big ideas are implicitly signed off on by one person, or perhaps a small group of autistic people.
In many respects, there’s nothing wrong with this – most (all?) major open source projects work similarly with very clear leadership structures. Often, they have benevolent dictators who “call the shots” in times of high-dimensional uncertainty. Everyone knows Guido, Linus, and the Christian resident of Skelete.
Bitcoin hates this aesthetically, but the reality, whether we like it or not, is that this is the way things have continued until roughly 2021.
Given this, there are three factors that create the consensus puzzle facing Bitcoin currently:
(1) The old benevolent tyrants (or upper-class oligarchs) have given up their power, leaving a vacuum that transforms the enterprise from a “traditional mode of operation” to a “new and never-before-tried” mode: an attempt at some kind of business. From the lack of leadership assumed on the basis of merit.
This change is coupled with the fact that
(2) The possible design space for improvements and things to take care of in Bitcoin is wide open at this point. Do you want lockers? Or more L2s? What about assemblies? Or what about a general calculation tool like CAT? Or should we bundle the generic stuff with the apps (CTV + VAULT) to make sure it really works?
The problem is that all of these opinions are correct. They all have an advantage, both in terms of what to focus on and how to reach the end goal. There’s really no clear “correct” design style.
(3) The final factor that makes this situation toxic is that sincerely following through, fleshing out, building, and “doing the work” of presenting the suggestion is truly time-consuming and mind-melting.
Putting together demos, specifications, implementation, and “marketing” materials is a long process that takes years of experience with Core to even get close to.
I’d been paid well to do this full-time for years, and the process left me disgusted with the dysfunction and little desire to continue contributing. I think this is a common feeling.
There is a related myth that companies will do something similar to help in this process. The idea that companies will build on potential forks is laughable. Most Bitcoin companies have a lot of backlogs, are struggling to survive, and do not have anyone dedicated to R&D. They’ve had enough difficulty integrating features that actually make it exist.
Many people with an R&D budget are crypto factories who don’t care about Bitcoin-specific upgrades.
I’ve worked with some rare companies that are interested in Bitcoin and have the funds for this kind of R&D, and even then the resources are not enough to create a serious demo of the product plus 1 speculative software fork that may never happen.
—
This type of situation is why human systems have evolved leadership hierarchies. Generally, to come forward in a situation like this, someone has to be in a position to say “Okay, after due consideration, we’ll do X.”
Of course what makes this seem so intractable is that Bitcoin mythology (rightly) dictates that a clear hierarchy of leadership is how you end up, within its confines, at the Fed.
Of course, Bitcoin cannot change again in any meaningful way (“fossilization”). But at this point it is almost certainly surrendering to another financial product that is only accessible to a large institution.
If you agree that Bitcoin will probably continue to tighten its rules to get more and better functionality, but we should go “slow and steady”, then I think there are problems with that as well.
Because another factor that hasn’t been talked about is that as the price of Bitcoin rises, and as nation states start buying in volume, it will be difficult to change the rules. So inaction – failure to make a decision – is actually a very important decision.
I don’t know how to solve this.
—
There’s another uncomfortable topic I want to touch on: where the power actually lies.
The current mechanism for changing Bitcoin depends on what the core developers will integrate. This is of course not official policy, but it is the unintended reality.
Other less technically experienced actors (such as miners and exchanges) have to choose some indicators to pay attention to that tell them what changes are safe and when they will come. They have little ability or interest to determine the extent of these things for themselves, or to undertake the development necessary to discover them.
My core colleagues will bristle at this characterization. They’ll say, “We’re just cleaners!” We only incorporate what is unanimous! They are not disingenuous in saying that. But they also don’t acknowledge that historically, and that’s how consensus changes work.
This is something everyone semi-consciously knows but doesn’t really want to have.
The core developers saying “yes” and clicking on the merge was a necessary introduction every time. At the moment, none of the core developers are interested in soft fork talks – which is somewhat understandable, as there is a lot to do in Bitcoin.
But let’s be honest here, a lot of the work happening at Core was kind of secondary to the realization of Bitcoin.
Mempool’s work is interesting, but the whole model is somewhat upside down because it’s based on altruism. Dark pools and for-profit accelerators seem inevitable to me, although that can be argued. Much of the mempool’s operation relies on Lightning support, which obviously won’t solve the scaling problem.
Sure, encrypted P2P communications are great, but what’s the point even if we can’t get on-chain ownership to a level beyond the basic need to use an exchange, 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 scoffs at people who fiddle with agreed-upon things over the long term rather than actually trying to deal with difficult problems.
This could leave Bitcoin falling short of its potential.
—
I don’t know what the solution is to any of this. I know that self-custodialism is completely unnerving and basically unthinkable for average users, and I know that Bitcoin in its current form will never reach twice-monthly trading volume in even 10% of the US, let alone most of it. the world.
People who don’t admit it, who want to spend critical time and energy wallowing in the morass of CTV’s perfect remix proposal, are making a fateful choice.
Most of the fully specified fork proposals active today are perfectly fine, and in theory would be great additions to Bitcoin.
Hell, a larger block size would probably be safe given features like compressed blocks, sumutxo, and eventually utreexo. But that’s another post for another day.
—
I’ve gone back and forth on writing a post like this, because I don’t have any specific recipes or recommendations. I guess I can only hope that the provocation of these uncomfortable remarks will be a distant prelude to progress in expanding the scope of self-policing.
All these opinions may have been expressed by @Jeremy Rubin Years ago on his blog. I’m just tired of biting my tongue.
Thanks for @rot13maxi and @MsHodl To get feedback on drafts of this.
This is a guest post by James O’Byrne. The opinions expressed are entirely their own and do not necessarily reflect the opinions of BTC Inc or Bitcoin Magazine.
Comments are closed, but trackbacks and pingbacks are open.