You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
Copy file name to clipboardExpand all lines: bip-0008.mediawiki
+36-26Lines changed: 36 additions & 26 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -37,8 +37,8 @@ Each soft fork deployment is specified by the following per-chain parameters (fu
37
37
# 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.
38
38
# 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}.
39
39
# 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.
42
42
43
43
===Selection guidelines===
44
44
@@ -59,10 +59,10 @@ With each block and soft fork, we associate a deployment state. The possible sta
59
59
60
60
# '''DEFINED''' is the first state that each soft fork starts out as. The genesis block is by definition in this state for each deployment.
61
61
# '''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.
63
64
# '''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.
66
66
67
67
===Bit flags===
68
68
@@ -77,14 +77,13 @@ for the purposes of this proposal, and support two future upgrades for different
77
77
When a block nVersion does not have top bits 001, it is treated as if all
78
78
bits are 0 for the purposes of deployments.
79
79
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
-
84
80
===New consensus rules===
85
81
86
82
The new consensus rules for each soft fork are enforced for each block that has ACTIVE state.
87
83
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.
@@ -121,7 +120,8 @@ We remain in the initial state until we reach the start block height.
121
120
After a period in the STARTED state, we tally the bits set,
122
121
and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their
123
122
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.
125
125
126
126
Note that a block's state never depends on its own nVersion; only on that of its ancestors.
127
127
@@ -131,28 +131,22 @@ Note that a block's state never depends on its own nVersion; only on that of its
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.
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
+
181
192
===Warning mechanism===
182
193
183
194
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:
211
222
The "version" key of the template is retained, and used to indicate the server's preference of deployments.
212
223
If versionbits is being used, "version" MUST be within the versionbits range of [0x20000000...0x3FFFFFFF].
213
224
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.
215
226
216
227
Softfork deployment names listed in "rules" or as keys in "vbavailable" may be prefixed by a '!' character.
217
228
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.
0 commit comments