From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id B19F1C000E for ; Wed, 30 Jun 2021 06:39:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 8180783AA5 for ; Wed, 30 Jun 2021 06:39:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 9Ah2mRY6pge1 for ; Wed, 30 Jun 2021 06:39:53 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) by smtp1.osuosl.org (Postfix) with ESMTPS id EB31C83934 for ; Wed, 30 Jun 2021 06:39:52 +0000 (UTC) Received: by mail-il1-x133.google.com with SMTP id a11so1884651ilf.2 for ; Tue, 29 Jun 2021 23:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J4eHvHsqhizKxK/pg+euUm3pACclCMM7oml4cV6+FLg=; b=lW7gJgYQ3nOFyN7W7fGeMY+CmqAaEi/NfGGJQ2rQwvMH0WEXmwk831odZpCSwUgchL aISVAlsp4jFZUkxdgayuq4K4xt2IL/uLmdv2mgKC+NO9Vkl2hx4i2hGIwV6mnfIX9d1+ xA7CDCAsOPBSCHwnHZj1fLFx14QRdN6gq+ZzhnTLAgFHbja9x2ieairyw8hRnZBvvDIm 9Pnn4HZohVjuqbJXOYm4yrDMHJ1yHSvGr+xfH14TZfK86iH2kcorZTUjAC9U8d7YlRIg //uUp0Cve+NYqBWKxtkYEl/3PGWRhnu/I8/+Ht/vU2rkKeuCm/1avVVPxu4VEfNYytIq 7DLA== 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=J4eHvHsqhizKxK/pg+euUm3pACclCMM7oml4cV6+FLg=; b=aKVX9rL4F9zum6d0RlLL1/+TspRGQx9CL1q1UnTEuBeUysbX7YFSN8vnDZHwqJFQsB FYp4FUig1XEPP0+2imTvr5SBR17K/kGxoiAIr+6m/jkC8ar2kOk/Xv7ambzyvRcPgq0j WjUK67TxeFkchMqC8hMSMKNxGsA8Ejgq6AAytn7KbEIYaCB33PgY08udoyJyqp4bsmGy T4xgRqkDuowZVtMJ7rgl9NwHPbCkMdKgSiS4iFbTmAwpAkGCIG9Ha6tkNMWbWJUJw9xN /HpQpfK4EjAcyR/ha0KpApEHNtF2FK6ojVLHGSy8W20xBVZI/OVqIZf/WZPumTL9D4KC yqAg== X-Gm-Message-State: AOAM532hJlYad0M8qsYHRcX/B66tYB0Gh9MPe9dnlfcaGvYqdL2CPSWN Nkql/KYTSpZ4b6bgYZdYOtNNtAu6ZzQW1crsPTY2uoNk X-Google-Smtp-Source: ABdhPJzEwTwb5G3i3YxA6kz1p+w2sVwb4jQ17kBUQOgIio5LDHvFrrAimkGEruDLw20OplwXpd+Z4D1sfvcveJ1G6wM= X-Received: by 2002:a05:6e02:156a:: with SMTP id k10mr25131421ilu.111.1625035191951; Tue, 29 Jun 2021 23:39:51 -0700 (PDT) MIME-Version: 1.0 References: <2368396E-6964-4F12-B50F-2BE477D0C7D8@voskuil.org> In-Reply-To: <2368396E-6964-4F12-B50F-2BE477D0C7D8@voskuil.org> From: Zac Greenwood Date: Wed, 30 Jun 2021 08:39:41 +0200 Message-ID: To: Bitcoin Protocol Discussion , Eric Voskuil Content-Type: multipart/alternative; boundary="0000000000005d25ae05c5f5fdc3" X-Mailman-Approved-At: Wed, 30 Jun 2021 08:11:56 +0000 Cc: 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: Wed, 30 Jun 2021 06:39:55 -0000 --0000000000005d25ae05c5f5fdc3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Majority hash power does have the ability to determine what gets confirmed. Miners don=E2=80=99t have the ability to decide whether a block is valid. Hash power is only recognized as such if it is used for creating a valid block, i.e., a block that strictly follows all the rules as set by the node software that transacting users choose to run. If suddenly 70% of all hash power decided to start mining blocks that are invalid according to the rules set in the users=E2=80=99 software, then the= se invalid blocks will be disregarded. From a user perspective, 70% of all hash power will seem to have disappeared. In short, users define what is Bitcoin, not miners. This is fundamental to being decentralized. On Tue, 29 Jun 2021 at 23:17, Eric Voskuil via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Jun 29, 2021, at 12:28, Jorge Tim=C3=B3n wrote: > > =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 > without it has essentially the same effect as hard forking, the chain > splits. > > Miners controlling confirmation doesn't mean miners control the rules, > they never did. > > > Please define =E2=80=9Ccontrol=E2=80=9D because these statements hinge on= that word. > Nobody =E2=80=9Ccontrols=E2=80=9D the rules of others, nor did anyone cla= im 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 take= s > that decision out of the hands of politicians and places it at the feet o= f > the market. > > Read section 11 of the bitcoin paper "even with a majority of hashrate on= e > 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 decidin= g > them for users more political? > > > No, it=E2=80=99s economic. The largest investment in mining (including hi= ghest > fees paid to incentivize it) determines censorship 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 other= s > agree (same rules), and to be money bitcoin requires confirmation. > > It is extremely disappointing to see how few developers seem to ubderstan= d > 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 = better > making very misleading statements. > > How can we expect users to understand bitcoin when most developers don't > seem to understand it? > > > Clearly we cannot. > > It is really sad. > > On Tue, Jun 29, 2021, 19:17 Eric Voskuil wrote: > >> >> > On Jun 29, 2021, at 10:55, Luke Dashjr wrote: >> > >> > =EF=BB=BFThe only alternative to a split in the problematic scenarios = are 1) >> concede >> > centralised miner control over the network, >> >> Miners control confirmation, entirely. >> >> 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 likel= y a handful of >> exchanges, 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 rule= s >> are, >> >> There are no =E2=80=9Ccorrect=E2=80=9D rules. Whatever rules one enforce= s determine 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 >> users >> > is the ONLY way Bitcoin can possibly continue as a decentralised >> currency. >> >> No, it is not. You are proposing splitting as the method of censorship >> resistance inherent to Bitcoin. Coordinating this split requires >> coordinated action. 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 to political money. >> >> > Making that split as clean and well-defined as possible not only >> ensures the >> > best opportunity for both sides of the disagreement, >> >> Trivially accomplished, just change a rule. This isn=E2=80=99t about tha= t. It=E2=80=99s >> about how one gets others to go along with the new coin, or stay with th= e >> old. An entirely political process, which is clearly evident from the >> campaigns around such attempts. >> >> > but also minimises the >> > risk that the split occurs at all (since the "losing" side needs to >> concede, >> > rather than passively continue the disagreement ongoing after the >> attempted >> > protocol change). >> >> Nobody =E2=80=9Cneeds to=E2=80=9D concede once a split has occurred, whi= ch is 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=99s= about. >> That=E2=80=99s >> >> progress. >> >> >> >> e >> >> >> >>>> On Jun 29, 2021, at 01:32, Jorge Tim=C3=B3n wrot= e: >> >>> >> >>> =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. >> >>> >> >>>> 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 bitcoi= n >> >>>> users support the upgrade *before* releasing it, however >> realistically >> >>>> this can never be more than an estimate, and estimates can sometime= s >> 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 with Eric that the goal here is to prevent a cha= in >> >>>> split during an upgrade when 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 >> >>>> mechanism to improve upon the speedy-trial idea, allowing for even >> >>>> speedier releases (than speedy trial) without adding additional ris= k >> 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 >> >>>> 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 y= ou >> >>>> mean? Do you mean that signaling of opposition in a block can be do= ne >> >>>> 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 n= o >> >>>>> 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 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 tha= t >> >>>> many users would rather choose the chain with the most support rath= er >> >>>> 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 >> >>>> certainty 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 t= he >> >>>> actual deployment period. Neither of these are perfect, but they ar= e >> >>>> 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). >> >>>> >> >>>> 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 measuri= ng >> >>>> the consensus of the bitcoin community can be extraordinarily >> difficult >> >>>> to do with consistent accuracy, and so I think miner signaling as i= t >> has >> >>>> been used as 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=9Ccompatibil= ity=E2=80=9D and >> the >> >>>>> implication that activation without hash power enforcement does no= t >> >>>>> 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 some sort of >> >>>>> activation choice with =E2=80=9Censured=E2=80=9D equal outcomes (m= aybe =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. >> >>>>> >> >>>>> The statements below are grossly misleading and need to be called >> out >> >>>>> as such so that people can actually make this decision you speak o= f. >> >>>>> 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 care he can >> >>>>> split at any time, no discussion required. >> >>>>> >> >>>>> e >> >>>>> >> >>>>>> On Jun 27, 2021, at 01:47, Jorge Tim=C3=B3n wr= ote: >> >>>>>> >> >>>>>> =EF=BB=BFIf different users want different incompatible things (e= nough on >> >>>>>> each side), there's no way to avoid the split. We shouldn't try t= o >> >>>>>> 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 majori= ty >> >>>>>>> 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. >> >>>>>>> Given that there is no collective =E2=80=9Cwe=E2=80=9D, those wa= nts differ. >> Bitcoin >> >>>>>>> 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 i= s >> >>>>>>> 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=99s time Bitcoiners stop thinking of miners as ot= her >> 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 >> 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 changing a rule (soft or otherwise) at any time, so th= is >> >>>>>>>> is a bit of an empty claim. >> >>>>>>>> >> >>>>>>>> Nobody can stop a person from splitting. The relevant question = is >> >>>>>>>> how to *prevent* a split. And activation without majority hash >> >>>>>>>> power certainly does not =E2=80=9Censure=E2=80=9D this. >> >>>>>>>> >> >>>>>>>> e >> >>>>>>>> >> >>>>>>>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev >> >>>>>>>>> wrote: >> >>>>>>>>> >> >>>>>>>>> =EF=BB=BFBIP8 LOT=3DTrue just ensures miners cannot block an u= pgrade >> >>>>>>>>> entirely. They can still slow it down. >> >>>>>>>>> >> >>>>>>>>> It also already has the trinary state you seem to be describin= g >> >>>>>>>>> (although perhaps this could be better documented in the BIP): >> >>>>>>>>> users who oppose the softfork can and should treat the >> successful >> >>>>>>>>> signal (whether MASF or UASF) as invalid, thereby ensuring the= y >> 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 as also being users). The miner involvement is only >> out >> >>>>>>>>> of necessity (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 bitcoin-d= ev >> >>>>>>>>>>> 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 poi= nt >> >>>>>>>>>> that LOT=3Dtrue can lead to undesirable forks that might caus= e a >> >>>>>>>>>> lot of chaos. I believe both points are essentially correct a= nd >> >>>>>>>>>> have created a proposal >> >>>>>>>>>> < >> https://github.com/fresheneesz/bip-trinary-version-signaling/blo >> >>>>>>>>>> b/master/b ip-trinary-version-bits.md> for soft fork upgrades >> that >> >>>>>>>>>> solve both problems. >> >>>>>>>>>> >> >>>>>>>>>> The proposal uses trinary version signaling rather than binar= y >> >>>>>>>>>> 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 oppo= se >> >>>>>>>>>> the change are incentivized 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 lo= ck >> >>>>>>>>>> in the upgrade. With the parameters I currently recommended i= n >> >>>>>>>>>> the proposal, this chart shows how much support signaling wou= ld >> >>>>>>>>>> be necessary given a particular amount of active opposition >> >>>>>>>>>> signaling: >> >>>>>>>>>> >> >>>>>>>>>> [image: thresholdChart.png] >> >>>>>>>>>> If literally no one signals opposition, a 60% threshold shoul= d >> 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 fro= m >> >>>>>>>>>> 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 miners to remain lazy without slowing down the soft fork >> >>>>>>>>>> activation much. >> >>>>>>>>>> >> >>>>>>>>>> I think now is the right time to discuss new soft fork upgrad= e >> >>>>>>>>>> mechanisms, when there are no pressing soft fork upgrades rea= dy >> >>>>>>>>>> to deploy. Waiting until we need to deploy a soft fork to >> discuss >> >>>>>>>>>> this will only delay things and cause contention again like i= t >> >>>>>>>>>> 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 issu= es >> >>>>>>>>>> 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 >> > >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000005d25ae05c5f5fdc3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0Majority hash = power does have the ability to determine what gets confirmed.
<= div dir=3D"auto">
Miners don=E2=80=99t have the ab= ility to decide whether a block is valid.

Has= h power is only recognized as such if it is used for creating a valid block= , i.e., a block that strictly follows all the rules as set by the node soft= ware that transacting users choose to run.

If sudden= ly 70% of all hash power decided to start mining blocks that are invalid ac= cording to the rules set in the users=E2=80=99 software, then these invalid= blocks will be disregarded. From a user perspective, 70% of all hash power= will seem to have disappeared.

In short, users defi= ne what is Bitcoin, not miners. This is fundamental to being decentralized.=

=

<= div>
On= Tue, 29 Jun 2021 at 23:17, Eric Voskuil via bitcoin-dev <bitcoin-dev@lists.linuxfoundatio= n.org> wrote:

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

=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 without it has essent= ially the same effect as hard forking, the chain splits.

Miners controlling conf= irmation doesn't mean miners control the rules, they never did.

Please define =E2=80=9Ccontrol=E2=80= =9D because these statements hinge on that word. Nobody =E2=80=9Ccontrols= =E2=80=9D the rules of others, nor did anyone claim that to be the case. Ma= jority hash power does have the ability to determine what gets confirmed. T= hat is the central design principle of proof of work. It takes that decisio= n out of the hands of politicians and places it at the feet of the market.<= /div>
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 rule= s that one desires.

You may say users chosing the rules is &qu= ot;politicial". Isn't miners deciding them for users more politica= l?

No, it=E2=80=99s econo= mic. The largest investment in mining (including highest fees paid to incen= tivize it) determines censorship resistance.

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

A *person* can run whatever soft= ware they want. Money requires that others agree (same rules), and to be mo= ney bitcoin requires confirmation.

It is extremely disappointi= ng to see how few developers seem to ubderstand this, or even care about us= ers deciding or miners not deciding the rules.

It=E2=80=99s poorly understood because there are so m= any who should know better making very misleading statements.

= How can we expect users to understand bitcoin when 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 = are 1) concede
> centralised miner control over the network,

Miners control confirmation, entirely.

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 exc= hanges, 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 d= etermine 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 centralize= d, just as with merchanting, is up to individuals.

> In other words, in this context, accepting a split between disagreeing= users
> is the ONLY way Bitcoin can possibly continue as a decentralised curre= ncy.

No, it is not. You are proposing splitting as the method of censorship resi= stance inherent to Bitcoin. Coordinating this split requires coordinated ac= tion. The whole point of bitcoin is coordinate that action based on mining = (proof of work). Replacing that with a political process is just a reversio= n to political money.

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

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 st= ay with the old. An entirely political process, which is clearly evident fr= om the campaigns around such attempts.

> but also minimises the
> risk that the split occurs at all (since the "losing" side n= eeds to concede,
> rather than passively continue the disagreement ongoing after the atte= mpted
> protocol change).

Nobody =E2=80=9Cneeds to=E2=80=9D concede once a split has occurred, which = is 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= =99s about. That=E2=80=99s
>> progress.
>>
>> e
>>
>>>> On Jun 29, 2021, at 01:32, Jorge Tim=C3=B3n <jtimon@jti= mon.cc> wrote:
>>>
>>> =EF=BB=BF
>>> I think the option of "permanent failure because miners v= eto" should
>>> actually be abandoned. No, I don't think we should avoid s= plits when
>>> possible, I don't think we should avoid splits at all cost= s.
>>>
>>>> On Sun, Jun 27, 2021, 19:12 Billy Tetrud <billy.tet= rud@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 enou= gh bitcoin
>>>> users support the upgrade *before* releasing it, however r= ealistically
>>>> this can never be more than an estimate, and estimates can= sometimes be
>>>> wildly wrong. It would be unfortunate if miners had a subs= tantially
>>>> different estimate of user support than the people putting= in the work
>>>> to release bitcoin upgrades. Even if upgrades are never re= leased before
>>>> it becomes clear that a large supermajority of users want = the upgrade,
>>>> if miners don't agree with the estimate a harmful chai= n split could
>>>> occur. And I agree with Eric that the goal here is to prev= ent a chain
>>>> split during an upgrade when possible. This includes perma= nent failure
>>>> of an upgrade when there is unexpectedly large miner oppos= ition.
>>>>
>>>> This of course does not prevent a UASF-style deployment to= be done after
>>>> an initial failure to deploy occurs. My proposal is essent= ially a
>>>> mechanism to improve upon the speedy-trial idea, allowing = for even
>>>> speedier releases (than speedy trial) without adding addit= ional risk of
>>>> undesired chain splits.
>>>>
>>>>> [BIP8] already has the trinary state you seem to be de= scribing
>>>>
>>>> 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 t= he
>>>> 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 signali= ng. I'm sure
>>>> you can agree that does not exist in BIP8.
>>>>
>>>>> No additional bit is needed, as softforks are coordina= ted between
>>>>> users, NOT miners
>>>>
>>>> And yet there is miner involvement, as you rightly pointed= out. Miners
>>>> are needed to set the nVersion in the header. So when you = say "no
>>>> additional bit is needed", could you please be cleare= r 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 sa= ying that it is
>>>> redundant to consider what miners might be opposing an upg= rade?
>>>>
>>>> @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, a= nd they have
>>>> the chain they want now.
>>>>
>>>> But we generally all want to avoid a chain split when poss= ible. Because
>>>> chain splits have a cost, and that cost can be high, its l= ikely that
>>>> many users would rather choose the chain with the most sup= port rather
>>>> than choosing the chain with their preferred rules.
>>>>
>>>> However, the question here is: how do we estimate what fra= ction 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 vario= us levels of
>>>> inaccuracy. The methods bitcoin has been using is communit= y discussion
>>>> and social consensus estimation as well as miner signaling= during the
>>>> actual deployment period. Neither of these are perfect, bu= t they are
>>>> both reasonable enough mechanisms. However, because both o= f these
>>>> mechanisms are very rough estimates of user sentiment, we = need to
>>>> consider the possibility that sometimes the estimate may b= e
>>>> substantially inaccurate when we design deployment procedu= res. This
>>>> inaccuracy is why we need multiple barriers in place for a= n upgrade, and
>>>> why we need to have higher thresholds of success (require = larger
>>>> supermajorities in both consensus and miner signaling). >>>>
>>>> Developers obviously care about bitcoin and have an incent= ive (personal
>>>> and probably financial) to do it right. And miners have bo= th an
>>>> incentive to keep the system healthy, as well as an incent= ive to mine on
>>>> the chain that the economic majority of users is using. Bu= t measuring
>>>> the consensus of the bitcoin community can be extraordinar= ily difficult
>>>> to do with consistent accuracy, and so I think miner signa= ling as it has
>>>> been used as a second barrier to entry for an upgrade is q= uite
>>>> appropriate.
>>>>
>>>>> On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil <eric@vo= skuil.org> wrote:
>>>>> I have not objected to anyone splitting. As I said, a = split is always
>>>>> possible, and of course has been done on a large scale= . It is only the
>>>>> misleading statements about inherent soft fork =E2=80= =9Ccompatibility=E2=80=9D and the
>>>>> implication that activation without hash power enforce= ment does not
>>>>> create a split that I object to. People who know bette= r 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 ha= sh power
>>>>> enforcement. Soft forks are rule changes, and thereby = incompatible -
>>>>> unless enforced by majority hash power.
>>>>>
>>>>> The statements below are grossly misleading and need t= o 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 rule= s 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 <jt= imon@jtimon.cc> wrote:
>>>>>>
>>>>>> =EF=BB=BFIf different users want different incompa= tible 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.linux= foundation.org> wrote:
>>>>>>>
>>>>>>> Ultimately there is only one answer to this qu= estion. Get majority
>>>>>>> hash power support.
>>>>>>>
>>>>>>> Soft fork enforcement is the same act as any o= ther censorship
>>>>>>> enforcement, 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
>>>>>>> resolves this question of conflicting wants, b= ut it is not a
>>>>>>> democracy, it=E2=80=99s a market. One votes by= trading.
>>>>>>>
>>>>>>> If one wants to enforce a soft fork (or otherw= ise censor) this is
>>>>>>> accomplished by mining (or paying others to do= so). Anyone can mine,
>>>>>>> so everyone gets a say. Mining is trading capi= tal now for more
>>>>>>> later. If enough people want to do that, they = can enforce a soft
>>>>>>> fork. It=E2=80=99s time Bitcoiners stop thinki= ng of miners as other people.
>>>>>>> Anyone can mine, and that=E2=80=99s your vote.=
>>>>>>>
>>>>>>> Otherwise, as mentioned below, anyone can star= t a new coin. But it=E2=80=99s
>>>>>>> dishonest to imply that one can do this and al= l others will surely
>>>>>>> follow. This cannot be known, it=E2=80=99s mer= ely 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 Voskui= l <eric@voskuil.org> wrote:
>>>>>>>>
>>>>>>>> =EF=BB=BFFor some definitions of =E2=80=9C= block=E2=80=9D.
>>>>>>>>
>>>>>>>> Without majority hash power support, activ= ation simply means you
>>>>>>>> are off on a chain split. Anyone can of co= urse split off from a
>>>>>>>> chain by changing a rule (soft or otherwis= e) at any time, so this
>>>>>>>> is a bit of an empty claim.
>>>>>>>>
>>>>>>>> Nobody can stop a person from splitting. T= he relevant question is
>>>>>>>> how to *prevent* a split. And activation w= ithout majority hash
>>>>>>>> power certainly does not =E2=80=9Censure= =E2=80=9D this.
>>>>>>>>
>>>>>>>> e
>>>>>>>>
>>>>>>>>> On Jun 26, 2021, at 14:13, Luke Dashjr= via bitcoin-dev
>>>>>>>>> <bitcoin-dev@lis= ts.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 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 or UASF) as inval= id, thereby ensuring they do
>>>>>>>>> not follow a chain with the rules in f= orce.
>>>>>>>>>
>>>>>>>>> No additional bit is needed, as softfo= rks are coordinated between
>>>>>>>>> users, NOT miners (who have no particu= lar say in them, aside from
>>>>>>>>> their role as also being users). The m= iner involvement is only out
>>>>>>>>> of necessity (to set the bit in the he= ader, which users coordinate
>>>>>>>>> with) and potentially to accelerate ac= tivation 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 bo= th sides brought up. In short,
>>>>>>>>>> BIP8 LOT=3Dtrue proponents make th= e point that lazy miners failing
>>>>>>>>>> to upgrade in a timely manner slow= down releases of bitcoin
>>>>>>>>>> upgrades, and BIP9 / BIP8 LOT=3Dfa= lse proponents make the point
>>>>>>>>>> that LOT=3Dtrue can lead to undesi= rable forks that might cause a
>>>>>>>>>> lot of chaos. I believe both point= s are essentially correct and
>>>>>>>>>> have created a proposal
>>>>>>>>>> <https://github.com/fresheneesz/bip-trinary-version-sign= aling/blo
>>>>>>>>>> b/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 pros= pective soft fork upgrade, this
>>>>>>>>>> allows for three signaling states:=
>>>>>>>>>>
>>>>>>>>>> * Actively support the change.
>>>>>>>>>> * Actively oppose the change.
>>>>>>>>>> * Not signaling (neither support o= r 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 contentiou= s upgrades, miners who oppose
>>>>>>>>>> the change are incentivized to upd= ate their software to a version
>>>>>>>>>> that can actively signal oppositio= n to the change. The more
>>>>>>>>>> opposition there is, the higher th= e threshold necessary to lock
>>>>>>>>>> in the upgrade. With the parameter= s I currently recommended in
>>>>>>>>>> the proposal, this chart shows how= much support signaling would
>>>>>>>>>> be necessary given a particular am= ount of active opposition
>>>>>>>>>> signaling:
>>>>>>>>>>
>>>>>>>>>> [image: thresholdChart.png]
>>>>>>>>>> If literally no one signals opposi= tion, a 60% threshold should be
>>>>>>>>>> relatively safe because it is a su= permajority amount that is
>>>>>>>>>> unlikely to change significantly v= ery quickly (ie if 60% of
>>>>>>>>>> miners support the change today, i= ts unlikely that less than a
>>>>>>>>>> majority of miners would support t= he change a year or two from
>>>>>>>>>> now), and if no one is signaling o= pposition, chances are that the
>>>>>>>>>> vast majority of the other 40% wou= ld also eventually signal
>>>>>>>>>> support.
>>>>>>>>>>
>>>>>>>>>> This both gives an incentive for &= quot;lazy" miners to upgrade if they
>>>>>>>>>> actually oppose the change while a= t the same time allowing these
>>>>>>>>>> lazy miners to remain lazy without= slowing down the soft fork
>>>>>>>>>> activation much.
>>>>>>>>>>
>>>>>>>>>> I think now is the right time to d= iscuss new soft fork upgrade
>>>>>>>>>> mechanisms, when there are no pres= sing soft fork upgrades ready
>>>>>>>>>> to deploy. Waiting until we need t= o deploy a soft fork to discuss
>>>>>>>>>> this will only delay things and ca= use 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.l= inuxfoundation.org
>>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /a>
>>>>>>>
>>>>>>> ______________________________________________= _
>>>>>>> bitcoin-dev mailing list
>>>>>>> bitcoin-dev@lists.linuxfoun= dation.org
>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
_______________________________________________ bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000005d25ae05c5f5fdc3--