What is TimeLock?

Timelocks are one of the most practical functionalities of Bitcoin, allowing you the ability to program actions according to a series of parameters and thus making Bitcoin better than money, a fully programmable digital money.

Una of the innovative functions it has Bitcoin known as Timelock. This is a tool that it serves to establish and specify certain conditions under which transactions may be validated.

Un time lock o time lock, is a kind of smart contract primitive, which refers to what block height or specific time, a particular transaction may be included by miners on the blockchain. So that works as a kind of absolute block or restriction on the spending of certain bitcoins until these conditions are met.

A timelock can be set based on real time or a specific block height. So when that time or that block height defined in the timelock, miners will be able to include the transaction in the hash of the merkle tree, and add it to the last block of the blockchain. And at this time it is that the transaction may be confirmed.

TimeLocks classification

Timelocks were added to the original Bitcoin software by its creator, Satoshi Nakamoto. They are present in all transactions even if most do not use this function, so the default blocking time is 0x00000000 (0) or 0xFFFFFFFF (4294967295). However, for those transactions in which timelock is used, it is important to know that it has 3 important attributes. What are they: location, orientation y metrics.

Location

As we already mentioned, Timelocks can be found in transactions even if this feature is not used. And they can also be included in the scripts. Both are very similar, but perform completely different functions.

In transactions, timelocks mean that it cannot be validated until it reaches a certain time or reaches a defined block height, although its digital signatures and scripts yes they are valid. Whereas locktimes in scripts determine if a script is valid. So conditions can be established in all transactions that spend an exit.

Unlike blocking on transactions, they only restrict that particular transaction. Hence the importance of the location of the timelocks so that they can carry out the corresponding operation.

Orientation

There are time timelocks absolute or time relative. The first allows us to define the block in terms of a certain time. So we can choose the exact moment in which the block will end.

While the relative time lock allows us to define a certain amount of time that must elapse starting from the confirmation of the previous exits. Both options are extremely useful to define necessary time intervals for a transaction to be processed by the Bitcoin network.

Metric

In Bitcoin there are two ways to measure time: the block number and timestamp. So we can use both to establish a timelock. When a timelock is established based on a block number, miners should expect to reach that block number. This in order to validate and confirm the operation, and include it in a new block.

Conversely, when the timelock is set based on a timestamp, miners wait for the set time in seconds to elapse. In other words, a certain time is reached to validate the transaction. This is measured with the mark of Unix time.

Types of Locks

Today, Bitcoin currently has 4 ways to establish locks or timelocks. Two of these tools are at the transaction level and the other two are at the script level. Let's see each one of them.

1.nLockTime

This is a absolute time blocking at transaction level. It is the only time lock that was available in the original version of Bitcoin software. When the nodes. did not retransmit or undermine transactions with nLockTime equal to or greater than the height of the current block.

So the transactions were not validated until the established block was reached. In these locks, time is expressed as unsigned 32-bit integers. If the number is less than 500 million, it is interpreted as a block height. On the contrary, if it is greater than 500 million, it is taken as a Unix Time mark.

In version 0.1.6 of Bitcoin, the interpretation of nLockTime was adjusted to also allow time-based locking. Then, starting with block 31001, the nLockTime constraints were activated as a rule that also applied to accepting the block. Later, in July 2016, the time-based locks were changed to operate on the past mean time instead of the block's time stamp.

An nLockTime can block a transaction for up to 9.500 years using block numbers, and 2.106 years using time stamps. And although every transaction currently contains the nLockTime function, most wallets have it preset to 0. This means that transactions can be validated in any block of the chain.

2.nSequence

This is a transaction level relative time lock. These locks were introduced into the soft fork 68 BIP in the middle of the year 2016. In it, the sequence numbers are used to establish relative time timelocks at the transaction level. This allows an entry to specify the earliest time that can be added to a block. Depending on how long ago the output spent by that input was included in a block on the blockchain.

When applying a nSequence Several different time conditions can be set within the same transaction. Thus, for the transaction to be valid, all conditions must be met. And if this does not happen, the entire transaction will be rejected.

Unlike nLockTime, nSequences only use 18 of the total 32 bits, so 14 bits are reserved for future implementations. And of those 18 bits in use, 16 bits are intended to encode the blocking time. So nSequence locks are limited to 65.535 block units, and only 18 hours in seconds.

3.CheckLockTimeVerify

Also known by its initials as CLTVIs a absolute time blocking at script level. It is detailed in the soft fork 65 BIP and it was introduced to the network in late 2015, by developer Peter Todd. This proposal opens the possibility of being able to carry out a transaction in which the specific date on which it will become effective can be specified (that is, the date on which the recipient can make use of the funds sent).

One of the advanced functions that CTLV allows is to change the authentication parameter of a multi-signature address. For example, if a multi-signature address has been created with a scheme 2 of 3, CLTV can change said parameter under certain criteria to a scheme 1 of 3. In this way, the person can recover the funds under certain previously agreed conditions and which are defined in the transaction due to the ability to be Bitcoin programmable money.

4.- CheckSquenceVerify

Is script-level relative time lock. Also part of the soft fork 68 BIP, but was described in the 112 BIP and was added in mid-2016. CSV It provides a relative blocking time, just as CLTV provides one for the absolute blocking time, so they are extremely very similar. However, instead of checking time as CLTV does, CSV checks the top stack with the input field.

When the CSV opcode is called, it will cause the script to fail unless nSequence in the transaction indicates that a relative amount of lockout time equal to or greater than the parameter provided to the CSV opcode has passed. This ensures that the transaction can be included in a valid block when the CSV-based time lock has expired.

With this operation code, transactions can be blocked for a maximum of 65.535 blocks, which is equivalent to approximately 455 days. Or a maximum of 65.535 × 512 seconds, which is approximately 388 days.