Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gnomon.org.uk
	designates 93.93.131.22 as permitted sender)
	client-ip=93.93.131.22; envelope-from=roy@gnomon.org.uk;
	helo=darla.gnomon.org.uk; 
Date: Sat, 20 Jun 2015 21:07:53 +0100
From: Roy Badami <roy@gnomon.org.uk>
To: Pieter Wuille <pieter.wuille@gmail.com>
Message-ID: <20150620200751.GW13473@giles.gnomon.org.uk>
References: <CAPg+sBijQ0Q9U00hUaotYujqW8M+v1ED+PV+ap2g7b0Z4=RNSA@mail.gmail.com>
	<CAPg+sBhb6TyS=Bz4chLixw4Qc0Q1w6VdW-YTHZ-O_fyfvCJ+6Q@mail.gmail.com>
	<20150620184250.GV13473@giles.gnomon.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150620184250.GV13473@giles.gnomon.org.uk>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Hard fork via miner vote
Precedence: list

> I just wish that half as much energy had gone into discussing
> whether we want a 100% supermajority or a 99% supermajority or an
> 80% supermajority, as has gone into discussing whether we want 1MB
> blocks or 8MB blocks or 20MB blocks.

And I understand that Gavin is now proposing that a 75% supermajority
should be enough.  This constantly reducing threshold worries me
greatly.

There is a risk that we get a situation where a stable amount of
hashing power somewhat over 75% (say 80%) accepts the fork - and
therefore triggers it - but both a significant minority (say 20%) of
hashrate rejects it *and* the economic majority rejects it.

I'm not saying this is a likely outcome - indeed I hope it's not - but
it is a _possible_ outcome.  Ok, the chain that the economic marjority
is using will have a bit of a temporary crisis due to 50 minute block
times, but it will recover in a few weeks as difficulty adjusts.  And,
in the worst case, you end up with two competing semi-stable
ecosystems both claiming to be 'the real Bitcoin'.

My fear is that in that situation it could take an extended period -
perhaps many months - for one fork to clearly win and the other fork
to lose support (or at least lose sufficient support to be relegated
to altcoin status).  I think such an extended period of uncertainty
would be the ultimate worst case scenario for Bitcoin.  It _probably_
wouldn't be fatal to Bitcoin, but it would certainly be far worse for
Bitcoin than getting the blocksize wrong even by an order of magnitude
(in either direction).  Therefore if we can design the hardfork
mechanism to make such an outcome impossible, I believe we really need
to.

roy