path: root/92/4fa44109b3ffb3a794f7530d86eb95756cc2f3

Return-Path: <eric@voskuil.org>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 39E22C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Jun 2021 22:05:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 2900B832A9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Jun 2021 22:05:08 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=voskuil-org.20150623.gappssmtp.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id FLBqroHaZs_3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Jun 2021 22:05:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com
 [IPv6:2607:f8b0:4864:20::62b])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 08D938329A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Jun 2021 22:05:06 +0000 (UTC)
Received: by mail-pl1-x62b.google.com with SMTP id c15so6618477pls.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Jun 2021 15:05:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=voskuil-org.20150623.gappssmtp.com; s=20150623;
 h=content-transfer-encoding:from:mime-version:subject:date:message-id
 :references:cc:in-reply-to:to;
 bh=3Uc/46VYoj9PCLunrwEoYHZ/uoCOG/1JIqi0AYqH6Sg=;
 b=LKskxmcm5yQvwrmK3efBsAJVI+mqWWK3Iga+lYJQYOqdo3N5WRqxL0HQ4B5CfFCeUu
 /fDlcG+Z7h+Haaf74VJ3z3KHZKtsmvTnXxFg/3Rr7w81qpVsHT4TXu8tbV4h59mBQb+w
 +b/3MLX0XZTuL4UBoUU3vg46jpDdea8V+Fk4jVtS2dNW8NLU+Kvg9iXm1LLpyEnODPaz
 36JCICS5FtxvYTxS4nHQeW/KsfyFtcDiivGgOIvG4z7/h3cK5HX7M1B7yERFkcxuTlkz
 b/by8Pe79FETzaaYXrVq44m3IgpIjveFjIPNuxop/i5Sjbo6zujAqM97TzQjJo4VIB22
 IwOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:content-transfer-encoding:from:mime-version
 :subject:date:message-id:references:cc:in-reply-to:to;
 bh=3Uc/46VYoj9PCLunrwEoYHZ/uoCOG/1JIqi0AYqH6Sg=;
 b=lMKYEeDbnQW16edepDgsekR61XT8EUsUlZDWsYoI2tVEzgeqe+VTzTFjBT87bL3l/L
 VRRSCM2zgarHhk3XPqBdKn6W0rrr/dCKTZuPy13oWEZNxHqTM7zjeRyDhDEJzeWyPEo2
 WDdWgwIccoUxiUG2mrgPO7Rqu6YoXTPHHWDr1Kjy5bH25VQVdD+AdjJx4QJV+xGmqhhs
 xVhcW5/Q4F2q5mnhnzaHX6RXfhCK4WeC4RkiYMsRzM09Zd4IIWFO68QGnjJjH8OMzO2s
 FXZkHVZ6nAgaEjP2RMMm+HozOSZUL9sRxrQWSxEmwl/6mCJEGpQrO19sylPtLhFxpiKU
 SArg==
X-Gm-Message-State: AOAM532S4z+AhT+r5wK1+TFFACOe9KTJWpbTwkeoq71WD//1rbZk42Yt
 XAVDMM/ov+3s4H7kHR0GcIb5zA==
X-Google-Smtp-Source: ABdhPJz1fTEIb/7eiwHd6FNDaqNwyPzCCjFxUGTcfIR4vmmo9haZHzImjMpJxl9wSefTCQr2saStyQ==
X-Received: by 2002:a17:902:e8c2:b029:123:25ba:e443 with SMTP id
 v2-20020a170902e8c2b029012325bae443mr15410791plg.29.1624745106352; 
 Sat, 26 Jun 2021 15:05:06 -0700 (PDT)
Received: from smtpclient.apple ([2601:600:9c00:1d0::437e])
 by smtp.gmail.com with ESMTPSA id z3sm9416839pfa.67.2021.06.26.15.05.05
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sat, 26 Jun 2021 15:05:05 -0700 (PDT)
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>
X-Mailer: iPhone Mail (18F72)
Cc: Billy Tetrud <billy.tetrud@gmail.com>
Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Jun 2021 22:05:08 -0000

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