path: root/1f/b235c605cb517bdf8f75cf437089aeeb5a956f

Return-Path: <jaredr26@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B6353899
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 08:45:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f49.google.com (mail-vk0-f49.google.com
	[209.85.213.49])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ED191AF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 08:45:15 +0000 (UTC)
Received: by mail-vk0-f49.google.com with SMTP id z204so9744898vkd.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 01:45:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=CVKnSUjiAFmrcxBgiMA/o3FHmvRVLjG1SKEGohoPAuA=;
	b=Z7KycD7wThKKR1zCHT57kRfsgjkNsspZ4OUu9HfRfTB1lO+r+4HVDhNhuXdicMcp07
	h9BqsOsGVmkmFG91cAGr9aApxguzao1nEM8fwMHR8T6iDw4OE00LwhG8o3YfblC/3s07
	727dPem98bwkmm4+THSnXc0JezmmQW5fJ41Ul2dYc8dgy3yhtBQRCQkVOfrK0eWwH7Tj
	4OsEu8189P1wu0V1bBoxK7EgxYTs27eH8n6bfjdHnlYMrScB6V6UuxHonEBkc4IHWxqI
	gOIqg0YBWKFS49tWrAASdPH8NpjbzoOKWdjCePXkJycuNoIU6NmWxqvI6DIgDzXUrhPJ
	IKog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=CVKnSUjiAFmrcxBgiMA/o3FHmvRVLjG1SKEGohoPAuA=;
	b=btA/6ztEsDAGGTAqXA5qXDkPmvgWRB2niF7U/v1en6wnEIAimc61+Th44msxq2HLYc
	6CESeGON8AWwLTQxQDmVeRu19PMIKbhSpnTciTbL5MOXy3SzHeOgZTb1+RD+nnYgOTeh
	XSQl70npNiJRDx5D65bRwglgCefA4JpnOJQs36VoRANsF5lS3Tn0RuhbCjctV7BOeAxC
	qSJxaFdfx8IwOJM9iuLMHMwUEGffhu/YNJ5zkEkLiEbBvkIF8XuW0gFTLHV7l47R0auF
	BC7QScvfAenow8kryQWDJ2Sd7lrpvrBMqd71f0YMbxDugIXEvLCJ9z89DH1NicYdZ6Xy
	clIg==
X-Gm-Message-State: AFeK/H1/aImjYhugbkV1VJ2ndButVsCMmM3ts/L88ii24acxMVTfzvJPRMrfbPfrJRylmyNZdCritz2///4KBQ==
X-Received: by 10.176.69.161 with SMTP id u30mr3576214uau.69.1490777115026;
	Wed, 29 Mar 2017 01:45:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.157.143 with HTTP; Wed, 29 Mar 2017 01:45:14 -0700 (PDT)
In-Reply-To: <6d7e8bb9-ef08-70bb-1609-66b063e500f1@mattcorallo.com>
References: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com>
	<6d7e8bb9-ef08-70bb-1609-66b063e500f1@mattcorallo.com>
From: Jared Lee Richardson <jaredr26@gmail.com>
Date: Wed, 29 Mar 2017 01:45:14 -0700
Message-ID: <CAD1TkXtn=9F8UW1dozRRsOVWzduUdX84EckE2igzAo_ky8EThg@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c11c960616e90054bda98d1
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 29 Mar 2017 13:47:52 +0000
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 08:45:16 -0000

--94eb2c11c960616e90054bda98d1
Content-Type: text/plain; charset=UTF-8

> That said, for that to be alleviated we
could simply do something based on historical transaction growth (which
is somewhat linear, with a few inflection points),

Where do you get this?  Transaction growth for the last 4 years averages to
+65% per year and the last 2 is +80% per year.  That's very much not linear.



On Tue, Mar 28, 2017 at 10:13 AM, Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Not sure what "last week's meeting" is in reference to?
>
> Agreed that the hard fork should be well-prepared, but I think its
> dangerous to think that a hard fork as agreed upon would be a simple
> relaxation of the block size. For example, Johnson Lau's previous
> proposal, Spoonnet, which I think is probably one of the better ones,
> would be incompatible with these rules.
>
> I, of course, worry about what happens if we cannot come to consensus on
> a number to soft fork down to, potentially significantly risking miner
> profits (and, thus, the security of Bitcoin) if a group is able to keep
> things "at the status quo". That said, for that to be alleviated we
> could simply do something based on historical transaction growth (which
> is somewhat linear, with a few inflection points), but that number ends
> up being super low (eg somewhere around 2MB at the next halving, which
> SegWit itself already provides :/.
>
> We could, of course, focus on designing a hard fork's activation and
> technical details, with a very large block size increase in it (ie
> closer to 4/6MB at the next halving or so, something we at least could
> be confident we could develop software for), with intention to soft fork
> it back down if miner profits are suffering.
>
> Matt
>
> On 03/28/17 16:59, Wang Chun via bitcoin-dev wrote:
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > Anyway, we must code something right now, before it becomes too late.
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">&gt;=C2=A0<span style=3D"font-size:12.8px">That said, for =
that to be alleviated we</span><br style=3D"font-size:12.8px"><span style=
=3D"font-size:12.8px">could simply do something based on historical transac=
tion growth (which</span><br style=3D"font-size:12.8px"><span style=3D"font=
-size:12.8px">is somewhat linear, with a few inflection points),<br><br>Whe=
re do you get this?=C2=A0 Transaction growth for the last 4 years averages =
to +65% per year and the last 2 is +80% per year.=C2=A0 That&#39;s very muc=
h not linear.<br><br><br></span></div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">On Tue, Mar 28, 2017 at 10:13 AM, Matt Corallo via bit=
coin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">Not sure what &quot;last =
week&#39;s meeting&quot; is in reference to?<br>
<br>
Agreed that the hard fork should be well-prepared, but I think its<br>
dangerous to think that a hard fork as agreed upon would be a simple<br>
relaxation of the block size. For example, Johnson Lau&#39;s previous<br>
proposal, Spoonnet, which I think is probably one of the better ones,<br>
would be incompatible with these rules.<br>
<br>
I, of course, worry about what happens if we cannot come to consensus on<br=
>
a number to soft fork down to, potentially significantly risking miner<br>
profits (and, thus, the security of Bitcoin) if a group is able to keep<br>
things &quot;at the status quo&quot;. That said, for that to be alleviated =
we<br>
could simply do something based on historical transaction growth (which<br>
is somewhat linear, with a few inflection points), but that number ends<br>
up being super low (eg somewhere around 2MB at the next halving, which<br>
SegWit itself already provides :/.<br>
<br>
We could, of course, focus on designing a hard fork&#39;s activation and<br=
>
technical details, with a very large block size increase in it (ie<br>
closer to 4/6MB at the next halving or so, something we at least could<br>
be confident we could develop software for), with intention to soft fork<br=
>
it back down if miner profits are suffering.<br>
<br>
Matt<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On 03/28/17 16:59, Wang Chun via bitcoin-dev wrote:<br>
&gt; I&#39;ve proposed this hard fork approach last year in Hong Kong Conse=
nsus<br>
&gt; but immediately rejected by coredevs at that meeting, after more than<=
br>
&gt; one year it seems that lots of people haven&#39;t heard of it. So I wo=
uld<br>
&gt; post this here again for comment.<br>
&gt;<br>
&gt; The basic idea is, as many of us agree, hard fork is risky and should<=
br>
&gt; be well prepared. We need a long time to deploy it.<br>
&gt;<br>
&gt; Despite spam tx on the network, the block capacity is approaching its<=
br>
&gt; limit, and we must think ahead. Shall we code a patch right now, to<br=
>
&gt; remove the block size limit of 1MB, but not activate it until far in<b=
r>
&gt; the future. I would propose to remove the 1MB limit at the next block<=
br>
&gt; halving in spring 2020, only limit the block size to 32MiB which is<br=
>
&gt; the maximum size the current p2p protocol allows. This patch must be<b=
r>
&gt; in the immediate next release of Bitcoin Core.<br>
&gt;<br>
&gt; With this patch in core&#39;s next release, Bitcoin works just as befo=
re,<br>
&gt; no fork will ever occur, until spring 2020. But everyone knows there<b=
r>
&gt; will be a fork scheduled. Third party services, libraries, wallets and=
<br>
&gt; exchanges will have enough time to prepare for it over the next three<=
br>
&gt; years.<br>
&gt;<br>
&gt; We don&#39;t yet have an agreement on how to increase the block size<b=
r>
&gt; limit. There have been many proposals over the past years, like<br>
&gt; BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so<b=
r>
&gt; on. These hard fork proposals, with this patch already in Core&#39;s<b=
r>
&gt; release, they all become soft fork. We&#39;ll have enough time to disc=
uss<br>
&gt; all these proposals and decide which one to go. Take an example, if we=
<br>
&gt; choose to fork to only 2MB, since 32MiB already scheduled, reduce it<b=
r>
&gt; from 32MiB to 2MB will be a soft fork.<br>
&gt;<br>
&gt; Anyway, we must code something right now, before it becomes too late.<=
br>
&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt;<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>

--94eb2c11c960616e90054bda98d1--