Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z6NjP-0006kL-VM for bitcoin-development@lists.sourceforge.net; Sat, 20 Jun 2015 18:43:07 +0000 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; Received: from darla.gnomon.org.uk ([93.93.131.22]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Z6NjO-0004D0-25 for bitcoin-development@lists.sourceforge.net; Sat, 20 Jun 2015 18:43:07 +0000 Received: from darla.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by darla.gnomon.org.uk (8.14.3/8.14.3) with ESMTP id t5KIgpl1037558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 20 Jun 2015 19:42:56 +0100 (BST) (envelope-from roy@darla.gnomon.org.uk) Received: (from roy@localhost) by darla.gnomon.org.uk (8.14.3/8.14.1/Submit) id t5KIgpta037557; Sat, 20 Jun 2015 19:42:51 +0100 (BST) (envelope-from roy) Date: Sat, 20 Jun 2015 19:42:51 +0100 From: Roy Badami To: Pieter Wuille Message-ID: <20150620184250.GV13473@giles.gnomon.org.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -2.1 (--) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1Z6NjO-0004D0-25 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Hard fork via miner vote X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 18:43:08 -0000 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