Merge pull request #354 from sipa/bip9fixes

Small improvements to BIP9

1 files changed, 14 insertions, 10 deletions

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index 49e6adf..509a8a9 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -28,14 +28,18 @@ Each soft fork deployment is specified by the following per-chain parameters (fu
 # The '''starttime''' specifies a minimum median time past of a block at which the bit gains its meaning.
 # The '''timeout''' specifies a time at which the deployment is considered failed. If the median time past of a block >= timeout and the soft fork has not yet locked in (including this block's bit state), the deployment is considered failed on all descendants of the block.
 
-The starttime should be set to some date in the future, coordinates with software release date. This is to prevent
-triggers as a result of parties running pre-release software. The timeout should be set a reasonable time after the
-starttime. A later deployment using the same bit is possible as long as the starttime is after the previous one's
-timeout or activation, though it is recommended to have a pause in between to detect buggy software.
+===Selection guidelines===
 
-Setting the timeout to 3 years after the starttime allows at least 9 new deployments per year.
+The following guidelines are suggested for selecting these parameters for a soft fork:
 
-====States====
+# '''bit''' should be selected such that no two concurrent softforks use the same bit.
+# '''starttime''' should be set to some date in the future, approximately one month after a software release date including the soft fork.  This allows for some release delays, while preventing triggers as a result of parties running pre-release software.
+# '''timeout''' should be 1 year (31536000 seconds) after starttime.
+
+A later deployment using the same bit is possible as long as the starttime is after the previous one's
+timeout or activation, but it is discouraged until necessary, and even then recommended to have a pause in between to detect buggy software.
+
+===States===
 
 With each block and soft fork, we associate a deployment state. The possible states are:
 
@@ -45,7 +49,7 @@ With each block and soft fork, we associate a deployment state. The possible sta
 # '''ACTIVE''' for all blocks after the LOCKED_IN retarget period.
 # '''FAILED''' for one retarget period past the timeout time, if LOCKED_IN was not reached.
 
-====Bit flags====
+===Bit flags===
 
 Blocks in the STARTED state get an nVersion whose bit position bit is set to 1. The top 3 bits of such blocks must be
 001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive.
@@ -59,11 +63,11 @@ bits are 0 for the purposes of deployments.
 Miners should continue setting the bit in LOCKED_IN phase so uptake is visible, though this has no effect on
 consensus rules.
 
-====New consensus rules====
+===New consensus rules===
 
 The new consensus rules for each soft fork are enforced for each block that has ACTIVE state.
 
-====State transitions====
+===State transitions===
 
 <img src="bip-0009/states.png" align="middle"></img>
 
@@ -149,7 +153,7 @@ current retarget period (i.e. up to and including its ancestor with height block
 it is possible to implement the mechanism above efficiently and safely by caching the resulting state of every multiple-of-2016
 block, indexed by its parent.
 
-====Warning mechanism====
+===Warning mechanism===
 
 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).