BIP8: Make signalling during LOCKED_IN recommended rather than mandatory

Author: ajtowns

bip-0008.mediawiki

@@ -77,12 +77,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, blocks that fail to signal are invalid.
 
 ===State transitions===
 
@@ -174,18 +175,13 @@ 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. 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");
-        }
-    }
 
 Implementations should be careful not to ban peers that send blocks that are invalid due to not signalling (or blocks that build on those blocks), as that would allow an incompatible chain that is only briefly longer than the compliant chain to cause a split of the p2p network. If that occurred, nodes that have not set ''lockinontimeout'' may not see new blocks in the compliant chain, and thus not reorg to it at the point when it has more work, and would thus not be following the valid chain with the most work.
 
@@ -224,7 +220,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.