path: root/68/e0e70a87c2f3586e6920928a66d775bd86df59

Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 73145102A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  7 Feb 2016 17:24:10 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E02632F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  7 Feb 2016 17:24:08 +0000 (UTC)
Received: from 119246245241.ctinets.com ([119.246.245.241]:51099 helo=2012R2)
	by server47.web-hosting.com with esmtpsa
	(TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86)
	(envelope-from <jl2012@xbt.hk>)
	id 1aST4A-000f1a-JY; Sun, 07 Feb 2016 12:24:07 -0500
From: <jl2012@xbt.hk>
To: "'Jonathan Toomim'" <j@toom.im>,
	"'Anthony Towns'" <aj@erisian.com.au>
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>	<CABm2gDoungCbB22_SKHcedBKegWEPpjeM2woxLGchC4=om8BrA@mail.gmail.com>	<1804222.7gVHPiWqto@kiwi>
	<201602062046.40193.luke@dashjr.org>	<CABsx9T0N_TBbmy3xr-mqNDdKVF_3_QHYA1W2ttsZBQnt4dWxgw@mail.gmail.com>	<20160207151927.GA14750@sapphire.erisian.com.au>
	<57C403C6-2680-4C3D-8860-E33A525A99D4@toom.im>
In-Reply-To: <57C403C6-2680-4C3D-8860-E33A525A99D4@toom.im>
Date: Mon, 8 Feb 2016 01:24:25 +0800
Message-ID: <22e401d161cc$66af6b50$340e41f0$@xbt.hk>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_22E5_01D1620F.74D431F0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQH4jF1VS2oYOn83eis4ezLyrErEQAKPS4/SAWOghZICnxtKJgMInfBgAnCdUFECASrdP55iGSxg
Content-Language: en-hk
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - server47.web-hosting.com
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - xbt.hk
X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id:
	jl2012@xbt.hk
X-Authenticated-Sender: server47.web-hosting.com: jl2012@xbt.hk
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to
	2	megabytes
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Feb 2016 17:24:10 -0000

This is a multipart message in MIME format.

------=_NextPart_000_22E5_01D1620F.74D431F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

You are making a very na=EFve assumption that miners are just looking =
for
profit for the next second. Instead, they would try to optimize their =
short
term and long term ROI. It is also well known that some miners would =
mine at
a loss, even not for ideological reasons, if they believe that their =
action
is beneficial to the network and will provide long term ROI. It happened
after the last halving in 2012. Without any immediate price =
appreciation,
the hashing rate decreased by only less than 10%

=20

http://bitcoin.sipa.be/speed-ever.png

=20

=20

From: bitcoin-dev-bounces@lists.linuxfoundation.org
[mailto:bitcoin-dev-bounces@lists.linuxfoundation.org] On Behalf Of =
Jonathan
Toomim via bitcoin-dev
Sent: Monday, 8 February, 2016 01:11
To: Anthony Towns <aj@erisian.com.au>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
megabytes

=20

=20

On Feb 7, 2016, at 7:19 AM, Anthony Towns via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org
<mailto:bitcoin-dev@lists.linuxfoundation.org> > wrote:





The stated reasoning for 75% versus 95% is "because it gives "veto =
power"
to a single big solo miner or mining pool". But if a 20% miner wants to
"veto" the upgrade, with a 75% threshold, they could instead simply use
their hashpower to vote for an upgrade, but then not mine anything on
the new chain. At that point there'd be as little as 55% mining the new
2MB chain with 45% of hashpower remaining on the old chain. That'd be 18
minute blocks versus 22 minute blocks, which doesn't seem like much of
a difference in practice, and at that point hashpower could plausibly
end up switching almost entirely back to the original consensus rules
prior to the grace period ending.

=20

Keep in mind that within a single difficulty adjustment period, the
difficulty of mining a block on either chain will be identical. Even if =
the
value of a 1MB branch coin is $100 and the hashrate on the 1 MB branch =
is
100 PH/s, and the value of a 2 MB branch coin is $101 and the hashrate =
on
the 2 MB branch is 1000 PH/s, the rational thing for a miner to do (for =
the
first adjustment period) is to mine on the 2 MB branch, because the =
miner
would earn 1% more on that branch.

=20

So you're assuming that 25% of the hashrate chooses to remain on the
minority version during the grace period, and that 20% chooses to switch
back to the minority side. The fork happens. One branch has 1 MB blocks
every 22 minutes, and the other branch has 2 MB blocks every 18 minutes. =
The
first branch cannot handle the pre-fork transaction volume, as it only =
has
45% of the capacity that it had pre-fork. The second one can, as it has =
111%
of the pre-fork capacity. This makes the 1 MB branch much less usable =
than
the 2 MB branch, which in turn causes the market value of newly minted =
coins
on that branch to fall, which in turn causes miners to switch to the =
more
profitable 2MB branch. This exacerbates the usability difference, which
exacerbates the price difference, etc. Having two competing chains with
equal hashrate using the same PoW function and nearly equal features is =
not
a stable state. Positive feedback loops exist to make the vast majority =
of
the users and the hashrate join one side.

=20

Basically, any miners who stick to the minority branch are going to lose =
a
lot of money.

=20

=20


------=_NextPart_000_22E5_01D1620F.74D431F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1"><meta name=3DGenerator content=3D"Microsoft Word =
15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:DengXian;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@DengXian";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
	{mso-style-name:msonormal;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman",serif;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri",sans-serif;
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-HK link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'=
>You are making a very na=EFve assumption that miners are just looking =
for profit for the next second. Instead, they would try to optimize =
their short term and long term ROI. It is also well known that some =
miners would mine at a loss, even not for ideological reasons, if they =
believe that their action is beneficial to the network and will provide =
long term ROI. It happened after the last halving in 2012. Without any =
immediate price appreciation, the hashing rate decreased by only less =
than 10%<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'=
><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'=
><a =
href=3D"http://bitcoin.sipa.be/speed-ever.png">http://bitcoin.sipa.be/spe=
ed-ever.png</a><o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'=
><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'=
><o:p>&nbsp;</o:p></span></p><div><div =
style=3D'border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm =
0cm 0cm'><p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span><=
/b><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'> =
bitcoin-dev-bounces@lists.linuxfoundation.org =
[mailto:bitcoin-dev-bounces@lists.linuxfoundation.org] <b>On Behalf Of =
</b>Jonathan Toomim via bitcoin-dev<br><b>Sent:</b> Monday, 8 February, =
2016 01:11<br><b>To:</b> Anthony Towns =
&lt;aj@erisian.com.au&gt;<br><b>Cc:</b> =
bitcoin-dev@lists.linuxfoundation.org<br><b>Subject:</b> Re: =
[bitcoin-dev] BIP proposal: Increase block size limit to 2 =
megabytes<o:p></o:p></span></p></div></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><div><p class=3DMsoNormal>On =
Feb 7, 2016, at 7:19 AM, Anthony Towns via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.l=
inuxfoundation.org</a>&gt; wrote:<o:p></o:p></p></div><p =
class=3DMsoNormal><br><br><o:p></o:p></p><blockquote =
style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><p =
class=3DMsoNormal><span =
style=3D'font-size:9.0pt;font-family:"Helvetica",sans-serif'>The stated =
reasoning for 75% versus 95% is &quot;because it gives &quot;veto =
power&quot;<br>to a single big solo miner or mining pool&quot;. But if a =
20% miner wants to<br>&quot;veto&quot; the upgrade, with a 75% =
threshold, they could instead simply use<br>their hashpower to vote for =
an upgrade, but then not mine anything on<br>the new chain. At that =
point there'd be as little as 55% mining the new<br>2MB chain with 45% =
of hashpower remaining on the old chain. That'd be 18<br>minute blocks =
versus 22 minute blocks, which doesn't seem like much of<br>a difference =
in practice, and at that point hashpower could plausibly<br>end up =
switching almost entirely back to the original consensus rules<br>prior =
to the grace period =
ending.</span><o:p></o:p></p></blockquote></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><div><p =
class=3DMsoNormal>Keep in mind that within a single difficulty =
adjustment period, the difficulty of mining a block on either chain will =
be identical. Even if the value of a 1MB branch coin is $100 and the =
hashrate on the 1 MB branch is 100 PH/s, and the value of a 2 MB branch =
coin is $101 and the hashrate on the 2 MB branch is 1000 PH/s, the =
rational thing for a miner to do (for the first adjustment period) is to =
mine on the 2 MB branch, because the miner would earn 1% more on that =
branch.<o:p></o:p></p></div></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><p class=3DMsoNormal>So =
you're assuming that 25% of the hashrate chooses to remain on the =
minority version during the grace period, and that 20% chooses to switch =
back to the minority side. The fork happens. One branch has 1 MB blocks =
every 22 minutes, and the other branch has 2 MB blocks every 18 minutes. =
The first branch cannot handle the pre-fork transaction volume, as it =
only has 45% of the capacity that it had pre-fork. The second one can, =
as it has 111% of the pre-fork capacity. This makes the 1 MB branch much =
less usable than the 2 MB branch, which in turn causes the market value =
of newly minted coins on that branch to fall, which in turn causes =
miners to switch to the more profitable 2MB branch. This exacerbates the =
usability difference, which exacerbates the price difference, etc. =
Having two competing chains with equal hashrate using the same PoW =
function and nearly equal features is not a stable state. Positive =
feedback loops exist to make the vast majority of the users and the =
hashrate join one side.<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>Basically, any miners who stick to the minority branch =
are going to lose a lot of money.<o:p></o:p></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'=
><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'=
><o:p>&nbsp;</o:p></span></p></div></div></body></html>
------=_NextPart_000_22E5_01D1620F.74D431F0--