OP_CAT proposal for covenants on Bitcoin receives official BIP number

OP_CAT has finally received an official Bitcoin BTC +4.19% Improvement Proposal number, BIP-347, following an attempt to meme it into existence, as the ongoing debate surrounding covenants on Bitcoin continues.

“BIP-420 enables covenants on bitcoin, allowing for smart contracts, secure bridges, on-chain trading, zk proof verification and more,” OP_CAT advocate and co-founder of Taproot Wizards Udi Wertheimer posted on Monday. The problem was that "BIP-420" is not an official Bitcoin Improvement Proposal and just represents a draft proposal for OP_CAT, in an update to a prior version.

However, the plan seemed to work and OP_CAT was subsequently assigned BIP-347. The official BIP number was assigned by one of five newly named BIP editors for Bitcoin, Olaoluwa Osuntokun, also known as “Roasbeef,” the CTO of Lightning Labs. The Bitcoin community will now decide whether to move forward with the controversial proposal in a process that could potentially take years.

What are covenants and OP_CAT?

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 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 any such 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 chances 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, 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.

Updates to headline and additional details throughout.