The mystery of consensus: an article to understand the progress of the Bitcoin upgrade community

This article will define the upgrade of Bitcoin, summarize certain rules by looking back at history, and then analyze the current upgrade proposals and potential alternatives, and finally summarize several takeaways for readers. The intention is to present this information so that readers can grasp the concept/history/progress of Bitcoin upgrades, lay the foundation for readers to further discuss the topic of Bitcoin upgrades, and pave the way for the formation of the final community consensus.

This article strives to present facts. At the same time, as a Bitcoin ecosystem developer, the author hopes that Bitcoin can have more possibilities, so the author will express clear views on some topics, please pay attention to distinguish.

Upgrade Introduction: What and Why

What is Bitcoin Upgrade

The Bitcoin white paper defines a protocol, which consists of tens of thousands of nodes that follow the Bitcoin protocol.

There are many versions of the implementation of the protocol (usually called the client). 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 a considerable influence on the life of Bitcoin.

what-why-1

The Bitcoin node software consists of multiple modules. Bitcoin-related upgrade proposals are defined by BIP (Bitcoin Improvement Proposal), and people have made several classifications for BIP.

Usually, when people discuss Bitcoin upgrades, they generally refer to "consensus protocol upgrades". The same applies to the following. Since the consensus protocol upgrade requires most of the nodes in the entire network to reach a consensus (otherwise it may cause a fork), it requires special caution. As shown in the figure below, the consensus protocol-related modules in the Bitcoin system and the BIP consensus layer-related proposals deserve special attention.

what-why-2

In fact, according to statistics from the Bitcoin github repository, modifications are very active. Since most of the changes are not related to the consensus protocol, they have not attracted widespread attention.

Bitcoin-core-github-stats

Consensus protocol upgrade types

According to the definition of BIP-123, consensus protocol upgrades are mainly divided into soft forks and hard forks.

In addition, there is a less intuitive way to interpret and compare, which is also very interesting:

• Soft fork: add/strengthen rules (simply imagine adding a new feature, such as supporting taproot addresses)

• Hard fork: remove/relax rules (simply imagine removing a restriction, such as removing the restriction on block rewards)

BIP and soft fork process

The first two successful consensus protocol upgrades (Taproot/SegWit) both used soft forks. In the absence of a huge community split, this article focuses on soft forks. Fork (soft fork) means upgrading while being compatible with the old version of the software.

After the BIP proposal is submitted, the process is roughly as shown in the figure below:

bip-state, source: https://river.com/learn/what-is-a-bitcoin-improvement-proposal-bip/

Usually a soft fork proposal will aggregate multiple BIPs. For example, taproot includes 3 BIPs:

1. Schnorr Signature: BIP-340

2. Taproot: BIP-341

3. Review the Taproot upgrade schedule:

   

   Taproot-timeline, Source: Kraken Intelligence, GitHub, CoinDesk, https://www.argoblockchain.com/articles/bitcoin-taproot-upgrade-explained

   The phase milestones of the Taproot soft fork include:

   1. The corresponding BIP is proposed and the implementation plan passes review

   2. The Bitcoin-Core code maintainer initiates the upgrade github pull

   3. Bitcoin-Core code maintainers review and merge github pull requests to decide on the activation method

   4. New version of Bitcoin-Core code is released

   5. Miners vote on the chain to approve the activation block height of BIP

   6. The block height reaches the agreed height and the upgrade is completed

   It should be noted that this process is summarized by looking back at history, and there is actually no written consensus on this milestone.

   Throughout the process, the Bitcoin Development Mailing List played a key role in consolidating the consensus of all parties.

   Why upgrade?

   As mentioned at the beginning of the article, there are three main voices in the community regarding the upgrade:

   1. Active promoters: A large number of proposals have been put forward, which will be analyzed below.

   2. Pragmatic constructionists: Implement Fraud Proof (BitVM and its extensions), function encryption (contracts and zk proofs implemented through Bitcoin PIPEs) and hash collisions (contracts implemented through ColliderScript) based on existing protocols.

   3. Maintainers: TeamSlowAndSteady, who believe that upgrades should be very slow and steady (10-year cycle), and Ossifiers, who believe that upgrades should not be made unless there is a quantum attack (reference)

   The author made an analysis of the pros and cons of updating and not updating:

   

   As a pragmatic Bitcoin ecosystem developer, the author believes that under the existing protocol framework, it is essential to fully tap the potential of Bitcoin through cryptography or engineering innovation. At the same time, from the perspective of "sustainability" and "adaptability", it is desirable to continuously upgrade as needed while fully evaluating the scope of impact and security risks.

   Upgrade in Depth

   Stakeholders of the Upgrade

   The main participants of the Hong Kong Consensus in Bitcoin's history (signed at the Bitcoin Roundtable event in February 2016, reference) are:

   1. Bitcoin-Core-Devs

   2. Mining Pools

   3. Users and Ecosystem Developers (mainly exchanges/chip manufacturers, etc.)

   With the rapid increase in Bitcoin's adoption rate, the stakeholders of Bitcoin upgrades have gradually evolved from the earliest simple separation of powers to a situation of kings' disputes, refer to the report Analyzing Bitcoin Consensus: Risks in Protocol Upgrades.

   

   stakeholders

   Several roles here are worth highlighting:

   1. Economic Nodes: Mainly refers to mainstream CEX exchanges/payment institutions/custodian service providers, etc. Their attitude towards soft forks determines which type of Bitcoin is legal, which will have an important impact on the adoption rate.

   2. Investors: In the context of the global prevalence of Bitcoin strategies (EFT/institutional reserves/national reserves, etc.), the role of investors itself has become more complicated.

   3. User&Ecosystem Developer: After the Taproot upgrade, the Bitcoin ecosystem has flourished, with the emergence of asset protocols such as Ordinals, as well as a large number of native applications/expansion protocols.

   For these roles, there are some interesting conclusions:

   1. Different stakeholders play different roles at different stages: for example, Ecosystem Developers are relatively active in proposals, Protocol Developers often exercise their BIP review authority, and mining pools and economic nodes have a relatively large influence on activation

   2. Different Ecosystem Developers tend to propose and support proposals related to their own business interests

   History and summary of upgrades

   According to public information, there have been many soft fork upgrades since the launch of the Bitcoin network.

   

   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 figure:

   1. Bitcoin's protocol has become somewhat rigid, and the frequency of softforks has decreased over time

   2. It takes longer and longer to reach consensus on upgrades

   Analyzing the BIPs included in past soft forks, we can summarize the following concerns:

   

   What is a good upgrade proposal?

   Based on the facts and analysis listed in the previous aspects, we try to define a good upgrade proposal:

   1. Adhere to the core positioning of Bitcoin as a payment system: Bitcoin has a unique positioning

   2. Achieve an elegant balance between application potential and risks: make most people like it and no one strongly opposes it

   3. left;">Appropriate upgrade scale: not too simple (not worth the fuss), nor too complex (difficult to promote)

   4. Reasonable timing: there needs to be a strong demand to solve specific problems. For example, in the SegWit upgrade phase, capacity expansion is a strong demand

   Upgrade Outlook

   Proposal Classification

   The author collected most of the active proposals, tried to label them with focus areas, and put them in four quadrants for readers to visualize and understand.

   Note about classification:

   1. The four focus areas are not completely isolated from each other. For example, BIPs that are conducive to enhancing programmability may actually help scalability to some extent.

   2. A proposal may have multiple concerns. For example, OP_CAT itself is to enhance programmability, but more people actually push it because it helps to achieve validity rollup.

   3. For the topic of which aspects a proposal focuses on, some kind of "consensus" is needed (politics itself). Note that there is no single definition here, because different participants will have different perspectives.

   4. The second diagram is not a coordinate system. It is classified according to the labels. The circle attributes (size/position/color, etc.) have no special meaning.

   

   proposal category-2

   

   proposal category-1

   Community Voice

   As can be seen from the above figure, the community has a certain consensus on the problems to be solved by the upgrade, that is, the functional expansion required by the payment system can be classified into the following two categories:

   1. Programmability: Make UTXO more programmable, such as covenant/vault/transaction introspection/conditional payment/script enhancement, etc.

   2. Scalability: For the expansion of L2, the overall solution is divided into two categories: 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 stuck in a maze of consensus for the next upgrade for the following reasons:

   1. Rigidity: For a software system approaching $2T FDV, a considerable number of stakeholders tend to maintain stability, and no party is willing to take responsibility for accidents

   2. Highly differentiated stakeholders: Different stakeholders have different demands and can play different roles at different stages; the government has also become a stakeholder

   3. Imperfect governance mechanism: As the earliest blockchain, Bitcoin lacks a very complete governance mechanism; the community cannot reach a consensus on the soft fork activation method

   4. The role of Protocol Developer itself is dynamically changing: Even if they do veto some proposals, it cannot be described as simply conservative/new

   5. Lack of urgency: The blockchain infrastructure is becoming more and more complete, and there is no very strong demand for Bitcoin upgrades

   Summary &Takeaway

   After reviewing and looking forward, I believe that readers have a certain understanding of the current status of the upgrade, and finally summarize several takeaways.

   1. Pragmatic construction and steady promotion of upgrades, soft forks are more desirable

   2. Stakeholders are highly divided, and the community tends to be conservative

   3. Upgrades must be discussed under the premise of adhering to the core value positioning of Bitcoin

   4. Scalability is just one of the focus areas of the upgrade

   5. A better time is needed, and good upgrade proposals will quickly gain consensus

   6. 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 community members who did not want to be named for various reasons. I would like to thank them here. It is worth noting that: considering that some of the opinions in this article are personal preferences, the following list of thanks does not mean that they fully agree with the content of the article, and this article does not intend to involve these enthusiastic people in the community in any disputes.