path: root/b4/d583457ecfb27370068d55da5fb2ea5b64d016

Return-Path: <micaroni3@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D49B2C000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 15 Oct 2021 00:44:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id B684E40395
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 15 Oct 2021 00:44:19 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id t0J4JX97ndZ9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 15 Oct 2021 00:44:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com
 [IPv6:2607:f8b0:4864:20::22b])
 by smtp4.osuosl.org (Postfix) with ESMTPS id A081B4033F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 15 Oct 2021 00:44:18 +0000 (UTC)
Received: by mail-oi1-x22b.google.com with SMTP id u69so10800099oie.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 Oct 2021 17:44:18 -0700 (PDT)
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;
 bh=C4E9JEc09YRE4yINE0wVi+mEklrmUsrzIUf7rMpFxdk=;
 b=irHT2SsEauyth4leCPe0+IvuX7P/VyZ9s9WJ/CcFhjb4ZuBEK8sQ8/DhAlIkLqIGbY
 HsBrcXpT7R44dJzSoqxZbJ26XICX2ud8lcUtgI8NaFF3PBqvEqLX011fXeM6JEJWLfUE
 qsYcDU0k52E+dHIEcRRJzKG+K2wFLDDwCMw6ayaPc+Y5YRS1MVFlKTjRUbx5s65WXIyO
 S8INFW2HP8BApk6G4KaA/lXh2T4jwm9CoERavwx+rAxphIE9gfxqSzW1QQnsH7X4W7q2
 CnF4S192YNyNlQVzWsGGqAyGi38bJbqf7ThaYa9A82O4uXVMcUzwkQ7VY106fd6n2Ujj
 0gcA==
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;
 bh=C4E9JEc09YRE4yINE0wVi+mEklrmUsrzIUf7rMpFxdk=;
 b=tb7x2JhjAgQNG8SND44SNxgVr6c5Kz920s05AqjiidfynsVzDK26vgjUsYiLzPV+t8
 uyxll+rf7y4pJoKGAWrLfpnALv5oJEMpO/LOQQIqKnziyqZVvZou4X5KgBI/OzDaEWhW
 Ms4vPLU8clyTm7QOYz/vnr6/w0zkFHkCjwgmqY9CUmYT8cCIjWDTcqsFZWyGskYeugZ4
 x3oz/f+34vl51MAcjtE8uBec7THvasi1cA5yoZeCTxy8FESz5hZEqbkWhOnnDhmbLdNs
 ZddFQFUL2vYmv1LXOM2zIFU65ZRlRl0O4kS1SQgJjGfqnUkom1XLaPoWd/QpQdIzFEN7
 ARcw==
X-Gm-Message-State: AOAM530OmYESg2h+VCf1GPrYszel82t4SfPp2ICg5Dhz/fgDJ4hqQ/Y8
 /rCBU+OBZVQJbc63FIbrgbYdIdwoMK2XTzznDKHjAZPUv+A=
X-Google-Smtp-Source: ABdhPJwV6EieRFfN1HZl4FS5zsZLtaTvBi7FiBgYP3rR/iGUbNPg9WavF2qAnm+99YASZ03ZRyXGn7r0b0o0RxuVqd4=
X-Received: by 2002:a05:6808:1984:: with SMTP id
 bj4mr6564873oib.30.1634258657538; 
 Thu, 14 Oct 2021 17:44:17 -0700 (PDT)
MIME-Version: 1.0
References: <LmX3Gnfkf1T0Eb_wUXxPe8c0Tf2DNipfIqufkRS6oOPhttr4iZIOWtjUL_7QkcWEHr8eFvehHooaM140ZBKLwi98F5NwyQKSyEhAPZDK1YQ=@protonmail.com>
 <CAD5xwhj3JCxH1=5Tj+hgiSxLWchLgT584X0YutKVeuibnpwmtA@mail.gmail.com>
 <20211014235207.GB6451@erisian.com.au>
In-Reply-To: <20211014235207.GB6451@erisian.com.au>
From: micaroni@gmail.com
Date: Thu, 14 Oct 2021 21:43:40 -0300
Message-ID: <CAHvMVPQ8jtfdbLg8NJv7bNM3a_nhF_aUfD2gwSdxpfgXQomn3A@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c0f74d05ce597e46"
X-Mailman-Approved-At: Fri, 15 Oct 2021 22:48:22 +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, 15 Oct 2021 00:44:19 -0000

--000000000000c0f74d05ce597e46
Content-Type: text/plain; charset="UTF-8"

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 has
> 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 this
> >    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 than
> "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 becoming
> an active soft fork.
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000c0f74d05ce597e46
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><span cl=
ass=3D"gmail-VIiyi" lang=3D"en"><span class=3D"gmail-JLqJ4b gmail-ChMk0b"><=
span></span></span><span class=3D"gmail-JLqJ4b gmail-ChMk0b"><span>Interest=
ing discussion.</span></span><span class=3D"gmail-JLqJ4b"><span> </span></s=
pan><span class=3D"gmail-JLqJ4b gmail-ChMk0b"><span>Correct me if I&#39;m w=
rong: but putting too many features together in one shot just can&#39;t mak=
e things harder to debug in production if something very unexpected happens=
. <span class=3D"gmail-VIiyi" lang=3D"en"><span class=3D"gmail-JLqJ4b gmail=
-ChMk0b"><span>It&#39;s a basic principle of software engineering.</span></=
span></span></span></span></span></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><=
span class=3D"gmail-VIiyi" lang=3D"en"><span class=3D"gmail-JLqJ4b gmail-Ch=
Mk0b"><span><span class=3D"gmail-VIiyi" lang=3D"en"><span class=3D"gmail-JL=
qJ4b gmail-ChMk0b"><span><br></span></span></span></span></span></span></di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:#000000"><span class=3D"gmail-VIiyi" lang=3D"en">=
<span class=3D"gmail-JLqJ4b gmail-ChMk0b"><span><span class=3D"gmail-VIiyi"=
 lang=3D"en"><span class=3D"gmail-JLqJ4b gmail-ChMk0b"><span><span class=3D=
"gmail-VIiyi" lang=3D"en"><span class=3D"gmail-JLqJ4b gmail-ChMk0b"><span>C=
hange.</span></span> <span class=3D"gmail-JLqJ4b gmail-ChMk0b"><span>Deploy=
.</span></span> <span class=3D"gmail-JLqJ4b gmail-ChMk0b"><span>Nothing bad=
 happened?</span></span> <span class=3D"gmail-JLqJ4b gmail-ChMk0b"><span>Ch=
ange it a little more.</span></span> <span class=3D"gmail-JLqJ4b gmail-ChMk=
0b"><span>Deployment.</span></span><span class=3D"gmail-JLqJ4b"><span><br><=
/span></span></span></span></span></span></span></span></span></div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:#000000"><span class=3D"gmail-VIiyi" lang=3D"en"><span cla=
ss=3D"gmail-JLqJ4b gmail-ChMk0b"><span><span class=3D"gmail-VIiyi" lang=3D"=
en"><span class=3D"gmail-JLqJ4b gmail-ChMk0b"><span><span class=3D"gmail-VI=
iyi" lang=3D"en"><span class=3D"gmail-JLqJ4b"><span></span></span><span cla=
ss=3D"gmail-JLqJ4b gmail-ChMk0b"><span>Or:</span></span><span class=3D"gmai=
l-JLqJ4b"><span>

</span></span><span class=3D"gmail-JLqJ4b gmail-ChMk0b"><span>Change, chang=
e, change.</span></span> Deploy. <span class=3D"gmail-JLqJ4b gmail-ChMk0b">=
<span>Did something bad happen?</span></span> <span class=3D"gmail-JLqJ4b g=
mail-ChMk0b"><span>What change caused the problem?</span></span></span></sp=
an></span></span></span></span></span></div></div><br><div class=3D"gmail_q=
uote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Oct 14, 2021 at 8:53 PM=
 Anthony Towns via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">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" 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></div>

--000000000000c0f74d05ce597e46--