From mboxrd@z Thu Jan 1 00:00:00 1970 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'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'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 <<a href=3D"mailto:gsanders87@gmail.com" tar= get=3D"_blank">gsanders87@gmail.com</a>> 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">> 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't think there'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 <<a href=3D"mail= to:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lis= ts.linuxfoundation.org</a>> 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'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'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's secret key from<= br> stealing the funds in that output. As shown in <ref>A. Poelstra, &quo= t;CAT<br> and Schnorr Tricks II", 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></ref><br> OP_CAT is sufficent to build vaults in Bitcoin.<br> * Replicating CheckSigFromStack <ref> A. Poelstra, "CAT and Schn= orr<br> Tricks I", 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> </ref> 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> <pre><br> =C2=A0 if (stack.size() < 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() > 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> </pre><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, "Program design in the UNIX<br> environment", 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, "Multisig on steroids using tree signatures", 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, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was= <br> CheckSigFromStack for Arithmetic Values]", 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, "Liar, Liar, Coins on Fire= :<br> Penalizing Equivocation by Loss of Bitcoins", 2015,<br> <a href=3D"https://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.727.= 6262&rep=3Drep1&type=3Dpdf" rel=3D"noreferrer" target=3D"_blank">ht= tps://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.727.6262&rep= =3Drep1&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, "Covenants with CAT and ECDSA", 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--