[Bitcoin-development] Mechanics of a hard fork
roy at gnomon.org.uk
Thu May 7 20:00:23 UTC 2015
I'd love to have more discussion of exactly how a hard fork should be
implemented. I think it might actually be of some value to have rough
consensus on that before we get too bogged down with exactly what the
proposed hard fork should do. After all, how can we debate whether a
particular hard fork proposal has consensus if we haven't even decided
what level of supermajority is needed to establish consensus?
For instance, back in 2012 Gavin was proposing, effectively, that a
hard fork should require a supermajority of 99% of miners in order to
More recently, Gavin has proposed that a supermoajority of only 80% of
miners should be needed in order to trigger the hard fork.
Just now, on this list (see attached message) Gavin seems to be
aluding to some mechanism for a hard fork which involves consensus of
full nodes, and then a soft fork preceeding the hard fork, which I'd
love to see a full explanation of.
FWIW, I think 80% is far too low to establish consensus for a hard
fork. I think the supermajority of miners should be sufficiently
large that the rump doesn't constitute a viable coin. If you don't
have that very strong level of consensus then you risk forking Bitcoin
into two competing coins (and I believe we already have one exchange
promissing to trade both forks as long as the blockchains are alive).
As a starting point, I think 35/36th of miners (approximately 97.2%)
is the minimum I would be comfortable with. It means that the rump
coin will initially have an average confirmation time of 6 hours
(until difficulty, very slowly, adjusts) which is probably far enough
from viable that the majority of holdouts will quickly desert it too.
-------------- next part --------------
An embedded message was scrubbed...
From: Gavin Andresen <gavinandresen at gmail.com>
Subject: Re: [Bitcoin-development] Block Size Increase
Date: Thu, 7 May 2015 10:52:54 -0400
More information about the bitcoin-dev