From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YqTHp-0005FA-2X for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 21:24:53 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.192.42 as permitted sender) client-ip=209.85.192.42; envelope-from=tier.nolan@gmail.com; helo=mail-qg0-f42.google.com; Received: from mail-qg0-f42.google.com ([209.85.192.42]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YqTHn-000851-A5 for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 21:24:53 +0000 Received: by qgej70 with SMTP id j70so27829179qge.2 for ; Thu, 07 May 2015 14:24:45 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.55.21.166 with SMTP id 38mr1495202qkv.88.1431033885826; Thu, 07 May 2015 14:24:45 -0700 (PDT) Received: by 10.140.85.241 with HTTP; Thu, 7 May 2015 14:24:45 -0700 (PDT) In-Reply-To: <20150507200023.GI63100@giles.gnomon.org.uk> References: <20150507200023.GI63100@giles.gnomon.org.uk> Date: Thu, 7 May 2015 22:24:45 +0100 Message-ID: From: Tier Nolan Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a1147efce6d3eb00515848a86 X-Spam-Score: 1.7 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (tier.nolan[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.2 MISSING_HEADERS Missing To: header 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 1.6 MALFORMED_FREEMAIL Bad headers on message from free email service -0.5 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YqTHn-000851-A5 Subject: Re: [Bitcoin-development] Mechanics of a hard fork X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 21:24:53 -0000 --001a1147efce6d3eb00515848a86 Content-Type: text/plain; charset=UTF-8 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 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 > > --001a1147efce6d3eb00515848a86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In terms of miners, a strong supermajority is ar= guably sufficient, even 75% would be enough.

The near total co= nsensus required is merchants and users.=C2=A0 If (almost) all merchants an= d 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 th= at 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.=C2=A0 The 25% of merchants and users sees a blockchain stal= l.

Miners are likely to switch to the fork that is worth = the most.=C2=A0 A mining pool could even give 2 different sub-domains.=C2= =A0 A hasher can pick which rule-set to follow.=C2=A0 Most likely, they wou= ld converge on the fork which paid the most, but the old ruleset would like= ly still have some hashing power and would eventually re-target.
<= /div>

On Thu, May = 7, 2015 at 9:00 PM, Roy Badami <roy@gnomon.org.uk> wrote:
I'd love to have more discussion of exa= ctly how a hard fork should be
implemented.=C2=A0 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.=C2=A0 After all, how can we debate whether a<= br> particular hard fork proposal has consensus if we haven't even decided<= br> 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/20= 15/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.=C2=A0 I think the supermajority of miners should be sufficiently
large that the rump doesn't constitute a viable coin.=C2=A0 If you don&= #39;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.=C2=A0 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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--001a1147efce6d3eb00515848a86--