What is CLTV in Bitcoin?

CLTV or CheckLockTimeVerify is an interesting time block functionality that exists in Bitcoin designed to allow your scripts to perform advanced temporary schedules on your transactions. A function that allows you to program advanced scripts tailored to the increasing demand for functions within Bitcoin.

Lupon arrival of Bitcoin, together with innovative technology Blockchain, has opened a world of possibilities; including programmable money. Yes, as you hear, programmable money. Bitcoin integrates many functions, and one of those functions is known as Check Lock Time Verify (CLTV), which makes it possible for unspent outputs (UTXO) Bitcoin are blocked and cannot be spent until a predetermined moment has arrived.

The function CLTV was integrated into Bitcoin Core through the soft fork BIP-0065, in which its developer Peter Todd describes the new opcode (OP_CODE) OP_CHECKLOCKTIMEVERIFY. This feature allows a transaction made in Bitcoin to remain blocked over time and not be effective until a certain block date, time or height is reached.

Thus, the CLTV function is very useful and positive for various use cases within the Bitcoin system. For example, for the long-term savings of funds destined for the payment of the university or graduation of a relative. It is also possible to schedule future payments for specific dates, such as rentals, services, medical appointments, or even a smart inheritance among others.

Likewise, this function is especially important for opening new payment alternatives. For example creating CLTV-style pay channels. These payment channels They allow transactions outside the blockchain while maintaining all the security and benefits of a conventional transaction that occurred within the chain. In addition, the CLTV function also allows the establishment of other alternatives such as time-limited repayments or trusts. The applications and use cases that this function has are really endless.

How does CLTV work?

When a user establishes and performs a transaction with the code OP_CHECKLOCKTIMEVERIFY, the outputs of said transaction will be activated only at the moment the established condition is fulfilled, and not at the moment the transaction is made. Which means that the transaction is successful but the cryptocurrencies will remain blocked in time until a future moment.

The code OP_CHECKLOCKTIMEVERIFY is executed as part of a Bitcoin script, and its programming is based on the use of the UNIX times (Unix Timestamp) or at the block heights within the blockchain. That is, it is necessary to establish a condition in any of these parameters to make a comparison with the current time. So he OP_CHECKLOCKTIMEVERIFY check the top element of the stack with time lock (nLockTime) that was established in the transaction. If by doing this comparison it is verified that the condition has been met, the script can be executed, otherwise the script will fail.

The conditions for the script to fail in a CLTV transaction are as follows:

1. That the stack is empty and there is no defined time for the code to perform the comparison and verification.
2. That, as already mentioned, the upper element of the stack is less than the condition established for unlocking the unspent outputs. This indicates that the time required to unlock the transaction has not elapsed.
3. Another failure condition will occur if the set time lock is measured in block height and the top element of the stack uses time measurements (in seconds) or vice versa.
4. Field nSequence This entry is set to 0xFFFFFFFF.

Then, A CLTV transaction can only be included within the blockchain once the established time or condition has expired. Once this happens, CLTV transactions are immediately verified and added to the blockchain, and are considered as spent.

CLTV and nLockTime relationship

Both CLTV and nLockTime They are two functions that allow Bitcoin to program actions that depend on the time or height of the block for its correct execution. But the relationship and scope of both goes much further. On the one hand, nLockTime ensures that Bitcoin can schedule transactions to be executed at a certain block height (block time block) or by timestamp or timestamp (specific time block). With this Bitcoin enables the ability to schedule payments using these parameters.

But on the other hand, CLTV allows you to add an additional verification and programming layer to nLockTime. This is because CLTV takes the nLockTime and verifies that an aggregate set of conditions scheduled for its activation are in place, a situation that was much more straightforward with the original nLockTime. CLTV even allows altering certain original conditions of the transaction if certain conditions are met.

For example, a multi-signature address 2 of 3, which has not been mobilized in a certain period of time, can change its authentication parameters to 1 of 3, so that some of the initially authorized persons can mobilize the funds that are there contents. This is unique functionality that CLTV can offer and nLockTime alone cannot.

CLTV implementation

One of the biggest and most important potentials of the CLTV function is to allow the creation of payment channels and that these can be implemented correctly. Through the payment channels, micro-transactions can be created outside the blockchain. All without having to pay so many commission fees for each one and without collapsing the blockchain.

In payment channels, a user can carry out a transaction to another by depositing a certain amount of cryptocurrencies in a multi-signature address (MultiSig). Both users will have access to that address. And the user who carries out the transaction can sign small transactions that will be made to the other user from those funds. This until you get the desired product. The remaining funds will be returned to you in a return transaction for each micro-transaction you make. While the merchant will be able to claim the final accumulated payment, which will have been made without collapsing the blockchain and for which Maria paid only a commission fee.

Example of how CLTV works

If Maria wants to see a video, but she must pay 1 sat per second viewed. Maria does not want to carry out these 1 sat per second transactions through a conventional Bitcoin transaction. Since for this you must pay the commission fee for each transaction you make. In addition, you must wait for said transaction to be confirmed in a block; what happens every 10 min in Bitcoin.

Seeing that it is not convenient, María decides to create a payment channel. In this channel, it will make a deposit in a multi-signature address of 0.5 BTC, which is equivalent to 50.000.000 satoshis. Both the merchant and Maria will have access to the multi-signature address. So when Maria starts viewing the video, she will sign a transaction where she will send 1 sat to the merchant for the first second displayed. And 49.999.999 sats to a change address for your membership.

This process will be repeated several times as long as Maria continues to watch the video. That is to say, she will continue signing micro-transactions and paying the amount of satoshis equivalent to the seconds that she visualizes of the video, and depositing her laps in a return address. If Maria only viewed 2 seconds of video, then she will sign a new transaction, but this time 2 sat for the merchant and 49.999.998 sat for her return address. If you viewed only 3 seconds, you will sign another transaction, but this time 3 sat for the merchant and 49.999.997 sat for your return address.

During this process, the merchant will not claim or sign the 1 sat or 2 sat transactions received. Rather, he will wait for Maria to view everything she wants from the video and claim the final payment. That is, the largest transaction. The rest of the transactions made at the beginning will not be signed since it would imply a double expense. So the merchant must choose the largest transaction that contains all the received satoshis, in this example the 3 satoshis transaction.

In addition, in the end, the merchant signs only one transaction, this is the one that will be added to the blockchain and will be the only one for which the commission fee corresponding to the miners must be canceled. Furthermore, Maria can implement a CLTV transaction at the beginning to guarantee the returnability of your funds deposited in the multi-signature address. If you set a certain time for both to sign the transaction, and for whatever reason, one or neither of you can sign it before that time. So Maria can get her money back. Because if the transaction is not signed before the established condition, Maria can sign the transaction and have her money back after the established time has elapsed.

So in summary, the code OP_CHECKLOCKTIMEVERIFY offers a positive advantage for the implementation of smart contracts. This guarantees the integrity of the funds until they have reached the established block height or time mark. While avoiding system failure due to transaction malleability.