The Mystery of Consensus: Understanding the Progress of the Bitcoin Upgrade Community in One Article
Preface
The topic of the next Bitcoin upgrade has been a constant discussion, yet as of now (DEC-2024), the community has not reached a consensus on whether to upgrade, the issues that need to be addressed, or the features that should be included. Essentially, it resembles a political stalemate.
In this deadlock, many interesting phenomena have emerged:
- Some community members actively promote the upgrade, often due to information asymmetry or commercial interests, with certain members frequently mentioning specific opcodes, and some projects relying on "potential" opcodes.
- A significant number of pragmatic ecosystem developers have done extensive cryptographic and engineering work based on the premise of not upgrading the protocol, to expand Bitcoin's potential.
- There are also many voices advocating for slow upgrades or opposing upgrades altogether.
These phenomena indicate that the topic of upgrades is quite popular in the Bitcoin community, but they also reflect that a considerable portion of community members do not fully understand the complete process of a Bitcoin upgrade and lack awareness of the role that innovative cryptographic tools play in unlocking Bitcoin's potential. The core purpose of this article is to break this information asymmetry, bringing everyone's knowledge to the same level, thereby facilitating deeper discussions.
This article will define Bitcoin upgrades, summarize certain patterns by tracing history, analyze current upgrade proposals and potential alternatives, and finally provide readers with several takeaways. The intention is to present this information so that readers can grasp the concepts, history, and progress of Bitcoin upgrades, laying the groundwork for further discussions on the topic and paving the way for the eventual formation of community consensus.
This article strives to present facts, while the author, as a Bitcoin ecosystem developer, hopes for more possibilities for Bitcoin; therefore, the author will express clear opinions on certain topics, and readers are advised to discern these.
Upgrade Overview: What and Why
What is a Bitcoin Upgrade
The Bitcoin whitepaper defines a protocol composed of thousands of nodes that follow the Bitcoin protocol, forming the Bitcoin blockchain network.
There are many versions of the protocol implementation (commonly referred to as clients). According to the data source from https://bitnodes.io/nodes/, the client with the largest market share is Bitcoin Core, thus the code maintainers of Bitcoin Core (hereinafter referred to as Bitcoin-Core-Devs) hold significant influence in the Bitcoin ecosystem. what-why-1 what-why-1
Bitcoin node software consists of multiple modules, and relevant upgrade proposals for Bitcoin are defined by BIP (Bitcoin Improvement Proposal), with several classifications made for BIPs.
Typically, when people discuss Bitcoin upgrades, they generally refer to "consensus protocol upgrades." This is because consensus protocol upgrades require a consensus among the majority of nodes in the network (otherwise, it could lead to a fork), thus requiring special caution. As shown in the figure below, the modules related to the consensus protocol in the Bitcoin system and the BIPs related to the consensus layer are particularly noteworthy. what-why-2 what-why-2
In fact, according to the statistics from the Bitcoin GitHub repository, modifications are very active, and since most changes are unrelated to the consensus protocol, they have not garnered widespread attention. Bitcoin-core-github-stats Bitcoin-core-github-stats
Types of Consensus Protocol Upgrades
According to the definition in BIP-123, consensus protocol upgrades are mainly divided into soft forks and hard forks.
Additionally, there is a less intuitive way to interpret and compare them, which is quite interesting:
Soft fork: Adding/strengthening rules (imagine adding a new feature, such as supporting taproot addresses)
Hard fork: Removing/loosening rules (imagine removing a restriction, such as lifting the limit on block rewards)
BIP and Soft Fork Process
The first two successful consensus protocol upgrades (Taproot/SegWit) used the soft fork method, allowing upgrades without causing significant community splits. This article focuses on soft forks, which upgrade while remaining compatible with older software versions.
After a BIP proposal is submitted, the process generally follows the flow shown in the diagram below: bip-state bip-state
Source: https://river.com/learn/what-is-a-bitcoin-improvement-proposal-bip/
Typically, a soft fork proposal will aggregate multiple BIPs; for example, taproot includes three BIPs:
Looking back at the timeline of the Taproot upgrade: Taproot-timeline Taproot-timeline
Source: Kraken Intelligence, GitHub, CoinDesk, https://www.argoblockchain.com/articles/bitcoin-taproot-upgrade-explained
The milestones in the Taproot soft fork phase include:
- The corresponding BIP is proposed, and the implementation plan is reviewed.
- Bitcoin-Core code maintainers initiate a GitHub pull request for the upgrade.
- Bitcoin-Core code maintainers review and merge the GitHub pull request, deciding on the activation method.
- A new version of the Bitcoin-Core code is released.
- Miners vote on-chain to approve the activation block height of the BIP.
- When the block height reaches the agreed height, the upgrade is completed.
It is important to note that this process is a retrospective summary, and there is no formal consensus on these milestones.
Throughout this process, the Bitcoin Development Mailing List has played a key role in consolidating consensus among various parties.
Why Upgrade
As mentioned at the beginning of the article, there are mainly three types of voices in the community regarding upgrades:
- The proactive faction: They have proposed a large number of suggestions, which will be analyzed below.
- The pragmatic builders: Based on the existing protocol, they have implemented Fraud Proof (BitVM and its extensions), function encryption (contracts and zk proofs implemented through Bitcoin PIPEs), and hash collisions (contracts implemented through ColliderScript).
- The maintain-the-status-quo faction: They believe that upgrades should be very slow and steady (with a 10-year cycle) like TeamSlowAndSteady, and that upgrades should not occur unless there is a quantum attack, like the Ossifiers (reference).
The author has conducted a pros and cons analysis of updates versus non-updates:
As a pragmatic Bitcoin ecosystem developer, the author believes that it is essential to fully explore Bitcoin's potential through cryptographic or engineering innovations within the existing protocol framework. Additionally, from the perspectives of sustainability and adaptability, it is advisable to continue upgrading as needed, after thoroughly assessing the impact and security risks.
In-Depth Upgrade
Stakeholders in Upgrades
The Hong Kong Consensus in Bitcoin's history (signed at the Bitcoin Roundtable event in February 2016, reference) involved the main participants:
- Bitcoin-Core-Devs
- Mining pools
- Users and ecosystem developers (mainly exchanges/chip manufacturers, etc.)
With the rapid increase in Bitcoin adoption, the stakeholders in Bitcoin upgrades have evolved from the initially simple tripartite division into a more complex landscape, resembling a battle of kings, as referenced in the report Analyzing Bitcoin Consensus: Risks in Protocol Upgrades. stakeholders stakeholders
Several roles here are worth highlighting:
- Economic Nodes: Mainly referring to mainstream CEX exchanges/payment institutions/custodians, their attitudes towards soft forks determine what constitutes legitimate Bitcoin and significantly impact adoption rates.
- Investors: In the context of the global prevalence of Bitcoin strategies (EFT/institutional reserves/national reserves, etc.), the role of investors has become more complex.
- User & Ecosystem Developer: After the Taproot upgrade, the Bitcoin ecosystem has flourished, leading to the emergence of asset protocols like Ordinals and a large number of native applications/scaling protocols.
Some interesting conclusions about these roles include:
- Different stakeholders play different roles at different stages: for example, Ecosystem Developers are quite proactive regarding proposals, Protocol Developers frequently exercise review authority over BIPs, and mining pools and economic nodes have significant influence over activations.
- Different Ecosystem Developers tend to propose and support proposals related to their commercial interests.
History and Summary of Upgrades
According to publicly available information, multiple soft fork upgrades have occurred since the launch of the Bitcoin network. soft forks soft forks
Data sources:
https://blog.bitmex.com/a-complete-history-of-bitcoins-consensus-forks-2022-update/
https://www.drivechain.info/media/slides/mit-2023.pdf
From the above figure, some interesting conclusions can be drawn:
- The Bitcoin protocol has shown signs of rigidity, with the frequency of soft forks decreasing over time.
- The time required to reach consensus for upgrades is increasing.
Focus Areas for Soft Forks
By analyzing the BIPs included in past soft forks, the following focus areas can be summarized:
What Constitutes a Good Upgrade Proposal
Based on the various facts and analyses presented earlier, we attempt to define a good upgrade proposal:
- Adhere to Bitcoin's core positioning as a payment system: Bitcoin has a unique positioning.
- Achieve an elegant balance between application potential and associated risks: making it appealing to most people, with no strong opposition.
- Appropriate scale of the upgrade: it should not be too simple (not worth the effort) nor too complex (difficult to promote).
- Reasonable timing: there needs to be a strong demand to solve specific problems. For example, during the SegWit upgrade phase, scalability was a strong demand.
Outlook on Upgrades
Proposal Classification
The author has collected most of the active proposals and attempted to label them with focus areas while placing them into quadrants for easier visual understanding by readers.
Points to note regarding the classification:
- The four focus areas are not completely isolated; for example, BIPs that enhance programmability may also contribute to scalability to some extent.
- A proposal may have multiple focus areas; for instance, OP_CAT itself enhances programmability, but it is more widely promoted because it aids in achieving validity rollup.
- The focus areas of a proposal require some form of "consensus" (which is inherently political); it is important to note that there is no single definition, as different participants may have different perspectives.
- The second diagram is not a coordinate system; it categorizes based on labels, and the attributes of the circles (size/position/color, etc.) do not carry special significance.
proposal category-2 proposal category-2 proposal category-1 proposal category-1
Community Voices
From the above figure, it can be seen that there is a certain consensus in the community regarding the issues that upgrades need to address, which can be categorized into the following two major areas:
- Programmability: Enhancing the programming capabilities of UTXOs, such as covenant/vault/transaction introspection/conditional payments/script enhancements, etc.
- Scalability: For L2 scalability, the overall solutions are divided into on-chain verification and off-chain verification, both of which have some actively promoted proposals.
The Mystery of Consensus
The author believes that the Bitcoin community is trapped in a maze of consensus regarding the next upgrade for the following reasons:
- Rigidity: With a software system close to $2T FDV, a significant portion of stakeholders tends to favor stability, with no party willing to bear the responsibility for accidents.
- Highly differentiated stakeholders: Different stakeholders have different demands, and their roles vary at different stages; governments have also become stakeholders.
- Inadequate governance mechanisms: As one of the earliest blockchains, Bitcoin lacks a well-developed governance mechanism; the community cannot reach a consensus on the activation methods for soft forks.
- The role of Protocol Developers is dynamically changing: Even if they do veto some proposals, they cannot simply be categorized as conservative or progressive.
- Lack of urgency: The development of blockchain infrastructure is becoming increasingly mature, leading to a lack of strong demand for Bitcoin upgrades.
Conclusion & Takeaway
This article introduces the basic concepts of Bitcoin upgrades, conducts an in-depth analysis of historical upgrades, and finally looks forward to the active proposals for the next upgrade, summarizing the reasons for the current consensus mystery.
After reviewing and looking ahead, it is believed that readers now have a certain understanding of the current state of upgrades, and the following takeaways are summarized.
- Pragmatic construction while steadily advancing upgrades; soft forks are preferable.
- Highly differentiated stakeholder interests lead the community to lean towards conservatism.
- Upgrades must be discussed while adhering to Bitcoin's core value positioning.
- Scalability is only one of the focus areas for upgrades.
- A better timing is needed; good upgrade proposals will quickly gain consensus.
- The community needs to explore better governance mechanisms.
Acknowledgments
During the research/writing/review process of this article, I received a lot of help, including from community members who preferred not to be named for various reasons, and I would like to thank them all here.
It is worth noting: Considering that some viewpoints in the article carry personal preferences, the following acknowledgment list does not represent their complete agreement with the content of the article, and this article also does not intend to involve these enthusiastic community members in any disputes.
- Co-editors and reviewers (in alphabetical order)
- Provided feedback and assistance (in alphabetical order)
Future Work
Throughout this process, the author has identified many issues worth exploring in depth, such as solutions for certain functionalities, research on specific proposals, and data support for certain viewpoints. The author will elaborate on these in subsequent articles.
References
https://bitcoinops.org/
https://opnext.dev/
https://groups.google.com/g/bitcoindev
https://github.com/TABConf/6.tabconf.com
https://petertodd.org/2024/covenant-dependent-layer-2-review
https://blog.bitmex.com/a-complete-history-of-bitcoins-consensus-forks-2022-update/
https://blog.bitmex.com/bitcoins-consensus-forks/
https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki
https://river.com/learn/what-is-a-bitcoin-improvement-proposal-bip/
https://bitnodes.io/nodes/
https://github.com/bitcoin/bitcoin/pulse/monthly
https://river.com/learn/what-is-a-bitcoin-improvement-proposal-bip/
https://trustmachines.co/learn/bitcoin-taproot-upgrade-basic-breakdown/
https://www.argoblockchain.com/articles/bitcoin-taproot-upgrade-explained
https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff
https://github.com/bitcoin-cap/bcap
https://newsletter.blockspacemedia.com/p/four-takeaways-from-op-next
https://blog.bitfinex.com/education/is-ossification-good-or-bad-for-bitcoin/
https://arxiv.org/abs/2305.04079
https://www.allocin.it/uploads/placeholder-bitcoin.pdf
https://eprint.iacr.org/2024/1802
https://en.bitcoin.it/wiki/Covenants_support