1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
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--
|
