Skip to content

Commit da9cdd6

Browse files
ajtownsluke-jr
authored andcommitted
BIP8: replace FAILING with MUST_SIGNAL
This removes the FAILING state and adds compulsory signalling during a new MUST_SIGNAL phase during the last retarget period prior to the timeout height. This ensures that if a deployment occurs using bip8 with lockinontimeout=false and timeoutheight=N, that a later deployment using bip8 with lockinontimeout=true and timeoutheight=K, where K<N that any chain where LOCKED_IN is reached prior to height K, will be accepted as valid by nodes using either set of deployment parameters. It also ensures that the soft-fork's changed rules are only enforced on chain a retarget period after signalling indicates enforcement is expected (which was not previously the case if the FAILING to ACTIVE transition took place).
1 parent 3c63846 commit da9cdd6

File tree

4 files changed

+116
-104
lines changed

4 files changed

+116
-104
lines changed

bip-0008.mediawiki

Lines changed: 36 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -37,8 +37,8 @@ Each soft fork deployment is specified by the following per-chain parameters (fu
3737
# The '''name''' specifies a very brief description of the soft fork, reasonable for use as an identifier. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number.
3838
# The '''bit''' determines which bit in the nVersion field of the block is to be used to signal the soft fork lock-in and activation. It is chosen from the set {0,1,2,...,28}.
3939
# The '''startheight''' specifies the height of the first block at which the bit gains its meaning.
40-
# The '''timeoutheight''' specifies a block height at which the miner signalling ends. Once this height has been reached, if the soft fork has not yet locked in (excluding this block's bit state), the deployment is either considered failed on all descendants of the block (but see the exception during '''FAILING''' state), or, if '''lockinontimeout'' is true, transitions to the '''LOCKED_IN''' state.
41-
# The '''lockinontimeout''' boolean if set to true, will transition state to '''LOCKED_IN''' at timeoutheight if not already '''LOCKED_IN''' or '''ACTIVE'''.
40+
# The '''timeoutheight''' specifies a block height at which the miner signalling ends. Once this height has been reached, if the soft fork has not yet locked in (excluding this block's bit state), the deployment is considered failed on all descendants of the block.
41+
# The '''lockinontimeout''' boolean if set to true, blocks are required to signal in the final period, ensuring the soft fork has locked in by timeoutheight.
4242
4343
===Selection guidelines===
4444

@@ -59,10 +59,10 @@ With each block and soft fork, we associate a deployment state. The possible sta
5959

6060
# '''DEFINED''' is the first state that each soft fork starts out as. The genesis block is by definition in this state for each deployment.
6161
# '''STARTED''' for blocks at or beyond the startheight.
62-
# '''LOCKED_IN''' for one retarget period after the first retarget period with STARTED blocks of which at least threshold have the associated bit set in nVersion, or for one retarget period after the timeout when '''lockinontimeout''' is true.
62+
# '''MUST_SIGNAL''' for one retarget period prior to the timeout, if LOCKED_IN was not reached and '''lockinontimeout''' is true.
63+
# '''LOCKED_IN''' for one retarget period after the first retarget period with STARTED (or MUST_SIGNAL) blocks of which at least threshold have the associated bit set in nVersion.
6364
# '''ACTIVE''' for all blocks after the LOCKED_IN retarget period.
64-
# '''FAILING''' for one retarget period after the timeout, if LOCKED_IN was not reached and '''lockinontimeout''' is false.
65-
# '''FAILED''' for all blocks after the FAILING retarget period.
65+
# '''FAILED''' for all blocks after the timeoutheight if LOCKED_IN is not reached.
6666
6767
===Bit flags===
6868

@@ -77,14 +77,13 @@ for the purposes of this proposal, and support two future upgrades for different
7777
When a block nVersion does not have top bits 001, it is treated as if all
7878
bits are 0 for the purposes of deployments.
7979

80-
Miners must continue setting the bit in LOCKED_IN phase so uptake is visible and acknowledged.
81-
Blocks without the applicable bit set are invalid during this period.
82-
For flexibility, this rule does NOT require the top 3 bits to be set any particular way.
83-
8480
===New consensus rules===
8581

8682
The new consensus rules for each soft fork are enforced for each block that has ACTIVE state.
8783

84+
During the MUST_SIGNAL and LOCKED_IN phases, blocks that fail to signal are invalid.
85+
For flexibility, during the LOCKED_IN phase only, this rule does NOT require the top 3 bits to be set any particular way.
86+
8887
===State transitions===
8988

9089
<img src="bip-0008/states.png" align="middle"></img>
@@ -121,7 +120,8 @@ We remain in the initial state until we reach the start block height.
121120
After a period in the STARTED state, we tally the bits set,
122121
and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their
123122
version numbers. The threshold is ≥1916 blocks (95% of 2016), or ≥1512 for testnet (75% of 2016).
124-
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.
123+
If the threshold hasn't been met, lockinontimeout is true, and we are at the last period before the timeout, then we transition to MUST_SIGNAL.
124+
If the threshold hasn't been met and we reach the timeout, we transition directly to FAILED.
125125

126126
Note that a block's state never depends on its own nVersion; only on that of its ancestors.
127127

@@ -131,28 +131,22 @@ Note that a block's state never depends on its own nVersion; only on that of its
131131
for (i = 0; i < 2016; i++) {
132132
walk = walk.parent;
133133
if (walk.nVersion & 0xE0000000 == 0x20000000 && (walk.nVersion >> bit) & 1 == 1) {
134-
count++;
134+
++count;
135135
}
136136
}
137137
if (count >= threshold) {
138138
return LOCKED_IN;
139+
} else if (lockinontimeout && block.height + 2016 >= timeoutheight) {
140+
return MUST_SIGNAL;
139141
} else if (block.height >= timeoutheight) {
140-
return (lockinontimeout == true) ? LOCKED_IN : FAILING;
142+
return FAILED;
141143
}
142144
return STARTED;
143145
144-
If the deployment is not LOCKED_IN by the timeout (or '''lockinontimeout'''), it has a single retarget period during which it may still become active, only by unanimous signalling in every block.
145-
This state exists such that if '''lockinontimeout''' is set to true later, it remains compatible with the original deployment.
146+
If we have finished a period of MUST_SIGNAL, we transition directly to LOCKED_IN.
146147

147-
case FAILING:
148-
walk = block;
149-
for (i = 0; i < 2016; i++) {
150-
walk = walk.parent;
151-
if (walk.nVersion & 0xE0000000 == 0x20000000 && ((walk.nVersion >> bit) & 1) != 1) {
152-
return FAILED;
153-
}
154-
}
155-
return ACTIVE;
148+
case MUST_SIGNAL:
149+
return LOCKED_IN;
156150
157151
After a retarget period of LOCKED_IN, we automatically transition to ACTIVE.
158152

@@ -178,6 +172,23 @@ current retarget period (i.e. up to and including its ancestor with height block
178172
it is possible to implement the mechanism above efficiently and safely by caching the resulting state of every multiple-of-2016
179173
block, indexed by its parent.
180174

175+
===Mandatory signalling===
176+
177+
Blocks received while in the MUST_SIGNAL and LOCKED_IN phases must be checked to ensure that they signal. For example:
178+
179+
if (GetStateForBlock(block) == MUST_SIGNAL) {
180+
if ((block.nVersion & 0xE0000000) != 0x20000000 || ((block.nVersion >> bit) & 1) != 1) {
181+
return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-must-signal");
182+
}
183+
}
184+
if (GetStateForBlock(block) == LOCKED_IN) {
185+
if (((block.nVersion >> bit) & 1) != 1) {
186+
return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-locked-in");
187+
}
188+
}
189+
190+
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.
191+
181192
===Warning mechanism===
182193

183194
To support upgrade warnings, an extra "unknown upgrade" is tracked, using the "implicit bit" mask = (block.nVersion & ~expectedVersion) != 0. Mask will be non-zero whenever an unexpected bit is set in nVersion. Whenever LOCKED_IN for the unknown upgrade is detected, the software should warn loudly about the upcoming soft fork. It should warn even more loudly after the next retarget period (when the unknown upgrade is in the ACTIVE state).
@@ -211,7 +222,7 @@ The template Object is also extended:
211222
The "version" key of the template is retained, and used to indicate the server's preference of deployments.
212223
If versionbits is being used, "version" MUST be within the versionbits range of [0x20000000...0x3FFFFFFF].
213224
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".
214-
Servers MUST set bits in "vbrequired" for deployments in LOCKED_IN state, to ensure blocks produced are valid.
225+
Servers MUST set bits in "vbrequired" for deployments in MUST_SIGNAL and LOCKED_IN states, to ensure blocks produced are valid.
215226

216227
Softfork deployment names listed in "rules" or as keys in "vbavailable" may be prefixed by a '!' character.
217228
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.
@@ -225,9 +236,8 @@ https://github.com/bitcoin/bitcoin/compare/master...luke-jr:bip8
225236

226237
==Contrasted with BIP 9==
227238

228-
* The '''lockinontimeout''' flag is added. BIP 9 would only transition to the FAILED state when timeout was reached.
239+
* The '''lockinontimeout''' flag is added, providing a way to guarantee transition to LOCKED_IN.
229240
* Block heights are used for the deployment monotonic clock, rather than median-time-past.
230-
* The last-ditch effort during a new FAILING state is added to allow '''lockinontimeout''' to be safely set after the initial deployment.
231241
232242
==Backwards compatibility==
233243

bip-0008/states.dot

Lines changed: 13 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -1,34 +1,34 @@
11
digraph {
22
rankdir=TD;
33

4-
node [style="rounded,filled,bold", shape=box, fixedsize=true, width=1.3, fontname="Arial"];
4+
node [style="rounded,filled,bold", shape=box, fixedsize=true, width=1.5, fontname="Arial"];
55

66
edge [weight = 100];
77
"DEFINED" -> "STARTED" [label="height >= start_height"];
8-
"STARTED" -> "FAILING" [label="height >= timeoutheight AND NOT lockinontimeout"];
9-
"STARTED" -> "LOCKED_IN" [label="(height < timeoutheight AND threshold reached)\nOR\n(height >= timeoutheight AND lockinontimeout)"];
8+
"STARTED" -> "MUST_SIGNAL" [label="height + 2016 >= timeoutheight AND lockinontimeout"];
9+
"STARTED" -> "FAILED" [label="height >= timeoutheight\nAND\nNOT lockinontimeout"];
1010
"LOCKED_IN" -> "ACTIVE" [label="always"];
11-
"FAILING" -> "FAILED" [label="NOT all blocks signal"];
11+
"MUST_SIGNAL" -> "LOCKED_IN" [label="always"];
1212

1313
edge [weight = 1];
14-
"FAILING" -> "ACTIVE" [label="all blocks signal"];
14+
"STARTED" -> "LOCKED_IN" [label="height < timeoutheight\nAND\nthreshold reached"];
15+
16+
"FAILED" -> "LOCKED_IN" [style=invis];
1517

1618
"DEFINED":sw -> "DEFINED":nw;
1719
"STARTED":sw -> "STARTED":nw;
1820
"ACTIVE":sw -> "ACTIVE":nw;
1921
"FAILED":sw -> "FAILED":nw;
2022

2123
"STARTED" [fillcolor="#a0a0ff"];
22-
23-
"FAILING" [fillcolor="#ffffa0"];
24+
"MUST_SIGNAL" [fillcolor="#a0a0ff"];
2425
"LOCKED_IN" [fillcolor="#ffffa0"];
25-
"ACTIVE" [fillcolor="#a0ffa0", shape=box];
26-
"FAILED" [fillcolor="#ffa0a0", shape=box];
27-
28-
"ACTIVE" -> "FAILED" [style=invis];
26+
"ACTIVE" [fillcolor="#a0ffa0"];
27+
"FAILED" [fillcolor="#ffa0a0"];
2928

30-
{ rank=same; "STARTED" "FAILING" }
31-
{ rank=sink; "ACTIVE" "FAILED" }
29+
{ rank=same; "STARTED" "MUST_SIGNAL" }
30+
{ rank=same; "FAILED" "LOCKED_IN" }
31+
{ rank=sink; "ACTIVE" }
3232
}
3333

3434

bip-0008/states.png

-1.91 KB
Loading

0 commit comments

Comments
 (0)