Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 48B77C000E for ; Tue, 29 Jun 2021 18:17:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 3768E8198A for ; Tue, 29 Jun 2021 18:17:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=voskuil-org.20150623.gappssmtp.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKg56pMAGPT6 for ; Tue, 29 Jun 2021 18:17:25 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) by smtp1.osuosl.org (Postfix) with ESMTPS id B296D839DD for ; Tue, 29 Jun 2021 18:17:25 +0000 (UTC) Received: by mail-pg1-x532.google.com with SMTP id w15so14736309pgk.13 for ; Tue, 29 Jun 2021 11:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=lGvhykyUF7p5DdQWiFmadIqicSI38uArso3lO2jxCOk=; b=piYYYf9vNn5hJGguX7tAU3Nny4Tk+wZzHUBBa77bnk+Do363FEFBxMRvaM6jtS7TdQ fRYC2mIsXV14NW7bQVXcKoMfpDLmjXltzcr96JjGeBHqnBl0IR1QjW0oXMJZioz/DooH jkWccS15md4TqWXANVQRWtqUVm46HOkoWEXi2OI1DG2o73mohk6OfL3MRdXxTnXssbE5 WiWPsjmpbtojvTETXVS7WXkKExU3XrNRmUMCIWUmf22frZ8XjY4fVwd6xZo4BQuGNHEd yWraQjGlSyD4HAvAU7rfic1t0V65PXodCqK+hlH44NDYSSuma66M37s3vCYzEPvQiD3+ 4cAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=lGvhykyUF7p5DdQWiFmadIqicSI38uArso3lO2jxCOk=; b=tplHG+4vrLMaKJ5ckkdWhlhwlQbzcx8/aAHKNmlLOBwRMk6RZSzFg0HUFlVX93GzSn 7HfvJAxjk8kwXRIpC17oiInqQw9nukN7dRVZ6A1FfNPvUJkBumBOeGLPxC++lIr/YHCg KJ/tqzk2BLqkBAMs3Q0n13XAJQnQRWN7TECsU/MOLIJl4XLhHALCuhuCOR19igXWGBt6 VKcblD2Peu+Gd4csp/pCaF9M7Sr/YeVtPUqlpSVMdOLLj4CiDAnjNq7LJj2nHMVZhksl JtNwHPr2PvqyCFWgwjfs40kkUmicgiuf+H9PuaWQXCf2S8xJYTwdlYKIeMeaZF+i4xXF vMjA== X-Gm-Message-State: AOAM533FQRgkZQhJ8V1+4/HeHhXaLa8qaVSx7WG7ReqE0Xg8L4kCDp/v oN4kmBNoThX4PRqYB6gCEFUNwNJKNcOSKQ== X-Google-Smtp-Source: ABdhPJyk14GklaA5OqmB9GsgRhodUvCxwOgEiQztW4foGJcYTqf03Tdt6wlZAUR9oErnbm1ZF6Wr5Q== X-Received: by 2002:a05:6a00:2395:b029:304:7a51:6f1d with SMTP id f21-20020a056a002395b02903047a516f1dmr31908873pfc.53.1624990644687; Tue, 29 Jun 2021 11:17:24 -0700 (PDT) Received: from smtpclient.apple ([2600:380:4548:79bc:4d8e:5eef:f49e:8219]) by smtp.gmail.com with ESMTPSA id w21sm5126506pge.30.2021.06.29.11.17.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Jun 2021 11:17:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Eric Voskuil Mime-Version: 1.0 (1.0) Date: Tue, 29 Jun 2021 11:17:22 -0700 Message-Id: References: <202106291755.11926.luke@dashjr.org> In-Reply-To: <202106291755.11926.luke@dashjr.org> To: Luke Dashjr X-Mailer: iPhone Mail (18F72) Cc: Bitcoin Protocol Discussion , Billy Tetrud Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 18:17:27 -0000 > On Jun 29, 2021, at 10:55, Luke Dashjr wrote: >=20 > =EF=BB=BFThe only alternative to a split in the problematic scenarios are 1= ) concede=20 > centralised miner control over the network, Miners control confirmation, entirely. This is the nature of bitcoin. And merchants control validation, entirely. A= nyone can be a miner or a merchant. Neither is inherently =E2=80=9Cbetter=E2= =80=9D than the other. The largest merchants are likely a handful of exchang= es, likely at least as centralized as miners are pooled. Splitting does not change this. > and 2) have inconsistent=20 > enforcement of rules by users who don't agree on what the correct rules ar= e,=20 There are no =E2=80=9Ccorrect=E2=80=9D rules. Whatever rules one enforces de= termine what network he chooses to participate in. > again leading to centralised miner control over the network. Leading to? Miners control confirmation, always. Whether that is centralized= , just as with merchanting, is up to individuals. > In other words, in this context, accepting a split between disagreeing use= rs=20 > 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 resis= tance inherent to Bitcoin. Coordinating this split requires coordinated acti= on. The whole point of bitcoin is coordinate that action based on mining (pr= oof of work). Replacing that with a political process is just a reversion to= political money. > Making that split as clean and well-defined as possible not only ensures t= he=20 > best opportunity for both sides of the disagreement, Trivially accomplished, just change a rule. This isn=E2=80=99t about that. I= t=E2=80=99s about how one gets others to go along with the new coin, or stay= with the old. An entirely political process, which is clearly evident from t= he campaigns around such attempts. > but also minimises the=20 > risk that the split occurs at all (since the "losing" side needs to conced= e,=20 > rather than passively continue the disagreement ongoing after the attempte= d=20 > protocol change). Nobody =E2=80=9Cneeds to=E2=80=9D concede once a split has occurred, which i= s evident in existing splits. e > Luke >=20 >=20 >> On Tuesday 29 June 2021 08:44:56 Eric Voskuil wrote: >> At least we are now acknowledging that splitting is what it=E2=80=99s abo= ut. That=E2=80=99s >> progress. >>=20 >> e >>=20 >>>> On Jun 29, 2021, at 01:32, Jorge Tim=C3=B3n wrote: >>>=20 >>> =EF=BB=BF >>> I think the option of "permanent failure because miners veto" should >>> actually be abandoned. No, I don't think we should avoid splits when >>> possible, I don't think we should avoid splits at all costs. >>>=20 >>>> On Sun, Jun 27, 2021, 19:12 Billy Tetrud wrote= : >>>> @Luke >>>>=20 >>>>> They can still slow it down. >>>>=20 >>>> Absolutely. However I think that the option of permanent failure is >>>> important. It certainly would be ideal to ensure that enough bitcoin >>>> users support the upgrade *before* releasing it, however 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. >>>>=20 >>>> This of course does not prevent a UASF-style deployment to be done afte= r >>>> an initial failure to deploy occurs. My proposal is essentially a >>>> mechanism to improve upon the speedy-trial idea, allowing for even >>>> speedier releases (than speedy trial) without adding additional risk of= >>>> undesired chain splits. >>>>=20 >>>>> [BIP8] already has the trinary state you seem to be describing >>>>=20 >>>> It sounds like you're saying the trinary state of BIP8 is A. Follow the= >>>> longest chain, B. Follow the upgrade chain, or C. follow the >>>> non-upgraded chain. I agree. However the trinary state in my proposal i= s >>>> 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. >>>>=20 >>>>> No additional bit is needed, as softforks are coordinated between >>>>> users, NOT miners >>>>=20 >>>> And yet there is miner involvement, as you rightly pointed out. Miners >>>> 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? >>>>=20 >>>> @Jorge >>>>=20 >>>>> If different users want different incompatible things... there's no >>>>> way to avoid the split >>>>=20 >>>> I agree. This happened with bcash, and that's fine. It was painful, but= >>>> there were a significant amount of users that disagreed, and they have >>>> the chain they want now. >>>>=20 >>>> 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. >>>>=20 >>>> However, the question here is: how do we estimate what fraction of user= s >>>> 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, an= d >>>> why we need to have higher thresholds of success (require larger >>>> supermajorities in both consensus and miner signaling). >>>>=20 >>>> Developers obviously care about bitcoin and have an incentive (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 o= n >>>> 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 ha= s >>>> been used as a second barrier to entry for an upgrade is quite >>>> appropriate. >>>>=20 >>>>> On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil 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. >>>>>=20 >>>>> Far too many people have been led to believe there is some sort of >>>>> activation choice with =E2=80=9Censured=E2=80=9D equal outcomes (maybe= =E2=80=9Cslowed down=E2=80=9D). >>>>> There is only a choice between creating a split and hash power >>>>> enforcement. Soft forks are rule changes, and thereby incompatible - >>>>> unless enforced by majority hash power. >>>>>=20 >>>>> The statements below are grossly misleading and need to be called 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 que= stion. The >>>>> question is only how to avoid a split. If one does not care he can >>>>> split at any time, no discussion required. >>>>>=20 >>>>> e >>>>>=20 >>>>>> On Jun 27, 2021, at 01:47, Jorge Tim=C3=B3n wrote:= >>>>>>=20 >>>>>> =EF=BB=BFIf different users want different incompatible things (enoug= h on >>>>>> each side), there's no way to avoid the split. We shouldn't try to >>>>>> avoid such a split. >>>>>> Users decide the rules, not miners nor developers. >>>>>>=20 >>>>>>> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev >>>>>>> wrote: >>>>>>>=20 >>>>>>> Ultimately there is only one answer to this question. Get majority >>>>>>> hash power support. >>>>>>>=20 >>>>>>> Soft fork enforcement is the same act as any other censorship >>>>>>> enforcement, the difference is only a question of what people want. >>>>>>> Given that there is no collective =E2=80=9Cwe=E2=80=9D, those wants d= iffer. Bitcoin >>>>>>> resolves this question of conflicting wants, but it is not a >>>>>>> democracy, it=E2=80=99s a market. One votes by trading. >>>>>>>=20 >>>>>>> If one wants to enforce a soft fork (or otherwise censor) this is >>>>>>> accomplished by mining (or paying others to do so). Anyone can 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 other p= eople. >>>>>>> Anyone can mine, and that=E2=80=99s your vote. >>>>>>>=20 >>>>>>> Otherwise, as mentioned below, anyone can start a new coin. But it=E2= =80=99s >>>>>>> dishonest to imply that one can do this and all others will surely >>>>>>> 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. >>>>>>>=20 >>>>>>> e >>>>>>>=20 >>>>>>>>> On Jun 26, 2021, at 14:43, Eric Voskuil wrote: >>>>>>>>=20 >>>>>>>> =EF=BB=BFFor some definitions of =E2=80=9Cblock=E2=80=9D. >>>>>>>>=20 >>>>>>>> Without majority hash power support, activation simply means you >>>>>>>> are off on a chain split. Anyone can of course split off from a >>>>>>>> chain by changing a rule (soft or otherwise) at any time, so this >>>>>>>> is a bit of an empty claim. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> e >>>>>>>>=20 >>>>>>>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> =EF=BB=BFBIP8 LOT=3DTrue just ensures miners cannot block an upgra= de >>>>>>>>> entirely. They can still slow it down. >>>>>>>>>=20 >>>>>>>>> It also already has the trinary state you seem to be describing >>>>>>>>> (although perhaps this could be better documented in the BIP): >>>>>>>>> users who oppose the softfork can and should treat the successful >>>>>>>>> signal (whether MASF or UASF) as invalid, thereby ensuring they do= >>>>>>>>> not follow a chain with the rules in force. >>>>>>>>>=20 >>>>>>>>> No additional bit is needed, as softforks are coordinated 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. >>>>>>>>>=20 >>>>>>>>> Luke >>>>>>>>>=20 >>>>>>>>>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev >>>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>> Given the recent controversy over upgrade mechanisms for the >>>>>>>>>> non-controversial taproot upgrade, I have been thinking about >>>>>>>>>> ways to solve the problems that both sides brought up. In short, >>>>>>>>>> BIP8 LOT=3Dtrue proponents make the point that lazy miners failin= g >>>>>>>>>> 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 tha= t >>>>>>>>>> solve both problems. >>>>>>>>>>=20 >>>>>>>>>> The proposal uses trinary version signaling rather than binary >>>>>>>>>> signaling. For any particular prospective soft fork upgrade, this= >>>>>>>>>> allows for three signaling states: >>>>>>>>>>=20 >>>>>>>>>> * Actively support the change. >>>>>>>>>> * Actively oppose the change. >>>>>>>>>> * Not signaling (neither support or oppose). This is the default >>>>>>>>>> state. >>>>>>>>>>=20 >>>>>>>>>> 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 oppose >>>>>>>>>> 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 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: >>>>>>>>>>=20 >>>>>>>>>> [image: thresholdChart.png] >>>>>>>>>> If literally no one signals opposition, a 60% threshold should be= >>>>>>>>>> relatively safe because it is a supermajority amount that is >>>>>>>>>> unlikely to change significantly very quickly (ie if 60% of >>>>>>>>>> miners support the change today, its unlikely that less than a >>>>>>>>>> majority of miners would support the change a year or two from >>>>>>>>>> now), and if no one is signaling opposition, chances are that the= >>>>>>>>>> vast majority of the other 40% would also eventually signal >>>>>>>>>> support. >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> 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 discuss= >>>>>>>>>> this will only delay things and cause contention again like it >>>>>>>>>> did with taproot. >>>>>>>>>>=20 >>>>>>>>>> I'm very curious to know what people think of this mechanism. I >>>>>>>>>> would appreciate any comments here, or written as github issues >>>>>>>>>> on the proposal repo itself. >>>>>>>>>>=20 >>>>>>>>>> Thanks, >>>>>>>>>> BT >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> bitcoin-dev mailing list >>>>>>>>> bitcoin-dev@lists.linuxfoundation.org >>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> bitcoin-dev mailing list >>>>>>> bitcoin-dev@lists.linuxfoundation.org >>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >=20