MIME-Version: 1.0
In-Reply-To: <CA+KqGkpFW8qDPVgY+11o_CC+6FMWUNUZ7REHJKYM9-3wbrUwYw@mail.gmail.com>
References: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com>
	<CA+KqGkpFW8qDPVgY+11o_CC+6FMWUNUZ7REHJKYM9-3wbrUwYw@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Wed, 29 Mar 2017 11:37:08 +0200
Message-ID: <CABm2gDrN5Wt9+2sVAjRiDG_axHmxF+iFujvApBMqrs-GjBG4pg@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Bram Cohen <bram@bittorrent.com>
Content-Type: multipart/alternative; boundary=001a114e605200d5d5054bdb529d
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
Precedence: list

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

While Segwit's change from 1 mb size limit to 4 mb weight limit seems to be
controversial among some users (I find that very often it is because they
have been confused about what segwit does or even outright lied about it) I
don't think it's very interesting to discuss further size increases.
I find more interesting to talk to the users and see how they think Segwit
harms them, maybe we missed something in segwit that needs to be removed
for segwit to become uncontroversial, or maybe it is just disinformation.

On the other hand, we may want to have our first uncontroversial hardfork
asap, independently of block size. For example, we could do something as
simple as fixing the timewarp attack as bip99 proposes. I cannot think of a
hf that is easier to implement or has less potential for controversy than
that.

On 29 Mar 2017 8:32 am, "Bram Cohen via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

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.


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

<div dir=3D"auto"><div>While Segwit&#39;s change from 1 mb size limit to 4 =
mb weight limit seems to be controversial among some users (I find that ver=
y often it is because they have been confused about what segwit does or eve=
n outright lied about it) I don&#39;t think it&#39;s very interesting to di=
scuss further size increases.</div><div dir=3D"auto">I find more interestin=
g to talk to the users and see how they think Segwit harms them, maybe we m=
issed something in segwit that needs to be removed for segwit to become unc=
ontroversial, or maybe it is just disinformation.=C2=A0</div><div dir=3D"au=
to"><br></div><div dir=3D"auto">On the other hand, we may want to have our =
first uncontroversial hardfork asap, independently of block size. For examp=
le, we could do something as simple as fixing the timewarp attack as bip99 =
proposes. I cannot think of a hf that is easier to implement or has less po=
tential for controversy than that.<br><div class=3D"gmail_extra" dir=3D"aut=
o"><br><div class=3D"gmail_quote">On 29 Mar 2017 8:32 am, &quot;Bram Cohen =
via bitcoin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br type=3D"att=
ribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><div class=3D"quoted-text">On Tue, Mar 28, 2=
017 at 9:59 AM, Wang Chun via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev=
@lists.<wbr>linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-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><div>Much as it may be appealing to repeal the block size lim=
it now with a grace period until a replacement is needed in a repeal and re=
place 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 i=
t runs into the possibility that you&#39;ll find that whatever reasons ther=
e 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.</div><div><br></div></div></div></d=
iv>
<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>
<br></blockquote></div><br></div></div></div>

--001a114e605200d5d5054bdb529d--