Received-SPF: pass (sog-mx-4.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 19:42:51 +0100
From: Roy Badami <roy@gnomon.org.uk>
To: Pieter Wuille <pieter.wuille@gmail.com>
Message-ID: <20150620184250.GV13473@giles.gnomon.org.uk>
References: <CAPg+sBijQ0Q9U00hUaotYujqW8M+v1ED+PV+ap2g7b0Z4=RNSA@mail.gmail.com>
	<CAPg+sBhb6TyS=Bz4chLixw4Qc0Q1w6VdW-YTHZ-O_fyfvCJ+6Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPg+sBhb6TyS=Bz4chLixw4Qc0Q1w6VdW-YTHZ-O_fyfvCJ+6Q@mail.gmail.com>
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

As I've observed before, Gavin originally advocated either a 99% or
100% buy in by miners for a hard fork to trigger.

https://gist.github.com/gavinandresen/2355445

I don't understand why people (Gavin included) now seem to favour a
much more modest supermajority except perhaps that they believe that
that level of consensus is unachievable.

FWIW I'm in favour of a block size increase.  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.  (So thank you, Pieter, for raising this.)

roy

On Sat, Jun 20, 2015 at 07:13:06PM +0200, Pieter Wuille wrote:
> Hello all,
> 
> I've seen ideas around hard fork proposals that involve a block version
> vote (a la BIP34, BIP66, or my more recent versionbits BIP draft). I
> believe this is a bad idea, independent of what the hard fork itself is.
> 
> Ultimately, the purpose of a hard fork is asking the whole community to
> change their full nodes to new code. The purpose of the trigger mechanism
> is to establish when that has happened.
> 
> Using a 95% threshold, implies the fork can happen when at least 5% of
> miners have not upgraded, which implies some full nodes have not (as miners
> are nodes), and in addition, means the old chain can keep growing too,
> confusing old non-miner nodes as well.
> 
> Ideally, the fork should be scheduled when one is certain nodes will have
> upgraded, and the risk for a fork will be gone. If everyone has upgraded,
> no vote is necessary, and if nodes have not, it remains risky to fork them
> off.
> 
> I understand that, in order to keep humans in the loop, you want an
> observable trigger mechanism, and a hashrate vote is an easy way to do
> this. But at least, use a minimum timestamp you believe to be reasonable
> for upgrade, and a 100% threshold afterwards. Anything else guarantees that
> your forking change happens *knowingly* before the risk is gone.
> 
> You may argue that miners would be asked to - and have it in their best
> interest - to not actually make blocks that violate the changed rule before
> they are reasonably sure that everyone has upgraded. That is possible, but
> it does not gain you anything over just using a 100% threshold, as how
> would they be reasonably sure everyone has upgraded, while blocks creater
> by non-upgraded miners are still being created?
> 
> TL;DR: use a timestamp switchover for a hard fork, or add a block voting
> threshold as a means to keep humans in the loop, but if you do, use 100% as
> threshold.
> 
> -- 
> Pieter

> ------------------------------------------------------------------------------

> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development