diff options
| author | Keagan McClelland <keagan.mcclelland@gmail.com> | 2021-12-30 20:10:48 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-12-31 03:11:05 +0000 |
| commit | 4616a48f56dade051c57783e5f9f85295fb5673f (patch) | |
| tree | 5e2c034c860e71b0cede613dbd5de30fac950a5b | |
| parent | e4a701da4d95155e4b20470d3e6382f18f2dd752 (diff) | |
| download | pi-bitcoindev-4616a48f56dade051c57783e5f9f85295fb5673f.tar.gz pi-bitcoindev-4616a48f56dade051c57783e5f9f85295fb5673f.zip | |
Re: [bitcoin-dev] On the regularity of soft forks
| -rw-r--r-- | 5e/330f14c0058a8515b4b6a665f155aa1c4ff451 | 735 |
1 files changed, 735 insertions, 0 deletions
diff --git a/5e/330f14c0058a8515b4b6a665f155aa1c4ff451 b/5e/330f14c0058a8515b4b6a665f155aa1c4ff451 new file mode 100644 index 000000000..a54ab73c4 --- /dev/null +++ b/5e/330f14c0058a8515b4b6a665f155aa1c4ff451 @@ -0,0 +1,735 @@ +Return-Path: <keagan.mcclelland@gmail.com> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 59D84C0012 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 31 Dec 2021 03:11:05 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with ESMTP id 45C5360C0F + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 31 Dec 2021 03:11:05 +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: smtp3.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=gmail.com +Received: from smtp3.osuosl.org ([127.0.0.1]) + by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 0RbzUj8zB8ep + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 31 Dec 2021 03:11:03 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com + [IPv6:2a00:1450:4864:20::330]) + by smtp3.osuosl.org (Postfix) with ESMTPS id 1B8326058D + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 31 Dec 2021 03:11:02 +0000 (UTC) +Received: by mail-wm1-x330.google.com with SMTP id + f134-20020a1c1f8c000000b00345c05bc12dso14193876wmf.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 30 Dec 2021 19:11:02 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :cc; bh=ODEUozJWn0RbZfXS7KyomnxMS6KfSLvWk/15aEFGvPw=; + b=iR+jD4FQtYEG6y7+Ig5TEeGwt9Lw8MG//dikik72wx+BuEZZqO7b+IIrqfuQjh7xkf + vCzjmTsoEwc5Nn4BhTCztbgCdaQc/YgPoBDj1PiGJ0M/lVr9un9RptlNNw4bJJzD7sry + NToIYFrJGI6N1ovw4r1pvAESYKn7Ej2WZao2EMVUcw6cZd89dhSGMIMqx0bcLZbbDE2E + nhPzRZU1p6kohB/SzOOhVjUN7xoQ2JlxO/cnM4snyY/jxjduziN0BOH38AMxdHpoQTpr + RCnYZ7Bep7g8f0g3HHquvf0NsaINqsZ9ZBdroProO2RgImv52EO3XfxGkiaE9cZ7dFqt + 0q0A== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20210112; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to:cc; + bh=ODEUozJWn0RbZfXS7KyomnxMS6KfSLvWk/15aEFGvPw=; + b=Hx1PUIETv3CrjesgLZlkJU4G8XQ2bRGr8PD9+UhTwSoqTPVY7nVoOr0ClyQO9Mxy2s + /vg/xfe1aAQ06aQ4WRwk5ZEotHYBSsnX0KD9eUiIlEM7gy5wm7keo6M4LKyIn/eL2HMP + BDh5/ZLaVnbjiYYBNAbFSO5JxycUVRJWGoJy0426IpkkgLPDPhGospv+uDIBKFYmiWnb + NBVzeHDFTkPCVxouAO5/C9Sr+KNELHUCnMEXt3BAoDm9Ktvxdt60gW0zKZRee0V/JeCY + 6aN3FR0xhH+ARd6dRwzhVHPJep3f7Zn2nTJltMzBoUEai+PjIuAuL0FV7wQBQrRFDkSo + 8mBA== +X-Gm-Message-State: AOAM53357dn3IAfoB5FxMto9ELX+wMV15t8ABPBDgyZhh/DegoJ7IkZE + 7sTTzLRfl0QCw/5DLOPaxJYoh5ITuOsynsJfoOi3c9dZdbQ= +X-Google-Smtp-Source: ABdhPJwE/uTH2MZn2pa9AYXsQpGvEQ6zmcVo35xr4hXwL9P+kvWYEQClxhZDYk6CEfDarPv/shLWOpBzXztqF9cHCj0= +X-Received: by 2002:a05:600c:245:: with SMTP id + 5mr28359944wmj.23.1640920261087; + Thu, 30 Dec 2021 19:11:01 -0800 (PST) +MIME-Version: 1.0 +References: <LmX3Gnfkf1T0Eb_wUXxPe8c0Tf2DNipfIqufkRS6oOPhttr4iZIOWtjUL_7QkcWEHr8eFvehHooaM140ZBKLwi98F5NwyQKSyEhAPZDK1YQ=@protonmail.com> + <CAD5xwhj3JCxH1=5Tj+hgiSxLWchLgT584X0YutKVeuibnpwmtA@mail.gmail.com> + <20211014235207.GB6451@erisian.com.au> + <CAHvMVPQ8jtfdbLg8NJv7bNM3a_nhF_aUfD2gwSdxpfgXQomn3A@mail.gmail.com> + <1HjQQw-RXvEW5i73Hjx_QqDms44sQMnNWWl9oQ_SwIoYGpog6LzGK4M_omAEMXxgXIID37V7sdyG_AW8WkaNByppB2EJ7wlzOZgrDloMv2c=@protonmail.com> +In-Reply-To: <1HjQQw-RXvEW5i73Hjx_QqDms44sQMnNWWl9oQ_SwIoYGpog6LzGK4M_omAEMXxgXIID37V7sdyG_AW8WkaNByppB2EJ7wlzOZgrDloMv2c=@protonmail.com> +From: Keagan McClelland <keagan.mcclelland@gmail.com> +Date: Thu, 30 Dec 2021 20:10:48 -0700 +Message-ID: <CALeFGL3EGJ-kHs2C5qfTVcfZ0QNAHECOgMevoFEJJjTEcBLeEw@mail.gmail.com> +To: Michael Folkson <michaelfolkson@protonmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="00000000000044554e05d4688530" +X-Mailman-Approved-At: Fri, 31 Dec 2021 09:34:47 +0000 +Subject: Re: [bitcoin-dev] On the regularity of soft forks +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: Fri, 31 Dec 2021 03:11:05 -0000 + +--00000000000044554e05d4688530 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +> But whether or not it is a basic principle of general software +engineering kind of misses the point. Security critical software clearly +isn't engineered in the same way as a new social media app. Bugs are easily +reverted in a new social media app.On top of that we aren't just dealing +with security critical software. One of the most important objectives is to +keep all the nodes on the network in consensus. Introducing a consensus +change before we are comfortable there is community consensus for it is a +massive effective bug in itself. The network can split in multiple ways +e.g. part of the network disagrees on whether to activate the consensus +change, part of the network disagrees on how to resist that consensus +change, part of the network disagrees on how to activate that consensus +change etc + +> A consensus change is extremely hard to revert and probably requires a +hard fork, a level of central coordination we generally attempt to avoid +and a speed of deployment that we also attempt to avoid. + +This seems to assert the idea that soft forks are all the same: they are +not. For instance a soft fork, lowering the block subsidy is completely +different than changing the semantics of an OP_NOP to have semantics that +may reject a subset of the witnesses that attest to the transactions +permissibility. As a result, reversion means two entirely different things +in these contexts. While a strict reversion of both soft forks is by +definition a hard fork, the requirement of reversion as a result of +undesired behavior is not the same. In the case of opcodes, there is almost +never a requirement to revert it. If you don't like the way the opcodes +behave, then you just don't use them. If you don't like the reduction of +the block subsidy, well that's a much bigger problem. + +I make this point to elucidate the idea that we cannot treat SoftForks=E2= +=84=A2 as +a single monolithic idea. Perhaps we need to come up with better +terminology to be specific about what each fork actually is. The soft vs. +hard distinction is a critical one but it is not enough and treating soft +forks that are noninvasive such as OP_NOP tightenings. This has been +proposed before [1], and while I do not necessarily think the terms cited +are necessarily complete, they admit the low resolution of our current +terminology. + +> Soft fork features can (and should) obviously be tested thoroughly on +testnet, signet, custom signets, sidechains etc on a standalone basis and a +bundled basis. + +I vehemently disagree that any consensus changes should be bundled, +especially when it comes to activation parameters. When we start to bundle +things, we amplify the community resources needed to do review, not reduce +them. I suspect your opinion here is largely informed by your frustration +with the Taproot Activation procedure that you underwent earlier this year. +This is understandable. However, let me present the alternative case. If we +start to bundle features, the review of the features gets significantly +harder. As the Bitcoin project scales, the ability of any one developer to +understand the entire codebase declines. Bundling changes reduces the +number of people who are qualified to review a particular proposal, and +even worse, intimidates people who may be willing and able to review +logically distinct portions of the proposal, resulting in lower amounts of +review overall. This will likely have the opposite effect of what you seem +to desire. BIP8 and BIP9 give us the ability to have multiple independent +soft forks in flight at once. Choosing to bundle them instead makes little +sense when we do not have to. Bundling them will inevitably degenerate into +political horse trading and everyone will be worse off for it. + +> part of the network disagrees on whether to activate the consensus +change, part of the network disagrees on how to resist that consensus +change, part of the network disagrees on how to activate that consensus +change etc + +Disagreements, and by extension, forks are a part of Bitcoin. What is +important is that they are well defined and clean. This is the reason why +the mandatory signaling period exists in BIP8/9, so that clients that +intend to reject the soft fork change have a very easy means of doing so in +a clean break where consensus is clearly divergent. In accordance with +this, consensus changes should be sequenced so that people can decide which +sides of the forks they want to follow and that the economic reality can +reorganize around that. If choose to bundle them, you have one of two +outcomes: either consensus atomizes into a mist where people have different +ideas of which subsets of a soft fork bundle they want to adopt, or what +likely comes after is a reconvergence on the old client with none of the +soft fork rules in place. This will lead to significantly more confusion as +well given that with sufficient miner consensus some of the rules may stick +anyway even if the rest of the user base reconverges on the old client. + +It is quite likely less damaging to consensus to have frequent but strictly +sequenced soft forks so that if one of the new rules is contentious the +break can happen cleanly. That said, if Core or any other client wishes to +cut a release of the software with the parameters bundled into a single +release, that is a significantly more palatable state of affairs, as you +can still pipeline signaling and activation. However, the protocol itself +adopting a tendency to activate unrelated proposals in bundles is a recipe +for disaster. + + +Respectfully, +Keagan + + +[1] https://www.truthcoin.info/blog/protocol-upgrade-terminology + +On Sat, Oct 16, 2021 at 12:57 PM Michael Folkson via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> > Interesting discussion. Correct me if I'm wrong: but putting too many +> features together in one shot just can't make things harder to debug in +> production if something very unexpected happens. It's a basic principle +> of software engineering. +> +> Soft fork features can (and should) obviously be tested thoroughly on +> testnet, signet, custom signets, sidechains etc on a standalone basis and= + a +> bundled basis. But whether or not it is a basic principle of general +> software engineering kind of misses the point. Security critical software +> clearly isn't engineered in the same way as a new social media app. Bugs +> are easily reverted in a new social media app. A consensus change is +> extremely hard to revert and probably requires a hard fork, a level of +> central coordination we generally attempt to avoid and a speed of +> deployment that we also attempt to avoid. On top of that we aren't just +> dealing with security critical software. One of the most important +> objectives is to keep all the nodes on the network in consensus. +> Introducing a consensus change before we are comfortable there is communi= +ty +> consensus for it is a massive effective bug in itself. The network can +> split in multiple ways e.g. part of the network disagrees on whether to +> activate the consensus change, part of the network disagrees on how to +> resist that consensus change, part of the network disagrees on how to +> activate that consensus change etc +> +> In addition, a social media app can experiment in production whether +> Feature A works, whether Feature B works or whether Feature A and B work +> best together. In Bitcoin if we activate consensus Feature A, later decid= +e +> we want consensus Feature B but find out that by previously activating +> Feature A we can't have Feature B (it is now unsafe to activate it) or it= +s +> design now has to be suboptimal because we have to ensure it can safely +> work in the presence of Feature A we have made a mistake by activating +> Feature A in the first place. Decentralized security critical consensus +> changes are an emerging field in itself and really can't be treated like +> any other software project. This will become universally understood I'm +> sure over time. +> +> --Michael Folkson +> Email: michaelfolkson at protonmail.com +> Keybase: michaelfolkson +> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 +> +> +> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original = +Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 +> On Friday, October 15th, 2021 at 1:43 AM, Felipe Micaroni Lalli via +> bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: +> +> Interesting discussion. Correct me if I'm wrong: but putting too many +> features together in one shot just can't make things harder to debug in +> production if something very unexpected happens. It's a basic principle +> of software engineering. +> +> Change. Deploy. Nothing bad happened? Change it a little more. Deployment= +. +> Or: Change, change, change. Deploy. Did something bad happen? What change +> caused the problem? +> +> On Thu, Oct 14, 2021 at 8:53 PM Anthony Towns via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org> wrote: +> +>> On Mon, Oct 11, 2021 at 12:12:58PM -0700, Jeremy via bitcoin-dev wrote: +>> > > ... in this post I will argue against frequent soft forks with a +>> single or +>> > minimal +>> > > set of features and instead argue for infrequent soft forks with +>> batches +>> > > of features. +>> > I think this type of development has been discussed in the past and ha= +s +>> been +>> > rejected. +>> +>> > AJ: - improvements: changes might not make everyone better off, but we +>> > don't want changes to screw anyone over either -- pareto +>> > improvements in economics, "first, do no harm", etc. (if we get thi= +s +>> > right, there's no need to make compromises and bundle multiple +>> > flawed proposals so that everyone's an equal mix of happy and +>> > miserable) +>> +>> I don't think your conclusion above matches my opinion, for what it's +>> worth. +>> +>> If you've got two features, A and B, where the game theory is: +>> +>> If A happens, I'm +100, You're -50 +>> If B happens, I'm -50, You're +100 +>> +>> then even though A+B is +50, +50, then I do think the answer should +>> generally be "think harder and come up with better proposals" rather tha= +n +>> "implement A+B as a bundle that makes us both +50". +>> +>> _But_ if the two features are more like: +>> +>> If C happens, I'm +100, You're +/- 0 +>> If D happens, I'm +/- 0, You're +100 +>> +>> then I don't have a problem with bundling them together as a single +>> simultaneous activation of both C and D. +>> +>> Also, you can have situations where things are better together, +>> that is: +>> +>> If E happens, we're both at +100 +>> If F happens, we're both at +50 +>> If E+F both happen, we're both at +9000 +>> +>> In general, I think combining proposals when the combination is better +>> than the individual proposals were is obviously good; and combining +>> related proposals into a single activation can be good if it is easier +>> to think about the ideas as a set. +>> +>> It's only when you'd be rejecting the proposal on its own merits that +>> I think combining it with others is a bad idea in principle. +>> +>> For specific examples, we bundled schnorr, Taproot, MAST, OP_SUCCESSx +>> and CHECKSIGADD together because they do have synergies like that; we +>> didn't bundle ANYPREVOUT and graftroot despite the potential synergies +>> because those features needed substantially more study. +>> +>> The nulldummy soft-fork (bip 147) was deployed concurrently with +>> the segwit soft-fork (bip 141, 143), but I don't think there was any +>> particular synergy or need for those things to be combined, it just +>> reduced the overhead of two sets of activation signalling to one. +>> +>> Note that the implementation code for nulldummy had already been merged +>> and were applied as relay policy well before activation parameters were +>> defined (May 2014 via PR#3843 vs Sep 2016 for PR#8636) let alone becomin= +g +>> an active soft fork. +>> +>> Cheers, +>> aj +>> +>> _______________________________________________ +>> 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 +> + +--00000000000044554e05d4688530 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">>=C2=A0<span style=3D"color:rgb(0,0,0);font-family:aria= +l,helvetica,sans-serif">=C2=A0But whether or not it is a basic principle of= + general software engineering kind of misses the point. Security critical s= +oftware clearly isn't engineered in the same way as a new social media = +app. Bugs are easily reverted in a new social media app.On top of that we a= +ren't just dealing with security critical software. One of the most imp= +ortant objectives is to keep all the nodes on the network in consensus. Int= +roducing a consensus change before we are comfortable there is community co= +nsensus for it is a massive effective bug in itself. The network can split = +in multiple ways e.g. part of the network disagrees on whether to activate = +the consensus change, part of the network disagrees on how to resist that c= +onsensus change, part of the network disagrees on how to activate that cons= +ensus change etc</span><div><font color=3D"#000000" face=3D"arial, helvetic= +a, sans-serif"><br></font></div><div><font color=3D"#000000" face=3D"arial,= + helvetica, sans-serif">>=C2=A0</font><span style=3D"color:rgb(0,0,0);fo= +nt-family:arial,helvetica,sans-serif">=C2=A0A consensus change is extremely= + hard to revert and probably requires a hard fork, a level of central coord= +ination we generally attempt to avoid and a speed of deployment that we als= +o attempt to avoid.</span><font color=3D"#000000" face=3D"arial, helvetica,= + sans-serif"><br></font><div style=3D"box-sizing:inherit;quotes:"\0020= +1c" "\00201d" "\002018" "\002019";line-h= +eight:normal;font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br><= +/div><div style=3D"box-sizing:inherit;quotes:"\00201c" "\002= +01d" "\002018" "\002019";line-height:normal;font-f= +amily:arial,helvetica,sans-serif;color:rgb(0,0,0)">This seems to assert the= + idea that soft forks are all the same: they are not. For instance a soft f= +ork, lowering the block subsidy is completely different than changing the s= +emantics of an OP_NOP to have semantics that may reject a subset of the wit= +nesses that attest to the transactions permissibility. As a result, reversi= +on means two entirely different things in these contexts. While a strict re= +version of both soft forks is by definition a hard fork, the requirement of= + reversion as a result of undesired behavior is not the same. In the case o= +f opcodes, there is almost never a requirement to revert it. If you don'= +;t like the way the opcodes behave, then you just don't use them. If yo= +u don't like the reduction of the block subsidy, well that's a much= + bigger problem.</div><div style=3D"box-sizing:inherit;quotes:"\00201c= +" "\00201d" "\002018" "\002019";line-hei= +ght:normal;font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br></d= +iv><div style=3D"box-sizing:inherit;quotes:"\00201c" "\00201= +d" "\002018" "\002019";line-height:normal;font-fam= +ily:arial,helvetica,sans-serif;color:rgb(0,0,0)">I make this point to eluci= +date the idea that we cannot treat SoftForks=E2=84=A2 as a single monolithi= +c idea. Perhaps we need to come up with better terminology to be specific a= +bout what each fork actually is. The soft vs. hard distinction is a critica= +l one but it is not enough and treating soft forks that are noninvasive suc= +h as OP_NOP tightenings. This has been proposed before [1], and while I do = +not necessarily think the terms cited are necessarily complete, they admit = +the low resolution of our current terminology.</div></div><div style=3D"box= +-sizing:inherit;quotes:"\00201c" "\00201d" "\00201= +8" "\002019";line-height:normal;font-family:arial,helvetica,= +sans-serif;color:rgb(0,0,0)"><br></div><div style=3D"box-sizing:inherit;quo= +tes:"\00201c" "\00201d" "\002018" "\0020= +19";line-height:normal;font-family:arial,helvetica,sans-serif;color:rg= +b(0,0,0)">> Soft fork features can (and should) obviously be tested thor= +oughly on testnet, signet, custom signets, sidechains etc on a standalone b= +asis and a bundled basis.</div><div style=3D"box-sizing:inherit;quotes:&quo= +t;\00201c" "\00201d" "\002018" "\002019"= +;line-height:normal;font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)= +"><br></div><div style=3D"box-sizing:inherit;quotes:"\00201c" &qu= +ot;\00201d" "\002018" "\002019";line-height:normal= +;font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">I vehemently disa= +gree that any consensus changes should be bundled, especially when it comes= + to activation parameters. When we start to bundle things, we amplify the c= +ommunity resources needed to do review, not reduce them. I suspect your opi= +nion here is largely informed by your frustration with the Taproot Activati= +on procedure that you underwent earlier this year. This is understandable. = +However, let me present the alternative case. If we start to bundle feature= +s, the review of the features gets significantly harder. As the Bitcoin pro= +ject scales, the ability of any one developer to understand the entire code= +base declines. Bundling changes reduces the number of people who are qualif= +ied to review a particular proposal, and even worse, intimidates people who= + may be willing and able to review logically distinct portions of the propo= +sal, resulting in lower amounts of review overall. This will likely have th= +e opposite effect of what you seem to desire. BIP8 and BIP9 give us the abi= +lity to have multiple independent soft forks in flight at once. Choosing to= + bundle them instead makes little sense when we do not have to. Bundling th= +em will inevitably degenerate into political horse trading and everyone wil= +l be worse off for it.</div><div style=3D"box-sizing:inherit;quotes:"\= +00201c" "\00201d" "\002018" "\002019";li= +ne-height:normal;font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><= +br></div><div style=3D"box-sizing:inherit;quotes:"\00201c" "= +\00201d" "\002018" "\002019";line-height:normal;fo= +nt-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">> part of the net= +work disagrees on whether to activate the consensus change, part of the net= +work disagrees on how to resist that consensus change, part of the network = +disagrees on how to activate that consensus change etc</div><div style=3D"b= +ox-sizing:inherit;quotes:"\00201c" "\00201d" "\002= +018" "\002019";line-height:normal;font-family:arial,helvetic= +a,sans-serif;color:rgb(0,0,0)"><br></div><div style=3D"box-sizing:inherit;q= +uotes:"\00201c" "\00201d" "\002018" "\00= +2019";line-height:normal;font-family:arial,helvetica,sans-serif;color:= +rgb(0,0,0)">Disagreements, and by extension, forks are a part of Bitcoin. W= +hat is important is that they are well defined and clean. This is the reaso= +n why the mandatory signaling period exists in BIP8/9, so that clients that= + intend to reject the soft fork change have a very easy means of doing so i= +n a clean break where consensus is clearly divergent. In accordance with th= +is, consensus changes should be sequenced so that people can decide which s= +ides of the forks they want to follow and that the economic reality can reo= +rganize around that. If choose to bundle them, you have one of two outcomes= +: either consensus atomizes into a mist where people have different ideas o= +f which subsets of a soft fork bundle they want to adopt, or what likely co= +mes after is a reconvergence on the old client with none of the soft fork r= +ules in place. This will lead to significantly more confusion as well given= + that with sufficient miner consensus some of the rules may stick anyway ev= +en if the rest of the user base reconverges on the old client.</div><div st= +yle=3D"box-sizing:inherit;quotes:"\00201c" "\00201d" &q= +uot;\002018" "\002019";line-height:normal;font-family:arial,= +helvetica,sans-serif;color:rgb(0,0,0)"><br></div><div style=3D"box-sizing:i= +nherit;quotes:"\00201c" "\00201d" "\002018" &= +quot;\002019";line-height:normal;font-family:arial,helvetica,sans-seri= +f;color:rgb(0,0,0)">It is quite likely less damaging to consensus to have f= +requent but strictly sequenced soft forks so that if one of the new rules i= +s contentious the break can happen cleanly. That said, if Core or any other= + client wishes to cut a release of the software with the parameters bundled= + into a single release, that is a significantly=C2=A0more palatable state o= +f affairs, as you can still pipeline signaling and activation. However, the= + protocol itself adopting a tendency to activate unrelated proposals in bun= +dles is a recipe for disaster.</div><div style=3D"box-sizing:inherit;quotes= +:"\00201c" "\00201d" "\002018" "\002019&= +quot;;line-height:normal;font-family:arial,helvetica,sans-serif;color:rgb(0= +,0,0)"><br></div><div style=3D"box-sizing:inherit;quotes:"\00201c"= +; "\00201d" "\002018" "\002019";line-height:n= +ormal;font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br></div><d= +iv style=3D"box-sizing:inherit;quotes:"\00201c" "\00201d&quo= +t; "\002018" "\002019";line-height:normal;font-family:a= +rial,helvetica,sans-serif;color:rgb(0,0,0)">Respectfully,</div><div style= +=3D"box-sizing:inherit;quotes:"\00201c" "\00201d" "= +;\002018" "\002019";line-height:normal;font-family:arial,hel= +vetica,sans-serif;color:rgb(0,0,0)">Keagan</div><div style=3D"box-sizing:in= +herit;quotes:"\00201c" "\00201d" "\002018" &q= +uot;\002019";line-height:normal;font-family:arial,helvetica,sans-serif= +;color:rgb(0,0,0)"><br></div><div style=3D"box-sizing:inherit;quotes:"= +\00201c" "\00201d" "\002018" "\002019";l= +ine-height:normal;font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">= +<br></div><div style=3D"box-sizing:inherit;quotes:"\00201c" "= +;\00201d" "\002018" "\002019";line-height:normal;f= +ont-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">[1]=C2=A0<a href=3D= +"https://www.truthcoin.info/blog/protocol-upgrade-terminology">https://www.= +truthcoin.info/blog/protocol-upgrade-terminology</a></div></div><br><div cl= +ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Oct 16, 2= +021 at 12:57 PM Michael Folkson via bitcoin-dev <<a href=3D"mailto:bitco= +in-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>= +> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px = +0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div= + style=3D"box-sizing:inherit;quotes:"\00201c" "\00201d"= + "\002018" "\002019";line-height:normal;font-style:norm= +al;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;l= +etter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;w= +hite-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-d= +ecoration-style:initial;text-decoration-color:initial;font-family:arial,hel= +vetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span style=3D"box-sizi= +ng:inherit;quotes:"\00201c" "\00201d" "\002018&quo= +t; "\002019";line-height:normal" lang=3D"en"><span style=3D"box-s= +izing:inherit;quotes:"\00201c" "\00201d" "\002018&= +quot; "\002019";line-height:normal"><span style=3D"box-sizing:inh= +erit;quotes:"\00201c" "\00201d" "\002018" &qu= +ot;\002019";line-height:normal">> Interesting discussion.<span>=C2= +=A0</span>Correct me if I'm wrong: but putting too many features togeth= +er in one shot just can't make things harder to debug in production if = +something very unexpected happens.<span>=C2=A0</span><span style=3D"box-siz= +ing:inherit;quotes:"\00201c" "\00201d" "\002018&qu= +ot; "\002019";line-height:normal" lang=3D"en"><span style=3D"box-= +sizing:inherit;quotes:"\00201c" "\00201d" "\002018= +" "\002019";line-height:normal"><span style=3D"box-sizing:in= +herit;quotes:"\00201c" "\00201d" "\002018" &q= +uot;\002019";line-height:normal">It's a basic principle of softwar= +e engineering.</span></span></span></span></span></span><br></div><div styl= +e=3D"box-sizing:inherit;quotes:"\00201c" "\00201d" &quo= +t;\002018" "\002019";line-height:normal;font-style:normal;fo= +nt-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter= +-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-= +space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decora= +tion-style:initial;text-decoration-color:initial;font-family:arial,helvetic= +a,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"box-= +sizing:inherit;quotes:"\00201c" "\00201d" "\002018= +" "\002019";line-height:normal;font-style:normal;font-varian= +t-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:= +normal;text-align:start;text-indent:0px;text-transform:none;white-space:nor= +mal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-styl= +e:initial;text-decoration-color:initial;font-family:arial,helvetica,sans-se= +rif;font-size:small;color:rgb(0,0,0)">Soft fork features can (and should) o= +bviously be tested thoroughly on testnet, signet, custom signets, sidechain= +s etc on a standalone basis and a bundled basis. But whether or not it is a= + basic principle of general software engineering kind of misses the point. = +Security critical software clearly isn't engineered in the same way as = +a new social media app. Bugs are easily reverted in a new social media app.= + A consensus change is extremely hard to revert and probably requires a har= +d fork, a level of central coordination we generally attempt to avoid and a= + speed of deployment that we also attempt to avoid. On top of that we aren&= +#39;t just dealing with security critical software. One of the most importa= +nt objectives is to keep all the nodes on the network in consensus. Introdu= +cing a consensus change before we are comfortable there is community consen= +sus for it is a massive effective bug in itself. The network can split in m= +ultiple ways e.g. part of the network disagrees on whether to activate the = +consensus change, part of the network disagrees on how to resist that conse= +nsus change, part of the network disagrees on how to activate that consensu= +s change etc<br></div><div style=3D"box-sizing:inherit;quotes:"\00201c= +" "\00201d" "\002018" "\002019";line-hei= +ght:normal;font-style:normal;font-variant-ligatures:normal;font-variant-cap= +s:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent= +:0px;text-transform:none;white-space:normal;word-spacing:0px;background-col= +or:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:ini= +tial;font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0= +)"><br></div><div style=3D"box-sizing:inherit;quotes:"\00201c" &q= +uot;\00201d" "\002018" "\002019";line-height:norma= +l;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;= +font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text= +-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(25= +5,255,255);text-decoration-style:initial;text-decoration-color:initial;font= +-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">In add= +ition, a social media app can experiment in production whether Feature A wo= +rks, whether Feature B works or whether Feature A and B work best together.= + In Bitcoin if we activate consensus Feature A, later decide we want consen= +sus Feature B but find out that by previously activating Feature A we can&#= +39;t have Feature B (it is now unsafe to activate it) or its design now has= + to be suboptimal because we have to ensure it can safely work in the prese= +nce of Feature A we have made a mistake by activating Feature A in the firs= +t place. Decentralized security critical consensus changes are an emerging = +field in itself and really can't be treated like any other software pro= +ject. This will become universally understood I'm sure over time.<br></= +div><div style=3D"box-sizing:inherit;quotes:"\00201c" "\0020= +1d" "\002018" "\002019";line-height:normal;font-st= +yle:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weig= +ht:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transfor= +m:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255= +);text-decoration-style:initial;text-decoration-color:initial;font-family:a= +rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div>= +<div></div></div><pre style=3D"box-sizing:inherit;font-size:14px;line-heigh= +t:normal;margin:0px;font-family:SFMono-Regular,Consolas,"Liberation Mo= +no",Menlo,monospace,monospace;white-space:pre-wrap;height:auto;max-wid= +th:100%;quotes:"\00201c" "\00201d" "\002018" = +"\002019";font-style:normal;font-variant-ligatures:normal;font-va= +riant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;te= +xt-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:in= +itial;text-decoration-color:initial;background-color:rgb(255,255,255);color= +:rgb(0,0,0)"><span style=3D"box-sizing:inherit;quotes:"\00201c" &= +quot;\00201d" "\002018" "\002019";line-height:norm= +al"><span style=3D"box-sizing:inherit;quotes:"\00201c" "\002= +01d" "\002018" "\002019";line-height:normal"><span= + style=3D"font-size:14px">-- +</span></span></span>Michael Folkson +Email: michaelfolkson at <a href=3D"http://protonmail.com" target=3D"_blank= +">protonmail.com</a> +Keybase: michaelfolkson +PGP:=C2=A043ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3<br></pre><div><= +br></div><div> + =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Ori= +ginal Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80= +=90<br> + On Friday, October 15th, 2021 at 1:43 AM, Felipe Micaroni Lalli via= + bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t= +arget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> + <blockquote type=3D"cite"> + <div dir=3D"ltr"><div dir=3D"ltr"><div style=3D"font-family:ari= +al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span lang=3D"en"= +><span><span></span></span><span><span>Interesting discussion.</span></span= +><span><span> </span></span><span><span>Correct me if I'm wrong: but pu= +tting too many features together in one shot just can't make things har= +der to debug in production if something very unexpected happens. <span lang= +=3D"en"><span><span>It's a basic principle of software engineering.</sp= +an></span></span></span></span></span></div><div style=3D"font-family:arial= +,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span lang=3D"en"><= +span><span><span lang=3D"en"><span><span><br></span></span></span></span></= +span></span></div><div style=3D"font-family:arial,helvetica,sans-serif;font= +-size:small;color:rgb(0,0,0)"><span lang=3D"en"><span><span><span lang=3D"e= +n"><span><span><span lang=3D"en"><span><span>Change.</span></span> <span><s= +pan>Deploy.</span></span> <span><span>Nothing bad happened?</span></span> <= +span><span>Change it a little more.</span></span> <span><span>Deployment.</= +span></span><span><span><br></span></span></span></span></span></span></spa= +n></span></span></div><div style=3D"font-family:arial,helvetica,sans-serif;= +font-size:small;color:rgb(0,0,0)"><span lang=3D"en"><span><span><span lang= +=3D"en"><span><span><span lang=3D"en"><span><span></span></span><span><span= +>Or:</span></span><span><span> + +</span></span><span><span>Change, change, change.</span></span> Deploy. <sp= +an><span>Did something bad happen?</span></span> <span><span>What change ca= +used the problem?</span></span></span></span></span></span></span></span></= +span></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Oc= +t 14, 2021 at 8:53 PM Anthony Towns via bitcoin-dev <<a href=3D"mailto:b= +itcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer nofollow noopener" = +target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br><= +/div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= +b(204,204,204);padding-left:1ex" class=3D"gmail_quote">On Mon, Oct 11, 2021= + at 12:12:58PM -0700, Jeremy via bitcoin-dev wrote:<br> +> > ...=C2=A0in this post I will argue against frequent soft forks wi= +th a single or<br> +> minimal<br> +> > set of features and instead argue for infrequent soft forks with = +batches<br> +> > of features.<br> +> I think this type of development has been discussed in the past and ha= +s been<br> +> rejected.<br> +<br> +> AJ:=C2=A0- improvements: changes might not make everyone better off, b= +ut we<br> +> =C2=A0 =C2=A0don't want changes to screw anyone over either -- par= +eto<br> +> =C2=A0 =C2=A0improvements in economics, "first, do no harm",= + etc. (if we get this<br> +> =C2=A0 =C2=A0right, there's no need to make compromises and bundle= + multiple<br> +> =C2=A0 =C2=A0flawed proposals so that everyone's an equal mix of h= +appy and<br> +> =C2=A0 =C2=A0miserable)<br> +<br> +I don't think your conclusion above matches my opinion, for what it'= +;s<br> +worth.<br> +<br> +If you've got two features, A and B, where the game theory is:<br> +<br> +=C2=A0If A happens, I'm +100, You're -50<br> +=C2=A0If B happens, I'm -50, You're +100<br> +<br> +then even though A+B is +50, +50, then I do think the answer should<br> +generally be "think harder and come up with better proposals" rat= +her than<br> +"implement A+B as a bundle that makes us both +50".<br> +<br> +_But_ if the two features are more like:<br> +<br> +=C2=A0 If C happens, I'm +100, You're +/- 0<br> +=C2=A0 If D happens, I'm +/- 0, You're +100<br> +<br> +then I don't have a problem with bundling them together as a single<br> +simultaneous activation of both C and D.<br> +<br> +Also, you can have situations where things are better together,<br> +that is:<br> +<br> +=C2=A0 If E happens, we're both at +100<br> +=C2=A0 If F happens, we're both at +50<br> +=C2=A0 If E+F both happen, we're both at +9000<br> +<br> +In general, I think combining proposals when the combination is better<br> +than the individual proposals were is obviously good; and combining<br> +related proposals into a single activation can be good if it is easier<br> +to think about the ideas as a set. <br> +<br> +It's only when you'd be rejecting the proposal on its own merits th= +at<br> +I think combining it with others is a bad idea in principle.<br> +<br> +For specific examples, we bundled schnorr, Taproot, MAST, OP_SUCCESSx<br> +and CHECKSIGADD together because they do have synergies like that; we<br> +didn't bundle ANYPREVOUT and graftroot despite the potential synergies<= +br> +because those features needed substantially more study.<br> +<br> +The nulldummy soft-fork (bip 147) was deployed concurrently with<br> +the segwit soft-fork (bip 141, 143), but I don't think there was any<br= +> +particular synergy or need for those things to be combined, it just<br> +reduced the overhead of two sets of activation signalling to one.<br> +<br> +Note that the implementation code for nulldummy had already been merged<br> +and were applied as relay policy well before activation parameters were<br> +defined (May 2014 via PR#3843 vs Sep 2016 for PR#8636) let alone becoming<b= +r> +an active soft fork.<br> +<br> +Cheers,<br> +aj<br> +<br> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer = +nofollow noopener" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org<= +/a><br> +<a rel=3D"noreferrer nofollow noopener" href=3D"https://lists.linuxfoundati= +on.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://lists.linuxf= +oundation.org/mailman/listinfo/bitcoin-dev</a><br> +</blockquote></div></div> + + </blockquote><br> + </div>_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> + +--00000000000044554e05d4688530-- + + |