mirrors/bitcoin-bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-01-18 13:26:08 +01:00
Code Issues Projects Releases Wiki Activity

BIP8: clarify timeoutheight behaviour and requirements

Browse Source 
When lockinontimeout is true, we don't transition directly from STARTED
to LOCKED_IN, so don't imply that we do.

If startheight or timeoutheight are not on a retarget boundary, they
behave as if they had been rounded up to the next retarget boundary,
so to keep things simple, require them to be at a boundary.

If timeoutheight is less than two retarget periods later than startheight,
behaviour when lockinontimeout is true (one retarget period of STARTED,
one of MUST_SIGNAL, one of LOCKED_IN, then ACTIVE) will not match
behaviour when lockinontimeout is false (one retarget period of STARTED,
then either LOCKED_IN or FAILED), so disallow that as well.
This commit is contained in:
Anthony Towns 2020-10-17 17:24:10 +10:00
parent 0f683f71f5
commit b6b5b92337
1 changed files with 3 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
bip-0008.mediawiki
View File

@ -53,6 +53,8 @@ The following guidelines are suggested for selecting these parameters for a soft
A later deployment using the same bit is possible as long as the startheight is after the previous one's
timeoutheight or activation, but it is discouraged until necessary, and even then recommended to have a pause in between to detect buggy software.
'''startheight''' and '''timeoutheight''' must be an exact multiple of 2016 (ie, at a retarget boundary), and '''timeoutheight''' must be at least 4096 blocks (2 retarget intervals) after '''startheight'''.
===States===
With each block and soft fork, we associate a deployment state. The possible states are:
@ -88,7 +90,7 @@ For flexibility, during the LOCKED_IN phase only, this rule does NOT require the
<img src="bip-0008/states.png" align="middle"></img>
During the STARTED state if the '''lockinontimeout''' is set to true, the state will transition to LOCKED_IN when '''timeoutheight''' is reached.
Note that when '''lockinontimeout''' is true, the LOCKED_IN state will be reached no later than at a height of '''timeoutheight''', and ACTIVE will be reached no later than at a height of '''timeoutheight + 2016'''.
The genesis block has state DEFINED for each deployment, by definition.