MIME-Version: 1.0
In-Reply-To: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
From: Yifu Guo <yifu@coinapex.com>
Date: Fri, 5 Feb 2016 17:36:09 -0500
Message-ID: <CAHcfU-V7V8oerKPzuxE1iwZezFnQ1WTCC9g_rGmp7C56wpT19w@mail.gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=089e0160b7c698c88c052b0d7cef
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
	megabytes
Precedence: list

--089e0160b7c698c88c052b0d7cef
Content-Type: text/plain; charset=UTF-8

"We can look at the adoption of the last major Bitcoin core release to
guess how long it might take people to upgrade. 0.11.0 was released on 12
July, 2015. Twenty eight days later, about 38% of full nodes were running
that release. Three months later, about 50% of the network was running that
release, and six months later about 66% of the network was running some
flavor of 0.11."

On what grounds do you think it is reasonable to assume that this update
will roll out 6x faster than previous data suggested, as oppose to your own
observation of 66% adoption in 6 month. or do you believe 38% node
upgrade-coverage ( in 28 days ) on the network for a hard fork is good
enough?

There are no harm in choosing a longer grace period but picking one short
as 28 days you risk on alienating the nodes who do not upgrade with the
aggressive upgrade timeline you proposed.


On Fri, Feb 5, 2016 at 3:51 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> This has been reviewed by merchants, miners and exchanges for a couple of
> weeks, and has been implemented and tested as part of the Bitcoin Classic
> and Bitcoin XT implementations.
>
> Constructive feedback welcome; argument about whether or not it is a good
> idea to roll out a hard fork now will be unproductive, so I vote we don't
> go there.
>
> Draft BIP:
>   https://github.com/gavinandresen/bips/blob/bump2mb/bip-bump2mb.mediawiki
>
> Summary:
>   Increase block size limit to 2,000,000 bytes.
>   After 75% hashpower support then 28-day grace period.
>   With accurate sigop counting, but existing sigop limit (20,000)
>   And a new, high limit on signature hashing
>
> Blog post walking through the code:
>   http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork
>
> Blog post on a couple of the constants chosen:
>   http://gavinandresen.ninja/seventyfive-twentyeight
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


-- 
*Yifu Guo*
*"Life is an everlasting self-improvement."*

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

<div dir=3D"ltr">&quot;We can look at the adoption of the last major Bitcoi=
n core release to guess how long it might take people to upgrade. 0.11.0 wa=
s released on 12 July, 2015. Twenty eight days later, about 38% of full nod=
es were running that release. Three months later, about 50% of the network =
was running that release, and six months later about 66% of the network was=
 running some flavor of 0.11.&quot;<div><br></div><div>On what grounds do y=
ou think it is reasonable to assume that this update will roll out 6x faste=
r than previous data suggested, as oppose to your own observation of 66% ad=
option in 6 month. or do you believe 38% node upgrade-coverage ( in 28 days=
 ) on the network for a hard fork is good enough?</div><div><br></div><div>=
There are no harm in choosing a longer grace period but picking one short a=
s 28 days you risk on alienating the nodes who do not upgrade with the aggr=
essive upgrade timeline you proposed.</div><div><br></div><div><br></div></=
div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Feb 5=
, 2016 at 3:51 PM, Gavin Andresen via bitcoin-dev <span dir=3D"ltr">&lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bit=
coin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">This has been reviewed by merchants, miner=
s and exchanges for a couple of weeks, and has been implemented and tested =
as part of the Bitcoin Classic and Bitcoin XT implementations.<div><br></di=
v><div>Constructive feedback welcome; argument about whether or not it is a=
 good idea to roll out a hard fork now will be unproductive, so I vote we d=
on&#39;t go there.</div><div><br></div><div>Draft BIP:</div><div>=C2=A0=C2=
=A0<a href=3D"https://github.com/gavinandresen/bips/blob/bump2mb/bip-bump2m=
b.mediawiki" target=3D"_blank">https://github.com/gavinandresen/bips/blob/b=
ump2mb/bip-bump2mb.mediawiki</a></div><div><br></div><div>Summary: =C2=A0</=
div><div>=C2=A0 Increase block size limit to 2,000,000 bytes.</div><div>=C2=
=A0 After 75% hashpower support then 28-day grace period.</div><div>=C2=A0 =
With accurate sigop counting, but existing sigop limit (20,000)</div><div>=
=C2=A0 And a new, high limit on signature hashing</div><div><br></div><div>=
Blog post walking through the code:</div><div>=C2=A0=C2=A0<a href=3D"http:/=
/gavinandresen.ninja/a-guided-tour-of-the-2mb-fork" target=3D"_blank">http:=
//gavinandresen.ninja/a-guided-tour-of-the-2mb-fork</a><br><div><br></div><=
div>Blog post on a couple of the constants chosen:</div><div>=C2=A0=C2=A0<a=
 href=3D"http://gavinandresen.ninja/seventyfive-twentyeight" target=3D"_bla=
nk">http://gavinandresen.ninja/seventyfive-twentyeight</a></div><span class=
=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div>-- <br><div><div di=
r=3D"ltr"><div dir=3D"ltr"><div>--<br>Gavin Andresen<br></div><div><br></di=
v></div></div></div>
</div></font></span></div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div cla=
ss=3D"gmail_signature"><div dir=3D"ltr"><span style=3D"font-size:small;colo=
r:rgb(136,136,136)"><font face=3D"garamond, serif" size=3D"4"><b>Yifu Guo</=
b></font></span><div style=3D"font-size:small"><font face=3D"verdana, sans-=
serif"><div style=3D"font-size:13px"><font size=3D"1" color=3D"#333333"><i>=
&quot;Life is an everlasting self-improvement.&quot;</i></font></div></font=
></div></div></div>
</div>

--089e0160b7c698c88c052b0d7cef--