Analysis of the paper published by developer Peter Todd. Not just CTV: the most notable covenants and layer-2 proposals to improve Bitcoin’s scalability.
In Bitcoin, on-chain transactions follow a one-to-one ratio: for each transaction, it is necessary to perform a transaction on the timechain. The Lightning Network improves this ratio, allowing many transactions to take place in a single channel, linked to a single UTXO.
However, having a UTXO for each user may not be sufficient for the scalability of the protocol. For this reason, there are several proposals to allow more people to share ownership of a single UTXO independently, further improving the scalability of the network.
What is a layer-2
A layer-2 (L2) solution is defined as a system designed to enable more frequent transactions compared to on-chain transactions.
In the paper, Todd clarifies that an L2 must meet two fundamental requirements:
- ensure that no one can steal funds;
- allow the owners of the funds to withdraw them unilaterally without the cooperation of third parties.
This definition makes it possible to exclude from the category of L2 solutions such as Liquid, Cashu, Fedimint, RGB, and Statechain, which are systems that involve the control of third parties over the funds or do not allow to transact directly in bitcoin in a trustless manner.
How to unpack a UTXO for multiple people? Channels and V-UTXO
Among the various L2 scalability solutions, two main approaches emerge: channels and V-UTXO.
The channel model, used by the Lightning Network, is based on pre-signed transactions between the parties, who divide a UTXO and allow continuous transactions without the need to register them on-chain, unless it is necessary to resolve a dispute between the two parties.
On the other hand, the V-UTXO (Virtual UTXO) model, as proposed by the Ark project, offers an approach where the UTXOs are virtualized and managed off-chain, allowing transactions between users without creating new “real” UTXOs on the blockchain. V-UTXOs can be created, transferred, and spent efficiently, with a coordinator managing their duration and validity. We could compare V-UTXOs to a bank-issued check with an expiration date. This approach allows sharing a single UTXO among multiple users, reducing the load on the timechain and improving scalability.
Lightning Network: current state and limitations
According to Todd, the Lightning Network is currently the most advanced L2 system for Bitcoin, but it has some important limitations:
- Scalability: Lightning requires at least one UTXO per end-user, limiting overall scalability;
- Liquidity: Funds must be locked in channels to facilitate transactions;
- Interactivity: Recipients must be online to securely receive payments.
Despite these obstacles, the Lightning Network remains effective for routing payments, and many L2 solution proposals intend to integrate with LN.
Most interesting L2 proposals
Channel Factories
With Channel Factories, instead of opening a channel between just two users, multiple people agree to create a single multisig address where they deposit their funds.
From the multisig address locked on the timechain, off-chain channels are created between the users. Each user can open a channel with the others. These channels can be closed and reopened without ever returning to the timechain, as long as the transactions do not exceed the amount of funds initially deposited on the multisig address.
Channel Factories therefore allow multiple users to share a single UTXO, reducing the number of on-chain transactions required to open and close channels.
They do not require updates to the Bitcoin protocol to function, but in practice they are complicated to manage if there are too many participants, making it difficult to obtain a real scalability benefit. To improve management and allow individual participants to act without involving everyone, solutions like OP_Evict or OP_CTV have been proposed.
LN-Symmetry/Eltoo
Also known as Eltoo, LN-Symmetry simplifies Lightning channels by removing penalties for publishing incorrect state, allowing instead to correct a wrong version of the channel state with a new transaction. This proposal simplifies the management of a Lightning node, facilitating the backup procedure in a reliable and secure way.
Although it does not directly improve scalability, it can facilitate the implementation of solutions like Channel Factories.
LN-Symmetry requires a modification to the Bitcoin protocol (soft-fork) to enable SIGHASH_ANYPREVOUT, which allows state transactions to reuse other state transactions during updates.
Ark
The Ark protocol architecture proposes the use of transferable and expiring virtual UTXOs (V-UTXOs) to increase the scalability of Bitcoin.
A central coordinator (Ark Service Provider), which cannot access user funds, manages the creation and management of V-UTXOs through defined time rounds, usually of four weeks.
To obtain a new V-UTXO, users must go online before the round expires to avoid the funds becoming the property of the ASP. To reach its full potential, Ark requires the enablement of covenants like CTV.
Covenants: a necessity for L2s?
A covenant is a mechanism that limits how an UTXO can be spent. With a covenant, in addition to the transaction signature, other conditions are required to be able to spend an UTXO.
The constraints established by covenants allow enabling a series of new properties for the Bitcoin protocol.
L2 systems that allow multiple users to share a single UTXO need covenants to limit how that UTXO can be spent, in order to apply the rules and incentives provided by the L2 protocol.
Initially, Satoshi Nakamoto introduced 15 opcodes in Bitcoin Core, only to remove them shortly after due to possible future bugs or unintended consequences.
Below is an analysis of some of the main operators (opcodes) that enable certain types of covenants.
OP_Expire
OP_Expire is an operator designed to solve the problem of HTLC replacement cycling attacks. OP_Expire allows making an UTXO non-spendable after a certain amount of time, thus simplifying the spending conditions. OP_Expire could be useful in various contexts as a solution to the replacement cycling problem, but it does not seem essential for the functioning of Bitcoin.
SIGHASH_ANYPREVOUT
SIGHASH_ANYPREVOUT was originally proposed for LN-Symmetry to simplify the management of LN channels. In practice, it allows avoiding the need to separately sign each previous state of the channel, which might need to be restored or updated. Instead of having to create and sign many transactions for every possible channel modification, SIGHASH_ANYPREVOUT allows doing it more efficiently and with less complexity.
CTV
OP_CheckTemplateVerify (CTV) is a proposal that allows limiting how an UTXO can be spent in the future. This allows establishing certain rules in advance on how an UTXO can be spent, but without creating complicated recursive constraints, i.e., it cannot create rules that apply indefinitely over time to every future transaction. It is a measure to manage transactions in a more controlled way without adding excessive complexity.
Some of the constraints introduced by CTV can be:
- an UTXO that can only be spent to certain specific addresses;
- a limit on the amount of bitcoin that can be spent on-chain;
- a limit on the number of outputs a transaction can create.
One of the use cases that CTV enables in a compatible way is that of Vaults. Vaults are a type of covenant that requires two separate transactions, inserted in two different blocks, to allow a user to spend funds from their wallet. The first transaction serves as a signal that someone is trying to spend the funds, giving the user the ability to block the second transaction, which is the one that actually completes the operation. In this way, Vaults offer an additional level of security, allowing the user to intervene in case of unauthorized spending within a certain time frame.
Thanks to its simplicity, CTV currently has the most support from the technical community compared to any other covenant opcode proposal.
OP_CAT
The concatenation operator, called OP_CAT, takes two elements from a data stack and joins them into one. In practice, it allows combining two pieces of data into a single piece during the execution of a Bitcoin transaction.
Despite appearing very simple, OP_CAT can be very powerful and versatile.
Precisely for this reason, the main problem lies in the difficulty of predicting all the ways and all the possibilities of use that OP_CAT could make possible. One argument against OP_CAT is that some of the new possibilities it could create would not necessarily be beneficial for Bitcoin users and could lead to unforeseen and not always positive consequences for the network (e.g., drivechain or alternative projects to Bitcoin).
According to Todd, CTV currently represents the best compromise for considering a potential soft fork, enabling the use cases proposed by the Ark protocol, and improving the functioning of the Lightning Network.
