MIME-Version: 1.0
In-Reply-To: <CAKzdR-oRdX-fXyc6womZOyYyfHUJZdgh92FUMM8pR_QDNiJfkQ@mail.gmail.com>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
	<CADJgMzuCcJhoEbaGUv8QgaaL82+UiV6Q9Tbbti++J=Jg5B=sgg@mail.gmail.com>
	<A7FFF8F7-9806-44F1-B68F-F83C44893365@ob1.io>
	<CAKzdR-oRdX-fXyc6womZOyYyfHUJZdgh92FUMM8pR_QDNiJfkQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Mon, 10 Jul 2017 20:38:08 +0200
Message-ID: <CABm2gDo0wgqkEufKn=Z8uAsi=_6fgE=0TS6Bcr21mg3xAX7Kyw@mail.gmail.com>
To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Segwit2x BIP
Precedence: list

On Mon, Jul 10, 2017 at 1:50 PM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Regarding the timeline, its certainly rather short, but also is the UASF BIP
> 148 ultimatum.

This is correct. If you are trying to imply that makes the short
timeline here right, you are falling for a "tu quoque" fallacy.

> More than 80% of the miners and many users are willing to go in the Segwit2x
> direction.

There's no logical reason I can think of (and I've heard many attempts
at explaining it) for miners to consider segwit bad for Bitcoin but
segwitx2 harmless. But I don't see 80% hashrate support for bip141, so
your claim doesn't seem accurate for the segwit part, let alone the
more controversial hardfork part.

I read some people controlling mining pools that control 80% of the
hashrate signed a paper saying they would "support segwit
immediately". Either what I read wasn't true, or the signed paper is
just a proof of the signing pool operators word being something we
cannot trust.

So where does this 80% figure come from? How can we trust the source?

> I want a Bitcoin united. But maybe a split of Bitcoin, each side with its
> own vision, is not so bad.

It would be unfortunate to split the network into 2 coins only because
of lack of patience for deploying non-urgent consensus changes like a
size increase or disagreements about the right time schedule.
I think anything less than 1 year after release of tested code by some
implementation would be irresponsible for any hardfork, even a very
simple one.