From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id A5B8CC000E for ; 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 ; 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 ; 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 ; Tue, 29 Jun 2021 08:44:58 +0000 (UTC) Received: by mail-pf1-x42e.google.com with SMTP id a127so16571658pfa.10 for ; 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 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: In-Reply-To: To: =?utf-8?Q?Jorge_Tim=C3=B3n?= X-Mailer: iPhone Mail (18F72) Cc: Bitcoin Protocol Discussion , Billy Tetrud 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: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 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 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 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 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 >>> >> 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 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 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 >>> >>>>> >> >>>>> 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
At least we are now acknow= ledging that splitting is what it=E2=80=99s about. That=E2=80=99s progress.<= /div>

e
On Jun 29, 2021, at 01:32, Jorge Tim=C3=B3n <j= timon@jtimon.cc> wrote:

=EF=BB=BF
I think the option of "perman= ent failure because miners veto" should actually be abandoned. 
No, I don't think we should avoid splits when possible, I don't th= ink we should avoid splits at all costs.


On S= un, 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 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 failure of an upgrade when there is unexpectedly larg= e miner opposition. 

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. 

<= div>> [BIP8] already has the trinary state you seem to be describing

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. 

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

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? 

= @Jorge
> If different users want different incompatible thi= ngs... there's no way to avoid the split

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.

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>

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). 

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. 

On Sun, Jun 27, 2021 at 2:22 A= M Eric Voskuil <eric@voskuil.org> wrote:
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.

Far too many people have been led to believe there is some sort of activatio= n choice with =E2=80=9Censured=E2=80=9D equal outcomes (maybe =E2=80=9Cslowe= d down=E2=80=9D). There is only a choice between creating a split and hash p= ower enforcement. Soft forks are rule changes, and thereby incompatible - un= less enforced by majority hash power.

The statements below are grossly misleading and need to be called out as suc= h so that people can actually make this decision you speak of. This idea tha= t =E2=80=9Cusers=E2=80=9D decide the rules is not the question. The question= is only how to avoid a split. If one does not care he can split at any time= , no discussion required.

e

> On Jun 27, 2021, at 01:47, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wr= ote:
>
> =EF=BB=BFIf different users want different incompatible things (enough o= n 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 h= ash power support.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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 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.
>>>
>>> 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.
>>>
>>> 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 a= n upgrade entirely. They can
>>>> still slow it down.
>>>>
>>>> It also already has the trinary state you seem to be descri= bing (although
>>>> perhaps this could be better documented in the BIP): users w= ho oppose the
>>>> softfork can and should treat the successful signal (whethe= r MASF or UASF) as
>>>> invalid, thereby ensuring they do not follow a chain with t= he rules in force.
>>>>
>>>> No additional bit is needed, as softforks are coordinated b= etween users, NOT
>>>> miners (who have no particular say in them, aside from thei= r role as also
>>>> being users). The miner involvement is only out of necessit= y (to set 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 b= itcoin-dev wrote:
>>>>> Given the recent controversy over upgrade mechanisms fo= r 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=3D= false
>>>>> proponents make the point that LOT=3Dtrue can lead to u= ndesirable forks that
>>>>> might cause a lot of chaos. I believe both points are e= ssentially correct
>>>>> and have created a proposal
>>>>> <https://github.com/fresheneesz/bip-trinary-version-signaling/blob/ma= ster/b
>>>>> ip-trinary-version-bits.md> for soft fork upgrades t= hat solve both problems.
>>>>>
>>>>> The proposal uses trinary version signaling rather than= binary signaling.
>>>>> For any particular prospective soft fork upgrade, this a= llows for three
>>>>> signaling states:
>>>>>
>>>>> * Actively support the change.
>>>>> * Actively oppose the change.
>>>>> * Not signaling (neither support or oppose). This is th= e default state.
>>>>>
>>>>> Using this additional information, we can release non-c= ontentious upgrades
>>>>> much quicker (with a much lower percent of miners signa= ling support). For
>>>>> contentious upgrades, miners who oppose the change are i= ncentivized to
>>>>> update their software to a version that can actively si= gnal opposition to
>>>>> the change. The more opposition there is, the higher th= e threshold
>>>>> necessary to lock in the upgrade. With the parameters I= currently
>>>>> recommended in the proposal, this chart shows how much s= upport signaling
>>>>> would be necessary given a particular amount of active o= pposition
>>>>> signaling:
>>>>>
>>>>> [image: thresholdChart.png]
>>>>> If literally no one signals opposition, a 60% threshold= should be
>>>>> relatively safe because it is a supermajority amount th= at is unlikely to
>>>>> change significantly very quickly (ie if 60% of miners s= upport 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 signal= ing opposition,
>>>>> chances are that the vast majority of the other 40% wou= ld also eventually
>>>>> signal support.
>>>>>
>>>>> This both gives an incentive for "lazy" miners to upgra= de if they actually
>>>>> oppose the change while at the same time allowing these= lazy miners to
>>>>> remain lazy without slowing down the soft fork activati= on much.
>>>>>
>>>>> I think now is the right time to discuss new soft fork u= pgrade mechanisms,
>>>>> when there are no pressing soft fork upgrades ready to d= eploy. Waiting
>>>>> until we need to deploy a soft fork to discuss this wil= l only delay things
>>>>> and cause contention again like it did with taproot. >>>>>
>>>>> I'm very curious to know what people think of this mech= anism. I would
>>>>> appreciate any comments here, or written as github issu= es on the proposal
>>>>> repo itself.
>>>>>
>>>>> Thanks,
>>>>> BT
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org=
>>>> https://list= s.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxf= oundation.org/mailman/listinfo/bitcoin-dev
= --Apple-Mail-6D18B293-AAE4-46AC-9D81-827DBC6557EA--