HashKey Capital: “Covenants” Bitcoin’s Programmability

Original author: HashKey Capital Head of Investment Research Jeffrey HU, HashKey Capital Investment Manager Harper LI

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 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 clause"? 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". They are 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, entering a matching script, etc. However, as long as the user can unlock it, he can spend the UTXO wherever he wants.

The restrictive 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 "special funds for special purposes"; or other input conditions sent in a transaction, etc.

More rigorously speaking, current Bitcoin scripts also have certain restrictions, such as time locks based on opcodes, which is to achieve the time limit before the transaction is spent by introspecting the nLock or nSequence fields of the transaction, but it is basically limited to time restrictions.

So why do developers and researchers design these restriction checks? Because the restrictions are not just for the sake of restrictions, but also set the 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.

Application scenarios

Ensure the punishment of staking

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, then through EOTS (extractable one-time signatures), this part of the assets can be unlocked, and the executive role in the network will force a part of the assets to be sent to the burning address (slash)

Source: Bitcoin Staking: Unlocking 21 M 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 OP_CTV and other restrictive terms, you can add OP_CTV and other opcodes in the "bad ending" branch of the staking script to implement restrictions.

Before OP_CTV is enabled, Babylon needs to use a workaround method, which is jointly executed by users + committees to simulate the effect of enforcing restrictive terms.

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, after a period of time, when the 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.

Vault

Vault is 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 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 on the chain first. This transaction indicates the intention to spend the vault, that is, the "trigger", and sets the conditions in it:

• If everything goes well, 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 the transaction was stolen (or coerced by a "wrench attack"), it can be immediately sent to another secure address (safer 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 restrictive terms. A feasible approach is to use a private key to prepare the signature for future spending and then destroy the private key. But there are still many restrictions, such as the need 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 pre-signing), and thus lack flexibility.

OP_VAULT and pre-signed vault process comparison, 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 later channel state to replace the previous state without the need for a penalty mechanism, so it can also avoid the need to save multiple previous states like the Lightning Network nodes to prevent opponents from doing evil. In order to achieve the above effect, Eltoo proposed the SIGHASH_NOINPUT signature method, namely APO (BIP-118). 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 the introduction of restrictions, Ark can reduce the amount of interaction required based on the transaction template and achieve a more trustless unilateral exit.

Technical Overview of Restrictions

From the above applications, we can see that restrictions are more like an effect than a certain technology, so there are many technical ways to implement them. 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 implemented, 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:

* Recursion: If combined with OP_CAT 

Restriction clause design

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 restriction clauses, we have to think about it in reverse: Why can't the current Bitcoin script implement restriction clauses?

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.

Based on opcodes vs. based on signatures

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 implement the check of the signature, you can indirectly implement transaction introspection and restrictions. This idea is based on the design method of 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, to selectively commit to the input or output of a transaction.

Currently, SIGHASH and its combination have signature ranges 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, and after the ANYONECANPAY modifier is superimposed, it is only applicable to one input.

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

This flexibility is the theoretical basis for APO to implement restriction 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

• It is worth noting that because this public key does not have a 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 the restriction clause.

  We can further understand by comparing Ethereum's smart contracts: through smart contracts, we can also withdraw money from the contract address only through certain conditions, rather than spending it arbitrarily with an EOA signature. From this point of view, Bitcoin can achieve this effect through the improvement of the signature mechanism.

  However, 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 a transaction.

  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_CHECKTEMPLATEVERIFY (CTV), or BIP-119, takes the approach of improving Opcode. It takes a commitment hash as a parameter and requires that any transaction that executes the opcode contain a set of outputs that match that commitment. With CTV, Bitcoin users will be allowed to restrict how they use Bitcoin. The proposal was originally introduced under the name 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 proposal 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 internal 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 each of them can verify Alice's setup transaction. When they later want to spend this payment, any of them can create a transaction containing the committed outputs.

  Throughout the process, while Alice creates and sends the setup transaction, Alice can send copies of the 10 outputs via 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

  CTV proposed on this basis 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 the 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, cold storage, or other payment path? Then the tree will expand 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/1744181234417140076

  Since its proposal, CTV has been renamed from COSHV in 2019, assigned BIP-119 in 2020, and a programming language Sapio for creating contracts that support CTV has emerged. In 22 and 23, the community has discussed and updated a lot, as well as debated about its activation plan. It is still one of the soft fork upgrade proposals that is discussed more in the community.

  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 signature, quantum-resistant Lamport signature, vault, etc.

  OP_CAT itself is not a new feature. It existed in the earliest version 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 at present.

  Conclusion

  "Self-discipline brings freedom", as can be seen from the above introduction, the restriction clause can directly implement the limitation of further transaction spending in the Bitcoin script, thereby realizing transaction rules similar to the effect of smart contracts. Compared with 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.

  Thanks to Ajian, Fisher, and Ben for reviewing and suggesting this article!

  References
  https://utxos.org/

  https://bitcoincovenants.com/

  A collection of resources related to covenants:

  https://gist.github.com/RobinLinus/c96fb7c81430ec6dc92f048687bd3068

  https://anyprevout.xyz/

  BIP 345: OP_VAULT Proposals: https://www.btcstudy.org/2023/04/13/bitcoin-improvement-proposals-345-op-vault-commit-0b0674c546/ https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final2 8.pdf https://maltemoeser.de/paper/covenants.pdf https://bitcoinops.org/en/topics/op_cat/ OP_CAT: https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0001.md CAT and Schnorr Tricks: https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298