Introduction
The topic of Bitcoin's next upgrade has been incessant, but as of now (DEC-2024), the community has not reached a consensus on whether to upgrade, what issues to address in the upgrade, or the features to be brought, with essentially conflicting opinions resembling a political stalemate.
In this stalemate, many interesting phenomena have emerged:
Some community members actively promote upgrades, but due to information asymmetry or commercial interests, certain members often mention specific opcodes, and some projects rely on certain 'potentially appearing' opcodes.
A considerable number of pragmatic ecosystem developers have done extensive cryptographic and engineering work to expand Bitcoin's potential based on the premise of not upgrading the protocol.
Voices advocating for slow upgrades or opposing upgrades are also not rare.
The emergence of these phenomena indicates that the topic of upgrades is quite popular in the Bitcoin community, but it also reflects that many community members do not fully understand the complete process of a Bitcoin upgrade and lack awareness of how innovative cryptographic tools can unlock Bitcoin's potential. The core writing purpose of this article is to break this information asymmetry, putting everyone's information on the same level for deeper discussions.
This article will define Bitcoin upgrades, summarize certain patterns by reviewing history, and analyze current upgrade proposals and potential alternatives, ultimately providing readers with several takeaways. The intent is to present this information so that readers grasp the concepts, history, and progress of Bitcoin upgrades, laying the groundwork for further discussions on the topic and paving the way for the formation of a final community consensus.
This article strives to present facts, and as an ecosystem developer in Bitcoin, the author hopes for more possibilities for Bitcoin, thus expressing clear opinions on some topics; please discern carefully.
Introduction to Upgrades: What and Why
What is a Bitcoin upgrade
The Bitcoin white paper 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
Data from https://bitnodes.io/nodes/ shows that Bitcoin Core has the largest market share among clients, so the code maintainers of Bitcoin-Core (hereinafter referred to as Bitcoin-Core-Devs) have a significant influence in Bitcoin.
Bitcoin node software consists of multiple modules, and relevant upgrade proposals for Bitcoin are defined by BIPs (Bitcoin Improvement Proposals), which have been categorized in several ways.
Generally, when people discuss Bitcoin upgrades, they refer to 'consensus protocol upgrades.' Since consensus protocol upgrades require a majority of nodes in the entire network to reach a consensus (otherwise it may lead to a fork), special caution is necessary. As shown in the figure below, modules related to consensus protocols in the Bitcoin system and proposals related to the consensus layer of BIPs deserve special attention.
In reality, according to statistics from the Bitcoin GitHub repository, modifications are very active, and since most changes are not related to the consensus protocol, they have not attracted broad attention.
Types of Consensus Protocol Upgrades
According to the definition in [BIP-123](https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki), consensus protocol upgrades are mainly divided into soft forks and hard forks.
Additionally, there is a not-so-intuitive way to interpret and compare, which is also interesting:
Soft fork: adding/strengthening rules (simply imagine adding a new feature, such as supporting taproot addresses).
Hard fork: removal/reduction of rules (simply imagine removing a restriction, such as the block reward limit).
The process of BIPs and soft forks
The first two successful consensus protocol upgrades (Taproot/SegWit) used a soft fork approach, avoiding major community splits. This article focuses on soft forks, which allow upgrades while being compatible with older version software.
After the submission of BIP proposals, the process roughly follows the diagram below:
Source: https://river.com/learn/what-is-a-bitcoin-improvement-proposal-bip/
Typically, a soft fork proposal aggregates multiple BIPs; for example, Taproot includes 3 BIPs:
Schnorr Signature: BIP-340
Taproot: BIP-341
Tapscript: BIP-342
Review of the timeline for the Taproot upgrade:
Source: Kraken Intelligence, GitHub, CoinDesk, https://www.argoblockchain.com/articles/bitcoin-taproot-upgrade-explained
Milestones in the Taproot soft fork phase include:
The corresponding BIP is proposed, and the implementation plan undergoes a review.
Bitcoin-Core code maintainers initiate upgrade GitHub pull requests.
Bitcoin-Core code maintainers review and merge GitHub pull requests, deciding on activation methods.
New version of Bitcoin-Core code released.
Miners vote on the blockchain to approve the block height for BIP activation.
Block height reaches the agreed height, completing the upgrade.
It should be noted that this process is a retrospective summary, and there is no written consensus on this milestone.
Throughout the process, the Bitcoin Development Mailing List played a key role in consolidating consensus.
Why Upgrade
As mentioned at the beginning of the article, there are mainly three voices regarding upgrades in the current community:
Proponents of active promotion: have proposed a large number of proposals, which will be analyzed below.
Pragmatic builders: Implementing Fraud Proof (BitVM and its extensions), function encryption (contracts and zk proofs achieved through Bitcoin PIPEs), and hash collisions (contracts achieved through ColliderScript), etc.
Maintainers: They believe upgrades should be very slow and steady (with a 10-year cycle) TeamSlowAndSteady, and those who oppose upgrades unless a quantum attack occurs (ossifiers).
The author conducted a pros and cons analysis of updates and no updates:
As a pragmatic Bitcoin ecosystem developer, the author believes it is essential to fully explore Bitcoin's potential through cryptographic or engineering innovations within the existing protocol framework, while also considering sustainability and adaptability. Continuous upgrades, based on a thorough assessment of impact scope and security risks, are desirable.
In-depth Upgrades
Stakeholders of the Upgrade
The Hong Kong Consensus in Bitcoin history (signed at the Bitcoin Roundtable event in February 2016, for reference) mainly involved the following parties:
Bitcoin-Core-Devs
Mining Pools
Users and ecosystem developers (mainly exchanges/chip manufacturers, etc.)
With the rapid increase in Bitcoin adoption, stakeholders in Bitcoin upgrades have gradually evolved from the initially simple tripartite structure into a competitive scenario, as referenced in the report 'Analyzing Bitcoin Consensus: Risks in Protocol Upgrades.'
Several roles here are worth highlighting:
Economic Nodes: Mainly refer to mainstream CEX exchanges/payment institutions/custodians, their attitudes towards soft forks determine what is considered legitimate Bitcoin and have significant influence on adoption rates.
Investors: Against the backdrop of widespread 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, with the emergence of asset protocols like Ordinals, as well as a large number of native applications and scaling protocols.
For these roles, there are some interesting conclusions:
Different stakeholders play different roles at different stages; for example, ecosystem developers show considerable enthusiasm for proposals, protocol developers often exercise review authority over BIPs, and mining pools and economic nodes have significant influence on activation.
Different ecosystem developers tend to propose and support proposals related to their commercial interests.
History and Summary of Upgrades
Publicly available information shows that multiple soft fork upgrades have occurred since the launch of the Bitcoin network.
Data Sources:
https://blog.bitmex.com/a-complete-history-of-bitcoins-consensus-forks-2022-update/
https://www.drivechain.info/media/slides/mit-2023.pdf
Some interesting conclusions can be drawn from the above diagram:
The Bitcoin protocol has shown some rigidity, and over time, the frequency of soft forks has decreased.
The time required to reach consensus on upgrades has been increasing.
Soft Fork Areas of Concern
Analyzing past soft forks containing BIPs, the following areas of concern can be summarized:
What constitutes a good upgrade proposal
Based on the various facts and analyses listed earlier, we attempt to define a good upgrade proposal:
Uphold 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 while not facing strong opposition.
Appropriate scale of upgrades: should not be too simple (not worth the effort) or too complex (difficult to promote).
Reasonable timing: there needs to be a strong demand to address specific issues. For example, during the SegWit upgrade phase, scalability was a strong demand.
Outlook on Upgrades
Proposal Classification
The author has collected most active proposals, labeled them with areas of concern, and placed them into quadrants for easier visualization by readers.
Note on classification:
The four areas of concern are not completely isolated; for example, BIPs that enhance programmability may also contribute to scalability to some extent.
A proposal may have multiple areas of concern; for example, OP_CAT itself enhances programmability, but it is more widely promoted because it helps achieve validity rollup.
The topic of which aspects to focus on in a proposal requires some form of 'consensus' (politics itself). It should be noted that there is no single definition here, 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 have special significance.
Community Voices
From the above diagram, it can be seen that there is a certain consensus in the community regarding the issues that need to be addressed by upgrades, which can be categorized into the following two main categories: those related to the functionalities required by the payment system.
Programmability: Enhancing the programming capabilities of UTXOs, such as covenant/vault/transaction introspection/conditional payments/script enhancements, etc.
Scalability: For L2 scaling, the overall solutions are divided into on-chain validation and off-chain validation, 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:
Stagnation: A software system with a nearly $2T FDV, a significant portion of stakeholders tend to prefer stability, with no party willing to bear the responsibility for accidents.
Highly differentiated stakeholders: Different stakeholders have different demands and play different roles at various stages; governments have also become stakeholders.
Governance mechanisms are inadequate: As the first blockchain, Bitcoin lacks a very robust governance mechanism; the community cannot reach a consensus on soft fork activation methods.
The role of Protocol Developer itself is dynamic: even though they may reject some proposals, they cannot simply be described as conservative or progressive.
Lack of urgency: As blockchain infrastructure develops increasingly well, there is not a very strong demand for Bitcoin upgrades.
Summary & Takeaway
This article introduces the basic concepts of Bitcoin upgrades, analyzes historical upgrades in depth, and finally looks forward to the active proposals for the next upgrade, summarizing the current reasons for the existing mystery of consensus.
After reviewing and looking ahead, readers should have a certain understanding of the current state of upgrades, and finally summarize several takeaways.
Pragmatic construction while steadily advancing upgrades, soft forks are preferable.
Highly differentiated interests; the community tends to be conservative.
Upgrades must be discussed under the premise of adhering to Bitcoin's core value positioning.
Scalability is just one of the areas of concern 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, the author received a lot of help, including consideration of various factors from community members who wished to remain anonymous; thanks to all of them.
It should be noted that, considering that some of the viewpoints in the article carry personal preferences, the following list of acknowledgments does not imply that they fully agree with the content of the article, and this article does not intend to involve these enthusiastic community members in any disputes.
Collaborative editing and review (alphabetical order)
Adrien Lacombe
Bob Bodily
Bitlayer Research Team
Domo
Jeffrey Hu
Red
Ren Zhang
Scott Odell
Super Testnet
Will Foxley
Provided feedback and assistance (alphabetical order)
Ajian
Andrew Fenton
Ben77
David Tse
Eli Ben-Sasson
Mi Zeng
Future Work
Throughout the process, the author found many issues worthy of deeper exploration, such as solutions for specific functionalities, research on particular 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
