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
|
Return-Path: <james.obeirne@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id B9FE1C000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Feb 2022 17:42:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id A848741637
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Feb 2022 17:42:26 +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: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id rYo9TV68mcgO
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Feb 2022 17:42:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com
[IPv6:2607:f8b0:4864:20::b2f])
by smtp4.osuosl.org (Postfix) with ESMTPS id 898804162F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Feb 2022 17:42:25 +0000 (UTC)
Received: by mail-yb1-xb2f.google.com with SMTP id v47so27059825ybi.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Feb 2022 09:42:25 -0800 (PST)
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=ezWaZMN2F5nXsKjgTz0rLrTkWAcShI8GITFTy2D+tUs=;
b=DqzfJl7PcgR2lhuE6IGkE7nCcZMLYwXAeVJRD8Vc7ATzUEx0lkC8GdoIxas76DPz7Z
SDO4d8juuGpijwdu4XnhrGv/ugXZzELExelOhQCq74aRgLU8cqNVPYNAU94JczsWwCcx
bAdT/XnkD+JTTpprK3/V9Fc5N+j9p+Nvj13lFndKbSLlFpA9PWU/HU0+B/Y7H7gejDza
CVo7jOSxoN9Gh1ckmkNtO3NZAhBIxxOCkbRSdQmGlUUspdKoaP8A5ikqBsyKaoeXFQ7k
J82TdC6pSAvwvHYmmzwxDuY/Ov9Ehac5csir2Pa7/que8o/9k9ALLbMZBhaQK1ori/eh
b/SA==
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=ezWaZMN2F5nXsKjgTz0rLrTkWAcShI8GITFTy2D+tUs=;
b=LT6gK9WZkeGH4V3V9dR45dZD3JXDo8BJ6dFAP3Fl/PFz7Kt51uGSPBgQstF3bNL9P/
nj5kRYnqsmbIt5o/nmTEt5z6peuUmr9M4AGHOxUdmjbYCihn5nf4qYhnwO3r6Ghcr9S7
IHvarohfaVwBMPYRTIaAXA+M65tRm2+wMz2EWAMSH/6r+S0SUyfEiOxniboVRAUMR7Zx
QJIBoRXifBX3qtRtYVJ1f6vQsKZf5WWVr2Qqugb6VPYfYXnF6HCdE5iT/7IkXURl8MNq
WNeJMr685CxUFvVgKn/vV43rb/L+p1N83sTS0QQ66zLEuPkog+BaNtFc2DXm3BcfVYhR
g/eA==
X-Gm-Message-State: AOAM530+6zsx0RVzvOcsOu3VKxgxCciLEfeqv8hzwkU8KUvyDJI8uhVE
n5RzcdnRcyITOq8jtTZvBOHcSIIH5XOePIpeFmk=
X-Google-Smtp-Source: ABdhPJxHcLF8839eE95GnOTVaqdlNJtC3QLndbdrA7nDU5fybDlnLRRwrvnVMgqSsdLPjypAqcPDAx4ZcOtzSH0SgLk=
X-Received: by 2002:a81:4417:: with SMTP id r23mr2910795ywa.222.1644601344129;
Fri, 11 Feb 2022 09:42:24 -0800 (PST)
MIME-Version: 1.0
References: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com>
<87leymuiu8.fsf@rustcorp.com.au>
<CAD5xwhgP2_51Dvar0f1tsMrCXZ61W9-HnLgR45D-54Oc7-X1ag@mail.gmail.com>
<0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com>
In-Reply-To: <0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com>
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Fri, 11 Feb 2022 12:42:11 -0500
Message-ID: <CAPfvXf+q-0JiM+qap9wgUB1FTAeHGio_XeWVBdRwKj-_GffeUQ@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000e9ffd505d7c196a4"
Subject: Re: [bitcoin-dev] Recursive covenant opposition,
or the absence thereof,
was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
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, 11 Feb 2022 17:42:26 -0000
--000000000000e9ffd505d7c196a4
Content-Type: text/plain; charset="UTF-8"
I don't oppose recursive covenants per se, but in prior posts I have
expressed uncertainty about proposals that enable more "featureful"
covenants by adding more kinds of computation into bitcoin script.
Not that anyone here is necessarily saying otherwise, but I am very
interested in limiting operations in bitcoin script to "verification" (vs.
"computation") to the extent practical, and instead encouraging general
computation be done off-chain. This of course isn't a new observation and I
think the last few years have been very successful to that effect, e.g. the
popularity of the "scriptless scripts" idea and Taproot's emphasis on
embedding computational artifacts in key tweaks.
My (maybe unfounded?) worry about opcodes like OP_CAT and OP_TX is that
more logic will live in script than is necessary, and so the burden to
verify the chain may grow and the extra "degrees of freedom" in script may
make it harder to reason about. But I guess at this point there aren't
alternative means to construct new kinds of sighashes that are necessary
for some interesting covenants.
One thing I like about CTV is that it buys a lot of functionality without
increasing the "surface area" of script's design. In general I think there
is a lot to be said for this "jets"-style approach[0] of codifying the
script operations that you'd actually want to do into single opcodes. This
adds functionality while introducing minimal surface area to script, giving
script implementers more flexibility for, say, optimization. But of course
this comes at the cost of precluding experimentation, and probably
requiring more soft-forking. Though whether the place for script
experimentation using more general-purpose opcodes on the main chain is
another interesting debate...
Sorry for going a little off-topic there.
[0]: https://medium.com/blockstream/simplicity-jets-release-803db10fd589
On Thu, Feb 10, 2022 at 7:55 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev
> wrote:
> > Whether [recursive covenants] is an issue or not precluding this sort
> > of design or not, I defer to others.
>
> For reference, I believe the last time the merits of allowing recursive
> covenants was discussed at length on this list[1], not a single person
> replied to say that they were opposed to the idea.
>
> I would like to suggest that anyone opposed to recursive covenants speak
> for themselves (if any intelligent such people exist). Citing the risk
> of recursive covenants without presenting a credible argument for the
> source of that risk feels to me like (at best) stop energy[2] and (at
> worst) FUD.
>
> -Dave
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019203.html
> [2]
> http://radio-weblogs.com/0107584/stories/2002/05/05/stopEnergyByDaveWiner.html
> (thanks to AJ who told me about stop energy one time when I was
> producing it)
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000e9ffd505d7c196a4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I don't oppose recursive covenants per se, but in=
prior posts I have expressed uncertainty about proposals that enable more =
"featureful" covenants by adding more kinds of computation into b=
itcoin script.</div><div><br></div><div>Not that anyone here is necessarily=
saying otherwise, but I am very interested in limiting operations in bitco=
in script to "verification" (vs. "computation") to the =
extent practical, and instead encouraging general computation be done off-c=
hain. This of course isn't a new observation and I think the last few y=
ears have been very successful to that effect, e.g. the popularity of the &=
quot;scriptless scripts" idea and Taproot's emphasis on embedding =
computational artifacts in key tweaks.</div><div><br></div><div>My (maybe u=
nfounded?) worry about opcodes like OP_CAT and OP_TX is that more logic wil=
l live in script than is necessary, and so the burden to verify the chain m=
ay grow and the extra "degrees of freedom" in script may make it =
harder to reason about. But I guess at this point there aren't alternat=
ive means to construct new kinds of sighashes that are necessary for some i=
nteresting covenants. <br></div><div><br></div><div>One thing I like about =
CTV is that it buys a lot of functionality without increasing the "sur=
face area" of script's design. In general I think there is a lot t=
o be said for this "jets"-style approach[0] of codifying the scri=
pt operations that you'd actually want to do into single opcodes. This =
adds functionality while introducing minimal surface area to script, giving=
script implementers more flexibility for, say, optimization. But of course=
this comes at the cost of precluding experimentation, and probably requiri=
ng more soft-forking. Though whether the place for script experimentation u=
sing more general-purpose opcodes on the main chain is another interesting =
debate...</div><div><br></div><div>Sorry for going a little off-topic there=
.<br></div><div><br></div><div>[0]: <a href=3D"https://medium.com/blockstre=
am/simplicity-jets-release-803db10fd589">https://medium.com/blockstream/sim=
plicity-jets-release-803db10fd589</a></div><br></div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 10, 2022 at 7:55=
PM David A. Harding via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Feb 07,=
2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev wrote:<br>
> Whether [recursive covenants] is an issue or not precluding this sort<=
br>
> of design or not, I defer to others.<br>
<br>
For reference, I believe the last time the merits of allowing recursive<br>
covenants was discussed at length on this list[1], not a single person<br>
replied to say that they were opposed to the idea.<br>
<br>
I would like to suggest that anyone opposed to recursive covenants speak<br=
>
for themselves (if any intelligent such people exist).=C2=A0 Citing the ris=
k<br>
of recursive covenants without presenting a credible argument for the<br>
source of that risk feels to me like (at best) stop energy[2] and (at<br>
worst) FUD.<br>
<br>
-Dave<br>
<br>
[1] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021=
-July/019203.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linux=
foundation.org/pipermail/bitcoin-dev/2021-July/019203.html</a><br>
[2] <a href=3D"http://radio-weblogs.com/0107584/stories/2002/05/05/stopEner=
gyByDaveWiner.html" rel=3D"noreferrer" target=3D"_blank">http://radio-weblo=
gs.com/0107584/stories/2002/05/05/stopEnergyByDaveWiner.html</a><br>
=C2=A0 =C2=A0 (thanks to AJ who told me about stop energy one time when I w=
as<br>
=C2=A0 =C2=A0 producing it)<br>
<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>
--000000000000e9ffd505d7c196a4--
|
