From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 42B8E1510 for ; Fri, 18 Sep 2015 23:24:41 +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 CE7FA26A for ; Fri, 18 Sep 2015 23:24:39 +0000 (UTC) Received: by ozlabs.org (Postfix, from userid 1011) id 1940F140AF3; Sat, 19 Sep 2015 09:24:37 +1000 (AEST) From: Rusty Russell To: Tier Nolan , Bitcoin Dev In-Reply-To: References: <87mvwqb132.fsf@rustcorp.com.au> <87r3lyjewl.fsf@rustcorp.com.au> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Fri, 18 Sep 2015 07:27:51 +0930 Message-ID: <87h9msiu8w.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DATE_IN_PAST_24_48, 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 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: Fri, 18 Sep 2015 23:24:41 -0000 Tier Nolan via bitcoin-dev writes: > The advantage of enforcing the rule when 75% is reached (but only for > blocks with the bit set) is that miners get early notification that they > have implemented the rule incorrectly. They might produce blocks that > they think are fine, but which aren't. Indeed. There are three believable failure possibilties: 1) You don't implement the rule at all, and don't set the bit. 2) You implement it and set bit, but think some valid block is invalid. 3) You implement it and set bit, but think some invalid block is valid. #1 is by far the most common, and the proposal is designed so they *always* get ~2 weeks warning before those drop to SPV security. Assuming the mining majority isn't buggy (otherwise, it's arguably not a bug but a feature!) #2 is the worst case: some miners fork off and don't rejoin. So there is a slight advantage in doing this early: those buggy miners no longer contribute to the 95% threshold. But that's outweighed IMHO by: 1) We would need another delay at 75% so #1 nodes can upgrade. 2) The new feature won't be exercised much before impliciation, since it's useless before then, so it might not find bugs anyway. In conclusion, I'm not convinced by the extra complexity. Cheers, Rusty.