From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6E6ABC000E for ; 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 ; 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 ; 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 ; Tue, 29 Jun 2021 08:32:39 +0000 (UTC) Received: by mail-yb1-xb2c.google.com with SMTP id k184so16279219ybf.12 for ; 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: In-Reply-To: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Date: Tue, 29 Jun 2021 09:32:33 +0100 Message-ID: To: Billy Tetrud Content-Type: multipart/alternative; boundary="000000000000d4e64d05c5e372de" Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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 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 >> >> 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 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
I think the option of "permanent failure because min= ers veto" should actually be abandoned.=C2=A0
No, I d= on't think we should avoid splits when possible, I don't think we s= hould avoid splits at all costs.

On Sun, J= un 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 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'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

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=

> [BIP8] already has the trinary state you see= m to be describing

It sounds like you'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'm sure you can agree that does not exist in BIP8.=C2=A0

> No additional bit is needed, as softforks are coo= rdinated between users, NOT miners

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 "no additional bit is neede= d", 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 mi= ners might be opposing an upgrade?=C2=A0

@Jorge
> If different users want different incompatible things... t= here'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 the chain they w= ant 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 e= stimate what fraction of users wants which rules? We don'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

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 class=3D"gmail_quote">
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 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.

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.

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.

e

> On Jun 27, 2021, at 01:47, Jorge Tim=C3=B3n <jtimon@jtimon.cc> w= rote:
>
> =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&g= t; 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 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.
>>
>> 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.
>>
>> 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.
>>
>> 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 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.
>>>
>>> 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.
>>>
>>> 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 upgrade entirely. They can
>>>> still slow it down.
>>>>
>>>> It also already has the trinary state you seem to be descr= ibing (although
>>>> perhaps this could be better documented in the BIP): users= who oppose the
>>>> softfork can and should treat the successful signal (wheth= er MASF or 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 the= ir role as also
>>>> being users). The miner involvement is only out of necessi= ty (to set the bit
>>>> in the header, which users coordinate with) and potentiall= y 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 f= or the
>>>>> non-controversial taproot upgrade, I have been thinkin= g about ways to solve
>>>>> the problems that both sides brought up. In short, BIP= 8 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/bl= ob/master/b
>>>>> ip-trinary-version-bits.md> for soft fork upgrades = that solve both problems.
>>>>>
>>>>> The proposal uses trinary version signaling rather tha= n 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 t= he default state.
>>>>>
>>>>> Using this additional information, we can release non-= contentious upgrades
>>>>> much quicker (with a much lower percent of miners sign= aling support). For
>>>>> contentious upgrades, miners who oppose the change are= incentivized to
>>>>> update their software to a version that can actively s= ignal opposition to
>>>>> the change. The more opposition there is, the higher t= he 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% threshol= d should be
>>>>> relatively safe because it is a supermajority amount t= hat is unlikely to
>>>>> change significantly very quickly (ie if 60% of miners= support the change
>>>>> today, its unlikely that less than a majority of miner= s would support the
>>>>> change a year or two from now), and if no one is signa= ling opposition,
>>>>> chances are that the vast majority of the other 40% wo= uld also eventually
>>>>> signal support.
>>>>>
>>>>> This both gives an incentive for "lazy" mine= rs to upgrade if they actually
>>>>> oppose the change while at the same time allowing thes= e lazy miners to
>>>>> remain lazy without slowing down the soft fork activat= ion 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 wi= ll only delay 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 iss= ues on the proposal
>>>>> repo itself.
>>>>>
>>>>> Thanks,
>>>>> BT
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://li= sts.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linu= xfoundation.org/mailman/listinfo/bitcoin-dev
--000000000000d4e64d05c5e372de--