summaryrefslogtreecommitdiff
path: root/84/c773f36c3ffc70ee7a974fd3e41947a5a8241d
blob: 332be2c9918b9639c1cec69a19c05e7059124be9 (plain)
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
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
Return-Path: <aubergemediale@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 68A6BC000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  7 Apr 2021 13:42:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 428EF848CD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  7 Apr 2021 13:42:16 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Cn1E6acb1wE5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  7 Apr 2021 13:42:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [IPv6:2a00:1450:4864:20::529])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 1DBA7848BB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  7 Apr 2021 13:42:14 +0000 (UTC)
Received: by mail-ed1-x529.google.com with SMTP id k8so13500879edn.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 07 Apr 2021 06:42:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=G4jy6snWEvWF1hEyDLALdZtsp1vb2dpKfvfhz2W3UIk=;
 b=j/50RMJC8yNOCLKK8aQ7SGwYnIsTICbrQSCD6wkeIPSJgKq6tm1fcJEGGsOMhCax5J
 Qvp2ycNj3kpASX74OJfOJduPfPVM9nDa2stYfhzEa6DM8lZw25FuLgv6KwVZUdb0m2J7
 ++z0KiBHoQ+Jb9Hdu1wN+T5N7k17Ez0q7H3RIwlvyu50xPe6YNaalPTS0/Pi5D1NAso1
 X5qStzvZOO2DmyR4H1lWs+4Kdfe1Qzf1on005cozlHURB8Td/CzMAuFsgNoNy1VR31MQ
 +cMUUZ+LnJN8ijRRa1LtFKECS+0ZH1EJN9aiSuRLwhCZtU+UPwVb8bHNum9LPXgd0qGa
 SjpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=G4jy6snWEvWF1hEyDLALdZtsp1vb2dpKfvfhz2W3UIk=;
 b=Z8z/BtJsY4j2Duc8X7NZi2auo6hcIldRaI96OTfR/3m7kHvizNtWBTVN/YgUlQl72L
 dtfpsHNtrpP+dFjMRDsv/XE5bdDprECCue3xtf4KPVJXg+tA9FBb5EyG3VRixVjh+axm
 skUjTS3tDHFCSmHOvxTpoXFsXDYYahy3AwMJWSEj0A6+ZNVGVXlYeqfyVPjyYEoIju8H
 6yl8hYXZoQu+90GR9RlJ/gGwC3IUcbN3RnfkBvLzSJq0Qn915ZEmjw1KojcuekkiS8Fk
 iqbll5cW738qtftJlapcQmYb4cxbafReMc5l40u2gVOS/d/RfTTseDxwhyV/b+R/5sPH
 UcHw==
X-Gm-Message-State: AOAM533cIByICg1czh4e8QhCMr618kdL2viPDue+/NtHnvpmIiKWdEod
 sb3xGYKCLrEp8lJ5Toc89IyOoRHGQp2/ndCfIjs5GjzH
X-Google-Smtp-Source: ABdhPJykfq1vyDtKOkknyQIMAUI+4BBlUXKPJ0LVPaVaNqOnGOnMY+O6ddtm8e8lD93DCHPS4KujyzuEf7Fs5/ODAmo=
X-Received: by 2002:a05:6402:c:: with SMTP id
 d12mr4500962edu.100.1617802932323; 
 Wed, 07 Apr 2021 06:42:12 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhiXE=yJFi+9aZQqMOCaiUrJ_UEvcESR3E0j2SA1RnbqmA@mail.gmail.com>
 <874kgkkpji.fsf@rustcorp.com.au>
 <CAMnpzfopMNO=73wqvXpOn9u8X4MwJArqGxODJAS4-9iFiZOd6A@mail.gmail.com>
 <87pmz6it7q.fsf@rustcorp.com.au>
In-Reply-To: <87pmz6it7q.fsf@rustcorp.com.au>
From: Claus Ehrenberg <aubergemediale@gmail.com>
Date: Wed, 7 Apr 2021 15:42:01 +0200
Message-ID: <CANPykMr_pyz7XxrXo2FfkNPmBwzMkmnL2SPw8-TmVhOtxkz=-A@mail.gmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000190ab805bf6219d8"
X-Mailman-Approved-At: Wed, 07 Apr 2021 15:20:31 +0000
Subject: Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes
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: Wed, 07 Apr 2021 13:42:16 -0000

--000000000000190ab805bf6219d8
Content-Type: text/plain; charset="UTF-8"

As a user, I think it's very important for me to know if Taproot is
eventually coming or not. So why not make it so that if _either_ miners
_or_ users decide for Taproot, it will activate no matter what. Accepting a
chain split is imo the fairest way to 'resolve the conflict' (it can't be
resolved anyway).

That would probably mean running ST and and UASF concurrently.

The upside would be that we've got a safe date for Taproot, except neither
users nor miners want it.

Cheers,
Claus

On Wed, Apr 7, 2021 at 7:02 AM Rusty Russell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Ryan Grant <bitcoin-dev@rgrant.org> writes:
> > On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >> The core question always was: what do we do if miners fail to activate?
> >>
> >> [...]  Speedy Trial takes the approach that "let's pretend we didn't
> >> *actually* ask [miners]".
> >
> > What ST is saying is that a strategy of avoiding unnecessary risk is
> > stronger than a strategy of brinkmanship when brinkmanship wasn't
> > our only option.  Having deescalation in the strategy toolkit makes
> > Bitcoin stronger.
>
> I don't believe that having a plan is brinkmanship or an escalation.
>
> During the segwit debate, Pieter Wuille said that users should decide.
> I've been thinking about that a lot, especially about what that means in
> a practical sense where the normal developer / miner dynamic has failed.
>
> >> It's totally a political approach, to avoid facing the awkward question.
> >> Since I believe that such prevaricating makes a future crisis less
> >> predictable, I am forced to conclude that it makes bitcoin less robust.
> >
> > LOT=true does face the awkward question, but there are downsides:
> >
> >   - in the requirement to drop blocks from apathetic miners (although
> >     as Luke-Jr pointed out in a previous reply on this list they have
> >     no contract under which to raise a complaint); and
>
> Surely, yes.  If the users of bitcoin decide blocks are invalid, they're
> invalid.  With a year's warning, and developer and user consensus
> against them, I think we've reached the limits of acceptable miner
> apathy.
>
> >   - in the risk of a chain split, should gauging economic majority
> >     support - which there is zero intrinsic tooling for - go poorly.
>
> Agreed that we should definitely do better here: in practice people
> would rely on third party explorers for information on the other side of
> the split.  Tracking the cumulative work on invalid chains would be a
> good idea for bitcoind in general (AJ suggested this, IIRC).
>
> >> Personally, I think the compromise position is using LOT=false and
> >> having those such as Luke and myself continue working on a LOT=true
> >> branch for future consideration.  It's less than optimal, but I
> >> appreciate that people want Taproot activated more than they want
> >> the groundwork future upgrades.
> >
> > Another way of viewing the current situation is that should
> > brinkmanship be necessary, then better tooling to resolve a situation
> > that requires brinkmanship will be invaluable.  But:
> >
> >   - we do not need to normalize brinkmanship;
> >
> >   - designing brinkmanship tooling well before the next crisis does
> >     not require selecting conveniently completed host features to
> >     strap the tooling onto for testing; and
>
> Again, openly creating a contingency plan is not brinkmanship, it's
> normal.  I know that considering these scenarios is uncomfortable; I
> avoid conflict myself!  But I feel obliged to face this as a real
> possibility.
>
> I think we should be normalizing the understanding that bitcoin users
> are the ultimate decider.  By offering *all* of them the tools to do so
> we show this isn't lip-service, but something that businesses and
> everyone else in the ecosystem should consider.
>
> >   - it's already the case that a UASF branch can be prepared along
> >     with ST (ie. without requiring LOT=false), although the code is a
> >     bit more complex and the appropriate stopheight a few blocks later.
>
> I don't believe this is true, unless you UASF before ST expires?  ST is
> explicitly designed *not* to give time to conclude that miners are
> stalling (unless something has changed from the initial 3 month
> proposal?).
>
> > Although your NACK is well explained, for the reasons above I am
> > prepared to run code that overrides it.
>
> Good.  In the end, we're all at the whim of the economic majority.
>
> Cheers!
> Rusty.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000190ab805bf6219d8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">As a user, I think it&#39;s very important for me to know =
if Taproot is eventually coming or not. So why not make it so that if _eith=
er_ miners _or_ users decide for Taproot, it will activate no matter what. =
Accepting a chain split is imo the fairest way to &#39;resolve the conflict=
&#39; (it can&#39;t be resolved anyway).<div><br></div><div>That would prob=
ably mean running ST and and UASF concurrently.<br><div><br></div><div>The =
upside would be that we&#39;ve got a safe date for Taproot, except neither =
users nor miners want it.</div><div><br></div><div>Cheers,</div><div>Claus<=
/div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g=
mail_attr">On Wed, Apr 7, 2021 at 7:02 AM Rusty Russell via bitcoin-dev &lt=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists=
.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">Ryan Grant &lt;<a href=3D"mailto:bitcoin-dev@rgrant.org=
" target=3D"_blank">bitcoin-dev@rgrant.org</a>&gt; writes:<br>
&gt; On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev<br>
&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt; The core question always was: what do we do if miners fail to acti=
vate?<br>
&gt;&gt;<br>
&gt;&gt; [...]=C2=A0 Speedy Trial takes the approach that &quot;let&#39;s p=
retend we didn&#39;t<br>
&gt;&gt; *actually* ask [miners]&quot;.<br>
&gt;<br>
&gt; What ST is saying is that a strategy of avoiding unnecessary risk is<b=
r>
&gt; stronger than a strategy of brinkmanship when brinkmanship wasn&#39;t<=
br>
&gt; our only option.=C2=A0 Having deescalation in the strategy toolkit mak=
es<br>
&gt; Bitcoin stronger.<br>
<br>
I don&#39;t believe that having a plan is brinkmanship or an escalation.<br=
>
<br>
During the segwit debate, Pieter Wuille said that users should decide.<br>
I&#39;ve been thinking about that a lot, especially about what that means i=
n<br>
a practical sense where the normal developer / miner dynamic has failed.<br=
>
<br>
&gt;&gt; It&#39;s totally a political approach, to avoid facing the awkward=
 question.<br>
&gt;&gt; Since I believe that such prevaricating makes a future crisis less=
<br>
&gt;&gt; predictable, I am forced to conclude that it makes bitcoin less ro=
bust.<br>
&gt;<br>
&gt; LOT=3Dtrue does face the awkward question, but there are downsides:<br=
>
&gt;<br>
&gt;=C2=A0 =C2=A0- in the requirement to drop blocks from apathetic miners =
(although<br>
&gt;=C2=A0 =C2=A0 =C2=A0as Luke-Jr pointed out in a previous reply on this =
list they have<br>
&gt;=C2=A0 =C2=A0 =C2=A0no contract under which to raise a complaint); and<=
br>
<br>
Surely, yes.=C2=A0 If the users of bitcoin decide blocks are invalid, they&=
#39;re<br>
invalid.=C2=A0 With a year&#39;s warning, and developer and user consensus<=
br>
against them, I think we&#39;ve reached the limits of acceptable miner<br>
apathy.<br>
<br>
&gt;=C2=A0 =C2=A0- in the risk of a chain split, should gauging economic ma=
jority<br>
&gt;=C2=A0 =C2=A0 =C2=A0support - which there is zero intrinsic tooling for=
 - go poorly.<br>
<br>
Agreed that we should definitely do better here: in practice people<br>
would rely on third party explorers for information on the other side of<br=
>
the split.=C2=A0 Tracking the cumulative work on invalid chains would be a<=
br>
good idea for bitcoind in general (AJ suggested this, IIRC).<br>
<br>
&gt;&gt; Personally, I think the compromise position is using LOT=3Dfalse a=
nd<br>
&gt;&gt; having those such as Luke and myself continue working on a LOT=3Dt=
rue<br>
&gt;&gt; branch for future consideration.=C2=A0 It&#39;s less than optimal,=
 but I<br>
&gt;&gt; appreciate that people want Taproot activated more than they want<=
br>
&gt;&gt; the groundwork future upgrades.<br>
&gt;<br>
&gt; Another way of viewing the current situation is that should<br>
&gt; brinkmanship be necessary, then better tooling to resolve a situation<=
br>
&gt; that requires brinkmanship will be invaluable.=C2=A0 But:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0- we do not need to normalize brinkmanship;<br>
&gt;<br>
&gt;=C2=A0 =C2=A0- designing brinkmanship tooling well before the next cris=
is does<br>
&gt;=C2=A0 =C2=A0 =C2=A0not require selecting conveniently completed host f=
eatures to<br>
&gt;=C2=A0 =C2=A0 =C2=A0strap the tooling onto for testing; and<br>
<br>
Again, openly creating a contingency plan is not brinkmanship, it&#39;s<br>
normal.=C2=A0 I know that considering these scenarios is uncomfortable; I<b=
r>
avoid conflict myself!=C2=A0 But I feel obliged to face this as a real<br>
possibility.<br>
<br>
I think we should be normalizing the understanding that bitcoin users<br>
are the ultimate decider.=C2=A0 By offering *all* of them the tools to do s=
o<br>
we show this isn&#39;t lip-service, but something that businesses and<br>
everyone else in the ecosystem should consider.<br>
<br>
&gt;=C2=A0 =C2=A0- it&#39;s already the case that a UASF branch can be prep=
ared along<br>
&gt;=C2=A0 =C2=A0 =C2=A0with ST (ie. without requiring LOT=3Dfalse), althou=
gh the code is a<br>
&gt;=C2=A0 =C2=A0 =C2=A0bit more complex and the appropriate stopheight a f=
ew blocks later.<br>
<br>
I don&#39;t believe this is true, unless you UASF before ST expires?=C2=A0 =
ST is<br>
explicitly designed *not* to give time to conclude that miners are<br>
stalling (unless something has changed from the initial 3 month<br>
proposal?).<br>
<br>
&gt; Although your NACK is well explained, for the reasons above I am<br>
&gt; prepared to run code that overrides it.<br>
<br>
Good.=C2=A0 In the end, we&#39;re all at the whim of the economic majority.=
<br>
<br>
Cheers!<br>
Rusty.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000190ab805bf6219d8--