Re: [bitcoin-dev] Hard fork proposal from last week's meeting

From: "Jorge Timón" <jtimon@jtimon•cc>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>,
	Bram Cohen <bram@bittorrent•com>
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
Date: Wed, 29 Mar 2017 11:37:08 +0200	[thread overview]
Message-ID: <CABm2gDrN5Wt9+2sVAjRiDG_axHmxF+iFujvApBMqrs-GjBG4pg@mail.gmail.com> (raw)
In-Reply-To: <CA+KqGkpFW8qDPVgY+11o_CC+6FMWUNUZ7REHJKYM9-3wbrUwYw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2889 bytes --]