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 AECB3FE9 for ; Sun, 7 Feb 2016 15:19:37 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [106.187.51.212]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3388D90 for ; Sun, 7 Feb 2016 15:19:37 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.84 #2 (Debian)) id 1aSR7d-0000Wi-5q for ; Mon, 08 Feb 2016 01:19:34 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Mon, 08 Feb 2016 01:19:27 +1000 Date: Mon, 8 Feb 2016 01:19:27 +1000 From: Anthony Towns To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20160207151927.GA14750@sapphire.erisian.com.au> References: <1804222.7gVHPiWqto@kiwi> <201602062046.40193.luke@dashjr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Score: -1.9 X-Spam-Score-int: -18 X-Spam-Bar: - X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, UNPARSEABLE_RELAY 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: Increase block size limit to 2 megabytes 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: Sun, 07 Feb 2016 15:19:37 -0000 On Sun, Feb 07, 2016 at 09:16:02AM -0500, Gavin Andresen via bitcoin-dev wrote: > There will be approximately zero percentage of hash power left on the > weaker branch of the fork, based on past soft-fork adoption by miners (they > upgrade VERY quickly from 75% to over 95%). The stated reasoning for 75% versus 95% is "because it gives "veto power" to a single big solo miner or mining pool". But if a 20% miner wants to "veto" the upgrade, with a 75% threshold, they could instead simply use their hashpower to vote for an upgrade, but then not mine anything on the new chain. At that point there'd be as little as 55% mining the new 2MB chain with 45% of hashpower remaining on the old chain. That'd be 18 minute blocks versus 22 minute blocks, which doesn't seem like much of a difference in practice, and at that point hashpower could plausibly end up switching almost entirely back to the original consensus rules prior to the grace period ending. With a non-consensus fork, I think you need to expect people involved to potentially act in ways that aren't very gentlemanly, and guard against it if you want the fork to be anything other than a huge mess. Cheers, aj