The short answer
Transaction locktime, stored as nLockTime, sets the earliest point at which a Bitcoin
transaction may be included in a block. The value is interpreted as a block height when it
is below 500,000,000 and as a timestamp when it is at or above that threshold.
It does not make a transaction valid by itself. The inputs, signatures and amounts must still satisfy the normal rules. Locktime adds one condition: the chosen height or time must have passed before miners can include the transaction.
How it works
Bitcoin Core 31.1 checks nLockTime against the candidate block height or, for a time-based
lock, the network's median time past. BIP 113
defines that time as the median timestamp of the previous 11 blocks. This makes the clock
advance monotonically without trusting one miner's timestamp.
The boundary is strict. A transaction with height locktime 900 is still too early for block
900 and becomes eligible at block 901. Bitcoin Core's
IsFinalTx
implements that comparison.
There is another required detail. If every input uses the final sequence value
0xffffffff, Bitcoin Core ignores nLockTime. At least one input must use a lower sequence
value for transaction-level locktime to take effect. The current
transaction definition
documents both fields.
A concrete example
Suppose two parties prepare a refund transaction with a height locktime. They can sign and store it before the target height, but a miner cannot include it yet. Once the chain moves past that height, the same signed transaction can become eligible without either party changing it.
This pattern is useful in protocols that need a delayed fallback. It is different from
locking a UTXO itself. Plain nLockTime delays one specific
transaction. Another valid transaction spending the same output may still exist.
What people get wrong
Locktime is not a wall-clock alarm, a promise that a transaction will confirm, or a rule that reserves block space. It only prevents confirmation before a boundary. Afterward, the transaction still needs to reach miners and offer a competitive fee.
It is also not the same as OP_CHECKLOCKTIMEVERIFY. BIP 65
lets an output script require a compatible locktime in any transaction that spends it.
That can make spending before the boundary impossible under the script. Transaction-level
nLockTime alone proves only that one prepared transaction waits.