Covenant

A Bitcoin Covenant is a type of transaction where the transaction’s output places conditions on how that particular output can be spent in the future. These spending constraints are distinct from those that already exist in Bitcoin transactions—where a valid signature and a particular pubkey are required to spend a UTXO.

Covenants extend Bitcoin’s script in meaningful ways; they enable use cases such as secure vaults, 2-way pegged drivechains, reduced spending on fees, decentralized options trading, batched lightning channel opens, multiparty (3+) lightning channels, and more.

Instead of going through each covenant implementation proposal, we will categorize them based upon functionality.

Generalized: These covenants are flexible in the applications and use cases enabled. The trade-offs here are that this flexibility comes with increased implementation complexities and the potential for tricky edge cases.

Restrictive: As the name implies, these covenants are focused on enabling a specific feature set and not much else—vaults, for example. The reduced functional scope of these proposals also reduces the complexities around implementation.

Another way to classify covenants is by examining if and how their constraints are propagated into the future. Covenants that replicate themselves and their rules into future UXTOs to which funds are sent, without limitation, are called Recursive. Conversely, those that apply their rules for one “round” of value flowing through whatever logic tree is implemented are called Non-recursive.

We can also consider how these proposed covenants would be implemented; if they are opcode-based, then a soft fork will be required in order to add any new operation(s) to Bitcoin script.

Signature-based covenants—wherein future (presigned) transactions can have their attributes verified by constructing them while executing the script and comparing hash values with OP_CHECKSIG—would not require a soft fork to implement.

“The main idea behind this category of covenants is that, while transaction information is not directly available inside Script, it is used to construct the value hash(tx) used internally in OP_CHECKSIG, so it’s possible to perform comparisons against it indirectly through hacks in the signatures passed to OP_CHECKSIG.” - bitcoincovenants.com

The trade-off with signature-based covenants is that all possible future transactions would need to be built, and signed, which means that users would have to commit to specific fee rates and private keys.

Additional Resources (non-exhaustive list of proposals):

• OP_CTV aka CHECKTEMPLATEVERIFY (BIP 119)
• OP_TX (alternate proposal to CTV)
• OP_TLUV aka TAPLEAFUPDATEVERIFY
• OP_EVICT (alternative proposal to TLUV)
• OP_VAULT (BIP 345) ; River’s OP_VAULT article
• APO aka ANYPREVOUT BIP 118
• OP_TXHASH + OP_CHECKSIGFROMSTACKVERIFY (Alternative to CTV + APO)
• OP_CHECKSIGFROMSTACK