OP_IF / Script Conditional

OP_IF and its companions OP_NOTIF, OP_ELSE, and OP_ENDIF are the conditional flow-control opcodes of Bitcoin Script. They let a single locking script contain more than one spending path, with the branch taken decided at spend time by a value the spender places on the stack. Nearly every interesting Bitcoin contract — payment channels, atomic swaps, timeout refunds — is at heart a small tree of OP_IF branches, each encoding one way the story of a coin can end.

How conditionals execute

OP_IF pops the top stack item: if it is true (non-zero), the statements up to the matching OP_ELSE or OP_ENDIF execute; if false, they are skipped and any OP_ELSE branch runs instead. OP_NOTIF inverts the test. Every OP_IF must be closed by a matching OP_ENDIF or the script is invalid, and branches can be nested. The spender steers execution by pushing the appropriate selector before the conditional — a 1 to take the "happy path," an empty value for the alternative branch. One subtlety matters for modern outputs: in SegWit and Tapscript contexts the selector must be minimally encoded (exactly an empty vector or a single 0x01 byte), a rule known as MINIMALIF that closes a malleability vector where a third party could substitute a different-but-truthy selector. Unexecuted branches are not free, either — their opcodes still occupy space and, in legacy contexts, still count toward limits — which is part of why script designers keep conditional trees shallow.

Why it matters for contracts

Conditionals are what let a single output support several mutually exclusive outcomes. The classic pattern pairs OP_IF with a timelock: one branch lets the recipient claim funds immediately with a signature and perhaps a hash preimage, while the OP_ELSE branch lets the sender reclaim them with OP_CHECKLOCKTIMEVERIFY (CLTV) or OP_CHECKSEQUENCEVERIFY (CSV) after a deadline. Hash Time-Locked Contracts, cross-chain atomic swaps, and the penalty and timeout paths inside Lightning commitment transactions are all built from exactly this shape. The structure means neither party has to trust the other's future cooperation: every contingency was compiled into the coin's locking script before the first satoshi moved.

From inline branches to Taproot leaves

Reading a real branch

A worked example makes the pattern stick. A hash time-locked contract's locking script says, in words: "IF the spender reveals the preimage of this hash and signs with the recipient key, pay them; ELSE, after the timeout, a signature from the sender key may reclaim the funds." On the wire that is an OP_IF guarding a hash check and a signature check, an OP_ELSE guarding a CLTV or CSV condition plus the refund signature check, and an OP_ENDIF closing the block. The spender's unlocking data supplies the arguments for one branch plus the selector that steers into it — forget the selector and the script fails even with a perfectly valid signature, a classic first-timer stumble when hand-building transactions. Auditing unfamiliar scripts follows the same path in reverse: enumerate every branch, ask who can satisfy it and when, and check that no branch exists that the parties did not intend. In Bitcoin, the contract is exactly what the branches say — no more, no less.

Tapscript reframed the same idea. Instead of packing every branch into one script where all paths are revealed on spend, Taproot lets designers split alternatives into separate leaves of a Merkle tree, revealing only the branch actually used — cheaper on-chain and more private, since unexercised contingencies stay invisible. OP_IF remains the canonical inline branching tool within any single leaf, and understanding it is still the fastest way to read real-world scripts: find the conditionals, and you have found the contract's decision points. These opcodes operate directly on the script stack, and tracing a script branch by branch with pencil and paper remains the best way to learn how Bitcoin's predicate logic actually settles money.