From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4478AC0088 for ; Sun, 22 Oct 2023 09:08:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 82CEF709E6 for ; Sun, 22 Oct 2023 09:08:15 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 82CEF709E6 Authentication-Results: smtp3.osuosl.org; dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl header.a=rsa-sha256 header.s=2013 header.b=FzQsDeng X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 rRpmrrUWl-AD for ; Sun, 22 Oct 2023 09:08:11 +0000 (UTC) X-Greylist: delayed 596 seconds by postgrey-1.37 at util1.osuosl.org; Sun, 22 Oct 2023 09:08:10 UTC DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org A1BFE61135 Received: from smtpo46.poczta.onet.pl (smtpo46.poczta.onet.pl [213.180.142.177]) by smtp3.osuosl.org (Postfix) with ESMTPS id A1BFE61135 for ; Sun, 22 Oct 2023 09:08:10 +0000 (UTC) Received: from pmq3v.m5r2.onet (pmq3v.m5r2.onet [10.174.32.69]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4SCsfl3D46zlgMTm for ; Sun, 22 Oct 2023 10:58:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1697965087; bh=b1oI4bvd5fA4I9jZcvNq1XTTztQ4jVuCvETT5BXaeCs=; h=From:To:In-Reply-To:Date:Subject:From; b=FzQsDengYtJE9R0QB2SFa1G4W8yWgS6FTtfuEMrmKDloYBMw2m+hNBSEVElO0X0/A qPZLdwBzXXcjDL0rkTdc6Li3M0wLcsZYGM0h2c3ASC+k165CPI+oxx/RD1dXp4GuAx l1LvqTZexzhWayJ0znjmGPBvoQMWAX++NQVAGBtc= Content-Type: multipart/alternative; boundary="===============6779532027553930604==" MIME-Version: 1.0 Received: from [5.173.249.56] by pmq3v.m5r2.onet via HTTP id ; Sun, 22 Oct 2023 10:58:07 +0200 From: vjudeu@gazeta.pl X-Priority: 3 To: "Ethan Heilman , Bitcoin Protocol Discussion" , Bitcoin Dev In-Reply-To: Date: Sun, 22 Oct 2023 10:58:07 +0200 Message-Id: <194372901-852eeb9299035adb7fdfc7fe5aa21080@pmq3v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;5.173.249.56;PL;1 X-Mailman-Approved-At: Sun, 22 Oct 2023 09:37:23 +0000 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: Sun, 22 Oct 2023 09:08:16 -0000 This is a multi-part message in MIME format. --===============6779532027553930604== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > This opcode would be activated via a soft fork by redefining the opcode O= P_SUCCESS80. =C2=A0 Why OP_SUCCESS80, and not OP_SUCCESS126? When there is some existing opcode= , it should be reused. And if OP_RESERVED will ever be re-enabled, I think = it should behave in the same way, as in pre-Taproot, so it should "Mark tra= nsaction as invalid unless occuring in an unexecuted OP_IF branch". Which m= eans, " OP_VERIFY" should be equivalent to " OP_NOTIF= OP_RESERVED OP_ENDIF". =C2=A0 On 2023-10-21 07:09:13 user Ethan Heilman via bitcoin-dev wrote: Hi everyone, We've posted a draft BIP to propose enabling OP_CAT as Tapscri= pt opcode. https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.media= wiki 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 5= 20 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 value= s off the stack, # concatenate the popped values together, # and then pushe= s 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 co= mbining objects on the stack restricting the expressiveness and power of ta= pscript. For instance this prevents among many other things the ability to = construct and evaluate merkle trees and other hashed data structures in tap= script. OP_CAT by adding a general purpose way to concatenate stack values = would overcome this limitation and greatly increase the functionality of ta= pscript. 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 demonstrat= e the usefulness of OP_CAT below we provide a non-exhaustive list of some u= secases that OP_CAT would enable: * Tree Signatures provide a multisignatur= e 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 tha= n 1KB in size could support tree signatures with a thousand public keys. Th= is also enables generalized logical spend conditions. [2] * Post-Quantum La= mport Signatures in Bitcoin transactions. Lamport signatures merely require= s the ability to hash and concatenate values on the stack. [3] * Non-equivo= cation contracts [4] in tapscript provide a mechanism to punish equivocatio= n/double spending in Bitcoin payment channels. OP_CAT enables this by enfor= cing 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, h= ttps://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/blockstrea= m/cat-and-schnorr-tricks-i-faf1b59bd298 which would allow the creation of s= imple covenants and other advanced contracts without having to presign spen= ding 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 av= ailable in early versions of Bitcoin. However OP_CAT was removed because it= enabled the construction of a script for which an evaluation could have me= mory usage exponential in the size of the script. For instance a script whi= ch 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 T= erabyte. This is no longer an issue because tapscript enforces a maximum st= ack element size of 520 Bytes. =3D=3DSpecification=3D=3D Implementation if = (stack.size() < 2) return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERAT= ION); valtype vch1 =3D stacktop(-2); valtype vch2 =3D stacktop(-1); if (vch= 1.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.in= sert(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/Eleme= ntsProject/elements/blob/master/src/script/interpreter.cpp#L1043) =3D=3DRef= erences=3D=3D [1]: R. Pike and B. Kernighan, "Program design in the UNIX en= vironment", 1983, https://harmful.cat-v.org/cat-v/unix_prog_design.pdf [2]:= P. Wuille, "Multisig on steroids using tree signatures", 2015, https://lis= ts.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html [3]: J. = Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFrom= Stack for Arithmetic Values]", 2021, https://lists.linuxfoundation.org/pipe= rmail/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 B= itcoins", 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, Bi= tcoin 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@list= s.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bi= tcoin-dev --===============6779532027553930604== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
> This opcode would be activated via a soft fork by redefining the = opcode OP_SUCCESS80.
 
Why OP_SUCCESS80, and not OP_SUCCESS126? When there is some existing o= pcode, it should be reused. And if OP_RESERVED will ever be re-enabled, I t= hink it should behave in the same way, as in pre-Taproot, so it should "Mar= k transaction as invalid unless occuring in an unexecuted OP_IF branch". Wh= ich means, "<condition> OP_VERIFY" should be equivalent to "<condi= tion> OP_NOTIF OP_RESERVED OP_ENDIF".


 
On 2023-10-21 07:09:13 user 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 Imp=
lementation =3D=3D [Elements](https://github.com/ElementsProject/elements/b=
lob/master/src/script/interpreter.cpp#L1043) =3D=3DReferences=3D=3D [1]: R.=
 Pike and B. Kernighan, "Program design in the UNIX environment", 1983, htt=
ps://harmful.cat-v.org/cat-v/unix_prog_design.pdf [2]: P. Wuille, "Multisig=
 on steroids using tree signatures", 2015, https://lists.linuxfoundation.or=
g/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/202=
1-July/019233.html [4]: T. Ruffing, A. Kate, D. Schröder, "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=3Drep=
1&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 wi=
th CAT and ECDSA", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d1=
3170ec79bf34d5e85#file-covenants_cat_ecdsa-md _____________________________=
__________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundati=
on.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--===============6779532027553930604==--