What Does Jeremy Rubin’s Recent Call to Action Mean for Consensus Around Covenants?
Jeremy Rubin has called on the Bitcoin development community to build consensus around a covenant proposal, emphasizing the need for a structured and coordinated effort to introduce meaningful upgrades to Bitcoin’s scripting capabilities. Covenants are restrictions placed on how Bitcoin can be spent, enabling advanced functionalities such as payment pools, vaults, and congestion control. Rubin’s approach favors a phased implementation, beginning with OP_CHECKTEMPLATEVERIFY (CTV) and OP_CHECKSIGFROMSTACK (CSFS), followed by OP_CAT and additional cryptographic and arithmetic operations. These upgrades are designed to enhance Bitcoin’s programmability while maintaining security and decentralisation. However, Rubin acknowledges the difficulty in reaching consensus on protocol changes, as past upgrade attempts have shown that the Bitcoin community is highly cautious when modifying the base layer.
The challenge of achieving consensus in Bitcoin stems from its decentralised nature and the strong preference among developers for stability over rapid innovation. Unlike other blockchain ecosystems that frequently introduce new features, Bitcoin’s development process is deliberately slow and conservative. The reluctance to adopt changes without overwhelming agreement reflects concerns about potential security risks, unintended consequences, and the difficulty of reversing protocol modifications once implemented. Bitcoin upgrades require careful vetting, peer review, and rigorous testing before they can be activated, ensuring that any new feature does not introduce systemic vulnerabilities or alter the core principles of the network.
The introduction of covenants into Bitcoin, if adopted, could significantly expand the functionality of the network without compromising its security model. Features like CTV and CSFS would allow for more efficient transaction batching, improved privacy mechanisms, and enhanced scalability solutions such as Ark and Lightning Network channel factories. The second phase, incorporating OP_CAT and cryptographic operations, would further enhance Bitcoin’s scripting capabilities, enabling more sophisticated smart contract functionality while still avoiding the risks associated with Turing-complete programming languages found in other blockchain ecosystems, particularly those in Web3, where smart contracts have been exploited by bad actors on numerous occasions. Proponents argue that these changes would make Bitcoin more competitive in financial applications without introducing unnecessary complexity.
Ultimately, Rubin’s proposal highlights the tension between innovation and conservatism in Bitcoin development. While some developers advocate for the careful introduction of new features to expand Bitcoin’s use cases, others remain skeptical of any changes that could introduce centralisation risks or unintended consequences. The process of generating consensus around a covenant upgrade will require thorough discussion, technical validation, and community-wide support. If successful, these upgrades could pave the way for more efficient transaction mechanisms, enhanced financial applications, and greater flexibility in Bitcoin scripting, ensuring the network remains both censorship-resistant and adaptable to future needs. However, the outcome of this effort will depend on whether developers and the broader Bitcoin community can find common ground on the path forward.
Summary of Different Covenant Proposals in Bitcoin
The following Covenants are the leading proposed modifications to Bitcoin’s scripting system that would allow users to enforce conditions on how coins can be spent in the future. These proposals introduce new opcodes to enhance Bitcoin’s programmability while maintaining its security model. Below is a summary of the major covenant proposals, according to the website covenants.info:
1. OP_CHECKTEMPLATEVERIFY (CTV)
Overview: CTV allows transactions to specify predetermined spending conditions, enabling more efficient transaction batching, congestion control, and enhanced privacy mechanisms. It ensures that outputs must follow a specific spending template without enabling arbitrary computation.
Use Cases: Vaults, payment pools, congestion control, and Lightning Network channel factories.
Status: Proposed in BIP-119, widely discussed but yet to achieve full consensus.
2. OP_CHECKSIGFROMSTACK (CSFS)
Overview: CSFS allows Bitcoin scripts to verify signatures from arbitrary data, enabling smart contract-like functionalities. This makes it easier to construct complex transaction structures while preserving security.
Use Cases: Federated systems, secure vaults, Discreet Log Contracts (DLCs), and enhanced security mechanisms for multisignature wallets.
Status: Considered in conjunction with CTV for an initial covenant upgrade.
3. OP_CAT and Arithmetic & Cryptographic Operations
Overview: OP_CAT (concatenation) was previously removed from Bitcoin but is now reconsidered for reintroduction, alongside arithmetic and elliptic curve operations. These additions would improve Bitcoin’s scripting capabilities, allowing for more efficient execution of smart contract functions.
Use Cases: More flexible covenants, advanced cryptographic proofs, and improved multi-signature schemes.
Status: Controversial due to concerns over potential complexity and security risks.
4. OP_VAULT
Overview: OP_VAULT is designed specifically to improve Bitcoin custody security. It introduces a mechanism that enforces a delay before funds can be moved, providing a safety net against theft by allowing users to recover funds during the delay period.
Use Cases: High-security self-custody solutions, institutional Bitcoin storage, and protection against hacks or compromised keys.
Status: Being actively developed with a proposed BIP-345.
5. OP_TXHASH and OP_CHECKTXHASHVERIFY
Overview: These proposals extend CTV by allowing a script to commit to parts of a transaction rather than the entire output set. This provides more flexibility while maintaining some of the deterministic behavior of CTV.
Use Cases: More advanced smart contracts, improved Lightning Network functionalities, and customisable payment conditions.
Status: Still in early discussion and development.
6. ANYPREVOUT (APO)
Overview: Originally designed for the Eltoo Lightning Network upgrade, APO allows a transaction to be signed without specifying the exact input, enabling flexible payment structures and allowing for non-interactive channel updates.
Use Cases: Lightning Network upgrades ( Eltoo), statechains, and payment pools.
Status: Proposed in BIP-118, currently undergoing further evaluation.
7. OP_TAPLEAF_UPDATE_VERIFY (TLUV)
Overview: TLUV allows a taproot script to modify its internal tree structure and enforce conditions on how it can be spent in the future, providing a more advanced version of Bitcoin covenants.
Use Cases: Enabling fraud-proof smart contracts and dynamic covenant structures.
Status: Experimental and under discussion.
8. CATT (Covenant All The Things)
Overview: CATT is a comprehensive covenant framework that integrates OP_TXHASH , OP_CAT , CSFS , andarithmetic operations into a unified system, allowing developers to construct highly flexible smart contracts.
Use Cases: General-purpose transaction templating, decentralized finance applications, and scalable second-layer solutions.
Status: Still in theoretical stages, with various components under independent development.
9. MATT (Merkleize All The Things)
Overview: MATT uses Merkle trees to implement fraud-proof smart contracts, enabling complex programmable conditions without relying on external validation mechanisms.
Use Cases: Secure vaults, joinpools, and multi-stage financial contracts.
Status: In early conceptual and testing phases.
Which Proposals are Currently the Most Popular with the Bitcoin Community?
Among the current covenant proposals, OP_CHECKTEMPLATEVERIFY (CTV) and OP_CHECKSIGFROMSTACK (CSFS) are the most widely discussed and have gained significant traction. These proposals are seen as minimal yet impactful improvements, enabling transaction batching, congestion control, and more advanced smart contract-like capabilities without introducing excessive complexity. CTV, in particular, has undergone extensive review and is considered one of the least controversial proposals, as it does not enable arbitrary computation. Developers advocating for this upgrade, argue that it could be implemented with minimal risk and significant benefits to scaling and security.
Another covenant proposal gaining attention is OP_VAULT, which focuses on enhancing Bitcoin security by enabling time-locked recovery mechanisms for lost or stolen funds. This proposal has strong support from those concerned about self-custody risks, as it allows users to create vaults where funds can only be withdrawn after a delay, giving the owner time to intervene in case of unauthorized access. OP_VAULT has been particularly well received by those looking to improve Bitcoin’s usability for long-term savings and institutional custody, as it offers a built-in safety net against certain types of attacks. However, while the concept is widely appreciated, the challenge remains in achieving consensus on its implementation and activation method.
More ambitious proposals, such as OP_CAT and CATT (Covenant All The Things), have generated debate but face more resistance due to concerns over security, complexity, and potential unintended consequences. OP_CAT, which allows concatenation of data in Bitcoin scripts, would enable more powerful smart contracts but also raises concerns about increased miner extractable value (MEV) risks and the possibility of script-based centralization. While some developers advocate for a phased approach, starting with CTV and CSFS, then introducing OP_CAT along with arithmetic and elliptic curve operations, there is still hesitation within the broader Bitcoin development community. Overall, while CTV and CSFS appear to have the strongest backing for near-term activation, OP_VAULT and OP_CAT continue to generate interest, with discussions ongoing about their feasibility and potential trade-offs.
The post appeared first on Bitfinex blog.
