Authors: Jeffrey HU & Harper LI, HashKey Capital
Recently, there has been a wave of discussions within the Bitcoin community about the reintroduction of OP_CAT and other opcodes. Taproot Wizard has also attracted a lot of attention by launching Quantum Cats NFTs and claiming to have obtained the BIP-420 number. Supporters claim that enabling OP_CAT can enable “covenants” and achieve smart contracts or programmability in Bitcoin.
If you pay attention to the term “covenants” and do a quick search, you will discover another significant concept. Developers have been discussing various technologies for implementing covenants for many years, including OP_CTV, APO, OP_VAULT, and more.
So, what exactly are “covenants” in Bitcoin? Why have they attracted the continuous attention and discussion of developers for years? What programmability can they bring to Bitcoin? What are the underlying design principles? This article aims to provide an overview and discussion of these questions.
What are “Covenants”?
Covenants are mechanisms that allow conditions to be set for future Bitcoin transactions. The current Bitcoin script already includes conditions such as requiring valid signatures or scripts when spending. However, as long as the user can unlock it, they can spend the UTXO anywhere they want.
Covenants, on the other hand, add additional restrictions based on how the unlocking is done. For example, they can limit the spending of UTXOs, achieving a “special-purpose” effect, or impose additional input conditions in a transaction. In essence, covenants can directly restrict further spending in Bitcoin scripts, thereby achieving transaction rules similar to smart contracts.
To be more precise, the current Bitcoin script already has some form of covenants, such as opcode-based time locks, which use the nLock or nSequence fields of the transaction to impose time restrictions on spending. However, these restrictions are mainly limited to time-related conditions.
So why do developers and researchers design these covenant checks? Because covenants are not just about restrictions, they set rules for transaction execution. This way, users can only execute transactions according to pre-defined rules, completing predetermined business processes.
Therefore, it is counterintuitive that this can unlock more application scenarios.
Applications of Covenants
Ensuring Staking Penalties
One of the most intuitive examples of covenants is the “slash” transaction in the Babylon Bitcoin staking process.
In the Babylon Bitcoin staking process, users send their BTC assets to a special script on the main chain. There are two spending conditions:
– Happy ending: After a certain period of time, the user can unlock it with their signature, completing the unstaking process.
– Bad ending: If the user engages in malicious behavior, such as double-spending on a PoS chain secured by Babylon, the assets can be unlocked using Extractable One-Time Signatures (EOTS). A portion of the assets will be forcibly sent to a burning address (slash) by executing roles in the network.
Note the term “forcibly sent”. This means that even if the UTXO can be unlocked, the assets cannot be sent anywhere else and must be burned. This ensures that malicious users cannot use their known signatures to transfer the assets back to themselves to escape punishment.
This feature can be implemented in the “bad ending” branch of the staking script by introducing opcodes like OP_CTV after OP_CTV is enabled. Before OP_CTV is enabled, Babylon needs to simulate the enforcement of covenant restrictions through alternative methods, executed by users and committees.
Congestion Control
Congestion refers to the situation when the fee rate on the Bitcoin network is high, and there are many transactions waiting to be included in blocks in the mempool. To ensure quick confirmation of transactions, users have to increase the transaction fees.
If a user needs to send multiple transactions to multiple recipients at the same time, they would have to increase the fees and bear higher costs. This also further increases the overall network fee rate.
With the introduction of covenants, one solution is for the sender to commit to a batch transaction. This commitment assures all recipients that the transactions will eventually be executed, and they can wait for a lower fee rate to send the specific transactions.
When the demand for block space is high, transactions become expensive. By using OP_CHECKTEMPLATEVERIFY, large payment processors can aggregate all their payments into a single transaction with O(1) complexity for confirmation. Later, when the demand for block space decreases, payments can be extended from that UTXO.
This scenario is a typical application case proposed by OP_CTV. More application cases can be found at https://utxos.org/uses/, which includes congestion control, Soft Fork Bets, Decentralized options, Drivechains, Batch Channels, Non-Interactive Channels, Trustless Coordination-Free Mining Pools, Vaults, and Safer Hashed Time Locked Contracts (HTLCS) Limits.
Vaults
Vaults are a widely discussed application scenario within the Bitcoin ecosystem, especially in the field of covenants. Because there is a need to balance between asset custody and usage, people hope to have a type of vault application that can ensure asset security and limit their usage even if the account is compromised (private key leaked).
Based on covenant technologies, vault-like applications can be easily constructed. Take the design of OP_VAULT as an example: when spending funds from a vault, a triggering transaction needs to be sent to the blockchain. This transaction indicates the intention to spend from the vault and sets conditions:
– If everything goes well, the second transaction is the final withdrawal transaction. After waiting for N blocks, the funds can be further spent anywhere.
– If it is discovered that the triggering transaction is stolen (or coerced in a “wrench attack”), before the withdrawal transaction after N blocks is sent, it can be immediately sent to another secure address (a safer custody for the user).
It is worth noting that without covenants, a vault application can still be built. One feasible method is to prepare the signatures for future spending with a private key and then destroy that private key. However, there are still many restrictions, such as ensuring that the private key has been destroyed (similar to the trusted setup process in zero-knowledge proofs), determining the amount and fees in advance (due to pre-signing), and lack of flexibility.
More Robust and Flexible State Channels
In general, state channels, including the Lightning Network, are considered to have security similar to the main chain (as long as the latest state is observable and can be published on-chain). However, with the introduction of covenants, new design ideas for state channels can be more robust or flexible on top of the Lightning Network. Some well-known examples include Eltoo and Ark.
Eltoo (also known as LN-Symmetry) is a typical example. This technology proposes an execution layer for the Lightning Network, allowing any subsequent channel state to replace the previous state without the need for a punishment mechanism. This also eliminates the need for Lightning Network nodes to store multiple previous states to prevent malicious behavior by counterparts. To achieve this, Eltoo introduces the SIGHASH_NOINPUT signature scheme, known as APO (BIP-118).
Ark aims to reduce the difficulty of inbound liquidity and channel management in the Lightning Network. It is a protocol in the form of joinpools, where multiple users can accept a service provider as a counterparty for a certain period. They can conduct off-chain virtual UTXO (vUTXO) transactions while sharing a UTXO on-chain to reduce costs. Similar to vaults, Ark can also be implemented on the current Bitcoin network. However, with the introduction of covenants, Ark can reduce the required interaction based on transaction templates, achieving a more trustless unilateral exit.
Overview of Covenant Technologies
From the above applications, it can be seen that covenants are more of an effect rather than a specific technology, which means there are many ways to implement them. If we classify them, they can be categorized based on:
– Type: General-purpose, special-purpose
– Implementation: Opcode-based, signature-based
– Recursion: Recursive, non-recursive
Recursion refers to the ability of some covenant implementations to restrict the spending of the next output, thereby limiting the spending of subsequent outputs and achieving a higher depth of transactions.
Some mainstream covenant designs include:
– OP_CTV: Covenant-based on opcode
– OP_CAT: Concatenation-based covenant
– APO (BIP-118): Signature-based covenant
Designing Covenant Restrictions
From the previous introduction, it can be seen that the current Bitcoin script mainly restricts the unlocking conditions, without limiting how the UTXO can be further spent. To implement covenants, we need to think the other way around: why can’t the current Bitcoin script achieve covenant restrictions?
The main reason is that the current Bitcoin script lacks the ability to restrict how UTXOs can be spent further. Covenant restrictions require additional capabilities beyond the current script.
Conclusion
Covenants are mechanisms that allow conditions to be set for future Bitcoin transactions, enabling programmability and smart contract-like features. They have diverse applications, including ensuring staking penalties, congestion control, vaults, and more. With the introduction of covenant technologies such as OP_CTV, Bitcoin’s programmability can be enhanced, unlocking new possibilities for the ecosystem.Bitcoin Script currently lacks the ability to read the contents of a transaction itself, also known as “introspection”. The design of restrictive clauses revolves around how to achieve introspection.
There are two main approaches to achieve introspection: opcode-based and signature-based. The opcode-based approach involves adding one or more opcodes that directly read the contents of the transaction. On the other hand, the signature-based approach utilizes the hash of the transaction, allowing for indirect introspection by modifying opcodes like OP_CHECKSIG to check the signature. This approach includes proposals like APO and OP_CSFS.
APO is a proposed Bitcoin signature scheme called SIGHASH_ANYPREVOUT. Unlike traditional signatures that commit to both inputs and outputs of a transaction, APO only signs the outputs. This means that a transaction signed with APO can be attached to any UTXO that meets the conditions specified in the previously created transactions. This flexibility forms the theoretical basis for implementing restrictive clauses.
By creating one or more transactions in advance and constructing a public key that can only be solved by a single signature using the information from these transactions, it is possible to restrict the spending of assets sent to that address. The assets can only be spent through the pre-created transactions, allowing for the implementation of restrictive clauses.
This concept can be further understood by comparing it to Ethereum’s smart contracts, where funds can only be withdrawn under certain conditions, rather than being spent with a single EOA signature. Bitcoin’s improved signature mechanism allows for similar functionality.
However, the challenge in this process lies in the presence of circular dependencies during computation, as the input’s content is needed to pre-sign and create the transaction. APO and SIGHASH_NOINPUT address this issue by allowing computation with just the outputs of the specified transaction.
OP_CHECKTEMPLATEVERIFY (CTV), also known as BIP-119, is another proposed opcode that improves the functionality of Bitcoin Script. It requires any transaction executing the opcode to include a set of outputs that match a commitment hash. CTV allows Bitcoin users to restrict the way they use their funds. Initially introduced as OP_CHECKOUTPUTSHASHVERIFY (COSHV), it focused on congestion control transactions. The criticism of this proposal was that it was too specific to congestion control and not general enough.
In the congestion control use case mentioned earlier, the sender, Alice, can create ten outputs and hash them to create a digest. She can then use this digest to create a tapleaf script that includes COSHV. Alice can also use participants’ public keys to form internal Taproot keys, allowing them to collaborate on spending without revealing the Taproot script path. By providing each recipient with a copy of all ten outputs, they can verify Alice’s setup transaction. When any of them want to spend this payment later, they can create a transaction containing the committed outputs.
CTV proposes checking if the spending transaction, after being hashed, matches the defined commitment. This allows transaction data to act as the key to unlocking the script.
OP_CAT is another opcode that is currently receiving attention as an upgrade proposal. It concatenates two elements in the stack. Although seemingly simple, OP_CAT can be used flexibly to achieve various functionalities in scripts.
For example, it can be used to implement Merkle tree verification by concatenating two elements before hashing them. Additionally, OP_CAT can enhance Schnorr signatures by setting the spending condition in the script as a concatenation of the user’s public key and a publicly disclosed nonce. This ensures the validity of signed transactions as using a different nonce would reveal the private key. OP_CAT also has applications in Bistream, tree signatures, quantum-resistant Lamport signatures, and custody solutions.
OP_CAT was present in early versions of Bitcoin but was disabled in 2010 due to potential exploitation. However, the current OP_CAT proposal only enables it in tapscript, which limits each stack element to 520 bytes, preventing stack explosions.
In conclusion, restrictive clauses can be implemented in Bitcoin Script to further limit spending in transactions, similar to the effects of smart contracts. This programming approach allows for native verification on the Bitcoin network and can improve on-chain applications (congestion control), off-chain applications (state channels), and other new application directions (staking penalties). However, the implementation of restrictive clauses requires careful consideration due to potential misuse or vulnerabilities. It also requires consensus rule upgrades, which may take time to complete.
