MIME-Version: 1.0
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
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
Precedence: list

--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--