I'm having a hard time understanding how nLockTime works. The Bitcoin wiki has an explanation that is confusing to me:
nLockTime is a parameter that can be attached to a transaction, that mandates a minimal time (specified in either unix time or block height), that before this time, the transaction cannot be accepted into a block.
Can someone explain it in plain English, with an example?
The locktime is a transaction field that can be used to prevent a transaction from being included in the blockchain until some point in the future.
If every input’s sequence number is set to the maximum 0xffffffff, the locktime on the transaction is inactive. Regardless of the locktime value, the transaction can be included at any height.
If at least one sequence number in the transaction is 0xfffffffe (MAX-1) or lower, a transaction’s locktime will be enforced per the following consensus rules:
If the locktime is less than 500,000,000, the locktime is interpreted as a block height. The locktime defines the greatest block height that cannot include the transaction. The transaction may be included in any block with a greater block height than its locktime.
Example: A transaction¹ has a locktime of 800,000. The transaction is invalid until block 800,000 but may be included in block 800,001 or any later block.
If the locktime is at least 500,000,000, the locktime is interpreted as a Unix time (seconds since 00:00:00 UTC on 1 January 1970). A transaction may be included in a block if the MedianTimePast at the preceding block’s timestamp is greater than the locktime. The MedianTimePast refers to the median timestamp of the last eleven blocks.
Example: A transaction¹ has a locktime of 1,702,483,200 (i.e. 2023-12-13T16:00:00). Block 821023 (see table below) is the first block with a greater timestamp than this locktime, but only after a block is found where this timestamp is the median element of the most recent eleven blocks’ timestamps (including the new block), the transaction may be included in the following block. The considered transaction is valid for inclusion in block 821029 or later, as block 821023's timestamp is the median element of the timestamps from blocks 821018 through 821028 (both inclusive).
| Height | Timestamp | MTP | May include Tx |
|---|---|---|---|
| 821031 | 2023-12-13 17:45:16 | 2023-12-13 17:01:24 | yes |
| 821030 | 2023-12-13 17:35:38 | 2023-12-13 16:49:14 | yes |
| 821029 | 2023-12-13 17:35:24 | 2023-12-13 16:19:05 | yes |
| 821028 | 2023-12-13 17:33:46 | 2023-12-13 16:02:03 | no |
| 821027 | 2023-12-13 17:21:32 | 2023-12-13 15:56:00 | no |
| 821026 | 2023-12-13 17:01:24 | 2023-12-13 15:41:28 | no |
| 821025 | 2023-12-13 16:49:14 | 2023-12-13 15:29:58 | no |
| 821024 | 2023-12-13 16:19:05 | 2023-12-13 15:24:19 | no |
| 821023 | 2023-12-13 16:02:03 | 2023-12-13 15:18:50 | no |
| 821022 | 2023-12-13 15:56:00 | 2023-12-13 15:10:06 | no |
| 821021 | 2023-12-13 15:41:28 | 2023-12-13 15:04:59 | no |
| 821020 | 2023-12-13 15:29:58 | 2023-12-13 14:59:44 | no |
| 821019 | 2023-12-13 15:24:19 | 2023-12-13 14:51:59 | no |
| 821018 | 2023-12-13 15:18:50 | 2023-12-13 14:28:53 | no |
| 821017 | 2023-12-13 15:10:06 | 2023-12-13 14:25:51 | no |
| 821016 | 2023-12-13 15:04:59 | 2023-12-13 14:21:23 | no |
Since timestamps are only restricted to being greater than the MTP of the prior block and smaller than 2h into the future of the evaluating block’s network time, a sorted sequence of the timestamps may not necessarily have the same order as the corresponding blocks' heights.
¹ As mentioned above, the example transactions must each have at least one sequence number lower than the maximum, or the locktime would not be active.
From the wiki it basically states that you can make a transaction to another bitcoin address and add nlocktime. The way that this would work in real life would be if you get paid on salary and are paid bi-weekly, the bitcoins will be on the network but won't reach you until the nlocktime is up Edit: read example 1 from https://en.bitcoin.it/wiki/Contracts
In order for the transaction to be final, i.e., not reversible, the transaction needs to be included in a block. The nLockTime parameter can be used to guarantee that the transaction cannot be mined prior to a certain block height or a certain unix time stamps. In other words, the protocol guarantees that a specific transaction cannot be finalized prior to a certain time.
Imagine that you deposit 1 BTC into a 2/2 multisignature account and you intend to use this to make incremental payments to some other party. One of the keys in the multisig account is held by you and another one is held by the other party. Each time you want to make a payment to the other party, you sign a transaction from the multisig to the other party and give the signature to them. The other party can then, at any time, choose to publish the transaction you just signed by adding their own signature and handing the transaction to miners, or they can wait to see if any more payments (i.e. signatures) come from you.
Before depositing the bitcoins to the multisig address, the other party should send you a signature of a transaction with nLockTime set to 1000 blocks in the future. This transaction transfers the entire deposit of 1 BTC back to you. If they do that, then you can always get your deposit back (after 1000 blocks) even if the other party for some reason dissapears or chooses to act destructively.
The parameter nLockTime makes it possible to create trust-free payment channels.
nLocktime is Time Locked Transaction, which means a transection cannot be verified until locked time passed.
you can take it as Future Date cheque (1st of next month) or Promise from friend to send you money next Monday. Now neither You receive funds or nor you can verify if funds are on the way until the time passed.
On Due Date might your cheque bounce or your friend make an ugly excuse. NLocktime allow double spending and Transaction with Nlocktime can't be verified by the nodes until time passed.
More Secure and trustless Time lock options are OP_CLTV and OP_CSV. They apply time lock on Script level, which means transection can be verified but script wont get verified until time passed.
This article helped me
https://medium.com/summa-technology/bitcoins-time-locks-27e0c362d7a1
IsFinalTxfunction in the Bitcoin Core source code): a transaction is final if all its locking constraints are satisfied (so, either all sequence values are maximal, or all the locktime and sequence values refer to heights/times in the past). – Pieter Wuille Dec 13 '23 at 18:34