Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8BEA41358 for ; Wed, 16 Sep 2015 20:20:09 +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 3388B1D9 for ; Wed, 16 Sep 2015 20:20:08 +0000 (UTC) Received: by ozlabs.org (Postfix, from userid 1011) id 28773140518; Thu, 17 Sep 2015 06:20:05 +1000 (AEST) From: Rusty Russell To: Tier Nolan In-Reply-To: References: <87mvwqb132.fsf@rustcorp.com.au> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Thu, 17 Sep 2015 05:49:22 +0930 Message-ID: <87r3lyjewl.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: Bitcoin Dev Subject: Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay. 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, 16 Sep 2015 20:20:09 -0000 Tier Nolan via bitcoin-dev writes: > On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> '''States''' >> With every softfork proposal we associate a state BState, which begins >> at ''defined'', and can be ''locked-in'', ''activated'', >> or ''failed''. Transitions are considered after each >> retarget period. >> > > I think the 75% rule should be maintained. It confirms that miners who are > setting the bit are actually creating blocks that meet the new rule (though > it doesn't check if they are enforcing it). I couldn't see a use for it, since partial enforcement of a soft fork is pretty useless. Your point about checking that miners are actually doing it is true, though all stuff being forked in in future will be nonstandard AFAICT. I bias towards simplicity for this. > What is the reason for aligning the updated to the difficulty window? Miners already have that date in their calendar, so prefer to anchor to that. > *defined* > Miners set bit > If 75% of blocks of last 2016 have bit set, goto tentative > > > *tentative* > Miners set bit > Reject blocks that have bit set that don't follow new rule > If 95% of blocks of last 2016 have bit set, goto locked-in > > > *locked-in* > > Point of no return > Miners still set bit > Reject blocks that have bit set that don't follow new rule > After 2016 blocks goto notice OK, *that* variant makes perfect sense, and is no more complex, AFAICT. So, there's two weeks to detect bad implementations, then you everyone stops setting the bit, for later reuse by another BIP. > I think counting in blocks is easier to be exact here. Easier for code, but harder for BIP authors. > If two bits were allocated per proposal, then miners could vote against > forks to recover the bits. If 25% of the miners vote against, then that > kills it. You need a timeout: an ancient (non-mining, thus undetectable) node should never fork itself off the network because someone reused a failed BIP bit. > In the rationale, it would be useful to discuss effects on SPV clients and > buggy miners. > > SPV clients should be recommended to actually monitor the version field. SPV clients don't experience a security change when a soft fork occurs? They're already trusting miners. Greg pointed out that soft forks tend to get accompanied by block forks across activation, but SPV clients should *definitely* be taking those into account whenever they happen, right? Thanks! Rusty.