Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 581A31EA1 for ; Wed, 30 Sep 2015 02:30:43 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from ozlabs.org (ozlabs.org [103.22.144.67]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A27D8130 for ; Wed, 30 Sep 2015 02:30:42 +0000 (UTC) Received: by ozlabs.org (Postfix, from userid 1011) id E2F7C140B0E; Wed, 30 Sep 2015 12:30:39 +1000 (AEST) From: Rusty Russell To: "Bitcoin Dev" User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 30 Sep 2015 12:00:23 +0930 Message-ID: <87zj04fxkw.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Pieter Wuille Subject: [bitcoin-dev] Versionbits BIP (009) minor revision proposal. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 02:30:43 -0000 Hi all, Pieter and Eric pointed out that the current BIP has miners turning off the bit as soon as it's locked in (75% testnet / 95% mainnet). It's better for them to keep setting the bit until activation (2016 blocks later), so network adoption is visible. I'm not proposing another suggestion, though I note it for future: miners keep setting the bit for another 2016 blocks after activation, and have a consensus rule that rejects blocks without the bit. That would "force" upgrades on those last miners. I feel we should see how this works first. Cheers, Rusty. 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;