OP_NOTIF - The Inverted Conditional

2. OP_NOTIF — The Inverted Conditional

Overview

OP_NOTIF is the logical inverse of OP_IF. It enters its branch when the top stack element is false (zero or empty byte array) and skips its branch when the value is true. Think of it as a built-in NOT applied to the conditional check, saving you from having to explicitly negate the condition before calling OP_IF.

Opcode Reference

Opcode:     OP_NOTIF
Hex:        0x64
Byte value: 100 (decimal)
Category:   Flow Control

Behavioral Comparison

; OP_IF behavior:
<value>
OP_IF       ; enters branch if value != 0
  ...
OP_ENDIF

; OP_NOTIF behavior:
<value>
OP_NOTIF    ; enters branch if value == 0
  ...
OP_ENDIF

Both opcodes pop the top stack element. The difference is purely in which boolean state triggers branch entry.

Equivalence to OP_NOT + OP_IF

OP_NOTIF is functionally equivalent to:

OP_NOT
OP_IF
  ...
OP_ENDIF

However, using OP_NOTIF is preferred because:

• It saves one opcode byte (OP_NOT = 0x91).

• It is more readable and expressive in script source.

• It avoids the need to reason about OP_NOT's behavior on multi-byte stack values (which can be nuanced).

Stack Behavior

Stack before: [ ..., <0> ]   (falsy value)

OP_NOTIF
  <branch executes because condition was false>
OP_ENDIF

Stack before: [ ..., <1> ]   (truthy value)

OP_NOTIF
  <branch skipped>
OP_ENDIF

Practical Example: Timeout Fallback

A common pattern is to use OP_NOTIF for a timeout/fallback branch where the "normal" condition is presented first, and absence of it triggers the alternative:

; Script: Alice can spend anytime with signature + preimage
;         OR Bob can spend after timeout with just a signature

OP_IF
  ; Normal path: check hash preimage
  OP_SHA256 <hash> OP_EQUALVERIFY
  <Alice_pubkey> OP_CHECKSIG
OP_ELSE
  ; Fallback path (Bob after timeout)
  <locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP
  <Bob_pubkey> OP_CHECKSIG
OP_ENDIF

This can be rewritten with OP_NOTIF to express the fallback first:

OP_NOTIF
  ; Fallback path: Bob after timeout
  <locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP
  <Bob_pubkey> OP_CHECKSIG
OP_ELSE
  ; Normal path: Alice with preimage
  OP_SHA256 <hash> OP_EQUALVERIFY
  <Alice_pubkey> OP_CHECKSIG
OP_ENDIF

OP_NOTIF in HTLC Scripts

In real HTLC scripts used in the Lightning Network, OP_NOTIF is commonly employed to separate the payment path (which requires the preimage) from the timeout path (which does not). The spending party signals which path they are taking by pushing OP_1 or OP_0 before the script, and OP_NOTIF provides the clean inversion without extra opcodes.

; Simplified HTLC using OP_NOTIF
<remote_pubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
OP_NOTIF
  ; timeout path
  OP_DROP 2 <local_pubkey> <remote_pubkey> 2 OP_CHECKMULTISIG
OP_ELSE
  ; payment path (32-byte preimage present)
  OP_SHA256 <payment_hash> OP_EQUALVERIFY OP_CHECKSIG
OP_ENDIF

The Minimal Push Rule and OP_NOTIF

Like OP_IF, in SegWit v0 and Tapscript contexts, OP_NOTIF requires that the stack top be a minimal boolean — exactly 0x (empty, false) or 0x01 (true). Non-minimal representations cause immediate script failure.

When to Choose OP_NOTIF Over OP_IF

Use OP_NOTIF when:

• The "exceptional" or "fallback" case is more naturally expressed first.

• You want to avoid an OP_ELSE when the false branch is your primary logic.

• The selector pushed by the spender naturally means "not the default path."

Use OP_IF when:

• The "happy path" or primary condition is tested first (most common).

• The truthy case represents normal, intended behavior.