path: root/5c/119ddd62eca3ffdd12332b23f904cb6424ccf1

Return-Path: <jtimon@jtimon.cc>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6E6ABC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 08:32:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 4EF0B40263
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 08:32:42 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.92
X-Spam-Level: 
X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=jtimon-cc.20150623.gappssmtp.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id WGJE-Gm_6Scn
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 08:32:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com
 [IPv6:2607:f8b0:4864:20::b2c])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 7EB2B4025D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 08:32:39 +0000 (UTC)
Received: by mail-yb1-xb2c.google.com with SMTP id k184so16279219ybf.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Jun 2021 01:32:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=IWfli4P2yGC8Z5bia9BAc2/4K+rd8Ltcku2s5N9e4bo=;
 b=iZCOYINHCk3CboeHULZBT1BQn3nHIOYA6BHLBQ7WUxMFH/i7nlzOkcipVwE6RLNgzV
 dk42W+RaKTPTFi1vQl9ildndl2XvHnM24damNPc8MaB41puUnpqShxnzNqr+IvMYKgMJ
 RjCcUPt0P8v1DiZh2CXEjhMUH8nmmppseI+QadTC4tbah+vgS5DzKw1pJuqY4oIE0bm9
 FDeqrBb9zAT/7Q0UdCQISCU28lLi9AntIwM8zRDpVb4uHsRcQcfjeXuaj6h1esB7cywS
 6qfbKxtXO1vuno1zwaFHsc+bu+RMH0DnLcbe+WUDn245G6BBuSD1VnJ9c7KgvftF/oZG
 MACg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=IWfli4P2yGC8Z5bia9BAc2/4K+rd8Ltcku2s5N9e4bo=;
 b=oAjRbUWgilgJ/Bqlszxcb0ZYhHs0++CbGeBx+BmG6iBFxzjFUnaNtJgIExjBbqAopH
 somPdh1+UwXNxSqWr7ZgKmUDQTSUWCWlurfkHG9xabZdudAj9p3ZFL763/Ublhpvqoy/
 q6nzCRoijH+aLl9pMbBSr/f2txqUdfhx4ht7Pk6e4wcHTIisW5jFEBBfDAOe3B0kPl2k
 OwqXK/47EcnEZwna0zypGMaWY2JpSt/rql75ColZj2ZlhQU0XZa6vwgULmBMOjMSoMBK
 u96zY4ou/nclmEAclVkzUJiUAcKRTUP0yCNp7fExsrWwQLubDKV9T27hqODTF2aqCXP8
 dEUQ==
X-Gm-Message-State: AOAM530JadyhjQ8XStkeRuqAY+1vTvE1e1dhv5p4JT/lHroRkr7OrWmX
 QaVgJiwY2I2joYMQmCVue4nydt+4xtG1vjl3rE/Zxw==
X-Google-Smtp-Source: ABdhPJzR7tWMj0ykIcgqkQEsAYqtZeHll3JRrhWBNpqQe6BfHcp8BxiNjIf3jL7UsNXo3vEoEla3vMlVkCn30f/Io9M=
X-Received: by 2002:a25:e756:: with SMTP id e83mr16229467ybh.133.1624955558349; 
 Tue, 29 Jun 2021 01:32:38 -0700 (PDT)
MIME-Version: 1.0
References: <CABm2gDrCOVN5FQ4DCGwG=1XjZisTVQdOKCwuPnNxd6yHQhy6rA@mail.gmail.com>
 <E6D7F613-2378-44BE-8AFD-CB9A3CF59675@voskuil.org>
 <CAGpPWDZKU7bM4URGxceoCmbvJNJBVhSsaiXTjie7kPoBh3TCkQ@mail.gmail.com>
In-Reply-To: <CAGpPWDZKU7bM4URGxceoCmbvJNJBVhSsaiXTjie7kPoBh3TCkQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Tue, 29 Jun 2021 09:32:33 +0100
Message-ID: <CABm2gDqQm0_JnddJ2AKbDnNTGV0kYm-zOqtyZFn2=GHRb2cY2g@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000d4e64d05c5e372de"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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:32:42 -0000

--000000000000d4e64d05c5e372de
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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.


On Sun, Jun 27, 2021, 19:12 Billy Tetrud <billy.tetrud@gmail.com> wrote:

> @Luke
> > They can still slow it down.
>
> Absolutely. However I think that the option of permanent failure is
> important. It certainly would be ideal to ensure that enough bitcoin user=
s
> 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 wi=
th
> Eric that the goal here is to prevent a chain split during an upgrade whe=
n
> possible. This includes permanent failure of an upgrade when there is
> unexpectedly large miner opposition.
>
> This of course does not prevent a UASF-style deployment to be done after
> an initial failure to deploy occurs. My proposal is essentially a mechani=
sm
> to improve upon the speedy-trial idea, allowing for even speedier release=
s
> (than speedy trial) without adding additional risk of undesired chain
> splits.
>
> > [BIP8] already has the trinary state you seem to be describing
>
> 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 is 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.
>
> > No additional bit is needed, as softforks are coordinated between users=
,
> NOT miners
>
> 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
> 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?
>
> @Jorge
> > If different users want different incompatible things... there's no way
> to avoid the split
>
> 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 th=
e
> chain they want now.
>
> 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.
>
> However, the question here is: how do we estimate what fraction of users
> wants which rules? We don't have a divining rod to determine with certain=
ty
> 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 a=
re
> very rough estimates of user sentiment, we need to consider the possibili=
ty
> that sometimes the estimate may be substantially inaccurate when we desig=
n
> deployment procedures. This inaccuracy is why we need multiple barriers i=
n
> place for an upgrade, and why we need to have higher thresholds of succes=
s
> (require larger supermajorities in both consensus and miner signaling).
>
> 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 on 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 has been used a=
s
> a second barrier to entry for an upgrade is quite appropriate.
>
> 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 crea=
te
>> a split 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
>> 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 enforceme=
nt.
>> Soft forks are rule changes, and thereby incompatible - unless enforced =
by
>> majority hash power.
>>
>> 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 i=
dea
>> that =E2=80=9Cusers=E2=80=9D decide the rules is not the question. The q=
uestion 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:
>> >
>> > =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.
>> >
>> >> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
>> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >>
>> >> Ultimately there is only one answer to this question. Get majority
>> hash power support.
>> >>
>> >> Soft fork enforcement is the same act as any other censorship
>> enforcement, the difference is only a question of what people want. Give=
n
>> that there is no collective =E2=80=9Cwe=E2=80=9D, those wants differ. Bi=
tcoin resolves this
>> question of conflicting wants, but it is not a democracy, it=E2=80=99s a=
 market.
>> One votes by trading.
>> >>
>> >> 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=99=
s time
>> Bitcoiners stop thinking of miners as other people. Anyone can mine, and
>> that=E2=80=99s your vote.
>> >>
>> >> 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 follo=
w.
>> 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.
>> >>
>> >> e
>> >>
>> >>>> On Jun 26, 2021, at 14:43, Eric Voskuil <eric@voskuil.org> wrote:
>> >>>
>> >>> =EF=BB=BFFor some definitions of =E2=80=9Cblock=E2=80=9D.
>> >>>
>> >>> 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.
>> >>>
>> >>> Nobody can stop a person from splitting. The relevant question is ho=
w
>> to *prevent* a split. And activation without majority hash power certain=
ly
>> does not =E2=80=9Censure=E2=80=9D this.
>> >>>
>> >>> e
>> >>>
>> >>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >>>>
>> >>>> =EF=BB=BFBIP8 LOT=3DTrue just ensures miners cannot block an upgrad=
e entirely.
>> They can
>> >>>> still slow it down.
>> >>>>
>> >>>> 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 o=
r
>> UASF) as
>> >>>> invalid, thereby ensuring they do not follow a chain with the rules
>> in force.
>> >>>>
>> >>>> No additional bit is needed, as softforks are coordinated between
>> users, 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
>> accelerate
>> >>>> activation by protecting upgrade-lagging users.
>> >>>>
>> >>>> Luke
>> >>>>
>> >>>>
>> >>>>>> 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 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
>> 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/blob/master=
/b
>> >>>>> ip-trinary-version-bits.md> for soft fork upgrades that solve both
>> problems.
>> >>>>>
>> >>>>> The proposal uses trinary version signaling rather than binary
>> signaling.
>> >>>>> For any particular prospective soft fork upgrade, this allows for
>> three
>> >>>>> signaling states:
>> >>>>>
>> >>>>> * Actively support the change.
>> >>>>> * Actively oppose the change.
>> >>>>> * Not signaling (neither support or oppose). This is the default
>> state.
>> >>>>>
>> >>>>> 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 incentivize=
d
>> 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:
>> >>>>>
>> >>>>> [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.
>> >>>>>
>> >>>>> This both gives an incentive for "lazy" miners to upgrade if they
>> actually
>> >>>>> oppose the change while at the same time allowing these lazy miner=
s
>> to
>> >>>>> remain lazy without slowing down the soft fork activation much.
>> >>>>>
>> >>>>> 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 dela=
y
>> things
>> >>>>> and cause contention again like it did with taproot.
>> >>>>>
>> >>>>> 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.
>> >>>>>
>> >>>>> Thanks,
>> >>>>> BT
>> >>>>
>> >>>> _______________________________________________
>> >>>> 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
>>
>

--000000000000d4e64d05c5e372de
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">I think the option of &quot;permanent failure because min=
ers veto&quot; should actually be abandoned.=C2=A0<div dir=3D"auto">No, I d=
on&#39;t think we should avoid splits when possible, I don&#39;t think we s=
hould 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 Sun, J=
un 27, 2021, 19:12 Billy Tetrud &lt;<a href=3D"mailto:billy.tetrud@gmail.co=
m">billy.tetrud@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">@Luke<div>&gt; They can still slow it down.</div><di=
v><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 bitc=
oin users support the upgrade *before* releasing it, however realistically =
this can never be more than an estimate, and estimates can sometimes be wil=
dly wrong. It would be unfortunate if miners had a substantially different =
estimate of user support than the people putting in the work to release bit=
coin upgrades. Even if upgrades are never released before it becomes clear =
that a large supermajority of users want the upgrade, if miners don&#39;t a=
gree 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=C2=A0failure of an upgrade when there is =
unexpectedly large miner opposition.=C2=A0</div><div><br></div><div>This of=
 course does not prevent a UASF-style deployment to be done after an initia=
l failure to deploy occurs. My proposal is essentially a mechanism to impro=
ve upon the speedy-trial idea, allowing for even speedier releases (than sp=
eedy trial) without adding additional risk of undesired chain splits.=C2=A0=
</div><div><br></div><div>&gt; [BIP8] already has the trinary state you see=
m to be describing</div><div><br></div><div>It sounds like you&#39;re sayin=
g the trinary state of BIP8 is A. Follow the longest chain, B. Follow the u=
pgrade chain, or C. follow the non-upgraded chain. I agree. However the tri=
nary state in my proposal is materially different - it is the signaling its=
elf that is trinary, not just which chain is being followed. This allows ot=
hers to know and make programmatic decisions (in software) based on that si=
gnaling. I&#39;m sure you can agree that does not exist in BIP8.=C2=A0</div=
><div><br></div><div>&gt; No additional bit is needed, as softforks are coo=
rdinated between users, NOT miners</div><div><br></div><div>And yet there i=
s miner involvement, as you rightly pointed out. Miners are needed to set t=
he nVersion in the header. So when you say &quot;no additional bit is neede=
d&quot;, 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 &quot;additional=
 bit&quot;? Or are you just saying that it is redundant to consider what mi=
ners might be opposing an upgrade?=C2=A0</div><div><br></div><div>@Jorge<br=
></div><div>&gt; If different users want different incompatible things... t=
here&#39;s no way to avoid the split</div><div><br></div><div>I agree. This=
 happened with bcash, and that&#39;s fine. It was painful, but there were a=
 significant amount of users that disagreed, and they have the chain they w=
ant now.</div><div><br></div><div><div>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=
.</div></div><div><br></div><div>However, the question here is: how do we e=
stimate what fraction of users wants which rules? We don&#39;t have a divin=
ing 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 com=
munity discussion and social consensus estimation as well as miner signalin=
g during the actual deployment period.=20

Neither of these are perfect, but they are both reasonable enough mechanism=
s. However, because both of these mechanisms are very rough estimates of us=
er sentiment, we need to consider the possibility that sometimes the estima=
te may be substantially inaccurate when we design deployment procedures. Th=
is inaccuracy is why we need multiple barriers in place for an upgrade, and=
 why we need to have higher thresholds of success (require larger supermajo=
rities in both consensus and miner signaling).=C2=A0</div><div><br></div><d=
iv>Developers obviously care about bitcoin and have an incentive (personal =
and probably financial) to do it right. And miners have both an incentive t=
o keep the system healthy, as well as an incentive to mine on the chain tha=
t the economic majority of users is using. But measuring the consensus of t=
he bitcoin community can be extraordinarily difficult to do with consistent=
 accuracy, and so I think miner signaling as it has been used as a second b=
arrier to entry for an upgrade is quite appropriate.=C2=A0</div></div><br><=
div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jun=
 27, 2021 at 2:22 AM Eric Voskuil &lt;<a href=3D"mailto:eric@voskuil.org" t=
arget=3D"_blank" rel=3D"noreferrer">eric@voskuil.org</a>&gt; wrote:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">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 inhe=
rent soft fork =E2=80=9Ccompatibility=E2=80=9D and the implication that act=
ivation without hash power enforcement does not create a split that I objec=
t to. People who know better should be honest about it.<br>
<br>
Far too many people have been led to believe there is some sort of activati=
on choice with =E2=80=9Censured=E2=80=9D equal outcomes (maybe =E2=80=9Cslo=
wed down=E2=80=9D). There is only a choice between creating a split and has=
h power enforcement. Soft forks are rule changes, and thereby incompatible =
- unless enforced by majority hash power.<br>
<br>
The statements below are grossly misleading and need to be called out as su=
ch so that people can actually make this decision you speak of. This idea t=
hat =E2=80=9Cusers=E2=80=9D decide the rules is not the question. The quest=
ion 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; w=
rote:<br>
&gt; <br>
&gt; =EF=BB=BFIf different users want different incompatible things (enough=
 on each<br>
&gt; side), there&#39;s no way to avoid the split. We shouldn&#39;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" targe=
t=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t; wrote:<br>
&gt;&gt; <br>
&gt;&gt; Ultimately there is only one answer to this question. Get majority=
 hash power support.<br>
&gt;&gt; <br>
&gt;&gt; Soft fork enforcement is the same act as any other censorship enfo=
rcement, 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 re=
solves this question of conflicting wants, but it is not a democracy, it=E2=
=80=99s 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 =
accomplished by mining (or paying others to do so). Anyone can mine, so eve=
ryone gets a say. Mining is trading capital now for more later. If enough p=
eople want to do that, they can enforce a soft fork. It=E2=80=99s time Bitc=
oiners stop thinking of miners as other people. Anyone can mine, and that=
=E2=80=99s 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 sure=
ly 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.<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"mai=
lto: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 y=
ou 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 em=
pty claim.<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; Nobody can stop a person from splitting. The relevant question=
 is how to *prevent* a split. And activation without majority hash power ce=
rtainly 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"=
 rel=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 =
an 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 descr=
ibing (although<br>
&gt;&gt;&gt;&gt; perhaps this could be better documented in the BIP): users=
 who oppose the<br>
&gt;&gt;&gt;&gt; softfork can and should treat the successful signal (wheth=
er MASF or UASF) as<br>
&gt;&gt;&gt;&gt; invalid, thereby ensuring they do not follow a chain with =
the rules in force.<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; No additional bit is needed, as softforks are coordinated =
between users, NOT<br>
&gt;&gt;&gt;&gt; miners (who have no particular say in them, aside from the=
ir role as also<br>
&gt;&gt;&gt;&gt; being users). The miner involvement is only out of necessi=
ty (to set the bit<br>
&gt;&gt;&gt;&gt; in the header, which users coordinate with) and potentiall=
y 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=
 bitcoin-dev wrote:<br>
&gt;&gt;&gt;&gt;&gt; Given the recent controversy over upgrade mechanisms f=
or the<br>
&gt;&gt;&gt;&gt;&gt; non-controversial taproot upgrade, I have been thinkin=
g about ways to solve<br>
&gt;&gt;&gt;&gt;&gt; the problems that both sides brought up. In short, BIP=
8 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=
=3Dfalse<br>
&gt;&gt;&gt;&gt;&gt; proponents make the point that LOT=3Dtrue can lead to =
undesirable forks that<br>
&gt;&gt;&gt;&gt;&gt; might cause a lot of chaos. I believe both points are =
essentially 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-trin=
ary-version-signaling/blob/master/b" rel=3D"noreferrer noreferrer" target=
=3D"_blank">https://github.com/fresheneesz/bip-trinary-version-signaling/bl=
ob/master/b</a><br>
&gt;&gt;&gt;&gt;&gt; ip-trinary-version-bits.md&gt; for soft fork upgrades =
that solve both problems.<br>
&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt; The proposal uses trinary version signaling rather tha=
n binary signaling.<br>
&gt;&gt;&gt;&gt;&gt; For any particular prospective soft fork upgrade, this=
 allows 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 t=
he default state.<br>
&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt; Using this additional information, we can release non-=
contentious upgrades<br>
&gt;&gt;&gt;&gt;&gt; much quicker (with a much lower percent of miners sign=
aling support). For<br>
&gt;&gt;&gt;&gt;&gt; contentious upgrades, miners who oppose the change are=
 incentivized to<br>
&gt;&gt;&gt;&gt;&gt; update their software to a version that can actively s=
ignal opposition to<br>
&gt;&gt;&gt;&gt;&gt; the change. The more opposition there is, the higher t=
he 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=
 support signaling<br>
&gt;&gt;&gt;&gt;&gt; would be necessary given a particular amount of active=
 opposition<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% threshol=
d should be<br>
&gt;&gt;&gt;&gt;&gt; relatively safe because it is a supermajority amount t=
hat is unlikely to<br>
&gt;&gt;&gt;&gt;&gt; change significantly very quickly (ie if 60% of miners=
 support the change<br>
&gt;&gt;&gt;&gt;&gt; today, its unlikely that less than a majority of miner=
s would support the<br>
&gt;&gt;&gt;&gt;&gt; change a year or two from now), and if no one is signa=
ling opposition,<br>
&gt;&gt;&gt;&gt;&gt; chances are that the vast majority of the other 40% wo=
uld 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 &quot;lazy&quot; mine=
rs to upgrade if they actually<br>
&gt;&gt;&gt;&gt;&gt; oppose the change while at the same time allowing thes=
e lazy miners to<br>
&gt;&gt;&gt;&gt;&gt; remain lazy without slowing down the soft fork activat=
ion 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=
 upgrade mechanisms,<br>
&gt;&gt;&gt;&gt;&gt; when there are no pressing soft fork upgrades ready to=
 deploy. Waiting<br>
&gt;&gt;&gt;&gt;&gt; until we need to deploy a soft fork to discuss this wi=
ll only delay things<br>
&gt;&gt;&gt;&gt;&gt; and cause contention again like it did with taproot.<b=
r>
&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt; I&#39;m very curious to know what people think of this=
 mechanism. I would<br>
&gt;&gt;&gt;&gt;&gt; appreciate any comments here, or written as github iss=
ues 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" t=
arget=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</=
a><br>
&gt;&gt;&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listi=
nfo/bitcoin-dev" rel=3D"noreferrer noreferrer" target=3D"_blank">https://li=
sts.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/bitc=
oin-dev" rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linu=
xfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>

--000000000000d4e64d05c5e372de--