Mechanics of a hard fork
8 messages, 7 to 8 May 2015. Started by Roy Badami.
Roy Badami (3), Pieter Wuille (2), Tier Nolan, Adam Back, Cameron Garnham
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 succeed:
https://gist.github.com/gavinandresen/2355445
More recently, Gavin has proposed that a supermoajority of only 80% of miners should be needed in order to trigger the hard fork.
http://www.gavintech.blogspot.co.uk/2015/01/twenty-megabytes-testing-results.html
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.
Thoughs?
roy
In terms of miners, a strong supermajority is arguably sufficient, even 75% would be enough.
The near total consensus required is merchants and users. If (almost) all merchants and users updated and only 75% of the miners updated, then that would give a successful hard-fork.
On the other hand, if 99.99% of the miners updated and only 75% of merchants and 75% of users updated, then that would be a serioud split of the network.
The advantage of strong miner support is that it effectively kills the fork that follows the old rules. The 25% of merchants and users sees a blockchain stall.
Miners are likely to switch to the fork that is worth the most. A mining pool could even give 2 different sub-domains. A hasher can pick which rule-set to follow. Most likely, they would converge on the fork which paid the most, but the old ruleset would likely still have some hashing power and would eventually re-target.
On Thu, May 7, 2015 at 9:00 PM, Roy Badami <roy@gnomon•org•uk> wrote:
Quoted text (53 lines)
> 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 > succeed: > > https://gist.github.com/gavinandresen/2355445 > > More recently, Gavin has proposed that a supermoajority of only 80% of > miners should be needed in order to trigger the hard fork. > > > http://www.gavintech.blogspot.co.uk/2015/01/twenty-megabytes-testing-results.html > > 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. > > Thoughs? > > roy > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >
Quoted text (3 lines)
> On the other hand, if 99.99% of the miners updated and only 75% of > merchants and 75% of users updated, then that would be a serioud split of > the network.
But is that a plausible scenario? Certainly *if* the concensus rules required a 99% supermajority of miners for the hard fork to go ahead, then there would be absoltely no rational reason for merchants and users to refuse to upgrade, even if they don't support the changes introduces by the hard fork. Their only choice, if the fork succeeds, is between the active chain and the one that is effectively stalled - and, of course, they can make that choice ahead of time.
roy
I would not modify my node if the change introduced a perpetual 100 BTC subsidy per block, even if 99% of miners went along with it.
A hardfork is safe when 100% of (economically relevant) users upgrade. If miners don't upgrade at that point, they just lose money.
This is why a hashrate-triggered hardfork does not make sense. Either you believe everyone will upgrade anyway, and the hashrate doesn't matter. Or you are not certain, and the fork is risky, independent of what hashrate upgrades.
And the march 2013 fork showed that miners upgrade at a different schedule than the rest of the network. On May 7, 2015 5:44 PM, "Roy Badami" <roy@gnomon•org•uk> wrote:
Quoted text (27 lines)
> > > On the other hand, if 99.99% of the miners updated and only 75% of > > merchants and 75% of users updated, then that would be a serioud split of > > the network. > > But is that a plausible scenario? Certainly *if* the concensus rules > required a 99% supermajority of miners for the hard fork to go ahead, > then there would be absoltely no rational reason for merchants and > users to refuse to upgrade, even if they don't support the changes > introduces by the hard fork. Their only choice, if the fork succeeds, > is between the active chain and the one that is effectively stalled - > and, of course, they can make that choice ahead of time. > > roy > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >
On Thu, May 07, 2015 at 11:49:28PM +0200, Pieter Wuille wrote:
Quoted text (2 lines)
> I would not modify my node if the change introduced a perpetual 100 BTC > subsidy per block, even if 99% of miners went along with it.
Surely, in that scenario Bitcoin is dead. If the fork you prefer has only 1% of the hash power it is trivially vulnerably not just to a 51% attack but to a 501% attack, not to mention the fact that you'd only be getting one block every 16 hours.
Quoted text (8 lines)
> > A hardfork is safe when 100% of (economically relevant) users upgrade. If > miners don't upgrade at that point, they just lose money. > > This is why a hashrate-triggered hardfork does not make sense. Either you > believe everyone will upgrade anyway, and the hashrate doesn't matter. Or > you are not certain, and the fork is risky, independent of what hashrate > upgrades.
Beliefs are all very well, but they can be wrong. Of course we should not go ahead with a fork that we believe to be dangerous, but requiring a supermajority of miners is surely a wise precaution. I fail to see any realistic scenario where 99% of miners vote for the hard fork to go ahead, and the econonomic majority votes to stay on the blockchain whose hashrate has just dropped two orders of magnitude - so low that the mean time between blocks is now over 16 hours.
Quoted text (32 lines)
> > And the march 2013 fork showed that miners upgrade at a different schedule > than the rest of the network. > On May 7, 2015 5:44 PM, "Roy Badami" <roy@gnomon•org•uk> wrote: > > > > > > On the other hand, if 99.99% of the miners updated and only 75% of > > > merchants and 75% of users updated, then that would be a serioud split of > > > the network. > > > > But is that a plausible scenario? Certainly *if* the concensus rules > > required a 99% supermajority of miners for the hard fork to go ahead, > > then there would be absoltely no rational reason for merchants and > > users to refuse to upgrade, even if they don't support the changes > > introduces by the hard fork. Their only choice, if the fork succeeds, > > is between the active chain and the one that is effectively stalled - > > and, of course, they can make that choice ahead of time. > > > > roy > > > > > > ------------------------------------------------------------------------------ > > One dashboard for servers and applications across Physical-Virtual-Cloud > > Widest out-of-the-box monitoring support with 50+ applications > > Performance metrics, stats and reports that give you Actionable Insights > > Deep dive visibility with transaction tracing using APM Insight. > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists•sourceforge•net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >
Well this is all very extreme circumstances, and you'd have to assume no rational player with an interest in bitcoin would go there, but to play your analysis forward: users are also not powerless at the extreme: they could change the hash function rendering current deployed ASICs useless in reaction for example, and reset difficulty at the same time, or freeze transactions until some minimum hashrate is reached. People would figure out what is the least bad way forward.
Adam On May 7, 2015 3:09 PM, "Roy Badami" <roy@gnomon•org•uk> wrote:
Quoted text (76 lines)
> On Thu, May 07, 2015 at 11:49:28PM +0200, Pieter Wuille wrote: > > I would not modify my node if the change introduced a perpetual 100 BTC > > subsidy per block, even if 99% of miners went along with it. > > Surely, in that scenario Bitcoin is dead. If the fork you prefer has > only 1% of the hash power it is trivially vulnerably not just to a 51% > attack but to a 501% attack, not to mention the fact that you'd only > be getting one block every 16 hours. > > > > > A hardfork is safe when 100% of (economically relevant) users upgrade. If > > miners don't upgrade at that point, they just lose money. > > > > This is why a hashrate-triggered hardfork does not make sense. Either you > > believe everyone will upgrade anyway, and the hashrate doesn't matter. Or > > you are not certain, and the fork is risky, independent of what hashrate > > upgrades. > > Beliefs are all very well, but they can be wrong. Of course we should > not go ahead with a fork that we believe to be dangerous, but > requiring a supermajority of miners is surely a wise precaution. I > fail to see any realistic scenario where 99% of miners vote for the > hard fork to go ahead, and the econonomic majority votes to stay on > the blockchain whose hashrate has just dropped two orders of magnitude > - so low that the mean time between blocks is now over 16 hours. > > > > > And the march 2013 fork showed that miners upgrade at a different > schedule > > than the rest of the network. > > On May 7, 2015 5:44 PM, "Roy Badami" <roy@gnomon•org•uk> wrote: > > > > > > > > > On the other hand, if 99.99% of the miners updated and only 75% of > > > > merchants and 75% of users updated, then that would be a serioud > split of > > > > the network. > > > > > > But is that a plausible scenario? Certainly *if* the concensus rules > > > required a 99% supermajority of miners for the hard fork to go ahead, > > > then there would be absoltely no rational reason for merchants and > > > users to refuse to upgrade, even if they don't support the changes > > > introduces by the hard fork. Their only choice, if the fork succeeds, > > > is between the active chain and the one that is effectively stalled - > > > and, of course, they can make that choice ahead of time. > > > > > > roy > > > > > > > > > > ------------------------------------------------------------------------------ > > > One dashboard for servers and applications across > Physical-Virtual-Cloud > > > Widest out-of-the-box monitoring support with 50+ applications > > > Performance metrics, stats and reports that give you Actionable > Insights > > > Deep dive visibility with transaction tracing using APM Insight. > > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > _______________________________________________ > > > Bitcoin-development mailing list > > > Bitcoin-development@lists•sourceforge•net > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >
On May 7, 2015 3:08 PM, "Roy Badami" <roy@gnomon•org•uk> wrote:
Quoted text (9 lines)
> > On Thu, May 07, 2015 at 11:49:28PM +0200, Pieter Wuille wrote: > > I would not modify my node if the change introduced a perpetual 100 BTC > > subsidy per block, even if 99% of miners went along with it. > > Surely, in that scenario Bitcoin is dead. If the fork you prefer has > only 1% of the hash power it is trivially vulnerably not just to a 51% > attack but to a 501% attack, not to mention the fact that you'd only > be getting one block every 16 hours.
Yes, indeed, Bitcoin would be dead if this actually happens. But that is still where the power lies: before anyone (miners or others) would think about trying such a change, they would need to convince people and be sure they will effectively modify their code.
While being in the Bitcoin community for a long time, I haven't been so directly involved in the development. However I wish to suggest a different pre-hard-fork soft-fork approach:
Set a 'block size cap' in the similar same way as we set difficulty.
Every 2016 blocks take the average size of the blocks and multiply the size by 1.5x, rejecting blocks that are larger than this size, for the next 2016 period.
I would of-course suggest that we keep the limits at min 100kb and max (initially) 990kb (not 1mb on purpose, as this should become the new limit), rounding up to the nearest 10kb.
A: we don't have pressure at the 1mb limit, (we reduce the limit in a flexible manner to 990kb).
B: we can upgrade the network to XYZ hard-limit, then slowly raze the soft-limit after being sure the network, as-a-whole is ready.
If we on-day remove the block-size limit, this rule will stop a rouge miner from making 10mb, or 100mb blocks, or 1gb blocks.
This could be implemented by the miners without breaking any of the clients, and would tend to produce a better dynamic fee pressure.
This will give the mechanics to the miners to create consensus to agree what block-sizes they believe are best for the network, and allows the block-sizes to dynamically grow in response to larger demand.
On 5/8/2015 10:35 AM, Pieter Wuille wrote:
Quoted text (21 lines)
> On May 7, 2015 3:08 PM, "Roy Badami" <roy@gnomon•org•uk> wrote: >> >> On Thu, May 07, 2015 at 11:49:28PM +0200, Pieter Wuille wrote: >>> I would not modify my node if the change introduced a perpetual >>> 100 BTC subsidy per block, even if 99% of miners went along >>> with it. >> >> Surely, in that scenario Bitcoin is dead. If the fork you prefer >> has only 1% of the hash power it is trivially vulnerably not just >> to a 51% attack but to a 501% attack, not to mention the fact >> that you'd only be getting one block every 16 hours. > > Yes, indeed, Bitcoin would be dead if this actually happens. But > that is still where the power lies: before anyone (miners or > others) would think about trying such a change, they would need to > convince people and be sure they will effectively modify their > code. > > > > ----------------------------------------------------------------------
- --------
Quoted text (2 lines)
> >
One dashboard for servers and applications across Physical-Virtual-Cloud
Quoted text (11 lines)
> Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable > Insights Deep dive visibility with transaction tracing using APM > Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > > _______________________________________________ Bitcoin-development > mailing list Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >