diff options
Diffstat (limited to 'bip-0008.mediawiki')
| -rw-r--r-- | bip-0008.mediawiki | 34 |
1 files changed, 22 insertions, 12 deletions
diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki index dc2291a..d5cb191 100644 --- a/bip-0008.mediawiki +++ b/bip-0008.mediawiki @@ -53,6 +53,8 @@ The following guidelines are suggested for selecting these parameters for a soft A later deployment using the same bit is possible as long as the startheight is after the previous one's timeoutheight or activation, but it is discouraged until necessary, and even then recommended to have a pause in between to detect buggy software. +'''startheight''' and '''timeoutheight''' must be an exact multiple of 2016 (ie, at a retarget boundary), and '''timeoutheight''' must be at least 4096 blocks (2 retarget intervals) after '''startheight'''. + ===States=== With each block and soft fork, we associate a deployment state. The possible states are: @@ -77,18 +79,19 @@ 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=== <img src="bip-0008/states.png" align="middle"></img> -During the STARTED state if the '''lockinontimeout''' is set to true, the state will transition to LOCKED_IN when '''timeoutheight''' is reached. +Note that when '''lockinontimeout''' is true, the LOCKED_IN state will be reached no later than at a height of '''timeoutheight''', and ACTIVE will be reached no later than at a height of '''timeoutheight + 2016'''. The genesis block has state DEFINED for each deployment, by definition. @@ -174,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; } } @@ -224,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. |