BIP9: More explicit recommendations on values.

Basically the same thing reworded as a checklist, with 3 years turned into 1,
and suggesting a 1 month delay after expected deployment date.

Signed-off-by: Rusty Russell <[email protected]>

bip-0009.mediawiki

@@ -28,12 +28,16 @@ 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===
+
+The following guidelines are suggested for selecting these parameters for a soft fork:
 
-Setting the timeout to 3 years after the starttime allows at least 9 new deployments per year.
+# '''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 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, though it is recommended to have a pause in between to detect buggy software.
 
 ===States===