Waiting for Bitcoin transactions – OP code proposed by Jeremy Rubin

I said in the last article that OP_CHECKTEMPLATEVERIFY is a new OP code proposed by Jeremy Rubin whose main advantage is to reduce the fees paid to the miners and to maintain the network’s operation when many pending Bitcoin transactions occur.

In other words, CTV could allow a Bitcoin transaction to be divided into two parts. The first part of the transaction, “to send”, would contain all the inputs (in principle the addresses that have the positive balance from which “they are sent”). The second part of the transaction, “receivable”, will contain the outputs (addresses where the coins will be “sent”).

These two parts of a transaction will be linked to a special output that will be included in the “send” transaction. The output is called “committed output” (COUT). COUT would contain crypto-deterrent hash: an apparently random number, relatively short, which has the role of serial number in a transaction and links the two parts. The currencies that are “sent” in the transaction to be sent can only be received by the addresses defined in the transaction to be received.

The secret, in fact, is that both halves of the transaction are sent to the network with a major difference.

The “send” transaction is propagated with a high enough charge to be confirmed quickly while the “receivable” transaction is propagated with a low charge (it will take confirmation). The fact that the one waiting for the receipt of the coins is waiting for the confirmation of the transaction “to be received” should not be a very big problem because the transaction “to be sent” is already written and confirmed in the register, so the coins can only be received by the addresses in the transaction ” to recieve”.

There will be no pending Bitcoin transactions

However, if the recipient of the coins wishes to send them to another address, he can do so directly from the second part of the transaction, (before being confirmed). If the fees for the new transaction are high enough, it can be confirmed with the initial one (the procedure is called “Child pays for Parent” “Child pays for Parent”). Even more than that, CTV also allows for more efficient solutions, allowing “receivable” trading parties to be divided into smaller transactions (Tree Payments).

The main objection to CTV is that there are several simpler ways to achieve the same thing. The general solution is even “Covenants” as well as the fact that Noinput class or OP_cat would have the same benefits. You will find more on this topic in the last article.

To read more about OP_CHECKTEMPLATEVERIFY we invite you to study Aaron van Wirdum’s article, in which all the terms mentioned in the current article are explained in detail.

One of the latest “upgrades” we will discuss is Drivechain BIPs. In principle, these are protocols that run alongside the general Bitcoin protocol (Sidechains) but are closely linked to it. These new types of protocols allow real Bitcoin currencies to “teleport” on them and back into the general protocol.