From: Luke Dashjr <luke@dashjr.org>
To: Anthony Towns <aj@erisian.com.au>
Date: Sun, 12 Jan 2020 05:58:33 +0000
User-Agent: KMail/1.9.10
References: <20200111144207.5xzspeptstspsbsf@erisian.com.au>
In-Reply-To: <20200111144207.5xzspeptstspsbsf@erisian.com.au>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <202001120558.34256.luke@dashjr.org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Modern Soft Fork Activation
Precedence: list

On Saturday 11 January 2020 14:42:07 Anthony Towns wrote:
>  the UASF approach had significant potential technical problems
> =A0 =A0 =A0 =A0(potential for long reorgs, p2p network splits) that weren=
't
> =A0 =A0 =A0 =A0resolved by the time it became active.

Long reorgs, only for old nodes, were a possibility, but not a problem.

The p2p network split issues WERE resolved well before activation.
(In fact, Bitcoin Knots still ships with the general p2p fixes.)

> =A0 =A0 =A0 =A0neither=20
> =A0 =A0 =A0 =A0BIP-148 or BIP-91 gained enough consensus to be supported =
in
> =A0 =A0 =A0 =A0bitcoin core though

There was no measurable difference in community support between BIP148 and=
=20
Segwit itself, months before BIP148's activation. (There was about 20% that=
=20
indicated they would support BIP148 "only if Bitcoin Core releases it", whi=
ch=20
IMO "counts" in this context.)

The only difference was in the opinions of developers. Basing the decision =
to=20
exclude BIP148 as even an *option* on this basis was IMO improper and=20
shouldn't be repeated. The community's readiness to switch to another=20
fork/build for UASFs is also valuable, but shouldn't be necessary.

Luke