Skip to main content

Timelock | Bitcoin Glossary | Mapping Bitcoin

Timelock

Protocol

Also known as: time lock, CLTV, CSV

A restriction that prevents bitcoin from being spent until a specified time or block height is reached. Bitcoin supports absolute timelocks (nLockTime, OP_CHECKLOCKTIMEVERIFY) and relative timelocks (nSequence, OP_CHECKSEQUENCEVERIFY), which are essential for Lightning Network and other protocols.

Overview

Timelocks are a fundamental building block in Bitcoin's scripting system that restrict when a UTXO can be spent. By encoding time-based conditions into spending conditions, timelocks enable a wide range of applications including payment channels, HTLCs, vaults, and time-delayed recovery mechanisms.

Types of Timelocks

Bitcoin supports four distinct timelock mechanisms across two dimensions:

                   Transaction-level     Script-level
                   (in tx fields)        (in Script)
                ┌───────────────────┬───────────────────┐
   Absolute     │ nLockTime         │ OP_CLTV           │
   (fixed time  │ (BIP-original)    │ (BIP65)           │
    or height)  │                   │                   │
                ├───────────────────┼───────────────────┤
   Relative     │ nSequence         │ OP_CSV            │
   (time since  │ (BIP68)           │ (BIP112)          │
    confirmation)│                  │                   │
                └───────────────────┴───────────────────┘

Absolute Timelocks

  • nLockTime: A transaction-level field that prevents the transaction from being valid before a specified block height or Unix timestamp.
  • OP_CHECKLOCKTIMEVERIFY (CLTV): A script opcode (BIP65) that makes an output unspendable until an absolute time or block height, enforced within the locking script itself.

Relative Timelocks

  • nSequence (BIP68): A per-input field that encodes a minimum time (in blocks or 512-second intervals) that must pass after the referenced UTXO is confirmed.
  • OP_CHECKSEQUENCEVERIFY (CSV): A script opcode (BIP112) that enforces relative timelocks within the script, enabling outputs that cannot be spent until a certain number of blocks have passed since the UTXO was confirmed.

Applications

  • Lightning Network: Timelocks are essential to HTLCs, ensuring that payments can be refunded if not claimed within a window.
  • Vaults: Timelocked spending paths create a recovery window to cancel unauthorized transactions.
  • Inheritance planning: Time-locked scripts can release bitcoin to heirs after a specified period of inactivity.

Edge Cases

  • nLockTime values below 500,000,000 are interpreted as block heights; values at or above that threshold are interpreted as Unix timestamps. This dual interpretation can cause confusion if not handled carefully.
  • Relative timelocks only begin counting after the referenced UTXO is confirmed in a block, not from when the spending transaction is created.

Related Terms

nLockTimeProtocol

A field in a Bitcoin transaction that prevents it from being mined until a specified block height or Unix timestamp is reached. nLockTime is one of Bitcoin's oldest timelock mechanisms and is used in payment channels and other time-sensitive contracts.

Spending ConditionProtocol

The set of requirements encoded in a transaction output's locking script that must be satisfied to spend the associated bitcoin. Spending conditions can include signatures, hash preimages, timelocks, or combinations thereof.

HTLCLightning

Hash Time-Locked Contract, a conditional payment mechanism used in the Lightning Network and atomic swaps. An HTLC locks funds that can only be claimed by providing a cryptographic preimage before a timeout expires, enabling trustless multi-hop payments.

Bitcoin ScriptProtocol

A stack-based, non-Turing-complete programming language used to define the spending conditions of Bitcoin transactions. Scripts are embedded in transaction outputs and inputs, enabling features like multisig, timelocks, and hash locks.