Locktime

Locktime is a four-byte field in every transaction that sets the earliest point it can be mined. That point is either a block height or a Unix time. Nodes will not accept or relay a transaction before its lock has passed, so the sender holds it until then.

Locktime works a little like a post-dated check. It only takes effect when at least one input's sequence value is not the maximum, as the section on when locktime is enforced explains.

What does locktime do?

A transaction with a locktime is fully signed and valid. It is simply not yet allowed into a block. The sender keeps it until the lock is met, then broadcasts it, and nodes accept it from that point on.

The lock is enforced by the network, not by the sender. Once the height or time passes, any node will accept the transaction and miners can include it.

How is locktime stored?

The locktime field is four bytes long. Its value runs from 0 (00000000) to 4,294,967,295 (ffffffff). In a raw transaction it is the last four bytes, stored in little-endian order, so the least significant byte comes first.

Take transaction f168381d…. Its raw form ends in 500e0c00. Reversing those bytes gives 000c0e50, which is 790,096 in hexadecimal. A lock of 790,096 means the transaction can only go into a block above that height. It was mined in block 790,097, the first block that qualifies.

Is a locktime a height or a time?

The value tells the network which kind of lock it is. The split is at 500,000,000:

Locktime value	Meaning	Lock is met when
0 to 499,999,999	A block height	The block is above that height
500,000,000 to 4,294,967,295	A Unix time, in seconds since 1 January 1970 UTC	The median time of recent blocks is past that time

For the time range, nodes compare the locktime with the median timestamp of the last 11 blocks, as BIP 113 specifies. They do not use their own clock. The median smooths out any single block whose timestamp is off.

The threshold, 500,000,000, is 5 November 1985 at 00:53:20 UTC. The largest value, 4,294,967,295, is 7 February 2106 at 06:28:15 UTC. The height range would take thousands of years to reach at the current pace of one block every ten minutes, so it is not a practical limit.

When is locktime enforced?

Each input has a sequence number. Locktime is only enforced when at least one input's sequence is less than the maximum, ffffffff. If every input has ffffffff, the transaction counts as final and the locktime field has no effect.

Two sides of the same rule show up in practice. Transaction 13e100dd… set a locktime of block 198,370, but its only input had sequence ffffffff. The lock was ignored, and the transaction was mined in block 198,359, eleven blocks early.

A wallet that wants a lock to work must set at least one sequence below ffffffff.

What are some real examples?

• Transaction b0fa60f6… has locktime 199,000 and an input sequence below ffffffff. It was mined in block 199,002, after the lock.
• Transaction 648fe76b… has locktime 1,358,106,524, which is 13 January 2013 at 19:48:44 UTC. Its input sequence was ffffefff, so the lock applied. It was mined in block 216,410, whose timestamp is 21:12:02 UTC that day.
• Transaction 938b171f… has a time locktime of 1,409,599,601, which is 1 September 2014. Its only input had sequence ffffffff, so the lock was ignored. It was mined in block 287,080 on 21 February 2014, long before that time.

These examples show the two rules at work. The lock only matters when the sequence check turns it on.

Is there a relative locktime?

Yes. The absolute locktime described here fixes a height or time for the whole transaction. A relative lock works per input and counts from when that input's previous transaction was confirmed. It is set in the sequence field, and BIP 68 defines it. The sequence page explains the bits.

Scripts can also check locktimes directly. BIP 65 added OP_CHECKLOCKTIMEVERIFY, which lets a script's conditions depend on a lock.

Why does a time lock feel approximate?

The miner sets a block's timestamp, and it can drift from the true time. A node accepts a block time only if it is later than the median of the previous 11 blocks. It must also be no more than two hours ahead of the node's own clock.

The median rule above softens the drift. A time lock is therefore accurate to within the spread of recent block times, not to the second. For anything that needs a precise moment, use a height instead.

Locktime is part of the TXID, so changing it makes a different transaction. The wTXID page explains the two IDs that identify a transaction.

Sources

• BIP 65: CHECKLOCKTIMEVERIFY defines how locktimes can be checked inside scripts.
• BIP 68: relative lock-time defines the sequence-based lock.
• BIP 113: median time past defines the time that time locks are compared against.
• Bitcoin Core's block validation code checks each block time against the median and the two-hour limit.