diff options
| author | Jorge Timón <jtimon@jtimon.cc> | 2021-06-29 09:32:33 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-06-29 08:32:42 +0000 |
| commit | d40a20ca7aa1a45420637581e22d074f03f3a2b8 (patch) | |
| tree | f8722b5366b52ff41e01a74096f470590f98205b /5c | |
| parent | 867805d3239b6a7b9d30a9c55e44b0625399d00b (diff) | |
| download | pi-bitcoindev-d40a20ca7aa1a45420637581e22d074f03f3a2b8.tar.gz pi-bitcoindev-d40a20ca7aa1a45420637581e22d074f03f3a2b8.zip | |
Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
Diffstat (limited to '5c')
| -rw-r--r-- | 5c/119ddd62eca3ffdd12332b23f904cb6424ccf1 | 705 |
1 files changed, 705 insertions, 0 deletions
diff --git a/5c/119ddd62eca3ffdd12332b23f904cb6424ccf1 b/5c/119ddd62eca3ffdd12332b23f904cb6424ccf1 new file mode 100644 index 000000000..21e2cfc0f --- /dev/null +++ b/5c/119ddd62eca3ffdd12332b23f904cb6424ccf1 @@ -0,0 +1,705 @@ +Return-Path: <jtimon@jtimon.cc> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 6E6ABC000E + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 29 Jun 2021 08:32:42 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id 4EF0B40263 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 29 Jun 2021 08:32:42 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -0.92 +X-Spam-Level: +X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, + RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no autolearn_force=no +Authentication-Results: smtp4.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=jtimon-cc.20150623.gappssmtp.com +Received: from smtp4.osuosl.org ([127.0.0.1]) + by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id WGJE-Gm_6Scn + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 29 Jun 2021 08:32:39 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com + [IPv6:2607:f8b0:4864:20::b2c]) + by smtp4.osuosl.org (Postfix) with ESMTPS id 7EB2B4025D + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 29 Jun 2021 08:32:39 +0000 (UTC) +Received: by mail-yb1-xb2c.google.com with SMTP id k184so16279219ybf.12 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 29 Jun 2021 01:32:39 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=jtimon-cc.20150623.gappssmtp.com; s=20150623; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :cc; bh=IWfli4P2yGC8Z5bia9BAc2/4K+rd8Ltcku2s5N9e4bo=; + b=iZCOYINHCk3CboeHULZBT1BQn3nHIOYA6BHLBQ7WUxMFH/i7nlzOkcipVwE6RLNgzV + dk42W+RaKTPTFi1vQl9ildndl2XvHnM24damNPc8MaB41puUnpqShxnzNqr+IvMYKgMJ + RjCcUPt0P8v1DiZh2CXEjhMUH8nmmppseI+QadTC4tbah+vgS5DzKw1pJuqY4oIE0bm9 + FDeqrBb9zAT/7Q0UdCQISCU28lLi9AntIwM8zRDpVb4uHsRcQcfjeXuaj6h1esB7cywS + 6qfbKxtXO1vuno1zwaFHsc+bu+RMH0DnLcbe+WUDn245G6BBuSD1VnJ9c7KgvftF/oZG + MACg== +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=IWfli4P2yGC8Z5bia9BAc2/4K+rd8Ltcku2s5N9e4bo=; + b=oAjRbUWgilgJ/Bqlszxcb0ZYhHs0++CbGeBx+BmG6iBFxzjFUnaNtJgIExjBbqAopH + somPdh1+UwXNxSqWr7ZgKmUDQTSUWCWlurfkHG9xabZdudAj9p3ZFL763/Ublhpvqoy/ + q6nzCRoijH+aLl9pMbBSr/f2txqUdfhx4ht7Pk6e4wcHTIisW5jFEBBfDAOe3B0kPl2k + OwqXK/47EcnEZwna0zypGMaWY2JpSt/rql75ColZj2ZlhQU0XZa6vwgULmBMOjMSoMBK + u96zY4ou/nclmEAclVkzUJiUAcKRTUP0yCNp7fExsrWwQLubDKV9T27hqODTF2aqCXP8 + dEUQ== +X-Gm-Message-State: AOAM530JadyhjQ8XStkeRuqAY+1vTvE1e1dhv5p4JT/lHroRkr7OrWmX + QaVgJiwY2I2joYMQmCVue4nydt+4xtG1vjl3rE/Zxw== +X-Google-Smtp-Source: ABdhPJzR7tWMj0ykIcgqkQEsAYqtZeHll3JRrhWBNpqQe6BfHcp8BxiNjIf3jL7UsNXo3vEoEla3vMlVkCn30f/Io9M= +X-Received: by 2002:a25:e756:: with SMTP id e83mr16229467ybh.133.1624955558349; + Tue, 29 Jun 2021 01:32:38 -0700 (PDT) +MIME-Version: 1.0 +References: <CABm2gDrCOVN5FQ4DCGwG=1XjZisTVQdOKCwuPnNxd6yHQhy6rA@mail.gmail.com> + <E6D7F613-2378-44BE-8AFD-CB9A3CF59675@voskuil.org> + <CAGpPWDZKU7bM4URGxceoCmbvJNJBVhSsaiXTjie7kPoBh3TCkQ@mail.gmail.com> +In-Reply-To: <CAGpPWDZKU7bM4URGxceoCmbvJNJBVhSsaiXTjie7kPoBh3TCkQ@mail.gmail.com> +From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc> +Date: Tue, 29 Jun 2021 09:32:33 +0100 +Message-ID: <CABm2gDqQm0_JnddJ2AKbDnNTGV0kYm-zOqtyZFn2=GHRb2cY2g@mail.gmail.com> +To: Billy Tetrud <billy.tetrud@gmail.com> +Content-Type: multipart/alternative; boundary="000000000000d4e64d05c5e372de" +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Tue, 29 Jun 2021 08:32:42 -0000 + +--000000000000d4e64d05c5e372de +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +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 <billy.tetrud@gmail.com> 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 bitcoin user= +s +> 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 wi= +th +> Eric that the goal here is to prevent a chain split during an upgrade whe= +n +> 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 mechani= +sm +> to improve upon the speedy-trial idea, allowing for even speedier release= +s +> (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 ar= +e +> 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 th= +e +> 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 users +> wants which rules? We don't have a divining rod to determine with certain= +ty +> 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 a= +re +> very rough estimates of user sentiment, we need to consider the possibili= +ty +> that sometimes the estimate may be substantially inaccurate when we desig= +n +> deployment procedures. This inaccuracy is why we need multiple barriers i= +n +> place for an upgrade, and why we need to have higher thresholds of succes= +s +> (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 has been used a= +s +> a second barrier to entry for an upgrade is quite appropriate. +> +> On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil <eric@voskuil.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 enforcement does not crea= +te +>> 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 (maybe = +=E2=80=9Cslowed down=E2=80=9D). +>> There is only a choice between creating a split and hash power enforceme= +nt. +>> 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 i= +dea +>> that =E2=80=9Cusers=E2=80=9D decide the rules is not the question. The q= +uestion 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 <jtimon@jtimon.cc> wrote: +>> > +>> > =EF=BB=BFIf different users want different incompatible 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.linuxfoundation.org> 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. Give= +n +>> that there is no collective =E2=80=9Cwe=E2=80=9D, those wants differ. Bi= +tcoin 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 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=99= +s time +>> Bitcoiners stop thinking of miners as other 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 follo= +w. +>> 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 <eric@voskuil.org> 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 ho= +w +>> to *prevent* a split. And activation without majority hash power certain= +ly +>> does not =E2=80=9Censure=E2=80=9D this. +>> >>> +>> >>> e +>> >>> +>> >>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev < +>> bitcoin-dev@lists.linuxfoundation.org> wrote: +>> >>>> +>> >>>> =EF=BB=BFBIP8 LOT=3DTrue just ensures miners cannot block an upgrad= +e 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 o= +r +>> 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 a= +s +>> also +>> >>>> being users). The miner involvement is only out of necessity (to se= +t +>> 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-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 failing 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 +>> >>>>> < +>> https://github.com/fresheneesz/bip-trinary-version-signaling/blob/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 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 oppose the change are incentivize= +d +>> 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: +>> >>>>> +>> >>>>> [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. +>> >>>>> +>> >>>>> This both gives an incentive for "lazy" miners to upgrade if they +>> actually +>> >>>>> oppose the change while at the same time allowing these lazy miner= +s +>> 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 discuss this will only dela= +y +>> 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 +>> +> + +--000000000000d4e64d05c5e372de +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"auto">I think the option of "permanent failure because min= +ers veto" should actually be abandoned.=C2=A0<div dir=3D"auto">No, I d= +on't think we should avoid splits when possible, I don't think we s= +hould avoid splits at all costs.</div><div dir=3D"auto"><br></div></div><br= +><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, J= +un 27, 2021, 19:12 Billy Tetrud <<a href=3D"mailto:billy.tetrud@gmail.co= +m">billy.tetrud@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmai= +l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left= +:1ex"><div dir=3D"ltr">@Luke<div>> They can still slow it down.</div><di= +v><br></div><div>Absolutely. However I think that the option of permanent f= +ailure is important. It certainly would be ideal to ensure that enough bitc= +oin users support the upgrade *before* releasing it, however realistically = +this can never be more than an estimate, and estimates can sometimes be wil= +dly wrong. It would be unfortunate if miners had a substantially different = +estimate of user support than the people putting in the work to release bit= +coin upgrades. Even if upgrades are never released before it becomes clear = +that a large supermajority of users want the upgrade, if miners don't a= +gree 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=C2=A0failure of an upgrade when there is = +unexpectedly large miner opposition.=C2=A0</div><div><br></div><div>This of= + course does not prevent a UASF-style deployment to be done after an initia= +l failure to deploy occurs. My proposal is essentially a mechanism to impro= +ve upon the speedy-trial idea, allowing for even speedier releases (than sp= +eedy trial) without adding additional risk of undesired chain splits.=C2=A0= +</div><div><br></div><div>> [BIP8] already has the trinary state you see= +m to be describing</div><div><br></div><div>It sounds like you're sayin= +g the trinary state of BIP8 is A. Follow the longest chain, B. Follow the u= +pgrade chain, or C. follow the non-upgraded chain. I agree. However the tri= +nary state in my proposal is materially different - it is the signaling its= +elf that is trinary, not just which chain is being followed. This allows ot= +hers to know and make programmatic decisions (in software) based on that si= +gnaling. I'm sure you can agree that does not exist in BIP8.=C2=A0</div= +><div><br></div><div>> No additional bit is needed, as softforks are coo= +rdinated between users, NOT miners</div><div><br></div><div>And yet there i= +s miner involvement, as you rightly pointed out. Miners are needed to set t= +he nVersion in the header. So when you say "no additional bit is neede= +d", 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 mi= +ners might be opposing an upgrade?=C2=A0</div><div><br></div><div>@Jorge<br= +></div><div>> If different users want different incompatible things... t= +here's no way to avoid the split</div><div><br></div><div>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 w= +ant now.</div><div><br></div><div><div>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= +.</div></div><div><br></div><div>However, the question here is: how do we e= +stimate what fraction of users wants which rules? We don't have a divin= +ing 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 com= +munity discussion and social consensus estimation as well as miner signalin= +g during the actual deployment period.=20 + +Neither of these are perfect, but they are both reasonable enough mechanism= +s. However, because both of these mechanisms are very rough estimates of us= +er sentiment, we need to consider the possibility that sometimes the estima= +te may be substantially inaccurate when we design deployment procedures. Th= +is inaccuracy is why we need multiple barriers in place for an upgrade, and= + why we need to have higher thresholds of success (require larger supermajo= +rities in both consensus and miner signaling).=C2=A0</div><div><br></div><d= +iv>Developers obviously care about bitcoin and have an incentive (personal = +and probably financial) to do it right. And miners have both an incentive t= +o keep the system healthy, as well as an incentive to mine on the chain tha= +t the economic majority of users is using. But measuring the consensus of t= +he bitcoin community can be extraordinarily difficult to do with consistent= + accuracy, and so I think miner signaling as it has been used as a second b= +arrier to entry for an upgrade is quite appropriate.=C2=A0</div></div><br><= +div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jun= + 27, 2021 at 2:22 AM Eric Voskuil <<a href=3D"mailto:eric@voskuil.org" t= +arget=3D"_blank" rel=3D"noreferrer">eric@voskuil.org</a>> wrote:<br></di= +v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde= +r-left:1px solid rgb(204,204,204);padding-left:1ex">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 inhe= +rent soft fork =E2=80=9Ccompatibility=E2=80=9D and the implication that act= +ivation without hash power enforcement does not create a split that I objec= +t to. People who know better should be honest about it.<br> +<br> +Far too many people have been led to believe there is some sort of activati= +on choice with =E2=80=9Censured=E2=80=9D equal outcomes (maybe =E2=80=9Cslo= +wed down=E2=80=9D). There is only a choice between creating a split and has= +h power enforcement. Soft forks are rule changes, and thereby incompatible = +- unless enforced by majority hash power.<br> +<br> +The statements below are grossly misleading and need to be called out as su= +ch so that people can actually make this decision you speak of. This idea t= +hat =E2=80=9Cusers=E2=80=9D decide the rules is not the question. The quest= +ion is only how to avoid a split. If one does not care he can split at any = +time, no discussion required.<br> +<br> +e<br> +<br> +> On Jun 27, 2021, at 01:47, Jorge Tim=C3=B3n <jtimon@jtimon.cc> w= +rote:<br> +> <br> +> =EF=BB=BFIf different users want different incompatible things (enough= + on each<br> +> side), there's no way to avoid the split. We shouldn't try to = +avoid<br> +> such a split.<br> +> Users decide the rules, not miners nor developers.<br> +> <br> +>> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev<br> +>> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe= +t=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>&g= +t; wrote:<br> +>> <br> +>> Ultimately there is only one answer to this question. Get majority= + hash power support.<br> +>> <br> +>> Soft fork enforcement is the same act as any other censorship enfo= +rcement, 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 re= +solves this question of conflicting wants, but it is not a democracy, it=E2= +=80=99s a market. One votes by trading.<br> +>> <br> +>> 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 eve= +ryone gets a say. Mining is trading capital now for more later. If enough p= +eople want to do that, they can enforce a soft fork. It=E2=80=99s time Bitc= +oiners stop thinking of miners as other people. Anyone can mine, and that= +=E2=80=99s your vote.<br> +>> <br> +>> Otherwise, as mentioned below, anyone can start a new coin. But it= +=E2=80=99s dishonest to imply that one can do this and all others will 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.<br> +>> <br> +>> e<br> +>> <br> +>>>> On Jun 26, 2021, at 14:43, Eric Voskuil <<a href=3D"mai= +lto:eric@voskuil.org" target=3D"_blank" rel=3D"noreferrer">eric@voskuil.org= +</a>> wrote:<br> +>>> <br> +>>> =EF=BB=BFFor some definitions of =E2=80=9Cblock=E2=80=9D.<br> +>>> <br> +>>> Without majority hash power support, activation simply means y= +ou 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 em= +pty claim.<br> +>>> <br> +>>> Nobody can stop a person from splitting. The relevant question= + is how to *prevent* a split. And activation without majority hash power ce= +rtainly does not =E2=80=9Censure=E2=80=9D this.<br> +>>> <br> +>>> e<br> +>>> <br> +>>>> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev <= +;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"= + rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br= +> +>>>> <br> +>>>> =EF=BB=BFBIP8 LOT=3DTrue just ensures miners cannot block = +an upgrade entirely. They can<br> +>>>> still slow it down.<br> +>>>> <br> +>>>> It also already has the trinary state you seem to be descr= +ibing (although<br> +>>>> perhaps this could be better documented in the BIP): users= + who oppose the<br> +>>>> softfork can and should treat the successful signal (wheth= +er MASF or UASF) as<br> +>>>> invalid, thereby ensuring they do not follow a chain with = +the rules in force.<br> +>>>> <br> +>>>> No additional bit is needed, as softforks are coordinated = +between users, NOT<br> +>>>> miners (who have no particular say in them, aside from the= +ir role as also<br> +>>>> being users). The miner involvement is only out of necessi= +ty (to set the bit<br> +>>>> in the header, which users coordinate with) and potentiall= +y to accelerate<br> +>>>> activation by protecting upgrade-lagging users.<br> +>>>> <br> +>>>> Luke<br> +>>>> <br> +>>>> <br> +>>>>>> On Saturday 26 June 2021 20:21:52 Billy Tetrud via= + bitcoin-dev wrote:<br> +>>>>> Given the recent controversy over upgrade mechanisms f= +or the<br> +>>>>> non-controversial taproot upgrade, I have been thinkin= +g about ways to solve<br> +>>>>> the problems that both sides brought up. In short, BIP= +8 LOT=3Dtrue proponents<br> +>>>>> make the point that lazy miners failing to upgrade in = +a timely manner slow<br> +>>>>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT= +=3Dfalse<br> +>>>>> proponents make the point that LOT=3Dtrue can lead to = +undesirable forks that<br> +>>>>> might cause a lot of chaos. I believe both points are = +essentially correct<br> +>>>>> and have created a proposal<br> +>>>>> <<a href=3D"https://github.com/fresheneesz/bip-trin= +ary-version-signaling/blob/master/b" rel=3D"noreferrer noreferrer" target= +=3D"_blank">https://github.com/fresheneesz/bip-trinary-version-signaling/bl= +ob/master/b</a><br> +>>>>> ip-trinary-version-bits.md> for soft fork upgrades = +that solve both problems.<br> +>>>>> <br> +>>>>> The proposal uses trinary version signaling rather tha= +n binary signaling.<br> +>>>>> For any particular prospective soft fork upgrade, this= + allows for three<br> +>>>>> signaling states:<br> +>>>>> <br> +>>>>> * Actively support the change.<br> +>>>>> * Actively oppose the change.<br> +>>>>> * Not signaling (neither support or oppose). This is t= +he default state.<br> +>>>>> <br> +>>>>> Using this additional information, we can release non-= +contentious upgrades<br> +>>>>> much quicker (with a much lower percent of miners sign= +aling support). For<br> +>>>>> contentious upgrades, miners who oppose the change are= + incentivized to<br> +>>>>> update their software to a version that can actively s= +ignal opposition to<br> +>>>>> the change. The more opposition there is, the higher t= +he threshold<br> +>>>>> necessary to lock in the upgrade. With the parameters = +I currently<br> +>>>>> recommended in the proposal, this chart shows how much= + support signaling<br> +>>>>> would be necessary given a particular amount of active= + opposition<br> +>>>>> signaling:<br> +>>>>> <br> +>>>>> [image: thresholdChart.png]<br> +>>>>> If literally no one signals opposition, a 60% threshol= +d should be<br> +>>>>> relatively safe because it is a supermajority amount t= +hat is unlikely to<br> +>>>>> change significantly very quickly (ie if 60% of miners= + support the change<br> +>>>>> today, its unlikely that less than a majority of miner= +s would support the<br> +>>>>> change a year or two from now), and if no one is signa= +ling opposition,<br> +>>>>> chances are that the vast majority of the other 40% wo= +uld also eventually<br> +>>>>> signal support.<br> +>>>>> <br> +>>>>> This both gives an incentive for "lazy" mine= +rs to upgrade if they actually<br> +>>>>> oppose the change while at the same time allowing thes= +e lazy miners to<br> +>>>>> remain lazy without slowing down the soft fork activat= +ion much.<br> +>>>>> <br> +>>>>> I think now is the right time to discuss new soft fork= + upgrade mechanisms,<br> +>>>>> when there are no pressing soft fork upgrades ready to= + deploy. Waiting<br> +>>>>> until we need to deploy a soft fork to discuss this wi= +ll only delay things<br> +>>>>> and cause contention again like it did with taproot.<b= +r> +>>>>> <br> +>>>>> I'm very curious to know what people think of this= + mechanism. I would<br> +>>>>> appreciate any comments here, or written as github iss= +ues on the proposal<br> +>>>>> repo itself.<br> +>>>>> <br> +>>>>> Thanks,<br> +>>>>> BT<br> +>>>> <br> +>>>> _______________________________________________<br> +>>>> bitcoin-dev mailing list<br> +>>>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t= +arget=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</= +a><br> +>>>> <a href=3D"https://lists.linuxfoundation.org/mailman/listi= +nfo/bitcoin-dev" rel=3D"noreferrer noreferrer" target=3D"_blank">https://li= +sts.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br> +>> _______________________________________________<br> +>> bitcoin-dev mailing list<br> +>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D= +"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br> +>> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc= +oin-dev" rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linu= +xfoundation.org/mailman/listinfo/bitcoin-dev</a><br> +</blockquote></div> +</blockquote></div> + +--000000000000d4e64d05c5e372de-- + |