Re: [bitcoin-dev] On the regularity of soft forks

From: micaroni@gmail•com
To: Anthony Towns <aj@erisian•com.au>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] On the regularity of soft forks
Date: Thu, 14 Oct 2021 21:43:40 -0300	[thread overview]
Message-ID: <CAHvMVPQ8jtfdbLg8NJv7bNM3a_nhF_aUfD2gwSdxpfgXQomn3A@mail.gmail.com> (raw)
In-Reply-To: <20211014235207.GB6451@erisian.com.au>

[-- Attachment #1: Type: text/plain, Size: 3532 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 6660 bytes --]