From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 01202C0032 for ; 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 ; 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 ; 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 ; 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 ; 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: In-Reply-To: From: Ethan Heilman Date: Sat, 21 Oct 2023 16:24:29 -0400 Message-ID: To: Greg Sanders Content-Type: multipart/alternative; boundary="000000000000ddacf806083fc878" Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 A. Poelstra, "CAT >> and Schnorr Tricks II", 2021, >> https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html >> >> OP_CAT is sufficent to build vaults in Bitcoin. >> * Replicating CheckSigFromStack A. Poelstra, "CAT and Schnorr >> Tricks I", 2021, >> https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 >> 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 >> 
>>   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);
>>
>> >> 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
Hi Greg,

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

Thanks,
Ethan


On Sat, Oct 21, 2023 at 12= :10=E2=80=AFPM Greg Sanders <gsanders87@gmail.com> wrote:
> This is no
long= er an issue in the current age as tapscript enforces a maximum
stack ele= ment size of 520 Bytes.

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

On Sat, Oct 21= , 2023 at 1:09=E2=80=AFAM Ethan Heilman via bitcoin-dev <bitcoin-dev@lis= ts.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<= br> stealing the funds in that output. As shown in <ref>A. Poelstra, &quo= t;CAT
and Schnorr Tricks II", 2021,
https://www.wpsoftware.net/andr= ew/blog/cat-and-schnorr-tricks-ii.html</ref>
OP_CAT is sufficent to build vaults in Bitcoin.
* Replicating CheckSigFromStack <ref> A. Poelstra, "CAT and Schn= orr
Tricks I", 2021,
https://medium.com/blockstream/c= at-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>
=C2=A0 if (stack.size() < 2)
=C2=A0 =C2=A0 return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);=
=C2=A0 valtype vch1 =3D stacktop(-2);
=C2=A0 valtype vch2 =3D stacktop(-1);

=C2=A0 if (vch1.size() + vch2.size() > MAX_SCRIPT_ELEMENT_SIZE)
=C2=A0 =C2=A0 =C2=A0 return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPER= ATION);

=C2=A0 valtype vch3;
=C2=A0 vch3.reserve(vch1.size() + vch2.size());
=C2=A0 vch3.insert(vch3.end(), vch1.begin(), vch1.end());
=C2=A0 vch3.insert(vch3.end(), vch2.begin(), vch2.end());

=C2=A0 popstack(stack);
=C2=A0 popstack(stack);
=C2=A0 stack.push_back(vch3);
</pre>

The value of MAX_SCRIPT_ELEMENT_SIZE is 520 Bytes

=3D=3D Reference Implementation =3D=3D
[Elements](h= ttps://github.com/ElementsProject/elements/blob/master/src/script/interpret= er.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", 201= 5,
https://lists.linuxfoun= dation.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.linuxfoun= dation.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,
ht= tps://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-covenan= ts_cat_ecdsa-md
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000ddacf806083fc878--