Bitcoin Magazine
Exploring Bitcoin Covenants: CHECKTEMPLATEVERIFY (BIP 119)
This piece serves as the inaugural deep dive into specific covenant proposals that have reached a level of development warranting a thorough examination.
CHECKTEMPLATEVERIFY (CTV), proposed by Jeremy Rubin as part of BIP 119, stands out as the most advanced and comprehensively developed covenant proposal, surpassing not only those set to be discussed here but all existing covenant proposals overall. As highlighted in the introductory article of this series, there are considerable apprehensions within the ecosystem regarding covenants that are overly flexible, potentially leading to severely harmful outcomes for Bitcoin.
The design of CTV is intentionally restrictive, aimed at addressing these concerns by limiting its capabilities. To grasp how CTV operates, itโs essential to dissect the various components that constitute a Bitcoin transaction.
At a high level, a Bitcoin transaction comprises inputs, which are unspent coins (UTXOs), and outputs, which are the new unspent coins generated upon confirmation of the transaction in a block. While there are more elements to discuss, this overview captures the fundamental structure of a transaction.
Each transaction includes a version number, which indicates the applicability of newer rules or features. Additionally, there’s a marker and a flag that are set to specific values to signify the use of Segregated Witness (Segwit). Following this are the input count and then the actual inputs themselves.
Each input consists of a transaction ID (TXID) of the transaction that birthed the unspent coin, a VOUT denoting which output is being utilized, the size of the ScriptSig, and the ScriptSig itself, which is the unlocking script that confirms the legitimacy of the input according to the locking script’s rules. Lastly, thereโs a Sequence number used to verify relative timelock rules, ensuring the input has existed for an appropriate number of blocks or a certain duration post-creation.
The output count follows, revealing how many outputs exist within the transaction. Next come the outputs, featuring the amount of satoshis allocated to each output, the ScriptPubKey size, and the actual ScriptPubKey, which serves as the locking script for that output. The nLocktime field enforces a timelock constraint based on either a timestamp or block height applicable to the whole transaction.
Moreover, every Segwit transaction contains a Witness section, where each input corresponds to a witness comprising a Stack Items count, the total number of items to be placed on the script stack, a Size field for each item, and the respective data item to populate the stack.
Mechanics of CTV
CTV operates as an opcode that facilitates the most fundamental form of introspection and forward data transfer among the diverse covenant proposals. It permits a script to capture a pre-defined 32-byte hash and compare it with a hash derived from the majority of the fields in the spending transaction. Should the hash generated from the spending transaction fail to synchronize with the pre-set hash, the transaction is deemed invalid.
The fields that CTV commits to include:
- nVersion
- nLocktime
- Input count
- A hash of all nSequence fields
- Output count
- A hash of all outputs
- Input index (indicating the sequence of input in the transaction, whether it’s the first, second, etc.)
These fields are comprehensively included in the CTV hash with no selective option. The CTV-enabled introspection simply checks whether the hash of these fields within the spending transaction aligns with the hash embedded in the locking script of the input being utilized; that’s the crux. This hash effectively encapsulates the entire transaction aside from the actual inputs. The rationale behind not incorporating the inputs in the hash centers around the necessity of knowing the transaction’s hash before crafting the entire transaction to secure an output to a 32-byte hash via CTV. Therefore, for the CTV-locked input to be spent, it must also present this hash for validation against CTV, making it impossible to have the prior hash without the complete transaction being established first.
Additionally, CTV scripts can be nested, meaning one CTV script can commit to a transaction with outputs that also include other CTV scripts. This nesting capability allows CTV to effectively “carry forward” data. However, in practical applications, what it truly conveys is limited to the data contained within the sequence of transactions. While theoretically, this process can be executed to infinite depths, practical limitations exist. Each nesting level, or โhop,โ must have the transaction’s hash for moving to the next, making it impossible to generate the locking script initially if the next transaction is unknown. Thus, if one lacks knowledge about the subsequent transaction, the prior one cannot be formulated.
Applications of CTV
CTV empowers users to restrict an output such that it can solely be spent according to predetermined consensus rules associated with a specific transaction. Some may question the significance of this since pre-signed transactions already exist. If CTV’s introspection capabilities are so rudimentary that they only replicate pre-signing functionalities, what additional benefits does it offer?
One key distinction is that pre-signed transactions inherently leave a door open for the keyholder(s) to authorize new transactions, permitting alternate spending methods. Trusting that the keyholder will refrain from utilizing this option is essential, but CTV eliminates this requirement entirely. Once a spending transaction is established and the output locked to a particular CTV hash is created, there is no alternative for spending it, as enforced by consensus rules.
The only current workaround to this reliance on trust involves being part of a multisig-based pre-signing process. This approach certifies that unless an individual chooses to engage in signing, no valid transaction can be executed in a different manner. However, as the number of participants increases, coordinating simultaneous pre-signing becomes progressively complex and less reliable. Beyond a small group, it becomes impractical to achieve reliable consensus on pre-signing transactions.
CTV offers a solution for ensuring a series of transactions is committed without necessitating simultaneous online participation from everyone involved. It simplifies the coordination process, enabling individuals to relay the required information to one another at their convenience. Once a participant has collected each personโs information, they can create the sequence of CTV transactions independently of others, allowing everyone to verify and establish assurance that the designated outcome is indeed the only feasible one.
This capability is immensely valuable, but CTV also has the potential to unlock even greater benefits when combined with other opcodes, which will be explored in the subsequent article.
Final Insights
CTV represents a tightly controlled covenant that provides a limited yet significant degree of introspection and forward data transmission, closely mirroring functionalities attainable through pre-signed transactions. Its primary value lies not in introducing new functionalities independently but in greatly enhancing efficiency, scalability, and the security assurances of existing pre-signing methods. This enhancement presents tremendous advantages for nearly all protocols currently utilizing pre-signed transactions.
Numerous projects exemplify the extensive development and analysis of this covenant compared to its counterparts:
- A basic payment pool example developed by stutxo.
- A CTV vault implementation by James OโBeirne, who later proposed OP_VAULT, which still utilizes CTV.
- A proof-of-concept adaptation of the pre-signed transaction-based Ark implementation from Second by Steven Roose to leverage CTV instead.
- The Sapio Language developed by Jeremy Rubin, a higher-level language designed for crafting contracts with CTV (also allowing pre-signed transactions).
- Timeout Trees, a proposal for a foundational coin pool design by John Law.
- A myriad of other potential protocols such as optimized Discreet Log Contracts (DLCs), non-interactive Lightning channels that one party could initiate without requiring consensus from the other, and innovative decentralized methods for miners to collaborate.
At this juncture, CTV has matured into a sophisticated proposal with substantial added value, posing no risk of generating concerns associated with other covenants. It deserves serious consideration and, in my view, should have been activated long ago.
This article titled Bitcoin Covenants: CHECKTEMPLATEVERIFY (BIP 119) was first published on Bitcoin Magazine and authored by Shinobi.
