path: root/40/fea18ed66b7d9fe797a4a1529f45406f39b564

Return-Path: <gsanders87@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 71014C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Oct 2023 16:10:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 39C0C7083F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Oct 2023 16:10:19 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 39C0C7083F
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20230601 header.b=BMlNirDS
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level: 
X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, 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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id dXBjMK_8Bz-c
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Oct 2023 16:10:14 +0000 (UTC)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [IPv6:2a00:1450:4864:20::529])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 3DF9C7083E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Oct 2023 16:10:14 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 3DF9C7083E
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-53de0d1dc46so2811676a12.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Oct 2023 09:10:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1697904612; x=1698509412;
 darn=lists.linuxfoundation.org; 
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=gNRquZ3o24y6NGhOco4V1jDb1UaRBtkqBTOxUrXKrio=;
 b=BMlNirDSN19pz7zOK6Jhe225SlfBjeJ0pEUdkZePKP39bSx/4HnLVGSX8E+aF0ZcvP
 +MI5HbFyPjdxNXk5fVWvpemB6sAxJ+l4tz4X7XFwaWNuN4kX1wmvdJIExAfKkxwRL8b+
 aC089dVw3JAgyG6rsKFc2KcO6m6RwOAko2B/ujGxrvDSRC7VaEvPS+vXZ8Z+RudsUhVu
 Mxag4MviCI+VhWpq48UBykIA9oNRSheIP3V4PWgcwIEHzsub4YrZwIFNBcyiz9S7dlKy
 Tk9Zh07BXr2HgVJNIaV9TpFtQlkiHuMvL/7A67YT/mnH/b1kSzfgstQ21SPQUHIxKJx1
 Y9Iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1697904612; x=1698509412;
 h=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=gNRquZ3o24y6NGhOco4V1jDb1UaRBtkqBTOxUrXKrio=;
 b=aVKfB6QQx7fqFmuNO7QYz/VGBr1XcQZb3evQZRNkOwcUZH1S6d2cERx3ihiz5aa4P/
 1P15SnambTrvsFLNbRkArA0n/KikUNt2leIad3ZzzWOD+wiq1+ULJBY4clSJmpu60Aa/
 2xsr9LlEqGg7u0JFAze4Zwc8KtkSgaR2MWgdyP69IQ9nqBffNBp5h+Ergu0XR2XpvO5U
 w2sxausTxVCFZVFrP/Q5TiPGhENifRMQmOoux2jvllBruZAmT77DbasKjq9+CLMytzWu
 7z7WOnBGrj4HQyDAI+fIUjfxZ2IbYfCW6lFXAoDFz7S4natg4i1L9caiq0ufYCRw+mM+
 WZrQ==
X-Gm-Message-State: AOJu0YwJkFLzoepFxdpd+L9nhKpzO6b6JzsnNuSwy5RDoY9XhMEA33CP
 lbbrr3AqEAbxUje3uuCEL/IYu/7i4881T2fkmqw=
X-Google-Smtp-Source: AGHT+IEeibW+gaAiSXrrIN5mFC17RMUxsFsvM5dxRLWsEAHQe6C7XvOzBwfU9qIOkA7DykeOcFEvDoVgied7a8v7AqI=
X-Received: by 2002:a17:907:7b99:b0:9c4:6893:ccc5 with SMTP id
 ne25-20020a1709077b9900b009c46893ccc5mr3363170ejc.57.1697904611837; Sat, 21
 Oct 2023 09:10:11 -0700 (PDT)
MIME-Version: 1.0
References: <CAEM=y+XDB7GGa5BTAWrQHqTqQHBE2VRyd7VWjEb+zCOMzRP+Lg@mail.gmail.com>
In-Reply-To: <CAEM=y+XDB7GGa5BTAWrQHqTqQHBE2VRyd7VWjEb+zCOMzRP+Lg@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Sat, 21 Oct 2023 12:10:00 -0400
Message-ID: <CAB3F3DuV8SHc+fKVEpvWBBE0+=tqJX7pr0Xzhmtj=bQfKbx0eg@mail.gmail.com>
To: Ethan Heilman <eth3rs@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000404cd306083c3906"
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 16:10:19 -0000

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

> 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/interp=
reter.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
>

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

<div dir=3D"ltr">&gt; This is no<br>longer an issue in the current age as t=
apscript enforces a maximum<br>stack element size of 520 Bytes.<div><br></d=
iv><div>I don&#39;t think there&#39;s a new limit related to tapscript? In =
the very beginning there was no limit, but a 5k limit was put into place, t=
hen 520 the same commit that OP_CAT was disabled:=C2=A04bd188c4383d6e614e18=
f79dc337fbabe8464c82</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 Hei=
lman via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);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>

--000000000000404cd306083c3906--