Locktime (nLockTime)

What Is Locktime (nLockTime)?

Locktime, technically called nLockTime, is a field present in every Bitcoin transaction. It occupies the last 4 bytes of the raw transaction data as a 32-bit unsigned integer in little-endian byte order. When set to a non-zero value, it tells the network: do not include this transaction in a block until a specified point in time has passed.

nLockTime was part of Satoshi Nakamoto's original Bitcoin implementation (v0.1). Satoshi envisioned it working alongside the nSequence field to enable a transaction replacement mechanism where parties could create a transaction with a future lock time, then update it by broadcasting new versions with higher sequence numbers. While that original replacement mechanism was never fully realized, nLockTime itself has become a foundational primitive for Bitcoin Script programmability and time-locked contracts.

How It Works

Every Bitcoin transaction contains an nLockTime value. When set to 0, the transaction can be included in any block with no restriction. When set to a non-zero value, the interpretation depends on whether the value falls above or below a specific threshold.

Dual Interpretation

The threshold value is exactly 500,000,000 (hex 0x1DCD6500). This threshold was chosen because block 500,000,000 will not be reached for approximately 9,500 years at Bitcoin's 10-minute block interval, providing an unambiguous separation between the two modes:

For timestamp-based locks, since BIP 113 activation in 2016, the comparison is made against the Median Time Past (MTP): the median timestamp of the 11 blocks preceding the block being validated. This ensures the comparison value increases monotonically, preventing miners from manipulating their block timestamp to include time-locked transactions early.

The nSequence Gate

nLockTime enforcement depends on the nSequence fields of the transaction's inputs. If every input has nSequence set to 0xFFFFFFFF (the maximum value, called SEQUENCE_FINAL), the transaction is considered "final" and nLockTime is ignored entirely by consensus. At least one input must have nSequence below 0xFFFFFFFF for nLockTime to be enforced.

Bitcoin Core checks this via its IsFinalTx() function. Nodes will neither relay nor mine a transaction whose nLockTime has not yet been satisfied.

// Simplified nLockTime validation logic
bool IsFinalTx(const CTransaction& tx, int nBlockHeight, int64_t nBlockTime) {
    if (tx.nLockTime == 0)
        return true;

    int64_t lockTimeLimit = (tx.nLockTime < 500000000)
        ? (int64_t)nBlockHeight  // Compare to block height
        : nBlockTime;            // Compare to median time past

    if (tx.nLockTime < lockTimeLimit)
        return true;

    // Check if all inputs are final (nSequence == 0xFFFFFFFF)
    for (const auto& txin : tx.vin)
        if (!txin.IsFinal())
            return false;

    return true;
}

Fee Sniping Prevention

The most common use of nLockTime today is automatic fee sniping prevention. Since Bitcoin Core 0.11.0 (merged December 2014 via PR #2340), the wallet sets nLockTime on every new transaction to the current block height and sets all input nSequence values to 0xFFFFFFFE.

Fee sniping is an attack where a miner with significant hashrate attempts to re-mine a recent block to capture its high-fee transactions. Without nLockTime protection, a miner could orphan the current best block and include those transactions in their own competing version. By locking transactions to the current block height, a miner attempting to re-mine a previous block cannot include them: they are only valid at the current height or later.

For privacy, Bitcoin Core adds a random offset with 10% probability: instead of setting nLockTime to exactly the current block height, it subtracts a random number between 0 and 99. This prevents observers from determining exactly when a transaction was created based on its nLockTime value. BIP 326 extends this concept to Taproot transactions.

Relationship to OP_CHECKLOCKTIMEVERIFY

nLockTime alone has an important limitation: it is a transaction-level restriction, not an output-level one. The holder of a private key can always create a new transaction without any nLockTime restriction to spend the same outputs. There is nothing stopping the key holder from bypassing the lock.

OP_CHECKLOCKTIMEVERIFY (CLTV), introduced in BIP 65 and activated in late 2015, solves this by enforcing timelocks at the script level. CLTV is an opcode embedded in the output's spending conditions that compares a value on the stack against the spending transaction's nLockTime field. The script fails if the transaction's nLockTime is less than the value specified in the script.

This transforms nLockTime from a voluntary, sender-imposed delay into a consensus-enforced, output-level lock. No matter who holds the private key or what transaction they construct, the output cannot be spent before the specified time. For a deeper look at both absolute and relative timelocks, see the Bitcoin Timelocks: CLTV and CSV research article.

Relative Timelocks: nSequence and OP_CSV

While nLockTime provides absolute timelocks (a specific block height or timestamp), OP_CHECKSEQUENCEVERIFY (CSV) and BIP 68 enable relative timelocks based on the age of the output being spent. BIP 68 repurposes the nSequence field with new consensus-enforced semantics, using bit flags to signal block-based or time-based (512-second granularity) relative delays. Together, these mechanisms form the complete timelock toolkit on Bitcoin.

Use Cases

Time-Locked Contracts

CLTV combined with nLockTime enables contracts where funds become spendable only after a future date. A common pattern uses multiple spending paths: one path requiring multiple signatures is available immediately, while a fallback path using a single signature becomes available only after a CLTV timelock expires. This powers wallet recovery mechanisms, vesting schedules, and inheritance planning.

// Example: time-locked output script (simplified)
// Before block 900000: requires 2-of-2 multisig
// After block 900000: spendable with single key (recovery)
OP_IF
    <pubkey_A> OP_CHECKSIGVERIFY
    <pubkey_B> OP_CHECKSIG
OP_ELSE
    900000 OP_CHECKLOCKTIMEVERIFY OP_DROP
    <pubkey_recovery> OP_CHECKSIG
OP_ENDIF

Hashed Time-Locked Contracts (HTLCs)

HTLCs combine hash locks with timelocks to enable trustless conditional payments. The timelock component (using CLTV) ensures that if the recipient fails to claim funds by revealing a preimage before the deadline, the sender can reclaim them. HTLCs are the core mechanism powering the Lightning Network and atomic swaps.

Payment Channel Dispute Resolution

Lightning Network commitment transactions use timelocks for dispute resolution. When a channel is force-closed, the broadcasting party's funds are subject to a timelock delay, giving the counterparty time to broadcast a justice transaction if the closure was fraudulent. Layer 2 protocols like Spark build on these timelock primitives to enable efficient off-chain transactions while preserving self-custodial security guarantees.

Scheduled and Deferred Payments

A sender can create and sign a transaction with a future nLockTime, then share it with the recipient. The recipient holds a valid, signed transaction that cannot be broadcast until the specified time. This provides a simple form of scheduled payment, though the sender retains the ability to double-spend the inputs before the lock time is reached.

Risks and Considerations

Transaction-Level vs. Script-Level Enforcement

A bare nLockTime restriction (without CLTV in the output script) offers no guarantee to anyone other than the sender. The sender can always create a competing transaction without nLockTime and broadcast it before the locked version becomes valid. For enforceable timelocks, CLTV must be used in the output's spending script.

Timestamp Precision Limitations

When using timestamp-based nLockTime, the comparison against Median Time Past introduces imprecision. MTP typically lags actual wall-clock time by approximately one hour, and miners have some flexibility in the timestamps they include in block headers. Applications requiring precise timing should account for this variance or use block-height-based locks instead.

Type Mismatch

A CLTV script specifying a block height cannot be satisfied by a transaction with a timestamp-based nLockTime, and vice versa. The lock time types must match: both must be in the block height range or both must be in the timestamp range. A type mismatch causes the script to fail unconditionally.

Interaction with Replace-By-Fee

Transactions using nLockTime for fee sniping prevention set nSequence to 0xFFFFFFFE, which does not signal Replace-By-Fee (RBF). RBF signaling requires nSequence below 0xFFFFFFFD. Developers building applications that use both timelocks and RBF must carefully choose nSequence values to enable the desired behavior. For a broader look at how fees interact with Bitcoin's mempool, see the fee market dynamics research article.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.