Covenants

Covenants refer to a mechanism that allows certain conditions to be placed on how Bitcoin can be spent in the future. These conditions can restrict or guide future bitcoin transactions. Covenants have been proposed and discussed in Bitcoin Improvement Proposals (BIPs). For instance, a covenant might only permit transactions to a predefined list of addresses or impose a waiting period before funds can be transferred to any address. This concept aims to enhance Bitcoin’s scripting capabilities for various applications such as creating complex smart contracts.

Covenants may enhance Bitcoin’s security. For example, they can help prevent funds from being stolen in hacking incidents. Covenants also allow for controlled spending, where users can set conditions for how their Bitcoin can be used, adding an extra layer of security.

However, there are significant drawbacks as well. Covenants can reduce the fungibility of Bitcoin, limiting its free exchange and affecting its uniformity and exchangeability. While covenants can protect against theft, they can also be used by governments or other entities to impose control and censorship over bitcoin transactions. Finally, integrating covenants into Bitcoin’s existing consensus rules is technically complex and controversial. Some consider these added features to be inconsistent with Satoshi’s vision for Bitcoin.

Covenants offer potential security benefits but come with trade-offs that impact the fundamental nature of Bitcoin as a censorship-resistant and fungible asset.

➤ Learn more about how Bitcoin development works

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