Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3DAD1C000E for ; Tue, 29 Jun 2021 19:44:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 158CB83716 for ; Tue, 29 Jun 2021 19:44:14 +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: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=voskuil-org.20150623.gappssmtp.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qm2PiyqoEi-o for ; Tue, 29 Jun 2021 19:44:11 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by smtp1.osuosl.org (Postfix) with ESMTPS id ABA3883A5E for ; Tue, 29 Jun 2021 19:44:11 +0000 (UTC) Received: by mail-pj1-x1032.google.com with SMTP id n11so242596pjo.1 for ; Tue, 29 Jun 2021 12:44:11 -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=2TP4X3uUnyEQ9sC6C/aULkjeEYfFUnyq2RtDLkxZ4Kk=; b=AtUgT8BfUQT5fOnrYJV3lwgtWOoIM0pVlvKDG5D58YJD55IONoCdBs5msXDwoA/w7u QlL/mAhC96+RGG/PoexUAo9L4N9kHglAQ18DByatmTMp8sAHbe63kgqnO/dPvTMHvYeM mYlC/QZtVuaD8sr+vncS0JCxc9MsivHYNXou2XcaDNDH7BXva+THlGiV/ib9oaziUHE9 Zowsi6AALvOC6K+ynnqkvBtteLNVf3otDQk8QDhufN+jAvtIW6dze+mCz8yyuTp6Cl+V wZsZ9jI3nOniqBEwV1akNXedbVTMGUMwUuhJfp2kYoI070mNMBgKr+BhKg75Fk+cNzvw rygg== 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=2TP4X3uUnyEQ9sC6C/aULkjeEYfFUnyq2RtDLkxZ4Kk=; b=dDJ7eShC817y5fXFbTCcPFVnZdemezXO+9LveAqLZrWghbSwzn8G376zKhAKK2ksZL I7vRdp1ZTscDO8MMNzupr7VHyYG/dvgNOmRp0wXFNHPXztsLl6MpiQbCGgvB1eEm2muk 3HyjLPXpoJczDHti58xMn/Bu1d3swujmRg0xPd2uHILs6GCl6ozdvVWwCc9yGKhldOMT JEHznELGf8hky9Rb5hkHoSIzskVN+u60J0Kl5D2ODsFMVIEF/uTA5T9mWSzBUw2Fg3cx VG/irFpD70GTSDCT0ltc1/mcSswGoDyDH5yuwj7hphStea9orV5j+MeXx+s8zUA/kc9U bM4Q== X-Gm-Message-State: AOAM533U3xoDXITARaW23sgrwO/kf7cs3eqvDdKgO/a8/yPo7SDYRgxt AptUo9clG9Gc/AnalXQg0RH+iBNLyZcUzACr X-Google-Smtp-Source: ABdhPJxKsdldz7qQNdAKpaM+tNHv7ytOyTYVPUzTmxBNrcwQq79BcbNpothO1H5qcExkWAurg0WDGA== X-Received: by 2002:a17:90a:ea8b:: with SMTP id h11mr532120pjz.122.1624995850771; Tue, 29 Jun 2021 12:44:10 -0700 (PDT) Received: from smtpclient.apple ([2601:600:9c00:1d0::da55]) by smtp.gmail.com with ESMTPSA id a20sm8436976pfo.190.2021.06.29.12.44.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Jun 2021 12:44:10 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-D6009DD5-D7D5-4796-AAAE-1F5B82A74249 Content-Transfer-Encoding: 7bit From: Eric Voskuil Mime-Version: 1.0 (1.0) Date: Tue, 29 Jun 2021 12:44:09 -0700 Message-Id: <2368396E-6964-4F12-B50F-2BE477D0C7D8@voskuil.org> References: In-Reply-To: To: =?utf-8?Q?Jorge_Tim=C3=B3n?= X-Mailer: iPhone Mail (18F72) X-Mailman-Approved-At: Tue, 29 Jun 2021 21:16:54 +0000 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 19:44:14 -0000 --Apple-Mail-D6009DD5-D7D5-4796-AAAE-1F5B82A74249 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Jun 29, 2021, at 12:28, Jorge Tim=C3=B3n wrote: >=20 > =EF=BB=BF > "Confirmation" isn't needed for softforks. All transactions require confirmation. Splitting does not change this. Softforks are not compatible without miner enforcement. So soft forking with= out it has essentially the same effect as hard forking, the chain splits. > Miners controlling confirmation doesn't mean miners control the rules, the= y never did. Please define =E2=80=9Ccontrol=E2=80=9D because these statements hinge on th= at word. Nobody =E2=80=9Ccontrols=E2=80=9D the rules of others, nor did anyo= ne claim that to be the case. Majority hash power does have the ability to d= etermine what gets confirmed. That is the central design principle of proof o= f work. It takes that decision out of the hands of politicians and places it= at the feet of the market. > Read section 11 of the bitcoin paper "even with a majority of hashrate one= cannot arbitrarily change rules or forge signatures. Never claimed that was the case. One can run any rules that one desires. > You may say users chosing the rules is "politicial". Isn't miners deciding= them for users more political? No, it=E2=80=99s economic. The largest investment in mining (including highe= st fees paid to incentivize it) determines censorship resistance. > Whatever you call it, it is still how free software works: users decide wh= at to run. A *person* can run whatever software they want. Money requires that others a= gree (same rules), and to be money bitcoin requires confirmation. > It is extremely disappointing to see how few developers seem to ubderstand= this, or even care about users deciding or miners not deciding the rules. It=E2=80=99s poorly understood because there are so many who should know bet= ter making very misleading statements. > How can we expect users to understand bitcoin when most developers don't s= eem to understand it? Clearly we cannot. > It is really sad. >=20 >> On Tue, Jun 29, 2021, 19:17 Eric Voskuil wrote: >>=20 >> > On Jun 29, 2021, at 10:55, Luke Dashjr wrote: >> >=20 >> > =EF=BB=BFThe only alternative to a split in the problematic scenarios a= re 1) concede=20 >> > centralised miner control over the network, >>=20 >> Miners control confirmation, entirely. >>=20 >> This is the nature of bitcoin. And merchants control validation, entirely= . Anyone can be a miner or a merchant. Neither is inherently =E2=80=9Cbetter= =E2=80=9D than the other. The largest merchants are likely a handful of exch= anges, likely at least as centralized as miners are pooled. >>=20 >> Splitting does not change this. >>=20 >> > and 2) have inconsistent=20 >> > enforcement of rules by users who don't agree on what the correct rules= are,=20 >>=20 >> There are no =E2=80=9Ccorrect=E2=80=9D rules. Whatever rules one enforces= determine what network he chooses to participate in. >>=20 >> > again leading to centralised miner control over the network. >>=20 >> Leading to? Miners control confirmation, always. Whether that is centrali= zed, just as with merchanting, is up to individuals. >>=20 >> > In other words, in this context, accepting a split between disagreeing u= sers=20 >> > is the ONLY way Bitcoin can possibly continue as a decentralised curren= cy. >>=20 >> No, it is not. You are proposing splitting as the method of censorship re= sistance inherent to Bitcoin. Coordinating this split requires coordinated a= ction. The whole point of bitcoin is coordinate that action based on mining (= proof of work). Replacing that with a political process is just a reversion t= o political money. >>=20 >> > Making that split as clean and well-defined as possible not only ensure= s the=20 >> > best opportunity for both sides of the disagreement, >>=20 >> Trivially accomplished, just change a rule. This isn=E2=80=99t about that= . It=E2=80=99s about how one gets others to go along with the new coin, or s= tay with the old. An entirely political process, which is clearly evident fr= om the campaigns around such attempts. >>=20 >> > but also minimises the=20 >> > risk that the split occurs at all (since the "losing" side needs to con= cede,=20 >> > rather than passively continue the disagreement ongoing after the attem= pted=20 >> > protocol change). >>=20 >> Nobody =E2=80=9Cneeds to=E2=80=9D concede once a split has occurred, whic= h is evident in existing splits. >>=20 >> e >>=20 >> > Luke >> >=20 >> >=20 >> >> On Tuesday 29 June 2021 08:44:56 Eric Voskuil wrote: >> >> At least we are now acknowledging that splitting is what it=E2=80=99s a= bout. That=E2=80=99s >> >> progress. >> >>=20 >> >> e >> >>=20 >> >>>> 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 >> >>> actually be abandoned. No, I don't think we should avoid splits when >> >>> possible, I don't think we should avoid splits at all costs. >> >>>=20 >> >>>> On Sun, Jun 27, 2021, 19:12 Billy Tetrud wr= ote: >> >>>> @Luke >> >>>>=20 >> >>>>> They can still slow it down. >> >>>>=20 >> >>>> Absolutely. However I think that the option of permanent failure is >> >>>> important. It certainly would be ideal to ensure that enough bitcoin= >> >>>> users support the upgrade *before* releasing it, however realistical= ly >> >>>> 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 wo= rk >> >>>> to release bitcoin upgrades. Even if upgrades are never released bef= ore >> >>>> it becomes clear that a large supermajority of users want the upgrad= e, >> >>>> if miners don't agree with the estimate a harmful chain split could >> >>>> occur. And I agree with Eric that the goal here is to prevent a chai= n >> >>>> split during an upgrade when possible. This includes permanent failu= re >> >>>> of an upgrade when there is unexpectedly large miner opposition. >> >>>>=20 >> >>>> This of course does not prevent a UASF-style deployment to be done a= fter >> >>>> an initial failure to deploy occurs. My proposal is essentially a >> >>>> mechanism to improve upon the speedy-trial idea, allowing for even >> >>>> speedier releases (than speedy trial) without adding additional risk= of >> >>>> undesired chain splits. >> >>>>=20 >> >>>>> [BIP8] already has the trinary state you seem to be describing >> >>>>=20 >> >>>> It sounds like you're saying the trinary state of BIP8 is A. Follow t= he >> >>>> longest chain, B. Follow the upgrade chain, or C. follow the >> >>>> non-upgraded chain. I agree. However the trinary state in my proposa= l is >> >>>> materially different - it is the signaling itself that is trinary, n= ot >> >>>> just which chain is being followed. This allows others to know and m= ake >> >>>> programmatic decisions (in software) based on that signaling. I'm su= re >> >>>> you can agree that does not exist in BIP8. >> >>>>=20 >> >>>>> No additional bit is needed, as softforks are coordinated between >> >>>>> users, NOT miners >> >>>>=20 >> >>>> And yet there is miner involvement, as you rightly pointed out. Mine= rs >> >>>> 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 yo= u >> >>>> mean? Do you mean that signaling of opposition in a block can be don= e >> >>>> without any "additional bit"? Or are you just saying that it is >> >>>> redundant to consider what miners might be opposing an upgrade? >> >>>>=20 >> >>>> @Jorge >> >>>>=20 >> >>>>> If different users want different incompatible things... there's no= >> >>>>> way to avoid the split >> >>>>=20 >> >>>> I agree. This happened with bcash, and that's fine. It was painful, b= ut >> >>>> there were a significant amount of users that disagreed, and they ha= ve >> >>>> the chain they want now. >> >>>>=20 >> >>>> But we generally all want to avoid a chain split when possible. Beca= use >> >>>> 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 rathe= r >> >>>> than choosing the chain with their preferred rules. >> >>>>=20 >> >>>> However, the question here is: how do we estimate what fraction of u= sers >> >>>> wants which rules? We don't have a divining rod to determine with >> >>>> certainty what users want. We can only make polls of various levels o= f >> >>>> inaccuracy. The methods bitcoin has been using is community discussi= on >> >>>> and social consensus estimation as well as miner signaling during th= e >> >>>> actual deployment period. Neither of these are perfect, but they are= >> >>>> both reasonable enough mechanisms. However, because both of these >> >>>> mechanisms are very rough estimates of user sentiment, we need to >> >>>> consider the possibility that sometimes the estimate may be >> >>>> substantially inaccurate when we design deployment procedures. This >> >>>> inaccuracy is why we need multiple barriers in place for an upgrade,= and >> >>>> why we need to have higher thresholds of success (require larger >> >>>> supermajorities in both consensus and miner signaling). >> >>>>=20 >> >>>> Developers obviously care about bitcoin and have an incentive (perso= nal >> >>>> and probably financial) to do it right. And miners have both an >> >>>> incentive to keep the system healthy, as well as an incentive to min= e on >> >>>> the chain that the economic majority of users is using. But measurin= g >> >>>> the consensus of the bitcoin community can be extraordinarily diffic= ult >> >>>> to do with consistent accuracy, and so I think miner signaling as it= has >> >>>> been used as a second barrier to entry for an upgrade is quite >> >>>> appropriate. >> >>>>=20 >> >>>>> On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil wro= te: >> >>>>> I have not objected to anyone splitting. As I said, a split is alwa= ys >> >>>>> possible, and of course has been done on a large scale. It is only t= he >> >>>>> misleading statements about inherent soft fork =E2=80=9Ccompatibili= ty=E2=80=9D and the >> >>>>> implication that activation without hash power enforcement does not= >> >>>>> create a split that I object to. People who know better should be >> >>>>> honest about it. >> >>>>>=20 >> >>>>> Far too many people have been led to believe there is some sort of >> >>>>> activation choice with =E2=80=9Censured=E2=80=9D equal outcomes (ma= ybe =E2=80=9Cslowed down=E2=80=9D). >> >>>>> There is only a choice between creating a split and hash power >> >>>>> enforcement. Soft forks are rule changes, and thereby incompatible -= >> >>>>> unless enforced by majority hash power. >> >>>>>=20 >> >>>>> The statements below are grossly misleading and need to be called o= ut >> >>>>> 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 q= uestion. The >> >>>>> question is only how to avoid a split. If one does not care he can >> >>>>> split at any time, no discussion required. >> >>>>>=20 >> >>>>> e >> >>>>>=20 >> >>>>>> On Jun 27, 2021, at 01:47, Jorge Tim=C3=B3n wro= te: >> >>>>>>=20 >> >>>>>> =EF=BB=BFIf different users want different incompatible things (en= ough 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 majorit= y >> >>>>>>> hash power support. >> >>>>>>>=20 >> >>>>>>> Soft fork enforcement is the same act as any other censorship >> >>>>>>> enforcement, the difference is only a question of what people wan= t. >> >>>>>>> Given that there is no collective =E2=80=9Cwe=E2=80=9D, those wan= ts differ. Bitcoin >> >>>>>>> resolves this question of conflicting wants, but it is not a >> >>>>>>> democracy, it=E2=80=99s a market. One votes by trading. >> >>>>>>>=20 >> >>>>>>> If one wants to enforce a soft fork (or otherwise censor) this is= >> >>>>>>> accomplished by mining (or paying others to do so). Anyone can mi= ne, >> >>>>>>> so everyone gets a say. Mining is trading capital now for more >> >>>>>>> later. If enough people want to do that, they can enforce a soft >> >>>>>>> fork. It=E2=80=99s time Bitcoiners stop thinking of miners as oth= er people. >> >>>>>>> Anyone can mine, and that=E2=80=99s your vote. >> >>>>>>>=20 >> >>>>>>> Otherwise, as mentioned below, anyone can start a new coin. But i= t=E2=80=99s >> >>>>>>> dishonest to imply that one can do this and all others will surel= y >> >>>>>>> follow. This cannot be known, it=E2=80=99s merely a gamble. And i= t=E2=80=99s one >> >>>>>>> that has been shown to not always pay off. >> >>>>>>>=20 >> >>>>>>> e >> >>>>>>>=20 >> >>>>>>>>> On Jun 26, 2021, at 14:43, Eric Voskuil wrot= e: >> >>>>>>>>=20 >> >>>>>>>> =EF=BB=BFFor some definitions of =E2=80=9Cblock=E2=80=9D. >> >>>>>>>>=20 >> >>>>>>>> Without majority hash power support, activation simply means you= >> >>>>>>>> are off on a chain split. Anyone can of course split off from a >> >>>>>>>> chain by changing a rule (soft or otherwise) at any time, so thi= s >> >>>>>>>> is a bit of an empty claim. >> >>>>>>>>=20 >> >>>>>>>> Nobody can stop a person from splitting. The relevant question i= s >> >>>>>>>> how to *prevent* a split. And activation without majority hash >> >>>>>>>> power certainly does not =E2=80=9Censure=E2=80=9D this. >> >>>>>>>>=20 >> >>>>>>>> e >> >>>>>>>>=20 >> >>>>>>>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev >> >>>>>>>>> wrote: >> >>>>>>>>>=20 >> >>>>>>>>> =EF=BB=BFBIP8 LOT=3DTrue just ensures miners cannot block an up= grade >> >>>>>>>>> entirely. They can still slow it down. >> >>>>>>>>>=20 >> >>>>>>>>> It also already has the trinary state you seem to be describing= >> >>>>>>>>> (although perhaps this could be better documented in the BIP): >> >>>>>>>>> users who oppose the softfork can and should treat the successf= ul >> >>>>>>>>> signal (whether MASF or UASF) as invalid, thereby ensuring they= do >> >>>>>>>>> not follow a chain with the rules in force. >> >>>>>>>>>=20 >> >>>>>>>>> No additional bit is needed, as softforks are coordinated betwe= en >> >>>>>>>>> users, NOT miners (who have no particular say in them, aside fr= om >> >>>>>>>>> their role as also being users). The miner involvement is only o= ut >> >>>>>>>>> of necessity (to set the bit in the header, which users coordin= ate >> >>>>>>>>> with) and potentially to accelerate activation by protecting >> >>>>>>>>> upgrade-lagging users. >> >>>>>>>>>=20 >> >>>>>>>>> Luke >> >>>>>>>>>=20 >> >>>>>>>>>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-de= v >> >>>>>>>>>>> wrote: >> >>>>>>>>>>=20 >> >>>>>>>>>> Given the recent controversy over upgrade mechanisms for the >> >>>>>>>>>> non-controversial taproot upgrade, I have been thinking about >> >>>>>>>>>> ways to solve the problems that both sides brought up. In shor= t, >> >>>>>>>>>> BIP8 LOT=3Dtrue proponents make the point that lazy miners fai= ling >> >>>>>>>>>> to upgrade in a timely manner slow down releases of bitcoin >> >>>>>>>>>> upgrades, and BIP9 / BIP8 LOT=3Dfalse proponents make the poin= t >> >>>>>>>>>> that LOT=3Dtrue can lead to undesirable forks that might cause= a >> >>>>>>>>>> lot of chaos. I believe both points are essentially correct an= d >> >>>>>>>>>> have created a proposal >> >>>>>>>>>> > >>>>>>>>>> b/master/b ip-trinary-version-bits.md> for soft fork upgrades t= hat >> >>>>>>>>>> solve both problems. >> >>>>>>>>>>=20 >> >>>>>>>>>> The proposal uses trinary version signaling rather than binary= >> >>>>>>>>>> signaling. For any particular prospective soft fork upgrade, t= his >> >>>>>>>>>> allows for three signaling states: >> >>>>>>>>>>=20 >> >>>>>>>>>> * Actively support the change. >> >>>>>>>>>> * Actively oppose the change. >> >>>>>>>>>> * Not signaling (neither support or oppose). This is the defau= lt >> >>>>>>>>>> state. >> >>>>>>>>>>=20 >> >>>>>>>>>> Using this additional information, we can release non-contenti= ous >> >>>>>>>>>> upgrades much quicker (with a much lower percent of miners >> >>>>>>>>>> signaling support). For contentious upgrades, miners who oppos= e >> >>>>>>>>>> the change are incentivized to update their software to a vers= ion >> >>>>>>>>>> that can actively signal opposition to the change. The more >> >>>>>>>>>> opposition there is, the higher the threshold necessary to loc= k >> >>>>>>>>>> in the upgrade. With the parameters I currently recommended in= >> >>>>>>>>>> the proposal, this chart shows how much support signaling woul= d >> >>>>>>>>>> be necessary given a particular amount of active opposition >> >>>>>>>>>> signaling: >> >>>>>>>>>>=20 >> >>>>>>>>>> [image: thresholdChart.png] >> >>>>>>>>>> If literally no one signals opposition, a 60% threshold should= be >> >>>>>>>>>> relatively safe because it is a supermajority amount that is >> >>>>>>>>>> unlikely to change significantly very quickly (ie if 60% of >> >>>>>>>>>> miners support the change today, its unlikely that less than a= >> >>>>>>>>>> majority of miners would support the change a year or two from= >> >>>>>>>>>> now), and if no one is signaling opposition, chances are that t= he >> >>>>>>>>>> vast majority of the other 40% would also eventually signal >> >>>>>>>>>> support. >> >>>>>>>>>>=20 >> >>>>>>>>>> This both gives an incentive for "lazy" miners to upgrade if t= hey >> >>>>>>>>>> actually oppose the change while at the same time allowing the= se >> >>>>>>>>>> lazy miners to remain lazy without slowing down the soft fork >> >>>>>>>>>> activation much. >> >>>>>>>>>>=20 >> >>>>>>>>>> I think now is the right time to discuss new soft fork upgrade= >> >>>>>>>>>> mechanisms, when there are no pressing soft fork upgrades read= y >> >>>>>>>>>> to deploy. Waiting until we need to deploy a soft fork to disc= uss >> >>>>>>>>>> this will only delay things and cause contention again like it= >> >>>>>>>>>> did with taproot. >> >>>>>>>>>>=20 >> >>>>>>>>>> I'm very curious to know what people think of this mechanism. I= >> >>>>>>>>>> would appreciate any comments here, or written as github issue= s >> >>>>>>>>>> on the proposal repo itself. >> >>>>>>>>>>=20 >> >>>>>>>>>> Thanks, >> >>>>>>>>>> BT >> >>>>>>>>>=20 >> >>>>>>>>> _______________________________________________ >> >>>>>>>>> bitcoin-dev mailing list >> >>>>>>>>> bitcoin-dev@lists.linuxfoundation.org >> >>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >>>>>>>=20 >> >>>>>>> _______________________________________________ >> >>>>>>> bitcoin-dev mailing list >> >>>>>>> bitcoin-dev@lists.linuxfoundation.org >> >>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >=20 --Apple-Mail-D6009DD5-D7D5-4796-AAAE-1F5B82A74249 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

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

=EF=BB=BF
"Confirmation" isn't needed f= or softforks.

All transactions r= equire confirmation. Splitting does not change this.

Softforks are not compatible without miner enforcement. So soft forking wi= thout it has essentially the same effect as hard forking, the chain splits.<= /div>
Miners= controlling confirmation doesn't mean miners control the rules, they never d= id.

Please define =E2=80=9Ccontr= ol=E2=80=9D because these statements hinge on that word. Nobody =E2=80=9Ccon= trols=E2=80=9D the rules of others, nor did anyone claim that to be the case= . Majority hash power does have the ability to determine what gets confirmed= . That is the central design principle of proof of work. It takes that decis= ion out of the hands of politicians and places it at the feet of the market.=

Read s= ection 11 of the bitcoin paper "even with a majority of hashrate one cannot a= rbitrarily change rules or forge signatures.
Never claimed that was the case. One can run any rules that one= desires.

You may say users chosing the rules is "politicial". I= sn't miners deciding them for users more political?

No, it=E2=80=99s economic. The largest investment i= n mining (including highest fees paid to incentivize it) determines censorsh= ip resistance.

Whatever you call it, it is still how free software= works: users decide what to run.

A *person* can run whatever software they want. Money requires that o= thers agree (same rules), and to be money bitcoin requires confirmation.
It is extremely disappointing to see how few developers seem to ubder= stand this, or even care about users deciding or miners not deciding the rul= es.

It=E2=80=99s poorly un= derstood because there are so many who should know better making very mislea= ding statements.

How can we expect users to understand bitcoin w= hen most developers don't seem to understand it?

Clearly we cannot.

It is really sad.

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

Miners control confirmation, entirely.

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

Splitting does not change this.

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

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

> again leading to centralised miner control over the network.

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

> In other words, in this context, accepting a split between disagreeing u= sers
> is the ONLY way Bitcoin can possibly continue as a decentralised curren= cy.

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

> Making that split as clean and well-defined as possible not only ensure= s the
> best opportunity for both sides of the disagreement,

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

> but also minimises the
> risk that the split occurs at all (since the "losing" side needs to con= cede,
> rather than passively continue the disagreement ongoing after the attem= pted
> protocol change).

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

e

> Luke
>
>
>> On Tuesday 29 June 2021 08:44:56 Eric Voskuil wrote:
>> At least we are now acknowledging that splitting is what it=E2=80=99= s about. That=E2=80=99s
>> progress.
>>
>> e
>>
>>>> On Jun 29, 2021, at 01:32, Jorge Tim=C3=B3n <jtimon@jtim= on.cc> wrote:
>>>
>>> =EF=BB=BF
>>> I think the option of "permanent failure because miners veto" s= hould
>>> 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.tetru= d@gmail.com> wrote:
>>>> @Luke
>>>>
>>>>> They can still slow it down.
>>>>
>>>> Absolutely. However I think that the option of permanent fa= ilure is
>>>> important. It certainly would be ideal to ensure that enoug= h bitcoin
>>>> users support the upgrade *before* releasing it, however re= alistically
>>>> this can never be more than an estimate, and estimates can s= ometimes be
>>>> wildly wrong. It would be unfortunate if miners had a subst= antially
>>>> different estimate of user support than the people putting i= n the work
>>>> to release bitcoin upgrades. Even if upgrades are never rel= eased before
>>>> it becomes clear that a large supermajority of users want t= he upgrade,
>>>> if miners don't agree with the estimate a harmful chain spl= it could
>>>> occur. And I agree with Eric that the goal here is to preve= nt a chain
>>>> split during an upgrade when possible. This includes perman= ent failure
>>>> of an upgrade when there is unexpectedly large miner opposi= tion.
>>>>
>>>> This of course does not prevent a UASF-style deployment to b= e done after
>>>> an initial failure to deploy occurs. My proposal is essenti= ally a
>>>> mechanism to improve upon the speedy-trial idea, allowing f= or even
>>>> speedier releases (than speedy trial) without adding additi= onal risk of
>>>> undesired chain splits.
>>>>
>>>>> [BIP8] already has the trinary state you seem to be des= cribing
>>>>
>>>> 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 th= e
>>>> non-upgraded chain. I agree. However the trinary state in m= y proposal is
>>>> materially different - it is the signaling itself that is t= rinary, not
>>>> just which chain is being followed. This allows others to k= now and make
>>>> programmatic decisions (in software) based on that signalin= g. I'm sure
>>>> you can agree that does not exist in BIP8.
>>>>
>>>>> No additional bit is needed, as softforks are coordinat= ed between
>>>>> users, NOT miners
>>>>
>>>> And yet there is miner involvement, as you rightly pointed o= ut. Miners
>>>> are needed to set the nVersion in the header. So when you s= ay "no
>>>> additional bit is needed", could you please be clearer as t= o what you
>>>> mean? Do you mean that signaling of opposition in a block c= an be done
>>>> without any "additional bit"? Or are you just saying that i= t is
>>>> redundant to consider what miners might be opposing an upgr= ade?
>>>>
>>>> @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 p= ainful, but
>>>> there were a significant amount of users that disagreed, an= d they have
>>>> the chain they want now.
>>>>
>>>> But we generally all want to avoid a chain split when possi= ble. Because
>>>> chain splits have a cost, and that cost can be high, its li= kely that
>>>> many users would rather choose the chain with the most supp= ort rather
>>>> than choosing the chain with their preferred rules.
>>>>
>>>> However, the question here is: how do we estimate what frac= tion of users
>>>> wants which rules? We don't have a divining rod to determin= e with
>>>> certainty what users want. We can only make polls of variou= s levels of
>>>> inaccuracy. The methods bitcoin has been using is community= discussion
>>>> and social consensus estimation as well as miner signaling d= uring the
>>>> actual deployment period. Neither of these are perfect, but= they are
>>>> both reasonable enough mechanisms. However, because both of= these
>>>> mechanisms are very rough estimates of user sentiment, we n= eed to
>>>> consider the possibility that sometimes the estimate may be=
>>>> substantially inaccurate when we design deployment procedur= es. This
>>>> inaccuracy is why we need multiple barriers in place for an= upgrade, and
>>>> why we need to have higher thresholds of success (require l= arger
>>>> supermajorities in both consensus and miner signaling).
= >>>>
>>>> Developers obviously care about bitcoin and have an incenti= ve (personal
>>>> and probably financial) to do it right. And miners have bot= h an
>>>> incentive to keep the system healthy, as well as an incenti= ve to mine on
>>>> the chain that the economic majority of users is using. But= measuring
>>>> the consensus of the bitcoin community can be extraordinari= ly difficult
>>>> to do with consistent accuracy, and so I think miner signal= ing as it has
>>>> been used as a second barrier to entry for an upgrade is qu= ite
>>>> appropriate.
>>>>
>>>>> On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil <eric@vosk= uil.org> wrote:
>>>>> I have not objected to anyone splitting. As I said, a s= plit 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=9C= compatibility=E2=80=9D and the
>>>>> implication that activation without hash power enforcem= ent does not
>>>>> create 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 s= ome sort of
>>>>> activation choice with =E2=80=9Censured=E2=80=9D equal o= utcomes (maybe =E2=80=9Cslowed 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 i= ncompatible -
>>>>> 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 y= ou speak of.
>>>>> This idea that =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 c= are he can
>>>>> split at any time, no discussion required.
>>>>>
>>>>> e
>>>>>
>>>>>> On Jun 27, 2021, at 01:47, Jorge Tim=C3=B3n <jti= mon@jtimon.cc> wrote:
>>>>>>
>>>>>> =EF=BB=BFIf different users want different incompat= ible things (enough on
>>>>>> each side), there's no way to avoid the split. We s= houldn't try to
>>>>>> avoid such a split.
>>>>>> Users decide the rules, not miners nor developers.<= br> >>>>>>
>>>>>>> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil v= ia bitcoin-dev
>>>>>>> <bitcoin-dev@lists.linuxfo= undation.org> wrote:
>>>>>>>
>>>>>>> Ultimately there is only one answer to this que= stion. Get majority
>>>>>>> hash power support.
>>>>>>>
>>>>>>> Soft fork enforcement is the same act as any ot= her censorship
>>>>>>> enforcement, the difference is only a question o= f what people want.
>>>>>>> Given that there is no collective =E2=80=9Cwe=E2= =80=9D, those wants differ. Bitcoin
>>>>>>> resolves this question of conflicting wants, bu= t it is not a
>>>>>>> democracy, it=E2=80=99s a market. One votes by t= rading.
>>>>>>>
>>>>>>> If one wants to enforce a soft fork (or otherwi= se censor) this is
>>>>>>> accomplished by mining (or paying others to do s= o). Anyone can mine,
>>>>>>> so everyone gets a say. Mining is trading capit= al now for more
>>>>>>> later. If enough people want to do that, they c= an enforce a soft
>>>>>>> fork. It=E2=80=99s time Bitcoiners stop thinkin= g of miners as other people.
>>>>>>> Anyone can mine, and that=E2=80=99s your vote.<= br> >>>>>>>
>>>>>>> Otherwise, as mentioned below, anyone can start= a new coin. But it=E2=80=99s
>>>>>>> dishonest to imply that one can do this and all= others will surely
>>>>>>> follow. This cannot be known, it=E2=80=99s mere= ly 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=9Cb= lock=E2=80=9D.
>>>>>>>>
>>>>>>>> Without majority hash power support, activa= tion simply means you
>>>>>>>> are off on a chain split. Anyone can of cou= rse 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. Th= e relevant question is
>>>>>>>> how to *prevent* a split. And activation wi= thout majority hash
>>>>>>>> power certainly does not =E2=80=9Censure=E2= =80=9D this.
>>>>>>>>
>>>>>>>> e
>>>>>>>>
>>>>>>>>> On Jun 26, 2021, at 14:13, Luke Dashjr v= ia bitcoin-dev
>>>>>>>>> <bitcoin-dev@lists= .linuxfoundation.org> wrote:
>>>>>>>>>
>>>>>>>>> =EF=BB=BFBIP8 LOT=3DTrue just ensures m= iners cannot block an upgrade
>>>>>>>>> entirely. They can still slow it down.<= br> >>>>>>>>>
>>>>>>>>> It also already has the trinary state y= ou seem to be describing
>>>>>>>>> (although perhaps this could be better d= ocumented in the BIP):
>>>>>>>>> users who oppose the softfork can and s= hould treat the successful
>>>>>>>>> signal (whether MASF or UASF) as invali= d, thereby ensuring they do
>>>>>>>>> not follow a chain with the rules in fo= rce.
>>>>>>>>>
>>>>>>>>> No additional bit is needed, as softfor= ks are coordinated between
>>>>>>>>> users, NOT miners (who have no particul= ar say in them, aside from
>>>>>>>>> their role as also being users). The mi= ner involvement is only out
>>>>>>>>> of necessity (to set the bit in the hea= der, which users coordinate
>>>>>>>>> with) and potentially to accelerate act= ivation 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 u= pgrade mechanisms for the
>>>>>>>>>> non-controversial taproot upgrade, I= have been thinking about
>>>>>>>>>> ways to solve the problems that bot= h sides brought up. In short,
>>>>>>>>>> BIP8 LOT=3Dtrue proponents make the= point that lazy miners failing
>>>>>>>>>> to upgrade in a timely manner slow d= own releases of bitcoin
>>>>>>>>>> upgrades, and BIP9 / BIP8 LOT=3Dfal= se proponents make the point
>>>>>>>>>> that LOT=3Dtrue can lead to undesir= able 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-signalin= g/blo
>>>>>>>>>> b/master/b ip-trinary-version-bits.= md> for soft fork upgrades that
>>>>>>>>>> solve both problems.
>>>>>>>>>>
>>>>>>>>>> The proposal uses trinary version s= ignaling rather than binary
>>>>>>>>>> signaling. For any particular prosp= ective soft fork upgrade, this
>>>>>>>>>> allows for three signaling states:<= br> >>>>>>>>>>
>>>>>>>>>> * Actively support the change.
>>>>>>>>>> * Actively oppose the change.
>>>>>>>>>> * Not signaling (neither support or= oppose). This is the default
>>>>>>>>>> state.
>>>>>>>>>>
>>>>>>>>>> Using this additional information, w= e can release non-contentious
>>>>>>>>>> upgrades much quicker (with a much l= ower percent of miners
>>>>>>>>>> signaling support). For contentious= upgrades, miners who oppose
>>>>>>>>>> the change are incentivized to upda= te 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 m= uch support signaling would
>>>>>>>>>> be necessary given a particular amo= unt of active opposition
>>>>>>>>>> signaling:
>>>>>>>>>>
>>>>>>>>>> [image: thresholdChart.png]
>>>>>>>>>> If literally no one signals opposit= ion, a 60% threshold should be
>>>>>>>>>> relatively safe because it is a sup= ermajority amount that is
>>>>>>>>>> unlikely to change significantly ve= ry quickly (ie if 60% of
>>>>>>>>>> miners support the change today, it= s unlikely that less than a
>>>>>>>>>> majority of miners would support th= e change a year or two from
>>>>>>>>>> now), and if no one is signaling op= position, chances are that the
>>>>>>>>>> vast majority of the other 40% woul= d also eventually signal
>>>>>>>>>> support.
>>>>>>>>>>
>>>>>>>>>> This both gives an incentive for "l= azy" miners to upgrade if they
>>>>>>>>>> actually oppose the change while at= the same time allowing these
>>>>>>>>>> lazy miners to remain lazy without s= lowing down the soft fork
>>>>>>>>>> activation much.
>>>>>>>>>>
>>>>>>>>>> I think now is the right time to di= scuss new soft fork upgrade
>>>>>>>>>> mechanisms, when there are no press= ing soft fork upgrades ready
>>>>>>>>>> to deploy. Waiting until we need to= deploy a soft fork to discuss
>>>>>>>>>> this will only delay things and cau= se contention again like it
>>>>>>>>>> did with taproot.
>>>>>>>>>>
>>>>>>>>>> I'm very curious to know what peopl= e 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.lin= uxfoundation.org
>>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>>>>
>>>>>>> _______________________________________________=
>>>>>>> bitcoin-dev mailing list
>>>>>>> bitcoin-dev@lists.linuxfounda= tion.org
>>>>>>> = https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
= --Apple-Mail-D6009DD5-D7D5-4796-AAAE-1F5B82A74249--