The CheckSequenceVerify opcode is an interesting Bitcoin functionality that opens the doors to advanced scripts that allow us to make secure payments controlled by programmable time values.
Una of the most useful functions it has Bitcoin scriptAre the time locks or TimeLockand opcode (OP_CODE) CheckSequenceVerify (CSV). Which together with other lock codes make it possible for Bitcoin can be used as a programmable digital money.
El CheckSequenceVerify is a relative time lock that operates at the script level. This allows us to define the exact moment in which a block on a given transaction will end. And although this is a characteristic that was part of the soft fork of the 68 BIPit wasn't until 112 BIP where it was truly added to the Bitcoin system.
The utility CheckSequenceVerify enables advanced functionality for building systems such as payment channels de Lightning Network (LN). In addition, it opens the doors to the creation of advanced functionalities for the management of funds in a decentralized way, useful for Decentralized exchanges (DEX) or exchange services P2P insurance.
Likewise, although the way of operating of CheckSequenceVerify (CSV) is quite similar to that of CheckLockTimeVerify (CLTV)In CSV, the upper stack is checked with the input field, instead of checking the time, as is the case with CLTV. Thus we can calculate the time based on the number of blocks that have been generated after the transaction has been confirmed. That is, relative time locks like CheckSequenceVerify can mark a transaction as invalid. And for this, they monitor that the established time interval has elapsed since the previous exits of the transaction were confirmed.
In simpler words, relative time locks allow us to define exactly the amount of time to elapse before a transaction can be confirmed. Unlike absolute time locks that define the exact moment (block number, or date and time) at which the block on the transaction will end.
How does CheckSequenceVerify (CSV) work?
Script-level time locks like CheckSequenceVerify (CSV) operate in conjunction with transaction level locksTherefore, the latter are important when applying a CSV lock. This is because in CSV locks the scripts check the transaction lock. To do this, they verify that said transaction is blocked and use these locks on the transactions as a guarantee of age that indicates that the established time has elapsed.
In the 112 BIP Bitcoin, CheckSequenceVerify is described as an opcode that gives a new definition to the already existing OP_NOP3 command. This update enables you to block a transaction at the script level based on the age or age of the output being spent. This functionality is executed in conjunction with BIP 68. In this way, you can also prevent a transaction from being included within a block. This until the established time or age has elapsed.
When checking CSV lock with value nSequence established, it is verified if the minimum age of the output being spent has already been met. If not already fulfilled, the script execution paths that include the CSV lock can be validated. Thus, the transaction cannot be included in a block until the condition is met.
Thus, when the CSV opcode is called, it causes the script to fail unless the sequence number in the transaction indicates that a time interval has already elapsed in the relative time lock, which is greater than or equal to the CSV opcode indicator. Thus guaranteeing that the transaction can only be included in a valid block once the blocking time has been met or expired.
When this opcode is implemented, CheckSequenceVerify allows you to set locks on transactions with a maximum of up to 65.535 blocks. But you can also set such a lock to a maximum up to 65.535 * 512 seconds. On the other hand, these locks are very useful when establishing relative time locks on transactions that have not been confirmed or transmitted to the network. Since CSV allows the creation of intelligent transactions defining and establishing all the instructions that are necessary for their execution in advance. Thus we have the guarantee and security that said contract or transaction will only occur under the established order. All this regardless of when it begins to run.
CheckSequenceVerify (CSV) Implementations
The implementation of the operation code OP_CSV allow transactions on the blockchain to have a relative expiration date. A property that in turn allows transactions to be stored indefinitely. As long as the initially established time blocking conditions remain. The opposite would happen if the OP_CLTV operation code is used, with which the entire chain of transactions would have a deadline of execution and expiration.
So, when OP_CSV is used to chain transactions through relative hang times, it is possible to create a code path that is only accessible after the set time interval elapses. That is, after the exits that are being spent are confirmed. Allowing the creation and application of additional functions that make the network much more attractive. For example, the implementation of contracts with expiration terms or the possibility of practically having the chain reorganization characteristic or retroactive invalidation. Although it is almost impossible to perform on a blockchain, other similar applications can be established, such as custody protocols or time-blocked contracts, bidirectional payment channels y Lighting Network.
How much do you know, cryptonuta?
Is the existence of CheckSequenceVerify vital to Lightning Network?TRUE!
One of the necessary requirements for the operation of Lightning Network is the CheckSequenceVerify function, a necessity described in the Lightning Network whitepaper, especially to avoid situations in which one of the parties can steal funds from the system.
CheckSequenceVerify (CSV) use cases
Now let's examine some use cases that CSV allows us within Bitcoin thanks to its creation:
Creation of contracts with expiration time
With CSV it is possible to establish contracts with fixed-term time or expiration date. In these contracts, you can define various conditions that will start when a transaction begins and becomes effective. For example: to make a security deposit between 2 or more people, which expires automatically after 30 days from being made, the parties involved (María, Pedro and Juan) can create a multi-signature address with the following conditions:
- Funds can be scrambled at any time desired, if 2 of the 3 authorized firms are used. These can be combined in any way (Maria and Pedro, Pedro and Juan, María and Juan).
- Maria can sign alone and use the funds only after 30 days of the transaction.
This relative time lock will start until the transaction is confirmed at the deposit address.
Creation of retroactive invalidation protections
Although for security and protection reasons, the blockchain is immutable once data and information have been added to it. But there are many cases in which it is ideal to be able to change or cancel a contract once it is established. However, although you cannot directly carry out a retroactive invalidation once the data has been confirmed within the blockchain, a rearrangement of the chain. Although this feature is also particularly difficult to do and quite expensive.
Even so, by means of the CSV operation code, scripts with various ramifications can be built to carry out the operations. Where, if one or more of these branches are delayed or are not fulfilled, a space is created in which it is possible to add a condition for the invalidation of the original contract, which allows the expense of departures. Nullifying the branch where the condition that was not fulfilled is established. Thus preventing the transaction from being transmitted to the network. Otherwise, the contract will follow the originally established course.
Creation of HTLC contracts (Hash Time Locked Contracts)
One of the most important functions of CSVs is the creation of Hash Time Locked Contracts or Hash Time Locked Contracts (HTLC). It is thanks to these contracts that it is possible to carry out a system that allows two users to create a payment channel. One where the receiving party must create valid cryptographic evidence in order to release the payment withheld by the contract.
This function is the one that allows, for example, to create secure payment channels between two users. These channels are capable of performing on-chain (in the same chain) and cross-chain (between two different chains) operations. In this way, HTLC enable a secure mechanism to carry out atomic swaps.
But not only that, HTLC are also what make possible the safe operation of the Lightning Network. Thus demonstrating the impact and usefulness of CSVs throughout the Bitcoin ecosystem.
Author
