Spending Condition

What Is a Spending Condition?

A spending condition (also called a locking script or encumbrance) is the programmatic rule that governs how bitcoin locked in a UTXO can be spent. When a Bitcoin transaction creates an output, it assigns an amount of bitcoin and a spending condition to that output. Anyone who wants to spend that output must provide data that satisfies the condition.

Think of it as a lock on a safe. The spending condition defines the type of lock: it might require a single key (a signature), multiple keys (multisig), a combination plus a timer (timelock), or any combination of these. The spender must present the correct "keys" to unlock the funds.

Spending conditions are written in Bitcoin Script, a stack-based, intentionally limited programming language. Script lacks loops and general-purpose computation by design, ensuring that every spending condition can be validated quickly and predictably by all nodes on the network.

How It Works

Bitcoin uses a two-part system to enforce spending conditions. The output being spent contains a scriptPubKey (the locking script), and the spending transaction provides a scriptSig (the unlocking script) or witness data that satisfies it.

1. A transaction creates an output with a scriptPubKey that encodes the spending condition (for example: "require a valid signature from public key X")
2. When someone wants to spend that output, they construct a new transaction referencing it as an input
3. The spending transaction includes the required proof: a signature, a script, witness data, or whatever the condition demands
4. Every validating node executes the combined script on Bitcoin's stack machine. If execution completes with TRUE on the stack, the spending condition is satisfied and the transaction is valid

After SegWit, the unlocking data for modern output types moved from scriptSig to a separate witness field. This separation fixed transaction malleability and reduced the effective weight of spending proofs via the witness discount.

Common Spending Condition Types

Different address formats correspond to different spending condition structures:

Script Example

A Pay-to-Public-Key-Hash (P2PKH) spending condition looks like this in Script:

// Locking script (scriptPubKey)
OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

// Unlocking script (scriptSig)
<signature> <pubKey>

// Validation: the stack machine verifies that
// 1. The provided public key hashes to <pubKeyHash>
// 2. The signature is valid for this public key and transaction

The locking script says: "to spend this output, provide a public key that hashes to this value and a valid signature from that key." The OP_CHECKSIG opcode performs the digital signature verification.

Advanced Spending Conditions

Multisig Conditions

Multisig spending conditions require M-of-N signatures to spend. In legacy Script, this uses OP_CHECKMULTISIG:

// 2-of-3 multisig locking script
OP_2 <PubKeyA> <PubKeyB> <PubKeyC> OP_3 OP_CHECKMULTISIG

In Tapscript (Taproot's script version), OP_CHECKSIGADD replaces the legacy multisig opcode. It processes signatures individually and accumulates a counter, avoiding the off-by-one bug present in the original OP_CHECKMULTISIG and enabling more efficient batch validation:

// 2-of-3 multisig in Tapscript
<PubKeyA> OP_CHECKSIG
<PubKeyB> OP_CHECKSIGADD
<PubKeyC> OP_CHECKSIGADD
OP_2 OP_NUMEQUAL

Timelock Conditions

Timelocks add a time dimension to spending conditions. Bitcoin supports two timelock opcodes:

• OP_CHECKLOCKTIMEVERIFY (CLTV): an absolute timelock that prevents spending until a specific block height or Unix timestamp. Defined in BIP 65.
• OP_CHECKSEQUENCEVERIFY (CSV): a relative timelock that prevents spending until a certain number of blocks have passed since the UTXO was confirmed. Defined in BIP 112.

These opcodes are composable with other conditions. For example, a spending condition might require "Alice's signature after 144 blocks" or "Bob's signature OR Alice's signature after 30 days." This composability is fundamental to how HTLCs work in the Lightning Network.

Taproot: Multiple Spending Paths

Taproot (BIP 341) introduced a major upgrade to spending conditions by enabling two distinct spending paths in a single output:

• Key path spend: satisfy the condition with a single Schnorr signature for the output's tweaked public key. The internal key can actually be an aggregated key (via MuSig2) representing multiple parties, but on-chain it looks identical to a single-signature spend.
• Script path spend: reveal a specific script from a Merkle tree of scripts (the Taptree), plus a proof that the script belongs to the tree, and then satisfy that script. Only the executed script is revealed; all other spending paths remain hidden.

This design is powerful: a Taproot output could encode "Alice and Bob cooperate (key path), OR after 6 months Alice alone can spend (script path leaf 1), OR a 3-of-5 multisig can spend (script path leaf 2)." In the common case where Alice and Bob cooperate, only a single signature appears on-chain. The complex fallback conditions stay private.

Miniscript: Composable Policy Language

Miniscript is a structured subset of Bitcoin Script that makes spending conditions composable, analyzable, and human-readable. Developed by Pieter Wuille, Andrew Poelstra, and Sanket Kanjalkar, it provides a policy language that compiles to optimal Script:

// Miniscript policy: Alice can spend, OR Bob after 30 days
or(99@pk(Alice), and(older(4320), pk(Bob)))

// Compiles to Bitcoin Script automatically
// Miniscript can also:
// - Determine the maximum witness size
// - Find the cheapest spending path
// - Verify that the script is safe and correct

Miniscript enables wallet developers to compose spending conditions from building blocks (signatures, timelocks, hash preimages) without manually writing Script, reducing the risk of subtle bugs.

Use Cases

Simple Payments

The most common spending condition is a straightforward signature check: the recipient proves ownership of the private key corresponding to the address. P2WPKH and P2TR key-path spends are the modern standard for everyday Bitcoin transactions.

Custody and Governance

Organizations use multisig spending conditions to require multiple approvals before funds can move. A corporate treasury might use a 3-of-5 multisig where three executives must sign off. Inheritance schemes combine multisig with timelocks: a family member can claim funds after a year of inactivity, while the owner retains immediate spending access.

Payment Channels and Layer 2

Payment channels use spending conditions as their enforcement mechanism. A Lightning channel funding transaction locks bitcoin behind a 2-of-2 multisig: both parties must cooperate to spend. Commitment transactions add conditional branches with timelocks and revocation keys so that either party can claim their balance if the counterparty disappears.

Spark uses cooperative signing as its primary spending condition. The user and the Spark Operator each hold key shares, and spending requires both to produce a valid signature via FROST threshold signatures. On-chain, this appears as a single Schnorr signature through Taproot's key path. If the operator becomes unresponsive, users can fall back to a script-path spending condition that enables unilateral exit without operator cooperation.

Escrow and Conditional Payments

Spending conditions enable trustless escrow by combining hash locks with timelocks. HTLCs (hash time-locked contracts) create a condition that says: "provide the preimage for this hash before the timeout, or the sender reclaims the funds." This pattern powers atomic swaps, submarine swaps, and Lightning Network routing.

Vaults

Vault designs use spending conditions to create a "cooling-off period" for large withdrawals. The condition requires that funds first move to a staging address with a timelock. During the delay, the owner can claw back the funds to a recovery address if the withdrawal was unauthorized.

Risks and Considerations

Script Limitations

Bitcoin Script is intentionally limited: no loops, no floating-point math, a maximum script size of 10,000 bytes (with Tapscript allowing larger individual scripts), and a cap on the number of non-push opcodes. These constraints mean some spending conditions that developers might want simply cannot be expressed. Proposed covenant opcodes like OP_CAT and OP_CTV aim to expand what is possible.

Irrevocability

Once a spending condition is set on a UTXO, it cannot be changed. If a bug in the script makes the output unspendable, or if the required keys are lost, those funds are permanently inaccessible. This makes testing and formal verification critical for complex spending conditions. Miniscript helps mitigate this risk by providing automated analysis and correctness checking.

Privacy Trade-offs

Complex spending conditions can reveal information on-chain. A 3-of-5 multisig script exposes all five public keys when spent. Taproot improves this significantly: the key path reveals nothing about alternative spending paths, and the script path reveals only the branch used. However, spending via script path still discloses the executed script and the Merkle proof structure.

Fee Implications

More complex spending conditions require larger witness data, which increases transaction fees. A simple P2TR key-path spend is the cheapest option. Script-path spends cost more depending on the script complexity and Merkle proof depth. When designing spending conditions, developers must balance expressiveness against the cost to satisfy them on-chain.

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.