Timelocks → HTLCs & Atomic Swaps

Bitcoin can express “this coin cannot move until time T” and “this coin cannot move until N blocks after it was confirmed.” These timelocks look like minor footnotes, but they are the structural beams of every advanced contract in Bitcoin: payment channels, vaults, and trustless cross-chain swaps all reduce to timelocks + hashlocks. This page builds them from the four primitives up.

Two axes, two locations

Timelocks come in two independent flavours, and each can be enforced in two places:

                 ABSOLUTE (a specific time/height)   RELATIVE (an age after confirmation)
on the TX        nLockTime                            nSequence (BIP 68)
in the SCRIPT    OP_CHECKLOCKTIMEVERIFY (CLTV, BIP65) OP_CHECKSEQUENCEVERIFY (CSV, BIP112)

• Transaction-level locks (nLockTime, nSequence) say when this particular transaction becomes valid. They’re a property of the spend.
• Script-level locks (CLTV, CSV) bake the constraint into the coin’s locking script itself, so any spend is forced to respect it. This is the powerful version — the rule travels with the money.

Absolute: nLockTime and CLTV

nLockTime is a transaction field meaning “invalid until block height (or Unix time) X.” Below 500,000,000 it’s interpreted as a block height; at or above, as a Unix timestamp.

OP_CHECKLOCKTIMEVERIFY (BIP 65) puts that check inside a script: “this output cannot be spent by any transaction whose nLockTime is earlier than X.” It lets you write “these coins are frozen until block 900,000” as a spending condition that no one — not even the key holder — can bypass early.

Relative: nSequence and CSV

BIP 68 repurposed the input’s nSequence field to mean a relative timelock: “this input can’t be spent until N blocks (or N×512 seconds) after the output it spends was confirmed.”

OP_CHECKSEQUENCEVERIFY (BIP 112) is the script form: “once these coins land, they’re locked for N blocks before this branch can move them.” Relative locks are what let you say “the counterparty has 1,000 blocks to respond” — a countdown that starts when the coin is mined, not at a fixed calendar date. This is the heartbeat of payment channels.

Why nSequence is overloaded

nSequence started life as a half-finished idea for transaction replacement, sat unused for years, and was later given two real jobs: RBF signaling (see RBF/CPFP) and relative timelocks (BIP 68). One 4-byte field, three historical meanings — a classic source of confusion.

Building block 1: the hashlock (HTLC)

Combine a timelock with a hashlock and you get the single most important contract in off-chain Bitcoin: the Hash Time-Locked Contract (HTLC).

An HTLC output can be spent two ways:

Spend path A (the "hash" path):
    "Pay to Bob IF he reveals a secret R such that SHA256(R) == H"

Spend path B (the "time" path):
    "Refund to Alice AFTER the timelock expires"

In Script terms it’s an OP_IF … OP_SHA256 <H> OP_EQUAL … OP_ELSE <locktime> OP_CHECKLOCKTIMEVERIFY … OP_ENDIF construction. The genius: revealing R to claim the money also publishes R on-chain, where anyone watching can read it. That turns “I got paid” into a publicly verifiable event that propagates a secret — exactly what you need to chain payments together.

Use-case 1: Lightning (payments across a chain of strangers)

Suppose Alice wants to pay Carol but has no channel with her — only Alice↔Bob and Bob↔Carol exist. How do you route a payment through Bob without trusting Bob not to pocket it?

Carol picks a secret R, sends H = SHA256(R) to Alice.

Alice → Bob:   HTLC "pay 1 BTC if you show R, else refund me after 2 days"
Bob   → Carol: HTLC "pay 1 BTC if you show R, else refund me after 1 day"

Carol reveals R to claim Bob's HTLC  ──►  now Bob KNOWS R
Bob uses that same R to claim Alice's HTLC ──► everyone is square

The hashlock makes it atomic across the whole route: Carol can’t get paid without revealing R, and the instant she does, R is the key that lets each upstream hop claim its money. The staggered timelocks (2 days, then 1 day) guarantee each forwarder has time to claim after the downstream secret appears but before their own refund window — so no honest router can be left holding a loss. This is the actual machinery of a Lightning multi-hop payment.

Use-case 2: trustless cross-chain atomic swaps

The same HTLC trick works across two different blockchains (e.g. BTC ↔ LTC) with no exchange and no escrow:

Alice has BTC, wants LTC.   Bob has LTC, wants BTC.   Neither trusts the other.

1. Alice picks secret R, H = SHA256(R).
2. Alice locks her BTC in an HTLC: "Bob can claim with R; refund to Alice after 48h."
3. Bob sees it, locks his LTC in an HTLC on the LTC chain:
   "Alice can claim with R; refund to Bob after 24h."
4. Alice claims the LTC by revealing R on the LTC chain.
5. Bob reads R from the LTC chain and uses it to claim the BTC.

Either both legs complete (because claiming reveals R, which unlocks the other side) or both refund after the timelocks expire. No trusted third party ever holds both assets. The shorter timelock on Bob’s side (24h vs 48h) is deliberate — it protects the party who must act second.

Why the timelock ordering matters

The party who reveals the secret first (Alice) gets the longer refund window; the party who reacts (Bob) gets the shorter one. Get the asymmetry backwards and a malicious counterparty can wait for your refund window to lapse while still being able to claim — stealing one leg. The safety of every HTLC protocol lives in these inequalities.

Use-case 3: vaults and inheritance (CLTV) and channels (CSV)

• Dead-man’s switch / inheritance: <heir_key> OP_CHECKSIG available only after <2 years> OP_CHECKLOCKTIMEVERIFY, alongside a normal “owner can spend anytime” path. If you stop resetting it, your heir can sweep the coins after the deadline — enforced by Script, no lawyer.
• Payment channels: the penalty mechanism that keeps a Lightning counterparty honest relies on CSV — if someone publishes an old, revoked channel state, the relative timelock gives the victim a window to claim all the funds as a penalty. The timelock is what makes cheating unprofitable.

A rare-knowledge footnote: fee sniping and nLockTime

Why do modern wallets set nLockTime to roughly the current block height on ordinary, ready-to-confirm transactions, even though there’s nothing to delay?

It’s an anti-fee-sniping measure. If fees are high, a miner could be tempted to re-mine the last block instead of building a new one, scooping up the juiciest recent transactions for themselves. Setting nLockTime = currentHeight means your transaction is only valid from the next block onward, so it can’t be pulled into a re-mine of the current tip. It’s a tiny, almost invisible defense that nudges the incentive away from chain reorganizations. Spotting this in raw transaction data is a reliable “this person actually understands Bitcoin” signal.

The thread

How does this help untrusting strangers agree on one ledger? Timelocks let the ledger encode “not yet” and hashlocks let it encode “only if a secret is revealed.” Together they let mutually distrusting parties build multi-step deals where the protocol itself guarantees that either everyone is made whole or everyone is refunded — the same trust-minimization Bitcoin brought to single payments, now extended across hops, chains, and time.

Check your understanding

1. Distinguish absolute vs relative timelocks, and transaction-level vs script-level enforcement. Which field/opcode sits in each of the four cells?
2. Why is a script-level lock (CLTV/CSV) more powerful than a transaction-level one (nLockTime/nSequence)?
3. In an HTLC, why is it crucial that claiming the money reveals the secret?
4. In a cross-chain swap, why does the party who acts second get the shorter refund timelock?
5. Explain fee sniping and why setting nLockTime to the current height discourages it.