diff options
author | Jeremy <jlrubin@mit.edu> | 2021-10-11 12:12:58 -0700 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2021-10-11 19:13:13 +0000 |
commit | 6facd87e6e839b8ef2d6250fcd7a9d1e9af3fd8c (patch) | |
tree | f949e405e6855b31eab15552fbb739cadd8893a8 | |
parent | 089a8bca0f1380655efe08994267b76ca18b490a (diff) | |
download | pi-bitcoindev-6facd87e6e839b8ef2d6250fcd7a9d1e9af3fd8c.tar.gz pi-bitcoindev-6facd87e6e839b8ef2d6250fcd7a9d1e9af3fd8c.zip |
Re: [bitcoin-dev] On the regularity of soft forks
-rw-r--r-- | 46/0e21ec562a3eaa0c3136a23f2b2357301e5230 | 241 |
1 files changed, 241 insertions, 0 deletions
diff --git a/46/0e21ec562a3eaa0c3136a23f2b2357301e5230 b/46/0e21ec562a3eaa0c3136a23f2b2357301e5230 new file mode 100644 index 000000000..2274175f2 --- /dev/null +++ b/46/0e21ec562a3eaa0c3136a23f2b2357301e5230 @@ -0,0 +1,241 @@ +Return-Path: <jlrubin@mit.edu> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 6C11AC000D + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; Mon, 11 Oct 2021 15:13:10 -0400 +Received: by mail-il1-f172.google.com with SMTP id r9so19242765ile.5 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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: <LmX3Gnfkf1T0Eb_wUXxPe8c0Tf2DNipfIqufkRS6oOPhttr4iZIOWtjUL_7QkcWEHr8eFvehHooaM140ZBKLwi98F5NwyQKSyEhAPZDK1YQ=@protonmail.com> +In-Reply-To: <LmX3Gnfkf1T0Eb_wUXxPe8c0Tf2DNipfIqufkRS6oOPhttr4iZIOWtjUL_7QkcWEHr8eFvehHooaM140ZBKLwi98F5NwyQKSyEhAPZDK1YQ=@protonmail.com> +From: Jeremy <jlrubin@mit.edu> +Date: Mon, 11 Oct 2021 12:12:58 -0700 +X-Gmail-Original-Message-ID: <CAD5xwhj3JCxH1=5Tj+hgiSxLWchLgT584X0YutKVeuibnpwmtA@mail.gmail.com> +Message-ID: <CAD5xwhj3JCxH1=5Tj+hgiSxLWchLgT584X0YutKVeuibnpwmtA@mail.gmail.com> +To: Michael Folkson <michaelfolkson@protonmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 <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: 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 + +<div dir=3D"ltr"><div class=3D"gmail_quote"><i><span class=3D"gmail_default= +" style=3D"font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">> ..= +.=C2=A0</span>in this post I will argue against frequent soft forks with a = +single or minimal</i></div><div class=3D"gmail_quote"><i><span class=3D"gma= +il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small= +;color:rgb(0,0,0)">> </span>set of features and instead argue for infreq= +uent soft forks with batches</i></div><div class=3D"gmail_quote"><i><span c= +lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font= +-size:small;color:rgb(0,0,0)">> </span>of features.</i><div><span style= +=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></d= +iv><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-se= +rif"><span class=3D"gmail_default" style=3D"font-family:arial,helvetica,san= +s-serif;font-size:small;color:rgb(0,0,0)">I think this type of development = +has been discussed in the past and has been rejected.</span></span><br></di= +v><div><br></div><div><br></div><div class=3D"gmail_quote"><div class=3D"gm= +ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal= +l;color:rgb(0,0,0)">from: Matt Corallo's post: <a href=3D"https://lists= +.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html" target= +=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-Ja= +nuary/017547.html</a></div><br></div><div class=3D"gmail_quote"><br></div><= +i><span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s= +erif;font-size:small;color:rgb(0,0,0)">Matt: </span>Follow the will of the = +community, irrespective of individuals or<br>unreasoned objection, but with= +out ever overruling any reasonable<br>objection. Recent history also includ= +es "objection" to soft forks in the<br>form of "this is bad = +because it doesn't fix a different problem I want<br>fixed ASAP". = +I don't think anyone would argue this qualifies as a<br>reasonable obje= +ction to a change, and we should be in a place, as a<br>community (never as= + developers or purely one group), to ignore such<br>objections and make for= +ward progress in spite of them. We don't make<br>good engineering decis= +ions by "bundling" unrelated features together to</i></div><div c= +lass=3D"gmail_quote"><i>enable political football and compromise.</i></div>= +<div class=3D"gmail_quote"><i><br></i></div><div class=3D"gmail_quote"><i><= +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</span>- improvements: changes= + might not make everyone better off, but we</i></div><i>=C2=A0 =C2=A0don= +9;t want changes to screw anyone over either -- pareto<br>=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<br>=C2=A0 =C2=A0flawed proposals so that everyone's an equal mi= +x of happy and<br></i><div class=3D"gmail_quote"><i>=C2=A0 =C2=A0miserable)= +<span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser= +if;font-size:small;color:rgb(0,0,0)"></span></i><br></div><div class=3D"gma= +il_quote"><i><span class=3D"gmail_default" style=3D"font-family:arial,helve= +tica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></span></i></div><div= + class=3D"gmail_quote"><i><span class=3D"gmail_default" style=3D"font-famil= +y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></span><= +/i></div><div class=3D"gmail_quote"><div class=3D"gmail_default" style=3D"f= +ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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.</div><div class= +=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz= +e:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"f= +ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Thi= +s also has strong precedent in other important technical bodies, e.g. from= +=C2=A0<a href=3D"https://datatracker.ietf.org/doc/html/rfc7282">https://dat= +atracker.ietf.org/doc/html/rfc7282</a>=C2=A0<span style=3D"font-size:1em;fo= +nt-weight:bold">On Consensus and Humming in the IETF.</span></div><div clas= +s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si= +ze:small;color:rgb(0,0,0)"><br></div><pre class=3D"gmail-newpage" style=3D"= +margin-top:0px;margin-bottom:0px;break-before:page"><span class=3D"gmail_de= +fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo= +r:rgb(0,0,0)"> </span>Even worse is the "horse-trading" sort= + of compromise: "I object to<br>=C2=A0 =C2=A0your proposal for such-an= +d-so reasons.=C2=A0 You object to my proposal for<br>=C2=A0 =C2=A0this-and-= +that reason.=C2=A0 Neither of us agree.=C2=A0 If you stop objecting to<br>= +=C2=A0 =C2=A0my proposal, I'll stop objecting to your proposal and we&#= +39;ll put them<br>=C2=A0 =C2=A0both in." =C2=A0That again results in a= +n "agreement" of sorts, but instead<br>=C2=A0 =C2=A0of just one o= +utstanding unaddressed issue, this sort of compromise<br><span class=3D"gma= +il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small= +;color:rgb(0,0,0)"> </span>results in two, again ignoring them for the = +sake of expedience.<br><br>=C2=A0 =C2=A0These sorts of "capitulation&q= +uot; or "horse-trading" compromises have no<br>=C2=A0 =C2=A0place= + in consensus decision making.=C2=A0 In each case, a chair who looks<br>=C2= +=A0 =C2=A0for "agreement" might find it in these examples because= + it appears<br>=C2=A0 =C2=A0that people have "agreed".=C2=A0 But = +answering technical disagreements is<br>=C2=A0 =C2=A0what is needed to achi= +eve consensus, sometimes even when the people=C2=A0</pre><pre class=3D"gmai= +l-newpage" style=3D"margin-top:0px;margin-bottom:0px;break-before:page"><sp= +an class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;= +font-size:small;color:rgb(0,0,0)"> </span>who stated the disagreements= + no longer wish to discuss them.<span style=3D"color:rgb(0,0,0);font-size:s= +mall;font-family:arial,helvetica,sans-serif"></span><font color=3D"#000000"= + size=3D"3"><span style=3D"caret-color: rgb(0, 0, 0);"><br></span></font></= +pre><pre class=3D"gmail-newpage" style=3D"margin-top:0px;margin-bottom:0px;= +break-before:page"><span style=3D"color:rgb(0,0,0);font-size:small;font-fam= +ily:arial,helvetica,sans-serif"><br></span></pre><pre class=3D"gmail-newpag= +e" style=3D"margin-top:0px;margin-bottom:0px;break-before:page"><span style= +=3D"color:rgb(0,0,0);font-size:small;font-family:arial,helvetica,sans-serif= +"><span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s= +erif;font-size:small;color:rgb(0,0,0)">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.</span><br></span></pre><br></div></div> + +--000000000000fc008205ce188485-- + |