BIP 119: Bitcoin Covenants – Check template verification

It is the very first time that an article has been written to examine in detail individual proposals for covenants. 

CHECKTEMPLATEVERIFY (CTV), proposed by Jeremy Rubin in BIP 119 and the largest of all covenant proposals, has the highest level of maturity. In the first article of this series I discussed the concerns that exist in the Bitcoin ecosystem about covenants which are overly flexible and allow for things to happen that have very negative consequences. 

CTV’s capabilities were designed to be restricted to a degree that would avoid these concerns. In order to first understand CTV, it is important that we understand each part of the Bitcoin transaction. 

It is the high-level view of Bitcoin. The inputs are unspent or uncommitted coins.UTXOsThe outputs of a transaction are new coins which will be created when the block confirms the transaction. This is just the top-level structure of a transaction. There will be many other pieces that we’ll go over. 

A version number is also included in every transaction to indicate the applicability for new rules and features. The marker and flag are also set with specific values that indicate Segwit usage. The input count is then displayed, which shows the total number of inputs. After this, the actual inputs are listed. 

Each input has a unique TXID that identifies the transaction that generated the unspent coins being used, as well as a VOUT that indicates the specific output being used, along with the size and ScriptSig. This is the script that unlocks and verifies that the input spent was authorized according to its locking script. i.e. It is possible that the input exists for some time or has been in existence since it was created. 

Next, we have the actual outputs. These contain the amount of satoshis assigned to each output as well as the ScriptPubKey size and the ScriptPubKey itself. Next, we have the actual outputs. This contains the amount of satoshis that is assigned to the particular output. We also include the ScriptPubKey’s size and the ScriptPubKey itself, which represents the script that locks that specific output. The nLocktime value is a timestamp, block height or ScriptPubKey that will apply to the whole transaction. 

Segwit also has a Witness Section, which contains a Stack Items Count, the Number of Items that will go onto the Script Stack, a Size Field for each Item, as well as the Data Item. 

CTV: How it Works

CTV is a code that allows the most fundamental form of data forwarding and introspection of covenant proposals. The script can compare a 32-byte predefined hash to a hash made up of many fields in the actual spending transaction. The transaction will be invalid if the hash of the spending transaction doesn’t match the predefined hash. 

These are the fields that it is committed to:

• Version n
• Locktime
• Input count
• The nSequences fields have been hacked
• Count the output
• All the outputs mashed up
• The input index is the position of the input in the transaction (e.g., the first input, the second, etc.).

CTV’s hash is committed to all of these fields, without any option to choose. CTV offers a high level of insight. “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. Hashing commits you to almost the whole transaction, except for inputs. It is for this reason that the inputs are not included in the hash. You need to have the 32-byte hash for the transaction you want to ensure is only the way it can be spent in order to lock the output. This hash will be required to verify the input that was locked using CTV. The hash must be included in the transaction. Then, You create the entire transaction. It isn’t possible. 

CTV scripts may also be nested, that is. Have an initial CTV commit to a transtion with outputs which also include CTVscripts. CTV can only do this by committing an initial CTV script to a transaction with outputs that also include CTV scripts. “carry forward” data. In practice, it only carries the data contained within the transaction chain. The nesting can be created in reverse starting at the bottom. This is the only way to achieve an infinite number of levels. It is possible because every level, or “hop,” You must know the hash value of the previous transaction before you create the lock script. You can only generate the previous transaction if you know what the next one is. 

CTV: What is it good for?

CTV allows for the restriction of an output, so it can be only spent according to consensus rules by a predefined exact transaction. You might ask what’s the big deal, since we already pre-sign our transactions. What is the added value if the introspection can accomplish only pre-signing? 

The first thing to note is that pre-signed transaction always leaves the option open for the keyholder to sign new transactions or spend those coins a completely different way. It is up to you to be sure that they will either not delete their key or sign with another key. CTV eliminates this trust completely. CTV removes that trust completely. 

Multisig is the only method to circumvent this trust. If you pre-sign a transaction yourself, you will be able to be certain that other transactions spending coins in different ways cannot be generated unless it is signed by you. It is difficult to coordinate everyone signing a transaction simultaneously, and it becomes unreliable the larger the group. Once the problem grows beyond small size, it is impossible to resolve reliably. 

CTV lets people know that transactions have been committed, without having to all sign on at once. This greatly simplifies coordination by allowing people to share information with each other whenever they are able. 

CTV is extremely valuable by itself, but it can be even more useful when combined with other Opcodes. We’ll explore this in our next article. 

Closed Thoughts

CTV, or a covenant with tight restrictions on it, allows a limited amount of data transmission and introspection that does not go beyond the functionality that pre-signed transaction can provide. It isn’t about enabling new features, but rather improving efficiency, security, and scalability of existing pre-signed transaction applications. The benefits of this alone are huge for almost all protocols that use pre-signed transactions.

These projects show how well-developed and thoroughly explored the covenant in question is when compared with the other ones:

• The basic Payment Pool example By: stutxo. 
• CTV – A CTV Vault implementation By: James O’BeirneOP_VAULT was proposed by the same person (which uses CTV) 
• This is a proof of concept port from Second’s Ark implementation, which uses pre-signed transactions.
• You can also find out more about the following: Sapio Language By: Jeremy Rubin He uses a more advanced language to build contracts with CTV. 
• Timeout TreesJohn Law has proposed a design for a basic coinpool.
• Many other possible protocolsDiscreet Log Contracts are optimized, Lightning channels can be opened by one party without involving the other and decentralized pooling is possible. 

CTV has a lot of maturity at this stage, it adds a great deal to the market and there is no danger that anything will be enabled which would cause covenant concerns. I think this should be seriously considered and implemented years ago.