OP_CAT

Concatenation sounds trivial and is not. With it, a script can reassemble a transaction's signature hash from parts pushed on the stack, in chunks of no more than 520 bytes, and then check that hash using an ordinary signature check. That is how an opcode switched off for being dangerous became the most discussed item on the covenant list.

How it works

Status: disabled since August 2010, when a batch of string and arithmetic opcodes was switched off in a defensive sweep of the script engine. BIP-347 proposes re-enabling it in tapscript only. It is not active on mainnet.

The operation itself is one line: pop two elements, push their bytes joined end to end. The reason it was dangerous in 2010 is that nothing capped how large a stack element could grow. Concatenating an element with itself doubles it, so a short loop of pushes and joins could inflate a few bytes into gigabytes and take the node's memory with it. The modern engine has a hard 520-byte limit on any single stack element, so BIP-347 simply fails the operation when the result would exceed it, and the old attack disappears.

There is a quirk of numbering that makes the revival unusually clean. OP_CAT is opcode 126. When BIP-342 defined tapscript it declared opcodes 126 through 129, among others, to be OP_SUCCESS: encountering one makes the script succeed on the spot. Old nodes therefore already accept any tapscript containing byte 126 without executing it. Redefining it to do concatenation only narrows what those nodes would have allowed, which makes the change a soft fork rather than a chain split.

What concatenation unlocks is out of proportion to its size. A script that can build byte strings can verify a Merkle proof, check a Lamport or Winternitz signature built from hashes rather than elliptic curves, and force a signature to use a fixed nonce so that the signature equation itself exposes the spending transaction to the script. That last trick is the one that turns OP_CAT into a general covenant tool without any covenant-specific opcode.

Where you see it

OP_CAT does not run on bitcoin at all. The places it does run are the sidechains and test networks that copied bitcoin's script engine and then reversed the 2010 decision.

Elements, and therefore Liquid, has the opcode enabled, which is why most published covenant demonstrations are written against Liquid rather than bitcoin. Custom signets carrying the BIP-347 rules are the other venue, and they exist so that developers can build the thing before asking anyone to change consensus.

For someone buying or holding coins, the practical content is short: nothing about your wallet, your addresses or your backups changes if OP_CAT activates or if it never does. It is worth knowing the name because it sits at the centre of a real disagreement about how much programmability bitcoin should have, and because proposals to add hash-based signatures for a future with quantum computers tend to route through it.