CheckTemplateVerify (CTV) is a soft fork proposal for Bitcoin specified in the Bitcoin Improvement Proposal (BIP) 119. It aims to enable new use cases for the network by adding a basic type of “covenant,” or smart contract, which is more than what can be achieved at the moment.
Why Covenants?
Bitcoin, as is, doesn’t possess a lot of flexibility in its programmability at the base level of transactions — and certainly not as much flexibility as it has at the level of the public and private keys used to sign transactions.
A programmer can currently control the inputs of a transaction with Bitcoin Script, restricting what can be done before a transaction is spent, but they can’t control what types of transaction are permitted to be signed for. In other words, in most Bitcoin smart contracts today, a user can control how a coin can be unlocked by defining restrictions necessary to be satisfied. But they can’t control very well what can be done with that coin once it is unlocked.
For instance, one can define a certain amount of time before a transaction can be spent with a timelock, effectively locking that transaction until the specified block height is reached. In this case, restrictions are being imposed on when funds can be spent, preventing the correct key from unlocking those funds and spending them. However, after that time expires and the block height is reached on the Bitcoin blockchain, the key can unlock those funds and spend them freely. The when is restricted, but not the what or how.
Therefore, covenants have the power to unlock a new set of possibilities to the way Bitcoin can be programmed by enabling a pre-definition of which outputs are acceptable, instead of just controlling the inputs. Although complex covenants with endless possibilities could bring security risks to the network by potentially enabling unexpected or unintended consequences, the proposal for CTV is, for the most part, simple.
What Is CTV?
In short, CTV allows a Bitcoin user to restrict the way they can spend bitcoin even if they have the key to the bitcoin they want to spend.
More importantly, CTV allows these spending restrictions to be enforced non-interactively. Some use cases enabled by CTV could be made possible today, but most of the time the set of users participating in the smart contract arrangement would need to be online and manually interact to coordinate the spending rules, which isn’t always possible. CTV enables these restrictions to be enforced programmatically, without requiring manual interaction by participants, hence increasing the reliability of the covenant.
Today, you can spend your UTXOs however you want. In a post-CTV world, you could put rules in place over your UTXOs to control or limit the possible ways you could spend those coins. Not when they are spent, but how. By bringing these types of new features into Bitcoin, a more diverse set of use cases could be enabled, and a new ecosystem of applications could emerge.
Some of the functionalities that CTV could enable for Bitcoin include enhancements in security, privacy and scalability. With the activation of CTV, users would be able to create more sophisticated custody solutions, like vaults, that could allow a Bitcoin user to pre-define scheduled and limited spending of bitcoin from cold to hot storage, hence limiting the damage from a potential hack. CTV could also bring payment pools, a type of arrangement where a group of people can share a single UTXO and trustlessly rebalance funds among them, not only increasing their privacy but also enabling better scaling opportunities for Bitcoin. Moreover, CTV could supercharge the Lightning Network with improvements in channel creation and redemption, as well as in hash time locked contracts (HTLCs), thereby increasing efficiency and liquidity in Bitcoin’s second-layer protocol.
How Does CTV Work?
Under the hood, CTV brings a new opcode for Bitcoin, a new addition to the set of operations available in Bitcoin Script.
BIP119 adds the new opcode OP_CHECKTEMPLATEVERIFY to Bitcoin through OP_NOP4, implementing a consensus change in the protocol through a soft fork.
Currently, numbered OP_NOPs (OP_NOP1 and OP_NOP4 through OP_NOP10) are ignored when used while not making the transaction invalid; more notably, they are reserved opcodes that can be leveraged to add new opcodes to the protocol. However, that doesn’t hold true to OP_NOP itself (with no numbers), as it is a “non-operation” opcode.
BIP119 seeks to resignify OP_NOP4 to assume a verification role in the form of OP_CHECKTEMPLATEVERIFY, a procedure that was also leveraged for the addition of OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY to the protocol, ressignifying OP_NOP2 and OP_NOP3, respectively.
OP_CHECKTEMPLATEVERIFY does three checks when it is run. First, naturally, it checks if there is at least one element on the stack. If there is, it then checks if the element has exactly 32 bytes — the size of a SHA-256 hash. If there is an item on the stack and it has 32 bytes, then CTV will check if it matches the hash of the transaction at the current input index.
This step — checking if the element matches the hash — is exactly where the enforcement happens. Here, the program is verifying whether the transaction passed to it is part of the set of transactions previously specified by the contract (or covenant) as the “possible ones” — the ones that would receive approval. This set of transactions would have been previously defined by the user in a contract.
Though not necessary for building contracts that can be enforced with CTV, Sapio is a programming language under development designed specifically for this purpose. It abstracts away low-level programming details to facilitate building smart contracts for Bitcoin with, for example, components — reusable pieces of code that improve readability and usability of a program.
Programmers first build a template with Sapio, specifying some conditions, which then outputs a list of partially-signed bitcoin transactions (PSBTs) that can be leveraged to define an exhaustive set of transactions for spending — allowing us to constrain the set of allowed outputs in a transaction to a set that is smaller than the set of all possible outputs.
CHECKTEMPLATEVERIFY pre-commits to a transaction by constraining most of the data that determines all of the possible transaction IDs (TXIDs) ahead of time. This means, given a specific UTXO and a contract, you can usually pre-compute all of the TXIDs. Although restrictive, the assumption is that by knowing the TXIDs in advance, the covenant is easier to be enforced as the universe of transactions to be checked is restricted.
The specific hash function being analyzed by the opcode DefaultCheckTemplateVerifyHash hashes parts of a transaction in a serial manner, starting with version and locktime. Next, the function hashes the scriptSig hash if the transaction is not a SegWit transaction, and then it hashes the number of inputs, the hash of the sequences and the number of outputs. Lastly, the function hashes the outputs’ hash and the input index.
By committing to (or determining) most of these in advance, not only can the TXID be determined beforehand, but it also enables only a few of those to be set later on (to be malleable) and makes validation more efficient, as plenty of fields had already been hashed.
“The idea of ordering the fields in a particular way was that if at some point in the future you had something like OP_CAT in Bitcoin, you might be manipulating these on the stack,” Jeremy Rubin, the author of BIP119, told Bitcoin Magazine. “There’s some benefit for them to be in order of how likely you might be to change them programmatically.”
“So, part of the thinking was that nVersion is the least likely to be changed, input index is the most likely to be changed, and everything else falls in the middle in that order,” Rubin added.
The assumption is that a Bitcoin developer programming a covenant is more likely to programmatically change information about the outputs than the inputs, given the fact that a covenant tries to restrict how a coin can be spent.
Therefore, what OP_CHECKTEMPLATEVERIFY does is check if the transaction is allowed. In other words, it enforces the restrictions imposed by the covenant programmed with Sapio.
But that check only happens if the element on the stack is 32 bytes in size. If not, CTV will OP_NOP the element on the stack, meaning it will not fail execution, but rather “do nothing.”
This subtle difference seeks to accommodate future developments that could be built after CTV, for instance, a “CTV version two” that adds a flag byte to it — making the element 33 bytes. Then, instead of using CTV to check it, since it only checks elements of 32 bytes, the element would be checked by the “CTV version two” that checks 33 bytes. And that’d be possible because the OP_NOP enabled the script evaluation to continue. If it had failed instead, evaluation would not have continued and thus the element would not have been checked against “CTV version two.”
“Transactions with a 33 byte CTV would still be rejected by the network under standardness rules with these changes, but would be valid if a miner put it in a block,” Rubin explained. “This ensures the expectation that it will be assigned a specific meaning in the future, discouraging careless use.”
Will CTV Be Bitcoin’s Next Upgrade?
The Bitcoin upgrade process is known for its methodic and careful approach, a vital characteristic to the survival of the network and the ensured correctness of each new addition to the code. Therefore, it is very much unclear whether or not CTV might be added to Bitcoin any time soon.
Although not a new proposal — the BIP was created in January 2020 — prominent Bitcoin developers argue that there needs to be more extensive testing and discussions around the suggested changes, especially when it relates to possible optimizations and a more detailed consideration of alternatives.
CTV, at the time of writing, would add a limited set of new possibilities to Bitcoin as it seeks to implement a low-risk form of covenants into the protocol. Rubin told Bitcoin Magazine that the goal is to ship something that enables new functionality for Bitcoin while being “most likely one of the simplest soft forks in terms of the impact on Bitcoin validation that we’ve ever done.”
“Upgrades such as CLTV or CSV, for example, required both a soft fork to add an opcode and a soft fork to consensus-enforce the nLockTime and nSequence field (contextual data), whereas CTV validity only checks a property inherent to the transaction,” Rubin added.
Rubin also said that he feels like “there’s a little bit of a double standard” being applied in reviews of his proposal by the developer community.
“This is a much higher bar that CTV is being held to than anything we’ve done previously,” he told Bitcoin Magazine. “While we should always seek to raise the bar,” Rubin clarified, “it should not come without acknowledgement that CTV already meets or exceeds the level of testing and applications of prior forks.”
Earlier this month, Bitcoin and Lightning Network developer at Spiral, Matthew Corallo, tweeted that “at no point in Bitcoin’s history has it been okay to propose shipping things into consensus… without considering alternatives.” Corallo claims that Rubin, and those working on and supporting CTV in general, for the past couple of years have failed to show “a more formal approach to comparing it to alternatives.”
“The push for CTV feels… wrong in just about every way,” Corallo added. “Instead of collaborative engineering it feels like ‘I built this, let’s do it’ while ignoring any feedback.”
A desire for further experimentation and analysis is also shared by Blockstream’s director of research, Andrew Poelstra. When asked if CTV would be Bitcoin’s current best shot at extending functionality to support covenants, he told Bitcoin Magazine that he “would suggest not,” adding that “CTV is not the only proposed way to implement covenants in Bitcoin — and it hits a tradeoff between safety and generality which leaves room in either direction.”
“One way this could work is that CTV may be the most efficient way to implement ‘subtractive covenants,’ in which users restrict the majority of transaction data while leaving only a small part free,” Poelstra said. “Meanwhile, other proposals such as introspection opcodes may be best for ‘additive covenants’ where the majority of transaction data is free and only a small amount is restricted. If this is true, and the community needs more time to explore this, then we would actually want APO and CTV and general-purpose covenants.”
APO, or OP_ANYPREVOUT, is another proposal for adding new functionality to Bitcoin, specified in BIP118. Its author, Christian Decker, a researcher at Blockstream who focuses on scaling solutions for Bitcoin, told Bitcoin Magazine that he also considers APO and CTV “to be complementary and not competing” additions to Bitcoin.
“Both are beneficial,” Decker said. “So I agree we should activate them together when both of them are ready, reviewed and tested.”
At the moment, readiness for activation is a delicate topic in the Bitcoin community. In fact, part of the pushback against CTV by some developers is based on a supposed sense of urgency being portrayed by CTV proponents. Rushing into deployment could be harmful if changes that aren’t ready end up being added to Bitcoin’s code.
Decker told Bitcoin Magazine that he is comfortable with waiting longer for his proposal to be added to Bitcoin if that would mean a more robust testing process being employed, though he said he understands CTV proponents’ desire to activate as soon as possible.
“We don’t think it is beneficial to push a change through, and that APO needs to be urgently deployed,” Decker said. “The longer the proposal can stew, the more eyes can review it and highlight potential weaknesses. Reviewer and developer time are Bitcoin’s rarest resource, so we want to be respectful of that, despite having some [proof of concept] implementations of eltoo for example.”
In December 2021, in an effort to attract more eyes to his proposal, Rubin set up a bug bounty for CTV and its specifying BIP, saying he would grant $10,000 to anyone who found a “substantial” flaw in the suggested soft fork. The bounty has since grown immensely, but some developers, including Corallo and Adam Back, legendary cypherpunk and CEO of Blockstream, questioned Rubin’s initiative, suggesting that it was probably not the best solution for getting more reviewers.
Despite the pushback on covenants from parts of the community, Poelstra said he believes that “there is no real resistance in the Bitcoin community to any of these ideas; we really just need individuals to champion them and push forward on public communication, tooling, test vectors, exploring use cases, etc., the way that Jeremy has with CTV.”
Besides heated discussions on Twitter, Rubin’s proposal has received more formal feedback and questions in the bitcoin-dev mailing list. Developers that have recently given feedback on CTV include Michael Folkson, Peter Todd and Luke Dashjr. Decker has also shared his thoughts on the intersection between CTV and his proposal. Poelstra shared feedback and suggestions for CTV with Bitcoin Magazine.
“If CTV is the way that the Bitcoin community wants to go, there are two ways that I would suggest improving it: the first would be to change its hashing structure to be useful for more general covenant applications,” he said. “How to do this, exactly, is an active area of research that I hope we will learn much more about in the coming weeks. Perhaps CTV should have ‘sighash flags’ analogous to the existing flags for signature checks.”
“Secondly, I would suggest slightly changing CTV to merely push the transaction hash onto the stack, and require the user use the existing EQUALVERIFY opcode to check that it matches a given template,” he added. “This will cost ordinary CTV users a single byte of transaction witness data, while widening the design space for future extensions to Bitcoin.”
Rubin, on the other hand, told Bitcoin Magazine that he believes it is more useful to ship CTV as is, even though it brings limited functionality, and to iterate on additional features later.
In summary, although BIP119 has been generating a lot of buzz among the Bitcoin community, the future path for the proposed upgrade isn’t clear. The desire of proponents to increase Bitcoin’s scope of functionality to accommodate new use cases is clashing with some old-timers’ more cautionary approach.
Furthermore, given Bitcoin’s history of only pushing upgrades that achieve overwhelming consensus and have been thoroughly reviewed, there may be a bumpy road ahead for CTV as Rubin tries to advocate for his improvement proposal. The developer has gone the extra mile in creating a dedicated website with plenty of resources to educate interested Bitcoiners about the possibilities that CTV could enable, but his enthusiasm for a Bitcoin protocol with new functionality hasn’t yet received the blessing of major figures in the Bitcoin development community.
For now, BIP119 looks stalled, pressed between those in favor of adding exciting new use cases to Bitcoin and those warranting a more careful approach before enacting a consensus change in the world’s most revolutionary monetary system, a network that should last for thousands of years and cannot afford any missteps.
All in all, it might be some time before the two cohorts reach an agreement, but as the proposal gathers more understanding and interest among community members, the path for a consensus to be reached is being paved.
Special thanks to Rubin, who patiently helped the author bridge some gaps in his understanding. For a more detailed explanation of BIP119 technicals, watch this workshop from a couple of years ago (part one and part two). A transcript is available on this link. Other helpful resources are this conversation, this podcast episode and this other one, as well as a conversation between Rubin and Poelstra. To be a part of the conversation around BIP119 and hear the latest discussions on the matter, join the bitcoin-dev mailing list.