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: Sat, 26 Jun 2021 15:05:05 -0700
Message-Id: <99FAC012-22BB-4160-A941-A99FF4D330DF@voskuil.org>
References: <CB5A45C6-6446-4ECE-AD7D-8F079F8661BF@voskuil.org>
In-Reply-To: <CB5A45C6-6446-4ECE-AD7D-8F079F8661BF@voskuil.org>
To: Luke Dashjr <luke@dashjr.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Cc: Billy Tetrud <billy.tetrud@gmail.com>
Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
Precedence: list

Ultimately there is only one answer to this question. Get majority hash powe=
r support.

Soft fork enforcement is the same act as any other censorship enforcement, t=
he 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 this q=
uestion of conflicting wants, but it is not a democracy, it=E2=80=99s a mark=
et. One votes by trading.

If one wants to enforce a soft fork (or otherwise censor) this is accomplish=
ed by mining (or paying others to do so). Anyone can mine, so everyone gets a=
 say. Mining is trading capital now for more later. If enough people want to=
 do that, they can enforce a soft fork. It=E2=80=99s time Bitcoiners stop th=
inking of miners as other people. Anyone can mine, and that=E2=80=99s your v=
ote.

Otherwise, as mentioned below, anyone can start a new coin. But it=E2=80=99s=
 dishonest to imply that one can do this and all others will surely follow. T=
his cannot be known, it=E2=80=99s merely a gamble. And it=E2=80=99s one that=
 has been shown to not always pay off.

e

> 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 o=
n a chain split. Anyone can of course split off from a chain by changing a r=
ule (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 does n=
ot =E2=80=9Censure=E2=80=9D this.
>=20
> e
>=20
>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
>>=20
>> =EF=BB=BFBIP8 LOT=3DTrue just ensures miners cannot block an upgrade enti=
rely. They can=20
>> still slow it down.
>>=20
>> It also already has the trinary state you seem to be describing (although=
=20
>> perhaps this could be better documented in the BIP): users who oppose the=
=20
>> softfork can and should treat the successful signal (whether MASF or UASF)=
 as=20
>> invalid, thereby ensuring they do not follow a chain with the rules in fo=
rce.
>>=20
>> No additional bit is needed, as softforks are coordinated between users, N=
OT=20
>> miners (who have no particular say in them, aside from their role as also=
=20
>> being users). The miner involvement is only out of necessity (to set the b=
it=20
>> in the header, which users coordinate with) and potentially to accelerate=
=20
>> 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 so=
lve
>>> the problems that both sides brought up. In short, BIP8 LOT=3Dtrue propo=
nents
>>> make the point that lazy miners failing to upgrade in a timely manner sl=
ow
>>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=3Dfalse
>>> proponents make the point that LOT=3Dtrue can lead to undesirable forks t=
hat
>>> might cause a lot of chaos. I believe both points are essentially correc=
t
>>> and have created a proposal
>>> <https://github.com/fresheneesz/bip-trinary-version-signaling/blob/maste=
r/b
>>> ip-trinary-version-bits.md> for soft fork upgrades that solve both probl=
ems.
>>>=20
>>> The proposal uses trinary version signaling rather than binary signaling=
.
>>> For any particular prospective soft fork upgrade, this allows for three
>>> 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 upgrad=
es
>>> much quicker (with a much lower percent of miners signaling support). Fo=
r
>>> contentious upgrades, miners who oppose the change are incentivized to
>>> update their software to a version that can actively signal opposition t=
o
>>> 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 signaling=

>>> 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 to=

>>> change significantly very quickly (ie if 60% of miners support the chang=
e
>>> today, its unlikely that less than a majority of miners would support th=
e
>>> 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 eventuall=
y
>>> signal support.
>>>=20
>>> This both gives an incentive for "lazy" miners to upgrade if they actual=
ly
>>> 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 mechanism=
s,
>>> 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 thin=
gs
>>> 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 proposa=
l
>>> repo itself.
>>>=20
>>> Thanks,
>>> BT
>>=20
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev