MIME-Version: 1.0
In-Reply-To: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
From: Btc Drak <btcdrak@gmail.com>
Date: Fri, 5 Feb 2016 23:04:09 +0000
Message-ID: <CADJgMztVG0WSZ5mgG87eZGCGqvS1BjK9uKSXaaFmdTyHxD-v0g@mail.gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a113a6538886b03052b0ddfd9
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
	megabytes
Precedence: list

--001a113a6538886b03052b0ddfd9
Content-Type: text/plain; charset=UTF-8

On Fri, Feb 5, 2016 at 8: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
>

It's great to finally see a BIP, although seems strange to ask for feedback
after releasing binaries.

In any case, the issue isn't about "whether or not it is a good idea to
roll out a hard fork", the question has always been about how to do safe
hard fork deployment and what the technological requirements are for doing
so. Your BIP/blogs do not actually address any of this. 75% miner
signalling with a 28 day flag day thereafter gives virtually no time for
the entire ecosystem to migrate and is widely considered unsafe. It's
plainly obvious that an entire ecosystem of 5000 full nodes cannot be
prepared in a month.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Feb 5, 2016 at 8:51 PM, Gavin Andresen via bitcoin-dev <span dir=3D"ltr=
">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex"><div dir=3D"ltr">This has been reviewed by merchants, miners and=
 exchanges for a couple of weeks, and has been implemented and tested as pa=
rt of the Bitcoin Classic and Bitcoin XT implementations.<div><br></div><di=
v>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=
9;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-bump2mb.medi=
awiki" target=3D"_blank">https://github.com/gavinandresen/bips/blob/bump2mb=
/bip-bump2mb.mediawiki</a></div><div><br></div><div>Summary: =C2=A0</div><d=
iv>=C2=A0 Increase block size limit to 2,000,000 bytes.</div><div>=C2=A0 Af=
ter 75% hashpower support then 28-day grace period.</div><div>=C2=A0 With a=
ccurate 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 po=
st walking through the code:</div><div>=C2=A0=C2=A0<a href=3D"http://gavina=
ndresen.ninja/a-guided-tour-of-the-2mb-fork" target=3D"_blank">http://gavin=
andresen.ninja/a-guided-tour-of-the-2mb-fork</a><br><div><br></div><div>Blo=
g post on a couple of the constants chosen:</div><div>=C2=A0=C2=A0<a href=
=3D"http://gavinandresen.ninja/seventyfive-twentyeight" target=3D"_blank">h=
ttp://gavinandresen.ninja/seventyfive-twentyeight</a></div></div></div></bl=
ockquote><div><br></div><div style=3D"font-size:12.8px">It&#39;s great to f=
inally see a BIP, although seems strange to ask for feedback after releasin=
g binaries.<br></div><div style=3D"font-size:12.8px"><br></div><div><span s=
tyle=3D"font-size:12.8px">In any case, the issue isn&#39;t about &quot;whet=
her or not it is a good idea to roll out a hard fork&quot;, the question ha=
s always been about how to do safe hard fork deployment and what the techno=
logical requirements are for doing so. Your BIP/blogs do not actually addre=
ss any of this. 75% miner signalling with a 28 day flag day thereafter give=
s virtually no time for the entire ecosystem to migrate and is widely consi=
dered unsafe. It&#39;s plainly obvious that an entire ecosystem of 5000 ful=
l nodes cannot be prepared in a month.</span></div><div><br></div></div></d=
iv></div>

--001a113a6538886b03052b0ddfd9--