Bitcoin Magazine
Bitcoin Covenants: CHECKTEMPLATEVERIFY (BIP 119)
The is the first article deep diving into individual covenant proposals that have reached a point of maturity meriting an in depth breakdown.
CHECKTEMPLATEVERIFY (CTV), put forward by Jeremy Rubin with BIP 119, is the most mature and fully fleshed out covenant proposal, not only out of the proposals we will be covering, but out of all of the covenant proposals in their entirety. As I mentioned in the introduction article to this series, there are many concerns in the ecosystem regarding covenants that are too flexible enabling things that wind up having very detrimental consequences for Bitcoin.
CTV was designed specifically to constrain its capabilities tightly enough to avoid any of those concerns. To first understand how CTV functions, we need to understand the individual parts of a Bitcoin transaction.
This is a very high level view of a Bitcoin transaction. It has inputs, or unspent coins (UTXOs), and outputs, the new unspent coins that the transaction will create when it is confirmed in a block. There are a lot more pieces we will go through, but this is the highest level view of a transaction’s structure.
Every transaction also has a version number field for the whole transaction, indicating applicability of new versions of rules or features. There is also the marker and the flag, which are set to specific values to indicate the transaction uses Segwit. After this is the input count, the number of inputs in the transaction. Then come the actual inputs.
Each input contains a TXID of the transaction that created the unspent coin being spent, a VOUT which marks what output in that transaction is being spent, the size of the ScriptSig, and the ScriptSig, which is the unlocking script proving the input being spent is authorized by its locking script rules, and finally a Sequence number which is used to ensure the input being spent is following relative timelock rules. i.e. the input has existed for a certain number of blocks or length of time since its creation.
The output count is the next piece of data, the number of outputs in the transaction. After this comes the actual outputs, which contain an amount of satoshis assigned to that output, the ScriptPubKey size, and the actual ScriptPubKey, which is the locking script for that output. Lastly the nLocktime field applies a timelock value in timestamp or block height that applies to the entire transaction.
Each Segwit transaction also contains a Witness section, where each input has a corresponding witness containing a Stack Items count, how many things will be put on the script stack, a Size field for each item, and the actual data Item to go on the stack.
CTV is an opcode that enables the most basic form of introspection and forward data carrying out of all the covenant proposals. It allows a script to take a pre-defined 32 byte hash and compare that against a hash of most of the fields of the spending transaction. If the hash derived from the actual spending transaction does not match the pre-defined hash, the transaction is invalid.
The fields it commits to are:
These are all the fields committed to by the CTV hash, in their entirety, and with no ability to pick and choose. This is the degree of introspection CTV enables, “does the hash of these fields in the spending transaction match the hash in the locking script of the input being spent,” that’s it. The hash commits to essentially the entire transaction except the actual inputs. There is a reason the hash does not include the inputs. In order to lock an output to a 32 byte hash with CTV, you need to know the hash of the transaction that you are ensuring is the only way for it to be spent. The input locked with CTV being spent will have to include this hash in order to be verified against CTV. That necessitates having the hash of that transaction before you create the complete transaction. That is not possible.
You can also nest CTV scripts, i.e. have an initial CTV script commit to a transaction with outputs that also include CTV scripts. This is what allows CTV to “carry forward” data. All it carries forward in practice though is whatever data is contained in the chain of transactions. You can do this in theory to an infinite depth, but you are limited in practice to a finite depth because the nesting must be generated backwards starting from the end. This is because each level, or “hop,” must have the hash of the transaction moving to the next one, otherwise you can’t create the locking script in the first place. If you don’t already know the next transaction, you can’t generate the previous one.
CTV allows you to restrict an output so that it can only be spent, according to consensus rules, by an exact pre-defined transaction. Some of you might be asking what the big deal is, we can already pre-sign transactions. If the level of introspection is so limited that it can only accomplish something we can already do just pre-signing, what is the value add?
First, pre-signed transactions always leave open the possibility of the keyholder(s) signing new transactions and spending those coins in a different way. You have to trust that the keyholder will not do this, or will delete the key needed to sign with (which you also have to trust them on). CTV removes that trust entirely. Once the spending transaction is defined and the output locked to that CTV hash is created, there is no possibility of being spent another way, enforced by consensus.
Currently the only way around that trust is to be involved in pre-signing transactions yourself using multisig. Then you can be completely certain that unless you choose to sign one yourself, no other valid transaction spending a coin in a different way can be created. The problem is the more people are involved, the more difficult and unreliable coordinating everyone to pre-sign a transaction at the same time becomes. Past small sizes it becomes a totally impractical problem to solve reliably.
CTV gives a way for people to know a set of transactions is committed without everyone having to get online at the same time to sign them. It greatly simplifies the coordination process by allowing everyone to get the needed information to anyone else whenever they can, and once that person has everyone’s information they can create the chain of CTV transactions without anyone else’s involvement, and everyone can verify and be certain that the correct outcome is the only possible one.
That is incredibly valuable on its own, but CTV can also enable even more valuable things in combination with other opcodes, which we’ll see in the next article.
CTV is a tightly restricted covenant that enables a degree of introspection and forward data carrying that is so limited it does not exceed the actual functionality of anything that can be done with pre-signed transactions. The value proposition is not in enabling new functionality in its own right, but drastically improving the efficiency, scalability, and security guarantees of what can be built currently using pre-signed transactions. This alone is a massive benefit to almost every currently deployed protocol using pre-signed transactions.
Here are some of the projects demonstrating how thoroughly fleshed out and explored this particular covenant is compared to the others:
CTV is an incredibly mature proposal at this point, with a high value add, and no risk of enabling anything driving the concerns around covenants. This should not only be very seriously considered, but in my personal opinion should have been activated years ago.
This post Bitcoin Covenants: CHECKTEMPLATEVERIFY (BIP 119) first appeared on Bitcoin Magazine and is written by Shinobi.
Full story here:
Bitcoin Covenants: CHECKTEMPLATEVERIFY (BIP 119)
The is the first article deep diving into individual covenant proposals that have reached a point of maturity meriting an in depth breakdown.
CHECKTEMPLATEVERIFY (CTV), put forward by Jeremy Rubin with BIP 119, is the most mature and fully fleshed out covenant proposal, not only out of the proposals we will be covering, but out of all of the covenant proposals in their entirety. As I mentioned in the introduction article to this series, there are many concerns in the ecosystem regarding covenants that are too flexible enabling things that wind up having very detrimental consequences for Bitcoin.
CTV was designed specifically to constrain its capabilities tightly enough to avoid any of those concerns. To first understand how CTV functions, we need to understand the individual parts of a Bitcoin transaction.
This is a very high level view of a Bitcoin transaction. It has inputs, or unspent coins (UTXOs), and outputs, the new unspent coins that the transaction will create when it is confirmed in a block. There are a lot more pieces we will go through, but this is the highest level view of a transaction’s structure.
Every transaction also has a version number field for the whole transaction, indicating applicability of new versions of rules or features. There is also the marker and the flag, which are set to specific values to indicate the transaction uses Segwit. After this is the input count, the number of inputs in the transaction. Then come the actual inputs.
Each input contains a TXID of the transaction that created the unspent coin being spent, a VOUT which marks what output in that transaction is being spent, the size of the ScriptSig, and the ScriptSig, which is the unlocking script proving the input being spent is authorized by its locking script rules, and finally a Sequence number which is used to ensure the input being spent is following relative timelock rules. i.e. the input has existed for a certain number of blocks or length of time since its creation.
The output count is the next piece of data, the number of outputs in the transaction. After this comes the actual outputs, which contain an amount of satoshis assigned to that output, the ScriptPubKey size, and the actual ScriptPubKey, which is the locking script for that output. Lastly the nLocktime field applies a timelock value in timestamp or block height that applies to the entire transaction.
Each Segwit transaction also contains a Witness section, where each input has a corresponding witness containing a Stack Items count, how many things will be put on the script stack, a Size field for each item, and the actual data Item to go on the stack.
How CTV Works
CTV is an opcode that enables the most basic form of introspection and forward data carrying out of all the covenant proposals. It allows a script to take a pre-defined 32 byte hash and compare that against a hash of most of the fields of the spending transaction. If the hash derived from the actual spending transaction does not match the pre-defined hash, the transaction is 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 place the input has in the transaction, 1st input, 2nd, etc.)
These are all the fields committed to by the CTV hash, in their entirety, and with no ability to pick and choose. This is the degree of introspection CTV enables, “does the hash of these fields in the spending transaction match the hash in the locking script of the input being spent,” that’s it. The hash commits to essentially the entire transaction except the actual inputs. There is a reason the hash does not include the inputs. In order to lock an output to a 32 byte hash with CTV, you need to know the hash of the transaction that you are ensuring is the only way for it to be spent. The input locked with CTV being spent will have to include this hash in order to be verified against CTV. That necessitates having the hash of that transaction before you create the complete transaction. That is not possible.
You can also nest CTV scripts, i.e. have an initial CTV script commit to a transaction with outputs that also include CTV scripts. This is what allows CTV to “carry forward” data. All it carries forward in practice though is whatever data is contained in the chain of transactions. You can do this in theory to an infinite depth, but you are limited in practice to a finite depth because the nesting must be generated backwards starting from the end. This is because each level, or “hop,” must have the hash of the transaction moving to the next one, otherwise you can’t create the locking script in the first place. If you don’t already know the next transaction, you can’t generate the previous one.
What Is CTV Useful For
CTV allows you to restrict an output so that it can only be spent, according to consensus rules, by an exact pre-defined transaction. Some of you might be asking what the big deal is, we can already pre-sign transactions. If the level of introspection is so limited that it can only accomplish something we can already do just pre-signing, what is the value add?
First, pre-signed transactions always leave open the possibility of the keyholder(s) signing new transactions and spending those coins in a different way. You have to trust that the keyholder will not do this, or will delete the key needed to sign with (which you also have to trust them on). CTV removes that trust entirely. Once the spending transaction is defined and the output locked to that CTV hash is created, there is no possibility of being spent another way, enforced by consensus.
Currently the only way around that trust is to be involved in pre-signing transactions yourself using multisig. Then you can be completely certain that unless you choose to sign one yourself, no other valid transaction spending a coin in a different way can be created. The problem is the more people are involved, the more difficult and unreliable coordinating everyone to pre-sign a transaction at the same time becomes. Past small sizes it becomes a totally impractical problem to solve reliably.
CTV gives a way for people to know a set of transactions is committed without everyone having to get online at the same time to sign them. It greatly simplifies the coordination process by allowing everyone to get the needed information to anyone else whenever they can, and once that person has everyone’s information they can create the chain of CTV transactions without anyone else’s involvement, and everyone can verify and be certain that the correct outcome is the only possible one.
That is incredibly valuable on its own, but CTV can also enable even more valuable things in combination with other opcodes, which we’ll see in the next article.
Closing Thoughts
CTV is a tightly restricted covenant that enables a degree of introspection and forward data carrying that is so limited it does not exceed the actual functionality of anything that can be done with pre-signed transactions. The value proposition is not in enabling new functionality in its own right, but drastically improving the efficiency, scalability, and security guarantees of what can be built currently using pre-signed transactions. This alone is a massive benefit to almost every currently deployed protocol using pre-signed transactions.
Here are some of the projects demonstrating how thoroughly fleshed out and explored this particular covenant is compared to the others:
- A basic payment pool example by stutxo.
- A CTV vault implementation by James O’Beirne, who went on to propose OP_VAULT (which still makes use of CTV).
- A proof-of-concept port of the pre-signed transaction based Ark implementation from Second by Steven Roose to use CTV instead.
- The Sapio Language by Jeremy Rubin himself, a higher level language for building contracts with CTV (also supporting the use of pre-signed transactions instead).
- Timeout Trees, a proposal for a very basic coinpool design by John Law.
- Numerous other possible protocols, such as optimized Discreet Log Contracts (DLCs), non-interactive Lightning channels one party could open without the other, and even decentralized ways for miners to pool together.
CTV is an incredibly mature proposal at this point, with a high value add, and no risk of enabling anything driving the concerns around covenants. This should not only be very seriously considered, but in my personal opinion should have been activated years ago.
This post Bitcoin Covenants: CHECKTEMPLATEVERIFY (BIP 119) first appeared on Bitcoin Magazine and is written by Shinobi.
Full story here:
![[DK]](/data/avatars/s/57/57999.jpg?1720990206){kind=avatar}
