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 #1021 from ajtowns/202010-bip8-mustsignal-to-threshold

Browse Source 
BIP8: allow some MUST_SIGNAL blocks to not signal
This commit is contained in:
Luke Dashjr 2021-02-02 20:30:41 +00:00 committed by GitHub
commit 0aa8c3ae02
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 16 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
bip-0008.mediawiki
View File

@ -85,7 +85,7 @@ Miners should continue setting the bit in LOCKED_IN phase so uptake is visible,
The new consensus rules for each soft fork are enforced for each block that has ACTIVE state.
During the MUST_SIGNAL phase, blocks that fail to signal are invalid.
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===
@ -177,12 +177,24 @@ block, indexed by its parent.
===Mandatory signalling===
Blocks received while in the MUST_SIGNAL phase 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) {
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;
}
}
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.