MIME-Version: 1.0
In-Reply-To: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com>
References: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com>
From: Bram Cohen <bram@bittorrent.com>
Date: Tue, 28 Mar 2017 23:32:20 -0700
Message-ID: <CA+KqGkpFW8qDPVgY+11o_CC+6FMWUNUZ7REHJKYM9-3wbrUwYw@mail.gmail.com>
To: Wang Chun <1240902@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114220ac1d7ba6054bd8bd94
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
Precedence: list

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

On Tue, Mar 28, 2017 at 9:59 AM, Wang Chun via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

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

Much as it may be appealing to repeal the block size limit now with a grace
period until a replacement is needed in a repeal and replace strategy, it's
dubious to assume that an idea can be agreed upon later when it can't be
agreed upon now. Trying to put a time limit on it runs into the possibility
that you'll find that whatever reasons there were for not having general
agreement on a new setup before still apply, and running into the
embarrassing situation of winding up sticking with the status quo after
much sturm and drang.

--001a114220ac1d7ba6054bd8bd94
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 T=
ue, Mar 28, 2017 at 9:59 AM, Wang Chun via bitcoin-dev <span dir=3D"ltr">&l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank=
">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><br>
The basic idea is, as many of us agree, hard fork is risky and should<br>
be well prepared. We need a long time to deploy it.<br></blockquote><div><b=
r></div><div>Much as it may be appealing to repeal the block size limit now=
 with a grace period until a replacement is needed in a repeal and replace =
strategy, it&#39;s dubious to assume that an idea can be agreed upon later =
when it can&#39;t be agreed upon now. Trying to put a time limit on it runs=
 into the possibility that you&#39;ll find that whatever reasons there were=
 for not having general agreement on a new setup before still apply, and ru=
nning into the embarrassing situation of winding up sticking with the statu=
s quo after much sturm and drang.</div><div><br></div></div></div></div>

--001a114220ac1d7ba6054bd8bd94--