The history of Bitcoin soft fork activation (part 1)

Soft fork activation refers to the moment when a Bitcoin full node starts to add one or more consensus rules. This conversion creates coordination risks between nodes. Therefore, developers have spent a lot of effort over the years to create and improve the soft fork activation mechanism to reduce the probability of problems as much as possible.

The soft fork allows the network as a whole to switch to using new consensus rules, even if not every node accepts these rules. However, whenever different nodes use different consensus rules, there is a risk that a block will be accepted by some but rejected by other nodes (it violates non-uniform rules), leading to consensus errors (chain split), and eventually There are multiple payments of funds and loss of reputation for the security of the Bitcoin system. This is the main problem that the activation mechanism is trying to alleviate.


New soft fork activation proposals are usually designed to avoid the problems that have been encountered in previous soft forks, so this section attempts to outline the more famous soft fork activation attempts.

[2009] Hard-coded height: the consensus layer nLockTime is enabled

This earliest known soft fork was implemented in Bitcoin software version 0.1.6 (released in November 2009), hard-coded to activate at block height 31000, and the actual time of occurrence was November 22, 2009. When most of the development work was done by Satoshi Nakamoto, this hard-coded activation height method was used at least in another early soft fork.

[2011] Hard-coded time and manual intervention: BIP12 OP_EVAL failed

After Satoshi Nakamoto left Bitcoin, the first soft fork code merged into Bitcoin was BIP12  OP_EVAL. The original plan was to use a  hard-coded time  and manual intervention when the percentage of computing power supporting changes is less than 50%. Quoted from BIP12:

[…] New clients and miners will explain OP_EVAL as a no-op until February 1, 2012. Prior to this, supporting miners can write the word “OP_EVAL” in the blocks they produce, so that we can calculate the percentage of supported computing power. If no more than 50% of the computing power supports this change before January 15, 2012, activation will be postponed until more than 50% of the computing power supports OP_EVAL (if obviously most of the computing power will not activate this upgrade , The upgrade will be cancelled).

Manual intervention may be necessary because  OP_EVAL a serious vulnerability was discovered after the activation code was merged and before it was launched. Although this bug was fixed, some developers worried that this powerful new opcode might have other problems, so people gave up this soft fork.

[2012] Try hard coding time and manual intervention again: BIP16 P2SH

Several alternative  OP_EVAL simplified proposals have been proposed (see BIP13/16, 17, 18 and 19, among other ideas). The BIP13/16 payment to the script hash value (P2SH) has won the support of most developers. P2SH uses the same activation mechanism as OP_EVAL. The original planned activation time was March 1, 2012, but by the February 15 ticketing date, less than 50% of the miners in the last 100 blocks stated that they would implement the BIP16 rules before March. This resulted in a “quite long alternative chain” (chain split), because some miners who still implemented BIP16 on March 1 rejected blocks from the majority of miners (without implementing the new rules). The second billing date was a few thousand blocks later, March 15th; this time it received enough support. So the developer released Bitcoin 0.6.0 on March 30 and set the activation time on April 1.

[2012] Hard-coded time: BIP30 refused to copy txid

After the activation of P2SH was completed, people discovered that multiple transactions may share the same txid. On its own, this bug will only cause the funds of users who try to exploit this bug to be destroyed, but it can also combine with some strange behaviors in the construction of Bitcoin’s Merkel tree to break the consensus between nodes (see CVE- 2012-2459). The first soft fork to fix this vulnerability is BIP30, which simply marks the subsequent transactions using the same txid as invalid transactions, if the previous transaction has unspent output. This fix is ​​not disputed in the development team, so it is activated with hard-coded time in Bitcoin 0.6.0 that includes P2SH activation parameters.

[2012] IsSuperMajority (ISM): BIP34 coinbase prefix

Although BIP30 fixes the short-term problem caused by the coincidence of txid, Bitcoin developers know that this is just a stopgap measure, and there is no reason for the software to search the index of all transactions with unspent output every time it receives a new transaction. So the second solution is on the agenda, aiming to eliminate the weakness that makes txid replication a practical attack vector. This is BIP34. For this update, the developer used a miner voting method similar to BIP16 P2SH, but this time, miners who are ready to support EIP34 need to increase nVersion the value of their block  . More importantly, developers have automated the implementation of new rules in the Bitcoin code, so they can release software that supports soft forks while waiting for miners to upgrade. This rule from BIP34 is  implemented with a function called  IsSUperMajority(). At first, it included a single activation threshold, and when it reached it, it began to implement the new consensus rules of BIP34:

The 75% rule: If 75% of the latest 1000 blocks are vision 2 or greater, start to reject invalid vision 2 blocks

During the development of this feature, people decided to add a second activation threshold to decisively fix the problem to be solved by using BIP34:

95% rule: If 950 of the latest 1000 blocks are vision 2 or larger, reject all vision 1 blocks

A known problem with the rule of rejecting old versions of blocks is that unless all miners have been upgraded, there may be several invalid blocks generated every day (if it happens to be activated by 95% of the miners, each block has 5% The odds are invalid). Nodes that have been upgraded and implemented ISM rules will reject these blocks, but older nodes and light clients do not know this rule, so they will accept these blocks. This makes the network more dependent on miners who do not continue mining behind invalid blocks than normal.

[2015] ISM and non-verified mining: BIP66 strict DER activation

In September 2014, Pieter Wuille discovered that OpenSSL had differences in handling DER-encoded signatures on different platforms. This can be used, for example, to create a block that can be verified on the Linux operating system but will fail on the Windows operating system-the attacker creates a chain split at a fixed point. Wuille and several other developers secretly developed the patch and are committed to soft fork activation to ensure that all signatures use the same format. BIP66 was created for this matter, in public promotion, as a step to remove Bitcoin’s dependence on OpenSSL (this goal is real and will finally be achieved in 2019). After BIP66 has gained sufficient support from users and developers (many people don’t even know that this security vulnerability exists), it uses the same ISM activation mechanism as BIP34, increments the block version number to v3, and requires a 95% threshold Later, blocks with v2 and lower version numbers are rejected.

The 75% threshold was reached on July 4, 2015, and the 95% threshold was reached at block height 363725. All nodes are running Bitcoin Core v0.10.0 or higher software (or compatible implementations), and they are implemented New rules. However, at block height 363731, an unupgraded miner produced a block without the current version number, which is not a valid block under the new ISM activation rules. But other miners continued to produce after this invalid block, and eventually a chain with 6 invalid blocks was produced. This means that unupgraded nodes and many light clients will treat the 96 transactions in the first invalid block as a transaction that has accumulated 6 block confirmations, even if they have not obtained even a valid block at the time. confirm. In the end, developers can only contact the mining pool operator and ask them to manually restart the software and return to a valid chain. Such an event repeated itself the next day, resulting in three invalid confirmations for some transactions. Fortunately, all regular transactions in these six and three blocks were later packaged into valid blocks, which means that ordinary users have no losses.

The invalid block originally located at 363731 height is one of about 5% of the blocks that become invalid just because of the use of the old version number and is expected to appear every day. The probability of the next block being mined by an unupgraded miner is also 5%, so the probability that two consecutive blocks have the version number and cancel the block is 0.25%. Given that 95% of miners have been upgraded, the probability that 6 consecutive blocks are invalid version numbers is 0.000002%-but the culprit is not extremely bad luck. What is not considered is that miners may do “no-verification mining”, that is, after receiving a new block, miners will continue production without verification, which can improve efficiency a little. Although the verification-free mining software can theoretically easily handle invalid block version numbers, this function has not yet been implemented in the software used by the miners who mined the five blocks at the time. In the end, enough miners upgraded their non-verified mining software, or upgraded their nodes, and the accidental chain split associated with BIP66 activation disappeared.

In response to these issues that led to the fork in July 2015, developers have redoubled their efforts to reduce the need for verification-free mining, such as the relay of BIP152 compressed blocks and FIBRE software. Developers have also begun to think about a better activation mechanism, which is the BIP9 protocol that will be mentioned later.

[2015] The last ISM: BIP65 OP_CHECKLOCKTIMEVERIFY activation

Before the BIP66 strict DER soft fork, someone proposed to add a new opcode  (CLTV) to Bitcoin with a soft fork  OP_CHECKLOCKTIMEVERIFY, but it was delayed because of the fix for OpenSSL vulnerabilities. This reflects another weakness of the ISM mechanism using incremental version numbers-if a miner sends a signal to support the latest proposal (vision n), it implicitly indicates that it supports all previous proposals (such as vision n-1). This limits the ability to use ISM to coordinate multiple upgrades at the same time.

However, despite some problems with the activation of BIP 66, ISM was once again used in the delayed activation of BIP65. This time there were no more problems.


Posted by:CoinYuppie,Reprinted with attribution to:
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Leave a Reply