path: root/5e/330f14c0058a8515b4b6a665f155aa1c4ff451

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">&gt;=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&#39;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&#39;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">&gt;=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:&quot;\0020=
1c&quot; &quot;\00201d&quot; &quot;\002018&quot; &quot;\002019&quot;;line-h=
eight:normal;font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br><=
/div><div style=3D"box-sizing:inherit;quotes:&quot;\00201c&quot; &quot;\002=
01d&quot; &quot;\002018&quot; &quot;\002019&quot;;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&#39=
;t like the way the opcodes behave, then you just don&#39;t use them. If yo=
u don&#39;t like the reduction of the block subsidy, well that&#39;s a much=
 bigger problem.</div><div style=3D"box-sizing:inherit;quotes:&quot;\00201c=
&quot; &quot;\00201d&quot; &quot;\002018&quot; &quot;\002019&quot;;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:&quot;\00201c&quot; &quot;\00201=
d&quot; &quot;\002018&quot; &quot;\002019&quot;;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:&quot;\00201c&quot; &quot;\00201d&quot; &quot;\00201=
8&quot; &quot;\002019&quot;;line-height:normal;font-family:arial,helvetica,=
sans-serif;color:rgb(0,0,0)"><br></div><div style=3D"box-sizing:inherit;quo=
tes:&quot;\00201c&quot; &quot;\00201d&quot; &quot;\002018&quot; &quot;\0020=
19&quot;;line-height:normal;font-family:arial,helvetica,sans-serif;color:rg=
b(0,0,0)">&gt; 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&quot; &quot;\00201d&quot; &quot;\002018&quot; &quot;\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:&quot;\00201c&quot; &qu=
ot;\00201d&quot; &quot;\002018&quot; &quot;\002019&quot;;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:&quot;\=
00201c&quot; &quot;\00201d&quot; &quot;\002018&quot; &quot;\002019&quot;;li=
ne-height:normal;font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><=
br></div><div style=3D"box-sizing:inherit;quotes:&quot;\00201c&quot; &quot;=
\00201d&quot; &quot;\002018&quot; &quot;\002019&quot;;line-height:normal;fo=
nt-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">&gt; 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:&quot;\00201c&quot; &quot;\00201d&quot; &quot;\002=
018&quot; &quot;\002019&quot;;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:&quot;\00201c&quot; &quot;\00201d&quot; &quot;\002018&quot; &quot;\00=
2019&quot;;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:&quot;\00201c&quot; &quot;\00201d&quot; &q=
uot;\002018&quot; &quot;\002019&quot;;line-height:normal;font-family:arial,=
helvetica,sans-serif;color:rgb(0,0,0)"><br></div><div style=3D"box-sizing:i=
nherit;quotes:&quot;\00201c&quot; &quot;\00201d&quot; &quot;\002018&quot; &=
quot;\002019&quot;;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=
:&quot;\00201c&quot; &quot;\00201d&quot; &quot;\002018&quot; &quot;\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:&quot;\00201c&quot=
; &quot;\00201d&quot; &quot;\002018&quot; &quot;\002019&quot;;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:&quot;\00201c&quot; &quot;\00201d&quo=
t; &quot;\002018&quot; &quot;\002019&quot;;line-height:normal;font-family:a=
rial,helvetica,sans-serif;color:rgb(0,0,0)">Respectfully,</div><div style=
=3D"box-sizing:inherit;quotes:&quot;\00201c&quot; &quot;\00201d&quot; &quot=
;\002018&quot; &quot;\002019&quot;;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:&quot;\00201c&quot; &quot;\00201d&quot; &quot;\002018&quot; &q=
uot;\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:&quot;=
\00201c&quot; &quot;\00201d&quot; &quot;\002018&quot; &quot;\002019&quot;;l=
ine-height:normal;font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">=
<br></div><div style=3D"box-sizing:inherit;quotes:&quot;\00201c&quot; &quot=
;\00201d&quot; &quot;\002018&quot; &quot;\002019&quot;;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 &lt;<a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>=
&gt; 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:&quot;\00201c&quot; &quot;\00201d&quot;=
 &quot;\002018&quot; &quot;\002019&quot;;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:&quot;\00201c&quot; &quot;\00201d&quot; &quot;\002018&quo=
t; &quot;\002019&quot;;line-height:normal" lang=3D"en"><span style=3D"box-s=
izing:inherit;quotes:&quot;\00201c&quot; &quot;\00201d&quot; &quot;\002018&=
quot; &quot;\002019&quot;;line-height:normal"><span style=3D"box-sizing:inh=
erit;quotes:&quot;\00201c&quot; &quot;\00201d&quot; &quot;\002018&quot; &qu=
ot;\002019&quot;;line-height:normal">&gt; Interesting discussion.<span>=C2=
=A0</span>Correct me if I&#39;m wrong: but putting too many features togeth=
er in one shot just can&#39;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:&quot;\00201c&quot; &quot;\00201d&quot; &quot;\002018&qu=
ot; &quot;\002019&quot;;line-height:normal" lang=3D"en"><span style=3D"box-=
sizing:inherit;quotes:&quot;\00201c&quot; &quot;\00201d&quot; &quot;\002018=
&quot; &quot;\002019&quot;;line-height:normal"><span style=3D"box-sizing:in=
herit;quotes:&quot;\00201c&quot; &quot;\00201d&quot; &quot;\002018&quot; &q=
uot;\002019&quot;;line-height:normal">It&#39;s a basic principle of softwar=
e engineering.</span></span></span></span></span></span><br></div><div styl=
e=3D"box-sizing:inherit;quotes:&quot;\00201c&quot; &quot;\00201d&quot; &quo=
t;\002018&quot; &quot;\002019&quot;;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:&quot;\00201c&quot; &quot;\00201d&quot; &quot;\002018=
&quot; &quot;\002019&quot;;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&#39;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:&quot;\00201c=
&quot; &quot;\00201d&quot; &quot;\002018&quot; &quot;\002019&quot;;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:&quot;\00201c&quot; &q=
uot;\00201d&quot; &quot;\002018&quot; &quot;\002019&quot;;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&#39;t be treated like any other software pro=
ject. This will become universally understood I&#39;m sure over time.<br></=
div><div style=3D"box-sizing:inherit;quotes:&quot;\00201c&quot; &quot;\0020=
1d&quot; &quot;\002018&quot; &quot;\002019&quot;;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,&quot;Liberation Mo=
no&quot;,Menlo,monospace,monospace;white-space:pre-wrap;height:auto;max-wid=
th:100%;quotes:&quot;\00201c&quot; &quot;\00201d&quot; &quot;\002018&quot; =
&quot;\002019&quot;;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:&quot;\00201c&quot; &=
quot;\00201d&quot; &quot;\002018&quot; &quot;\002019&quot;;line-height:norm=
al"><span style=3D"box-sizing:inherit;quotes:&quot;\00201c&quot; &quot;\002=
01d&quot; &quot;\002018&quot; &quot;\002019&quot;;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 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t=
arget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; 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&#39;m wrong: but pu=
tting too many features together in one shot just can&#39;t make things har=
der to debug in production if something very unexpected happens. <span lang=
=3D"en"><span><span>It&#39;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 &lt;<a href=3D"mailto:b=
itcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer nofollow noopener" =
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; 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>
&gt; &gt; ...=C2=A0in this post I will argue against frequent soft forks wi=
th a single or<br>
&gt; minimal<br>
&gt; &gt; set of features and instead argue for infrequent soft forks with =
batches<br>
&gt; &gt; of features.<br>
&gt; I think this type of development has been discussed in the past and ha=
s been<br>
&gt; rejected.<br>
<br>
&gt; AJ:=C2=A0- improvements: changes might not make everyone better off, b=
ut we<br>
&gt; =C2=A0 =C2=A0don&#39;t want changes to screw anyone over either -- par=
eto<br>
&gt; =C2=A0 =C2=A0improvements in economics, &quot;first, do no harm&quot;,=
 etc. (if we get this<br>
&gt; =C2=A0 =C2=A0right, there&#39;s no need to make compromises and bundle=
 multiple<br>
&gt; =C2=A0 =C2=A0flawed proposals so that everyone&#39;s an equal mix of h=
appy and<br>
&gt; =C2=A0 =C2=A0miserable)<br>
<br>
I don&#39;t think your conclusion above matches my opinion, for what it&#39=
;s<br>
worth.<br>
<br>
If you&#39;ve got two features, A and B, where the game theory is:<br>
<br>
=C2=A0If A happens, I&#39;m +100, You&#39;re -50<br>
=C2=A0If B happens, I&#39;m -50, You&#39;re +100<br>
<br>
then even though A+B is +50, +50, then I do think the answer should<br>
generally be &quot;think harder and come up with better proposals&quot; rat=
her than<br>
&quot;implement A+B as a bundle that makes us both +50&quot;.<br>
<br>
_But_ if the two features are more like:<br>
<br>
=C2=A0 If C happens, I&#39;m +100, You&#39;re +/- 0<br>
=C2=A0 If D happens, I&#39;m +/- 0, You&#39;re +100<br>
<br>
then I don&#39;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&#39;re both at +100<br>
=C2=A0 If F happens, we&#39;re both at +50<br>
=C2=A0 If E+F both happen, we&#39;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&#39;s only when you&#39;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&#39;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&#39;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--