Written by: Kevin He, co-founder of Bitlayer
Introduction
The topic of Bitcoin's next upgrade has been a constant discussion, yet as of now (DEC-2024), the community has not reached a consensus on whether to upgrade, what problems the upgrade should solve, or the functionalities it should bring; essentially, there is a situation of conflicting opinions, reminiscent of a political stalemate.
In this deadlock, many interesting phenomena have emerged:
Some community members actively promote upgrades. Due to information asymmetry or commercial interests, some members frequently mention certain opcodes, and some projects rely on certain 'potentially available' opcodes.
A considerable number of pragmatic ecosystem developers have done a lot of cryptographic and engineering work based on the premise of not upgrading the protocol to expand Bitcoin's potential.
There are also numerous voices advocating for slow upgrades or opposing upgrades.
The emergence of these phenomena indicates that the topic of upgrades is quite popular in the Bitcoin community, but it also reflects that a significant portion of community members do not understand the complete process of a Bitcoin upgrade, and they lack awareness of the role of innovative cryptographic tools in realizing Bitcoin's potential. The core writing purpose of this article is to break this information asymmetry, bringing everyone's information to the same level, thereby allowing for deeper discussions.
This article will define Bitcoin upgrades, summarize certain patterns through a historical review, analyze current upgrade proposals and potential alternatives, and finally summarize several takeaways for readers. The intention is to present this information so that readers grasp the concepts/history/progress of Bitcoin upgrades, laying the foundation for further discussions on the topic of Bitcoin upgrades and paving the way for the eventual formation of community consensus.
This article strives to present the 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; please be discerning.
Upgrade introduction: What and Why
What is a Bitcoin upgrade
The Bitcoin white paper defines a protocol composed of thousands of nodes following the Bitcoin protocol, forming the Bitcoin blockchain network.
There are many versions of the protocol implementation (often referred to as clients). According to the bitnodes data source, the client with the largest market share is Bitcoin Core, so the code maintainers of Bitcoin Core (hereinafter referred to as Bitcoin-Core-Devs) have considerable influence in the Bitcoin ecosystem.
what-why-1
The Bitcoin node software consists of multiple modules, and relevant upgrade proposals for Bitcoin are defined by BIPs (Bitcoin Improvement Proposals), which have been categorized into several types.
Typically, when people discuss Bitcoin upgrades, they generally refer to 'consensus protocol upgrades'. The following text follows the same logic. Since consensus protocol upgrades require the consensus of the majority of nodes across the network (otherwise, it could lead to a fork), special caution is needed. As shown in the diagram, the modules related to the consensus protocol in the Bitcoin system and the proposals related to the BIP consensus layer warrant particular attention.
what-why-2
In fact, according to statistics from the Bitcoin GitHub repository, modifications are very active. Most of the changes are unrelated to the consensus protocol, thus not attracting widespread attention.
Bitcoin-core-github-stats
Types of consensus protocol upgrades
According to the definition of BIP-123, consensus protocol upgrades are mainly divided into soft forks and hard forks.
Additionally, there is another less intuitive way to interpret and compare, which is also very interesting:
Soft fork: Add / Strengthen rules (imagine simply that a new feature has been added, for example, supporting taproot addresses)
Hard fork: Remove / Relax rules (imagine simply that a restriction has been removed, for example, removing the limit on block rewards)
BIP and soft fork processes
The first two successful consensus protocol upgrades (Taproot/SegWit) were both conducted via soft forks, without causing significant community splits. This article focuses on soft forks, which are upgrades compatible with older versions of software.
The process after the submission of the BIP proposal is roughly as shown in the diagram:
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 3 BIPs:
Schnorr Signature: BIP-340
Taproot: BIP-341
Tapscript: BIP-342
Let’s review the timeline of the Taproot upgrade:
Taproot-timeline, Source: Kraken Intelligence, GitHub, CoinDesk, https://www.argoblockchain.com/articles/bitcoin-taproot-upgrade-explained
The milestones of the Taproot soft fork include:
The corresponding BIP is proposed, and the implementation plan goes through review.
Bitcoin-Core code maintainers initiate upgrade GitHub pull requests.
Bitcoin-Core code maintainers review and merge GitHub pull requests, deciding on the activation method.
New version of Bitcoin-Core code is released.
Miners vote on-chain to approve the activation block height of the BIP.
The block height reaches the agreed height, completing the upgrade.
It should be noted that this process is a retrospective summary, and there is no formal consensus on this milestone.
Throughout the process, the Bitcoin Development Mailing List played a key role in consolidating consensus among various parties.
Why upgrade
As mentioned at the beginning of the article, there are primarily three types of voices in the community regarding upgrades:
Proactive faction: Proposed a large number of proposals, which will be analyzed below.
Pragmatic construction faction: Based on the existing protocol, implementing Fraud Proof (BitVM and its extensions), function encryption (contracts and zk proofs realized through Bitcoin PIPEs), and hash collisions (contracts realized through ColliderScript), etc.
Status quo faction: They believe upgrades should be very slow and steady (with a 10-year cycle), referring to TeamSlowAndSteady, and that upgrades should not occur unless there is a quantum attack, known as Ossifiers.
The author conducted a pros-and-cons analysis of updating versus not updating:
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. Furthermore, from the perspectives of 'sustainability' and 'adaptability', continuous upgrades based on a thorough assessment of impact scope and security risks are desirable.
In-depth upgrade
Stakeholders in the upgrade
The Hong Kong consensus in Bitcoin's history (signed at the Bitcoin Roundtable event in February 2016, for reference) mainly involved:
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 a simple separation of powers to a situation of competing factions, referring to the report 'Analyzing Bitcoin Consensus: Risks in Protocol Upgrades.'
stakeholders
Several roles here are worth highlighting:
Economic Nodes: Mainly refer to mainstream CEX exchanges/payment institutions/custodians, etc. Their attitudes towards soft forks determine which Bitcoin is considered legitimate and significantly influence adoption rates.
Investors: In the global context where Bitcoin strategies (EFT/institutional reserves/national reserves, etc.) are prevalent, the role of investors has become more complex.
User & Ecosystem Developer: After the Taproot upgrade, the Bitcoin ecosystem has flourished, with asset protocols like Ordinals emerging, along with a large number of native applications/scaling protocols.
Some interesting conclusions can be drawn about these roles:
Different stakeholders play different roles at different stages: for example, Ecosystem Developers are quite proactive about proposals, Protocol Developers often exercise review authority over BIPs, and mining pools and economic nodes have significant influence over activation.
Different Ecosystem Developers tend to propose and support proposals related to their commercial interests.
History and summary of upgrades
According to public information, several soft fork upgrades have occurred since the Bitcoin network was launched.
soft forks, data source: 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 become somewhat rigid, and as time goes on, the frequency of soft forks has decreased.
The time required to reach consensus on upgrades is increasing.
Soft Fork focus areas
By analyzing past soft forks that included BIPs, we can summarize the following focus areas:
What constitutes a good upgrade proposal
Based on the 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 risks: making it favorable for most people, with no strong opposition.
Appropriate scale of upgrades: It cannot be too simple (not worth the effort), nor too complicated (difficult to promote).
Reasonable timing: A strong demand is needed to solve specific problems. For example, during the SegWit upgrade phase, scalability was a strong demand.
Upgrade outlook
Proposal categorization
The author has collected most of the active proposals and tagged them with focus areas, placing them in quadrants for easier visual understanding by the readers.
Regarding the need for categorization:
The four focus areas are not entirely isolated from each other; for example, BIPs that enhance programmability may also contribute to scalability to some extent.
A proposal may have multiple aspects of focus; for example, OP_CAT itself enhances programmability, but more people are pushing it because it helps achieve validity rollup.
The focus areas of a proposal require a certain 'consensus' (which is political in nature). It should be noted that there is no unique definition here, as different participants may have different perspectives.
The second diagram is not a coordinate system but categorizes based on labels; the attributes of the circles (size/position/color, etc.) do not carry special significance.
proposal category-2
proposal category-1
Community voices
From the above diagram, it can be seen that there is a certain consensus in the community regarding the problems to be solved by upgrades, which can be categorized into two main types related to the functionalities needed 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 expansion, the overall scheme is divided into on-chain verification and off-chain verification, both of which have actively promoted proposals.
The puzzle 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: A software system with an FDV close to $2T, a considerable portion of stakeholders prefer to maintain stability, and no party is willing to take responsibility for accidents.
Stakeholders are highly differentiated: Different interests have different demands and can play different roles at different stages; the government has also become a stakeholder.
Governance mechanisms are inadequate: As the earliest blockchain, Bitcoin lacks a very well-developed governance mechanism; the community also cannot reach a consensus on the activation method of soft forks.
The role of Protocol Developers is itself dynamic: Even though they may veto some proposals, they cannot simply be characterized as conservative or progressive.
Lack of urgency: The development of blockchain infrastructure is becoming increasingly robust, and there is no strong demand for Bitcoin upgrades.
Summary & Takeaway
This article provides an introduction to 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 puzzle of consensus.
After reviewing and looking forward, I believe readers now have a certain understanding of the current state of upgrades, and I will summarize several takeaways.
Pragmatic construction while steadily advancing upgrades; soft forks are more preferable
Stakeholders are highly differentiated, and the community tends to be conservative
Upgrades must be discussed under the premise of adhering to the core values of Bitcoin.
Scalability is just one of the focus areas of upgrades.
A better timing is needed; good upgrade proposals will quickly gain consensus.
The community needs to explore better governance mechanisms.
