Published on: 2015-09-30T23:41:51+00:00
In a discussion on the bitcoin-dev forum, Tier Nolan expressed his belief that the 75% rule should be maintained in softfork proposals to ensure miner compliance with new rules. Rusty Russell agreed with Nolan's point but emphasized simplicity and aligning with established dates. They proposed a solution where miners can set a bit, and if 75% of the blocks in the last 2016 blocks have the bit set, it moves to a tentative stage. If 95% of the blocks have the bit set, it moves to a locked-in stage. In the locked-in stage, miners do not set the bit for at least 10080 blocks and reject blocks that don't follow the new rule.The discussion also covered the effects of soft forks on Simplified Payment Verification (SPV) clients and buggy miners. They recommended that SPV clients monitor the version field and consider block forks when they occur. An email proposal suggested maintaining the 75% rule and outlined the process for moving through different stages based on block consensus. It also stressed the importance of including a timeout in softfork proposals and counting in blocks for accuracy.Another document proposed changing the semantics of the 'version' field in Bitcoin blocks to allow multiple backward-compatible changes to be deployed simultaneously. The version field would be interpreted as a bit vector, with each bit representing an independent change. A state would be associated with each softfork proposal, transitioning after each retarget period to locked-in, activated, or failed. The use of bit flags would enable multiple soft forks to be deployed at once.The proposed Version bits with timeout and delay suggested changes to the version field in Bitcoin blocks, allowing multiple backward-compatible changes to be deployed in parallel. Each bit in the version field represents an independent change that can be tallied every retarget period. A state is associated with each soft fork proposal, transitioning to locked-in, activated, or failed after each retarget period. The lock-in threshold determines when miners should stop setting the associated bit, and after another retarget period, the rules related to the locked-in soft fork are enforced. The proposal also highlighted the importance of including a timeout and allowing flexibility for future soft forks. This mechanism allows for multi-stage soft forks, conflicting soft forks, detection of buggy clients, and time for warnings and software upgrades.
Updated on: 2023-08-01T16:05:50.849173+00:00