Proposed BIP for OP_CAT

A programmer named Ethan Heilman sent an email to the bitcoin-dev mailing list proposing a new BIP (Bitcoin Improvement Proposal) for enabling the OP_CAT opcode as a Tapscript opcode. The draft BIP can be found on GitHub [1].

OP_CAT is a opcode that allows the concatenation of two values on the stack. It 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, concatenates them together, and then pushes the concatenated value back onto the stack. However, OP_CAT fails if there are less than two values on the stack or if the concatenated value would exceed the maximum script element size of 520 Bytes [2].

The motivation behind introducing OP_CAT is to overcome the limitation of Bitcoin tapscript lacking a general purpose way of combining objects on the stack. This limitation restricts the expressiveness and power of tapscript and prevents the construction and evaluation of merkle trees and other hashed data structures in tapscript. Introducing OP_CAT would greatly increase the functionality of tapscript and expand the toolbox of tapscript developers with a simple, modular, and useful opcode [3].

The email also provides a non-exhaustive list of use cases that OP_CAT would enable. These include tree signatures, post-quantum Lamport signatures, non-equivocation contracts in tapscript, vaults, and replicating CheckSigFromStack [4] [5] [6]. Each of these use cases demonstrates the usefulness of OP_CAT in different scenarios.

In early versions of Bitcoin, the opcode OP_CAT was available but later removed due to the possibility of memory usage exponential in the size of the script. However, this is no longer an issue because tapscript enforces a maximum stack element size of 520 Bytes, which ensures that the memory usage is limited [7].

The specification of the OP_CAT opcode is provided in the email, along with a reference implementation from the Elements project [8]. The value of MAX_SCRIPT_ELEMENT_SIZE is defined as 520 Bytes.

The email also includes several references to related papers and discussions on the bitcoin-dev mailing list, providing further background and context for the proposed OP_CAT opcode [1] [2] [3] [4] [5] [6].

Overall, Ethan Heilman's email proposes the activation of the OP_CAT opcode as a Tapscript opcode through a soft fork, highlighting its potential benefits and use cases for expanding the functionality of tapscript in Bitcoin.