Skip to content

Latest commit

 

History

History
89 lines (69 loc) · 7.04 KB

cat.mediawiki

File metadata and controls

89 lines (69 loc) · 7.04 KB
Raw

  BIP: ???
  Layer: Consensus (soft fork)
  Title: OP_CAT
  Author: Ethan Heilman <ethan.r.heilman@gmail.com>
          Armin Sabouri <arminsdev@gmail.com>
  Status: Draft
  Type: Standards Track
  Created: 2023-10-21
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-op-cat
  License: BSD-3-Clause

Table of Contents

Abstract

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

When evaluated the OP_CAT instruction:

  1. Pops the top two values off the stack,
  2. concatenate the popped values together,
  3. 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.

Motivation

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 expands 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:

  • Bitstream, a protocol for the atomic swap (fair exchange) of bitcoins for decryption keys, that enables decentralized file hosting systems paid in Bitcoin. While such swaps are currently possible on Bitcoin without OP_CAT they require the use of complex and computationally expensive Verifiable Computation cryptographic techniques. OP_CAT would remove this requirement on Verifiable Computation, making such protocols far more practical to build in Bitcoin. [2]
  • 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. [3]
  • Post-Quantum Lamport Signatures in Bitcoin transactions. Lamport signatures merely requires the ability to hash and concatenate values on the stack. [4]
  • Non-equivocation contracts [5] 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 [6] 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 [7] OP_CAT is sufficent to build vaults in Bitcoin.
  • Replicating CheckSigFromStack [8] 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 [9].
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.

Specification

OP_CAT pops two elements of the stack, concatenates them together in stack order and pushes the resultant element onto the stack. Given the stack [x1,x2], where x2 is at the top of the stack, OP_CAT will push x1||x2 onto the stack. By '||' we denote concatenation.

Implementation 

case OP_CAT:
{
    if (stack.size() < 2)
        return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
    valtype& vch1 = stacktop(-2);
    valtype& vch2 = stacktop(-1);
    if (vch1.size() + vch2.size() > MAX_SCRIPT_ELEMENT_SIZE)
        return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
    vch1.insert(vch1.end(), vch2.begin(), vch2.end());
    stack.pop_back();
}
break;
This implementation is inspired by the original implementation of OP_CAT as shown below. Alternative implementation of OP_CAT can be found in Elements [10].

The value of MAX_SCRIPT_ELEMENT_SIZE is 520 Bytes

Notes

OP_CAT as it existed in the Bitcoin codebase prior to the commit "misc changes" 4bd188c[11] which disabled it. 

  // (x1 x2 -- out)
  if (stack.size() < 2)
    return false;
  valtype& vch1 = stacktop(-2);
  valtype& vch2 = stacktop(-1);
  vch1.insert(vch1.end(), vch2.begin(), vch2.end());
  stack.pop_back();
  if (stacktop(-1).size() > 5000)
    return false;
  }

References

  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. ^ R. Linus, "BitStream: Decentralized File Hosting Incentivised via Bitcoin Payments", 2023, https://robinlinus.com/bitstream.pdf
  3. ^ P. Wuille, "Multisig on steroids using tree signatures", 2015, https://blog.blockstream.com/en-treesignatures/
  4. ^ J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html
  5. ^ 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=10.1.1.727.6262&rep=rep1&type=pdf
  6. ^ M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants, http://fc16.ifca.ai/bitcoin/papers/MES16.pdf
  7. ^ A. Poelstra, "CAT and Schnorr Tricks II", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html
  8. ^ A. Poelstra, "CAT and Schnorr Tricks I", 2021, https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
  9. ^ R. Linus, "Covenants with CAT and ECDSA", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file-covenants_cat_ecdsa-md
  10. ^ Roose S., Elements Project, "Re-enable several disabled opcodes", 2019, https://github.com/ElementsProject/elements/commit/13e1103abe3e328c5a4e2039b51a546f8be6c60a#diff-a0337ffd7259e8c7c9a7786d6dbd420c80abfa1afdb34ebae3261109d9ae3c19R740-R759
  11. ^ S. Nakamoto, "misc changes", Aug 25 2010, https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82#diff-27496895958ca30c47bbb873299a2ad7a7ea1003a9faa96b317250e3b7aa1fefL381

Acknowledgements

We wish to acknowledge Dan Gould for encouraging and helping review this effort.

Copyright

This document is placed in the public domain.