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
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
|
Return-Path: <james.obeirne@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id B4704C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 16:48:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id A267340126
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 16:48:53 +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: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
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 L5qzV6pLgCDM
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 16:48:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com
[IPv6:2607:f8b0:4864:20::233])
by smtp2.osuosl.org (Postfix) with ESMTPS id 50F87400BA
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 16:48:52 +0000 (UTC)
Received: by mail-oi1-x233.google.com with SMTP id v65so4940448oig.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 09:48:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=2V5Bvafnul3ACfoIHKV8xByjVWh9QDdRg+IXyEgQUD0=;
b=Gl+QWGFcq8hvnR9Leo0BhyRXnsam3pFwNvIJPQh8Jl+75DAoZ+Fmh0fxsdzm1t5rGl
vfkvBbsow7K7jBkPQrsaf6xuvc5GwT6sN8FdMso5kRD+zDJjimq1e3MIsTWKDqC+65Zo
8ttTI02jF+Rk5EhNGM0LFOSlD22H15B0wBVbWDOwUFawWP/YfQTpFPfyyolah5ttJ+fW
uXr6mvc27pgDjri6i8c9+Fim4bioCdFRF4rENfSzS+/7vrq22HzDEcdpGfoB75dtMZu2
fFqIfPY+MDks3xZTaz5E9xCqtnPEbCQq9iLpPJVtXUDhPY/qAbtykLvfyGfTBvTyBeNK
E24g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=2V5Bvafnul3ACfoIHKV8xByjVWh9QDdRg+IXyEgQUD0=;
b=5OpE10zkpE/nlP1vZtZwXj2v0YHVa6igZnvVhP76Ia5nZ4r34f0ANTWQxjT//diLsh
itvH9pRhmvc8KTDA3O7rqTBxrbTOgxxapiAshhQZfpUZrV6nnWdFGqnatvyWOyPO4nRx
CX00ahTgWBrGSaHCH38AIvxHqcAzhUQro3rYSWkAEC0ozin/BPUcGK503qx9wgkCHmRC
cVMVGWDCrUem8x6WDGP1TXZEJTFjI9U5xdBbeg+8VbiMZS0D8epuN7IPMJPLf5Vs6+Gf
s2G1GpQyp44zd9DgPlnURUOiHDvVTWbreMBAOj78o90ffUdP+zEk7kImRjkUBu/4UhKC
9phw==
X-Gm-Message-State: AOAM531Zb0RcY4YG4aEsG3snGBC5u2Hs9NnRXBoW4Ow/gZ3G4ksz2nSJ
IcXVfnDEd2nYt4YVqlHSruG1WDPGhVoaJI+P7s29nHZAlLHJ1g==
X-Google-Smtp-Source: ABdhPJzYCbKAyM90zPNd3JbT3nnhL6sll2ODwkm6439I2kT2+60u8aOf4sUKM35Ah2SFw9AFSNf8SCVjlqxKPjr4+pI=
X-Received: by 2002:a05:6808:1788:b0:322:eae3:5d3c with SMTP id
bg8-20020a056808178800b00322eae35d3cmr2795295oib.222.1650646131172; Fri, 22
Apr 2022 09:48:51 -0700 (PDT)
MIME-Version: 1.0
References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
<d95eec37-269d-eefb-d191-e8234e4faed3@mattcorallo.com>
<4b252ef6f86bbd494a67683f6113f3fe@dtrt.org>
<c779648c-891d-b920-f85f-c617a0448997@mattcorallo.com>
<4056eca7e1ff018bff03918b8c266d76@dtrt.org>
In-Reply-To: <4056eca7e1ff018bff03918b8c266d76@dtrt.org>
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Fri, 22 Apr 2022 12:48:39 -0400
Message-ID: <CAPfvXfJ+x5gysRU+H7hwxL2cYB9=2-YshrpqQm-OEFsSWf1GDA@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000004c676205dd41000b"
Subject: Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks,
e.g. for CTV
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: Fri, 22 Apr 2022 16:48:53 -0000
--0000000000004c676205dd41000b
Content-Type: text/plain; charset="UTF-8"
> APO/IIDs, CTV, and TLUV/EVICT all seem to me to be very specific to
> certain usecases (respectively: Eltoo, congestion control, and
> joinpools)
The enumeration of covenants uses here excludes vaulting,
which I see as far and away the highest utility use for covenants given
that it allows significant derisking of custody for any user of Bitcoin
interested in holding their own coins (which is debatably redundant
with a strict definition of "Bitcoin user" ;).
A lot of why I like CTV is the simple fact that it is a low-risk way of
getting us vaults. That feature in itself is more than enough to
justify (to me) CTV's added validation complexity, which is very modest
- in contrast every other covenant proposal I've seen so far.
On Thu, Apr 21, 2022 at 6:28 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On 21.04.2022 08:39, Matt Corallo wrote:
> > We add things to Bitcoin because (a) there's some demonstrated
> > use-cases and intent to use the change (which I think we definitely
> > have for covenants, but which only barely, if at all, suggests
> > favoring one covenant design over any other)
>
> I'm unconvinced about CTV's use cases but others have made reasonable
> claims that it will be used. We could argue about this indefinitely,
> but I would love to give CTV proponents an opportunity to prove that a
> significant number of people would use it.
>
> > (b) because its
> > generally considered aligned with Bitcoin's design and goals, based on
> > developer and more broad community response
>
> I think CTV fulfills this criteria. At least, I can't think of any way
> BIP119 itself (notwithstanding activation concerns) violates Bitcoin's
> designs and goals.
>
> > (c) because the
> > technical folks who have/are wiling to spend time working on the
> > specific design space think the concrete proposal is the best design
> > we have
>
> This is the criteria that most concerns me. What if there is no
> universal best? For example, I mentioned in my previous email that I'm
> a partisan of OP_CAT+OP_CSFS due to their min-max of implementation
> simplicity versus production flexibility. But one problem is that
> spends using them would need to contain a lot of witness data. In my
> mind, they're the best for experimentation and for proving the existence
> of demand for more optimized constructions.
>
> OP_TX or OP_TXHASH would likely offer almost as much simplicity and
> flexibility but be more efficient onchain. Does that make them better
> than OP_CAT+OP_CSFS? I don't know how to objectively answer that
> question, and I don't feel comfortable with my subjective opinion of
> CAT+CSFS being better than OP_TX.
>
> APO/IIDs, CTV, and TLUV/EVICT all seem to me to be very specific to
> certain usecases (respectively: Eltoo, congestion control, and
> joinpools), providing maximum onchain efficiency for those cases but
> requiring contortions or larger witnesses to accomplish other covenant
> usecases. Is their increased efficiency better than more general
> constructions like CSFS or TX? Again, I don't know how to answer that
> question objectively, although subjectively I'm ok with optimized
> constructions for cases of proven demand.
>
> > , and finally (d) because the implementation is well-reviewed
> > and complete.
>
> No comment here; I haven't followed CTV's review progress to know
> whether I'd consider it well enough reviewed or not.
>
> > I do not see how we can make an argument for any specific covenant
> > under (c) here. We could just as well be talking about
> > TLUV/CAT+CHECKSIGFROMSTACK/etc, and nearly anyone who is going to use
> > CTV can probably just as easily use those instead - ie this has
> > nothing to do with "will people use it".
>
> I'm curious how we as a technical community will be able to determine
> which is the best approach. Again, I like starting simple and general,
> gathering real usage data, and then optimizing for demonstrated needs.
> But the simplest and most general approaches seem to be too general for
> some people (because they enable recursive covenants), seemingly forcing
> us into looking only at application-optimized designs. In that case, I
> think the main thing we want to know about these narrow proposals for
> new applications is whether the applications and the proposed consensus
> changes will actually receive significant use. For that, I think we
> need some sort of test bed with real paying users, and ideally one that
> is as similar to Bitcoin mainnet as possible.
>
> > we
> > cannot remove the validation code for something ever, really - you
> > still want to be able to validate the historical chain
>
> You and Jeremy both brought up this point. I understand it and I
> should've addressed it better in my OP, but I'm of the opinion that
> reverting to earlier consensus rules gives future developers the
> *option* of dropping no-longer-used consensus code as a practical
> simplification of the same type we've used on several occasions before,
> and which is an optional default in newly started Bitcoin Core nodes for
> over a decade now (i.e. skipping verification of old signatures). If
> future devs *want* to maintain code from a set of temporary rules used
> millions of blocks ago, that's great, but giving them the option to
> forget about those rules eliminates one of my concerns about making
> consensus changes without fully proven demand for that change.
>
> I just wanted to mention the above in case this discussion comes back to
> serious consideration of a transitory soft fork. For now, I think we
> can table a debate over validating reverted rules and focus on how we'll
> come to agreement that a particular covenant-related consensus change is
> warranted.
>
> Thanks for your thoughtful response,
>
> -Dave
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--0000000000004c676205dd41000b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">> APO/IIDs, CTV, and TLUV/EVICT all seem to me to be ve=
ry specific to<br>> certain usecases (respectively: Eltoo, congestion co=
ntrol, and<br>> joinpools)<br><br><div>The enumeration of covenants uses=
here excludes vaulting, <br></div><div>which I see as far and away the hig=
hest utility use for covenants given <br></div><div>that it allows signific=
ant derisking of custody for any user of Bitcoin<br></div><div>interested i=
n holding their own coins (which is debatably redundant <br></div><div>with=
a strict definition of "Bitcoin user" ;).<br></div><br>A lot of =
why I like CTV is the simple fact that it is a low-risk way of<br>getting u=
s vaults. That feature in itself is more than enough to<br>justify (to me) =
CTV's added validation complexity, which is very modest<br>- in contras=
t every other covenant proposal I've seen so far.<br></div><br><div cla=
ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Apr 21, 20=
22 at 6:28 PM David A. Harding via bitcoin-dev <<a href=3D"mailto:bitcoi=
n-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 21=
.04.2022 08:39, Matt Corallo wrote:<br>
> We add things to Bitcoin because (a) there's some demonstrated<br>
> use-cases and intent to use the change (which I think we definitely<br=
>
> have for covenants, but which only barely, if at all, suggests<br>
> favoring one covenant design over any other)<br>
<br>
I'm unconvinced about CTV's use cases but others have made reasonab=
le <br>
claims that it will be used.=C2=A0 We could argue about this indefinitely, =
<br>
but I would love to give CTV proponents an opportunity to prove that a <br>
significant number of people would use it.<br>
<br>
> (b) because its<br>
> generally considered aligned with Bitcoin's design and goals, base=
d on<br>
> developer and more broad community response<br>
<br>
I think CTV fulfills this criteria.=C2=A0 At least, I can't think of an=
y way <br>
BIP119 itself (notwithstanding activation concerns) violates Bitcoin's =
<br>
designs and goals.<br>
<br>
> (c) because the<br>
> technical folks who have/are wiling to spend time working on the<br>
> specific design space think the concrete proposal is the best design<b=
r>
> we have<br>
<br>
This is the criteria that most concerns me.=C2=A0 What if there is no <br>
universal best?=C2=A0 For example, I mentioned in my previous email that I&=
#39;m <br>
a partisan of OP_CAT+OP_CSFS due to their min-max of implementation <br>
simplicity versus production flexibility.=C2=A0 But one problem is that <br=
>
spends using them would need to contain a lot of witness data.=C2=A0 In my =
<br>
mind, they're the best for experimentation and for proving the existenc=
e <br>
of demand for more optimized constructions.<br>
<br>
OP_TX or OP_TXHASH would likely offer almost as much simplicity and <br>
flexibility but be more efficient onchain.=C2=A0 Does that make them better=
<br>
than OP_CAT+OP_CSFS?=C2=A0 I don't know how to objectively answer that =
<br>
question, and I don't feel comfortable with my subjective opinion of <b=
r>
CAT+CSFS being better than OP_TX.<br>
<br>
APO/IIDs, CTV, and TLUV/EVICT all seem to me to be very specific to <br>
certain usecases (respectively: Eltoo, congestion control, and <br>
joinpools), providing maximum onchain efficiency for those cases but <br>
requiring contortions or larger witnesses to accomplish other covenant <br>
usecases.=C2=A0 Is their increased efficiency better than more general <br>
constructions like CSFS or TX?=C2=A0 Again, I don't know how to answer =
that <br>
question objectively, although subjectively I'm ok with optimized <br>
constructions for cases of proven demand.<br>
<br>
> , and finally (d) because the implementation is well-reviewed<br>
> and complete.<br>
<br>
No comment here; I haven't followed CTV's review progress to know <=
br>
whether I'd consider it well enough reviewed or not.<br>
<br>
> I do not see how we can make an argument for any specific covenant<br>
> under (c) here. We could just as well be talking about<br>
> TLUV/CAT+CHECKSIGFROMSTACK/etc, and nearly anyone who is going to use<=
br>
> CTV can probably just as easily use those instead - ie this has<br>
> nothing to do with "will people use it".<br>
<br>
I'm curious how we as a technical community will be able to determine <=
br>
which is the best approach.=C2=A0 Again, I like starting simple and general=
, <br>
gathering real usage data, and then optimizing for demonstrated needs.=C2=
=A0 <br>
But the simplest and most general approaches seem to be too general for <br=
>
some people (because they enable recursive covenants), seemingly forcing <b=
r>
us into looking only at application-optimized designs.=C2=A0 In that case, =
I <br>
think the main thing we want to know about these narrow proposals for <br>
new applications is whether the applications and the proposed consensus <br=
>
changes will actually receive significant use.=C2=A0 For that, I think we <=
br>
need some sort of test bed with real paying users, and ideally one that <br=
>
is as similar to Bitcoin mainnet as possible.<br>
<br>
> we<br>
> cannot remove the validation code for something ever, really - you<br>
> still want to be able to validate the historical chain<br>
<br>
You and Jeremy both brought up this point.=C2=A0 I understand it and I <br>
should've addressed it better in my OP, but I'm of the opinion that=
<br>
reverting to earlier consensus rules gives future developers the <br>
*option* of dropping no-longer-used consensus code as a practical <br>
simplification of the same type we've used on several occasions before,=
<br>
and which is an optional default in newly started Bitcoin Core nodes for <b=
r>
over a decade now (i.e. skipping verification of old signatures).=C2=A0 If =
<br>
future devs *want* to maintain code from a set of temporary rules used <br>
millions of blocks ago, that's great, but giving them the option to <br=
>
forget about those rules eliminates one of my concerns about making <br>
consensus changes without fully proven demand for that change.<br>
<br>
I just wanted to mention the above in case this discussion comes back to <b=
r>
serious consideration of a transitory soft fork.=C2=A0 For now, I think we =
<br>
can table a debate over validating reverted rules and focus on how we'l=
l <br>
come to agreement that a particular covenant-related consensus change is <b=
r>
warranted.<br>
<br>
Thanks for your thoughtful response,<br>
<br>
-Dave<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>
--0000000000004c676205dd41000b--
|