Date: Mon, 8 Feb 2016 01:19:27 +1000
From: Anthony Towns <aj@erisian.com.au>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20160207151927.GA14750@sapphire.erisian.com.au>
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
	<CABm2gDoungCbB22_SKHcedBKegWEPpjeM2woxLGchC4=om8BrA@mail.gmail.com>
	<1804222.7gVHPiWqto@kiwi> <201602062046.40193.luke@dashjr.org>
	<CABsx9T0N_TBbmy3xr-mqNDdKVF_3_QHYA1W2ttsZBQnt4dWxgw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABsx9T0N_TBbmy3xr-mqNDdKVF_3_QHYA1W2ttsZBQnt4dWxgw@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
 megabytes
Precedence: list

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