BIP-420 formally introduces OP_CAT proposal for covenants on Bitcoin

“Today, after a long wait, the OP_CAT proposal formally received a BIP number. Meet BIP-420!,” OP_CAT advocate and co-founder of Taproot Wizards Udi Wertheimer posted late Monday. “BIP-420 enables covenants on bitcoin, allowing for smart contracts, secure bridges, on-chain trading, zk proof verification and more.”

Generally speaking, covenants on Bitcoin are advanced scripting features that allow for specific conditions on how bitcoins can be spent in future transactions. They could enable use cases, including the creation of secure "vaults" that allow reversible transactions, automated recurring payments, time-locked transfers for scenarios like inheritance, and complex financial instruments such as escrows and bonds.

OP_CAT was originally included as one of the first opcodes in Bitcoin. However, pseudonymous creator Satoshi Nakamoto disabled it alongside several other opcodes in 2010 due to concerns surrounding the potential for creating scripts that could lead to vulnerabilities.

An opcode refers to a command used in the scripting language that makes up part of the Bitcoin protocol. Bitcoin scripts are made up of sequences of opcodes, each of which performs a specific operation.

The BIP-420 proposal, authored by Ethan Heilman and Armin Sabouri, seeks to reintroduce OP_CAT to Bitcoin via a backward-compatible soft fork by “redefining the opcode OP_SUCCESS126.”

This is the same opcode value used by the original OP_CAT, designed to remove any potential confusion by not using a different opcode value. The proposal focuses solely on the reintroduction of the opcode without altering other aspects of the script's operational limits.

According to the proposal, the OP_CAT opcode would simplify and expand Bitcoin’s functionalities, including making decentralized protocols more practical and supporting advanced multi-sig setups. Essentially, OP_CAT would significantly increase the power and flexibility of Bitcoin scripting, making it easier to develop more sophisticated applications directly on the Bitcoin blockchain, the authors argue.

However, the likelihood of an OP_CAT soft fork is contingent on a combination of technical, security and community consensus considerations. Without broad agreement and a clear demonstration of its safety and utility, OP_CAT's implementation remains uncertain.

Other Bitcoin covenant proposals

The concept of covenants in Bitcoin has been discussed for several years, dating back to at least 2013. Integrating covenants into Bitcoin could significantly expand its functionality, bringing it closer to programmatically flexible platforms like Ethereum but also raising concerns regarding complexity and potential security risks.

OP_CAT is not the only Bitcoin covenant proposal on the table, with others including CTV, CSFS and LNHANCE, each varying in its approach and trade-offs and at different stages of research and debate.

Check Template Verify (CTV) was proposed by Jeremy Rubin in BIP-119, introducing a new opcode that ensures only transactions matching a predefined template can spend the bitcoins, enabling use cases like vaults, congestion control and legacy multisig migration.

OP_CHECKSIGFROMSTACK (CSFS) was proposed by various developers, including Rubin, allowing the validation of a signature with a message and public key specified in the script, independent of the transaction. CSFS is considered in some ways more flexible and powerful than CTV, potentially enabling a broader range of applications.

LNHANCE proposes adding even more flexible scripting possibilities, including loops and conditional execution based on external data. It’s a more conceptual and less formalized proposal compared to others.