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

2015-05-07 Thread Pieter Wuille
On May 7, 2015 3:08 PM, Roy Badami r...@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
--
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

2015-05-07 Thread 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 r...@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-

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

2015-05-07 Thread Adam Back
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 r...@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 r...@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

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

2015-05-07 Thread Pieter Wuille
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 r...@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


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

2015-05-07 Thread Tier Nolan
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 r...@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


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

2015-05-07 Thread 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

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

2015-05-07 Thread 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 r...@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