What is nLockTime?

nLockTime is the first time blocking function that Bitcoin had since its inception and designed by Satoshi Nakamoto, as a way to allow scheduled and triggered transactions by time parameters within the Bitcoin protocol.

Una of the most interesting properties it has Bitcoin are time locks or timelock such as nLockTime. These types of functionalities allow users to define the exact moment in which a transaction can be validated and confirmed on the network. A quality that turns Bitcoin into programmable digital money. For example, by implementing smart contracts or smart contracts. All this is possible thanks to the fact that Bitcoin has a powerful programming language called Bitcoin script.

So we have to nLockTime is an absolute time lock at the transaction level. This allows defining the moment from which a transaction can be validated and included within a valid block of the blockchain. That is, nLockTime specifies the earliest time from which a transaction can be validated and committed.

This type of time blocking is essential for the implementation of programmable transactions in the Bitcoin system. They allow that, once the conditions established in a contract are defined and fulfilled, the transactions can be executed automatically and without intermediaries.

Likewise, nLockTime is the only time lock that has been around since the implementation of Bitcoin's original client, the Bitcoin Core. So this field is included in every transaction. However, in Bitcoin clients and wallets the nLockTime field is default with the value 0. So if this field is not modified, the transactions can be included within any valid block of the blockchain.

How does nLockTime work?

The nLockTime time lock sets a minimum time interval so that a transaction can be validated and included within a block. So this function is implemented and used in order to avoid the extraction of a transaction before the determined time is reached in the established lock. And otherwise, the network simply invalidates said transaction avoiding its processing.

In the original Bitcoin client, this lock only allowed setting the blocking conditions based on the block height. Therefore, the network nodes could not include the transactions with nLockTime until the minimum block height established in the lock was reached.

Later, nLockTime was adjusted so that time-based blocking conditions could be applied to Bitcoin transactions. Which currently operate based on half time past and not in the block's own time stamp. So nLockTime then requires that a defined time interval elapse or a certain block height be reached for the transaction to be validated.

For its part, in nLockTime the lock is shown as a 32-bit integer, where:

• If nLockTime is less than 500.000.000, then it is understood as a time lock based on a block height. Where, only once this block height is reached or exceeded, the transaction can be confirmed within a valid block.
• If nLockTime is greater than 500.000.000, then it is understood as a time-based time lock, which will be measured in UNIX time. Where, only once this time stamp is equalized or exceeded, the transaction can be confirmed within a valid block.

Likewise, nLockTime allows a transaction to be blocked for up to 9.500 years when it is a time block based on block height. Whereas for locks based on a time interval, nLockTime can set a lock on one for up to 2.106 years.

Implementation of nLockTime

Since nLockTime will only allow a transaction to be fetched and added to a valid block once a set block height or time is reached or exceeded, this lock is used to set and schedule transactions that will only be committed in the future. So it is widely useful for creating smart contracts.

The particularity of nLockTime allows that if any of the parties involved in the contract does not comply, the scheduled transactions can be changed or modified, before the limited time elapses or the block height is reached and the transactions are executed. If any eventuality occurs, default or simply one of the parties decides to change their mind, a new transaction without blocking can be established to invalidate the transaction that does have the time blocking. As long as the same outputs used as inputs in the transaction with the nLockTime lock set are used as inputs.

Thus, the new transaction created, since it does not have an established blocking time, will be validated and confirmed within one of the following blocks immediately after its creation.

Smart contracts or payment channels without trust

On the other hand, through nLockTime you can create payment channels They do not require trust or third parties. For example, if a multi-signature address 2/2 in which bitcoins are deposited to make payments gradually to one of the parties involved, both parties will have possession over one of the keys of the address.

User A, before depositing bitcoins to the multi-signature address that User B will be paid with, can set up an nLockTime transaction at a certain block height or set time stamp.

Then user A will have possession of one of the keys, and user B will have possession of the other key of the address. Thus, user A can sign a transaction when he wants to make a payment to user B; placing the bitcoins in an output that requires the signature of both parties (users A and user B), but does not transmit it to the network. Using the hash of this first transaction, user B creates a second transaction that spends the first and returns bitcoins to user A through the multi-signature address. At this point, as both parties must sign, the transaction cannot be completed. So neither party can spend the bitcoins.

Since the nLockTime field is defined with a block height or time stamp, the transaction can be returned to user A. This in case the contract conditions are not met and the transaction is not signed by both parties as required. Therefore, the deposit made can be recovered, once the defined blockade has elapsed, if the other party involved does not do the work or acts in the wrong way.

nLockTime and CLTV How are they different?

In Bitcoin there are several forms of time blocking or timelocks. These operations allow Bitcoin to have transactions or operations that can be scheduled. And this can be in relation to a unit of time (described as a timestamp) or to a certain block height (activation with block height). Thanks to them, a TX can be sent and it can only be validated after reaching the specified time or height condition.

An example of this utility may be that Maria wants to send Daniel a payment. But said payment can only be made 15 hours after the transaction is issued. To do this, Maria issues the transaction using the nLockTime function. This ensures that the transaction can only be processed 15 hours after it is issued. Pretty useful to tell the truth.

But what if we need to do more complex operations? Well in that case, nLockTime does not allow us to do more complex things. So to save this situation, Bitcoin developers created CLTV or CheckLockTimeVerify. This OP_CODE or opcode Lets you use the value of nLockTime (the time block or block value) and add an additional schedule. That is to say, CLTV allows us to add a series of additional conditions that must be met in order for the transaction to be validated. Even CLTV can change these conditions in the event that the initial conditions have not been met, allowing the payment to be unlocked under other conditions already programmed.

A clear example of using CLTV is a bitcoin fund protected by a multi-signature address. If said funds are not mobilized in a certain period of time, CLTV may modify the conditions for unlocking said funds. Thus we can convert a 2-of-3 model's multi-signature address into a 1-of-3 model's multi-signature address. So only a valid signature would be enough to access these funds.