path: root/42/54d60fc579546f17c3d45df6ff18f817c1bcda

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 48B77C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 18:17:27 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 3768E8198A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 18:17:27 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 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,
 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 zKg56pMAGPT6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 18:17:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com
 [IPv6:2607:f8b0:4864:20::532])
 by smtp1.osuosl.org (Postfix) with ESMTPS id B296D839DD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 18:17:25 +0000 (UTC)
Received: by mail-pg1-x532.google.com with SMTP id w15so14736309pgk.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 11:17:25 -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=lGvhykyUF7p5DdQWiFmadIqicSI38uArso3lO2jxCOk=;
 b=piYYYf9vNn5hJGguX7tAU3Nny4Tk+wZzHUBBa77bnk+Do363FEFBxMRvaM6jtS7TdQ
 fRYC2mIsXV14NW7bQVXcKoMfpDLmjXltzcr96JjGeBHqnBl0IR1QjW0oXMJZioz/DooH
 jkWccS15md4TqWXANVQRWtqUVm46HOkoWEXi2OI1DG2o73mohk6OfL3MRdXxTnXssbE5
 WiWPsjmpbtojvTETXVS7WXkKExU3XrNRmUMCIWUmf22frZ8XjY4fVwd6xZo4BQuGNHEd
 yWraQjGlSyD4HAvAU7rfic1t0V65PXodCqK+hlH44NDYSSuma66M37s3vCYzEPvQiD3+
 4cAw==
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=lGvhykyUF7p5DdQWiFmadIqicSI38uArso3lO2jxCOk=;
 b=tplHG+4vrLMaKJ5ckkdWhlhwlQbzcx8/aAHKNmlLOBwRMk6RZSzFg0HUFlVX93GzSn
 7HfvJAxjk8kwXRIpC17oiInqQw9nukN7dRVZ6A1FfNPvUJkBumBOeGLPxC++lIr/YHCg
 KJ/tqzk2BLqkBAMs3Q0n13XAJQnQRWN7TECsU/MOLIJl4XLhHALCuhuCOR19igXWGBt6
 VKcblD2Peu+Gd4csp/pCaF9M7Sr/YeVtPUqlpSVMdOLLj4CiDAnjNq7LJj2nHMVZhksl
 JtNwHPr2PvqyCFWgwjfs40kkUmicgiuf+H9PuaWQXCf2S8xJYTwdlYKIeMeaZF+i4xXF
 vMjA==
X-Gm-Message-State: AOAM533FQRgkZQhJ8V1+4/HeHhXaLa8qaVSx7WG7ReqE0Xg8L4kCDp/v
 oN4kmBNoThX4PRqYB6gCEFUNwNJKNcOSKQ==
X-Google-Smtp-Source: ABdhPJyk14GklaA5OqmB9GsgRhodUvCxwOgEiQztW4foGJcYTqf03Tdt6wlZAUR9oErnbm1ZF6Wr5Q==
X-Received: by 2002:a05:6a00:2395:b029:304:7a51:6f1d with SMTP id
 f21-20020a056a002395b02903047a516f1dmr31908873pfc.53.1624990644687; 
 Tue, 29 Jun 2021 11:17:24 -0700 (PDT)
Received: from smtpclient.apple ([2600:380:4548:79bc:4d8e:5eef:f49e:8219])
 by smtp.gmail.com with ESMTPSA id w21sm5126506pge.30.2021.06.29.11.17.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 29 Jun 2021 11:17:24 -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: Tue, 29 Jun 2021 11:17:22 -0700
Message-Id: <B06FB5CC-646E-4AB9-AE06-83F41D0DDB63@voskuil.org>
References: <202106291755.11926.luke@dashjr.org>
In-Reply-To: <202106291755.11926.luke@dashjr.org>
To: Luke Dashjr <luke@dashjr.org>
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: Tue, 29 Jun 2021 18:17:27 -0000


> On Jun 29, 2021, at 10:55, Luke Dashjr <luke@dashjr.org> wrote:
>=20
> =EF=BB=BFThe only alternative to a split in the problematic scenarios are 1=
) concede=20
> centralised miner control over the network,

Miners control confirmation, entirely.

This is the nature of bitcoin. And merchants control validation, entirely. A=
nyone can be a miner or a merchant. Neither is inherently =E2=80=9Cbetter=E2=
=80=9D than the other. The largest merchants are likely a handful of exchang=
es, likely at least as centralized as miners are pooled.

Splitting does not change this.

> and 2) have inconsistent=20
> enforcement of rules by users who don't agree on what the correct rules ar=
e,=20

There are no =E2=80=9Ccorrect=E2=80=9D rules. Whatever rules one enforces de=
termine what network he chooses to participate in.

> again leading to centralised miner control over the network.

Leading to? Miners control confirmation, always. Whether that is centralized=
, just as with merchanting, is up to individuals.

> In other words, in this context, accepting a split between disagreeing use=
rs=20
> is the ONLY way Bitcoin can possibly continue as a decentralised currency.=


No, it is not. You are proposing splitting as the method of censorship resis=
tance inherent to Bitcoin. Coordinating this split requires coordinated acti=
on. The whole point of bitcoin is coordinate that action based on mining (pr=
oof of work). Replacing that with a political process is just a reversion to=
 political money.

> Making that split as clean and well-defined as possible not only ensures t=
he=20
> best opportunity for both sides of the disagreement,

Trivially accomplished, just change a rule. This isn=E2=80=99t about that. I=
t=E2=80=99s about how one gets others to go along with the new coin, or stay=
 with the old. An entirely political process, which is clearly evident from t=
he campaigns around such attempts.

> but also minimises the=20
> risk that the split occurs at all (since the "losing" side needs to conced=
e,=20
> rather than passively continue the disagreement ongoing after the attempte=
d=20
> protocol change).

Nobody =E2=80=9Cneeds to=E2=80=9D concede once a split has occurred, which i=
s evident in existing splits.

e

> Luke
>=20
>=20
>> On Tuesday 29 June 2021 08:44:56 Eric Voskuil wrote:
>> At least we are now acknowledging that splitting is what it=E2=80=99s abo=
ut. That=E2=80=99s
>> progress.
>>=20
>> e
>>=20
>>>> On Jun 29, 2021, at 01:32, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
>>>=20
>>> =EF=BB=BF
>>> I think the option of "permanent failure because miners veto" should
>>> actually be abandoned. No, I don't think we should avoid splits when
>>> possible, I don't think we should avoid splits at all costs.
>>>=20
>>>> On Sun, Jun 27, 2021, 19:12 Billy Tetrud <billy.tetrud@gmail.com> wrote=
:
>>>> @Luke
>>>>=20
>>>>> They can still slow it down.
>>>>=20
>>>> Absolutely. However I think that the option of permanent failure is
>>>> important. It certainly would be ideal to ensure that enough bitcoin
>>>> users support the upgrade *before* releasing it, however realistically
>>>> this can never be more than an estimate, and estimates can sometimes be=

>>>> wildly wrong. It would be unfortunate if miners had a substantially
>>>> different estimate of user support than the people putting in the work
>>>> to release bitcoin upgrades. Even if upgrades are never released before=

>>>> it becomes clear that a large supermajority of users want the upgrade,
>>>> if miners don't agree with the estimate a harmful chain split could
>>>> occur. And I agree with Eric that the goal here is to prevent a chain
>>>> split during an upgrade when possible. This includes permanent failure
>>>> of an upgrade when there is unexpectedly large miner opposition.
>>>>=20
>>>> This of course does not prevent a UASF-style deployment to be done afte=
r
>>>> an initial failure to deploy occurs. My proposal is essentially a
>>>> mechanism to improve upon the speedy-trial idea, allowing for even
>>>> speedier releases (than speedy trial) without adding additional risk of=

>>>> undesired chain splits.
>>>>=20
>>>>> [BIP8] already has the trinary state you seem to be describing
>>>>=20
>>>> It sounds like you're saying the trinary state of BIP8 is A. Follow the=

>>>> longest chain, B. Follow the upgrade chain, or C. follow the
>>>> non-upgraded chain. I agree. However the trinary state in my proposal i=
s
>>>> materially different - it is the signaling itself that is trinary, not
>>>> just which chain is being followed. This allows others to know and make=

>>>> programmatic decisions (in software) based on that signaling. I'm sure
>>>> you can agree that does not exist in BIP8.
>>>>=20
>>>>> No additional bit is needed, as softforks are coordinated between
>>>>> users, NOT miners
>>>>=20
>>>> And yet there is miner involvement, as you rightly pointed out. Miners
>>>> are needed to set the nVersion in the header. So when you say "no
>>>> additional bit is needed", could you please be clearer as to what you
>>>> mean? Do you mean that signaling of opposition in a block can be done
>>>> without any "additional bit"? Or are you just saying that it is
>>>> redundant to consider what miners might be opposing an upgrade?
>>>>=20
>>>> @Jorge
>>>>=20
>>>>> If different users want different incompatible things... there's no
>>>>> way to avoid the split
>>>>=20
>>>> I agree. This happened with bcash, and that's fine. It was painful, but=

>>>> there were a significant amount of users that disagreed, and they have
>>>> the chain they want now.
>>>>=20
>>>> But we generally all want to avoid a chain split when possible. Because=

>>>> chain splits have a cost, and that cost can be high, its likely that
>>>> many users would rather choose the chain with the most support rather
>>>> than choosing the chain with their preferred rules.
>>>>=20
>>>> However, the question here is: how do we estimate what fraction of user=
s
>>>> wants which rules? We don't have a divining rod to determine with
>>>> certainty what users want. We can only make polls of various levels of
>>>> inaccuracy. The methods bitcoin has been using is community discussion
>>>> and social consensus estimation as well as miner signaling during the
>>>> actual deployment period. Neither of these are perfect, but they are
>>>> both reasonable enough mechanisms. However, because both of these
>>>> mechanisms are very rough estimates of user sentiment, we need to
>>>> consider the possibility that sometimes the estimate may be
>>>> substantially inaccurate when we design deployment procedures. This
>>>> inaccuracy is why we need multiple barriers in place for an upgrade, an=
d
>>>> why we need to have higher thresholds of success (require larger
>>>> supermajorities in both consensus and miner signaling).
>>>>=20
>>>> Developers obviously care about bitcoin and have an incentive (personal=

>>>> and probably financial) to do it right. And miners have both an
>>>> incentive to keep the system healthy, as well as an incentive to mine o=
n
>>>> the chain that the economic majority of users is using. But measuring
>>>> the consensus of the bitcoin community can be extraordinarily difficult=

>>>> to do with consistent accuracy, and so I think miner signaling as it ha=
s
>>>> been used as a second barrier to entry for an upgrade is quite
>>>> appropriate.
>>>>=20
>>>>> On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil <eric@voskuil.org> wrote:=

>>>>> I have not objected to anyone splitting. As I said, a split is always
>>>>> possible, and of course has been done on a large scale. It is only the=

>>>>> misleading statements about inherent soft fork =E2=80=9Ccompatibility=E2=
=80=9D and the
>>>>> implication that activation without hash power enforcement does not
>>>>> create a split that I object to. People who know better should be
>>>>> honest about it.
>>>>>=20
>>>>> Far too many people have been led to believe there is some sort of
>>>>> activation choice with =E2=80=9Censured=E2=80=9D equal outcomes (maybe=
 =E2=80=9Cslowed down=E2=80=9D).
>>>>> There is only a choice between creating a split and hash power
>>>>> enforcement. Soft forks are rule changes, and thereby incompatible -
>>>>> unless enforced by majority hash power.
>>>>>=20
>>>>> The statements below are grossly misleading and need to be called out
>>>>> as such so that people can actually make this decision you speak of.
>>>>> This idea that =E2=80=9Cusers=E2=80=9D decide the rules is not the que=
stion. The
>>>>> question is only how to avoid a split. If one does not care he can
>>>>> split at any time, no discussion required.
>>>>>=20
>>>>> e
>>>>>=20
>>>>>> 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 (enoug=
h on
>>>>>> each 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 power 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 d=
iffer. Bitcoin
>>>>>>> resolves this question of conflicting wants, but it is not a
>>>>>>> democracy, it=E2=80=99s a market. One votes by trading.
>>>>>>>=20
>>>>>>> If one wants to enforce a soft fork (or otherwise censor) this is
>>>>>>> accomplished 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 thinking of miners as other p=
eople.
>>>>>>> Anyone can mine, and that=E2=80=99s your vote.
>>>>>>>=20
>>>>>>> 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. This 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.
>>>>>>>=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 does 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@lists.linuxfoundation.org> wrote:
>>>>>>>>>=20
>>>>>>>>> =EF=BB=BFBIP8 LOT=3DTrue just ensures miners cannot block an upgra=
de
>>>>>>>>> entirely. They can still slow it down.
>>>>>>>>>=20
>>>>>>>>> It also already has the trinary state you seem to be describing
>>>>>>>>> (although perhaps this could be better documented in the BIP):
>>>>>>>>> users who oppose the softfork can and should treat the successful
>>>>>>>>> signal (whether MASF or UASF) as invalid, thereby ensuring they do=

>>>>>>>>> not follow a chain with the rules in force.
>>>>>>>>>=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 also being users). The miner involvement is only out=

>>>>>>>>> of necessity (to set the bit in the header, which users coordinate=

>>>>>>>>> with) and potentially to accelerate activation by protecting
>>>>>>>>> upgrade-lagging users.
>>>>>>>>>=20
>>>>>>>>> Luke
>>>>>>>>>=20
>>>>>>>>>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev
>>>>>>>>>>> wrote:
>>>>>>>>>>=20
>>>>>>>>>> Given the recent controversy over upgrade mechanisms for the
>>>>>>>>>> non-controversial taproot upgrade, I have been thinking about
>>>>>>>>>> ways to solve the problems that both sides brought up. In short,
>>>>>>>>>> BIP8 LOT=3Dtrue proponents make the point that lazy miners failin=
g
>>>>>>>>>> to upgrade in a timely manner slow down releases of bitcoin
>>>>>>>>>> upgrades, and BIP9 / BIP8 LOT=3Dfalse proponents make the point
>>>>>>>>>> that LOT=3Dtrue can lead to undesirable forks that might cause a
>>>>>>>>>> lot of chaos. I believe both points are essentially correct and
>>>>>>>>>> have created a proposal
>>>>>>>>>> <https://github.com/fresheneesz/bip-trinary-version-signaling/blo=

>>>>>>>>>> b/master/b ip-trinary-version-bits.md> for soft fork upgrades tha=
t
>>>>>>>>>> solve both problems.
>>>>>>>>>>=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=

>>>>>>>>>> upgrades 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 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 change today, its unlikely that less than a
>>>>>>>>>> majority of miners would support the 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 eventually signal
>>>>>>>>>> support.
>>>>>>>>>>=20
>>>>>>>>>> This both gives an incentive for "lazy" miners to upgrade if they=

>>>>>>>>>> actually 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
>>>>>>>>>> mechanisms, 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 things 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 proposal repo itself.
>>>>>>>>>>=20
>>>>>>>>>> Thanks,
>>>>>>>>>> BT
>>>>>>>>>=20
>>>>>>>>> _______________________________________________
>>>>>>>>> bitcoin-dev mailing list
>>>>>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> bitcoin-dev mailing list
>>>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20