Merge pull request #1019 from ajtowns/202010-bip8-trivial

BIP8: clarify timeoutheight behaviour and requirements

1 files changed, 3 insertions, 1 deletions

diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki
index dc2291a..7030a20 100644
--- a/bip-0008.mediawiki
+++ b/bip-0008.mediawiki
@@ -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.