Make the threshold independent from the deployment

1 files changed, 3 insertions, 2 deletions

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index e6be63a..6c65c8c 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -25,7 +25,6 @@ In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule
 Each soft fork deployment is specified by the following per-chain parameters (further elaborated below):
 
 # The '''bit''' determines which bit in the nVersion field of the block is to be used to signal the soft fork lock-in and activation. It is chosen from the set {0,1,2,...,28}.
-# The '''threshold''' specifies how many blocks within a single retarget period (2016 blocks) must have the bit set before we lock in the deployment. The recommended value is 1916 (95%) for mainnet and 1512 (75%) for testnets.
 # 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.
 
@@ -95,7 +94,9 @@ refers to the median nTime of the 11 blocks preceeding a given block (referred t
             return DEFINED;
 
 After a period in the STARTED state, if we're past the timeout, we switch to FAILED. If not, we tally the bits set,
-and transition to LOCKED_IN if we pass the threshold. The transaction to FAILED takes precendence, as otherwise there
+and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their
+version numbers. The threshold is 1915 blocks (95% of 2016), or 1512 on testnet (75% of 2016).
+The transaction to FAILED takes precendence, as otherwise there
 could be two non-overlapping deployments on the same bit, where the first one transitions to LOCKED_IN and the other
 to STARTED, which would mean both would demand setting the bit. Note that a block's state never depends on its own
 nVersion; only on that of its ancestors.