Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
In-Reply-To: <20190816160650.artngylrzy2id5tr@petertodd.org>
Date: Fri, 16 Aug 2019 13:44:47 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <2377A2C2-04E6-4128-A756-2909474C423C@voskuil.org>
References: <CAFmfg2tv4AP6GYSeHkgOYBKiWa3ia_KxWWBBjqY5u4-GkW6oLw@mail.gmail.com>
	<20190816160650.artngylrzy2id5tr@petertodd.org>
To: Peter Todd <pete@petertodd.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Cc: John Newbery <john@johnnewbery.com>
Subject: Re: [bitcoin-dev] Burying CSV and segwit soft fork activations
Precedence: list

Thanks for adding this to the record.

And for the record I=E2=80=99ll reiterate here, as I did with BIP90, that th=
is is a hard fork.

e

> On Aug 16, 2019, at 12:06, Peter Todd via bitcoin-dev <bitcoin-dev@lists.l=
inuxfoundation.org> wrote:
>=20
>> On Fri, Aug 16, 2019 at 11:23:37AM -0400, John Newbery via bitcoin-dev wr=
ote:
>> Once a consensus change has been activated and buried by sufficient work,=

>> we consider the height of that change to be historic fact. The exact
>> activation method is no longer of practical interest. In some cases the
>> cause of activation is not even decidable. For example, we know that segw=
it
>> activated at height 481,824 but it's debatable whether that was due to BI=
P
>> 9 version bits signaling, BIP 148 UASF, or a combination of the two.
>=20
> I just wanted to elaborate on this excellent point:
>=20
> This is debatable because Bitcoin is a decentralized, soft-forks are backw=
ards
> compatible, and it's very difficult if not impossible to measure the
> preferences of economically significant nodes. Both the BIP9 version bits
> signalling and the BIP 148 UASF had the same basic effect: enforce segwit.=

> Furthermore, the BIP 148 UASF rejected blocks that didn't signal via the B=
IP9
> version bits.
>=20
> We can observe the fact that 100% of known blocks produced after Aug 1st 2=
017
> have complied with segwit rules, and the BIP9 signalling protocol for segw=
it.
> But strictly speaking we don't really know why that happened. It's possibl=
e
> that miners were running the BIP9 signalling Bitcoin Core release around t=
hat
> time. It's also possible that miners were running UASF enforcing software.=

> It's possible there was a combination of both. Or even entirely different
> software - remember that some miners produced segwit-valid blocks, but did=
n't
> actually mine segwit transactions. Each scenario leads to the same externa=
lly
> observable outcome.
>=20
> Furthermore there's the question as to why miners were producing
> segwit-compliant blocks: perhaps they thought the vast majority of economi=
cally
> significant nodes would reject their blocks? Perhaps they just wanted to
> enforce segwit?
>=20
> These are all questions that have plausible answers, backed by evidence an=
d
> argument. But because Bitcoin is a decentralized network no authority can t=
ell
> you what the answers are.
>=20
> --=20
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev