Can someone explain nLockTime?

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.

¹A transaction is non-final if the locktime is active and not smaller than the current block height. From Bitcoin Core source code: src/consensus/tx_verify.cpp:17–37

bool IsFinalTx(const CTransaction &tx, int nBlockHeight, int64_t nBlockTime)
{
if (tx.nLockTime == 0)
return true;
if ((int64_t)tx.nLockTime < ((int64_t)tx.nLockTime < LOCKTIME_THRESHOLD ? (int64_t)nBlockHeight : nBlockTime))
return true;

// Even if tx.nLockTime isn't satisfied by nBlockHeight/nBlockTime, a
// transaction is still considered final if all inputs' nSequence ==
// SEQUENCE_FINAL (0xffffffff), in which case nLockTime is ignored.
//
// Because of this behavior OP_CHECKLOCKTIMEVERIFY/CheckLockTime() will
// also check that the spending input's nSequence != SEQUENCE_FINAL,
// ensuring that an unsatisfied nLockTime value will actually cause
// IsFinalTx() to return false here:
for (const auto& txin : tx.vin) {
if (!(txin.nSequence == CTxIn::SEQUENCE_FINAL))
return false;
}
return true;
}

² 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

• "The bitcoins will be on the network" is false. nLockTime'd transactions are not kept in the mempools of miners nor are they relayed between miners, until the nLockTime has almost elapsed. It is your responsibility to keep the signed transaction and publish it when the time is right. Commented Nov 30, 2015 at 14:26

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.

• The payment channel I described here is the unidirectional payment channel that is explained in the first 10 minutes of this video: youtube.com/watch?v=8zVzw912wPo Commented Oct 10, 2019 at 12:18

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.