BIP 009: Minor revision to extend bit into lockin period.

As discussed here:
	http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011275.html

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

1 files changed, 4 insertions, 3 deletions

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index c17ca15..b160810 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -37,14 +37,15 @@ retarget period.
 Software which supports the change should begin by setting B in all blocks
 mined until it is resolved.
 
-    if (BState == defined) {
+    if (BState != activated && BState != failed) {
         SetBInBlock();
     }
 
 '''Success: Lock-in Threshold'''
 If bit B is set in 1916 (1512 on testnet) or
 more of the 2016 blocks within a retarget period, it is considered
-''locked-in''.  Miners should stop setting bit B.
+''locked-in''.  Miners should continue setting bit B, so uptake is
+visible.
 
     if (NextBlockHeight % 2016 == 0) {
         if (BState == defined && Previous2016BlocksCountB() >= 1916) {
@@ -57,7 +58,7 @@ more of the 2016 blocks within a retarget period, it is considered
 The consensus rules related to ''locked-in'' soft fork will be enforced in
 the second retarget period; ie. there is a one retarget period in
 which the remaining 5% can upgrade.  At the that activation block and
-after, the bit B may be reused for a different soft fork.
+after, miners should stop setting bit B, which may be reused for a different soft fork.
 
     if (BState == locked-in && NextBlockHeight == BActiveHeight) {
         BState = activated;