Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Sun, 27 Jun 2021 02:21:58 -0700
Message-Id: <E6D7F613-2378-44BE-8AFD-CB9A3CF59675@voskuil.org>
References: <CABm2gDrCOVN5FQ4DCGwG=1XjZisTVQdOKCwuPnNxd6yHQhy6rA@mail.gmail.com>
In-Reply-To: <CABm2gDrCOVN5FQ4DCGwG=1XjZisTVQdOKCwuPnNxd6yHQhy6rA@mail.gmail.com>
To: =?utf-8?Q?Jorge_Tim=C3=B3n?= <jtimon@jtimon.cc>
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

I have not objected to anyone splitting. As I said, a split is always possib=
le, and of course has been done on a large scale. It is only the misleading s=
tatements about inherent soft fork =E2=80=9Ccompatibility=E2=80=9D and the i=
mplication that activation without hash power enforcement does not create a s=
plit that I object to. People who know better should be honest about it.

Far too many people have been led to believe there is some sort of activatio=
n choice with =E2=80=9Censured=E2=80=9D equal outcomes (maybe =E2=80=9Cslowe=
d down=E2=80=9D). There is only a choice between creating a split and hash p=
ower enforcement. Soft forks are rule changes, and thereby incompatible - un=
less enforced by majority hash power.

The statements below are grossly misleading and need to be called out as suc=
h so that people can actually make this decision you speak of. This idea tha=
t =E2=80=9Cusers=E2=80=9D decide the rules is not the question. The question=
 is only how to avoid a split. If one does not care he can split at any time=
, no discussion required.

e

> On Jun 27, 2021, at 01:47, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
>=20
> =EF=BB=BFIf different users want different incompatible things (enough on e=
ach
> side), there's no way to avoid the split. We shouldn't try to avoid
> such a split.
> Users decide the rules, not miners nor developers.
>=20
>> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>=20
>> Ultimately there is only one answer to this question. Get majority hash p=
ower support.
>>=20
>> Soft fork enforcement is the same act as any other censorship enforcement=
, the difference is only a question of what people want. Given that there is=
 no collective =E2=80=9Cwe=E2=80=9D, those wants differ. Bitcoin resolves th=
is question of conflicting wants, but it is not a democracy, it=E2=80=99s a m=
arket. One votes by trading.
>>=20
>> If one wants to enforce a soft fork (or otherwise censor) this is accompl=
ished by mining (or paying others to do so). Anyone can mine, so everyone ge=
ts a say. Mining is trading capital now for more later. If enough people wan=
t to do that, they can enforce a soft fork. It=E2=80=99s time Bitcoiners sto=
p thinking of miners as other people. Anyone can mine, and that=E2=80=99s yo=
ur vote.
>>=20
>> Otherwise, as mentioned below, anyone can start a new coin. But it=E2=80=99=
s dishonest to imply that one can do this and all others will surely follow.=
 This cannot be known, it=E2=80=99s merely a gamble. And it=E2=80=99s one th=
at has been shown to not always pay off.
>>=20
>> e
>>=20
>>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric@voskuil.org> wrote:
>>>=20
>>> =EF=BB=BFFor some definitions of =E2=80=9Cblock=E2=80=9D.
>>>=20
>>> Without majority hash power support, activation simply means you are off=
 on a chain split. Anyone can of course split off from a chain by changing a=
 rule (soft or otherwise) at any time, so this is a bit of an empty claim.
>>>=20
>>> Nobody can stop a person from splitting. The relevant question is how to=
 *prevent* a split. And activation without majority hash power certainly doe=
s not =E2=80=9Censure=E2=80=9D this.
>>>=20
>>> e
>>>=20
>>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev <bitcoin-dev@lis=
ts.linuxfoundation.org> wrote:
>>>>=20
>>>> =EF=BB=BFBIP8 LOT=3DTrue just ensures miners cannot block an upgrade en=
tirely. They can
>>>> still slow it down.
>>>>=20
>>>> It also already has the trinary state you seem to be describing (althou=
gh
>>>> perhaps this could be better documented in the BIP): users who oppose t=
he
>>>> softfork can and should treat the successful signal (whether MASF or UA=
SF) as
>>>> invalid, thereby ensuring they do not follow a chain with the rules in f=
orce.
>>>>=20
>>>> No additional bit is needed, as softforks are coordinated between users=
, NOT
>>>> miners (who have no particular say in them, aside from their role as al=
so
>>>> being users). The miner involvement is only out of necessity (to set th=
e bit
>>>> in the header, which users coordinate with) and potentially to accelera=
te
>>>> activation by protecting upgrade-lagging users.
>>>>=20
>>>> Luke
>>>>=20
>>>>=20
>>>>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev wrote:=

>>>>> Given the recent controversy over upgrade mechanisms for the
>>>>> non-controversial taproot upgrade, I have been thinking about ways to s=
olve
>>>>> the problems that both sides brought up. In short, BIP8 LOT=3Dtrue pro=
ponents
>>>>> make the point that lazy miners failing to upgrade in a timely manner s=
low
>>>>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=3Dfalse
>>>>> proponents make the point that LOT=3Dtrue can lead to undesirable fork=
s that
>>>>> might cause a lot of chaos. I believe both points are essentially corr=
ect
>>>>> and have created a proposal
>>>>> <https://github.com/fresheneesz/bip-trinary-version-signaling/blob/mas=
ter/b
>>>>> ip-trinary-version-bits.md> for soft fork upgrades that solve both pro=
blems.
>>>>>=20
>>>>> The proposal uses trinary version signaling rather than binary signali=
ng.
>>>>> For any particular prospective soft fork upgrade, this allows for thre=
e
>>>>> signaling states:
>>>>>=20
>>>>> * Actively support the change.
>>>>> * Actively oppose the change.
>>>>> * Not signaling (neither support or oppose). This is the default state=
.
>>>>>=20
>>>>> Using this additional information, we can release non-contentious upgr=
ades
>>>>> much quicker (with a much lower percent of miners signaling support). =
For
>>>>> contentious upgrades, miners who oppose the change are incentivized to=

>>>>> update their software to a version that can actively signal opposition=
 to
>>>>> the change. The more opposition there is, the higher the threshold
>>>>> necessary to lock in the upgrade. With the parameters I currently
>>>>> recommended in the proposal, this chart shows how much support signali=
ng
>>>>> would be necessary given a particular amount of active opposition
>>>>> signaling:
>>>>>=20
>>>>> [image: thresholdChart.png]
>>>>> If literally no one signals opposition, a 60% threshold should be
>>>>> relatively safe because it is a supermajority amount that is unlikely t=
o
>>>>> change significantly very quickly (ie if 60% of miners support the cha=
nge
>>>>> today, its unlikely that less than a majority of miners would support t=
he
>>>>> change a year or two from now), and if no one is signaling opposition,=

>>>>> chances are that the vast majority of the other 40% would also eventua=
lly
>>>>> signal support.
>>>>>=20
>>>>> This both gives an incentive for "lazy" miners to upgrade if they actu=
ally
>>>>> oppose the change while at the same time allowing these lazy miners to=

>>>>> remain lazy without slowing down the soft fork activation much.
>>>>>=20
>>>>> I think now is the right time to discuss new soft fork upgrade mechani=
sms,
>>>>> when there are no pressing soft fork upgrades ready to deploy. Waiting=

>>>>> until we need to deploy a soft fork to discuss this will only delay th=
ings
>>>>> and cause contention again like it did with taproot.
>>>>>=20
>>>>> I'm very curious to know what people think of this mechanism. I would
>>>>> appreciate any comments here, or written as github issues on the propo=
sal
>>>>> repo itself.
>>>>>=20
>>>>> Thanks,
>>>>> BT
>>>>=20
>>>> _______________________________________________
>>>> 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