Author: Karl Johan Alm 2017-06-07 01:11:25
Published on: 2017-06-07T01:11:25+00:00
James Hilliard has proposed a new option, known as split protection soft fork, that miners can use to prevent a chain split ahead of the August 1st BIP148 activation date. This is due to the SegWit2x agreement being too slow to activate SegWit mandatory signalling ahead of BIP148 using BIP91. Split protection soft fork is essentially BIP91 but uses BIP8 instead of BIP9 with a lower activation threshold and immediate mandatory signalling lock-in. This allows for a majority of miners to activate mandatory SegWit signalling and prevent a potential chain split ahead of BIP148 activation. This BIP allows miners to respond to market forces quickly ahead of BIP148 activation by signalling for splitprotection. Any miners already running BIP148 should be encouraged to use splitprotection. The document specifies a coordination mechanism for a simple majority of miners to prevent a chain split ahead of BIP148 activation. Due to time constraints, unless immediately deployed, BIP91 will likely not be able to enforce mandatory signalling of segwit before the Aug 1st activation of BIP148. This BIP provides a method for rapid miner activation of SegWit mandatory signalling ahead of the BIP148 activation date. While this BIP is active, all blocks must set the nVersion header top 3 bits to 001 together with bit field (1 existing segwit deployment). Blocks that do not signal as required will be rejected. This deployment is compatible with the existing "segwit" bit 1 deployment scheduled between midnight November 15th, 2016 and midnight November 15th, 2017. This deployment is also compatible with the existing BIP148 deployment. Miners will need to upgrade their nodes to support splitprotection otherwise they may build on top of an invalid block.Historically we have used IsSuperMajority() to activate soft forks such as BIP66 which has a mandatory signalling requirement for miners once activated, this ensures that miners are aware of new rules being enforced. This technique can be leveraged to lower the signalling threshold of a soft fork while it is in the process of being deployed in a backwards compatible way. By orphaning non-signalling blocks during the BIP9 bit 1 "segwit" deployment, this BIP can cause the existing "segwit" deployment to activate without needing to release a new deployment.
Updated on: 2023-06-12T01:55:40.713480+00:00