BIP9 versionbits: BIP68/112/113 relative lock time activated
BIP9 proposes a new activation mechanism to solve several problems of ISM:
- Unnecessarily punish miners : ISM activation will cause the block version number to be incremented, and blocks produced by miners without incrementing the version number will be considered invalid, even if the block does not violate other soft fork rules. For example, in the chain split on July 4, 2015, all transactions were subject to soft fork rules-the only reason these miners lost $500,000 was that the upgrade required that the block header should contain one
3miner who did not upgrade. Used
- It is difficult to parallelize : With ISM, even if the developer considers it necessary, he must wait for one fork to end before the other fork can start collecting signals.
- Failure is not allowed : ISM does not set an expiration time. Once the node software waiting for the activation signal is released, the node running the new software will monitor the signal until the activation is completed. There is no way to determine if people do not need this soft fork at all.
- Unpredictable activation time : It is impossible to know the exact activation time in advance, which means that it is difficult for protocol developers, merchant system administrators, and mining pool operators to put into use immediately after activation, even if there is a need for rapid response problem.
BIP9 versionbits tries to solve these problems. It uses the vision field in the block header as a bit field. The data in this field is only used to indicate the signal-it will not be used as a basis for invalid blocks-and can be set in parallel. The measurement runs every 2016 blocks to reduce the possibility of a small portion of computing power that is lucky enough to impersonate 95% support. Finally, when the 95% signal threshold is reached, there will be an additional 2016 block (approximately two weeks) “lock-up period” before activation, so that all parties can prepare to upgrade. If the activation threshold is not reached before the expiration time, the entire soft fork attempt will end, and the unused code can be deleted in a later software version.
The first use of this activation method was in
OP_CHECKSEQUENCEVERIFY the soft fork of nLockTime defined by the BIP68 consensus sequence number, BIP112 and BIP113 median time. This 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 is released with BIP9 activation parameters. A few miners quickly expressed their support, but the support rate was far below the 95% threshold. Some Bitcoin users believe that miners are unreasonably delaying a useful new feature, so they have developed a voluntary activation measure called BIP148. The final form of BIP148 specifies that, starting from a certain date, all blocks that do not support segwit will be rejected,
After the emergence of the software that implements BIP148, there are three types of nodes in the network-non-upgradable nodes, BIP9/141 nodes, and BIP148/141 nodes-the probability of getting into consensus errors is greater. If miners do not support Segregated Witness and most users continue to treat these blocks as valid, users of BIP148 may receive bitcoins that are invalid in the eyes of other users. In addition, if most users support BIP148, but miners continue to produce many blocks that are deemed invalid by BIP148, those users who do not implement BIP148 will accept bitcoins deemed invalid by BIP148 users. Only if users follow the same rules and most of the computing power supports the BIP148 rule, the upgrade is safe.
One way to reduce the risk is to give enough time for users to upgrade to the node that forcibly activate Segregated Witness, but BIP148 cannot do this, because its goal is to trigger the existing BIP9 process, which means , It will force miners to signal support long before the expiry date of BIP9. As a potentially unpopular alternative to BIP148, BIP149 proposes to give users one more year to upgrade. BIP149 has never received enough public support, but it is the first proposal to use BIP8, and BIP8 has sparked more discussions in the next few years.
When BIP148 began to receive significant public support, multiple miners, exchanges, and industry professionals expressed their support for a two-step proposal that would maintain consensus with nodes that support BIP148 while activating Segregated Witness. The first step is written in BIP91, which improves the rules of BIP9. Miners can use the bit field of BIP9 to indicate whether they will implement a temporary rule: reject all blocks that do not signal support for BIP141/143 Segregated Witness. Unlike BIP9, the threshold of BIP91 has been reduced from 95% to 80%, and the length of its monitoring and lock-up period has been reduced from 2016 blocks to 336 blocks.
BIP91 is locked and activated. Subsequently, BIP141/143 was locked and activated. When they were locked, BIP148’s mandatory support measures expired.
The second phase of this proposal from miners, exchanges and industry players requires a hard fork. After a large number of individual users and companies strongly opposed the proposal, the signatories of the proposal withdrew the proposal.
So far, people are still arguing about how much impact these events and other events that occurred during the same period have caused the activation of Segregated Witness.
More than once, people discovered serious vulnerabilities in the consensus code, and developers released patches without going through the activation process. Doing so may cause the consensus to fail, but it also immediately eliminates the loopholes for the upgraded nodes. Significant events include:
- Use chainwork to replace height (July 2010) : Bitcoin initially identified the chain with the most blocks (the “longest chain”) as the effective chain. If each block has the same difficulty, then such the 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 a valid chain.
- Eliminate the script bypass bug (July 2010) : Bitcoin initially combines the script that spends UTXO (scriptSig) and the script that protects UTXO (scriptPubKey) and evaluates them at the same time. This design allows people to terminate the script before the lock mechanism is calculated, and exit with a successful state, for example,
OP_CHECKSIGto terminate the script before running to check the signature. This bug was originally reported as using
OP_TRUE OP_RETURNscriptSig that can cost anyone’s Bitcoin. This vulnerability was fixed for the first time in Bitcoin 0.3.6 by making
OP_RETURNsure it ended in failure, and also arranged numbers for other displays of the script. Although all these changes are soft forks, changes to the same code (and later removal of certain restrictions) will also result in hard fork 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 allowed the two to execute independently.
- Fix overflow vulnerability (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 satoshis (about 92 million btc). After this integer overflows, it will be from -9,223,372,036,854,776 Satoshi started. This means that this transaction seems to only cost a total of -0.1 btc. This also bypasses another rule that prohibits single negative outputs, but does not prohibit 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 a few hours, Bitcoin 0.3.10 released a soft fork patch, limiting the output to 21 million btc. It also requires the abandonment of chains with overflow transactions-this is a deliberate consensus failure, but it must be done in order for Bitcoin to still make sense.
- Temporarily fix the BDB lock problem (March 2013) : In early 2012, Bitcoin developers realized that if too many changes are made to the UTXO database (chain state) at the same time, one of the default capacity limits for chain state data may be exceeded. Because the Bitcoin blocks at the time were relatively small, this situation was only observed when the blockchain was reorganized and transactions from multiple blocks needed to be processed at the same time. At that time, people realized a simple solution: during the reorganization, only transactions from one block at a time were processed. Later, some people started asking miners to increase the optional default block size from 250 KB. On March 12, 2013, a miner produced a block of about 1 MB containing more than 1,700 transactions — the largest Bitcoin block at the time — exceeding the capacity of the database on many nodes , Leading them to think that this block is invalid, even if it fully complies with Bitcoin’s explicit consensus rules. What makes the water more muddled is that a new version of Bitcoin Core has been released. It 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 between. After a quick analysis of the situation, the developer encourages users to temporarily downgrade to the old version (the version of this large block will be rejected), and then update to an emergency version, temporarily reducing the upper limit of the block size to 500 KB with a soft fork , So as to allow time for every user to upgrade the new database engine, and this temporary reduction will automatically expire after a few months.
After several months of problems with Segwit activation, some people began to consider BIP8. Supporters of BIP8 believe that it can solve some of the problems of BIP9:
- Mandatory activation allowed : BIP8 is a generalization of BIP148. Miners can voluntarily signal their support while waiting for activation, but it also sets an ultimatum time period during which miners must signal their support, otherwise The produced blocks may become invalid. Later, people designed a parameter
LockinOnTimeout(LOT) to trigger this action: the used
LOT=truenode will require the miner to send a signal during the last period of time when the activation is about to time out; the used
LOT=falsenode will not require this, but if there are enough Blocks carry signals, and the new rules will still be implemented.
- Use height instead of time : The time when BIP9 starts and stops monitoring activation signals is based on the average of the time miners write to the block. Therefore, it is possible for miners to control this time, which will hinder
LOT=truethe function, so BIP8 proposes to use block height instead of time.
The flexibility of BIP8 makes it one of many candidate activation proposals for taproot soft forks, although critics have also criticized some aspects of it. For example, certain settings allow miners to refuse to activate proposals that are supported by a wide community and encourage one The group “captures” the signaling mechanism used by another group, requiring miners to make insignificant changes to the blocks produced, seems to give developers the authority to override the consensus rules and increase the risk of consensus failure. As of this writing, discussions on taproot activation methods are still ongoing.
Other ideas have been discussed, including “probabilistic soft fork activation (sporks)”, “multi-stage soft fork activation (MSFA)”, “decthresh threshold activation (decthresh)”, “return to hard-coded height or time Activation (flag days)”, and “a method of using a shorter signal period after activation is delayed (speedy trial)”.
Main code and documentation
Optech news and related sections of the website
(A lot, omitted)
See you again
- BIP activation height, time and threshold
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/the-history-of-bitcoin-soft-fork-activation-part-2/
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.