Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id D49B2C000D for ; 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 ; 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 ; 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 ; Fri, 15 Oct 2021 00:44:18 +0000 (UTC) Received: by mail-oi1-x22b.google.com with SMTP id u69so10800099oie.3 for ; 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: <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: To: Anthony Towns , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
<= span>Interest= ing discussion. Correct me if I'm w= rong: but putting too many features together in one shot just can't mak= e things harder to debug in production if something very unexpected happens= . It's a basic principle of software engineering.
<= span class=3D"gmail-VIiyi" lang=3D"en">
= C= hange. Deploy= . Nothing bad= happened? Ch= ange it a little more. Deployment.
<= /span>
Or: Change, chang= e, 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:
> > ...=C2=A0in this post I will argue against frequent soft forks wi= th 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:=C2=A0- improvements: changes might not make everyone better off, b= ut we
> =C2=A0 =C2=A0don't want changes to screw anyone over either -- par= eto
> =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= multiple
> =C2=A0 =C2=A0flawed proposals so that everyone's an equal mix of h= appy 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" rat= her 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 th= at
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<= br> 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/mail= man/listinfo/bitcoin-dev
--000000000000c0f74d05ce597e46--