Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 18C5CC000E for ; Wed, 30 Jun 2021 02:02:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id DB61883AAF for ; Wed, 30 Jun 2021 02:02:57 +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 bBoCELfWEmnL for ; Wed, 30 Jun 2021 02:02:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by smtp1.osuosl.org (Postfix) with ESMTPS id B1945827DE for ; Wed, 30 Jun 2021 02:02:54 +0000 (UTC) Received: by mail-ed1-x52c.google.com with SMTP id w17so868846edd.10 for ; Tue, 29 Jun 2021 19:02:54 -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=dCVmXOHuB6kYhRmONrQBRRy3ZP4QVtJLKL9UgLXb9yg=; b=KKfg+a/J1o9QFbzlRDAL9qTzGM8+snTpDgqE9s/Fb4SOfwut5ZALY4K1+MKo4/1aun fl25YrmraolZeKZvYWBl4ClcVxb5+O6gs1m8T42uo964okeBBq7/tsYM2Jj9diCeZMhd 9kIJ1H5gR7/uSWUGEr99iUJbbDXBz6BkRGELBpy480PEQdH38N7D1DE3HCf8NzxpLG8T J5GRh7Nr0o3BkAbHy1xqY+t8hRlNpYJEYYjfwg6YL0TxRTqgM1doAKRKefvhTz4yxylr aUuOJHz+rQCMsZoLjV5GwF8vsf9KcEwX11QxU/xXS8uU9DWWCnkZJHxHW38KLkOByrL4 M5Jg== 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=dCVmXOHuB6kYhRmONrQBRRy3ZP4QVtJLKL9UgLXb9yg=; b=k1rEyTneb3aewumIfx1bP/SQ+Z5uww2hMAUNhkOJO2+A/5ZrFeI161/eNvxJwhYPPO etCQtpuCSSuB4sV6yNOgFdFwMLkd45tYuhflHMPw/TaFXNO0A0zRvhmQn9uYmbpO4aCN gYyCz0p6GV75gHZXQfFqDhFJiLqv/1v4DWcThNrWMDZeh3bVdIMGVowZmXIfyg7o76e1 I+jLsFkp0Ib+OETnNa6s817RrRoWMA35eCSfbDJDWdCN9zXghtBOUdBD5rOzRBJ1kzeZ XtjTVY2Li147t9Duv9DBnAuIVLqeF63KmxLHWqg3vCKwhWwS1NJRtLIguPwo5ADJf091 RRXg== X-Gm-Message-State: AOAM53078/wavfzNqkjj8HWJMzF+YuO3A4yat6f25hvuXdvbHd2iyyap XYyzCaC8zf2dLkIll/QmT11Vtr2+3i59DjFGEFY= X-Google-Smtp-Source: ABdhPJz8huOYex5hyDyAOq93uqgf4f/PA6sDrOOJJ0S3S5+C3TpCglS0RdrMdyNMnc8aJe0YKMpEfBnlNKXyqhIP3WI= X-Received: by 2002:a05:6402:1111:: with SMTP id u17mr44057924edv.87.1625018572513; Tue, 29 Jun 2021 19:02:52 -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: Billy Tetrud Date: Tue, 29 Jun 2021 19:02:36 -0700 Message-ID: To: Eric Voskuil Content-Type: multipart/alternative; boundary="000000000000c4a4cc05c5f21e3e" X-Mailman-Approved-At: Wed, 30 Jun 2021 08:11:56 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2021 02:02:58 -0000 --000000000000c4a4cc05c5f21e3e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable @Jorge >I don't think we should avoid splits at all costs. I absolutely agree that we shouldn't avoid splits at all costs. There are some costs too high to pay to avoid a split. If an economic majority started wanting to increase bitcoin's blocksize to 1 GB next year, we should absolutely hard fork away from that mess with a minority chain. > I don't think we should avoid splits when possible, I want to see why exactly we disagree about avoiding chain splits "when possible". Are you really saying that we should just hard fork every time instead of soft fork? Should we even bother to get widespread buy in at all, or should we just release the software, hardfork away, and let anyone that wants to follow us follow us later? Are you not at all worried about the costs associated with an increased orphan rate and reorg rate? Are you not worried that an update might happen too fast and that a significant fraction of people that could have come along with us to the new update might be left behind because they didn't have time to evaluate the changed rules? Do you agree that, in a conversation about rule changes, some people want it their way no matter what and will hardfork to get the rules they want, and some people want it their way, but only if enough other people agree to follow those rules too? Some people might want a rule change, but aren't willing to follow, say, a 20% minority fork. Perhaps their personal cut-off is 40% or 50% or 75% or 90%. Do you agree those people exist? If you do, then I don't understand why you disagree that we should avoid chain splits even "when possible". Maybe you could elaborate as to what you mean there. @Luke Are you in agreement with Jorge here that we should not even attempt to avoid chain splits? > The only alternative to a split in the problematic scenarios are 1) concede centralised miner control over the network, and 2) have inconsistent enforcement of rules by users who don't agree on what the correct rules are, again leading to centralised miner control over the network. There is not simply a binary "do or do not". There is also timing. Non-contentious changes can happen fast. Contentious changes need more time for discussion, preparation, or coordination, even if the eventual outcome is the same. Do you disagree that timing issues can be important, that delays can be useful and help to avoid chain splits? Do you agree that miners have a (large) incentive to follow the economic majority? Is the goal here to do what the economic majority wants, or some other group? If so, do you think we have an accurate way of measuring what the economic majority wants? Will that mechanism continue to be accurate into the future? I'm asking these questions to try and figure out why we disagree here. On Tue, Jun 29, 2021 at 12:44 PM Eric Voskuil 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 >> > >> > --000000000000c4a4cc05c5f21e3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
@Jorge

>I don't think we sho= uld avoid splits at all costs.

I absolutely agree = that we shouldn't avoid splits at all costs. There are some costs too h= igh to pay to avoid a split. If an economic majority started wanting to inc= rease bitcoin's blocksize=C2=A0to 1 GB next year, we should absolutely = hard fork away from that mess with a minority chain.=C2=A0

>=C2=A0 I don't think we should avoid splits when possible,= =C2=A0

I want to see why exactly we disagree about= avoiding chain splits "when possible". Are you really saying tha= t we should just hard fork every time instead of soft fork? Should we even = bother to get widespread buy in at all, or should we just release the softw= are, hardfork away, and let anyone that wants to follow us follow us later?= Are you not at all worried about the costs associated with an increased or= phan rate and reorg rate? Are you not worried that an update might happen t= oo fast and that a significant fraction of people that could have come alon= g with us to the new update might be left behind because they didn't ha= ve time to evaluate the changed=C2=A0rules?

Do you= agree that, in a conversation about rule changes, some people want it thei= r way no matter what and will hardfork to get the rules they want, and some= people want it their way, but only if enough other people agree to follow = those rules too? Some people might want a rule change, but aren't willi= ng to follow, say, a 20% minority fork. Perhaps their personal cut-off is 4= 0% or 50% or 75% or 90%. Do you agree those people exist?=C2=A0

If you do, then I don't understand why you disagree t= hat we should avoid chain splits even "when possible". Maybe you = could elaborate as to what you mean there.=C2=A0

@= Luke

Are you in agreement with Jorge here that we = should not even attempt to avoid chain splits?=C2=A0

> The only alternative to a split in the problematic scenarios ar= e 1) concede centralised miner control over the network, and 2) have incons= istent enforcement of rules by users who don't agree on what the correc= t rules are, again leading to centralised miner control over the network.

There is not simply a binary "do or do no= t". There is also timing. Non-contentious changes can happen fast. Con= tentious changes need more time for discussion,=C2=A0preparation, or coordi= nation,=C2=A0even if the eventual outcome is the same. Do you disagree that= =C2=A0timing issues can be important,=C2=A0that=C2=A0delays can be useful a= nd help to avoid chain=C2=A0splits? Do you agree that miners have a (large)= incentive to follow the economic majority? Is the goal here to=C2=A0do wha= t the economic majority wants,=C2=A0or some other group? If so, do you thin= k we have an accurate way of measuring what the economic majority wants? Wi= ll that mechanism continue to be accurate into the future?=C2=A0

I'm asking these questions to try and figure out w= hy we disagree here.

On Tue, Jun 29, 2021 at 12:44 PM Eric Voskuil <= ;eric@voskuil.org> wrote:

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

<= /blockquote>
=EF=BB=BF
"Confirmation" isn't needed for softforks.
=

All transactions require confirmatio= n. Splitting does not change this.

Softforks are n= ot compatible without miner enforcement. So soft forking without it has ess= entially the same effect as hard forking, the chain splits.

Miners controlling c= onfirmation 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=9Ccontrol= s=E2=80=9D the rules of others, nor did anyone claim that to be the case. M= ajority hash power does have the ability to determine what gets confirmed. = That is the central design principle of proof of work. It takes that decisi= on 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 rul= es that one desires.

You may say users chosing the rules is &q= uot;politicial". Isn't miners deciding them for users more politic= al?

No, it=E2=80=99s econ= omic. The largest investment in mining (including highest fees paid to ince= ntivize it) determines censorship resistance.

Whatever you cal= l it, it is still how free software works: users decide what to run.
<= /div>

A *person* can run whatever sof= tware they want. Money requires that others agree (same rules), and to be m= oney bitcoin requires confirmation.

It is extremely disappoint= ing to see how few developers seem to ubderstand this, or even care about u= sers 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, 202= 1, 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
>
--000000000000c4a4cc05c5f21e3e--