bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-05-12 12:03:29 +00:00
Code Issues Releases Wiki Activity

Merge pull request #1020 from ajtowns/202010-bip8-lockedin-rec

Browse Source 
BIP8: Make signalling during LOCKED_IN recommended rather than mandatory
This commit is contained in:
Luke Dashjr 2021-02-02 19:52:33 +00:00 committed by GitHub
commit 79cd91ec98
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 5 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
bip-0008.mediawiki
View File

@ -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 When a block nVersion does not have top bits 001, it is treated as if all
bits are 0 for the purposes of deployments. 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=== ===New consensus rules===
The new consensus rules for each soft fork are enforced for each block that has ACTIVE state. 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. During the MUST_SIGNAL phase, 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.
===State transitions=== ===State transitions===
@ -176,18 +177,13 @@ block, indexed by its parent.
===Mandatory signalling=== ===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 (GetStateForBlock(block) == MUST_SIGNAL) {
if ((block.nVersion & 0xE0000000) != 0x20000000 || ((block.nVersion >> bit) & 1) != 1) { if ((block.nVersion & 0xE0000000) != 0x20000000 || ((block.nVersion >> bit) & 1) != 1) {
return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-must-signal"); 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. 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.
@ -226,7 +222,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. 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]. 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". 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. 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. 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.