summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJeremy <jlrubin@mit.edu>2021-10-11 12:12:58 -0700
committerbitcoindev <bitcoindev@gnusha.org>2021-10-11 19:13:13 +0000
commit6facd87e6e839b8ef2d6250fcd7a9d1e9af3fd8c (patch)
treef949e405e6855b31eab15552fbb739cadd8893a8
parent089a8bca0f1380655efe08994267b76ca18b490a (diff)
downloadpi-bitcoindev-6facd87e6e839b8ef2d6250fcd7a9d1e9af3fd8c.tar.gz
pi-bitcoindev-6facd87e6e839b8ef2d6250fcd7a9d1e9af3fd8c.zip
Re: [bitcoin-dev] On the regularity of soft forks
-rw-r--r--46/0e21ec562a3eaa0c3136a23f2b2357301e5230241
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)">&gt; ..=
+.=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)">&gt; </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)">&gt; </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&#39;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 &quot;objection&quot; to soft forks in the<br>form of &quot;this is bad =
+because it doesn&#39;t fix a different problem I want<br>fixed ASAP&quot;. =
+I don&#39;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&#39;t make<br>good engineering decis=
+ions by &quot;bundling&quot; 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&#3=
+9;t want changes to screw anyone over either -- pareto<br>=C2=A0 =C2=A0impr=
+ovements in economics, &quot;first, do no harm&quot;, etc. (if we get this<=
+br>=C2=A0 =C2=A0right, there&#39;s no need to make compromises and bundle m=
+ultiple<br>=C2=A0 =C2=A0flawed proposals so that everyone&#39;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&#39;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 &quot;horse-trading&quot; sort=
+ of compromise: &quot;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&#39;ll stop objecting to your proposal and we&#=
+39;ll put them<br>=C2=A0 =C2=A0both in.&quot; =C2=A0That again results in a=
+n &quot;agreement&quot; 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 &quot;capitulation&q=
+uot; or &quot;horse-trading&quot; 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 &quot;agreement&quot; might find it in these examples because=
+ it appears<br>=C2=A0 =C2=A0that people have &quot;agreed&quot;.=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--
+