Locktime

Think of locktime as a postdated cheque written into the protocol. One field, two meanings, decided by a threshold: any value below 500,000,000 counts blocks, and anything at or above it counts seconds since 1970. Most transactions you ever send will carry a locktime, and it will do nothing except protect you from a subtle miner trick.

How it works

Locktime sits at the very end of the serialized transaction and is checked before anything else about the spend is considered.

The threshold rule is what makes one field do two jobs. A locktime of 900,000 means the transaction cannot appear in a block below height 900,000. A locktime of 1,800,000,000 is a Unix timestamp and means the transaction cannot appear until the median time of the previous eleven blocks passes that moment. The dividing line, 500,000,000, corresponds to November 5, 1985, which is safely before bitcoin existed and safely above any plausible block height. The field is four bytes, so the maximum expressible time is February 7, 2106.

There is a switch. Locktime is only enforced if at least one input has a sequence number below 0xffffffff. Set every input to 0xffffffff and the field is ignored entirely, which is how transactions worked for years before wallets found a use for it.

That use is anti-fee-sniping. When fees are high, a miner who loses a block race has an incentive to try re-mining the previous block and stealing its fees rather than building forward. If wallets set the locktime of every transaction to the current chain tip, those transactions become invalid in any earlier block, which removes most of the loot and the incentive. Bitcoin Core does this on ordinary spends, and about one time in ten it picks a height uniformly from the previous 100 blocks so that transactions from different wallet software do not stand out from each other.

Where you see it

Open any recent transaction on a block explorer and the locktime field will usually hold a number close to the height at which it was mined.

That is the anti-fee-sniping behavior, and seeing it is a mild fingerprint of the software that built the payment. Wallets that leave the field at zero are announcing something too. Chain analysis firms read this field precisely because so few users think about it.

The deliberate uses are narrower. A locktime in the future creates a transaction that can be signed and handed over now but not broadcast until later, which is the basis of simple inheritance schemes and refund paths. Lightning force close transactions and submarine swaps use timelocks so that a counterparty who disappears cannot strand your money forever. Anyone constructing these should note the obvious weakness: a locked transaction is only as good as the coins behind it, and if the sender spends those inputs another way first, the postdated transaction becomes worthless.

Locktime vs OP_CHECKLOCKTIMEVERIFY

Locktime restricts a transaction; OP_CHECKLOCKTIMEVERIFY restricts a coin. The difference matters because only one of them binds anyone but the person signing.

A locktime is chosen by whoever builds the transaction, so it protects nobody: a sender can simply build a different transaction without it. OP_CHECKLOCKTIMEVERIFY, defined in BIP65 and active on the network since block 388,381 on December 14, 2015, puts the condition into the output's own script. Any future spend of that coin must itself carry a locktime at or beyond the stated point, and no signature can bypass it. That is what turns a timelock from an intention into a rule, and it is why vault, escrow and inheritance designs are written with the opcode rather than the field.