Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6C11AC000D for ; Mon, 11 Oct 2021 19:13:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 57C2940358 for ; Mon, 11 Oct 2021 19:13:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaOeBPxyYAJv for ; Mon, 11 Oct 2021 19:13:12 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp2.osuosl.org (Postfix) with ESMTPS id BC93940352 for ; Mon, 11 Oct 2021 19:13:11 +0000 (UTC) Received: from mail-il1-f172.google.com (mail-il1-f172.google.com [209.85.166.172]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 19BJD959010252 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 11 Oct 2021 15:13:10 -0400 Received: by mail-il1-f172.google.com with SMTP id r9so19242765ile.5 for ; Mon, 11 Oct 2021 12:13:09 -0700 (PDT) X-Gm-Message-State: AOAM530VI4wmqf3KCDmuH3lfULSwsKlaPu/m7JXQ7Z8LZMKv2GsH10ZD BTCZ7rcW17iQ9l5o8xwqN/Oq/z4WQVjKiKuBlrI= X-Google-Smtp-Source: ABdhPJwszi33mEUyqU/h/y7IgMAAZaStpZwlBmJmH33dNcEb8Pgus69JaZ190e2XlPAw9xIHY2ifXDXE//kgBrTdKLQ= X-Received: by 2002:a05:6e02:1c47:: with SMTP id d7mr20332897ilg.49.1633979589196; Mon, 11 Oct 2021 12:13:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Date: Mon, 11 Oct 2021 12:12:58 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Michael Folkson , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000fc008205ce188485" 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: Mon, 11 Oct 2021 19:13:13 -0000 --000000000000fc008205ce188485 Content-Type: text/plain; charset="UTF-8" *> ... 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. from: Matt Corallo's post: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html *Matt: Follow the will of the community, irrespective of individuals orunreasoned objection, but without ever overruling any reasonableobjection. Recent history also includes "objection" to soft forks in theform of "this is bad because it doesn't fix a different problem I wantfixed ASAP". I don't think anyone would argue this qualifies as areasonable objection to a change, and we should be in a place, as acommunity (never as developers or purely one group), to ignore suchobjections and make forward progress in spite of them. We don't makegood engineering decisions by "bundling" unrelated features together to* *enable political football and compromise.* *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 think Matt and AJ's PoV is widely reflected in the community that bundling changes leads to the inclusion of suboptimal features. This also has strong precedent in other important technical bodies, e.g. from https://datatracker.ietf.org/doc/html/rfc7282 On Consensus and Humming in the IETF. Even worse is the "horse-trading" sort of compromise: "I object to your proposal for such-and-so reasons. You object to my proposal for this-and-that reason. Neither of us agree. If you stop objecting to my proposal, I'll stop objecting to your proposal and we'll put them both in." That again results in an "agreement" of sorts, but instead of just one outstanding unaddressed issue, this sort of compromise results in two, again ignoring them for the sake of expedience. These sorts of "capitulation" or "horse-trading" compromises have no place in consensus decision making. In each case, a chair who looks for "agreement" might find it in these examples because it appears that people have "agreed". But answering technical disagreements is what is needed to achieve consensus, sometimes even when the people who stated the disagreements no longer wish to discuss them. If you would like to advocate bitcoin development run counter to that, you should provide a much stronger refutation of these engineering norms. --000000000000fc008205ce188485 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> ..= .=C2=A0in this post I will argue against frequent soft forks with a = single or minimal
> set of features and instead argue for infreq= uent soft forks with batches
> of features.

I think this type of development = has been discussed in the past and has been rejected.


from: Matt Corallo's post: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-Ja= nuary/017547.html


<= i>Matt: Follow the will of the = community, irrespective of individuals or
unreasoned objection, but with= out ever overruling any reasonable
objection. Recent history also includ= es "objection" to soft forks in the
form of "this is bad = because it doesn't fix a different problem I want
fixed ASAP". = I don't think anyone would argue this qualifies as a
reasonable obje= ction to a change, and we should be in a place, as a
community (never as= developers or purely one group), to ignore such
objections and make for= ward progress in spite of them. We don't make
good engineering decis= ions by "bundling" unrelated features together to
enable political football and compromise.
=

<= span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri= f;font-size:small;color:rgb(0,0,0)">AJ:=C2=A0- improvements: changes= might not make everyone better off, but we
=C2=A0 =C2=A0don= 9;t want changes to screw anyone over either -- pareto
=C2=A0 =C2=A0impr= ovements in economics, "first, do no harm", etc. (if we get this<= br>=C2=A0 =C2=A0right, there's no need to make compromises and bundle m= ultiple
=C2=A0 =C2=A0flawed proposals so that everyone's an equal mi= x of happy and
=C2=A0 =C2=A0miserable)=


<= /i>
I t= hink Matt and AJ's PoV is widely reflected in the community that bundli= ng changes leads to the inclusion of suboptimal features.

Thi= s also has strong precedent in other important technical bodies, e.g. from= =C2=A0https://dat= atracker.ietf.org/doc/html/rfc7282=C2=A0On Consensus and Humming in the IETF.

      Even worse is the "horse-trading" sort=
 of compromise: "I object to
=C2=A0 =C2=A0your proposal for such-an=
d-so reasons.=C2=A0 You object to my proposal for
=C2=A0 =C2=A0this-and-=
that reason.=C2=A0 Neither of us agree.=C2=A0 If you stop objecting to
=
=C2=A0 =C2=A0my proposal, I'll stop objecting to your proposal and we&#=
39;ll put them
=C2=A0 =C2=A0both in." =C2=A0That again results in a=
n "agreement" of sorts, but instead
=C2=A0 =C2=A0of just one o=
utstanding unaddressed issue, this sort of compromise
     results in two, again ignoring them for the =
sake of expedience.

=C2=A0 =C2=A0These sorts of "capitulation&q=
uot; or "horse-trading" compromises have no
=C2=A0 =C2=A0place=
 in consensus decision making.=C2=A0 In each case, a chair who looks
=C2=
=A0 =C2=A0for "agreement" might find it in these examples because=
 it appears
=C2=A0 =C2=A0that people have "agreed".=C2=A0 But =
answering technical disagreements is
=C2=A0 =C2=A0what is needed to achi=
eve consensus, sometimes even when the people=C2=A0
      who stated the disagreements=
 no longer wish to discuss them.

If you would like to advocate bitcoi=
n development run counter to that, you should provide a much stronger refut=
ation of these engineering norms.

--000000000000fc008205ce188485--