path: root/f2/b743e732dec79765a4f4928fee613295b2f689

Return-Path: <eric@voskuil.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A5B8CC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 08:45:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 82EDD607B2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 08:45:00 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, 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: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=voskuil-org.20150623.gappssmtp.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id S2Et5nt2UlQw
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 08:44:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com
 [IPv6:2607:f8b0:4864:20::42e])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 8F5996079D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 08:44:58 +0000 (UTC)
Received: by mail-pf1-x42e.google.com with SMTP id a127so16571658pfa.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 01:44:58 -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=v/apI+LT9hRgEtwaD9BJ3S1o7Y1ymjT1j2bzb+dDxKc=;
 b=RW5MJHDB6nNdEcULwNr3Lw3iZaAArXqfY6sz17sinFqbT5j74fwPzPuVKEoyFb91bV
 Kn4GDJdMVALDENL/XSqne+l5Oso2v97Yl6HSgxPa+17aw6cNqT34/WksBKE6oh1sM9ci
 9vX55AQjSM4Cl5fPwQw/OFpzMZ9UK94WWTodp8FS3h8sjotm65znM6SYYKsv737i4Q/4
 ZrjMesbImbi5ThfneO90riGnTARp1hd0X/YfapP70snQIBzxNR/9Tuu75GIO3T3WNlzb
 jh1NcWG2zanpdK0bBvahY9Zo/sb1knYPoy0FQIQFgoyHIV7r9d5lTjbheeCJUwyqw/Sb
 Bk/A==
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=v/apI+LT9hRgEtwaD9BJ3S1o7Y1ymjT1j2bzb+dDxKc=;
 b=BCx5KNUr3FV55nZFaLm1WyyTYsFN3RHkmhDKhqSl/XCYnTPs074JzU/fCuLP3WG7DP
 5VWL5YCHcN8kScBevXWNtVHgKo7lVAyiqKutYV1Rq5eGG3NvDr1bwjHAKKPLbasPxk1C
 csPXvN7grWZtt/dB5TEW4K+woQfPAo0qebpX71tnC+IPp/ATLg1nyZhfZokrE7UcoONZ
 H3GaOqAfs7abJ090kPOOJd6MGNuE4d+oquZloZPQxuy8mTOGLY3DGCt9/0yNO01ZIgda
 8iQdSDOGKv54o7kkgXvCun6UAmBatIPXuIVOw686nKBOsniWZvNv7mFBcUIcx8vY3WsV
 0UxA==
X-Gm-Message-State: AOAM53075cTrvYiVwtAvf7khlIuRBZeZK3WKC72EHADTLF/nWcjQvxyN
 860ZSLHjIeTnqzGJjaCFCXamKyLgEdcGqUlP
X-Google-Smtp-Source: ABdhPJySbg/xOYs/Tf09iSxPY+5CyjN5lgiddso+Yh8Yy3YT9fRBnMZI3S9bfr6itt85zaeMQEqylQ==
X-Received: by 2002:a63:5946:: with SMTP id j6mr18101043pgm.0.1624956297773;
 Tue, 29 Jun 2021 01:44:57 -0700 (PDT)
Received: from smtpclient.apple ([2601:600:9c00:1d0::da55])
 by smtp.gmail.com with ESMTPSA id d13sm16430081pfn.136.2021.06.29.01.44.56
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 29 Jun 2021 01:44:57 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary=Apple-Mail-6D18B293-AAE4-46AC-9D81-827DBC6557EA
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Tue, 29 Jun 2021 01:44:56 -0700
Message-Id: <4E02C43C-D5D9-489E-9D94-4BF2DCB92496@voskuil.org>
References: <CABm2gDqQm0_JnddJ2AKbDnNTGV0kYm-zOqtyZFn2=GHRb2cY2g@mail.gmail.com>
In-Reply-To: <CABm2gDqQm0_JnddJ2AKbDnNTGV0kYm-zOqtyZFn2=GHRb2cY2g@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: Tue, 29 Jun 2021 08:45:00 -0000


--Apple-Mail-6D18B293-AAE4-46AC-9D81-827DBC6557EA
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

At least we are now acknowledging that splitting is what it=E2=80=99s about.=
 That=E2=80=99s progress.

e

> 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 actua=
lly be abandoned.=20
> No, I don't think we should avoid splits when possible, I don't think we s=
hould avoid splits at all costs.
>=20
>=20
>> On Sun, Jun 27, 2021, 19:12 Billy Tetrud <billy.tetrud@gmail.com> wrote:
>> @Luke
>> > They can still slow it down.
>>=20
>> Absolutely. However I think that the option of permanent failure is impor=
tant. It certainly would be ideal to ensure that enough bitcoin users suppor=
t the upgrade *before* releasing it, however realistically this can never be=
 more than an estimate, and estimates can sometimes be wildly wrong. It woul=
d be unfortunate if miners had a substantially different estimate of user su=
pport than the people putting in the work to release bitcoin upgrades. Even i=
f upgrades are never released before it becomes clear that a large supermajo=
rity of users want the upgrade, if miners don't agree with the estimate a ha=
rmful chain split could occur. And I agree with Eric that the goal here is t=
o prevent a chain split during an upgrade when possible. This includes perma=
nent failure of an upgrade when there is unexpectedly large miner opposition=
.=20
>>=20
>> This of course does not prevent a UASF-style deployment to be done after a=
n initial failure to deploy occurs. My proposal is essentially a mechanism t=
o improve upon the speedy-trial idea, allowing for even speedier releases (t=
han speedy trial) without adding additional risk of undesired chain splits.=20=

>>=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 l=
ongest chain, B. Follow the upgrade chain, or C. follow the non-upgraded cha=
in. I agree. However the trinary state in my proposal is materially differen=
t - it is the signaling itself that is trinary, not just which chain is bein=
g followed. This allows others to know and make programmatic decisions (in s=
oftware) based on that signaling. I'm sure you can agree that does not exist=
 in BIP8.=20
>>=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 ar=
e needed to set the nVersion in the header. So when you say "no additional b=
it is needed", could you please be clearer as to what you mean? Do you mean t=
hat signaling of opposition in a block can be done without any "additional b=
it"? Or are you just saying that it is redundant to consider what miners mig=
ht be opposing an upgrade?=20
>>=20
>> @Jorge
>> > 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 t=
here were a significant amount of users that disagreed, and they have the ch=
ain they want now.
>>=20
>> But we generally all want to avoid a chain split when possible. Because c=
hain splits have a cost, and that cost can be high, its likely that many use=
rs would rather choose the chain with the most support rather than choosing t=
he chain with their preferred rules.
>>=20
>> However, the question here is: how do we estimate what fraction of users w=
ants which rules? We don't have a divining rod to determine with certainty w=
hat users want. We can only make polls of various levels of inaccuracy. The m=
ethods bitcoin has been using is community discussion and social consensus e=
stimation as well as miner signaling during the actual deployment period. Ne=
ither of these are perfect, but they are both reasonable enough mechanisms. H=
owever, because both of these mechanisms are very rough estimates of user se=
ntiment, we need to consider the possibility that sometimes the estimate may=
 be substantially inaccurate when we design deployment procedures. This inac=
curacy is why we need multiple barriers in place for an upgrade, and why we n=
eed to have higher thresholds of success (require larger supermajorities in b=
oth consensus and miner signaling).=20
>>=20
>> Developers obviously care about bitcoin and have an incentive (personal a=
nd probably financial) to do it right. And miners have both an incentive to k=
eep the system healthy, as well as an incentive to mine on the chain that th=
e economic majority of users is using. But measuring the consensus of the bi=
tcoin community can be extraordinarily difficult to do with consistent accur=
acy, and so I think miner signaling as it has been used as a second barrier t=
o entry for an upgrade is quite appropriate.=20
>>=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 po=
ssible, and of course has been done on a large scale. It is only the mislead=
ing statements about inherent soft fork =E2=80=9Ccompatibility=E2=80=9D and t=
he implication that activation without hash power enforcement does not creat=
e 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 activ=
ation choice with =E2=80=9Censured=E2=80=9D equal outcomes (maybe =E2=80=9Cs=
lowed down=E2=80=9D). There is only a choice between creating a split and ha=
sh 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 question. The ques=
tion is only how to avoid a split. If one does not care he can split at any t=
ime, 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 (enough=
 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 ha=
sh power support.
>>> >>=20
>>> >> Soft fork enforcement is the same act as any other censorship enforce=
ment, the difference is only a question of what people want. Given that ther=
e is no collective =E2=80=9Cwe=E2=80=9D, those wants differ. Bitcoin resolve=
s this question of conflicting wants, but it is not a democracy, it=E2=80=99=
s a market. One votes by trading.
>>> >>=20
>>> >> If one wants to enforce a soft fork (or otherwise censor) this is acc=
omplished by mining (or paying others to do so). Anyone can mine, so everyon=
e 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 people. Anyone can mine, and that=E2=80=99=
s 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 f=
ollow. This cannot be known, it=E2=80=99s merely a gamble. And it=E2=80=99s o=
ne 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 changi=
ng a rule (soft or otherwise) at any time, so this is a bit of an empty clai=
m.
>>> >>>=20
>>> >>> Nobody can stop a person from splitting. The relevant question is ho=
w 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 upgrad=
e entirely. They can
>>> >>>> still slow it down.
>>> >>>>=20
>>> >>>> It also already has the trinary state you seem to be describing (al=
though
>>> >>>> perhaps this could be better documented in the BIP): users who oppo=
se the
>>> >>>> softfork can and should treat the successful signal (whether MASF o=
r 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 u=
sers, NOT
>>> >>>> miners (who have no particular say in them, aside from their role a=
s also
>>> >>>> being users). The miner involvement is only out of necessity (to se=
t the bit
>>> >>>> in the header, which users coordinate with) and potentially to acce=
lerate
>>> >>>> activation by protecting upgrade-lagging users.
>>> >>>>=20
>>> >>>> Luke
>>> >>>>=20
>>> >>>>=20
>>> >>>>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev wr=
ote:
>>> >>>>> 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 failing to upgrade in a timely man=
ner slow
>>> >>>>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=3Dfalse
>>> >>>>> proponents make the point that LOT=3Dtrue can lead to undesirable f=
orks that
>>> >>>>> might cause a lot of chaos. I believe both points are essentially c=
orrect
>>> >>>>> and have created a proposal
>>> >>>>> <https://github.com/fresheneesz/bip-trinary-version-signaling/blob=
/master/b
>>> >>>>> ip-trinary-version-bits.md> for soft fork upgrades that solve both=
 problems.
>>> >>>>>=20
>>> >>>>> The proposal uses trinary version signaling rather than binary sig=
naling.
>>> >>>>> For any particular prospective soft fork upgrade, this allows for t=
hree
>>> >>>>> signaling states:
>>> >>>>>=20
>>> >>>>> * Actively support the change.
>>> >>>>> * Actively oppose the change.
>>> >>>>> * Not signaling (neither support or oppose). This is the default s=
tate.
>>> >>>>>=20
>>> >>>>> Using this additional information, we can release non-contentious u=
pgrades
>>> >>>>> much quicker (with a much lower percent of miners signaling suppor=
t). For
>>> >>>>> contentious upgrades, miners who oppose the change are incentivize=
d to
>>> >>>>> update their software to a version that can actively signal opposi=
tion 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 sig=
naling
>>> >>>>> 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 unlik=
ely to
>>> >>>>> change significantly very quickly (ie if 60% of miners support the=
 change
>>> >>>>> today, its unlikely that less than a majority of miners would supp=
ort the
>>> >>>>> change a year or two from now), and if no one is signaling opposit=
ion,
>>> >>>>> chances are that the vast majority of the other 40% would also eve=
ntually
>>> >>>>> signal support.
>>> >>>>>=20
>>> >>>>> This both gives an incentive for "lazy" miners to upgrade if they a=
ctually
>>> >>>>> oppose the change while at the same time allowing these lazy miner=
s 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 mec=
hanisms,
>>> >>>>> when there are no pressing soft fork upgrades ready to deploy. Wai=
ting
>>> >>>>> until we need to deploy a soft fork to discuss this will only dela=
y things
>>> >>>>> and cause contention again like it did with taproot.
>>> >>>>>=20
>>> >>>>> I'm very curious to know what people think of this mechanism. I wo=
uld
>>> >>>>> appreciate any comments here, or written as github issues on the p=
roposal
>>> >>>>> 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

--Apple-Mail-6D18B293-AAE4-46AC-9D81-827DBC6557EA
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr">At least we are now acknow=
ledging that splitting is what it=E2=80=99s about. That=E2=80=99s progress.<=
/div><div dir=3D"ltr"><br></div><div dir=3D"ltr">e</div><div dir=3D"ltr"><br=
><blockquote type=3D"cite">On Jun 29, 2021, at 01:32, Jorge Tim=C3=B3n &lt;j=
timon@jtimon.cc&gt; wrote:<br><br></blockquote></div><blockquote type=3D"cit=
e"><div dir=3D"ltr">=EF=BB=BF<div dir=3D"auto">I think the option of "perman=
ent failure because miners veto" should actually be abandoned.&nbsp;<div dir=
=3D"auto">No, I don't think we should avoid splits when possible, I don't th=
ink we should avoid splits at all costs.</div><div dir=3D"auto"><br></div></=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On S=
un, Jun 27, 2021, 19:12 Billy Tetrud &lt;<a href=3D"mailto:billy.tetrud@gmai=
l.com">billy.tetrud@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr">@Luke<div>&gt; They can still slow it down.</div><d=
iv><br></div><div>Absolutely. However I think that the option of permanent f=
ailure is important. It certainly would be ideal to ensure that enough bitco=
in users support the upgrade *before* releasing it, however realistically th=
is can never be more than an estimate, and estimates can sometimes be wildly=
 wrong. It would be unfortunate if miners had a substantially different esti=
mate of user support than the people putting in the work to release bitcoin u=
pgrades. Even if upgrades are never released before it becomes clear that a l=
arge 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 g=
oal here is to prevent a chain split during an upgrade when possible. This i=
ncludes permanent&nbsp;failure of an upgrade when there is unexpectedly larg=
e miner opposition.&nbsp;</div><div><br></div><div>This of course does not p=
revent a UASF-style deployment to be done after an initial failure to deploy=
 occurs. My proposal is essentially a mechanism to improve upon the speedy-t=
rial idea, allowing for even speedier releases (than speedy trial) without a=
dding additional risk of undesired chain splits.&nbsp;</div><div><br></div><=
div>&gt; [BIP8] already has the trinary state you seem to be describing</div=
><div><br></div><div>It sounds like you're saying the trinary state of BIP8 i=
s 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 is ma=
terially different - it is the signaling itself that is trinary, not just wh=
ich chain is being followed. This allows others to know and make programmati=
c decisions (in software) based on that signaling. I'm sure you can agree th=
at does not exist in BIP8.&nbsp;</div><div><br></div><div>&gt; No additional=
 bit is needed, as softforks are coordinated between users, NOT miners</div>=
<div><br></div><div>And yet there is miner involvement, as you rightly point=
ed 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 m=
ean? 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 consid=
er what miners might be opposing an upgrade?&nbsp;</div><div><br></div><div>=
@Jorge<br></div><div>&gt; If different users want different incompatible thi=
ngs... there's no way to avoid the split</div><div><br></div><div>I agree. T=
his happened with bcash, and that's fine. It was painful, but there were a s=
ignificant amount of users that disagreed, and they have the chain they want=
 now.</div><div><br></div><div><div>But we generally all want to avoid a cha=
in split when possible. Because chain splits have a cost, and that cost can b=
e high, its likely that many users would rather choose the chain with the mo=
st support rather than choosing the chain with their preferred rules.</div><=
/div><div><br></div><div>However, the question here is: how do we estimate w=
hat fraction of users wants which rules? We don't have a divining rod to det=
ermine with certainty what users want. We can only make polls of various lev=
els of inaccuracy. The methods bitcoin has been using is community discussio=
n and social consensus estimation as well as miner signaling during the actu=
al deployment period.=20

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 m=
ay be substantially inaccurate when we design deployment procedures. This in=
accuracy is why we need multiple barriers in place for an upgrade, and why w=
e need to have higher thresholds of success (require larger supermajorities i=
n both consensus and miner signaling).&nbsp;</div><div><br></div><div>Develo=
pers obviously care about bitcoin and have an incentive (personal and probab=
ly financial) to do it right. And miners have both an incentive to keep the s=
ystem healthy, as well as an incentive to mine on the chain that the economi=
c majority of users is using. But measuring the consensus of the bitcoin com=
munity can be extraordinarily difficult to do with consistent accuracy, and s=
o I think miner signaling as it has been used as a second barrier to entry f=
or an upgrade is quite appropriate.&nbsp;</div></div><br><div class=3D"gmail=
_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jun 27, 2021 at 2:22 A=
M Eric Voskuil &lt;<a href=3D"mailto:eric@voskuil.org" target=3D"_blank" rel=
=3D"noreferrer">eric@voskuil.org</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">I have not objected to anyone splitting. As I s=
aid, a split is always possible, and of course has been done on a large scal=
e. It is only the misleading statements about inherent soft fork =E2=80=9Cco=
mpatibility=E2=80=9D and the implication that activation without hash power e=
nforcement does not create a split that I object to. People who know better s=
hould be honest about it.<br>
<br>
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.<br>
<br>
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.<br>
<br>
e<br>
<br>
&gt; On Jun 27, 2021, at 01:47, Jorge Tim=C3=B3n &lt;jtimon@jtimon.cc&gt; wr=
ote:<br>
&gt; <br>
&gt; =EF=BB=BFIf different users want different incompatible things (enough o=
n each<br>
&gt; side), there's no way to avoid the split. We shouldn't try to avoid<br>=

&gt; such a split.<br>
&gt; Users decide the rules, not miners nor developers.<br>
&gt; <br>
&gt;&gt; On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev<br>
&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>&gt;=
 wrote:<br>
&gt;&gt; <br>
&gt;&gt; Ultimately there is only one answer to this question. Get majority h=
ash power support.<br>
&gt;&gt; <br>
&gt;&gt; Soft fork enforcement is the same act as any other censorship enfor=
cement, the difference is only a question of what people want. Given that th=
ere is no collective =E2=80=9Cwe=E2=80=9D, those wants differ. Bitcoin resol=
ves this question of conflicting wants, but it is not a democracy, it=E2=80=99=
s a market. One votes by trading.<br>
&gt;&gt; <br>
&gt;&gt; If one wants to enforce a soft fork (or otherwise censor) this is a=
ccomplished by mining (or paying others to do so). Anyone can mine, so every=
one gets a say. Mining is trading capital now for more later. If enough peop=
le want to do that, they can enforce a soft fork. It=E2=80=99s time Bitcoine=
rs stop thinking of miners as other people. Anyone can mine, and that=E2=80=99=
s your vote.<br>
&gt;&gt; <br>
&gt;&gt; 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 f=
ollow. This cannot be known, it=E2=80=99s merely a gamble. And it=E2=80=99s o=
ne that has been shown to not always pay off.<br>
&gt;&gt; <br>
&gt;&gt; e<br>
&gt;&gt; <br>
&gt;&gt;&gt;&gt; On Jun 26, 2021, at 14:43, Eric Voskuil &lt;<a href=3D"mail=
to:eric@voskuil.org" target=3D"_blank" rel=3D"noreferrer">eric@voskuil.org</=
a>&gt; wrote:<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; =EF=BB=BFFor some definitions of =E2=80=9Cblock=E2=80=9D.<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; Without majority hash power support, activation simply means yo=
u are off on a chain split. Anyone can of course split off from a chain by c=
hanging a rule (soft or otherwise) at any time, so this is a bit of an empty=
 claim.<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; Nobody can stop a person from splitting. The relevant question i=
s how to *prevent* a split. And activation without majority hash power certa=
inly does not =E2=80=9Censure=E2=80=9D this.<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; e<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev &lt;=
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" r=
el=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; =EF=BB=BFBIP8 LOT=3DTrue just ensures miners cannot block a=
n upgrade entirely. They can<br>
&gt;&gt;&gt;&gt; still slow it down.<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; It also already has the trinary state you seem to be descri=
bing (although<br>
&gt;&gt;&gt;&gt; perhaps this could be better documented in the BIP): users w=
ho oppose the<br>
&gt;&gt;&gt;&gt; softfork can and should treat the successful signal (whethe=
r MASF or UASF) as<br>
&gt;&gt;&gt;&gt; invalid, thereby ensuring they do not follow a chain with t=
he rules in force.<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; No additional bit is needed, as softforks are coordinated b=
etween users, NOT<br>
&gt;&gt;&gt;&gt; miners (who have no particular say in them, aside from thei=
r role as also<br>
&gt;&gt;&gt;&gt; being users). The miner involvement is only out of necessit=
y (to set the bit<br>
&gt;&gt;&gt;&gt; in the header, which users coordinate with) and potentially=
 to accelerate<br>
&gt;&gt;&gt;&gt; activation by protecting upgrade-lagging users.<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; Luke<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt;&gt; On Saturday 26 June 2021 20:21:52 Billy Tetrud via b=
itcoin-dev wrote:<br>
&gt;&gt;&gt;&gt;&gt; Given the recent controversy over upgrade mechanisms fo=
r the<br>
&gt;&gt;&gt;&gt;&gt; non-controversial taproot upgrade, I have been thinking=
 about ways to solve<br>
&gt;&gt;&gt;&gt;&gt; the problems that both sides brought up. In short, BIP8=
 LOT=3Dtrue proponents<br>
&gt;&gt;&gt;&gt;&gt; make the point that lazy miners failing to upgrade in a=
 timely manner slow<br>
&gt;&gt;&gt;&gt;&gt; down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=3D=
false<br>
&gt;&gt;&gt;&gt;&gt; proponents make the point that LOT=3Dtrue can lead to u=
ndesirable forks that<br>
&gt;&gt;&gt;&gt;&gt; might cause a lot of chaos. I believe both points are e=
ssentially correct<br>
&gt;&gt;&gt;&gt;&gt; and have created a proposal<br>
&gt;&gt;&gt;&gt;&gt; &lt;<a href=3D"https://github.com/fresheneesz/bip-trina=
ry-version-signaling/blob/master/b" rel=3D"noreferrer noreferrer" target=3D"=
_blank">https://github.com/fresheneesz/bip-trinary-version-signaling/blob/ma=
ster/b</a><br>
&gt;&gt;&gt;&gt;&gt; ip-trinary-version-bits.md&gt; for soft fork upgrades t=
hat solve both problems.<br>
&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt; The proposal uses trinary version signaling rather than=
 binary signaling.<br>
&gt;&gt;&gt;&gt;&gt; For any particular prospective soft fork upgrade, this a=
llows for three<br>
&gt;&gt;&gt;&gt;&gt; signaling states:<br>
&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt; * Actively support the change.<br>
&gt;&gt;&gt;&gt;&gt; * Actively oppose the change.<br>
&gt;&gt;&gt;&gt;&gt; * Not signaling (neither support or oppose). This is th=
e default state.<br>
&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt; Using this additional information, we can release non-c=
ontentious upgrades<br>
&gt;&gt;&gt;&gt;&gt; much quicker (with a much lower percent of miners signa=
ling support). For<br>
&gt;&gt;&gt;&gt;&gt; contentious upgrades, miners who oppose the change are i=
ncentivized to<br>
&gt;&gt;&gt;&gt;&gt; update their software to a version that can actively si=
gnal opposition to<br>
&gt;&gt;&gt;&gt;&gt; the change. The more opposition there is, the higher th=
e threshold<br>
&gt;&gt;&gt;&gt;&gt; necessary to lock in the upgrade. With the parameters I=
 currently<br>
&gt;&gt;&gt;&gt;&gt; recommended in the proposal, this chart shows how much s=
upport signaling<br>
&gt;&gt;&gt;&gt;&gt; would be necessary given a particular amount of active o=
pposition<br>
&gt;&gt;&gt;&gt;&gt; signaling:<br>
&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt; [image: thresholdChart.png]<br>
&gt;&gt;&gt;&gt;&gt; If literally no one signals opposition, a 60% threshold=
 should be<br>
&gt;&gt;&gt;&gt;&gt; relatively safe because it is a supermajority amount th=
at is unlikely to<br>
&gt;&gt;&gt;&gt;&gt; change significantly very quickly (ie if 60% of miners s=
upport the change<br>
&gt;&gt;&gt;&gt;&gt; today, its unlikely that less than a majority of miners=
 would support the<br>
&gt;&gt;&gt;&gt;&gt; change a year or two from now), and if no one is signal=
ing opposition,<br>
&gt;&gt;&gt;&gt;&gt; chances are that the vast majority of the other 40% wou=
ld also eventually<br>
&gt;&gt;&gt;&gt;&gt; signal support.<br>
&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt; This both gives an incentive for "lazy" miners to upgra=
de if they actually<br>
&gt;&gt;&gt;&gt;&gt; oppose the change while at the same time allowing these=
 lazy miners to<br>
&gt;&gt;&gt;&gt;&gt; remain lazy without slowing down the soft fork activati=
on much.<br>
&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt; I think now is the right time to discuss new soft fork u=
pgrade mechanisms,<br>
&gt;&gt;&gt;&gt;&gt; when there are no pressing soft fork upgrades ready to d=
eploy. Waiting<br>
&gt;&gt;&gt;&gt;&gt; until we need to deploy a soft fork to discuss this wil=
l only delay things<br>
&gt;&gt;&gt;&gt;&gt; and cause contention again like it did with taproot.<br=
>
&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt; I'm very curious to know what people think of this mech=
anism. I would<br>
&gt;&gt;&gt;&gt;&gt; appreciate any comments here, or written as github issu=
es on the proposal<br>
&gt;&gt;&gt;&gt;&gt; repo itself.<br>
&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt; Thanks,<br>
&gt;&gt;&gt;&gt;&gt; BT<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt;&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
rget=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>=
<br>
&gt;&gt;&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listin=
fo/bitcoin-dev" rel=3D"noreferrer noreferrer" target=3D"_blank">https://list=
s.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"=
_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitco=
in-dev" rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxf=
oundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>
</div></blockquote></body></html>=

--Apple-Mail-6D18B293-AAE4-46AC-9D81-827DBC6557EA--