From fd189fdccd7e3c3caef01313df9c36f621af6d04 Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Fri, 2 Oct 2015 10:50:18 +0930 Subject: 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 --- bip-0009.mediawiki | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'bip-0009.mediawiki') 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; -- cgit v1.2.3