Bitcoin CSV Soft Fork – Important Guidelines for Miners to Upgrade

There is a soft fork in progress for Bitcoin’s consensus rules, and while everything appears to be working fine, there is important information and a checklist of things that miners and mining pool owners must not ignore.

If miners and mining pool managers have any questions, please feel free to contact us.

summary

1. You must check all your nodes to ensure they have been upgraded to Bitcoin Core 0.12.1 or compatible software before block 419328 is produced.

2. If you are setting the block version number manually, or are using the nSequence or nLockTime parameters in the coinbase transaction, you must follow the instructions below carefully.

CSV Soft Fork

The "CSV" soft fork has reached the "lock-in" requirement and will be officially launched. Of the 2016 blocks from 415296 to 417311, 1946 (96.53%) showed that the BIP68, BIP112 and BIP113 ("CSV") soft fork was ready to be implemented. Starting from block 417312 (2016-06-21 05:18:58 UTC), the CSV soft fork entered a "lock-in" grace period of approximately two weeks until block 419327. After that, the new rules of BIP68, BIP112 and BIP113 will be officially implemented. The soft fork has passed the critical point and its implementation is irreversible without a very large blockchain rollback.

All miners please take note

During the grace period, all miners must upgrade to Bitcoin Core 0.12.1 or any compatible software that supports the CSV soft fork. In fact, at the time of writing this article, Bitcoin Core 0.12.1 is the only version that supports the CSV soft fork. Miners must double-check that all mining nodes and backup nodes are upgraded.

Failure to follow the above guidelines may result in the production of invalid blocks, or the extension of an invalid blockchain, causing a blockchain fork, resulting in economic losses for the relevant miners and the majority of Bitcoin users.

Miners who manually set the block version number should pay attention

The default setting of Bitcoin Core will automatically set the block version according to the requirements of BIP9. However, we have noticed that some miners will manually set the block version number. We strongly recommend not to manually set the block version number because it will bring risks to the Bitcoin system.

If a miner sets a version number but does not implement the corresponding rules, it may produce invalid blocks and extend an invalid blockchain. In short, not using the default version value provided by bitcoind may cause the version number to be inconsistent with the actual operating rules.

Unlike the IsSuperMajority soft fork used by BIP33/66/65, in the design of BIP9, no block will be considered invalid due to an improper version number (according to BIP65, the minimum valid version number is 4). Therefore, miners have no incentive to manually set the block version number, because this will only bring unnecessary maintenance work and the risk of human error.

However, if you do not follow the above advice and still set the block version number manually, you must do the following. During the "lock" grace period, you must remove the version bit of the CSV, which is bit 0. For example, if your original version number is 0×20000001, you must change it to 0×20000000 before block 419328, otherwise you will cause the logs of all nodes that support BIP9 to show "unknown soft fork" warning messages. Please see the Version Bits FAQ for details.

If you do not follow the above instructions, you may cause all nodes that support BIP9 to receive upgrade alerts, which will cause great confusion.

Miners who let bitcoind set the block version number do not need to take any action. Please note that your node will still produce blocks with version number 0×20000001 before block 419328, after which bit 0 will be automatically removed.

Miners using the nSequence parameter in Coinbase transactions should pay attention

Some miners may use the nSequence parameter in the Coinbase transaction as a mining random number. After BIP68 takes effect, these miners need to pay extra attention.

If miners modify the nSequence parameter of the Coinbase transaction in any way, they must ensure that the nVersion parameter of the Coinbase transaction ( not the block version number) must be 1 or below, such as manually setting the nVersion parameter to 1. Failure to follow the above guidelines may result in the production of invalid blocks, causing a blockchain fork, resulting in economic losses for the relevant miners and the majority of Bitcoin users.

Miners using the default Coinbase transaction nSequence and nVersion values ​​provided by bitcoind do not need to take any action.

Miners using the nLockTime parameter in Coinbase transactions should pay attention

This is a relatively rare case, as the Stratum protocol does not support the use of the nLockTime parameter as a mining random number. However, any miner who does this must be aware of the new rules of BIP113.

If miners modify the nLockTime parameter of the Coinbase transaction in any way, they must ensure that the parameter value, if considered as a UNIX timestamp (i.e. greater than or equal to 500000000), must be less than the median of the timestamps of the past 11 blocks, unless the nSequence parameter of the Coinbase transaction is also 0xffffffff. Failure to follow the above guidelines may result in the production of invalid blocks, causing a blockchain fork, resulting in economic losses for the relevant miners and the majority of Bitcoin users.

Miners using the default Coinbase transaction nLockTime value provided by bitcoind do not need to take any action.