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 ------------------------------------------------------------------------------ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
