From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9D828C000E for ; Tue, 29 Jun 2021 17:55:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 8C420403EE for ; Tue, 29 Jun 2021 17:55:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.401 X-Spam-Level: X-Spam-Status: No, score=-4.401 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=dashjr.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2m7_otfpib9r for ; Tue, 29 Jun 2021 17:55:16 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from zinan.dashjr.org (zinan.dashjr.org [IPv6:2001:470:88ff:2f::1]) by smtp2.osuosl.org (Postfix) with ESMTP id BE77C40100 for ; Tue, 29 Jun 2021 17:55:15 +0000 (UTC) Received: from ishibashi.lan (unknown [12.190.236.209]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 9878738A002A; Tue, 29 Jun 2021 17:55:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan; t=1624989313; bh=ZGtBQ2valVcNhlsVo0LknhHDkMjSArB+Bbel+dzUkHo=; h=From:To:Subject:Date:Cc:References:In-Reply-To; b=lAXWDOR99VJeFhAeUMXVc3xzAKPmVdKuL7pK5VYzS9+Pjsmc0fht1pdcC0KAxirtC y2uW8O9Q5FvZQvaGlk2Ur3sQ3zJmmt1lclwMfA4y+bD7tYFQ+xBa9S6E0C1aRXx/eR xPyJpW9QkqH0NaNfcAf245E3XP3464R9bVda2tQQ= From: Luke Dashjr To: Eric Voskuil Date: Tue, 29 Jun 2021 17:55:11 +0000 User-Agent: KMail/1.9.10 References: <4E02C43C-D5D9-489E-9D94-4BF2DCB92496@voskuil.org> In-Reply-To: <4E02C43C-D5D9-489E-9D94-4BF2DCB92496@voskuil.org> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <202106291755.11926.luke@dashjr.org> 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 17:55:17 -0000 The only alternative to a split in the problematic scenarios are 1) concede= =20 centralised miner control over the network, and 2) have inconsistent=20 enforcement of rules by users who don't agree on what the correct rules are= ,=20 again leading to centralised miner control over the network. In other words, in this context, accepting a split between disagreeing user= s=20 is the ONLY way Bitcoin can possibly continue as a decentralised currency.= =20 Making that split as clean and well-defined as possible not only ensures th= e=20 best opportunity for both sides of the disagreement, but also minimises the= =20 risk that the split occurs at all (since the "losing" side needs to concede= ,=20 rather than passively continue the disagreement ongoing after the attempted= =20 protocol change). 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 abo= ut. That=E2=80=99s > progress. > > e > > > On Jun 29, 2021, at 01:32, Jorge Tim=C3=B3n wrote: > > > > =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 wrot= e: > >> @Luke > >> > >> > They can still slow it down. > >> > >> Absolutely. However I think that the option of permanent failure is > >> important. It certainly would be ideal to ensure that enough bitcoin > >> users support the upgrade *before* releasing it, however realistically > >> this can never be more than an estimate, and estimates can sometimes be > >> wildly wrong. It would be unfortunate if miners had a substantially > >> different estimate of user support than the people putting in the work > >> to release bitcoin upgrades. Even if upgrades are never released before > >> it becomes clear that a large supermajority of users want the upgrade, > >> if miners don't agree with the estimate a harmful chain split could > >> occur. And I agree with Eric that the goal here is to prevent a chain > >> 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 aft= er > >> 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. > >> > >> > [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 you > >> mean? Do you mean that signaling of opposition in a block can be done > >> without any "additional bit"? Or are you just saying that it is > >> redundant to consider what miners might be opposing an upgrade? > >> > >> @Jorge > >> > >> > If different users want different incompatible things... there's no > >> > way to avoid the split > >> > >> I agree. This happened with bcash, and that's fine. It was painful, but > >> there were a significant amount of users that disagreed, and they have > >> 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 that > >> many users would rather choose the chain with the most support rather > >> than choosing the chain with their preferred rules. > >> > >> However, the question here is: how do we estimate what fraction of use= rs > >> 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 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 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, a= nd > >> 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 measuring > >> the consensus of the bitcoin community can be extraordinarily difficult > >> to do with consistent accuracy, and so I think miner signaling as it h= as > >> 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=9Ccompatibility= =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. > >>> > >>> 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 (mayb= e =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 of. > >>> This idea that =E2=80=9Cusers=E2=80=9D decide the rules is not the qu= estion. 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 wrot= e: > >>> > > >>> > =EF=BB=BFIf different users want different incompatible things (eno= ugh on > >>> > each side), there's no way to avoid the split. We shouldn't try to > >>> > avoid such a split. > >>> > Users decide the rules, not miners nor developers. > >>> > > >>> >> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev > >>> >> wrote: > >>> >> > >>> >> Ultimately there is only one answer to this question. Get majority > >>> >> hash power support. > >>> >> > >>> >> Soft fork enforcement is the same act as any other censorship > >>> >> enforcement, the difference is only a question of what people want. > >>> >> Given that there is no collective =E2=80=9Cwe=E2=80=9D, those want= s 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 is > >>> >> accomplished by mining (or paying others to do so). Anyone can min= e, > >>> >> 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 othe= r people. > >>> >> Anyone can mine, and that=E2=80=99s your vote. > >>> >> > >>> >> Otherwise, as mentioned below, anyone can start a new coin. But it= =E2=80=99s > >>> >> dishonest to imply that one can do this and all others will surely > >>> >> 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 you > >>> >>> are off on a chain split. Anyone can of course split off from a > >>> >>> chain by changing a rule (soft or otherwise) at any time, so this > >>> >>> is a bit of an empty claim. > >>> >>> > >>> >>> Nobody can stop a person from splitting. The relevant question is > >>> >>> 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 upg= rade > >>> >>>> 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 invalid, thereby ensuring they = do > >>> >>>> not follow a chain with the rules in force. > >>> >>>> > >>> >>>> No additional bit is needed, as softforks are coordinated between > >>> >>>> users, NOT miners (who have no particular say in them, aside from > >>> >>>> their role as also being users). The miner involvement is only o= ut > >>> >>>> of necessity (to set the bit in the header, which users coordina= te > >>> >>>> with) and potentially to accelerate activation by protecting > >>> >>>> upgrade-lagging users. > >>> >>>> > >>> >>>> Luke > >>> >>>> > >>> >>>>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev > >>> >>>>>> wrote: > >>> >>>>> > >>> >>>>> Given the recent controversy over upgrade mechanisms for the > >>> >>>>> non-controversial taproot upgrade, I have been thinking about > >>> >>>>> ways to solve the problems that both sides brought up. In short, > >>> >>>>> BIP8 LOT=3Dtrue proponents make the point that lazy miners fail= ing > >>> >>>>> to upgrade in a timely manner slow down releases of bitcoin > >>> >>>>> upgrades, and BIP9 / BIP8 LOT=3Dfalse proponents make the point > >>> >>>>> that LOT=3Dtrue can lead to undesirable forks that might cause a > >>> >>>>> lot of chaos. I believe both points are essentially correct and > >>> >>>>> have created a proposal > >>> >>>>> >>> >>>>>b/master/b ip-trinary-version-bits.md> for soft fork upgrades th= at > >>> >>>>> solve both problems. > >>> >>>>> > >>> >>>>> The proposal uses trinary version signaling rather than binary > >>> >>>>> signaling. For any particular prospective soft fork upgrade, th= is > >>> >>>>> 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-contentio= us > >>> >>>>> upgrades much quicker (with a much lower percent of miners > >>> >>>>> signaling support). For contentious upgrades, miners who oppose > >>> >>>>> the change are incentivized to update their software to a versi= on > >>> >>>>> that can actively signal opposition to the change. The more > >>> >>>>> opposition there is, the higher the threshold necessary to lock > >>> >>>>> in the upgrade. With the parameters I currently recommended in > >>> >>>>> the proposal, this chart shows how much support signaling would > >>> >>>>> be necessary given a particular amount of active opposition > >>> >>>>> signaling: > >>> >>>>> > >>> >>>>> [image: thresholdChart.png] > >>> >>>>> If literally no one signals opposition, a 60% threshold should = be > >>> >>>>> relatively safe because it is a supermajority amount that is > >>> >>>>> unlikely to change significantly very quickly (ie if 60% of > >>> >>>>> miners support the change today, its unlikely that less than a > >>> >>>>> majority of miners would support the change a year or two from > >>> >>>>> now), and if no one is signaling opposition, chances are that t= he > >>> >>>>> vast majority of the other 40% would also eventually signal > >>> >>>>> support. > >>> >>>>> > >>> >>>>> This both gives an incentive for "lazy" miners to upgrade if th= ey > >>> >>>>> 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 upgrade > >>> >>>>> mechanisms, when there are no pressing soft fork upgrades ready > >>> >>>>> to deploy. Waiting until we need to deploy a soft fork to discu= ss > >>> >>>>> this will only delay things and cause contention again like it > >>> >>>>> did with taproot. > >>> >>>>> > >>> >>>>> I'm very curious to know what people think of this mechanism. I > >>> >>>>> would appreciate any comments here, or written as github issues > >>> >>>>> on the proposal repo itself. > >>> >>>>> > >>> >>>>> Thanks, > >>> >>>>> BT > >>> >>>> > >>> >>>> _______________________________________________ > >>> >>>> bitcoin-dev mailing list > >>> >>>> bitcoin-dev@lists.linuxfoundation.org > >>> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >>> >> > >>> >> _______________________________________________ > >>> >> bitcoin-dev mailing list > >>> >> bitcoin-dev@lists.linuxfoundation.org > >>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev