path: root/20/f1bcb4d56a707ff1d81c609f35394db89663c7

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--