diff options
Diffstat (limited to 'bip-0008.mediawiki')
| -rw-r--r-- | bip-0008.mediawiki | 30 |
1 files changed, 19 insertions, 11 deletions
diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki index 7030a20..d5cb191 100644 --- a/bip-0008.mediawiki +++ b/bip-0008.mediawiki @@ -79,12 +79,13 @@ for the purposes of this proposal, and support two future upgrades for different When a block nVersion does not have top bits 001, it is treated as if all bits are 0 for the purposes of deployments. +Miners should continue setting the bit in LOCKED_IN phase so uptake is visible, though this has no effect on consensus rules. + ===New consensus rules=== The new consensus rules for each soft fork are enforced for each block that has ACTIVE state. -During the MUST_SIGNAL and LOCKED_IN phases, blocks that fail to signal are invalid. -For flexibility, during the LOCKED_IN phase only, this rule does NOT require the top 3 bits to be set any particular way. +During the MUST_SIGNAL phase, if '''(2016 - threshold)''' blocks in the retarget period have already failed to signal, any further blocks that fail to signal are invalid. ===State transitions=== @@ -176,16 +177,23 @@ block, indexed by its parent. ===Mandatory signalling=== -Blocks received while in the MUST_SIGNAL and LOCKED_IN phases must be checked to ensure that they signal. For example: +Blocks received while in the MUST_SIGNAL phase must be checked to ensure that they signal as required. For example: if (GetStateForBlock(block) == MUST_SIGNAL) { - if ((block.nVersion & 0xE0000000) != 0x20000000 || ((block.nVersion >> bit) & 1) != 1) { - return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-must-signal"); - } - } - if (GetStateForBlock(block) == LOCKED_IN) { - if (((block.nVersion >> bit) & 1) != 1) { - return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-locked-in"); + int nonsignal = 0; + int count = 1 + (block.nHeight % 2016); + walk = block; + while (count > 0) { + --count; + if ((walk.nVersion & 0xE0000000) != 0x20000000 || ((walk.nVersion >> bit) & 1) != 1) { + ++nonsignal; + if (nonsignal + threshold > 2016) { + return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-must-signal"); + } + } else if (nonsignal == 0) { + break; + } + walk = walk.parent; } } @@ -226,7 +234,7 @@ The template Object is also extended: The "version" key of the template is retained, and used to indicate the server's preference of deployments. If versionbits is being used, "version" MUST be within the versionbits range of [0x20000000...0x3FFFFFFF]. Miners MAY clear or set bits in the block version WITHOUT any special "mutable" key, provided they are listed among the template's "vbavailable" and (when clearing is desired) NOT included as a bit in "vbrequired". -Servers MUST set bits in "vbrequired" for deployments in MUST_SIGNAL and LOCKED_IN states, to ensure blocks produced are valid. +Servers MUST set bits in "vbrequired" for deployments in MUST_SIGNAL state, to ensure blocks produced are valid. Softfork deployment names listed in "rules" or as keys in "vbavailable" may be prefixed by a '!' character. Without this prefix, GBT clients may assume the rule will not impact usage of the template as-is; typical examples of this would be when previously valid transactions cease to be valid, such as BIPs 16, 65, 66, 68, 112, and 113. |