Spending Condition | Bitcoin Glossary | Mapping Bitcoin

Overview

Every Bitcoin UTXO is locked by a spending condition — a set of cryptographic and logical requirements that must be met before the bitcoin can be transferred. These conditions are encoded in the output's locking script (also called scriptPubKey) and are satisfied by providing the correct unlocking script (scriptSig) or witness data in a spending transaction.

Common Spending Conditions

Bitcoin supports a variety of spending conditions, from simple to highly complex:

• Single signature: The most common condition, requiring a valid digital signature from one private key.
• Multisig: Requires M-of-N signatures (e.g., 2-of-3) to authorize spending.
• Hash lock: Requires revealing a preimage that hashes to a specified value, used in HTLCs.
• Timelock: Prevents spending until a certain block height or timestamp is reached.
• Combination: Multiple conditions can be combined using Bitcoin Script logic (AND, OR, IF/ELSE).

Script Execution Model

Locking Script (in UTXO):
  OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

Unlocking Script (in spending tx):
  <signature> <pubKey>

Combined Execution:
  Stack: [signature, pubKey]
    -> OP_DUP     -> [signature, pubKey, pubKey]
    -> OP_HASH160 -> [signature, pubKey, pubKeyHash]
    -> <hash>     -> [signature, pubKey, pubKeyHash, expectedHash]
    -> OP_EQUALVERIFY -> [signature, pubKey]  (hashes match)
    -> OP_CHECKSIG    -> [TRUE]               (signature valid)

Taproot and Advanced Conditions

With Taproot, spending conditions gained significant flexibility. A Taproot output can be spent either via a simple key-path spend (single Schnorr signature) or a script-path spend that reveals one of potentially many alternative spending conditions hidden in a Merkle tree. This allows complex conditions to remain private unless actually used.

Edge Cases

• If a spending condition is too complex, the script may exceed size limits or require excessive computation, making the UTXO effectively unspendable.
• Outputs with the opcode OP_RETURN are provably unspendable by design, used for embedding data on-chain.