This is the initial article in a series that delves deeply into specific covenant proposals that have matured to a level warranting a thorough analysis.
CHECKTEMPLATEVERIFY (CTV), proposed by Jeremy Rubin within BIP 119, stands as the most advanced and comprehensive covenant proposition, not only among those we will examine, but across all covenant proposals in totality. As I noted in the introductory piece to this series, there are numerous apprehensions in the ecosystem concerning covenants that are overly adaptable, leading to outcomes that could severely harm Bitcoin.
CTV was crafted explicitly to limit its functionalities closely enough to mitigate any of these concerns. To adequately grasp how CTV operates, we must first comprehend the separate components of a Bitcoin transaction.
Here, we present a very broad overview of a Bitcoin transaction. It comprises inputs, or unspent coins (UTXOs), and outputs, the new unspent coins that the transaction will generate once it is confirmed in a block. There are many additional elements we will explore, but this represents the most fundamental view of a transaction’s framework.
Every transaction also includes a version number field for the entire transaction, indicating relevance to new iterations of rules or features. There is additionally the marker and the flag, assigned specific values to denote the transaction utilizes Segwit. Following this is the input count, which is the number of inputs in the transaction. Then we have the actual inputs.
Each input holds a TXID of the transaction that generated the unspent coin being utilized, a VOUT designating which output in that transaction is being spent, the size of the ScriptSig, and the ScriptSig itself, which serves as the unlocking script verifying that the input being spent is sanctioned by its locking script stipulations, along with a Sequence number that is employed to confirm that the input being used adheres to relative timelock conventions, e.g., the input has been valid for a specified block count or duration since its inception.
The output count is the subsequent piece of information, representing the quantity of outputs in the transaction. After this follows the actual outputs, which encompass an amount of satoshis designated to that output, the ScriptPubKey size, and the actual ScriptPubKey, which acts as the locking script for that output. Lastly, the nLocktime field applies a timelock value in timestamp or block height that pertains to the entire transaction.
Every Segwit transaction also contains a Witness section, where each input has a corresponding witness featuring a Stack Items count, indicating how many items will be added to the script stack, a Size field for each item, and the actual data Item to be placed on the stack.
How CTV Operates
CTV is an opcode that facilitates the most basic form of introspection and forward data transfer among all the covenant proposals. It enables a script to accept a pre-defined 32-byte hash and compare that with a hash of the majority of the fields in the spending transaction. If the hash generated from the actual spending transaction does not coincide with the pre-defined hash, the transaction becomes invalid.
The fields it commits to are:
- nVersion
- nLocktime
- Input count
- A hash of all the nSequence fields
- Output count
- A hash of all the outputs
- Input index (the position of the input in the transaction, 1st input, 2nd, etc.)
These consist of all the fields that the CTV hash commits to, in their entirety, with no capability to selectively choose. This is the extent of introspection that CTV permits: “does the hash of these fields in the spending transaction correspond to the hash in the locking script of the input being used,” and that’s all there is to it. The hash essentially commits to the entirety of the transaction, excluding the actual inputs. There is a specific rationale for the hash not encompassing the inputs. To secure an output to a 32-byte hash using CTV, it is necessary to know the hash of the transaction that you are ensuring is the sole method for its expenditure. The input secured with CTV, upon being spent, must incorporate this hash to validate it against CTV. This makes it essential to possess the hash of that transaction before crafting the entire transaction. That is not feasible.
Additionally, you may nest CTV scripts, i.e., have an initial CTV script commit to a transaction with outputs that also incorporate CTV scripts. This capability allows CTV to “carry forward” data. However, in practice, it merely propagates whatever data is encapsulated in the series of transactions. Theoretically, this can be done to infinite depth, but practically, you face limitations since the nesting must be created in reverse, starting from the end. This is because each level, or “hop,” must possess the hash of the transaction transitioning to the next one; otherwise, the locking script cannot be constructed initially. If you lack knowledge of the next transaction, creating the previous one becomes impossible.
What Is CTV Beneficial For
CTV enables you to impose restrictions on an output such that it can only be spent, as per consensus regulations, by an exact pre-defined transaction. Some of you may be curious about the significance of this; we can already pre-sign transactions. If the level of introspection is so restricted that it can only achieve what we can already do with pre-signing, what is the added value?
Firstly, pre-signed transactions constantly leave room for the keyholder(s) to sign new transactions and utilize those coins differently. You must place your trust in the keyholder not to do this or to erase the key necessary for signing (a trust issue, as well). CTV entirely eliminates that trust. Once the spending transaction is delineated and the output secured to that CTV hash is produced, there is no chance of it being spent in any other manner, enforced by consensus.
Presently, the only method to bypass this trust is to engage in pre-signing transactions yourself using multisig. In that case, you can be entirely assured that, unless you opt to sign one yourself, no other valid transaction expending a coin differently can be created. The problem arises that the more individuals involved, the more challenging and unreliable coordinating everyone to pre-sign a transaction simultaneously becomes. Beyond certain small group sizes, it becomes impractically difficult to solve reliably.
CTV provides a means for individuals to confirm that a set of transactions is agreed upon without requiring everyone to be online simultaneously to sign them. It significantly streamlines the coordination process by allowing each participant to share the necessary information at their convenience, and once an individual has everyone’s information, they can create the series of CTV transactions independently, enabling everyone to verify and ensure that the intended outcome is the only attainable one.
That is immensely valuable by itself, but CTV can also facilitate even more advantageous functionalities when combined with other opcodes, which we will explore in the forthcoming article.
Concluding Thoughts
CTV is a precisely constrained covenant that provides a level of introspection and forward data handling that is so restricted it does not surpass the actual functionality of anything achievable with pre-signed transactions. The value proposition is not about enabling new capabilities in its own right, but significantly enhancing the effectiveness, scalability, and security assurances of what can be established currently utilizing pre-signed transactions. This alone presents a tremendous advantage to nearly every presently implemented protocol using pre-signed transactions.
Here are several projects showcasing how exhaustively developed and examined this particular covenant is in comparison to others:
- A fundamental payment pool example by stutxo.
- A CTV vault implementation by James O’Beirne, who later proposed OP_VAULT (which still incorporates CTV).
- A proof-of-concept adaptation of the pre-signed transaction based Ark implementation from Second by Steven Roose to utilize CTV instead.
- The Sapio Language by Jeremy Rubin himself, a higher-level language for constructing contracts incorporating CTV (also facilitating the use of pre-signed transactions).
- Timeout Trees, a proposal for a very basic coinpool structure by John Law.
- A plethora of other potential protocols, such as refined Discreet Log Contracts (DLCs), non-interactive Lightning channels that one party could initiate without the consent of the other, and even decentralized methods for miners to collaborate.
At this stage, CTV is an exceptionally mature proposal, offering significant added value while posing no risk of enabling any issues that fuel the concerns surrounding covenants. This should not only be taken into serious consideration but, in my personal view, should have been implemented years ago.
