Исследовательский отчет HashKey Capital: Ковенанты, программируемость биткоина

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 Bitcoins smart contracts or programmability.

If you notice the word restrictions and do a little search, youll find that this is another big rabbit hole. Developers have been discussing for years that in addition to OP_CAT, there are OP_CTV, APO, OP_VAULT, and other techniques for implementing restriction clauses.

So, what exactly are Bitcoins restrictions? Why have they attracted so much attention and discussion from developers for years? What kind of programmability can Bitcoin achieve? What are the design principles behind it? This article attempts to give an overview and discussion.

What is a restriction clause?

Covenants, translated into Chinese as restrictive clauses and sometimes translated as contracts, 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 and entering a matching script when spending. However, as long as the user can unlock it, he can spend the UTXO anywhere he wants.

The restrictive terms are to make more restrictions based on how to unlock this restriction, such as limiting the spending after UTXO, that is, to achieve an effect similar to earnest funds for special purposes; or other input conditions sent in a transaction.

More precisely, current Bitcoin scripts also have certain restrictions, such as opcode-based time locks, which implement time limits before transactions are spent by introspecting the nLock or nSequence fields of transactions, but they are basically limited to time limits.

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

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

Application Scenario

Ensuring Staking Penalties

One of the most intuitive examples of restrictive clauses is Babylon鈥檚 slash transactions in the Bitcoin staking process.

Babylons 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 a user has double-signed or other malicious behavior 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 anywhere else at will and can only be burned. This ensures that malicious users cannot use their known signatures to transfer the assets back to themselves in advance to escape punishment.

If this function is implemented after restrictive terms such as OP_CTV are implemented, opcodes such as OP_CTV can be added to the bad ending branch of the staking script to implement the restrictions.

Before OP_CTV was enabled, Babylon needed to use a workaround method, with users and the committee jointly implementing it, to simulate the effect of enforcing the restrictive clauses.

Congestion Control

Generally speaking, congestion means that when the transaction fee rate on the Bitcoin network is very high, there are a lot of transactions waiting to be packaged in the transaction pool, so if users want to confirm transactions quickly, they need to increase the transaction fee.

If a user has to send multiple transactions to multiple recipients, he or she will have to increase the handling fee and bear relatively high costs, which will also further increase the handling fee rate of the entire network.

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

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

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

This scenario is a typical application case proposed by the OP_CTV restriction clause. More application cases 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 are a widely discussed application scenario in Bitcoin applications, especially in the field of restrictions. Because daily operations inevitably have to balance the need to keep funds and use funds, people hope to have a type of vault application that can ensure the safety of funds and even restrict the use of funds even if the account is hacked (private key leaked).

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

Take the design of OP_VAULT as an example: when spending funds in the vault, a transaction needs to be sent to 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, 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 this transaction was stolen (or coerced during a wrench attack), it can be immediately sent to another secure address (for safer custody by the user) before the withdrawal transaction of N blocks is sent.

OP_VAULT process, source: BIP-345

It should be noted that a vault application can be built without restrictions. One feasible way is to use the private key to prepare the signature for future spending and then destroy the private key. However, 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-signature), and thus lack flexibility.

Comparison of OP_VAULT and pre-signed vault processes, source: BIP-345

More robust and flexible state channels

It can be generally believed that state channels, including the Lightning Network, have almost the same security as the main chain (provided that nodes can observe the latest status and can publish the latest status to 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, Ark, etc.

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 the need for a penalty mechanism. Therefore, it can also avoid the need for Lightning Network nodes to save multiple previous states 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 one UTXO on-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 the transaction template and achieve a more trustless unilateral exit.

Technical Overview of Restrictions

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

• Type: general purpose, special purpose

• Implementation method: Opcode-based, signature-based

• Recursion: recursive, non-recursive

Recursion means that if there are some restrictive clauses implemented, 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 popular restriction clause designs include:

* Recursion: If combined with OP_CAT

Design of restriction clauses

From the previous introduction, we can see that the current Bitcoin script mainly restricts the conditions for unlocking, but does not restrict how the UTXO can be further spent. To implement the restriction clause, we have to think about it in reverse: Why cant the current Bitcoin script implement the 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 introspection of transactions – inspecting any content of a transaction (including outputs), then we can implement restrictions.

Therefore, the design ideas of restrictive clauses also mainly revolve around how to achieve 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 transaction content. This is also based on the idea of opcodes.

Another idea is to use the hash of the transaction content instead of directly reading and checking the transaction content in the script. If the hash has been signed, then as long as the script is modified to check the signature, such as OP_CHECKSIG, the transaction introspection and restriction clauses can be indirectly implemented. This idea is based on the design method of signatures. It mainly includes 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 method, SIGHASH, which selectively commits to the input or output of a transaction.

The current signature range of SIGHASH and its combination 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.

However, APOs SIGHASH 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 the APO implementation restriction clause:

• One or more transactions can be pre-created

• A public key that can only generate one signature is 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 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, thereby implementing restriction clauses.

We can further understand this by comparing it to Ethereum鈥檚 smart contracts: through smart contracts, we can only withdraw money from the contract address if certain conditions are met, rather than spending it arbitrarily with an EOA signature. From this point of view, Bitcoin can achieve this effect by improving the signature mechanism.

The problem with 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 the transaction.

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

OP_CTV

OP_CHECKTEMPLATEVERIFY (CTV), or BIP-119, takes an improved approach to 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 focused on the ability to create congestion-controlled transactions, so criticism of the proposal also focused on the fact that the solution 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 they can each verify Alices setup transaction. When they later want to spend this payment, any of them can create a transaction that includes the committed output.

Throughout the process, when Alice creates and sends the 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 combinable logic.

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

Based on this, 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 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, 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 it can support 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 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 in the community, as well as debates on its activation plan. It is still one of the soft fork upgrade proposals that is discussed more in the community.

OP_CAT

As mentioned in the beginning, OP_CAT is also a very popular upgrade proposal. It implements the function of concatenating 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 being concatenated first and then hashed. Currently, there are hash opcodes such as OP_SHA 256 in the Bitcoin script, so if OP_CAT can be used to concatenate two elements, the merkle tree verification function can be implemented in the script, which means that it has the ability of light client verification to a certain extent.

The other implementation basis also includes the enhancement of Schnorr signature: the spending signature condition of the script can be set as the concatenation of the users 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 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, as shown in this demo.

But wont the stack explosion problem mentioned above happen if OP_CAT is re-enabled now? 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 Nakamotos 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.

Therefore, considering the application scenarios and potential risks, OP_CAT has received a lot of attention recently and has also undergone PR review. It is one of the most popular upgrade proposals at present.

Заключение

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

If the restriction implementation technology can be combined with some underlying upgrades, it will further unleash the potential of programmability. For example, the proposal for 64-bit operators in review recently can be further combined with the proposed OP_TLUV or other restriction clauses to program based on the number of satoshis in the transaction output.

However, restrictions may also lead to some unplanned abuse or loopholes, so the community is cautious about this. In addition, the upgrade of restrictions also requires a soft fork upgrade of consensus rules. Given the situation during the taproot upgrade, the upgrade of restrictions may also take some time to complete.

Thanks to Ajian, Fisher, and Ben for reviewing and providing suggestions on this article!

Рекомендации
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 Proposal: 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

This article is sourced from the internet: HashKey Capital Research Report: Covenants, the Programmability of Bitcoin

Related: Meme Coin BONK Susceptible to 50% Decline Amid Bearish Cues

In Brief Bonk price is in a descending wedge, and the lower trend line will likely be tested again. This would result in a potential 50% drawdown, which broader market cues support. BONK holders are also betting on a price drop since Funding rates are highly negative. Bonk failed to breach a key resistance trend line, which would have resulted in the meme coin escaping further decline. However, looking at the descending wedge BONK is stuck in, it warrants another drawdown. This sentiment is also shared by investors who place short bets on the meme coin. Bonk Funding Rate Dips Again At the time of writing, Bonk’s price is above an important support line of $0.00002153. This level has been tested multiple times in the past, but this time around, the…