NEWSLETTER
This is the first article of a deep series in the individual pact proposals that have reached a maturity point that deserves a depth breakdown.
<a target="_blank" href="https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki” target=”_blank” rel=”noopener”>Check (CTV), presented by Jeremy Rubin with BIP 119, is the proposal of the most mature and fully developed pact, not only out of the proposals we will cover, but of all the proposals of pact as a whole. As I mentioned in the introduction article to this series, there are many concerns in the ecosystem regarding the agreements that are too flexible allowing things that end up having very harmful consequences for bitcoin.
CTV was specifically designed to restrict its abilities closely enough to avoid any of those concerns. To first understand how CTV works, we need to understand the individual parts of a bitcoin transaction.
This is a very high level view of a bitcoin transaction. It has non -spent entries, or coins (utxos) and exits, the new unbelievable coins that the transaction will create when confirmed in a block. There are many more pieces that we will pass through, but this is the highest level view of the structure of a transaction.
Each transaction also has a version number field for the entire transaction, which indicates applicability of new versions of rules or characteristics. There is also the marker and the indicator, which are established in specific values to indicate that the use use secwit. After this is the entrances count, the number of entries in the transaction. Then come the real entrances.
Each entry contains a TXID of the transaction that created the unbounded currency that is spent, a vout that marks what exit in that transaction is being spent, the size of the scriptsig and the scriptsig, which is the unlock script that proves the entry that is spent is authorized by its location script rules, and finally a sequence number that is used to guarantee that the entry is made after the entry TEMPORARY TIME RULES. That is, the entrance has existed for a certain number of blocks or duration 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 real outputs, which contain a number of satoshis assigned to that output, the scriptpubkey size and the real scriptpubkey, which is the blocking script for that output. Finally, the Nlocktime field applies a time of time value in the time or height brand of the block that is applied to the entire transaction.
Each secwit transaction also contains a section of witnesses, where each entry has a corresponding witness that contains a pile elements, how many things will be placed in the script pile, a size field for each element and the real data element to go to the battery.
How CTV works
CTV is an operation code that allows the most basic form of introspection and forward data that all proposals of the pact make. Allow a script to take a 32 -bytes hash predefined and compare that with a hash of most fields of spending transaction. If the hash derived from the real spending transaction does not coincide with the predefined hash, the transaction is not valid.
The fields to which he is committed are:
- chestnut
- nlocktime
- Input count
- A hash of all the fields of Nequence
- Departure count
- A hash of all outputs
- Input index (the place that has the entry into the transaction, first entry, 2nd, etc.)
These are all the fields committed by the hash CTV, in its entirety and without the capacity to choose and choose. This is the degree of introspection that CTV allows: “Does the hash of these fields in the transaction of expenses coincide with the hash in the blocking script of the entry that is spent”, that is all. The hash is essentially committed to the entire transaction, except the real entrances. There is a reason why the hash does not include tickets. To block an output to a 32 -Bytes Hash with CTV, you must know the transaction hash that is ensuring that it is the only way to spend. The entry blocked with CTV spent will have to include this hash to be verified against CTV. Which requires having the hash of that transaction before You create the complete transaction. That is not possible.
You can also nest CTV scripts, that is, have an initial script CTV commission with a transaction with outputs that also include CTV scripts. This is what allows CTV to “carry out.” However, everything that carries out in practice is any data contained in the transaction chain. You can do this in theory with an infinite depth, but it is limited in practice to a finite depth because nesting must be generated back from the end. This is because each level, or “jump” must make the transaction hash move the next; Otherwise, you cannot create the blocking script first. If you still don't know the next transaction, you can't generate the previous one.
What is CTV useful?
CTV allows you to restrict an exit so that it can only be spent, according to the consensus rules, by means of an exact predefined transaction. Some of you could ask what the big problem is, we can already sign transactions. If the level of introspection is so limited that it can only achieve something that we can only sign, what is the added value?
First, previous transactions signed always leave open the possibility that key holders sign new transactions and spend those coins in a different way. You must trust that the head of the key will not do this, or eliminate the necessary key to sign (which you also have to trust them). CTV eliminates that confidence completely. Once the spending transaction is defined and the output blocked to that hash CTV is created, there is no possibility of being spent otherwise, applied by consensus.
Currently, the only way to avoid this trust is to participate in transactions prior to the firm yourself using Multisig. Then you can be completely sure that, unless you choose to sign one yourself, you cannot create another valid transaction that spends a currency differently. The problem is that the more people get involved, the more difficult and unreliable coordinate everyone to sign a transaction at the same time. Past small sizes becomes a totally unchanging problem to solve reliably.
CTV offers a way that people know that a set of transactions is committed without everyone having to connect at the same time to sign them. It greatly simplifies the coordination process by allowing everyone to obtain the necessary information from any other person as long as they can, and once that person has everyone's information, you can create the CTV transactions chain without anyone's participation, and everyone can verify and be sure that the correct result is the only one possible.
That is incredibly valuable on its own, but CTV can also allow even more valuable things in combination with other operating codes, which we will see in the next article.
Closing thoughts
The CTV is a very restricted pact that allows a degree of introspection and progress data that is so limited that it does not exceed the real functionality of anything that can be done with previous transactions signed. The value proposal is not to enable a new functionality in its own right, but drastically improve efficiency, scalability and security guarantees of what can be built currently using previous transactions to the firm. This is only a massive benefit for almost all protocol currently implemented using transactions prior to the firm.
These are some of the projects that demonstrate how fully developed and explored this particular pact with others is compared:
- A basic payment group example by <a target="_blank" href="https://x.com/stutxo” target=”_blank”>stutter.
- A CTV vault implementation by <a target="_blank" href="https://x.com/jamesob” target=”_blank”>James O'Beirnewho went on to propose Op_Vault (which still makes use of CTV).
- Instead, a Test port of the ARK implementation based on transactions previously signed since the second by Steven Roose to use CTV.
- He SAPE LANGUAGE by <a target="_blank" href="https://x.com/JeremyRubin” target=”_blank”>Jeremy Rubin Himself, a higher level language to build contracts with CTV (also supports the use of transactions prior to signed).
- Waiting time, a proposal for a very basic coinpool design by John Law.
- Numerous others Possible protocolsAs optimized discrete registration contracts (DLC), non -interactive ray channels that one part could open without the other, and even decentralized forms for miners to join.
CTV is an incredibly mature proposal at this point, with a high added value and without risk of allowing anything to drive concerns about agreements. This should not only be considered very seriously, but in my personal opinion it should have been activated years ago.
