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

From: Jared Lee Richardson <jaredr26@gmail•com>
To: "Jorge Timón" <jtimon@jtimon•cc>,
	"Bitcoin Protocol Discussion"
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
Date: Wed, 29 Mar 2017 12:07:15 -0700	[thread overview]
Message-ID: <CAD1TkXuEE4ajE071R32skuHOq-0QHJuaO0OpztfSq=ZXpvd6Pw@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDrN5Wt9+2sVAjRiDG_axHmxF+iFujvApBMqrs-GjBG4pg@mail.gmail.com>

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

> While Segwit's change from 1 mb size limit to 4 mb weight limit seems to
be controversial among some users [..] I don't think it's very interesting
to discuss further size increases.

I think the reason for this is largely because SegWit as a blocksize
increase isn't very satisfying.  It resolves to a one-time increase with no
future plans, thus engendering the same objections as people who demand we
just "raise the number to N."  People can argue about what N should be, but
when N is just a flat number, we know we'll have to deal with the issue
again.

In that light I think it is even more essential to continue to discuss the
blocksize debate and problem.

> I find more interesting to talk to the users and see how they think
Segwit harms them,

From an inordinant amount of time spent reading Reddit, I believe this
largely comes down to the rumor that has a deathgrip on the BU community -
That Core are all just extensions of Blockstream, and blockstream wants to
restrict growth on-chain to force growth of their 2nd layer
services(lightning and/or sidechains).

I believe the tone of the discussion needs to be changed, and have been
trying to work to change that tone for weeks now.  There's one faction that
believes that Bitcoin will rarely, if ever, benefit from a blocksize
increase, and fees rising is a desired/unavoidable result.  There's a
different faction that believes Bitcoin limits are arbitrary and that all
people worldwide should be able to put any size transactions, even
microtransactions, on-chain.  Both factions are extreme in their viewpoints
and resort to conspiracy theories to interpret the actions of
Core(blockstream did it) or BU(Jihan controls everything and anyone who
says overwise is a shill paid by Roger Ver!)

It is all very unhealthy for Bitcoin.  Both sides need to accept that
microtransactions from all humans cannot go on-chain, and that never
increasing the blocksize doesn't mean millions of home users will run
nodes.  The node argument breaks down economically and the microtransaction
argument is an impossible mountain for a blockchain to climb.

On Wed, Mar 29, 2017 at 2:37 AM, Jorge Timón via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> 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
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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