summaryrefslogtreecommitdiff
path: root/20/f1bcb4d56a707ff1d81c609f35394db89663c7
blob: a82b43d3bb2cd3a5bb5fb54c891e80de2045de80 (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
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
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
Return-Path: <eth3rs@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 01202C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Oct 2023 20:25:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id C221C400D7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Oct 2023 20:25:13 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org C221C400D7
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20230601 header.b=eDHsSI5T
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 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, URI_DOTEDU=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 0zp6nvBhzGte
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Oct 2023 20:25:08 +0000 (UTC)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com
 [IPv6:2a00:1450:4864:20::52b])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 57E944016C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Oct 2023 20:25:08 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 57E944016C
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-53db3811d8fso4174742a12.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Oct 2023 13:25:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1697919906; x=1698524706;
 darn=lists.linuxfoundation.org; 
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=9a6ulWLp9hPaFe1kmnumkHKuLtRkoODhUIBrMVsYYlE=;
 b=eDHsSI5TmxqlPUuJy5jsvHp18/579UnA2GF4GcmEnTwZ49W0Gh7LcAqpM+XIBJ/v1h
 hqYGvqA32ERQb/CBzWFtaaOZfNf9D1uzxu2NXmjg+gb8WHsgL2ZW/7ces3CFI5De59sj
 YOtUa2SdU2+BzHp/bNuLXSHgQVaypJW2rka5keuPO3ewPpLaLR2YdNN0qVbJpBUZJDq5
 oJGxX9UZ6n7dWLG34ybLmOTUjMIL+4xQLdTc7VhEaKogyklXmE9OM2mKXqFUWvbKhEuQ
 +8aHRrYUTCdZOd+RAq8MjTEFChG+A2KWvb+fvT6UaDW67h7/qrtdrXLZsPX/QRHoOsCx
 Ui9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1697919906; x=1698524706;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=9a6ulWLp9hPaFe1kmnumkHKuLtRkoODhUIBrMVsYYlE=;
 b=Q0JQMQoahcz/p+ZTXjycKr2VTpr8R4ncbpS/fjjTEVUqL/AjXarjiaNUGCIR1FCo5u
 gco1B0VkVgcCiOxDZ1QVueAoJemI8YVTqLywaC4I3O8xilvmwKQCFGIiR+RTh+4qIooV
 gu/x6zBNgHITDPLVA5z+f4jM4mFt41ViEFsWlesXLcSQzgUNEqz7CKRoVLujm0lHSbNm
 1lZKHLAODZjKTRau1wW6b+/Q+pL1IpMiHeO2LQWhmB0GuWVx5paUQj1KyszXLgELQGKs
 ywjoFN44uLdCi7bZ+elF2+7yh9wCmcM8NxFJjWmgtj/01pfAHrN5RiUZcFxvu8feB1jQ
 6K8g==
X-Gm-Message-State: AOJu0YwZ28T61smk2xJQcVFfaX6gnuuzXACe72nNWTkA9jxavMSFtTJw
 8uo+d7A3co5qZx2R0T+9mUqPihWjSR2lq8nilAE4SPg3SPA=
X-Google-Smtp-Source: AGHT+IFVYadOwf/gxxva1rtoQ1ZjFvcYdRneExyJjvgnkGTu55xqdTo18+6B+hrhVykN4PaMKOPXNtjbCGujxzlesso=
X-Received: by 2002:a05:6402:2293:b0:525:4d74:be8c with SMTP id
 cw19-20020a056402229300b005254d74be8cmr7809194edb.14.1697919906195; Sat, 21
 Oct 2023 13:25:06 -0700 (PDT)
MIME-Version: 1.0
References: <CAEM=y+XDB7GGa5BTAWrQHqTqQHBE2VRyd7VWjEb+zCOMzRP+Lg@mail.gmail.com>
 <CAB3F3DuV8SHc+fKVEpvWBBE0+=tqJX7pr0Xzhmtj=bQfKbx0eg@mail.gmail.com>
In-Reply-To: <CAB3F3DuV8SHc+fKVEpvWBBE0+=tqJX7pr0Xzhmtj=bQfKbx0eg@mail.gmail.com>
From: Ethan Heilman <eth3rs@gmail.com>
Date: Sat, 21 Oct 2023 16:24:29 -0400
Message-ID: <CAEM=y+XLD2Vkuv1gzkeUj_zQJJqjz1UCKa4dwbA1WXSJBQZueQ@mail.gmail.com>
To: Greg Sanders <gsanders87@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000ddacf806083fc878"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposed BIP for OP_CAT
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: Sat, 21 Oct 2023 20:25:14 -0000

--000000000000ddacf806083fc878
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Greg,

I didn't mean to imply this limit is a unique feature of tapescript, but
rather that:OP_CAT is a tapscript opcode and that tapscript enforces a 520
byte element size thus we don't have to worry about OP_CAT creating very
large stack elements.

Thanks for pointing this out, I didn't realize that this limit was added in
the same commit that removed OP_CAT. I thought it was more recent than
that. Reading through that commit it also appears that it also reduced the
size limit on inputs to arithmetic operations (nMaxNumSize) from 2064-bits
to 32-bits. I had always assumed it was 32-bits from the beginning. It
would have been wild to have math opcodes that support 2064-bit inputs and
outputs.

Thanks,
Ethan


On Sat, Oct 21, 2023 at 12:10=E2=80=AFPM Greg Sanders <gsanders87@gmail.com=
> wrote:

> > This is no
> longer an issue in the current age as tapscript enforces a maximum
> stack element size of 520 Bytes.
>
> I don't think there's a new limit related to tapscript? In the very
> beginning there was no limit, but a 5k limit was put into place, then 520
> the same commit that OP_CAT was
> disabled: 4bd188c4383d6e614e18f79dc337fbabe8464c82
>
> On Sat, Oct 21, 2023 at 1:09=E2=80=AFAM Ethan Heilman via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi everyone,
>>
>> We've posted a draft BIP to propose enabling OP_CAT as Tapscript opcode.
>> https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.mediawiki
>>
>> OP_CAT was available in early versions of Bitcoin. It was disabled as
>> it allowed the construction of a script whose evaluation could create
>> stack elements exponential in the size of the script. This is no
>> longer an issue in the current age as tapscript enforces a maximum
>> stack element size of 520 Bytes.
>>
>> Thanks,
>> Ethan
>>
>> =3D=3DAbstract=3D=3D
>>
>> This BIP defines OP_CAT a new tapscript opcode which allows the
>> concatenation of two values on the stack. This opcode would be
>> activated via a soft fork by redefining the opcode OP_SUCCESS80.
>>
>> When evaluated the OP_CAT instruction:
>> # Pops the top two values off the stack,
>> # concatenate the popped values together,
>> # and then pushes the concatenated value on the top of the stack.
>>
>> OP_CAT fails if there are less than two values on the stack or if a
>> concatenated value would have a combined size of greater than the
>> maximum script element size of 520 Bytes.
>>
>> =3D=3DMotivation=3D=3D
>> Bitcoin tapscript lacks a general purpose way of combining objects on
>> the stack restricting the expressiveness and power of tapscript. For
>> instance this prevents among many other things the ability to
>> construct and evaluate merkle trees and other hashed data structures
>> in tapscript. OP_CAT by adding a general purpose way to concatenate
>> stack values would overcome this limitation and greatly increase the
>> functionality of tapscript.
>>
>> OP_CAT aims to expand the toolbox of the tapscript developer with a
>> simple, modular and useful opcode in the spirit of Unix[1]. To
>> demonstrate the usefulness of OP_CAT below we provide a non-exhaustive
>> list of some usecases that OP_CAT would enable:
>>
>> * Tree Signatures provide a multisignature script whose size can be
>> logarithmic in the number of public keys and can encode spend
>> conditions beyond n-of-m. For instance a transaction less than 1KB in
>> size could support tree signatures with a thousand public keys. This
>> also enables generalized logical spend conditions. [2]
>> * Post-Quantum Lamport Signatures in Bitcoin transactions. Lamport
>> signatures merely requires the ability to hash and concatenate values
>> on the stack. [3]
>> * Non-equivocation contracts [4] in tapscript provide a mechanism to
>> punish equivocation/double spending in Bitcoin payment channels.
>> OP_CAT enables this by enforcing rules on the spending transaction's
>> nonce. The capability is a useful building block for payment channels
>> and other Bitcoin protocols.
>> * Vaults [5] which are a specialized covenant that allows a user to
>> block a malicious party who has compromised the user's secret key from
>> stealing the funds in that output. As shown in <ref>A. Poelstra, "CAT
>> and Schnorr Tricks II", 2021,
>> https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html
>> </ref>
>> OP_CAT is sufficent to build vaults in Bitcoin.
>> * Replicating CheckSigFromStack <ref> A. Poelstra, "CAT and Schnorr
>> Tricks I", 2021,
>> https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
>> </ref> which would allow the creation of simple covenants and other
>> advanced contracts without having to presign spending transactions,
>> possibly reducing complexity and the amount of data that needs to be
>> stored. Originally shown to work with Schnorr signatures, this result
>> has been extended to ECDSA signatures. [6]
>>
>> The opcode OP_CAT was available in early versions of Bitcoin. However
>> OP_CAT was removed because it enabled the construction of a script for
>> which an evaluation could have memory usage exponential in the size of
>> the script.
>> For instance a script which pushed an 1 Byte value on the stack then
>> repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack
>> value whose size was greater than 1 Terabyte. This is no longer an
>> issue because tapscript enforces a maximum stack element size of 520
>> Bytes.
>>
>> =3D=3DSpecification=3D=3D
>>
>> Implementation
>> <pre>
>>   if (stack.size() < 2)
>>     return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
>>   valtype vch1 =3D stacktop(-2);
>>   valtype vch2 =3D stacktop(-1);
>>
>>   if (vch1.size() + vch2.size() > MAX_SCRIPT_ELEMENT_SIZE)
>>       return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
>>
>>   valtype vch3;
>>   vch3.reserve(vch1.size() + vch2.size());
>>   vch3.insert(vch3.end(), vch1.begin(), vch1.end());
>>   vch3.insert(vch3.end(), vch2.begin(), vch2.end());
>>
>>   popstack(stack);
>>   popstack(stack);
>>   stack.push_back(vch3);
>> </pre>
>>
>> The value of MAX_SCRIPT_ELEMENT_SIZE is 520 Bytes
>>
>> =3D=3D Reference Implementation =3D=3D
>> [Elements](
>> https://github.com/ElementsProject/elements/blob/master/src/script/inter=
preter.cpp#L1043
>> )
>>
>> =3D=3DReferences=3D=3D
>>
>> [1]: R. Pike and B. Kernighan, "Program design in the UNIX
>> environment", 1983,
>> https://harmful.cat-v.org/cat-v/unix_prog_design.pdf
>> [2]: P. Wuille, "Multisig on steroids using tree signatures", 2015,
>>
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233=
.html
>> [3]: J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was
>> CheckSigFromStack for Arithmetic Values]", 2021,
>>
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233=
.html
>> [4]: T. Ruffing, A. Kate, D. Schr=C3=B6der, "Liar, Liar, Coins on Fire:
>> Penalizing Equivocation by Loss of Bitcoins", 2015,
>>
>> https://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.727.6262&rep=
=3Drep1&type=3Dpdf
>> [5]: M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants,
>> http://fc16.ifca.ai/bitcoin/papers/MES16.pdf
>> [6]: R. Linus, "Covenants with CAT and ECDSA", 2023,
>>
>> https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file=
-covenants_cat_ecdsa-md
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

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

<div dir=3D"ltr">Hi Greg,<br><br>I didn&#39;t mean to imply this limit is a=
 unique feature of tapescript, but rather that:OP_CAT is a tapscript=C2=A0o=
pcode and that tapscript=C2=A0enforces a 520 byte element size thus we don&=
#39;t have to worry about OP_CAT creating very large stack elements.<br><br=
>Thanks for pointing this out, I didn&#39;t realize that this limit was add=
ed in the same commit that removed OP_CAT. I thought it was more recent tha=
n that. Reading through that commit it also appears that it also reduced th=
e size limit on inputs to arithmetic operations (nMaxNumSize)=C2=A0from=C2=
=A02064-bits to 32-bits. I had always assumed it was 32-bits from the begin=
ning. It would have been wild to have math opcodes that support 2064-bit in=
puts and outputs.<br><br>Thanks,<br>Ethan<br><br></div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Oct 21, 2023 at 12=
:10=E2=80=AFPM Greg Sanders &lt;<a href=3D"mailto:gsanders87@gmail.com" tar=
get=3D"_blank">gsanders87@gmail.com</a>&gt; wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">&gt; This is no<br>long=
er an issue in the current age as tapscript enforces a maximum<br>stack ele=
ment size of 520 Bytes.<div><br></div><div>I don&#39;t think there&#39;s a =
new limit related to tapscript? In the very beginning there was no limit, b=
ut a 5k limit was put into place, then 520 the same commit that OP_CAT was =
disabled:=C2=A04bd188c4383d6e614e18f79dc337fbabe8464c82</div></div><br><div=
 class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Oct 21=
, 2023 at 1:09=E2=80=AFAM Ethan Heilman via bitcoin-dev &lt;<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lis=
ts.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">Hi everyone,<br>
<br>
We&#39;ve posted a draft BIP to propose enabling OP_CAT as Tapscript opcode=
.<br>
<a href=3D"https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.media=
wiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/EthanHeilman/=
op_cat_draft/blob/main/cat.mediawiki</a><br>
<br>
OP_CAT was available in early versions of Bitcoin. It was disabled as<br>
it allowed the construction of a script whose evaluation could create<br>
stack elements exponential in the size of the script. This is no<br>
longer an issue in the current age as tapscript enforces a maximum<br>
stack element size of 520 Bytes.<br>
<br>
Thanks,<br>
Ethan<br>
<br>
=3D=3DAbstract=3D=3D<br>
<br>
This BIP defines OP_CAT a new tapscript opcode which allows the<br>
concatenation of two values on the stack. This opcode would be<br>
activated via a soft fork by redefining the opcode OP_SUCCESS80.<br>
<br>
When evaluated the OP_CAT instruction:<br>
# Pops the top two values off the stack,<br>
# concatenate the popped values together,<br>
# and then pushes the concatenated value on the top of the stack.<br>
<br>
OP_CAT fails if there are less than two values on the stack or if a<br>
concatenated value would have a combined size of greater than the<br>
maximum script element size of 520 Bytes.<br>
<br>
=3D=3DMotivation=3D=3D<br>
Bitcoin tapscript lacks a general purpose way of combining objects on<br>
the stack restricting the expressiveness and power of tapscript. For<br>
instance this prevents among many other things the ability to<br>
construct and evaluate merkle trees and other hashed data structures<br>
in tapscript. OP_CAT by adding a general purpose way to concatenate<br>
stack values would overcome this limitation and greatly increase the<br>
functionality of tapscript.<br>
<br>
OP_CAT aims to expand the toolbox of the tapscript developer with a<br>
simple, modular and useful opcode in the spirit of Unix[1]. To<br>
demonstrate the usefulness of OP_CAT below we provide a non-exhaustive<br>
list of some usecases that OP_CAT would enable:<br>
<br>
* Tree Signatures provide a multisignature script whose size can be<br>
logarithmic in the number of public keys and can encode spend<br>
conditions beyond n-of-m. For instance a transaction less than 1KB in<br>
size could support tree signatures with a thousand public keys. This<br>
also enables generalized logical spend conditions. [2]<br>
* Post-Quantum Lamport Signatures in Bitcoin transactions. Lamport<br>
signatures merely requires the ability to hash and concatenate values<br>
on the stack. [3]<br>
* Non-equivocation contracts [4] in tapscript provide a mechanism to<br>
punish equivocation/double spending in Bitcoin payment channels.<br>
OP_CAT enables this by enforcing rules on the spending transaction&#39;s<br=
>
nonce. The capability is a useful building block for payment channels<br>
and other Bitcoin protocols.<br>
* Vaults [5] which are a specialized covenant that allows a user to<br>
block a malicious party who has compromised the user&#39;s secret key from<=
br>
stealing the funds in that output. As shown in &lt;ref&gt;A. Poelstra, &quo=
t;CAT<br>
and Schnorr Tricks II&quot;, 2021,<br>
<a href=3D"https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii=
.html" rel=3D"noreferrer" target=3D"_blank">https://www.wpsoftware.net/andr=
ew/blog/cat-and-schnorr-tricks-ii.html</a>&lt;/ref&gt;<br>
OP_CAT is sufficent to build vaults in Bitcoin.<br>
* Replicating CheckSigFromStack &lt;ref&gt; A. Poelstra, &quot;CAT and Schn=
orr<br>
Tricks I&quot;, 2021,<br>
<a href=3D"https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59b=
d298" rel=3D"noreferrer" target=3D"_blank">https://medium.com/blockstream/c=
at-and-schnorr-tricks-i-faf1b59bd298</a><br>
&lt;/ref&gt; which would allow the creation of simple covenants and other<b=
r>
advanced contracts without having to presign spending transactions,<br>
possibly reducing complexity and the amount of data that needs to be<br>
stored. Originally shown to work with Schnorr signatures, this result<br>
has been extended to ECDSA signatures. [6]<br>
<br>
The opcode OP_CAT was available in early versions of Bitcoin. However<br>
OP_CAT was removed because it enabled the construction of a script for<br>
which an evaluation could have memory usage exponential in the size of<br>
the script.<br>
For instance a script which pushed an 1 Byte value on the stack then<br>
repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack<br>
value whose size was greater than 1 Terabyte. This is no longer an<br>
issue because tapscript enforces a maximum stack element size of 520<br>
Bytes.<br>
<br>
=3D=3DSpecification=3D=3D<br>
<br>
Implementation<br>
&lt;pre&gt;<br>
=C2=A0 if (stack.size() &lt; 2)<br>
=C2=A0 =C2=A0 return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);=
<br>
=C2=A0 valtype vch1 =3D stacktop(-2);<br>
=C2=A0 valtype vch2 =3D stacktop(-1);<br>
<br>
=C2=A0 if (vch1.size() + vch2.size() &gt; MAX_SCRIPT_ELEMENT_SIZE)<br>
=C2=A0 =C2=A0 =C2=A0 return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPER=
ATION);<br>
<br>
=C2=A0 valtype vch3;<br>
=C2=A0 vch3.reserve(vch1.size() + vch2.size());<br>
=C2=A0 vch3.insert(vch3.end(), vch1.begin(), vch1.end());<br>
=C2=A0 vch3.insert(vch3.end(), vch2.begin(), vch2.end());<br>
<br>
=C2=A0 popstack(stack);<br>
=C2=A0 popstack(stack);<br>
=C2=A0 stack.push_back(vch3);<br>
&lt;/pre&gt;<br>
<br>
The value of MAX_SCRIPT_ELEMENT_SIZE is 520 Bytes<br>
<br>
=3D=3D Reference Implementation =3D=3D<br>
[Elements](<a href=3D"https://github.com/ElementsProject/elements/blob/mast=
er/src/script/interpreter.cpp#L1043" rel=3D"noreferrer" target=3D"_blank">h=
ttps://github.com/ElementsProject/elements/blob/master/src/script/interpret=
er.cpp#L1043</a>)<br>
<br>
=3D=3DReferences=3D=3D<br>
<br>
[1]: R. Pike and B. Kernighan, &quot;Program design in the UNIX<br>
environment&quot;, 1983,<br>
<a href=3D"https://harmful.cat-v.org/cat-v/unix_prog_design.pdf" rel=3D"nor=
eferrer" target=3D"_blank">https://harmful.cat-v.org/cat-v/unix_prog_design=
.pdf</a><br>
[2]: P. Wuille, &quot;Multisig on steroids using tree signatures&quot;, 201=
5,<br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Jul=
y/019233.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoun=
dation.org/pipermail/bitcoin-dev/2021-July/019233.html</a><br>
[3]: J. Rubin, &quot;[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was=
<br>
CheckSigFromStack for Arithmetic Values]&quot;, 2021,<br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Jul=
y/019233.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoun=
dation.org/pipermail/bitcoin-dev/2021-July/019233.html</a><br>
[4]: T. Ruffing, A. Kate, D. Schr=C3=B6der, &quot;Liar, Liar, Coins on Fire=
:<br>
Penalizing Equivocation by Loss of Bitcoins&quot;, 2015,<br>
<a href=3D"https://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.727.=
6262&amp;rep=3Drep1&amp;type=3Dpdf" rel=3D"noreferrer" target=3D"_blank">ht=
tps://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.727.6262&amp;rep=
=3Drep1&amp;type=3Dpdf</a><br>
[5]: M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants,<br>
<a href=3D"http://fc16.ifca.ai/bitcoin/papers/MES16.pdf" rel=3D"noreferrer"=
 target=3D"_blank">http://fc16.ifca.ai/bitcoin/papers/MES16.pdf</a><br>
[6]: R. Linus, &quot;Covenants with CAT and ECDSA&quot;, 2023,<br>
<a href=3D"https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5=
e85#file-covenants_cat_ecdsa-md" rel=3D"noreferrer" target=3D"_blank">https=
://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file-covenan=
ts_cat_ecdsa-md</a><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>
</blockquote></div>

--000000000000ddacf806083fc878--