Author: kevin He, co-founder of Bitlayer

Foreword

There has been endless talk about the next upgrade of Bitcoin , however so far (DEC-2024), the community has not reached an agreement on topics such as whether to upgrade/the problems to be solved by the upgrade/the functions to be brought, etc. Basically, they all hold their own opinions, just like a certain kind of deadlock.

Under this deadlock, many interesting phenomena have emerged:

Some community members Actively promote upgrades. Due to information asymmetry or commercial interests, some members must refer to certain opcodes, and some projects will rely on certain opcodes that "may appear".

Quite a few pragmatic ecological developers have done a lot of cryptography and engineering work to expand the potential of Bitcoin based on the premise of not upgrading the protocol.

There are also many voices advocating slow upgrades or opposing upgrades.

The emergence of these phenomena shows that the topic of upgrade is quite popular in the Bitcoin community, but it also reflects that a considerable number of community members do not understand the complete process of a Bitcoin upgrade. There is a lack of understanding and lack of understanding of the role of innovative cryptographic tools in realizing the potential of Bitcoin. The core purpose of this article is to break this information asymmetry and bring everyone's information to the same level, allowing for a more in-depth discussion.

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. Finally, Summarize some takeaways for readers. The intention is to present this information to allow readers to grasp the concept/history/progress of Bitcoin upgrades, to lay the foundation for further discussions on the topic of Bitcoin upgrades, and to pave the way for the formation of a final community consensus.

This article strives to present the facts. At the same time, the author, as a Bitcoin ecological developer, hopes that Bitcoin will have more possibilities, so the author will express his opinions on some topics. Clear point of view, please pay attention to the distinction.

Upgrade Introduction: What and Why What is Bitcoin Upgrade

The Bitcoin white paper defines a protocol by tens of thousands of nodes that follow the Bitcoin protocolForms the Bitcoin blockchain network.

There are many versions of protocol implementations (often called clients). According to the bitnodes data source, the client with the largest market share is Bitcoin Core, so Bitcoin-Core's code maintainers (hereinafter referred to as Bitcoin-Core-Devs) have considerable influence in Bitcoin development.

what-why-1

< p style="text-align: left;">Bitcoin node software is composed of multiple modules. Bitcoin-related upgrade proposals are defined by BIP (Bitcoin Improvement Proposal). People have made several classifications for BIP.

Normally, when people discuss Bitcoin upgrades, they generally refer to "consensus protocol upgrades." The same applies below, because consensus protocol upgrades require a large network of the entire network. Some nodes form a consensus (otherwise it may lead to forks), so special caution is required. As shown in the figure below, the modules related to the consensus protocol in the Bitcoin system and the proposals related to the BIP consensus layer deserve special attention.

what-why-2

< p style="text-align: left;">In fact, according to statistics from the Bitcoin github repository, modifications are very active. Since most of the changes have nothing to do with 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 fork and hard fork.

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

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

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

BIP and soft fork process

The first two successful consensus protocol upgrades (Taproot/SegWit) both used soft forks. Without a huge community split, this article focuses on soft forks, that is Upgrade if compatible with older versions of software.

After the BIP proposal is submitted, the process is roughly as follows:

< p style="text-align: left;">bip-state, source: https://river.com/learn/what-is-a-bitcoin-improvement-proposal-bip/< /p>

Usually a soft fork proposal aggregates multiple BIPs. For example, taproot contains 3 BIPs:

Schnorr Signature: BIP-340

p>

Taproot: BIP-341

Tapscript: BIP-342

Review Taproot upgrade timeline:

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

Taproot soft fork phase milestones include:

The corresponding BIP was proposed, and the implementation plan was reviewed

Bitcoin-Core code maintainer initiated an upgrade github pull request

Bitcoin-Core The code maintainer reviews and merges the github pull request and decides the activation method

New version of Bitcoin-Core code release

Vote on the miner chain to approve the activation block height of BIP

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. In fact, there is no written consensus on this milestone.

During the entire process, the Bitcoin Development Mailing List played a key role in condensing consensus among all parties.

Why upgrade

As mentioned at the beginning of the article, there are three main types of voices for upgrading the current community:

Active promoters: put forward a large number of proposals, which will be analyzed below.

Pragmatic Constructionist: Implementing Fraud Proof (BitVM and its extensions) based on existing protocols, function encryption (contracts and zk proofs implemented through Bitcoin PIPEs) and Kazakhstan Collision (contract implemented through ColliderScript), etc.

Stand-still faction: They believe that the upgrade should be very slow and steady (10-year cycle) TeamSlowAndSteady, and Ossifiers (reference) that should not be upgraded unless there is a quantum attack

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

As A pragmatic Bitcoin ecological developer, the author believes that within the existing protocol framework, it is essential to fully tap the potential of Bitcoin through cryptography or engineering innovation, and at the same time, from the perspective of "sustainability" and "adaptability" From this perspective, it is advisable to continuously upgrade as needed after fully assessing the scope of impact and security risks.

Stakeholders of the in-depth upgrade

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

Bitcoin-Core-Devs

Mining Pool

Users and ecological developers (mainly exchanges/chip manufacturers, etc.)

With the rapid increase in the adoption rate of Bitcoin, Bitcoin upgrades The stakeholders have also gradually evolved from the earliest simple separation of powers into a situation of conflict among kings. Please refer to the report Analyzing Bitcoin Consensus: Risks in Protocol Upgrades.

stakeholders

Several roles here are worth introducing:

Economic Nodes: mainly refers to mainstream CEX exchanges/payment institutions/ Hosting service providers, etc., their soft forks This attitude determines which Bitcoin is legal and will have a significant impact on adoption rates.

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

User&Ecosystem Developer: in TaproAfter the ot upgrade, the Bitcoin ecosystem has flourished, with asset protocols such as Ordinals emerging, and a large number of native applications/scaling protocols emerging.

There are some interesting conclusions about these roles:

Different stakeholders in Different stages play different roles: for example, Ecosystem Developer has greater enthusiasm for proposals, Protocol Developer often exercises BIP review authority, and mining pools and economic nodes have greater influence on activation

Different Ecosystem Developer 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 forks since the launch of the Bitcoin network upgrade.

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:

Bitcoin's protocol has become somewhat rigid. As time goes by, softfork's Frequency decreases

It takes longer and longer to reach consensus on upgrades

Soft Fork concerns

Analyze what past soft forks contain BIP can summarize the following areas of concern:

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:

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

Application potential/brings An elegant balance between risks: so that most people like it and no one strongly objects

Appropriate upgrade scale: not too simple (not worth the effort), It can’t be too complicated (it’s difficult to push)

Reasonable timing: There needs to be a strong need to solve a specific problem. For example, in the SegWit upgrade phase, capacity expansion is a strong demand

Upgrade Prospect Proposal Classification

The author collected most of the active proposals and tried to label them with concerns. Put it into four quadrants to facilitate readers' visual understanding.

Note on classification:

The four areas of concern are not completely isolated from each other. For example, a BIP that helps enhance programmability may actually help scalability to some extent.

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

For the topic of what aspects a proposal should focus on, some kind of "consensus" (itself) is needed. It should be noted that there is no unique definition here, because different Participants will have different angles

The second diagram is not a coordinate system, it is classified and divided according to labels, and the circle attributes (size/position/color, etc.) Has no special meaning

proposal category-2

proposal category-1

Community Voice

You can see from the picture aboveIt can be seen that 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:

Programmability: Enables UTXO to have stronger programming capabilities, such as coinant/vault/transaction introspection/conditional payment/script enhancement, etc.

Extensibility: for 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 Bitcoin The currency community is stuck in a maze of consensus for the next upgrade for the following reasons:

rigidity: a software system close to $2T FDV, a considerable number of stakeholders tend to maintain Stable, no party is willing to take responsibility for the accident

Stakeholders are highly differentiated: Different stakeholders have different demands and play different roles at different stages; they have also become stakeholders

Incomplete governance mechanism: Bitcoin, as the earliest blockchain, lacks a very complete governance mechanism; the community cannot reach a consensus on the soft fork activation method

Protocol Developer The role itself is dynamic: even if they do veto some proposals, they cannot be described as simply conservative/chasing the new

Lack of urgency: Block The development of chain infrastructure is becoming more and more perfect, and there is no strong demand for the upgrade of Bitcoin

Summary&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 confusion about consensus.

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

Pragmatic construction while steadily promoting upgrades, soft forks are more preferable

Highly differentiated interests , the community tends to be conservative

We must discuss upgrades while adhering to the core value positioning of Bitcoin

Scalability is only one of the concerns of upgrades

We need a better time, good upgrade proposals will quickly gain consensus

Community Better governance mechanisms need to be explored

Acknowledgments

During the research/writing/review process of this article, I received a lot of help, including community members who were unwilling to sign their names due to various factors. I would like to express my gratitude here. It is worth noting: Considering that the opinions in the article contain personal preferences, the following list of thanks does not mean that they completely agree with the content of the article, and this article does not intend to involve the enthusiasts in these communities into any disputes.