path: root/8f/2dba55192615a93244e4383325df3b8bad18e8

Return-Path: <vjudeu@gazeta.pl>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D4123C001E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  1 Jan 2022 15:45:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 95C5F8144B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  1 Jan 2022 15:45:26 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.856
X-Spam-Level: 
X-Spam-Status: No, score=-0.856 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, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=gazeta.pl
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id y7L95cTSLTsq
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  1 Jan 2022 15:45:24 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtpo41.poczta.onet.pl (smtpo116.poczta.onet.pl
 [213.180.149.169])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 0B0EA81446
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  1 Jan 2022 15:45:23 +0000 (UTC)
Received: from pmq4v.m5r2.onet (pmq4v.m5r2.onet [10.174.32.70])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4JR5tg0S3FzljCpM;
 Sat,  1 Jan 2022 16:45:15 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
 t=1641051915; bh=WpeSeyjBnqFSZ8olZOyRQtu1pJqbwaDAyEftE+ac1u0=;
 h=From:To:Date:Subject:From;
 b=OTI6dibRBNxzZYnCdblD1w2dZqX4PxriJpEt8bUQbs9jCgJhqeQCGdkCEdYp4Fv9z
 XHmtbvUTdE7tr58z/PR4XX3F9rAZ1AP/QAKEADpiwhzTsLyhlFc8WWgX3xZXuk2b1m
 zAKp7PhRCBPSKFD7FY9FnARUxpGiEUDjXxmAgEQU=
Content-Type: multipart/alternative;
 boundary="===============1490301051660604798=="
MIME-Version: 1.0
Received: from [5.173.249.98] by pmq4v.m5r2.onet via HTTP id ;
 Sat, 01 Jan 2022 16:45:15 +0100
From: vjudeu@gazeta.pl
X-Priority: 3
To: Keagan McClelland <keagan.mcclelland@gmail.com>,
 Michael Folkson <michaelfolkson@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Date: Sat, 01 Jan 2022 16:45:11 +0100
Message-Id: <151636693-b9baa24a337b74e4b019a92e12c81eff@pmq4v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.249.98;PL;3
X-Mailman-Approved-At: Sat, 01 Jan 2022 15:59: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: Sat, 01 Jan 2022 15:45:26 -0000

This is a multi-part message in MIME format.
--===============1490301051660604798==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

> If you don't like the reduction of the block subsidy, well that's a much =
bigger problem.
It is reversible, because you can also increase the block subsidy by using =
another kind of soft-fork. For example, you can create spendable outputs wi=
th zero satoshis. In this way, old nodes will accept that silently, but new=
 nodes can check something more, because you can specify somewhere else, wh=
at is the "real" amount. Finally, if all nodes will upgrade, you will end u=
p in a network, where all transactions spend zero satoshi inputs, create ze=
ro satoshi outputs and have zero fee. Old nodes would accept all of that, b=
ut new nodes would really see, what is going on, and they will check that a=
ll rules are met, and the new subsidy is for example increased x1000 (that =
could lead to the same situation as moving from satoshis to millisatoshis w=
ith some hard-fork, but doing that kind of change with a soft-fork is safer=
).
On 2021-12-31 10:35:06 user Keagan McClelland via bitcoin-dev <bitcoin-dev@=
lists.linuxfoundation.org> wrote:
>=C2=A0=C2=A0But whether or not it is a basic principle of general software=
 engineering kind of misses the point. Security critical software clearly i=
sn'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 wi=
th security critical software. One of the most important objectives is to k=
eep all the nodes on the network in consensus. Introducing a consensus chan=
ge before we are comfortable there is community consensus for it is a massi=
ve effective bug in itself. The network can split in multiple ways e.g. par=
t of the network disagrees on whether to activate the consensus change, par=
t of the network disagrees on how to resist that consensus change, part of =
the network disagrees on how to activate that consensus change etc
=C2=A0
>=C2=A0=C2=A0A consensus change is extremely hard to revert and probably re=
quires a hard fork, a level of central coordination we generally attempt to=
 avoid and a speed of deployment that we also attempt to avoid.
=C2=A0
This seems to assert the idea that soft forks are all the same: they are no=
t. For instance a soft fork, lowering the block subsidy is completely diffe=
rent than changing the semantics of an OP_NOP to have semantics that may re=
ject a subset of the witnesses that attest to the transactions permissibili=
ty. As a result, reversion means two entirely different things in these con=
texts. 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 r=
evert 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.
=C2=A0
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. h=
ard distinction is a critical one but it is not enough and treating soft fo=
rks 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 neces=
sarily complete, they admit the low resolution of our current terminology.
=C2=A0
> Soft fork features can (and should) obviously be tested thoroughly on tes=
tnet, signet, custom signets, sidechains etc on a standalone basis and a bu=
ndled basis.
=C2=A0
I vehemently disagree that any consensus changes should be bundled, especia=
lly 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. A=
s the Bitcoin project scales, the ability of any one developer to understan=
d the entire codebase declines. Bundling changes reduces the number of peop=
le who are qualified to review a particular proposal, and even worse, intim=
idates people who may be willing and able to review logically distinct port=
ions of the proposal, resulting in lower amounts of review overall. This wi=
ll likely have the opposite effect of what you seem to desire. BIP8 and BIP=
9 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 hav=
e to. Bundling them will inevitably degenerate into political horse trading=
 and everyone will be worse off for it.
=C2=A0
> part of the network disagrees on whether to activate the consensus change=
, part of the network disagrees on how to resist that consensus change, par=
t of the network disagrees on how to activate that consensus change etc
=C2=A0
Disagreements, and by extension, forks are a part of Bitcoin. What is impor=
tant is that they are well defined and clean. This is the reason why the ma=
ndatory signaling period exists in BIP8/9, so that clients that intend to r=
eject the soft fork change have a very easy means of doing so in a clean br=
eak where consensus is clearly divergent. In accordance with this, consensu=
s 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 arou=
nd that. If choose to bundle them, you have one of two outcomes: either con=
sensus atomizes into a mist where people have different ideas of which subs=
ets 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 plac=
e. This will lead to significantly more confusion as well given that with s=
ufficient miner consensus some of the rules may stick anyway even if the re=
st of the user base reconverges on the old client.
=C2=A0
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 br=
eak can happen cleanly. That said, if Core or any other client wishes to cu=
t a release of the software with the parameters bundled into a single relea=
se, that is a significantly=C2=A0more palatable state of affairs, as you ca=
n still pipeline signaling and activation. However, the protocol itself ado=
pting a tendency to activate unrelated proposals in bundles is a recipe for=
 disaster.
=C2=A0
=C2=A0
Respectfully,
Keagan
=C2=A0
=C2=A0
[1]=C2=A0https://www.truthcoin.info/blog/protocol-upgrade-terminology
On Sat, Oct 16, 2021 at 12:57 PM Michael Folkson via bitcoin-dev <bitcoin-d=
ev@lists.linuxfoundation.org> wrote:
> Interesting discussion.=C2=A0Correct me if I'm wrong: but putting too man=
y features together in one shot just can't make things harder to debug in p=
roduction if something very unexpected happens.=C2=A0It's a basic principle=
 of software engineering.
=C2=A0
Soft fork features can (and should) obviously be tested thoroughly on testn=
et, signet, custom signets, sidechains etc on a standalone basis and a bund=
led basis. But whether or not it is a basic principle of general software e=
ngineering 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 re=
verted in a new social media app. A consensus change is extremely hard to r=
evert 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 soft=
ware. One of the most important objectives is to keep all the nodes on the =
network in consensus. Introducing a consensus change before we are comforta=
ble there is community consensus for it is a massive effective bug in itsel=
f. The network can split in multiple ways e.g. part of the network disagree=
s on whether to activate the consensus change, part of the network disagree=
s on how to resist that consensus change, part of the network disagrees on =
how to activate that consensus change etc
=C2=A0
In addition, a social media app can experiment in production whether Featur=
e A works, whether Feature B works or whether Feature A and B work best tog=
ether. In Bitcoin if we activate consensus Feature A, later decide 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 its design now h=
as to be suboptimal because we have to ensure it can safely work in the pre=
sence of Feature A we have made a mistake by activating Feature A in the fi=
rst place. Decentralized security critical consensus changes are an emergin=
g field in itself and really can't be treated like any other software proje=
ct. This will become universally understood I'm sure over time.
=C2=A0
=C2=A0
-- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michael=
folkson PGP:=C2=A043ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
=C2=A0
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =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 featu=
res together in one shot just can't make things harder to debug in producti=
on if something very unexpected happens. It's a basic principle of software=
 engineering.
=C2=A0
Change. Deploy. Nothing bad happened? Change it a little more. Deployment.
Or: Change, change, change. Deploy. Did something bad happen? What change c=
aused 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:
> > ...=C2=A0in this post I will argue against frequent soft forks with a s=
ingle 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 has b=
een
> rejected.
> AJ:=C2=A0- improvements: changes might not make everyone better off, but =
we
> =C2=A0 =C2=A0don't want changes to screw anyone over either -- pareto
> =C2=A0 =C2=A0improvements in economics, "first, do no harm", etc. (if we =
get this
> =C2=A0 =C2=A0right, there's no need to make compromises and bundle multip=
le
> =C2=A0 =C2=A0flawed proposals so that everyone's an equal mix of happy and
> =C2=A0 =C2=A0miserable)
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:
=C2=A0If A happens, I'm +100, You're -50
=C2=A0If 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 than
"implement A+B as a bundle that makes us both +50".
_But_ if the two features are more like:
=C2=A0 If C happens, I'm +100, You're +/- 0
=C2=A0 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:
=C2=A0 If E happens, we're both at +100
=C2=A0 If F happens, we're both at +50
=C2=A0 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 becoming
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
--===============1490301051660604798==
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<div>&gt; If you don't like the reduction of the block subsidy, well that's=
 a much bigger problem.<br /><br />It is reversible, because you can also i=
ncrease the block subsidy by using another kind of soft-fork. For example, =
you can create spendable outputs with zero satoshis. In this way, old nodes=
 will accept that silently, but new nodes can check something more, because=
 you can specify somewhere else, what is the "real" amount. Finally, if all=
 nodes will upgrade, you will end up in a network, where all transactions s=
pend zero satoshi inputs, create zero satoshi outputs and have zero fee. Ol=
d nodes would accept all of that, but new nodes would really see, what is g=
oing on, and they will check that all rules are met, and the new subsidy is=
 for example increased x1000 (that could lead to the same situation as movi=
ng from satoshis to millisatoshis with some hard-fork, but doing that kind =
of change with a soft-fork is safer).<br /><br /></div>
<div>On 2021-12-31 10:35:06 user Keagan McClelland via bitcoin-dev &lt;bitc=
oin-dev@lists.linuxfoundation.org&gt; wrote:</div>
<blockquote style=3D"margin-left: 7px; border-left: 2px solid orange; paddi=
ng-left: 8px;">
<div dir=3D"ltr">&gt;&nbsp;<span style=3D"color: #000000; font-family: aria=
l,helvetica,sans-serif;">&nbsp;But whether or not it is a basic principle o=
f 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. Introducin=
g 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 mult=
iple ways e.g. part of the network disagrees on whether to activate the con=
sensus change, part of the network disagrees on how to resist that consensu=
s change, part of the network disagrees on how to activate that consensus c=
hange etc</span>
<div><span style=3D"color: #000000;">&nbsp;</span></div>
<div><span style=3D"color: #000000;">&gt;&nbsp;</span><span style=3D"color:=
 #000000; font-family: arial,helvetica,sans-serif;">&nbsp;A consensus chang=
e 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 deployme=
nt that we also attempt to avoid.</span><span style=3D"color: #000000;"><br=
 /></span>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-family: arial,helvetica,sans-serif; colo=
r: #000000;">&nbsp;</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-family: arial,helvetica,sans-serif; colo=
r: #000000;">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 com=
pletely different than changing the semantics of an OP_NOP to have semantic=
s 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 defin=
ition a hard fork, the requirement of reversion as a result of undesired be=
havior is not the same. In the case of opcodes, there is almost never a req=
uirement to revert it. If you don't like the way the opcodes behave, then y=
ou just don't use them. If you don't like the reduction of the block subsid=
y, well that's a much bigger problem.</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-family: arial,helvetica,sans-serif; colo=
r: #000000;">&nbsp;</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-family: arial,helvetica,sans-serif; colo=
r: #000000;">I make this point to elucidate the idea that we cannot treat S=
oftForks&trade; as a single monolithic idea. Perhaps we need to come up wit=
h better terminology to be specific about what each fork actually is. The s=
oft vs. hard distinction is a critical one but it is not enough and treatin=
g 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 term=
inology.</div>
</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-family: arial,helvetica,sans-serif; colo=
r: #000000;">&nbsp;</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-family: arial,helvetica,sans-serif; colo=
r: #000000;">&gt; Soft fork features can (and should) obviously be tested t=
horoughly on testnet, signet, custom signets, sidechains etc on a standalon=
e basis and a bundled basis.</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-family: arial,helvetica,sans-serif; colo=
r: #000000;">&nbsp;</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-family: arial,helvetica,sans-serif; colo=
r: #000000;">I vehemently disagree that any consensus changes should be bun=
dled, especially when it comes to activation parameters. When we start to b=
undle things, we amplify the community resources needed to do review, not r=
educe them. I suspect your opinion here is largely informed by your frustra=
tion 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 significan=
tly harder. As the Bitcoin project scales, the ability of any one developer=
 to understand the entire codebase declines. Bundling changes reduces the n=
umber 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 ove=
rall. 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.</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-family: arial,helvetica,sans-serif; colo=
r: #000000;">&nbsp;</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-family: arial,helvetica,sans-serif; colo=
r: #000000;">&gt; 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</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-family: arial,helvetica,sans-serif; colo=
r: #000000;">&nbsp;</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-family: arial,helvetica,sans-serif; colo=
r: #000000;">Disagreements, and by extension, forks are a part of Bitcoin. =
What is important is that they are well defined and clean. This is the reas=
on why the mandatory signaling period exists in BIP8/9, so that clients tha=
t 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 t=
his, 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 re=
organize around that. If choose to bundle them, you have one of two outcome=
s: 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 c=
omes 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 give=
n that with sufficient miner consensus some of the rules may stick anyway e=
ven if the rest of the user base reconverges on the old client.</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-family: arial,helvetica,sans-serif; colo=
r: #000000;">&nbsp;</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-family: arial,helvetica,sans-serif; colo=
r: #000000;">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 conte=
ntious 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&nbsp;more palatable state of affai=
rs, as you can still pipeline signaling and activation. However, the protoc=
ol itself adopting a tendency to activate unrelated proposals in bundles is=
 a recipe for disaster.</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-family: arial,helvetica,sans-serif; colo=
r: #000000;">&nbsp;</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-family: arial,helvetica,sans-serif; colo=
r: #000000;">&nbsp;</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-family: arial,helvetica,sans-serif; colo=
r: #000000;">Respectfully,</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-family: arial,helvetica,sans-serif; colo=
r: #000000;">Keagan</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-family: arial,helvetica,sans-serif; colo=
r: #000000;">&nbsp;</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-family: arial,helvetica,sans-serif; colo=
r: #000000;">&nbsp;</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-family: arial,helvetica,sans-serif; colo=
r: #000000;">[1]&nbsp;<a href=3D"https://www.truthcoin.info/blog/protocol-u=
pgrade-terminology" target=3D"_blank" rel=3D"noopener">https://www.truthcoi=
n.info/blog/protocol-upgrade-terminology</a></div>
</div>
<br />
<div class=3D"gmail_quote">
<div class=3D"gmail_attr" dir=3D"ltr">On Sat, Oct 16, 2021 at 12:57 PM Mich=
ael Folkson via bitcoin-dev &lt;<a href=3D"../NowaWiadomosc/Do/QlIkBFQ6QUFh=
IVRZX192dnQBeCtCchE6GhA5LFpLCUc7EVZQVl9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVV=
DEyBdVkE9JVRdEwFhYXVlblhVIkosEAszLR5BQVV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXR=
QUQUoDQlAiBFY8" target=3D"_parent">bitcoin-dev@lists.linuxfoundation.org</a=
>&gt; wrote:</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left: 1px solid #cccccc; padding-left: 1ex;">
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-style: normal; font-variant-ligatures: n=
ormal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal;=
 text-align: start; text-indent: 0px; text-transform: none; white-space: no=
rmal; word-spacing: 0px; background-color: #ffffff; text-decoration-style: =
initial; text-decoration-color: initial; font-family: arial,helvetica,sans-=
serif; font-size: small; color: #000000;"><span lang=3D"en" style=3D"box-si=
zing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&rsquo;'; line-height=
: normal;"><span style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' =
'&lsquo;' '&rsquo;'; line-height: normal;"><span style=3D"box-sizing: inher=
it; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&rsquo;'; line-height: normal;">=
&gt; Interesting discussion.&nbsp;Correct me if I'm wrong: but putting too =
many features together in one shot just can't make things harder to debug i=
n production if something very unexpected happens.&nbsp;<span lang=3D"en" s=
tyle=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&rsquo;=
'; line-height: normal;"><span style=3D"box-sizing: inherit; quotes: '&ldqu=
o;' '&rdquo;' '&lsquo;' '&rsquo;'; line-height: normal;"><span style=3D"box=
-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&rsquo;'; line-hei=
ght: normal;">It's a basic principle of software engineering.</span></span>=
</span></span></span></span></div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-style: normal; font-variant-ligatures: n=
ormal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal;=
 text-align: start; text-indent: 0px; text-transform: none; white-space: no=
rmal; word-spacing: 0px; background-color: #ffffff; text-decoration-style: =
initial; text-decoration-color: initial; font-family: arial,helvetica,sans-=
serif; font-size: small; color: #000000;">&nbsp;</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-style: normal; font-variant-ligatures: n=
ormal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal;=
 text-align: start; text-indent: 0px; text-transform: none; white-space: no=
rmal; word-spacing: 0px; background-color: #ffffff; text-decoration-style: =
initial; text-decoration-color: initial; font-family: arial,helvetica,sans-=
serif; font-size: small; color: #000000;">Soft fork features can (and shoul=
d) obviously be tested thoroughly on testnet, signet, custom signets, sidec=
hains 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 poi=
nt. 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'=
t just dealing with security critical software. One of the most important o=
bjectives 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 multi=
ple ways e.g. part of the network disagrees on whether to activate the cons=
ensus change, part of the network disagrees on how to resist that consensus=
 change, part of the network disagrees on how to activate that consensus ch=
ange etc</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-style: normal; font-variant-ligatures: n=
ormal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal;=
 text-align: start; text-indent: 0px; text-transform: none; white-space: no=
rmal; word-spacing: 0px; background-color: #ffffff; text-decoration-style: =
initial; text-decoration-color: initial; font-family: arial,helvetica,sans-=
serif; font-size: small; color: #000000;">&nbsp;</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-style: normal; font-variant-ligatures: n=
ormal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal;=
 text-align: start; text-indent: 0px; text-transform: none; white-space: no=
rmal; word-spacing: 0px; background-color: #ffffff; text-decoration-style: =
initial; text-decoration-color: initial; font-family: arial,helvetica,sans-=
serif; font-size: small; color: #000000;">In addition, a social media app c=
an experiment in production whether Feature A works, whether Feature B work=
s or whether Feature A and B work best together. In Bitcoin if we activate =
consensus Feature A, later decide 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 its design now has to be suboptimal because we ha=
ve 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.</div>
<div style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&=
rsquo;'; line-height: normal; font-style: normal; font-variant-ligatures: n=
ormal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal;=
 text-align: start; text-indent: 0px; text-transform: none; white-space: no=
rmal; word-spacing: 0px; background-color: #ffffff; text-decoration-style: =
initial; text-decoration-color: initial; font-family: arial,helvetica,sans-=
serif; font-size: small; color: #000000;">&nbsp;</div>
<div>
<div>&nbsp;</div>
</div>
<pre style=3D"box-sizing: inherit; font-size: 14px; line-height: normal; ma=
rgin: 0px; font-family: SFMono-Regular,Consolas,'Liberation Mono',Menlo,mon=
ospace,monospace; white-space: pre-wrap; height: auto; max-width: 100%; quo=
tes: '&ldquo;' '&rdquo;' '&lsquo;' '&rsquo;'; font-style: normal; font-vari=
ant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-=
spacing: normal; text-align: start; text-indent: 0px; text-transform: none;=
 word-spacing: 0px; text-decoration-style: initial; text-decoration-color: =
initial; background-color: #ffffff; color: #000000;"><span style=3D"box-siz=
ing: inherit; quotes: '&ldquo;' '&rdquo;' '&lsquo;' '&rsquo;'; line-height:=
 normal;"><span style=3D"box-sizing: inherit; quotes: '&ldquo;' '&rdquo;' '=
&lsquo;' '&rsquo;'; 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=
" rel=3D"noopener">protonmail.com</a>
Keybase: michaelfolkson
PGP:&nbsp;43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3</pre>
<div>&nbsp;</div>
<div>=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origin=
al 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 bi=
tcoin-dev &lt;<a href=3D"../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCch=
E6GhA5LFpLCUc7EVZQVl9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVDEyBdVkE9JVRdEwFhY=
XVlblhVIkosEAszLR5BQVV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQUQUoDQlAiBFY8" ta=
rget=3D"_parent">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br />
<blockquote>
<div dir=3D"ltr">
<div dir=3D"ltr">
<div style=3D"font-family: arial,helvetica,sans-serif; font-size: small; co=
lor: #000000;"><span lang=3D"en">Interesting discussion. Correct me if I'm =
wrong: but putting too many features together in one shot just can't make t=
hings harder to debug in production if something very unexpected happens. <=
span lang=3D"en">It's a basic principle of software engineering.</span></sp=
an></div>
<div style=3D"font-family: arial,helvetica,sans-serif; font-size: small; co=
lor: #000000;"><span lang=3D"en"><span lang=3D"en">&nbsp;</span></span></di=
v>
<div style=3D"font-family: arial,helvetica,sans-serif; font-size: small; co=
lor: #000000;"><span lang=3D"en"><span lang=3D"en"><span lang=3D"en">Change=
. Deploy. Nothing bad happened? Change it a little more. Deployment.<br /><=
/span></span></span></div>
<div style=3D"font-family: arial,helvetica,sans-serif; font-size: small; co=
lor: #000000;"><span lang=3D"en"><span lang=3D"en"><span lang=3D"en">Or: Ch=
ange, change, change. Deploy. Did something bad happen? What change caused =
the problem?</span></span></span></div>
</div>
<br />
<div class=3D"gmail_quote">
<div dir=3D"ltr">On Thu, Oct 14, 2021 at 8:53 PM Anthony Towns via bitcoin-=
dev &lt;<a href=3D"../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchE6GhA5=
LFpLCUc7EVZQVl9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVDEyBdVkE9JVRdEwFhYXVlblh=
VIkosEAszLR5BQVV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQUQUoDQlAiBFY8" target=
=3D"_parent" rel=3D"noreferrer nofollow noopener">bitcoin-dev@lists.linuxfo=
undation.org</a>&gt; wrote:</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left: 1px solid #cccccc; padding-left: 1ex;">On Mon, Oct 11, 2021 at 12:1=
2:58PM -0700, Jeremy via bitcoin-dev wrote:<br />&gt; &gt; ...&nbsp;in this=
 post I will argue against frequent soft forks with a single or<br />&gt; m=
inimal<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 has been<br />&gt; rejec=
ted.<br /><br />&gt; AJ:&nbsp;- improvements: changes might not make everyo=
ne better off, but we<br />&gt; &nbsp; &nbsp;don't want changes to screw an=
yone over either -- pareto<br />&gt; &nbsp; &nbsp;improvements in economics=
, "first, do no harm", etc. (if we get this<br />&gt; &nbsp; &nbsp;right, t=
here's no need to make compromises and bundle multiple<br />&gt; &nbsp; &nb=
sp;flawed proposals so that everyone's an equal mix of happy and<br />&gt; =
&nbsp; &nbsp;miserable)<br /><br />I don't think your conclusion above matc=
hes my opinion, for what it's<br />worth.<br /><br />If you've got two feat=
ures, A and B, where the game theory is:<br /><br />&nbsp;If A happens, I'm=
 +100, You're -50<br />&nbsp;If 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 />ge=
nerally be "think harder and come up with better proposals" rather than<br =
/>"implement A+B as a bundle that makes us both +50".<br /><br />_But_ if t=
he two features are more like:<br /><br />&nbsp; If C happens, I'm +100, Yo=
u're +/- 0<br />&nbsp; 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 />simult=
aneous activation of both C and D.<br /><br />Also, you can have situations=
 where things are better together,<br />that is:<br /><br />&nbsp; If E hap=
pens, we're both at +100<br />&nbsp; If F happens, we're both at +50<br />&=
nbsp; If E+F both happen, we're both at +9000<br /><br />In general, I thin=
k combining proposals when the combination is better<br />than the individu=
al proposals were is obviously good; and combining<br />related proposals i=
nto 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 that<br />I think combining it with others is a bad idea=
 in principle.<br /><br />For specific examples, we bundled schnorr, Taproo=
t, MAST, OP_SUCCESSx<br />and CHECKSIGADD together because they do have syn=
ergies like that; we<br />didn't bundle ANYPREVOUT and graftroot despite th=
e potential synergies<br />because those features needed substantially more=
 study.<br /><br />The nulldummy soft-fork (bip 147) was deployed concurren=
tly 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 be=
en merged<br />and were applied as relay policy well before activation para=
meters were<br />defined (May 2014 via PR#3843 vs Sep 2016 for PR#8636) let=
 alone becoming<br />an active soft fork.<br /><br />Cheers,<br />aj<br /><=
br />_______________________________________________<br />bitcoin-dev maili=
ng list<br /><a href=3D"../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchE=
6GhA5LFpLCUc7EVZQVl9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVDEyBdVkE9JVRdEwFhYX=
VlblhVIkosEAszLR5BQVV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQUQUoDQlAiBFY8" tar=
get=3D"_parent" rel=3D"noreferrer nofollow noopener">bitcoin-dev@lists.linu=
xfoundation.org</a><br /><a href=3D"https://lists.linuxfoundation.org/mailm=
an/listinfo/bitcoin-dev" target=3D"_blank" rel=3D"noreferrer nofollow noope=
ner">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></bl=
ockquote>
</div>
</div>
</blockquote>
</div>
_______________________________________________<br />bitcoin-dev mailing li=
st<br /><a href=3D"../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchE6GhA5=
LFpLCUc7EVZQVl9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVDEyBdVkE9JVRdEwFhYXVlblh=
VIkosEAszLR5BQVV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQUQUoDQlAiBFY8" target=
=3D"_parent">bitcoin-dev@lists.linuxfoundation.org</a><br /><a href=3D"http=
s://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blan=
k" rel=3D"noopener noreferrer">https://lists.linuxfoundation.org/mailman/li=
stinfo/bitcoin-dev</a></blockquote>
</div>
</blockquote>

--===============1490301051660604798==--