path: root/5f/9027efd60ab82cd780d7cbe8b8ee0d853953ec

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 5E828C26
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 15:34:51 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8C213FB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 15:34:49 +0000 (UTC)
Received: from [10.8.8.2] (119246245241.ctinets.com [119.246.245.241]) by
	mx.zohomail.com with SMTPS id 1490801685693216.73459769209137;
	Wed, 29 Mar 2017 08:34:45 -0700 (PDT)
From: Johnson Lau <jl2012@xbt.hk>
Message-Id: <1471A2C5-C72C-46EB-8C7A-C2FAF705E88B@xbt.hk>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_FD40351F-41DC-4CFE-9CEC-22FB5F5DD556"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 29 Mar 2017 23:34:41 +0800
In-Reply-To: <CAPkFh0uGcN=6Sgyb5z61h36CS3-VfNHZDHoM+hpqmKFdF+_L0A@mail.gmail.com>
To: =?utf-8?Q?Emin_G=C3=BCn_Sirer?= <el33th4x0r@gmail.com>,
	bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
References: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com>
	<CAMBsKS8oSKS5g8UEyCu18bjzGJWpA+sJEaxBUV9FXAmXhX1ApA@mail.gmail.com>
	<RO1P152MB16424A3706E408DA163B1D95F5320@RO1P152MB1642.LAMP152.PROD.OUTLOOK.COM>
	<CAMBsKS9n7Mxd2LwXwSXUjHbBQj932QQW7-CnXe10tia6Ga0iBQ@mail.gmail.com>
	<RO1P152MB16428E9EFBF561B2642C3B0BF5320@RO1P152MB1642.LAMP152.PROD.OUTLOOK.COM>
	<CAPkFh0uGcN=6Sgyb5z61h36CS3-VfNHZDHoM+hpqmKFdF+_L0A@mail.gmail.com>
X-Mailer: Apple Mail (2.3259)
X-ZohoMailClient: External
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Wed, 29 Mar 2017 15:34:51 -0000


--Apple-Mail=_FD40351F-41DC-4CFE-9CEC-22FB5F5DD556
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 29 Mar 2017, at 14:24, Emin G=C3=BCn Sirer via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> >Even when several of the experts involved in the document you refer =
has my respect and admiration, I do not agree with some of their =
conclusions
>=20
> I'm one of the co-authors of that study. I'd be the first to agree =
with your conclusion
> and argue that the 4MB size suggested in that paper should not be used =
without
> compensation for two important changes to the network.
>=20
> Our recent measurements of the Bitcoin P2P network show that network =
speeds
> have improved tremendously. =46rom February 2016 to February 2017, the =
average
> provisioned bandwidth of a reachable Bitcoin node went up by =
approximately 70%.=20
> And that's just in the last year.

4 * 144 * 30 =3D 17.3GB per month, or 207GB per year. Full node =
initialisation will become prohibitive for most users until a shortcut =
is made (e.g. witness pruning and UTXO commitment but these are not =
trust-free)

>=20
> Further, the emergence of high-speed block relay networks, like Falcon =
(http://www.falcon-net.org <http://www.falcon-net.org/>)
> and FIBRE, as well as block compression, e.g. BIP152 and xthin, change =
the picture dramatically.=20

Also as the co-author of the selfish mining paper, you should know all =
these technology assume big miners being benevolent.

>=20
> So, the 4MB limit mentioned in our paper should not be used as a =
protocol limit today.=20
>=20
> Best,
> - egs
>=20
>=20
>=20
> On Tue, Mar 28, 2017 at 3:36 PM, Juan Garavaglia via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> Alphonse,
>=20
> =20
>=20
> Even when several of the experts involved in the document you refer =
has my respect and admiration, I do not agree with some of their =
conclusions some of their estimations are not accurate other changed =
like Bootstrap Time, Cost per Confirmed Transaction they consider a =
network of 450,000,00 GH and today is 3.594.236.966 GH, the energy =
consumption per GH is old, the cost of electricity is wrong even when =
the document was made and is hard to find any parameter used that is =
valid for an analysis today.
>=20
> =20
>=20
> Again with all respect to the experts involved in that analysis is not =
valid today.
>=20
> =20
>=20
> I tend to believe more in Moore=E2=80=99s law, Butters' Law of =
Photonics and Kryder=E2=80=99s Law all has been verified for many years =
and support that 32 MB in 2020 are possible and equals or less than 1 MB =
in 2010.
>=20
> =20
>=20
> Again may be is not possible Johnson Lau and LukeJr invested a =
significant amount of time investigating ways to do a safe HF, and may =
be not possible to do a safe HF today but from processing power, =
bandwidth and storage is totally valid and Wang Chung proposal has solid =
grounds.
>=20
> =20
>=20
> Regards
>=20
> =20
>=20
> Juan
>=20
> =20
>=20
> =20
>=20
> From: Alphonse Pace [mailto:alp.bitcoin@gmail.com =
<mailto:alp.bitcoin@gmail.com>]=20
> Sent: Tuesday, March 28, 2017 2:53 PM
> To: Juan Garavaglia <jg@112bit.com <mailto:jg@112bit.com>>; Wang Chun =
<1240902@gmail.com <mailto:1240902@gmail.com>>
> Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>>
>=20
>=20
> Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
>=20
> =20
>=20
> Juan,
>=20
> =20
>=20
> I suggest you take a look at this paper: =
http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf =
<http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf>  It may help you form =
opinions based in science rather than what appears to be nothing more =
than a hunch.  It shows that even 4MB is unsafe.  SegWit provides up to =
this limit.
>=20
> =20
>=20
> 8MB is most definitely not safe today.
>=20
> =20
>=20
> Whether it is unsafe or impossible is the topic, since Wang Chun =
proposed making the block size limit 32MiB. =20
>=20
> =20
>=20
> =20
>=20
> Wang Chun,
>=20
>=20
> Can you specify what meeting you are talking about?  You seem to have =
not replied on that point.  Who were the participants and what was the =
purpose of this meeting?
>=20
> =20
>=20
> -Alphonse
>=20
> =20
>=20
> On Tue, Mar 28, 2017 at 12:33 PM, Juan Garavaglia <jg@112bit.com =
<mailto:jg@112bit.com>> wrote:
>=20
> Alphonse,
>=20
> =20
>=20
> In my opinion if 1MB limit was ok in 2010, 8MB limit is ok on 2016 and =
32MB limit valid in next halving, from network, storage and CPU =
perspective or 1MB was too high in 2010 what is possible or 1MB is to =
low today.
>=20
> =20
>=20
> If is unsafe or impossible to raise the blocksize is a different =
topic.=20
>=20
> =20
>=20
> Regards
>=20
> =20
>=20
> Juan
>=20
> =20
>=20
> =20
>=20
> From: bitcoin-dev-bounces@lists.linuxfoundation.org =
<mailto:bitcoin-dev-bounces@lists.linuxfoundation.org> =
[mailto:bitcoin-dev-bounces@lists.linuxfoundation.org =
<mailto:bitcoin-dev-bounces@lists.linuxfoundation.org>] On Behalf Of =
Alphonse Pace via bitcoin-dev
> Sent: Tuesday, March 28, 2017 2:24 PM
> To: Wang Chun <1240902@gmail.com <mailto:1240902@gmail.com>>; Bitcoin =
Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>>
> Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
>=20
> =20
>=20
> What meeting are you referring to?  Who were the participants?
>=20
> =20
>=20
> Removing the limit but relying on the p2p protocol is not really a =
true 32MiB limit, but a limit of whatever transport methods provide.  =
This can lead to differing consensus if alternative layers for relaying =
are used.  What you seem to be asking for is an unbound block size (or =
at least determined by whatever miners produce).  This has the =
possibility (and even likelihood) of removing many participants from the =
network, including many small miners. =20
>=20
> =20
>=20
> 32MB in less than 3 years also appears to be far beyond limits of =
safety which are known to exist far sooner, and we cannot expect =
hardware and networking layers to improve by those amounts in that time.
>=20
> =20
>=20
> It also seems like it would be much better to wait until SegWit =
activates in order to truly measure the effects on the network from this =
increased capacity before committing to any additional increases.
>=20
> =20
>=20
> -Alphonse
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> On Tue, Mar 28, 2017 at 11:59 AM, Wang Chun via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>=20
> I've proposed this hard fork approach last year in Hong Kong Consensus
> but immediately rejected by coredevs at that meeting, after more than
> one year it seems that lots of people haven't heard of it. So I would
> post this here again for comment.
>=20
> The basic idea is, as many of us agree, hard fork is risky and should
> be well prepared. We need a long time to deploy it.
>=20
> Despite spam tx on the network, the block capacity is approaching its
> limit, and we must think ahead. Shall we code a patch right now, to
> remove the block size limit of 1MB, but not activate it until far in
> the future. I would propose to remove the 1MB limit at the next block
> halving in spring 2020, only limit the block size to 32MiB which is
> the maximum size the current p2p protocol allows. This patch must be
> in the immediate next release of Bitcoin Core.
>=20
> With this patch in core's next release, Bitcoin works just as before,
> no fork will ever occur, until spring 2020. But everyone knows there
> will be a fork scheduled. Third party services, libraries, wallets and
> exchanges will have enough time to prepare for it over the next three
> years.
>=20
> We don't yet have an agreement on how to increase the block size
> limit. There have been many proposals over the past years, like
> BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so
> on. These hard fork proposals, with this patch already in Core's
> release, they all become soft fork. We'll have enough time to discuss
> all these proposals and decide which one to go. Take an example, if we
> choose to fork to only 2MB, since 32MiB already scheduled, reduce it
> from 32MiB to 2MB will be a soft fork.
>=20
> Anyway, we must code something right now, before it becomes too late.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> =20
>=20
> =20
>=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_FD40351F-41DC-4CFE-9CEC-22FB5F5DD556
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On 29 Mar 2017, at 14:24, Emin G=C3=BCn Sirer via bitcoin-dev =
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D"">&gt;<span =
style=3D"font-family:calibri,sans-serif;font-size:14.6667px" =
class=3D"">Even when several of the experts involved in the document you =
refer has my respect and admiration, I do not agree with some of their =
conclusions</span><div class=3D""><span =
style=3D"font-family:calibri,sans-serif;font-size:14.6667px" =
class=3D""><br class=3D""></span></div><div class=3D""><span =
style=3D"font-family:calibri,sans-serif;font-size:14.6667px" =
class=3D"">I'm one of the co-authors of that study. I'd be the first to =
agree with your conclusion</span></div><div class=3D""><span =
style=3D"font-family:calibri,sans-serif;font-size:14.6667px" =
class=3D"">and&nbsp;</span><span =
style=3D"font-family:calibri,sans-serif;font-size:14.6667px" =
class=3D"">argue that the 4MB size&nbsp;</span><span =
style=3D"font-family:calibri,sans-serif;font-size:14.6667px" =
class=3D"">suggested in that paper should not be used =
without</span></div><div class=3D""><span =
style=3D"font-family:calibri,sans-serif;font-size:14.6667px" =
class=3D"">compensation for two important changes to the =
network.</span></div></div></div></blockquote><blockquote type=3D"cite" =
class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div =
class=3D""><span =
style=3D"font-family:calibri,sans-serif;font-size:14.6667px" =
class=3D""><br class=3D""></span></div><div class=3D""><font =
face=3D"calibri, sans-serif" class=3D""><span =
style=3D"font-size:14.6667px" class=3D"">Our recent measurements of the =
Bitcoin P2P network show that network speeds</span></font></div><div =
class=3D""><font face=3D"calibri, sans-serif" class=3D""><span =
style=3D"font-size:14.6667px" class=3D"">have improved tremendously. =
=46rom February 2016 to February 2017, the =
average</span></font></div><div class=3D""><font face=3D"calibri, =
sans-serif" class=3D""><span style=3D"font-size:14.6667px" =
class=3D"">provisioned bandwidth of a reachable Bitcoin node went up by =
approximately 70%.&nbsp;</span></font></div><div class=3D""><font =
face=3D"calibri, sans-serif" class=3D""><span =
style=3D"font-size:14.6667px" class=3D"">And that's just in the last =
year.</span></font></div></div></div></blockquote><div><br =
class=3D""></div><div>4 * 144 * 30 =3D 17.3GB per month, or 207GB per =
year. Full node initialisation will become prohibitive for most users =
until a shortcut is made (e.g. witness pruning and UTXO commitment but =
these are not trust-free)</div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div =
class=3D""><font face=3D"calibri, sans-serif" class=3D""><span =
style=3D"font-size:14.6667px" class=3D""><br =
class=3D""></span></font></div><div class=3D""><font face=3D"calibri, =
sans-serif" class=3D""><span style=3D"font-size:14.6667px" =
class=3D"">Further, the emergence of high-speed block relay networks, =
like Falcon&nbsp;</span></font><span =
style=3D"font-size:14.6667px;font-family:calibri,sans-serif" =
class=3D"">(<a href=3D"http://www.falcon-net.org/" =
class=3D"">http://www.falcon-net.org</a>)</span></div><div =
class=3D""><font face=3D"calibri, sans-serif" class=3D""><span =
style=3D"font-size:14.6667px" class=3D"">and FIBRE, as well as block =
compression, e.g. BIP152 and xthin, change the picture =
dramatically.&nbsp;</span></font></div></div></div></blockquote><div><br =
class=3D""></div><div>Also as the co-author of the selfish mining paper, =
you should know all these technology assume big miners being =
benevolent.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D""><div dir=3D"ltr" class=3D""><div class=3D""><br =
class=3D""></div><div class=3D""><font face=3D"calibri, sans-serif" =
class=3D""><span style=3D"font-size:14.6667px" class=3D"">So, the 4MB =
limit mentioned in our paper s</span></font><span =
style=3D"font-size:14.6667px;font-family:calibri,sans-serif" =
class=3D"">hould not be used as a protocol limit =
today.&nbsp;</span></div><div class=3D""><br class=3D""></div><div =
class=3D"">Best,</div><div class=3D"">- egs</div><div class=3D""><br =
class=3D""></div><div class=3D""><font face=3D"calibri, sans-serif" =
class=3D""><span style=3D"font-size:14.6667px" class=3D""><br =
class=3D""></span></font></div></div><div class=3D"gmail_extra"><br =
class=3D""><div class=3D"gmail_quote">On Tue, Mar 28, 2017 at 3:36 PM, =
Juan Garavaglia via bitcoin-dev <span dir=3D"ltr" class=3D"">&lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> =
wrote:<br class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple" class=3D"">
<div class=3D"m_6410332602410038595WordSection1"><p =
class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D"">Alphonse,<u class=3D""></u><u class=3D""></u></span></p><p =
class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D""><u class=3D""></u>&nbsp;<u class=3D""></u></span></p><p =
class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D"">Even when several of the experts involved in the document you =
refer has my respect and admiration, I do not agree with some of their =
conclusions some of their estimations are
 not accurate other changed like Bootstrap Time, Cost per Confirmed =
Transaction they consider a network of 450,000,00 GH and today is =
3.594.236.966 GH, the energy consumption per GH is old, the cost of =
electricity is wrong even when the document was made and
 is hard to find any parameter used that is valid for an analysis =
today.<u class=3D""></u><u class=3D""></u></span></p><p =
class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D""><u class=3D""></u>&nbsp;<u class=3D""></u></span></p><p =
class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D"">Again with all respect to the experts involved in that =
analysis is not valid today.<u class=3D""></u><u =
class=3D""></u></span></p><p class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D""><u class=3D""></u>&nbsp;<u class=3D""></u></span></p><p =
class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D"">I tend to believe more in Moore=E2=80=99s law, Butters' Law =
of Photonics and Kryder=E2=80=99s Law all has been verified for many =
years and support that 32 MB in 2020 are possible and equals
 or less than 1 MB in 2010.<u class=3D""></u><u =
class=3D""></u></span></p><p class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D""><u class=3D""></u>&nbsp;<u class=3D""></u></span></p><p =
class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D"">Again may be is not possible Johnson Lau and LukeJr invested =
a significant amount of time investigating ways to do a safe HF, and may =
be not possible to do a safe HF today
 but from processing power, bandwidth and storage is totally valid and =
Wang Chung proposal has solid grounds.<u class=3D""></u><u =
class=3D""></u></span></p><p class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D""><u class=3D""></u>&nbsp;<u class=3D""></u></span></p><p =
class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D"">Regards<u class=3D""></u><u class=3D""></u></span></p><p =
class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D""><u class=3D""></u>&nbsp;<u class=3D""></u></span></p><p =
class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D"">Juan<u class=3D""></u><u class=3D""></u></span></p><p =
class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D""><u class=3D""></u>&nbsp;<u class=3D""></u></span></p><p =
class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D""><u class=3D""></u>&nbsp;<u class=3D""></u></span></p><p =
class=3D"MsoNormal"><b class=3D""><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D"">From:</span></b><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D""> Alphonse Pace [mailto:<a href=3D"mailto:alp.bitcoin@gmail.com"=
 target=3D"_blank" class=3D"">alp.bitcoin@gmail.com</a>]
<br class=3D"">
<b class=3D"">Sent:</b> Tuesday, March 28, 2017 2:53 PM<br class=3D"">
<b class=3D"">To:</b> Juan Garavaglia &lt;<a href=3D"mailto:jg@112bit.com"=
 target=3D"_blank" class=3D"">jg@112bit.com</a>&gt;; Wang Chun &lt;<a =
href=3D"mailto:1240902@gmail.com" target=3D"_blank" =
class=3D"">1240902@gmail.com</a>&gt;<br class=3D"">
<b class=3D"">Cc:</b> Bitcoin Protocol Discussion &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
class=3D"">bitcoin-dev@lists.<wbr =
class=3D"">linuxfoundation.org</a>&gt;</span></p><div class=3D""><div =
class=3D"h5"><br class=3D"">
<b class=3D"">Subject:</b> Re: [bitcoin-dev] Hard fork proposal from =
last week's meeting<u class=3D""></u><u class=3D""></u></div></div><div =
class=3D""><br class=3D"webkit-block-placeholder"></div><div =
class=3D""><div class=3D"h5"><p class=3D"MsoNormal"><u =
class=3D""></u>&nbsp;<u class=3D""></u></p>
<div class=3D""><p class=3D"MsoNormal">Juan,<u class=3D""></u><u =
class=3D""></u></p>
<div class=3D""><p class=3D"MsoNormal"><u class=3D""></u>&nbsp;<u =
class=3D""></u></p>
</div>
<div class=3D""><p class=3D"MsoNormal">I suggest you take a look at this =
paper:&nbsp;<a href=3D"http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf" =
target=3D"_blank" class=3D"">http://fc16.ifca.ai/<wbr =
class=3D"">bitcoin/papers/CDE+16.pdf</a> &nbsp;It may help you form =
opinions based in science rather than what appears to be nothing more
 than a hunch.&nbsp; It shows that even 4MB is unsafe.&nbsp; SegWit =
provides up to this limit.<u class=3D""></u><u class=3D""></u></p>
</div>
<div class=3D""><p class=3D"MsoNormal"><u class=3D""></u>&nbsp;<u =
class=3D""></u></p>
</div>
<div class=3D""><p class=3D"MsoNormal">8MB is most definitely not safe =
today.<u class=3D""></u><u class=3D""></u></p>
</div>
<div class=3D""><p class=3D"MsoNormal"><u class=3D""></u>&nbsp;<u =
class=3D""></u></p>
</div>
<div class=3D""><p class=3D"MsoNormal">Whether it is unsafe or =
impossible is the topic, since Wang Chun proposed making the block size =
limit 32MiB. &nbsp;<u class=3D""></u><u class=3D""></u></p>
</div>
<div class=3D""><p class=3D"MsoNormal"><u class=3D""></u>&nbsp;<u =
class=3D""></u></p>
</div>
<div class=3D""><p class=3D"MsoNormal"><u class=3D""></u>&nbsp;<u =
class=3D""></u></p>
</div>
<div class=3D""><p class=3D"MsoNormal">Wang Chun,<u class=3D""></u><u =
class=3D""></u></p>
</div>
<div class=3D""><p class=3D"MsoNormal"><br class=3D"">
Can you specify what meeting you are talking about?&nbsp; You seem to =
have not replied on that point.&nbsp; Who were the participants and what =
was the purpose of this meeting?<u class=3D""></u><u class=3D""></u></p>
</div>
<div class=3D""><p class=3D"MsoNormal"><u class=3D""></u>&nbsp;<u =
class=3D""></u></p>
</div>
<div class=3D""><p class=3D"MsoNormal">-Alphonse<u class=3D""></u><u =
class=3D""></u></p>
</div>
<div class=3D""><p class=3D"MsoNormal"><u class=3D""></u>&nbsp;<u =
class=3D""></u></p>
<div class=3D""><p class=3D"MsoNormal">On Tue, Mar 28, 2017 at 12:33 PM, =
Juan Garavaglia &lt;<a href=3D"mailto:jg@112bit.com" target=3D"_blank" =
class=3D"">jg@112bit.com</a>&gt; wrote:<u class=3D""></u><u =
class=3D""></u></p>
<blockquote style=3D"border:none;border-left:solid #cccccc =
1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in" =
class=3D"">
<div class=3D"">
<div class=3D""><p class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D"">Alphonse,</span><u class=3D""></u><u class=3D""></u></p><p =
class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D"">&nbsp;</span><u class=3D""></u><u class=3D""></u></p><p =
class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D"">In my opinion if 1MB limit was ok in 2010, 8MB limit is ok on =
2016 and 32MB limit valid in next halving, from network,
 storage and CPU perspective or 1MB was too high in 2010 what is =
possible or 1MB is to low today.</span><u class=3D""></u><u =
class=3D""></u></p><p class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D"">&nbsp;</span><u class=3D""></u><u class=3D""></u></p><p =
class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D"">If is unsafe or impossible to raise the blocksize is a =
different topic.</span>&nbsp;<u class=3D""></u><u class=3D""></u></p>
</div>
</div>
</blockquote>
<blockquote style=3D"border:none;border-left:solid #cccccc =
1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in" =
class=3D"">
<div class=3D"">
<div class=3D""><p class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D"">&nbsp;</span><u class=3D""></u><u class=3D""></u></p><p =
class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D"">Regards</span><u class=3D""></u><u class=3D""></u></p><p =
class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D"">&nbsp;</span><u class=3D""></u><u class=3D""></u></p><p =
class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D"">Juan</span><u class=3D""></u><u class=3D""></u></p><p =
class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D"">&nbsp;</span><u class=3D""></u><u class=3D""></u></p><p =
class=3D"MsoNormal"><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D"">&nbsp;</span><u class=3D""></u><u class=3D""></u></p><p =
class=3D"MsoNormal"><b class=3D""><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D"">From:</span></b><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif" =
class=3D"">
<a href=3D"mailto:bitcoin-dev-bounces@lists.linuxfoundation.org" =
target=3D"_blank" class=3D"">bitcoin-dev-bounces@lists.<wbr =
class=3D"">linuxfoundation.org</a> [mailto:<a =
href=3D"mailto:bitcoin-dev-bounces@lists.linuxfoundation.org" =
target=3D"_blank" class=3D"">bitcoin-dev-bounces@<wbr =
class=3D"">lists.linuxfoundation.org</a>]
<b class=3D"">On Behalf Of </b>Alphonse Pace via bitcoin-dev<br =
class=3D"">
<b class=3D"">Sent:</b> Tuesday, March 28, 2017 2:24 PM<br class=3D"">
<b class=3D"">To:</b> Wang Chun &lt;<a href=3D"mailto:1240902@gmail.com" =
target=3D"_blank" class=3D"">1240902@gmail.com</a>&gt;; Bitcoin Protocol =
Discussion &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
target=3D"_blank" class=3D"">bitcoin-dev@lists.<wbr =
class=3D"">linuxfoundation.org</a>&gt;<br class=3D"">
<b class=3D"">Subject:</b> Re: [bitcoin-dev] Hard fork proposal from =
last week's meeting</span><u class=3D""></u><u class=3D""></u></p>
<div class=3D"">
<div class=3D""><p class=3D"MsoNormal">&nbsp;<u class=3D""></u><u =
class=3D""></u></p>
<div class=3D""><p class=3D"MsoNormal">What meeting are you referring =
to?&nbsp; Who were the participants?<u class=3D""></u><u =
class=3D""></u></p>
<div class=3D""><p class=3D"MsoNormal">&nbsp;<u class=3D""></u><u =
class=3D""></u></p>
</div>
<div class=3D""><p class=3D"MsoNormal">Removing the limit but relying on =
the p2p protocol is not really a true 32MiB limit, but a limit of =
whatever transport methods provide.&nbsp; This can lead to differing =
consensus if
 alternative layers for relaying are used.&nbsp; What you seem to be =
asking for is an unbound block size (or at least determined by whatever =
miners produce).&nbsp; This has the possibility (and even likelihood) of =
removing many participants from the network, including
 many small miners. &nbsp;<u class=3D""></u><u class=3D""></u></p>
</div>
<div class=3D""><p class=3D"MsoNormal">&nbsp;<u class=3D""></u><u =
class=3D""></u></p>
</div>
<div class=3D""><p class=3D"MsoNormal">32MB in less than 3 years also =
appears to be far beyond limits of safety which are known to exist far =
sooner, and we cannot expect hardware and networking layers to improve =
by those
 amounts in that time.<u class=3D""></u><u class=3D""></u></p>
</div>
<div class=3D""><p class=3D"MsoNormal">&nbsp;<u class=3D""></u><u =
class=3D""></u></p>
</div>
<div class=3D""><p class=3D"MsoNormal">It also seems like it would be =
much better to wait until SegWit activates in order to truly measure the =
effects on the network from this increased capacity before committing to
 any additional increases.<u class=3D""></u><u class=3D""></u></p>
</div>
<div class=3D""><p class=3D"MsoNormal">&nbsp;<u class=3D""></u><u =
class=3D""></u></p>
</div>
<div class=3D""><p class=3D"MsoNormal">-Alphonse<u class=3D""></u><u =
class=3D""></u></p>
</div>
<div class=3D""><p class=3D"MsoNormal">&nbsp;<u class=3D""></u><u =
class=3D""></u></p>
</div>
<div class=3D""><p class=3D"MsoNormal">&nbsp;<u class=3D""></u><u =
class=3D""></u></p>
</div>
</div>
<div class=3D""><p class=3D"MsoNormal">&nbsp;<u class=3D""></u><u =
class=3D""></u></p>
<div class=3D""><p class=3D"MsoNormal">On Tue, Mar 28, 2017 at 11:59 AM, =
Wang Chun via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
class=3D"">bitcoin-dev@lists.<wbr class=3D"">linuxfoundation.org</a>&gt; =
wrote:<u class=3D""></u><u class=3D""></u></p>
<blockquote style=3D"border:none;border-left:solid #cccccc =
1.0pt;padding:0in 0in 0in =
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.=
0pt" class=3D""><p class=3D"MsoNormal">I've proposed this hard fork =
approach last year in Hong Kong Consensus<br class=3D"">
but immediately rejected by coredevs at that meeting, after more than<br =
class=3D"">
one year it seems that lots of people haven't heard of it. So I would<br =
class=3D"">
post this here again for comment.<br class=3D"">
<br class=3D"">
The basic idea is, as many of us agree, hard fork is risky and should<br =
class=3D"">
be well prepared. We need a long time to deploy it.<br class=3D"">
<br class=3D"">
Despite spam tx on the network, the block capacity is approaching its<br =
class=3D"">
limit, and we must think ahead. Shall we code a patch right now, to<br =
class=3D"">
remove the block size limit of 1MB, but not activate it until far in<br =
class=3D"">
the future. I would propose to remove the 1MB limit at the next block<br =
class=3D"">
halving in spring 2020, only limit the block size to 32MiB which is<br =
class=3D"">
the maximum size the current p2p protocol allows. This patch must be<br =
class=3D"">
in the immediate next release of Bitcoin Core.<br class=3D"">
<br class=3D"">
With this patch in core's next release, Bitcoin works just as before,<br =
class=3D"">
no fork will ever occur, until spring 2020. But everyone knows there<br =
class=3D"">
will be a fork scheduled. Third party services, libraries, wallets =
and<br class=3D"">
exchanges will have enough time to prepare for it over the next three<br =
class=3D"">
years.<br class=3D"">
<br class=3D"">
We don't yet have an agreement on how to increase the block size<br =
class=3D"">
limit. There have been many proposals over the past years, like<br =
class=3D"">
BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so<br =
class=3D"">
on. These hard fork proposals, with this patch already in Core's<br =
class=3D"">
release, they all become soft fork. We'll have enough time to discuss<br =
class=3D"">
all these proposals and decide which one to go. Take an example, if =
we<br class=3D"">
choose to fork to only 2MB, since 32MiB already scheduled, reduce it<br =
class=3D"">
from 32MiB to 2MB will be a soft fork.<br class=3D"">
<br class=3D"">
Anyway, we must code something right now, before it becomes too late.<br =
class=3D"">
______________________________<wbr class=3D"">_________________<br =
class=3D"">
bitcoin-dev mailing list<br class=3D"">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
 class=3D"">bitcoin-dev@lists.<wbr class=3D"">linuxfoundation.org</a><br =
class=3D"">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"=
 target=3D"_blank" class=3D"">https://lists.linuxfoundation.<wbr =
class=3D"">org/mailman/listinfo/bitcoin-<wbr class=3D"">dev</a><u =
class=3D""></u><u class=3D""></u></p>
</blockquote>
</div><p class=3D"MsoNormal">&nbsp;<u class=3D""></u><u =
class=3D""></u></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div><p class=3D"MsoNormal"><u class=3D""></u>&nbsp;<u =
class=3D""></u></p>
</div>
</div>
</div></div></div>
</div>

<br class=3D"">______________________________<wbr =
class=3D"">_________________<br class=3D"">
bitcoin-dev mailing list<br class=3D"">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.<wbr class=3D"">linuxfoundation.org</a><br =
class=3D"">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"=
 rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://lists.linuxfoundation.<wbr =
class=3D"">org/mailman/listinfo/bitcoin-<wbr class=3D"">dev</a><br =
class=3D"">
<br class=3D""></blockquote></div><br class=3D""></div>
_______________________________________________<br class=3D"">bitcoin-dev =
mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""></div></blockquote></div><br class=3D""></body></html>=

--Apple-Mail=_FD40351F-41DC-4CFE-9CEC-22FB5F5DD556--