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 = <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" = class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" = class=3D"">><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 </span><span = style=3D"font-family:calibri,sans-serif;font-size:14.6667px" = class=3D"">argue that the 4MB size </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%. </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 </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. </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. </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""><<a = href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" = class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>></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:"Calibri",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:"Calibri",sans-serif" = class=3D""><u class=3D""></u> <u class=3D""></u></span></p><p = class=3D"MsoNormal"><span = style=3D"font-size:11.0pt;font-family:"Calibri",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:"Calibri",sans-serif" = class=3D""><u class=3D""></u> <u class=3D""></u></span></p><p = class=3D"MsoNormal"><span = style=3D"font-size:11.0pt;font-family:"Calibri",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:"Calibri",sans-serif" = class=3D""><u class=3D""></u> <u class=3D""></u></span></p><p = class=3D"MsoNormal"><span = style=3D"font-size:11.0pt;font-family:"Calibri",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:"Calibri",sans-serif" = class=3D""><u class=3D""></u> <u class=3D""></u></span></p><p = class=3D"MsoNormal"><span = style=3D"font-size:11.0pt;font-family:"Calibri",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:"Calibri",sans-serif" = class=3D""><u class=3D""></u> <u class=3D""></u></span></p><p = class=3D"MsoNormal"><span = style=3D"font-size:11.0pt;font-family:"Calibri",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:"Calibri",sans-serif" = class=3D""><u class=3D""></u> <u class=3D""></u></span></p><p = class=3D"MsoNormal"><span = style=3D"font-size:11.0pt;font-family:"Calibri",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:"Calibri",sans-serif" = class=3D""><u class=3D""></u> <u class=3D""></u></span></p><p = class=3D"MsoNormal"><span = style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif" = class=3D""><u class=3D""></u> <u class=3D""></u></span></p><p = class=3D"MsoNormal"><b class=3D""><span = style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif" = class=3D"">From:</span></b><span = style=3D"font-size:11.0pt;font-family:"Calibri",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 <<a href=3D"mailto:jg@112bit.com"= target=3D"_blank" class=3D"">jg@112bit.com</a>>; Wang Chun <<a = href=3D"mailto:1240902@gmail.com" target=3D"_blank" = class=3D"">1240902@gmail.com</a>><br class=3D""> <b class=3D"">Cc:</b> Bitcoin Protocol Discussion <<a = href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" = class=3D"">bitcoin-dev@lists.<wbr = class=3D"">linuxfoundation.org</a>></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> <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> <u = class=3D""></u></p> </div> <div class=3D""><p class=3D"MsoNormal">I suggest you take a look at this = paper: <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> 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.<u class=3D""></u><u class=3D""></u></p> </div> <div class=3D""><p class=3D"MsoNormal"><u class=3D""></u> <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> <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. <u class=3D""></u><u class=3D""></u></p> </div> <div class=3D""><p class=3D"MsoNormal"><u class=3D""></u> <u = class=3D""></u></p> </div> <div class=3D""><p class=3D"MsoNormal"><u class=3D""></u> <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? You seem to = have not replied on that point. 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> <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> <u = class=3D""></u></p> <div class=3D""><p class=3D"MsoNormal">On Tue, Mar 28, 2017 at 12:33 PM, = Juan Garavaglia <<a href=3D"mailto:jg@112bit.com" target=3D"_blank" = class=3D"">jg@112bit.com</a>> 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:"Calibri",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:"Calibri",sans-serif" = class=3D""> </span><u class=3D""></u><u class=3D""></u></p><p = class=3D"MsoNormal"><span = style=3D"font-size:11.0pt;font-family:"Calibri",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:"Calibri",sans-serif" = class=3D""> </span><u class=3D""></u><u class=3D""></u></p><p = class=3D"MsoNormal"><span = style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif" = class=3D"">If is unsafe or impossible to raise the blocksize is a = different topic.</span> <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:"Calibri",sans-serif" = class=3D""> </span><u class=3D""></u><u class=3D""></u></p><p = class=3D"MsoNormal"><span = style=3D"font-size:11.0pt;font-family:"Calibri",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:"Calibri",sans-serif" = class=3D""> </span><u class=3D""></u><u class=3D""></u></p><p = class=3D"MsoNormal"><span = style=3D"font-size:11.0pt;font-family:"Calibri",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:"Calibri",sans-serif" = class=3D""> </span><u class=3D""></u><u class=3D""></u></p><p = class=3D"MsoNormal"><span = style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif" = class=3D""> </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:"Calibri",sans-serif" = class=3D"">From:</span></b><span = style=3D"font-size:11.0pt;font-family:"Calibri",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 <<a href=3D"mailto:1240902@gmail.com" = target=3D"_blank" class=3D"">1240902@gmail.com</a>>; Bitcoin Protocol = Discussion <<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""> <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"> <u class=3D""></u><u = class=3D""></u></p> <div class=3D""><p class=3D"MsoNormal">What meeting are you referring = to? Who were the participants?<u class=3D""></u><u = class=3D""></u></p> <div class=3D""><p class=3D"MsoNormal"> <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. 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. <u class=3D""></u><u class=3D""></u></p> </div> <div class=3D""><p class=3D"MsoNormal"> <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"> <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"> <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"> <u class=3D""></u><u = class=3D""></u></p> </div> <div class=3D""><p class=3D"MsoNormal"> <u class=3D""></u><u = class=3D""></u></p> </div> </div> <div class=3D""><p class=3D"MsoNormal"> <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 <<a = href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" = class=3D"">bitcoin-dev@lists.<wbr class=3D"">linuxfoundation.org</a>> = 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"> <u class=3D""></u><u = class=3D""></u></p> </div> </div> </div> </div> </div> </blockquote> </div><p class=3D"MsoNormal"><u class=3D""></u> <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--