Bitcoin Covenants: CheckTemplateVerify (BIP 119)

This is the first in a series that delves deep into individual contract proposals that have reached maturity worthy of depth failure.

Jeremy Rubin’s proposal for CheckTemplateVerify (CTV) with BIP 119 is the most mature and fully fleshed out contract proposal, not just from the proposals we cover, but from the whole of all contract proposals. As mentioned in the introductory article in this series, the ecosystem has many concerns about contracts that are too flexible that allow for extremely detrimental results for Bitcoin.

CTV was specifically designed to constrain its functionality sufficiently to avoid those concerns. First, to understand how CTV works, you need to understand the individual parts of a Bitcoin transaction.

This is a very high level view of Bitcoin transactions. There are new unheaded coins that the transaction creates when it is verified in blocks. There are many works that we pass through, and this is the highest level view of the structure of a transaction.

All transactions also have a transaction-wide version number field, indicating the applicability of a new version of a rule or feature. It also has markers and flags, set to a specific value indicating that the transaction uses SEGWIT. After this, the number of inputs and the number of transaction inputs. Next, the actual input comes.

Each input contains the TXID of the transaction that created the unused coin, what the output of that transaction is being used, the size of the Scriptsig, and a Vout that marks the sequence number where the unlock script script rules grant the script that will be approved by the lock script rules and the sequence number that will be used successfully. That is, the input has been around for a certain number of blocks or lengths since its creation.

Output count is the number of outputs for the following data, transactions: After this, we’ll see the actual output, including the amount of atshis allocated to that output, the ScriptPubkey size, and the actual ScriptPubkey, which is the lock script for that output. Finally, the Nlocktime field applies the time-lock value of the timestamp or block height that is applied to the entire transaction.

Each Segwit transaction also includes a witness section that contains the corresponding witness, which contains the count of stack items in each input, what is in the script stack, the size field for each item, and the actual data items to move into the stack.

How CTV works

CTV is an opcode that allows for the most basic form of introspection and transfer data carried out from all contract proposals. This allows the script to get a predefined 32-byte hash and compare it with the hash of most fields in the expenditure transaction. If the hash derived from the actual expenditure transaction does not match the predefined hash, the transaction is invalid.

The fields it commits are:

• nversion
• nlocktime
• Number of inputs
• Hashing of all n-sequence fields
• Output count
• Hashing of all outputs
• Input index (where the input is in a transaction, first input, second etc.)

These are all fields committed by the CTV hash, and the whole is not entirely capable of selecting and selecting. This is the degree to which introspection CTV is enabled. “Does the hash of these fields in the expenditure transaction match the hash of the lock script of the input being used?” A hash essentially commits the entire transaction, except for the actual input. There is a reason the hash does not contain input. To lock the output to a 32-byte hash using CTV, you need to know the hash of the transaction, the only way it is used. Inputs locked using CTV must include this hash to validate against CTV. That requires a hash of that transaction in front Create a complete transaction. That’s not possible.

You can also nest CTV scripts. This means that you can also commit the first CTV script to a transaction using output that also includes the CTV script. This allows CTV to “move” the data. In reality, anything data is contained in the transaction chain. This can theoretically be done to infinite depths, but in practice it is limited to a finite depth, as nesting must be generated in the last direction. This is because each level, or “hop”, requires that the hash of the transaction be moved to the next level. Otherwise, you will not be able to create a lock script first. If you don’t know the next transaction yet, you cannot generate the previous transaction.

What is CTV?

With CTV, you limit the output so that it can only be used by accurate, predefined transactions according to consensus rules. Some of you may be asking what a big deal is, but we can already pre-sign the transaction. If the level of introspection is so limited that you can only achieve what you can do by signing, what is the value?

First, pre-signed transactions always keep open the possibility of signing new transactions and spending those coins differently. You need to trust that the keychain doesn’t do this or trust that it removes the keys needed to sign (this should also be trusted). CTV removes that trust entirely. Once an expenditure transaction is defined and output is created in its CTV hash, there is no chance that it will be spent in another way implemented by consensus.

Currently, the only way to avoid that trust is to engage in a signature transaction yourself using Multisig. Secondly, unless you choose to sign it yourself, you can be completely certain that you cannot create other valid transactions that use the coin in a different way. The problem is that the more people are involved, the more difficult and unreliable, the more coordinated everyone and pre-signing transactions at the same time. The small sizes of the past become completely impractical to ensure that they are resolved.

CTV provides a way for people to know that a series of transactions are committed without everyone coming online for them to sign. By making the necessary information available to everyone as much as possible, it greatly simplifies the adjustment process. Also, having that person’s information allows you to create a chain of CTV transactions without the involvement of others.

It’s very valuable, but CTV can also be combined with other opcodes to allow for something even more valuable.

Close thoughts

CTV is a strictly limited contract that allows for some degree of introspection and forward-looking data transport, and is limited to the extent that it does not exceed the actual functionality that can be performed in pre-signed transactions. Rather than enabling new features on its own, value propositions significantly improve the efficiency, scalability, and security assurance of what can now be built using pre-signed transactions. This alone is a great advantage for almost any protocol currently being deployed, using pre-signed transactions.

Here we present some of the projects we have thoroughly implemented the comparison of this particular agreement with other agreements and investigated.

• Example of a basic payment pool with Stutxo.
• Implementation of CTV Vault by James O’Beirne proposed OP_VAULT (still using CTV).
• The proof-of-concept port for a pre-signed transaction-based ARK implementation from the second by Steven Roose uses CTV instead.
• Jeremy Rubin’s own Sapio language is a higher level language for building contracts with CTV (also supports the use of pre-signed transactions instead).
• A very basic coin pool design proposal by Timeout Tree, John Law.
• There are many other protocols, such as optimized, discreet logging agreements (DLCs), non-interactive lightning channels that one party can open without the other, and even decentralized ways for miners to pool together.

CTV is a very mature proposal at this point, with high value and no risk of enabling anything that encourages contract concerns. This should not only be considered very seriously, but in my personal opinion it should have been revitalized many years ago.