jakiro
Author: Jeffrey HU & Harper LI, HashKey Capital
Recently, a wave of discussions have started in the Bitcoin community about re-enablement of opcodes such as OP_CAT.Taproot Wizard has also attracted a lot of attention by launching Quantum Cats’ NFT, claiming to have obtained the BIP-420 number, etc.Supporters claim that enabling OP_CAT can implement “covenants”, implement smart contracts for Bitcoin, or programmability.
If you notice the term “restriction clause” and search for it,You will find that this is another big rabbit hole.The developers have been discussing it for years,In addition to OP_CAT, there are also technologies that implement restrictions such as OP_CTV, APO, OP_VAULT.
So, what exactly are Bitcoin’s “restricted terms”?Why can it attract so many developers to continue their attention and discussion for years?What programmability can be achieved in Bitcoin?What is the design principle behind it?This article will give an overview introduction and discussion.
What are “restricted terms”
Covenants, translated as “restricted clauses” in Chinese, sometimes translated as “contracts”, is a mechanism that can set conditions for future Bitcoin transactions.
Current Bitcoin scripts also contain restrictions, such as entering a legal signature when spending, sending a compliant script, etc.But as long as the user can unlock it, he can spend the UTXO anywhere he wants.
The restriction clause is to make more restrictions on how to unlock this restriction.For example, limiting the cost after UTXO is to achieve an effect similar to “special funds and special purposes”; or other input conditions sent in a transaction, etc.In the final analysis,The restriction clause can directly limit the transaction costs in the Bitcoin script, thereby achieving transaction rules similar to the effect of smart contracts.
More rigorously, current Bitcoin scripts also have certain restrictions. For example, time locks based on opcodes are used to implement the time limit before transaction spending by introspecting the nLock or nSequence fields of transactions, but they are basically limited toTime limitations.
So why do developers and researchers design these limit checks?Because the restriction clause is not only restricted for the sake of limitation, but also sets rules for transaction execution.In this way, the user can only execute transactions according to preset rules to complete the predetermined business process.
So it is more counterintuitive that this can unlock more application scenarios.
Covenants application scenarios
Ensure staking punishment
One of the most intuitive examples of restrictions is Babylon’s slash transaction in the Bitcoin staking process.
Babylon’s Bitcoin staking process is that users send their BTC assets on the main chain to a special script, with two expense conditions:
·Happy ending:After a certain period of time, the user can unlock it with his own signature, that is, the unstake process is completed.
·Bad ending: If a user commits evil behavior such as double signing on a PoS chain that is rented by Babylon, then through EOTS (extractable one-time signatures, you can extract signatures at one time), you can unlock this part of the assets and get them from the networkThe execution role forces a part of the assets to the burning address (slash)
(Source: Bitcoin Staking: Unlocking 21M Bitcoins to Secure the Proof-of-Stake Economic)
Pay attention to the “forced send” here, which means that even if the UTXO can be unlocked, the asset cannot be sent arbitrarily to anywhere else and can only be burned.This will ensure that the evil user cannot transfer the assets back to him first with his known signature to escape punishment.
If this function is implemented in the restrictions such as OP_CTV, you can add opcodes such as OP_CTV to the “bad ending” branch of the staking script to implement the restrictions.
Before OP_CTV is enabled, Babylon needs to simulate the implementation of the enforcement of restricted clauses through a workaround, which is jointly implemented by the user + committee.
Congestion control
Generally speaking,Congestion refers to when the handling fee rate on the Bitcoin network is very high, and there are more transactions accumulated in the transaction pool waiting to be packaged.Therefore, if the user wants to quickly confirm the transaction, he needs to increase the handling fee.
At this time, if a user has to send multiple transactions to multiple payees, he has to increase the handling fee and bear relatively high costs.At the same time, it will further increase the handling fee rate of the entire network.
If there are restrictions, one solution is to send the sender.You can first commit to a batch-sent transaction.This promise can make all recipients believe that the final transaction will be carried out, and you can wait until the handling fee is low before sending the specific transaction.
As shown in the figure below, when the demand for block space is high, transactions become very expensive.By using OP_CHECKTEMPLATEVERIFY, a mass payment processor can aggregate all of its payments into a single transaction of complexity O(1) for confirmation.Then, after a while, when people’s 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 restriction clause of OP_CTV.There are more application cases available at https://utxos.org/uses/. In addition to the above congestion control, the page lists Soft Fork Bets, Decentralized options, Drivechains, Batch Channels, Non Interactive Channels, Trustless Coordination-FreeMining 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 restricted clauses.Because daily operations inevitably need to balance the needs of funds storage and fund use,People hope that there will be a type of application for custody of vaults: it can ensure the security of funds, and even if the account is hacked (the private key is leaked), it can limit the use of funds.
Based on the technology to implement restrictions, vault applications can be built relatively easily.
Take the design plan of OP_VAULT as an example:When spending funds in the vault, you need to send a transaction to the link first.This transaction demonstrates the intention to spend the vault, i.e. “trigger”, and sets the conditions there:
If everything is OK, then the second transaction is the final withdrawal.After waiting for N blocks, you can further spend the funds anywhere.
If you find that the transaction was stolen (or was coerced when attacked by a “wrench”), you can immediately send it to another secure address before the withdrawal transaction in N blocks (the user can keep it safer)
(OP_VAULT process, source: BIP-345)
It should be noted thatWithout restrictions, a vault application can also be built, A feasible way is to use the private key to prepare the signature you spend in the future, and then destroy the private key.But there are still many restrictions.For example, it is necessary to ensure that this 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 pre-signed), and therefore lack flexibility.
(Comparison of OP_VAULT and pre-signed vault processes, source: BIP-345)
More robust and flexible state channels
It can generally be considered that state channels including Lightning Network have almost the same security as the main chain (when ensuring that nodes can observe the latest state and can publish the latest state to the link normally).However, with restrictions in place, 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 one of the most typical examples.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 punishment mechanism. Therefore, it can also avoid the need for saving like the Lightning Network nodes.Multiple previous states to prevent opponents from committing evil.In order to achieve the above effect, Eltoo proposed the signature method of SIGHASH_NOINPUT, namely APO (BIP-118).
Ark aims to reduce the difficulty of inbound liquidity and channel management of Lightning Network.It is a form of joinpool protocol. Multiple users can accept a service provider as a counterparty within a certain period of time to conduct virtual UTXO (vUTXO) transactions off-chain, but share a UTXO on the chain to reduce costs.Similar to vaults, 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 to achieve a more detrustworthy unilateral exit.
Covenants Technology Overview
From the above application, 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:Based on Opcode, signature-based
recursion:Recursive, non-recursive
Among them, recursion refers to: there are some implementations of restrictions, and the output of the next transaction can be limited by limiting the next transaction. The added restrictions can be achieved that exceed one transaction and achieve a higher transaction depth.
Some mainstream restrictions designs include:
Design of Covenants restricted terms
As can be seen from the previous introduction, the current Bitcoin scripts mainly limit the conditions for unlocking, and do not limit how the UTXO will be spent further.To implement the restriction clause, we must think 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 introspection of the transaction – checking anything about the transaction (including output), then we can implement the restriction clause.
Therefore, the design idea of restricted clauses is mainly focused on how to achieve introspection.
Based on opcode vs based on signature
The simplest and crude 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 the operation code.
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 this hash has been signed, then just modify, for example, OP_CHECKSIG in the scriptBy implementing the inspection of this signature, you can indirectly realize transaction introspection and restriction clauses.This idea is based on signature design.It mainly includes APO and OP_CSFS, etc.
APO
SIGHASH_ANYPREVOUT (APO) is a proposed Bitcoin signature method.The easiest way to sign is to commit to both the input and output of the transaction, but Bitcoin also has a more flexible way, namely SIGHASH, which selectively commits to the input or output of a transaction.
Currently, SIGHASH and its combinations sign the transaction input and output range (Source “Mastering Bitcoin, 2nd”
As shown in the figure above, except for ALL that applies to all data, NONE’s signature method is to only apply to all inputs, not for outputs; SINGLE is based on this, only outputs that apply to the same input serial number.In addition, SIGHASH can also be combined, and only applies to one input after the ANYONECANPAY modifier is superimposed.
APO’s SIGHASH only signs the output, not the input part.This means that transactions signed by APO can be attached to any UTXO that meets the conditions later.
This flexibility is the theoretical basis for APO to implement restrictions:
One or more transactions can be created in advance
Through these transaction information, a public key that can only obtain one signature can be built.
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 is ensured that these assets can only be spent through pre-created transactions.Then, we can specify where the assets go in these pre-created transactions, thereby implementing the restriction clause.
We can further understand by comparing Ethereum’s smart contracts:What we can achieve through smart contracts is that we can withdraw money from the contract address only through certain conditions, rather than spending it at will with an EOA signature.From this point of view, Bitcoin can achieve this effect through improvements in the signature mechanism.
But the problem in the above process is that there is a circular dependency during calculation, because you need to know the input content to pre-sign and create a transaction.
The significance of APO and SIGHASH_NOINPUT to implement this signature method is that it can solve this circular dependency problem. When calculating, you only need to know all the output of (specified) transactions.
OP_CTV
OP_CHECKTEMPLATEVERIFY (CTV), or BIP-119, adopts the method of improving Opcode.It takes the commit hash as a parameter and requires that any transaction that executes the opcode contains a set of outputs that match that commitment.Through CTV, Bitcoin users will be allowed to limit the way they use Bitcoin.
The proposal was originally launched under the name of OP_CHECKOUTPUTSHASHVERIFY(COSHV), and early on focusing on the ability to create congestion control transactions, criticism of the proposal also focused on the inconsistency control use cases that were not universal enough and were too specific.
In the congestion control use case mentioned above, the sender Alice can create 10 outputs and hash the 10 outputs and use the generated summary to create a tapeleaf script containing COSHV.Alice can also use participants’ public keys to form Taproot internal keys to allow them to spend together without leaking 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 want to spend this payment later, either of them can create a transaction containing the promised output.
Throughout the process, when Alice creates and sends set transactions, 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 according to expenditure conditions, and “locks” can be created 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 can check whether the spending transaction after hash matches the definition, that is, use the transaction data as the key to open the “lock”.
We can continue to extend the above 10 recipient examples, and the receiver can further set its address key to a signed but not broadcast tx to send it to the next batch of recipient addresses, and so on, forming a shown in the figure belowtree-like structure.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
And what if one of the leaves is a lightning channel, a cold storage, or other payment paths?Then this tree will expand from a single-dimensional and multi-layer expenditure tree to a multi-dimensional and multi-layer expenditure tree, and the scenarios it can support will be richer and more flexible.
Source: https://twitter.com/OwenKemeys/status/1741575353716326835
Since its introduction, CTV has undergone a rename change from COSHV in 2019, assigned BIP-119 in 2020, and the emergence of Sapio, a programming language used to create a CTV contract, has received a lot of discussion and updates in the community in 22 and 23 years, as well asThe debate over its activation plan is still one of the soft fork upgrade proposals that the community has discussed a lot.
OP_CAT
OP_CAT As introduced at the beginning, it is also an upgrade proposal that is currently very concerned. The implemented functions concatenate two elements in the stack.Although it looks simple, OP_CAT can implement many functions in scripts with flexibility.
The most direct example is the operation related to the merkle tree.The Merkle tree can be understood as two elements are spliced first and then hashed.Currently, there are hash operation codes such as OP_SHA256 in the Bitcoin script, so if you can use OP_CAT to splice two elements, you can implement the verification function of the merkle tree in the script, which will have light client verification to a certain extentability.
Another implementation basis also includes enhancements for Schnorr signatures: the script’s spending signature condition can be set to the user’s public key and public nonce splicing; then if the signer wants to sign another transaction, spend the funds elsewhere if the signer wants to sign another transaction., you have to use the same nonce, resulting in the private key leakage.That is, the commitment to nonce is achieved through OP_CAT, thereby ensuring the validity of signed transactions.
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 has existed in the earliest versions of Bitcoin, but it has been disabled in 2010 due to the potential to be exploited by attacks.For example, reusing OP_DUP and OP_CAT can easily make the whole node stack explode when processing such scripts, refer to this demo.
But will the aforementioned stack explosion problem be encountered if OP_CAT is re-enabled now?Because the current OP_CAT proposal only involves enabling in tapscript, which qualifies that each stack element does not exceed 520 bytes, there will be no previous stack explosion problem.Some developers also believe that Satoshi Nakamoto’s direct disabling OP_CAT may be too strict.However, due to the flexibility of OP_CAT, some application scenarios that may cause vulnerabilities cannot be exhausted at present.
Therefore, combining application scenarios and potential risks, OP_CAT has received a lot of attention recently and has also had PR review, which is one of the most popular upgrade proposals at present.
Conclusion
“Self-discipline brings freedom”, as shown in the above introduction,The restriction clause can directly limit the transaction costs in the Bitcoin script, thereby achieving 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 applications on the main chain (congestion control), off-chain applications (state channels) and other new ones.Application direction (staking punishment, etc.).
If the implementation technology of restricted clauses can be combined with some underlying upgrades, it will further unleash the potential of programmability.For example, the recent proposal for the 64-bit operator in the review can be further combined with the proposed OP_TLUV or other restrictions, and can be programmed based on the number of transaction outputs.
But restrictions may also lead to some unplanned abuse or loopholes, so the community is more cautious about this.In addition, the upgrade of the restriction clause also requires soft fork upgrades involving consensus rules.Given the situation when taproot is upgraded, the upgrades related to the restriction clauses may also take time to complete.
