From 760e2a15bf04f888ee6c40f90d70ceac25c315c4 Mon Sep 17 00:00:00 2001 From: Pieter Wuille Date: Wed, 2 Mar 2016 19:19:42 +0100 Subject: Make the threshold independent from the deployment --- bip-0009.mediawiki | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'bip-0009.mediawiki') 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. -- cgit v1.2.3