Exploring Covenants: How to Bring Native Programmability to Bitcoin

Author: Jeffrey HU & Harper LI, HashKey Capital

Recently, there has been a wave of discussion in the Bitcoin community about re-enabling opcodes such as OP_CAT. 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 implement "covenants" and realize Bitcoin's smart contracts or programmability.

If you notice the word "covenants" and search for it, you will find that this is another big rabbit hole. Developers have been discussing it for years. In addition to OP_CAT, there are also OP_CTV, APO, OP_VAULT and other technologies for implementing covenants.

So, what exactly is Bitcoin's "restrictive clauses"? Why has it attracted so many developers' attention and discussion for years? What programmability can Bitcoin achieve? What is the design principle behind it? This article attempts to give an overview and discussion.

What are "restrictive clauses"?

Covenants, translated into Chinese as "restrictive clauses", are sometimes translated as "contracts", which is a mechanism that can set conditions for future Bitcoin transactions.

The current Bitcoin script also contains restrictive conditions, such as entering a legal signature when spending and sending a matching script. But as long as the user can unlock it, he can spend the UTXO wherever he wants.

The restriction clause is to make more restrictions on how to unlock it, such as limiting the subsequent spending of UTXO, that is, to achieve a similar effect of "earmarked funds for specific purposes"; or other input conditions sent in a transaction, etc. In the final analysis, the restriction clause can directly limit the further spending of the transaction in the Bitcoin script, thereby realizing transaction rules similar to the effect of smart contracts.

More rigorously speaking, the current Bitcoin script also has certain restriction clauses, such as the time lock based on the opcode, which is to achieve the time limit before the transaction is spent by introspecting the nLock or nSequence field of the transaction, but it is basically limited to time restrictions.

So why do developers and researchers design these restriction checks? Because restrictions are not just restrictions for the sake of restrictions, but also set rules for transaction execution. In this way, users can only execute transactions according to pre-set rules to complete the predetermined business process.

So it is counterintuitive that this can unlock more application scenarios.

Covenants Application Scenarios

Ensure Staking Penalties

One ​​of the most intuitive examples of restriction clauses is Babylon's slash transaction in the Bitcoin staking process.

Babylon's Bitcoin staking process is that users send their BTC assets to a special script on the main chain. The spending conditions include two types:

·Happy ending:After a certain period of time, the user can unlock it with his own signature, completing the unstake process

·Bad ending: If the user has double signatures and other malicious behaviors on a PoS chain that is rented by Babylon for security, then through EOTS (extractable one-time signatures), this part of the assets can be unlocked, and the executive role in the network will forcibly send part of the assets to the burning address (slash)

（Source: Bitcoin Staking: Unlocking 21M Bitcoins to Secure the Proof-of-Stake Economy）

Note the "forced send" here, which means that even if the UTXO can be unlocked, the asset cannot be sent to any other place at will and can only be burned. This ensures that malicious users cannot use their known signatures to transfer assets back to themselves first to escape punishment.

If this function is implemented after the restriction clauses such as OP_CTV, OP_CTV and other opcodes can be added to the "bad ending" branch of the staking script to implement the restriction.

Before OP_CTV is enabled, Babylon needs to use a workaround method, in which users + committees jointly execute to simulate the effect of enforcing the restriction clauses.

Congestion Control

Generally speaking, congestion refers to when the transaction fee rate on the Bitcoin network is high and there are many transactions waiting to be packaged in the transaction pool, so if users want to confirm transactions quickly, they need to increase the transaction fee.

At this time, if a user must send multiple transactions to multiple recipients, they have to increase the transaction fee and bear a relatively high cost. At the same time, it will also further push up the transaction fee rate of the entire network.

If there are restrictions, one solution is that the sender can first commit to a batch of transactions. This commitment can make all recipients believe that the final transaction will be carried out, and they can wait until the transaction fee rate is low to send specific transactions.

As shown in the figure below, when the demand for block space is high, it becomes very expensive to conduct transactions. By using OP_CHECKTEMPLATEVERIFY, high-volume payment processors can aggregate all of their payments into a single O(1) transaction for confirmation. Then, over time, when demand for block space decreases, payments can be expanded from that UTXO.

（Source: https://utxos.org/uses/scaling/）

This scenario is a typical application case proposed by the OP_CTV restriction clause. There are more application cases that can be found at https://utxos.org/uses/. In addition to the above congestion control, the webpage lists Soft Fork Bets, Decentralized options, Drivechains, Batch Channels, Non Interactive Channels, Trustless Coordination-Free Mining Pools, Vaults, Safer Hashed Time Locked Contracts (HTLCS) Limits, etc.

Vaults

Vaults are a widely discussed application scenario in Bitcoin applications, especially in the field of restriction clauses. Because daily operations inevitably have to balance the need for fund custody and fund use, people hope to have a type of vault application: it can ensure the safety of funds, and even limit the use of funds even if the account is hacked (private key leaked).

Based on the technology for implementing restriction clauses, vault-type applications can be built relatively easily.

Take the design of OP_VAULT as an example:When spending funds in the vault, you need to send a transaction to the chain first. This transaction indicates the intention to spend the vault, the "trigger", and sets the conditions in it:

If everything is normal, then the second transaction is the final withdrawal transaction. After waiting for N blocks, the funds can be further spent anywhere

If it is found that this transaction was stolen (or coerced by a "wrench attack"), it can be immediately sent to another secure address (safer custody for users) before the withdrawal transaction of N blocks is sent

(OP_VAULT process, source: BIP-345)

It should be noted that a vault application can also be built without restrictions. A feasible way is to use the private key to prepare the signature for future spending and then destroy the private key. But there are still many restrictions, for example, it is necessary to ensure that the private key has been destroyed (similar to the trusted setup process in zero-knowledge proof), the amount and handling fee are determined in advance (because of the pre-signature), and thus lack flexibility.

(Comparison of OP_VAULT and pre-signed vault process, source: BIP-345)

More robust and flexible state channels

It can be generally believed that state channels, including lightning networks, have almost the same security as the main chain (under the condition that nodes can observe the latest status and can publish the latest status on the chain normally). However, with the restrictions, some new state channel design ideas can be more robust or flexible on top of the lightning network. Among them, the more well-known ones include Eltoo and Ark.

Eltoo (also known as LN-Symmetry) is a typical example. This technical solution takes the homonym of "L2" and proposes an execution layer for the Lightning Network, allowing any subsequent channel state to replace the previous state without a penalty mechanism, so it can also avoid the need for multiple previous states to be saved by Lightning Network nodes to prevent opponents from doing evil. To achieve the above effect, Eltoo proposed the SIGHASH_NOINPUT signature method, namely APO (BIP-118).

And Ark aims to reduce the difficulty of inbound liquidity and channel management of the Lightning Network. It is a joinpool-style protocol, where multiple users can accept a service provider as a counterparty within a certain period of time to trade virtual UTXO (vUTXO) off-chain, but share a UTXO on the chain to reduce costs. Similar to the vault, Ark can also be implemented on the current Bitcoin network; but after introducing restrictions, Ark can reduce the amount of interaction required based on transaction templates and achieve a more trustless unilateral exit.

Covenants Technical Overview

From the above applications, we can see that the Covenants restriction clause is more like an effect than a certain technology, so there are many technical ways to implement it. If classified, it can include:

Type:General type, special type

Implementation method:Opcode-based, signature-based

Recursion:Recursive, non-recursive

Among them, recursion means: there are some restrictive clauses for implementation, and the output of the next transaction can be restricted by restricting the next output. The added restrictions can go beyond one transaction and achieve a higher transaction depth.

Some mainstream restriction clause designs include:

Design of Covenants restriction clause

From the previous introduction, it can be seen that the current Bitcoin script mainly restricts the conditions for unlocking, and does not restrict how the UTXO can be further spent. To implement the restriction clause, we have to think about it in reverse: Why can't the current Bitcoin script implement the Covenants restriction clause?

The main reason is that the current Bitcoin script cannot read the content of the transaction itself, that is, the "introspection" of the transaction.

If we can implement transaction introspection - check any content of the transaction (including output), then we can implement restrictions.

Therefore, the design idea of ​​restrictions is also mainly centered on how to implement introspection.

Opcode-based vs. signature-based

The simplest and crudest idea is to add one or more opcodes (i.e., one opcode + multiple parameters, or multiple opcodes with different functions) to directly read the content of the transaction. This is the idea based on opcodes.

Another idea is that instead of directly reading and checking the content of the transaction itself in the script, you can use the hash of the transaction content - if the hash has been signed, then as long as you modify the script, such as OP_CHECKSIG, to check the signature, you can indirectly implement transaction introspection and restrictions. This idea is the design method based on signatures. Mainly including APO and OP_CSFS.

APO

SIGHASH_ANYPREVOUT (APO) is a proposed Bitcoin signature method. The simplest way to sign is to commit to both the input and output of a transaction, but Bitcoin has a more flexible way, namely SIGHASH, which selectively commits to the input or output of a transaction.

Currently, SIGHASH and its combination have signature scopes for transaction input and output (Source: "Mastering Bitcoin, 2nd"

As shown in the figure above, in addition to ALL, which is applicable to all data, the NONE signature method is only applicable to all inputs, not outputs; SINGLE is based on this and is only applicable to outputs with the same input sequence number. In addition, SIGHASH can also be combined. After the ANYONECANPAY modifier is superimposed, it is only applicable to one input.

And APO's SIGHASH only signs the output, not the input part. This means that a transaction signed with the APO method can be attached to any UTXO that meets the conditions later.

This flexibility is the theoretical basis for APO to implement restrictive clauses:

One ​​or more transactions can be created in advance

A public key that can only obtain one signature can be constructed through the information of these transactions

In this way, any assets sent to the public key address can only be spent through pre-created transactions

It is worth noting that because this public key has no corresponding private key, it can ensure that these assets can only be spent through pre-created transactions. Then, we can specify the destination of the assets in these pre-created transactions to implement restrictive clauses.

We can further understand this by comparing Ethereum's smart contracts:Through smart contracts, we can also achieve that only through certain conditions can we withdraw money from the contract address, rather than relying on an EOA Signatures can be spent at will. From this point of view, Bitcoin can achieve this effect through the improvement of the signature mechanism.

But the problem in the above process is that there is a circular dependency in the calculation, because the input content needs to be known to pre-sign and create transactions.

APO and SIGHASH_NOINPUT The significance of implementing this signature method is that it can solve this circular dependency problem. When calculating, you only need to know (specify) all the outputs of the transaction.

OP_CTV

OP_CHECKTEMPLATEVERIFY (CTV), also known as BIP-119, adopts the method of improving Opcode. It takes the commitment hash as a parameter and requires that any transaction that executes the opcode contains a set of outputs that match the commitment. Through CTV, Bitcoin users will be allowed to restrict the way they use Bitcoin.

The proposal was originally introduced as OP_CHECKOUTPUTSHASHVERIFY(COSHV), and early on it focused on the ability to create congestion control transactions, so criticism of the proposal also focused on the fact that the scheme was not general enough and was too specific to the congestion control use case.

In the congestion control use case mentioned above, the sender Alice can create 10 outputs and hash these 10 outputs, and use the resulting digest to create a tapleaf script containing COSHV. Alice can also use the public keys of the participants to form a Taproot inner key to allow them to collaborate on spending without revealing the Taproot script path.

Alice then gives each recipient a copy of all 10 outputs so that they can each verify Alice's setup transaction. When they later want to spend this payment, any of them can create a transaction containing the committed output.

Throughout the process, when Alice creates and sends a setup transaction, Alice can send these 10 copies of the output through existing asynchronous communication methods such as email or cloud drives. This means that the recipients do not need to be online or interact with each other.

（Source: https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-transaction-output-commitments）

Similar to APO, addresses can also be constructed based on spending conditions, and "locks" can be made in different ways, including: adding other keys, time locks, and composable logic.

（Source: https://twitter.com/OwenKemeys/status/1741575353716326835）

On this basis, CTV proposed that it is possible to check whether the hashed spending transaction matches the definition, that is, to use the transaction data as the key to open the "lock".

We can extend the example of the 10 recipients above. The recipient can further set its address key to a signed but unbroadcasted tx to send to the next batch of recipient addresses, and so on, forming a tree structure as shown in the figure below. Alice can construct an account balance change involving multiple users using only 1 utxo block space on the chain.

Source: https://twitter.com/OwenKemeys/status/1741575353716326835

What if one of the leaves is a lightning channel, a cold storage, or another payment path? Then this tree will be expanded from a single-dimensional and multi-layered expenditure tree to a multi-dimensional and multi-layered expenditure tree, and the scenarios that can be supported will be richer and more flexible.

Source: https://twitter.com/OwenKemeys/status/1741575353716326835

Since its proposal, CTV has been renamed from COSHV in 2019, assigned BIP-119 in 2020, and the programming language Sapio for creating contracts that support CTV has emerged. In 2022 and 2023, it has received a lot of discussion and updates from the community, as well as debates on its activation plan. It is still one of the soft fork upgrade proposals that the community discusses more.

OP_CAT

OP_CAT As introduced at the beginning, it is also a very popular upgrade proposal. The function implemented is to concatenate two elements in the stack. Although it looks simple, OP_CAT can flexibly implement many functions in the script.

The most direct example is the operation related to the merkle tree. The Merkle tree can be understood as two elements concatenated first and then hashed. Currently, there are hash opcodes such as OP_SHA256 in the Bitcoin script, so if OP_CAT can be used to concatenate two elements, the verification function of the merkle tree can be implemented in the script, which means that it has the ability of light client verification to a certain extent.

Other implementation bases include enhancements to Schnorr signatures: the spending signature condition of the script can be set to the concatenation of the user's public key and public nonce; if the signer wants to sign another transaction to spend the funds elsewhere, he has to use the same nonce, which will lead to the leakage of the private key. That is, the commitment to nonce is achieved through OP_CAT, thereby ensuring the validity of the signed transaction.

Other application scenarios of OP_CAT include: Bistream, tree signatures, quantum-resistant Lamport signatures, vaults, etc.

OP_CAT itself is not a new feature. It existed in the earliest versions of Bitcoin, but it was disabled in 2010 because it could be exploited by attacks. For example, repeated use of OP_DUP and OP_CAT can easily cause the stack of a full node to explode when processing such scripts, refer to this demo.

But if OP_CAT is re-enabled now, won't the stack explosion problem mentioned above occur? Because the current OP_CAT proposal only involves enabling it in tapscript, and tapscript limits each stack element to no more than 520 bytes, it will not cause the previous stack explosion problem. Some developers also think that Nakamoto's direct disabling of OP_CAT may be too harsh. However, due to the flexibility of OP_CAT, there may indeed be some application scenarios that may lead to vulnerabilities that cannot be exhausted at present.

So considering the application scenarios and potential risks, OP_CAT has received a lot of attention recently, and has also had a PR review, making it one of the most popular upgrade proposals.

Conclusion

"Self-discipline brings freedom", as can be seen from the above introduction, restrictive clauses can be directly implemented in Bitcoin scripts to limit the further spending of transactions, thereby realizing transaction rules similar to the effect of smart contracts. Compared to off-chain methods such as BitVM, this programming method can be verified more natively on Bitcoin, and can also improve applications on the main chain (congestion control), off-chain applications (state channels) and other new application directions (staking penalties, etc.).

If the implementation technology of the restriction clause can be combined with some underlying upgrades, it will further release the potential of programmability. For example, the proposal of 64-bit operators in the recent review can be further combined with the proposed OP_TLUV or other restriction clauses, and can be programmed based on the number of satoshis output by the transaction.

However, restriction clauses may also lead to some unplanned abuse or vulnerabilities, so the community is also cautious about this. In addition, the upgrade of restriction clauses also requires the soft fork upgrade of consensus rules. In view of the situation during the taproot upgrade, the upgrade related to restriction clauses may also take some time to complete.