Currently, various consensus change proposals for Bitcoin are under consideration, each motivated by different goals, such as enhancing UTXO (Unspent Transaction Output) ownership and simplifying self-management systems. While I won’t delve into the specifics again, many of these proposals have been in development for several years.
The previous significant changes to Bitcoin—Segregated Witness (SegWit) and Taproot—were major endeavors that stirred up considerable discussions and challenges. In the past, Bitcoin experienced minor adjustments, like the addition of locktime, but those recent changes emerged as complex issues requiring extensive effort.
It’s often unspoken among Bitcoin engineers that before Taproot, the development of Bitcoin’s consensus functioned under a somewhat benevolent dictatorship. Leadership has shifted from Satoshi to other figures in the Bitcoin community, but I’ll refrain from naming anyone specific.
Core developers may contest this viewpoint, yet deep down, many recognize that there was a reality where a singular leader, or a small group, held significant influence over critical decisions.
This structure isn’t inherently problematic. Most notable open-source projects exhibit similar dynamics, often guided by recognized leaders. Figures like Guido van Rossum or Linus Torvalds come to mind, representing a trend wherein specific individuals steer the project direction.
Despite Bitcoin’s philosophical objection to such structures, it functioned under this model until around 2021, whether we approve of it or not.
Given this context, three main factors contribute to the consensus challenges Bitcoin currently faces:
(1) A longstanding benevolent leader (or a small oligarchy) has stepped down, leaving a gap in leadership, which has led to a trial of a new, untested approach, suggesting a meritocratic environment.
This transition relates to a crucial observation:
(2) There’s now a vast range of possibilities for Bitcoin’s design and enhancement. Options like Layer 2 solutions, roll-ups, or general-purpose calculation tools like CAT are now up for discussion. Should we couple something generic with an application (like CTV + VAULT) to ensure functionality?
All these perspectives hold merit, offering benefits in terms of focus areas and achieving goals. Ultimately, there’s no unequivocally “right” design approach.
(3) Lastly, the task of properly developing, detailing, and executing a consensus proposal can be an immensely time-consuming and challenging process.
Creating prototypes, writing specifications, coding implementations, and producing marketing materials is a lengthy endeavor that typically calls for extensive experience with the Bitcoin Core codebase.
I’ve spent years engaged in this work and was compensated well, yet I eventually became fatigued by the ongoing dysfunction and lost motivation to contribute. I suspect this sentiment is widespread.
Another misconception is the expectation that companies will similarly contribute to the process. The notion that businesses can establish themselves based on anticipated forks is somewhat naive. Most Bitcoin-related companies already face significant challenges and are primarily focused on survival, leaving little room for research and development efforts. Integrating new functionalities alone takes substantial time.
Many R&D budgets belong to companies more interested in producing alternative cryptocurrencies rather than enhancing Bitcoin-specific features.
While I have collaborated with several Bitcoin-focused companies with adequate funds for research and development, I still believe much of these resources are tied up in speculative soft forks that may not ever come to fruition. It’s insufficient to create full-fledged product demonstrations based merely on these concepts.
—
This scenario illustrates why human systems often establish leadership hierarchies. To progress in a situation like this, it’s typically necessary for someone to step forward and declare, “After thorough consideration, we’re going to execute X.”
However, this appears complex due to Bitcoin’s foundational philosophy, which rightly suggests that a distinct leadership hierarchy could lead to undesirable affiliations, especially with centralized authorities like the Federal Reserve.
Indeed, it’s likely that Bitcoin will reach a point where significant changes (known as “ossified”) will no longer occur. Yet for now, we must rely on various financial services that necessitate engaging with larger institutions.
For Bitcoin to continue evolving and incorporating more sophisticated features, there is a need for stricter regulations. Nevertheless, endorsing a “slow and steady” approach presents its own set of challenges.
Additionally, as Bitcoin’s value escalates and nations start acquiring it in bulk, altering its rules will become more complicated. Thus, indecision—essentially choosing to do nothing—embodies a significant choice in itself.
Finding a resolution to this dilemma is unclear.
—
Another uncomfortable aspect that needs addressing relates to the locus of power.
The current model for modifying Bitcoin hinges on the decisions made by core developers regarding code merges. Although there isn’t an official stance on this, it reflects a practical reality.
Less tech-savvy participants, such as miners and exchanges, must determine which indicators signify that changes are prudent and when adjustments are being made. Unfortunately, they usually lack the expertise or inclination to evaluate these changes independently.
My colleagues in Core would likely contest this depiction, asserting, “We are merely custodians!” and emphasize their role in merging proposals that have garnered consensus. Their intentions are generally sincere, but they can overlook how consensus evolution has historically functioned.
This is something that, on some level, everyone intuitively realizes but hesitates to acknowledge.
Ultimately, it is imperative for a core developer to provide a warm “yes” and facilitate a merge. Up until now, none have paid much attention to the discussions surrounding soft forks—an understandable choice given the vast responsibilities facing Bitcoin.
However, we must be candid: Much of what is being undertaken by Core feels secondary to the core realization of Bitcoin.
While mempool improvements are noteworthy, they hinge upon the principle of altruism, which challenges the established model. The emergence of profit-driven dark pools and accelerators seems inevitable, though this may be open to debate. Much of the mempool work is inherently tied to Lightning support, which, unfortunately, doesn’t adequately resolve scalability challenges.
Though encrypted P2P connections are valuable, on-chain ownership necessitates engagement with exchanges, ecash mints, sidechains, or other trusted intermediaries to be genuinely effective. Without that access, what’s the ultimate benefit?
My primary concern is that Core, rather than confronting pressing challenges, may have developed a kind of detached mindset that undermines those who invest in long-term agreements.
This could hinder Bitcoin from achieving its full potential.
—
I’m unsure what the solution could be. It’s clear that managing self-custody can feel overwhelming and is nearly unattainable for average users. Moreover, Bitcoin’s current structure significantly impacts a considerable segment of the U.S. population, let alone globally.
I also recognize that the existing framework may not be able to accommodate increasing transaction volumes as demands rise.
Individuals who fail to acknowledge this reality and choose to devote their essential time and energy trapped in theoretical discussions about perfecting innovations for CTV are making a critical decision.
Most well-developed, fully specified fork proposals that exist are fundamentally sound and could enhance Bitcoin’s ecosystem.
Considering new features like compactblock, assignutxo, and eventually utreexo, it seems feasible to contemplate increasing the block size, though that discussion can wait for another day.
—
I’ve hesitated to write pieces like this, lacking a definitive prescription or advice. Perhaps by raising these uncomfortable truths, we may pave the way for broader acceptance of self-custody options.
Many of these perspectives echo what @JeremyRubin has articulated on his blog years ago. I’m tired of holding back.
I appreciate the feedback from @rot13maxi and @MsHodl on this draft.
This article is a guest contribution by James O’Beirne. The views expressed are solely his own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
