path: root/3f/5483ab0fc1b747120e65e9352722611fb908a9

Return-Path: <eric@voskuil.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 8C8A9C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 27 Jun 2021 09:22:01 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 748A9401BD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 27 Jun 2021 09:22:01 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=voskuil-org.20150623.gappssmtp.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id jX7CHKql0_32
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 27 Jun 2021 09:22:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com
 [IPv6:2607:f8b0:4864:20::42c])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 2083540165
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 27 Jun 2021 09:22:00 +0000 (UTC)
Received: by mail-pf1-x42c.google.com with SMTP id k6so11428143pfk.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 27 Jun 2021 02:22:00 -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=MdSAAsnnCm3dWv1ZzuM67jkAS5RdJUo03E7+KHT+4ZM=;
 b=xqDbdDXhjDcYE4F1ahhTnznVYlOeCTXHWoCQuy6/dLS6gUye+2rBSaxrdSS86xNAqG
 dcCTihyfvhrZtMCyTX9t9NZ+ndEXP+KN2Al+RB8WCILQ2oJc+6G2CMu9o87PUAobnQMa
 xSYcE4SMheXFCR+VbLUigT8vwVrxPM+ztrCMWkes3BGex8ikUEUmcLlw3wkrAo72Q/pq
 oQT1JxRYTJGx/PEKBh0Hxy7bL3J1NQ7f51MMZq6hjtRcTlnmCDzcIxVGoAsTkYTaiE0/
 k9GiZCn0N03q53pM7to7XK6YuIt/W6FiOROm6hGXxLvpEr0ozee3TDmfpKPyKlYFBwx9
 1ThA==
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=MdSAAsnnCm3dWv1ZzuM67jkAS5RdJUo03E7+KHT+4ZM=;
 b=kQGDA9o750fS5r5QKtkd5nL6h9rP3VfNzr1ONxiIGkmWwHH2+PASF/308HRqVl2uE8
 2XsJgTlteWjoGr21b01KQZBbO1VoKR+s9KbVqvxzHNML57ejh753+ey9GkWI5Or03yOs
 xV1Dp3TRtUUnoac4CXYcvg8ovrBnv5OqthT/TQMVNQYHVbpiBFtj89he/QOX7aDGUhtQ
 pu51v2qs/b9auNtr8ohBKViFgiICiljnEGXDPC9XMRk95lslDAJhFOQBPGc32tMFdb8L
 MrZMELVMSbGjvaEyEDAWRoDoOXIUR4lktXcUyJ2/KnsnTtOrojHPQYePHA1KeH7/KZcg
 en0g==
X-Gm-Message-State: AOAM532gdanAp4tCEBO0elp0xPgFZYnxbsbS5xaGcyaS0vIgzsYEL3Qt
 E3Sx4IS5l0L+Xp8q+5OJnP1BvyJnxDDq+oGu
X-Google-Smtp-Source: ABdhPJyNQnIQimFHJum+M7nw4v/kvCflWv2/2Jdrw1DsYrfjiA+5MfEHOJqejhzkXVlCpgrZTeIPuA==
X-Received: by 2002:a63:5fd4:: with SMTP id
 t203mr18050007pgb.401.1624785719256; 
 Sun, 27 Jun 2021 02:21:59 -0700 (PDT)
Received: from smtpclient.apple ([2601:600:9c00:1d0::437e])
 by smtp.gmail.com with ESMTPSA id o20sm10126614pjq.57.2021.06.27.02.21.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 27 Jun 2021 02:21:58 -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: 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>
X-Mailer: iPhone Mail (18F72)
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
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: Sun, 27 Jun 2021 09:22:01 -0000

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