Original link:

Original link:

https://bitcoinops.org/en/topics/soft-fork-activation/

Soft fork activationRefers to the moment when a Bitcoin full node begins to add one or more consensus rules. This transition creates coordination risks among nodes. Therefore, developers have spent considerable effort over the years to create and improve the soft fork activation mechanism to minimize the probability of problems.

history

history

secondary title

[2009] Hardcoded height: Consensus layer nLockTime enabled

The earliest known soft fork was implemented in Bitcoin software version 0.1.6 (released in November 2009), hardcoded to activate at block height 31000, and the actual time was November 22, 2009. This hardcoded activation height was used in at least one other early soft fork when most of the development work was done by Satoshi Nakamoto.

[2011] Hardcoded time and manual intervention: BIP12OP_EVAL fails

After Satoshi Nakamoto left Bitcoin, the first soft fork code merged into Bitcoin was BIP12OP_EVAL. The original plan was to use a hard-coded time and manual intervention when less than 50% of the computing power supported the change. Quoting from BIP12:

[...] new clients and miners will interpret OP_EVAL as a no-op until February 1, 2012. Prior to this, supported miners can write "OP_EVAL" in the blocks they produce, which is convenient for us to calculate the proportion of supported computing power. If there is no more than 50% support for this change by January 15, 2012, activation will be delayed until there is more than 50% support for OP_EVAL (if it is clear that most of the support will not activate this upgrade , the upgrade will be cancelled).

Manual intervention may have been necessary because OP_EVAL was found to have a critical vulnerability after the activation code was merged but before it was rolled out. While the bug was fixed, some developers were concerned that there might be other issues with this powerful new opcode, so people abandoned the soft fork.

[2012] Another attempt at hardcoding time and manual intervention: BIP16 P2SH

There are several simplified proposals to replace OP_EVAL (see BIP13/16, 17, 18 and 19, among other ideas). And BIP13/16 Pay to Script Hash (P2SH) has won the support of most developers. P2SH uses the same activation mechanism as OP_EVAL. The originally planned activation time was March 1, 2012, but by the February 15 billing date, less than 50% of the miners in the last 100 blocks indicated that they would implement the BIP16 rules by March. This resulted in a "pretty long replacement chain" (a chain split), as some miners who were still implementing BIP16 on March 1 rejected blocks from a majority of miners (who did not implement the new rules). The second vote date was a few thousand blocks later, on March 15th; this time it had enough support. So the developer released Bitcoin 0.6.0 on March 30, and set the activation time on April 1.

[2012] Hardcoded time: BIP30 refuses to copy txid

After the activation of P2SH is completed, it is found that multiple transactions may share the same txid. On its own, this bug would simply cause the funds of users trying to exploit the bug to be destroyed, but it could also be combined with some odd behavior in Bitcoin's Merkle tree construction to break consensus among nodes (see CVE- 2012-2459). The first soft fork to fix this vulnerability was BIP30, which simply marks subsequent transactions with the same txid as invalid if the previous transaction had unspent outputs. This fix was not controversial among the development team, so it was activated with a hardcoded time in Bitcoin 0.6.0 which included the P2SH activation parameter.

[2012] IsSuperMajority (ISM): BIP34 coinbase prefix

Although BIP30 fixes the short-term problem caused by txid overlap, Bitcoin developers know that this is a stopgap measure, and there is no reason for the software to search the index of all transactions with unspent outputs every time it receives a new transaction. So a second solution was proposed, aimed at eliminating the weakness that made txid replication a practical attack vector. This is BIP34. For this update, the developers used a miner voting method similar to BIP16 P2SH, but this time, miners who are ready to support EIP34 need to increase the nVersion value of their blocks. What's more, the developers automated the implementation of the new rules in the Bitcoin code, so they could release software that supports the soft fork while waiting for miners to upgrade. This rule from BIP34 is implemented with a function called IsSUperMajority(). At first, it contained a single activation threshold, and when it was reached, the new consensus rules of BIP34 began to be implemented:

75% rule: If 75% of the latest 1000 blocks are vision2 or larger, start rejecting invalid vision 2 blocks

During the development of this feature, it was decided to add a second activation threshold that decisively fixed the problem that BIP34 was intended to solve:

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

A known problem with the rule rejecting older versions of blocks is that, unless all miners have upgraded, there may be several invalid blocks per day (if exactly 95% of miners activate, each block has 5% odds are invalid). Nodes that have been upgraded to enforce the ISM rules will reject these blocks, but older nodes and light clients are unaware of the rules and will accept them. This makes the network more dependent than normal on miners not continuing to mine after invalid blocks.

[2015] ISM and Verificationless Mining: BIP66 Strict DER Activation

In September 2014, Pieter Wuille found a discrepancy in OpenSSL's handling of DER-encoded signatures for different platforms. This could be exploited, for example, to create a block that would pass validation on a Linux operating system but would fail on a Windows operating system—an attacker creating a chain split at the point. Wuille and several other developers developed the patch in secret and worked to activate it as a soft fork, ensuring that all signatures use the same format. BIP66 was created for this very thing, publicized as a step towards removing Bitcoin's reliance on OpenSSL (a real goal, finally achieved in 2019). After BIP66 gained enough support from users and developers (many didn't even know the security hole existed), it used the same ISM activation mechanism as BIP34, incrementing the block version number to v3 and requiring a 95% threshold Blocks with v2 and lower version numbers are then 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 later software (or compatible implementations), and the implementation begins new rules. However, at block height 363731, a non-upgraded miner produced a block that did not contain 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 finally produced a chain with 6 invalid blocks. This means that non-upgraded nodes and many light clients will treat the 96 transactions in the first invalid block as transactions that have accumulated 6 block confirmations, even if they have not yet obtained the confirmation of even a valid block at that time. confirm. In the end, the developers had no choice but to contact the mining pool operators and have them manually restart the software and get back on the active chain. Such an event repeated itself the next day, leaving some transactions with three invalid confirmations. 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 original invalid block at height 363731 is one of about 5% of blocks estimated to occur every day that become invalid simply because they use an old version number. The probability that the next block will be mined by an unupgraded miner is also 5%, so the probability that two consecutive blocks are version number canceled blocks is 0.25%. Given that 95% of miners have upgraded, the probability of 6 consecutive blocks being blocks with an invalid version number is 0.000002% - but the culprit is not yet extreme bad luck. What is not considered is that the miners may do "mining without verification", that is, after the miners receive a new block, they will continue to produce without verification, which can improve a little efficiency. While verification-less mining software could theoretically easily handle invalid block version numbers, this feature was not yet implemented in the software used by the miners who mined those five blocks at the time. Eventually, enough miners upgraded their proof-less mining software, or upgraded their nodes, and accidental chain splits related to BIP66 activation disappeared.

In response to these issues that led to the fork in July 2015, developers doubled down on efforts to reduce the need for verification-less mining, with results such as the relay of BIP152 compressed blocks and the FIBER software. Developers also began to think about a better activation mechanism, which is the BIP9 protocol that will be mentioned later.

[2015] Last ISM: BIP65OP_CHECKLOCKTIMEVERIFY activated

Before the BIP66 strict DER soft fork, it was proposed to use a soft fork to add a new opcode OP_CHECKLOCKTIMEVERIFY (CLTV) to Bitcoin, but it was postponed due to the repair of the OpenSSL vulnerability. This demonstrates another weakness of the ISM mechanism using incremental version numbers - if a miner signals support for the latest proposal (vision n), it implicitly supports all previous proposals (eg vision n-1). This limits the ability to coordinate multiple upgrades at the same time using the ISM.

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.

[2016] BIP9 versionbits: BIP68/112/113 relative lock time activation

BIP9 proposes a new activation mechanism to solve several problems with ISM:

• Penalize miners unnecessarily: ISM activation will cause the block version number to be incremented, and a block produced by a miner who does not increment the version number will be considered invalid, even if the block does not violate other rules of the soft fork. As an example, in the chain split on July 4, 2015, all transactions obeyed the soft fork rules - the only reason these miners lost $500,000 was because the upgrade required that the block header should contain a 3 and did not upgrade The miner used 2.

• Difficult to parallelize: with ISM, one has to wait for one fork to finish before another fork can start collecting signals, even if the developer deems it necessary.

• No failure allowed: ISM does not set an expiration time. Once the node software waiting for the activation signal is released, the nodes running the new software will monitor the signal until the activation is complete. There is no way to be sure that people don't need this soft fork at all.

• Unpredictable activation time: The exact activation time cannot be known in advance, which means that it is difficult for protocol developers, merchant system administrators, and mining pool operators to put it into use immediately after activation, even if there is an emergency that requires quick response question.

BIP9 versionbits try to solve these problems. It uses the vision field inside the block header as a bit field. The data in this field is only used for signaling - it will not be used as a basis for invalid blocks - and can be set in parallel. The measurement is run every 2016 blocks to compress the likelihood that a small fraction of hash power will be lucky enough to pass off 95% support. Finally, when the 95% signaling threshold is reached, there will be an additional 2016 block (approximately two weeks) "lockup period" before activation, in order for all parties to prepare for the upgrade. If the activation threshold is not reached before the expiration time, the entire soft fork attempt ends, and unused code can be removed in a later software release.

This activation method was first used in the soft fork of BIP68 consensus-enforced sequence number, BIP112OP_CHECKSEQUENCEVERIFY, and nLockTime defined in BIP113. The fork quickly entered the lock phase, and then automatically entered the activation phase.

[2016-7] BIP9, BIP148 and BIP91: BIP141/143 Segregated Witness Activation

The Segregated Witness soft fork was released with BIP9 activation parameters. A handful of miners were quick to voice their support, but support was well below the 95% threshold. Some Bitcoin users felt that miners were unreasonably delaying a useful new feature, so a voluntary activation was developed, known as BIP148. The final form of BIP148 specifies that, starting from a certain date, all blocks that do not support segwit are rejected,

After the emergence of software that implements BIP148, there are three types of nodes in the network - nodes that do not upgrade, BIP9/141 nodes, and BIP148/141 nodes - and the probability of falling into consensus errors is even greater. If miners do not support segwit, and a majority of users continue to treat these blocks as valid, BIP148 users may receive bitcoins that other users consider invalid. Furthermore, if a majority of users support BIP148, but miners continue to produce many blocks that are considered invalid by BIP148, those users who do not implement BIP148 will accept bitcoins that BIP148 users consider invalid. Upgrades are safe only if users follow the same rules and most of the computing power supports the BIP148 rules.

One way to reduce risk is to give enough time for users to upgrade to nodes that force segwit activation, but BIP148 cannot do this because its goal is to trigger the existing BIP9 process, which means , which forces miners to signal support for BIP9 long before its expiration date. As a potentially unpopular alternative to BIP148, BIP149 proposes giving users an extra year to upgrade. BIP149 never got much public support, but it was the first proposal to use BIP8, which sparked more discussion in the years to come.

As BIP148 started to gain significant public support, multiple miners, exchanges, and industry figures expressed support for a two-step proposal to activate Segregated Witness while maintaining consensus with nodes supporting BIP148. The first step is written in BIP91, which improves the rules of BIP9. Miners can use the BIP9 bitfield to indicate whether they will enforce a temporary rule: reject all blocks that do not signal support for BIP141/143 Segregated Witness. Unlike BIP9, BIP91's threshold was lowered from 95% to 80%, while the length of its monitoring and locking period was reduced from 2016 blocks to 336 blocks.

BIP91 locked and activated. Subsequently, BIP141/143 is locked and activated. When they are locked, the mandatory support measures of BIP148 expire.

The second phase of this proposal from miners, exchanges, and industry figures required a hard fork, which was withdrawn by the proposal’s signers after a large number of individual users and businesses objected fiercely.

To this day, people are still debating how much these events, and others that happened around the same time, played a role in the activation of Segregated Witness.

emergency activation

More than once, serious bugs were found in the consensus code and developers released patches without going through the activation process. Doing so could result in a consensus failure, but also immediately eliminates the vulnerability for upgraded nodes. Significant events include:

• Using chainwork to replace height (July 2010): Bitcoin initially considered the chain with the most blocks (the "longest chain") to be the valid chain. If every block has the same difficulty, then such a longest chain will also be the chain that has accumulated the most proof-of-work. But different blocks have different difficulties, so the chainwork soft fork was released in Bitcoin 0.3.3, and the chain with the most accumulated proof of work is regarded as the valid chain.

• Eliminate bugs that bypass scripts (July 2010): Bitcoin originally combined the script that spent UTXOs (scriptSig) and the script that protected UTXOs (scriptPubKey) and evaluated them simultaneously. This design allows one to terminate the script before the locking mechanism has been evaluated, exiting with a success status, for example, before running OP_CHECKSIG to check the signature. This bug was originally reported as scriptSig using OP_TRUE OP_RETURN could spend anyone's bitcoins. This bug was first fixed in Bitcoin 0.3.6 by making OP_RETURN always fail and assigning numbers to other displays in the script. While all of these changes were soft forks, changes to the same code (which later removed certain restrictions) also resulted in hard fork-style changes. Even with such a major change, the underlying problem that scriptSig can tamper with the operation of scriptPubKeys still exists, so the second soft fork was implemented in Bitcoin 0.3.8, which let the two execute independently.

• Fixed overflow bug (August 2010): Someone created a transaction to spend 0.5 btc and created two outputs worth 92,233,720,368.54277039 BTC. Bitcoin does require that the output value cannot be greater than the input value, but the detection method is to add the output value to a 64-bit integer that can represent up to 9,223,372,036,854,776 Satoshi (about 92 million btc). Satoshi started. This means that the transaction appears to have only cost a total of -0.1 btc. This also bypasses another rule that prohibits individually negative outputs, but not total negative values ​​- because it assumes that the sum of any positive values ​​will still be positive. This allows someone to create 184 billion btc, and this trick can be repeated without any cost, generating countless bitcoins. Within hours, Bitcoin 0.3.10 released a soft fork patch that limited output to 21 million btc. It also requires abandoning chains with overflowing transactions — an intentional consensus failure, but necessary for Bitcoin to still make sense.

• Temporary fix for BDB locking issue (March 2013): In early 2012, Bitcoin developers realized that if too many changes were made to the UTXO database (chain state) at the same time, one of the default capacity limits for chain state data could be exceeded. Because Bitcoin blocks were relatively small at the time, this was only observed when the blockchain reorganized, requiring transactions from multiple blocks to be processed simultaneously. A simple solution was implemented at the time: during reorganization, only process transactions from one block at a time. Later, some people started asking miners to increase the optional default block size from 250 KB. On March 12, 2013, a miner produced a ~1 MB block containing over 1,700 transactions—the largest Bitcoin block to date—that exceeded the capacity of the database on many nodes , causing them to consider the block invalid even though it fully complies with Bitcoin's explicit consensus rules. To make the water even more muddy, a new version of Bitcoin Core has been released, which uses a different database engine without this limitation, so it can safely receive this larger block - so different versions of nodes There was a consensus error. After a quick analysis of the situation, the developers encourage users to temporarily downgrade to an older version (which would reject the version with this large block), and then update to an emergency version that temporarily lowers the block size cap to 500 KB with a soft fork , to allow time for every user to upgrade to the new database engine, and this temporary downgrade automatically expires after a few months.

future activation

After months of problems with Segwit activation, some people started thinking about BIP8. Supporters of BIP8 believe that it can solve some of the problems of BIP9:

• Allow mandatory activation: BIP8 is a generalization of BIP148, miners can voluntarily signal their support during the time period waiting for activation, but it also sets an ultimatum time period during which miners must signal their support, otherwise Produced blocks may become invalid. Later, people designed a parameter LockinOnTimeout (LOT) to trigger this action: nodes using LOT=true will require miners to send a signal during the last period of time when the activation is about to time out; nodes using LOT=false will not require this , but the new rules will still apply if enough blocks are signaled.

• Use altitude instead of time: BIP9 starts and stops monitoring for activation signals based on the average of the time miners write blocks. Therefore, it is possible for miners to manipulate this time, which will hinder the function of LOT=true, so BIP8 proposes to use block height instead of time.

The flexibility of BIP8 has made it one of many candidate activation proposals for the taproot soft fork, although critics have also criticized some aspects of it, such as certain settings that allow miners to refuse to activate proposals that have broad community support, encouraging a Groups "capture" the signaling mechanism used by another group, requiring miners to make insubstantial changes to blocks produced, seemingly giving developers authority over consensus rules and increasing the risk of consensus failure. As of this writing, discussions of taproot activation methods are still ongoing.

Other ideas have been discussed, including "probabilistic soft-fork activations (sporks)", "multi-stage soft-fork activations (MSFA)", "threshold-decreasing activations (decthresh)", "returning hard-coded heights or times Activation (flag days)", and "Shorter signal period after activation delay (speedy trial)".

main code and documentation

• BIP9

• BIP8

Optech news and related sections of the website

(many, slightly)

See also

• BIP Activation Altitude, Time and Threshold

• Taproot