1
0
mirror of https://github.com/bitcoin/bips.git synced 2025-01-19 05:45:07 +01:00

BIP 8: Fix timeout logic

This commit is contained in:
Luke Dashjr 2020-06-26 17:37:50 +00:00
parent 8e906f14af
commit ef04aeca51

View File

@ -118,21 +118,16 @@ We remain in the initial state until we reach the start block height.
}
return DEFINED;
After a period in the STARTED state, if we're past the timeout, we switch to LOCKED_IN or FAILING. If not, we tally the bits set,
After a period in the STARTED state, we tally the bits set,
and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their
version numbers. The threshold is ≥1916 blocks (95% of 2016), or ≥1512 for testnet (75% of 2016).
The transition to FAILING takes precedence, as otherwise an ambiguity can arise.
There could be two non-overlapping deployments on the same bit, where the first one transitions to LOCKED_IN while the
other one simultaneously transitions to STARTED, which would mean both would demand setting the bit.
If the threshold hasn't been met, and we reach the timeout, then we either transition to LOCKED_IN state anyway (if lockinontimeout is true), or we transition to FAILING.
Note that a block's state never depends on its own nVersion; only on that of its ancestors.
case STARTED:
if (block.height >= timeoutheight) {
return (lockinontimeout == true) ? LOCKED_IN : FAILING;
int count = 0;
walk = block;
walk = block.parent;
for (i = 0; i < 2016; i++) {
walk = walk.parent;
if (walk.nVersion & 0xE0000000 == 0x20000000 && (walk.nVersion >> bit) & 1 == 1) {
@ -141,6 +136,8 @@ Note that a block's state never depends on its own nVersion; only on that of its
}
if (count >= threshold) {
return LOCKED_IN;
} else if (block.height >= timeoutheight) {
return (lockinontimeout == true) ? LOCKED_IN : FAILING;
}
return STARTED;