From: <eric@voskuil.org>
To: =?UTF-8?Q?'Jorge_Tim=C3=B3n'?= <jtimon@jtimon.cc>
References: <CABm2gDot=YnMB8isbouLV_g=P=OAeN7H966juqbBexXyK9jw8A@mail.gmail.com>
 <2368396E-6964-4F12-B50F-2BE477D0C7D8@voskuil.org>
 <CABm2gDrt5AD8erDwJQxtPg4bSbbxbRJ_Sm2KcHrqD2a=QVX3fQ@mail.gmail.com>
In-Reply-To: <CABm2gDrt5AD8erDwJQxtPg4bSbbxbRJ_Sm2KcHrqD2a=QVX3fQ@mail.gmail.com>
Date: Wed, 30 Jun 2021 02:52:42 -0700
Message-ID: <028901d76d95$abb883f0$03298bd0$@voskuil.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQGzRHqRlNUnlmfFxKP28gVDQPjFFgHW7TzYAvNJWiKrTkrfkA==
Content-Language: en-us
Cc: 'Bitcoin Protocol Discussion' <bitcoin-dev@lists.linuxfoundation.org>,
 'Billy Tetrud' <billy.tetrud@gmail.com>
Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
Precedence: list

> From: Jorge Tim=C3=B3n <jtimon@jtimon.cc>=20

>> "Soft forks aren=E2=80=99t compatible without miner enforcement"
> Compatible with what?

There is a good summary of what is meant by this term in BIP141:
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki

"Backward compatibility
As a soft fork, older software will continue to operate without =
modification. Non-upgraded nodes, however, will not see nor validate the =
witness data and will consider all witness programs as anyone-can-spend =
scripts (except a few edge cases where the witness programs are equal to =
0, which the script must fail). Wallets should always be wary of =
anyone-can-spend scripts and treat them with suspicion. Non-upgraded =
nodes are strongly encouraged to upgrade in order to take advantage of =
the new features."

The explanation is however incomplete. If majority hash power does not =
enforce the new rules, the above is incorrect. Granted the word =
"operate" is vague, but clearly what is intended is that "non-upgraded" =
nodes will not be on a different coin. But in fact they would be. The =
underlying presumption is that BIP141 is not only signaled, but enforced =
by majority hash power.

>> "Soft forks without miner support cause splits".
> No, what causes splits are 3 things:
>
> 1) bugs
> 2) coordination mistakes
> 3) people wanting different rules.

#3 (and possibly #4) is what we're talking about, so it's not at all =
clear why you said "no".

People change their rules, because #3. If majority hash power does not =
enforce this (soft) change, it's a chain split.

> Let me give an example. Let's say all users want change A.
>
> Only 60% miners want it.
> When it activates with LOT=3Dtrue, will this cause a split?

No, regardless of percentage adoption. You've proposed that it' is =
majority hash power enforced.

Furthermore, the term compatibility (see above) implies that not =
everyone (your impossible presumption of 100%) is aligned.

This is not a debatable subject as far as I'm concerned, but it's worth =
discussion for those who aren't familiar.

e