[Bitcoin-development] Mechanics of a hard fork

[Bitcoin-development] Mechanics of a hard fork

[Roy Badami]

[-- Attachment #1: Type: text/plain, Size: 1831 bytes --]

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

[-- Attachment #2: hardfork.eml --]
[-- Type: message/rfc822, Size: 9872 bytes --]

[-- Attachment #2.1.1.1: Type: text/plain, Size: 1971 bytes --]

For reference: the blog post that (re)-started this debate, and which links
to individual issues, is here:
  http://gavinandresen.ninja/time-to-roll-out-bigger-blocks

In it, I asked people to email me objections I might have missed. I would
still appreciate it if people do that; it is impossible to keep up with
this mailing list, /r/bitcoin posts and comments, and #bitcoin-wizards and
also have time to respond thoughtfully to the objections raised.

I would very much like to find some concrete course of action that we can
come to consensus on. Some compromise so we can tell entrepreneurs "THIS is
how much transaction volume the main Bitcoin blockchain will be able to
support over the next eleven years."

I've been pretty clear on what I think is a reasonable compromise (a
one-time increase scheduled for early next year), and I have tried to
explain why I think it it is the right set of tradeoffs.

There ARE tradeoffs here, and the hard question is what process do we use
to decide those tradeoffs?  How do we come to consensus? Is it worth my
time to spend hours responding thoughtfully to every new objection raised
here, or will the same thing happen that happened last year and the year
before-- everybody eventually gets tired of arguing
angels-dancing-on-the-head-of-a-pin, and we're left with the status quo?

I AM considering contributing some version of the bigger blocksize-limit
hard-fork patch to the Bitcoin-Xt fork (probably  "target a hobbyist with a
fast Internet connection, and assume Nelson's law to increase over time),
and then encouraging merchants and exchanges and web wallets and
individuals who think it strikes a reasonable balance to run it.

And then, assuming it became a super-majority of nodes on the network,
encourage miners to roll out a soft-fork to start producing bigger blocks
and eventually trigger the hard fork.

Because ultimately consensus comes down to what software people choose to
run.

-- 
--
Gavin Andresen

[-- Attachment #2.1.1.2: Type: text/html, Size: 2677 bytes --]

[-- Attachment #2.1.2: Type: text/plain, Size: 409 bytes --]

------------------------------------------------------------------------------
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

[-- Attachment #2.1.3: Type: text/plain, Size: 188 bytes --]

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

Re: [Bitcoin-development] Mechanics of a hard fork

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 3521 bytes --]

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:

> 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
>
>

[-- Attachment #2: Type: text/html, Size: 4563 bytes --]

Re: [Bitcoin-development] Mechanics of a hard fork

[Roy Badami]

> 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

Re: [Bitcoin-development] Mechanics of a hard fork

[Pieter Wuille]

[-- Attachment #1: Type: text/plain, Size: 1956 bytes --]

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:

>
> > 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
>

[-- Attachment #2: Type: text/html, Size: 2589 bytes --]

Re: [Bitcoin-development] Mechanics of a hard fork

[Roy Badami]

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
> >

Re: [Bitcoin-development] Mechanics of a hard fork

[Adam Back]

[-- Attachment #1: Type: text/plain, Size: 4116 bytes --]

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:

> 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
>

[-- Attachment #2: Type: text/html, Size: 5358 bytes --]

Re: [Bitcoin-development] Mechanics of a hard fork

[Pieter Wuille]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

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.

-- 
Pieter

[-- Attachment #2: Type: text/html, Size: 1010 bytes --]

Re: [Bitcoin-development] Mechanics of a hard fork

[Cameron Garnham]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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:
> 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.
> 
> 
> 
> ----------------------------------------------------------------------
- --------
>
> 
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
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlVMKZYACgkQBJ8cMDO159aTiQEApTITEBrhE1DRbj/w+GncNeqB
0hGvmIBa1z0hGww0kaMBAOhxjn/K5leRJgdt1fKhNEDKKHdeCOIX3QRgry90D3NO
=p0+H
-----END PGP SIGNATURE-----