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
|
Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 1CAC0C000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Feb 2022 04:34:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id F3F758131F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Feb 2022 04:34:45 +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 RYtzRqoOkhI9
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Feb 2022 04:34:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com
[IPv6:2a00:1450:4864:20::12f])
by smtp1.osuosl.org (Postfix) with ESMTPS id 7CC968131E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Feb 2022 04:34:44 +0000 (UTC)
Received: by mail-lf1-x12f.google.com with SMTP id f10so30904428lfu.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 07 Feb 2022 20:34:44 -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
:cc; bh=vcLERYvxxfbTmNSm872SoMEJhODJ9ExlXbBFUs10vKk=;
b=Y/b3iLvyHrIByLwaJ5Hif/PLIeRum5kOP2OpVirchJwNnImITdM+yHbFlHyr6pX/Ec
5SqhZqX4XQ9764hnQEe+6cgt92Rd4CQ4+rBU0v8nFOM6Y9YpdNqmsm+POBQL9e1a41BU
Tua5xbK0CI96ipCJ+liyrdWnyD0ZpLjE097YfevEV2VEJpZjcCMPPiELOjJuxe4UTdAy
q+dmXImLrGUdyKdT27AnjO8+CTKWGW+J/q9e4wVuNPj5BlJNDdWtYS4o5p2LiCWt/Myi
/+W6QQeKOo2sIUoJa3A8wtPwmV94UkiYA18FLJVrDSjBJX8o0t9AsvnVRlw/MvI4rxIv
t0ZA==
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:cc;
bh=vcLERYvxxfbTmNSm872SoMEJhODJ9ExlXbBFUs10vKk=;
b=3a6HtOPmLSHYdRSRgGO71KTLf33IKs/GaXsMl1OxMYh9mmK7msneDOVNfZXtLjgRil
5zdJ0E0jtD5pQtO1EhTWe/xDX8SOBE8OPhS9Yw5u2MpelwkDxYoQA7Z6S2jCy/VlsVKh
gTMa+GHbsL1QnQgH2YOg35Tl+KU0Hktg3xW5iSF/1mf9e07679E67LsSdJUeNvDcI7HL
xsS90eTp9++pdfZ6R2UyXYuqmhZlHLfhrJVhC6ojseKlX4xsalv3n1RRA9sLWFSIs6uV
PlIyJ0yB/l1gXd6Yc3SJ8QLyxYNBz1Mjj6YXtceSpZcVqMCmcGGgzCXEdBUVYtfij8zb
oA0w==
X-Gm-Message-State: AOAM530c6Jzu6Ij/ugz6J6wXdoYYQJXjLojlIeU38sNV8d1uH8R7qBx7
ierzZIq03gxyyXUDGdlunag50G4yzVM+WbZ0k48=
X-Google-Smtp-Source: ABdhPJxDH3Odr3tZ0oVTkE6uAnd3n8ZV8ovwaBCqrhQ7ypojSsQiSqihXLAy3dM2f+5Krm0SoL2SblXycA15KCms9xQ=
X-Received: by 2002:a05:6512:31d3:: with SMTP id
j19mr2014130lfe.112.1644294881882;
Mon, 07 Feb 2022 20:34:41 -0800 (PST)
MIME-Version: 1.0
References: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com>
<87leymuiu8.fsf@rustcorp.com.au>
In-Reply-To: <87leymuiu8.fsf@rustcorp.com.au>
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Mon, 7 Feb 2022 20:34:30 -0800
Message-ID: <CAD5xwhgP2_51Dvar0f1tsMrCXZ61W9-HnLgR45D-54Oc7-X1ag@mail.gmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000005733ef05d77a3c84"
Subject: Re: [bitcoin-dev] 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: Tue, 08 Feb 2022 04:34:46 -0000
--0000000000005733ef05d77a3c84
Content-Type: text/plain; charset="UTF-8"
Rusty,
Note that this sort of design introduces recursive covenants similarly to
how I described above.
Whether that is an issue or not precluding this sort of design or not, I
defer to others.
Best,
Jeremy
On Mon, Feb 7, 2022 at 7:57 PM Rusty Russell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Russell O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> writes:
> > Given the overlap in functionality between CTV and ANYPREVOUT, I think it
> > makes sense to decompose their operations into their constituent pieces
> and
> > reassemble their behaviour programmatically. To this end, I'd like to
> > instead propose OP_TXHASH and OP_CHECKSIGFROMSTACKVERIFY.
> >
> > OP_TXHASH would pop a txhash flag from the stack and compute a (tagged)
> > txhash in accordance with that flag, and push the resulting hash onto the
> > stack.
>
> It may be worth noting that OP_TXHASH can be further decomposed into
> OP_TX (and OP_TAGGEDHASH, or just reuse OP_SHA256).
>
> OP_TX would place the concatenated selected fields onto the stack
> (rather than hashing them) This is more compact for some tests
> (e.g. testing tx version for 2 is "OP_TX(version) 1 OP_EQUALS" vs
> "OP_TXHASH(version) 012345678...aabbccddeeff OP_EQUALS"), and also range
> testing (e.g amount less than X or greater than X, or less than 3 inputs).
>
> > I believe the difficulties with upgrading TXHASH can be mitigated by
> > designing a robust set of TXHASH flags from the start. For example
> having
> > bits to control whether (1) the version is covered; (2) the locktime is
> > covered; (3) txids are covered; (4) sequence numbers are covered; (5)
> input
> > amounts are covered; (6) input scriptpubkeys are covered; (7) number of
> > inputs is covered; (8) output amounts are covered; (9) output
> scriptpubkeys
> > are covered; (10) number of outputs is covered; (11) the tapbranch is
> > covered; (12) the tapleaf is covered; (13) the opseparator value is
> > covered; (14) whether all, one, or no inputs are covered; (15) whether
> all,
> > one or no outputs are covered; (16) whether the one input position is
> > covered; (17) whether the one output position is covered; (18) whether
> the
> > sighash flags are covered or not (note: whether or not the sighash flags
> > are or are not covered must itself be covered). Possibly specifying
> which
> > input or output position is covered in the single case and whether the
> > position is relative to the input's position or is an absolute position.
>
> These easily map onto OP_TX, "(1) the version is pushed as u32, (2) the
> locktime is pushed as u32, ...".
>
> We might want to push SHA256() of scripts instead of scripts themselves,
> to reduce possibility of DoS.
>
> I suggest, also, that 14 (and similarly 15) be defined two bits:
> 00 - no inputs
> 01 - all inputs
> 10 - current input
> 11 - pop number from stack, fail if >= number of inputs or no stack elems.
>
> Cheers,
> Rusty.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--0000000000005733ef05d77a3c84
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000"></div><div><div dir=3D"lt=
r" class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D=
"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:rgb(0,0,0)">Rusty,</div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Note that this=
sort of design introduces recursive covenants similarly to how I described=
above.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:rgb(0,0,0)">Whether that is an issue or not precluding this sort of=
design or not, I defer to others.</div><br></div><div dir=3D"ltr"><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)">Best,</div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)">Jeremy</div><br></div></div=
></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Mon, Feb 7, 2022 at 7:57 PM Rusty Russell via bitcoin-dev <<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.lin=
uxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:s=
olid;border-left-color:rgb(204,204,204);padding-left:1ex">Russell O'Con=
nor via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> write=
s:<br>
> Given the overlap in functionality between CTV and ANYPREVOUT, I think=
it<br>
> makes sense to decompose their operations into their constituent piece=
s and<br>
> reassemble their behaviour programmatically.=C2=A0 To this end, I'=
d like to<br>
> instead propose OP_TXHASH and OP_CHECKSIGFROMSTACKVERIFY.<br>
><br>
> OP_TXHASH would pop a txhash flag from the stack and compute a (tagged=
)<br>
> txhash in accordance with that flag, and push the resulting hash onto =
the<br>
> stack.<br>
<br>
It may be worth noting that OP_TXHASH can be further decomposed into<br>
OP_TX (and OP_TAGGEDHASH, or just reuse OP_SHA256).<br>
<br>
OP_TX would place the concatenated selected fields onto the stack<br>
(rather than hashing them) This is more compact for some tests<br>
(e.g. testing tx version for 2 is "OP_TX(version) 1 OP_EQUALS" vs=
<br>
"OP_TXHASH(version) 012345678...aabbccddeeff OP_EQUALS"), and als=
o range<br>
testing (e.g amount less than X or greater than X, or less than 3 inputs).<=
br>
<br>
> I believe the difficulties with upgrading TXHASH can be mitigated by<b=
r>
> designing a robust set of TXHASH flags from the start.=C2=A0 For examp=
le having<br>
> bits to control whether (1) the version is covered; (2) the locktime i=
s<br>
> covered; (3) txids are covered; (4) sequence numbers are covered; (5) =
input<br>
> amounts are covered; (6) input scriptpubkeys are covered; (7) number o=
f<br>
> inputs is covered; (8) output amounts are covered; (9) output scriptpu=
bkeys<br>
> are covered; (10) number of outputs is covered; (11) the tapbranch is<=
br>
> covered; (12) the tapleaf is covered; (13) the opseparator value is<br=
>
> covered; (14) whether all, one, or no inputs are covered; (15) whether=
all,<br>
> one or no outputs are covered; (16) whether the one input position is<=
br>
> covered; (17) whether the one output position is covered; (18) whether=
the<br>
> sighash flags are covered or not (note: whether or not the sighash fla=
gs<br>
> are or are not covered must itself be covered).=C2=A0 Possibly specify=
ing which<br>
> input or output position is covered in the single case and whether the=
<br>
> position is relative to the input's position or is an absolute pos=
ition.<br>
<br>
These easily map onto OP_TX, "(1) the version is pushed as u32, (2) th=
e<br>
locktime is pushed as u32, ...".<br>
<br>
We might want to push SHA256() of scripts instead of scripts themselves,<br=
>
to reduce possibility of DoS.<br>
<br>
I suggest, also, that 14 (and similarly 15) be defined two bits:<br>
00 - no inputs<br>
01 - all inputs<br>
10 - current input<br>
11 - pop number from stack, fail if >=3D number of inputs or no stack el=
ems.<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>
--0000000000005733ef05d77a3c84--
|