Alpha Kimchi

Live bro

OP_CAT is a Bitcoin Script opcode that concatenates the top two stack elements into one. “CAT” stands for concatenate. Its opcode number is 126 (0x7e). It is still disabled on Bitcoin mainnet and is proposed for re-enablement as a soft fork in BIP 347. What it does Bitcoin Script is stack-based: data is pushed onto the stack, and opcodes act on the top elements. OP_CAT: Pops the top two values. Joins their bytes end to end. Pushes the result back onto the stack. Example: 0xB10C and 0xCAFE become 0xB10CCAFE. The script fails if there are fewer than two elements, or if the result exceeds the maximum script element size (520 bytes in Tapscript). Why it was disabled OP_CAT was in early Bitcoin. In 2010 (around Bitcoin 0.3.10), Satoshi disabled it along with other opcodes, including arithmetic ones such as OP_MUL. The concern was denial of service. There was no hard cap that stopped a stack element from growing. A short script using OP_DUP and OP_CAT repeatedly could double the data each step. In theory that could produce an enormous element and exhaust a validating node’s memory. The removal was a conservative choice for a young network. Why it is proposed again Taproot (November 2021) introduced Tapscript with a hard 520-byte limit on any single stack element. That closes the old attack: OP_CAT can still run, but the result cannot exceed 520 bytes. BIP 347 (Ethan Heilman and Armin Sabouri) proposes restoring OP_CAT only in Tapscript by redefining OP_SUCCESS126, the same opcode value as the original OP_CAT. Because old nodes already treat that opcode as OP_SUCCESS, giving it stricter behavior is a soft fork, not a hard fork. The BIP specification is marked Complete (finalized around March 2026). That does not mean activation consensus exists. As of October 2026, OP_CAT is not active on mainnet and has no official activation parameters. Why a simple opcode matters By itself, OP_CAT only joins data. Its power comes from combining it with existing cryptography, especially Schnorr signatures (BIP 340) and OP_CHECKSIG. Script can also “invert” operations by requiring the spender to supply pieces that are then checked. That enables: Transaction introspection (covenants). Signature tricks plus concatenation can put a transaction hash on the stack, so a script can constrain how the coin is spent (destination, amount, and so on). A covenant is a rule that limits future spends. Merkle proof verification. Leaves and internal nodes can be concatenated and hashed in order, so a script can check a Merkle proof. Tapscript does not offer this generically today. Vaults and bonds. A known pattern forces a fixed public nonce to be concatenated with the signature scalar. Signing two different transactions with the same nonce leaks the private key. That is the basis of an equivocation bond. BitVM and hashed data structures. BIP 347 cites smaller BitVM transactions and removal of a trusted setup in some designs, plus general Merkle-tree construction. Recursive covenants. Unlike deliberately limited proposals such as OP_CTV, OP_CAT can restrict the next transaction, which can restrict the one after that. This is the main point of controversy. Some uses need only OP_CAT plus opcodes that already exist. Others are more practical with extra opcodes such as OP_CHECKSIGFROMSTACK. Debate and alternatives Supporters see a small change that restores a general primitive, already used on other networks, and useful for vaults, more efficient channels, and limited contracts without turning Bitcoin into a general-purpose chain. Critics worry that broad expressiveness, especially recursive covenants, could enable behavior part of the community does not want, and that any consensus change adds risk. Some prefer ossification after Taproot. Common alternatives: OP_CTV (BIP 119): a non-recursive covenant that commits to a transaction template. Narrower by design. OP_CHECKSIGFROMSTACK, OP_TXHASH, and others: more direct introspection primitives, with different script-size and complexity trade-offs. As of October 2026, no covenant proposal is active on mainnet. OP_CAT has been heavily tested on signet (tens of thousands of transactions in environments such as Bitcoin Inquisition) but has no activation client. OP_CTV has had a signaling window, with very low reported miner support. OP_CAT has run for years on Liquid (Elements) and Bitcoin Cash, and on sidechains such as Fractal, without a known public incident of the old memory-exhaustion attack. That is operational evidence, not mainnet consensus. In short: OP_CAT joins two stack items. Satoshi disabled it in 2010 over unbounded memory growth. The 520-byte Tapscript limit removes that risk, so BIP 347 proposes restoring it in Tapscript only. The opcode is simple, but enough to enable covenants and on-script data-structure checks that Bitcoin Script cannot do cleanly today. by @JeremyRubin