path: root/28/1851ebaf14adfc1f9564aacce16682ac8bd638

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 <tier.nolan@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <CAE-z3OVgX9S0sJqq-iFdkZn_wK-a=Vs4VpNwxpcagDEYFzNSDQ@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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
>
>

--001a1147efce6d3eb00515848a86
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>In terms of miners, a strong supermajority is ar=
guably sufficient, even 75% would be enough.<br><br></div>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.<br><br></div><div>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.<br><br></div><div>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.<br><br></div><div>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.<br></div><=
/div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, May =
7, 2015 at 9:00 PM, Roy Badami <span dir=3D"ltr">&lt;<a href=3D"mailto:roy@=
gnomon.org.uk" target=3D"_blank">roy@gnomon.org.uk</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">I&#39;d love to have more discussion of exa=
ctly how a hard fork should be<br>
implemented.=C2=A0 I think it might actually be of some value to have rough=
<br>
consensus on that before we get too bogged down with exactly what the<br>
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&#39;t even decided<=
br>
what level of supermajority is needed to establish consensus?<br>
<br>
For instance, back in 2012 Gavin was proposing, effectively, that a<br>
hard fork should require a supermajority of 99% of miners in order to<br>
succeed:<br>
<br>
<a href=3D"https://gist.github.com/gavinandresen/2355445" target=3D"_blank"=
>https://gist.github.com/gavinandresen/2355445</a><br>
<br>
More recently, Gavin has proposed that a supermoajority of only 80% of<br>
miners should be needed in order to trigger the hard fork.<br>
<br>
<a href=3D"http://www.gavintech.blogspot.co.uk/2015/01/twenty-megabytes-tes=
ting-results.html" target=3D"_blank">http://www.gavintech.blogspot.co.uk/20=
15/01/twenty-megabytes-testing-results.html</a><br>
<br>
Just now, on this list (see attached message) Gavin seems to be<br>
aluding to some mechanism for a hard fork which involves consensus of<br>
full nodes, and then a soft fork preceeding the hard fork, which I&#39;d<br=
>
love to see a full explanation of.<br>
<br>
FWIW, I think 80% is far too low to establish consensus for a hard<br>
fork.=C2=A0 I think the supermajority of miners should be sufficiently<br>
large that the rump doesn&#39;t constitute a viable coin.=C2=A0 If you don&=
#39;t<br>
have that very strong level of consensus then you risk forking Bitcoin<br>
into two competing coins (and I believe we already have one exchange<br>
promissing to trade both forks as long as the blockchains are alive).<br>
<br>
As a starting point, I think 35/36th of miners (approximately 97.2%)<br>
is the minimum I would be comfortable with.=C2=A0 It means that the rump<br=
>
coin will initially have an average confirmation time of 6 hours<br>
(until difficulty, very slowly, adjusts) which is probably far enough<br>
from viable that the majority of holdouts will quickly desert it too.<br>
<br>
Thoughs?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
roy</font></span><br>------------------------------------------------------=
------------------------<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>=
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>

--001a1147efce6d3eb00515848a86--