Covenants, OP_CAT, and OP_CTV: Everything You Need to Know About Bitcoin's Upcoming Update

In the cryptocurrency community, the Bitcoin blockchain is known for being a slow and expensive network to use, with limited computing capacity, making the creation of smart contracts more complex compared to other blockchains.

However, its slowness, small block size, and limited computing capacity are features that allow Bitcoin to be the most secure, decentralized, and censorship-resistant network in existence. For instance, increasing the block size would cause the blockchain to grow too quickly, leading to a rapid rise in the cost of maintaining a node.

The decentralization of a blockchain primarily depends on the number of nodes sharing the transaction history. If this history grows faster than the capacity of computer hardware, the network risks gradually becoming centralized, as access to validation will become more expensive and less accessible.

This principle is based on Moore’s Law, which also explains the blockchain trilemma: a blockchain that seeks to be scalable must compromise on security and decentralization.

In comparison, Ethereum is more scalable than Bitcoin, but its blockchain size is increasing very quickly, leading to centralization over time. Similarly, the Kaspa network is more scalable than Bitcoin and has the potential to become more decentralized, but it compromises security by using "pruned" nodes.

To make Bitcoin faster, several types of infrastructures have been proposed:
‍
- Sidechains, alternative chains that work closely with Bitcoin without fully relying on it or benefiting from its security, such as the Liquid (L-BTC) or Stacks (STX) blockchains;
‍
- Layer 2 solutions, infrastructures that perform computations off the main network and ultimately record only a footprint on it, such as BitVM and RGB, which are still under development;

- The Lightning Network, a network of liquidity channels allowing nearly instant and low-cost BTC transfers.

Among the proposed solutions, there are also modifications to the Bitcoin blockchain itself, such as the SegWit update in 2017 and Taproot, implemented since 2021.

More recently, the topic of covenants has gained visibility, sparking numerous debates about a potential Bitcoin update and a new soft fork.

Before diving into the subject, it is important to understand how the Script language works to grasp the implications of covenants and opcodes.

The mechanism for transferring BTC on Bitcoin is quite different from that used by blockchains utilizing the Ethereum Virtual Machine (EVM).

While these blockchains merge the same tokens received by an address, Bitcoin records each incoming BTC to an address as a distinct transaction output (output) and each outgoing transfer to an external address as a separate transaction input (input), rather than combining the total balance held by the wallet.

Thus, the BTC units we hold in our Bitcoin wallet are actually stored as unspent transaction outputs, referred to as "Unspent Transaction Outputs" or "UTXOs."

These UTXOs function somewhat like a digital version of cash or coins. For instance, if you receive 1 Bitcoin, you will have 1 UTXO worth 1 BTC. Once spent, your 1 BTC UTXO is consumed as an input in the transaction, which in turn creates a new 1 BTC UTXO in the recipient's wallet.

‍Before going further, it is essential to understand that for UTXOs to be spent, they must be unlocked and then locked by a language unique to Bitcoin, called "Script."

The Script programming language is essentially a script that specifies the spending conditions of a UTXO. These scripts are executed when the network nodes verify the validity of a transaction.

The primary reason why it is impossible to create applications on Bitcoin as complex as those on Ethereum is due to the fact that the Script language is not Turing-complete, much like Solidity.

While Solidity is often described as Turing-complete, in reality, it is not. The execution of a smart contract on Ethereum is primarily dependent on the availability of gas fees to pay for the transactions. Without funds to cover these fees, neither Ethereum nor Solidity can be considered truly Turing-complete.

To be more precise, Bitcoin's Script language is structured as a stack. Data is placed onto the stack, and operational codes, also known as "opcodes," act on this data. These opcodes can perform functions such as addition, subtraction, duplication, or swapping of the data in the stack.

Although it is often perceived as limited compared to other programming languages, Script is actually quite powerful, with over a hundred opcodes, such as OP_RETURN, OP_2DUP, OP_SWAP, OP_ADD, and more.

Additionally, the opcodes in Script already enable a wide range of functionalities for Bitcoin. For example, OP_CHECKMULTISIG allows for addresses managed by multiple private keys, and OP_CHECKSEQUENCEVERIFY enforces relative time constraints, like timelocks, which have facilitated the creation of the Lightning Network and escrow deposits.

As you can see, Script isn't particularly flexible, mainly because of its limited set of opcodes. However, many proposals to expand Script with new opcodes have been discussed over the years.

The addition of new opcodes could bring Bitcoin's Script language closer to the Turing-completeness of Ethereum, opening the door to more complex use cases.

Some opcodes could even enable the creation of "covenants," mechanisms that enforce more specific conditions on how UTXOs can be spent.

The English word "covenant" refers to a formal agreement or legal commitment between two or more parties. In finance, it can refer to conditions that borrowers must meet in a loan agreement. In a religious or historical context, it may refer to a sacred alliance or pact. It can be translated into French as "convention" or "alliance."

In the context of Bitcoin, a covenant is a mechanism that imposes specific conditions on the scriptPubKey used to lock a UTXO in the next transaction, with these conditions being explicitly defined in the scriptPubKey of the initial transaction.

In other words, a covenant defines the rules that the BTC locking script must follow, dictating how, when, and where those BTC can be spent.

There are different types of covenants:

- Transaction Hash Covenants: This type of covenant conditions the unlocking of UTXOs based on the validity of a specific hash present in the initial transaction. This means that BTC can only be spent if the spending transaction's hash matches the hash defined in the initial transaction. Transaction hash covenants ensure that a particular transaction has been created or signed in a specific way before allowing the BTC to be unlocked.

- Transaction Introspection Covenants: This type of covenant allows verification of certain internal properties of the transaction, such as its inputs, outputs, or even the transferred amounts, before allowing the UTXOs to be spent. Unlike transaction hash covenants, they provide control over the components of the transaction itself. Transaction introspection covenants could enforce more complex spending conditions, such as on transaction fees or outputs.

- Script Transformation Covenants: This type of covenant modifies or imposes conditions on the unlocking script of the following UTXOs. It allows the script to be transformed in a subsequent transaction, thus conditioning not only who can spend the BTC, but also how they can be spent in the future. Script transformation covenants could create chains of conditions over multiple transactions, where each transaction might change the rules for the next.

- Deferred Covenants: This type of covenant imposes a restriction that is not immediately applied but will be in a future transaction. It allows the validator to examine the entire script rather than step-by-step from the top of the stack. Deferred covenants delay the application of a condition until a specific moment, likely for privacy or complexity reasons. Deferred covenants could condition access to BTC based on future events or criteria, keeping the conditions hidden or pending until needed.

The various opcodes and covenants under consideration could make Bitcoin more scalable, not only in terms of transaction confirmation speed but also in terms of computational capacity and flexibility.

Covenants could introduce numerous improvements to Bitcoin and pave the way for the development of new applications, such as:

- The creation of advanced mechanisms to secure BTC;Improved performance of the Lightning Network through the implementation of Eltoo;

- The development of new layer 2 infrastructures like Ark or rollups;The establishment of Payment Pools, structures similar to mixers, to enhance privacy;

- The direct integration of protocols on the main chain, enabling applications similar to those of Ethereum on Bitcoin;

-The improvement of Discreet Log Contracts (DLC), particularly facilitating the creation of derivative markets on Bitcoin;

- The creation of more decentralized mining pools.

However, covenants are not a flawless solution. The implementation of new opcodes could not only increase attack surfaces and the potential for bugs due to the complexity of scripts, but also enable the creation of covenants that limit users' freedom in spending their BTC.

This is primarily due to the recursive nature of certain covenants.

A recursive covenant is a type of smart contract that imposes rules not only on the initial scriptPubKey but also on all subsequent ones. If a covenant applies only to the initial scriptPubKey or some but not all subsequent ones, it is not considered recursive.

In other words, a recursive covenant is a smart contract that imposes spending conditions on a UTXO and all following transactions, creating a chain where each transaction is bound by the rules established in the initial transaction.

An overly restrictive recursive covenant could result in losses for the BTC owner, harm the entire network by creating different versions of BTC that cannot be spent in the same way, thereby affecting the fungibility of BTC and reducing the total available supply.

Such restrictions could be introduced in various ways: through errors in the creation of a smart contract, by constraint if strict regulations prevent spending BTC from regulated companies to blacklisted addresses, or even by deliberate user choice.

For instance, preventing the spending of Bitcoins to blacklisted addresses, such as immediately after they exit exchange platforms, is already enforceable through strict regulation. This could involve the use of multisig wallets, where a regulated platform holds at least one key, for example in a 2/2 multisig wallet, and is prohibited from confirming transactions that transfer BTC to addresses not compliant with regulations.

Like those who adopted the hierarchy of satoshis from the Ordinals theory (which doesn’t actually exist on the Bitcoin network itself), these users could create an "Ordinals" covenant, making it impossible to mix rare satoshis with others.

However, it’s important to note that, in most cases, the ordinary user retains control over their BTC, and only the owner can decide to use a recursive covenant, thereby potentially compromising the fungibility of their BTC.

Several Bitcoin developers emphasize that censorship, such as that imposed by governments, is already possible, and covenants would not necessarily make it easier to implement.

Developer Andrew Poelstra, during an interview with Nik Bhatia for The Bitcoin Layer, highlighted that such projects would face strong social opposition, as users would need to update their wallets to recognize these restricted BTC.

He also mentioned economic obstacles, as adding opcodes to create these covenants would make BTC transactions larger and, therefore, more expensive in terms of transaction fees, along with technical challenges related to the complexity of creating such covenants.

Among the many opcodes being considered, two stand out for their simplicity and technical capabilities: OP_CAT and OP_CHECKTEMPLATEVERIFY.

OP_CAT is an opcode that could make Bitcoin's programming language, Script, much more flexible and pave the way for numerous new use cases.

Technically, OP_CAT is designed to concatenate two elements at the top of the script stack. Concatenation involves joining two pieces of data end to end, forming a single data sequence instead of two distinct ones, thereby reducing the script's complexity.

While this operation may seem simple, it significantly increases the expressiveness of the Script language, allowing for more complex data structures to be created directly within Bitcoin transactions.

For example, it would enable operations such as multiplication (3 x 4), which would otherwise require a series of successive additions (3 + 3 + 3 + 3) without OP_CAT.

Thus, OP_CAT makes it possible to implement more sophisticated scripts, including transaction hash and transaction introspection covenants. For instance, it could enable:

- The creation of Vaults, systems that enhance BTC security;
- The development of smart contracts as Turing-complete as those on Ethereum;
- The implementation of Eltoo to improve the Lightning Network;
- The creation of Ark, a Bitcoin layer 2 dedicated to BTC transfers;
- The optimization of BitVM, a computing paradigm enabling rollups;
- And the development of numerous layer 2 solutions that would truly benefit from Bitcoin’s security.

OP_CAT was originally part of Bitcoin's script when it was created, but it was quickly disabled in 2010 by Satoshi Nakamoto himself. The main reason for its removal was the risk of spam on the network, which could have compromised its security.

Indeed, OP_CAT had no size limit, which could potentially overwhelm nodes by congesting the mempool and exponentially increasing the size of the blockchain. Ethereum tried to solve a similar problem with its Solidity language, without much success, as Ethereum's adoption now depends on its layer 2 solutions.

So, why consider reintroducing OP_CAT into the Script language if it risks overloading Bitcoin nodes and reducing decentralization in the long term?

The simple reason is that the introduction of Tapscript in 2021 during the Taproot update mitigated this risk by imposing a 520-byte limit on stack elements. As a result, OP_CAT can be safely reintegrated into Script without compromising Bitcoin's decentralization.

The reactivation of OP_CAT is driven by the desire to add more powerful and flexible functionality to Bitcoin's script without altering the network's fundamentals or affecting users who are not interested in these features.

However, integrating OP_CAT could enable the creation of various covenants, including recursive covenants, which would increase attack surfaces.

Although this opcode could potentially transform the way scripts are written and used, it also poses significant risks for Bitcoin that must be carefully evaluated. Several Bitcoin developers, however, believe these risks are overstated.

If OP_CAT were to be reintroduced, it could happen within 1 to 5 years, following extensive discussions, rigorous testing, and a community vote.

In conclusion, OP_CAT is considered the simplest and most comprehensive way to add flexibility to Bitcoin. However, if its reintroduction does not materialize, other opcodes with less individual flexibility might be added, or OP_CAT could be reintroduced alongside other opcodes.

OP_CHECKTEMPLATEVERIFY, also known as "OP_CTV," is an opcode proposed by Jeremy Rubin in 2019 as part of BIP 119.
‍
This opcode allows for the creation of covenants based on a transaction’s hash, introducing non-recursive covenants into Bitcoin that can predefine how the next transaction must be constructed.

The idea behind OP_CTV emerged from the need to create more secure and efficient transactions for Bitcoin, particularly for applications such as Vaults, payment channels in the Lightning Network, transaction congestion control, improvements to DLC, and the creation of the layer 2 solution Ark.

In practice, a transaction using OP_CHECKTEMPLATEVERIFY must include a 32-byte hash on the stack, called a "commitment hash," which represents the hash of the next transaction. This hash commits to the future structure of the transaction, including the distribution of funds between two or more parties.

If the parties decide to modify this distribution, a new commitment hash is generated to reflect the new allocation. OP_CTV thus allows this hash to be updated in the script, but only if all concerned parties agree to the new conditions.

This update ensures that the UTXO spending follows the predefined conditions agreed upon by all participants, while maintaining strict control over the evolution of transactions, enabling secure and consensual modifications of BTC distribution even as conditions change.

The OP_CHECKTEMPLATEVERIFY code is particularly simple compared to OP_CAT and has been ready for several years.

Here are the main differences between OP_CTV and OP_CAT:
- Flexibility: OP_CTV is less flexible but also more predictable than OP_CAT, reducing the risks of vulnerabilities in its use;
- Potential Applications: OP_CTV is ideal for the development of several applications, while OP_CAT allows for more sophisticated applications, including the creation of complex scripts and layer 2 solutions like rollups;
- Risk of Overload: OP_CTV was designed to minimize its impact on the Bitcoin network by remaining limited in function, whereas OP_CAT requires additional precautions to avoid overloading the network;
- Adoption and Implementation: OP_CTV has significant support from the Bitcoin community, allowing for a potentially faster adoption due to its simplicity;
-Future Evolution: OP_CTV can meet most of the current needs of Bitcoin developers without over-complicating the system, whereas OP_CAT offers greater potential for future evolution.

However, OP_CTV does have a major limitation, highlighted by Peter Todd a few months ago. He pointed out that the implementation of CheckTemplateVerify (CTV) doesn’t truly solve Bitcoin’s scalability issues because it requires each user to have a UTXO to pay transaction fees, negating the advantages of UTXO sharing.

Indeed, while CTV allows for the sharing of a UTXO between different people, its use requires the possession of an additional UTXO to cover transaction fees, which doesn’t address the scalability challenges faced by the Lightning Network.

On the other hand, the fact that OP_CHECKTEMPLATEVERIFY is non-recursive gives it significant adoption potential compared to OP_CAT. As explained earlier, recursion could allow malicious entities or development bugs to affect the fungibility of BTC, potentially even enabling censorship.

Although such censorship could be implemented by other means almost as easily, and many Bitcoin developers believe the risks of exploiting this tool are overstated, OP_CAT would still introduce a new attack surface against user sovereignty.

The flexibility and lower impact on the Bitcoin blockchain give OP_CTV a significant advantage in community debates. Nonetheless, it’s worth noting that both opcodes could be added to Script simultaneously.

There are numerous proposals for adding opcodes to create different types of covenants. Below is a brief description of the proposals that have garnered the most attention from the Bitcoin community.

SIGHASH_ANYPREVOUT (APO), proposed in BIP-118, is an update to the SIGHASH_NOINPUT concept that allows signing a transaction without referencing a specific UTXO as input. This flexibility enables a pre-signed transaction to be funded later by various UTXOs, as long as the scripts are compatible.

APO is particularly useful for applications like Eltoo, which improves the management of Lightning Network channels, and can also be used for mechanisms such as Statechains and Spacechains. However, APO presents challenges in terms of security and complexity, requiring careful management during its implementation.

OP_VAULT is a proposal that introduces two new opcodes in Tapscript, OP_VAULT and OP_VAULT_RECOVER, specified in BIP-345.

These opcodes, in combination with OP_CHECKTEMPLATEVERIFY (CTV), allow for a delay before BTC can be spent to an arbitrary destination, unless they are sent through a pre-specified recovery path.

Before the final spending, the BTC can still be redirected to this recovery path. OP_VAULT aims to enhance the security of BTC by offering extra protection against theft, allowing the user to intervene in case of a theft attempt.

The TXHASH and CHECKSIGFROMSTACKVERIFY opcodes have been proposed to decompose and replicate the functionalities of CTV and ANYPREVOUT in a more flexible and modular manner. In essence, together they could replace all other covenant proposals.

Specifically, TXHASH generates transaction hashes based on specific parameters, while CHECKSIGFROMSTACKVERIFY verifies signatures from those hashes.

Although ANYPREVOUT can simulate CTV, it does so at a higher cost. TXHASH and CHECKSIGFROMSTACKVERIFY provide an alternative that allows for building covenants and other applications with a simpler and more adaptable set of opcodes, albeit at the cost of consuming more space.

Bitcoin developers and its community are known for taking several years to implement updates. Throughout its history, Bitcoin has only experienced two major updates: SegWit and Taproot, unlike other blockchains that evolve their consensus rules more regularly.

Some believe this slowness is a flaw, as it prevents Bitcoin from scaling more quickly. Others, however, see this cautious approach as beneficial, allowing the entire community to take the time to form an informed opinion while protecting the network from potential attacks.

For example, if someone were able to convince influential community members to increase the total BTC supply from 21 million to 42 million, and updates were rolled out quickly, developers, influencers, and community members could accept the change without having had the time to conduct technical tests on a testnet or to assess the implications of such a modification.

Therefore, the implementation of a previously proposed opcode could still take several years. This is why it’s crucial to delve deeper into the subject and gather as much information as possible about the potential risks and complications associated with such changes.