User Activated Soft Fork Split Protection

Summary:

James Hilliard has proposed a new option for miners called "splitprotection" to prevent a chain split ahead of the Aug 1st BIP148 activation date. The splitprotection soft fork is essentially BIP91 but using BIP8 instead of BIP9 with a lower activation threshold and immediate mandatory signalling lock-in. This allows for rapid miner activation of SegWit mandatory signalling ahead of the BIP148 activation date.Jared Lee Richardson raised concerns about the psychology of giving BIP148 a sense of safety that may not be valid. Without several more steps, BIP148 is definitely on track to be a risky chainsplit, and without segwit2x it will almost certainly be a small minority chain. He believes that it may provide a false sense of safety for BIP148 that currently does not exist and should not as it is a chainsplit.James Hilliard argues that the biggest risk of BIP148 is an extended chain split, and this BIP provides a way for a simple majority of miners to eliminate that risk. This BIP also allows miners to signal their intention to run BIP148 in order to prevent a chain split.The proposed BIP can cause the existing "segwit" deployment to activate without needing to release a new deployment by orphaning non-signalling blocks during the BIP9 bit 1 "segwit" deployment. As we approach BIP148 activation, it may be desirable for a majority of miners to have a method that will ensure that there is no chain split.The document is proposing a Bitcoin Improvement Proposal (BIP) that can be used to lower the signalling threshold of a soft fork while it is being deployed in a backwards compatible way. This BIP uses a mandatory signalling requirement for miners, which ensures that miners are aware of new rules being enforced. Additionally, a BIP8 style timeout is implemented to ensure that this BIP is compatible with BIP148 and that BIP148 compatible mandatory signalling activates regardless of miner signalling levels.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. The proposal is compatible with the existing "segwit" bit 1 deployment scheduled between midnight November 15th, 2016 and midnight November 15th, 2017.The references include a mailing list discussion and links to various Bitcoin Improvement Proposals such as BIP9 Version bits with timeout and delay, BIP16 Pay to Script Hash, BIP91 Reduced threshold Segwit MASF, BIP141 Segregated Witness (Consensus layer), BIP143 Transaction Signature Verification for Version 0 Witness Program, BIP147 Dealing with dummy stack element malleability, BIP148 Mandatory activation of segwit deployment, BIP149 Segregated Witness (second deployment), and Segwit benefits. The document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.

Updated on: 2023-06-12T01:55:22.392366+00:00