BitcoinMachine
TERM_DEF // SCRIPT_AUTHORIZATION / 1_OP_RETURN_BUG_HISTORICAL
1 OP_RETURN
BUG (HISTORICAL)
1 OP_RETURN Bug (Historical). Early bug allowing scripts to push 1 then OP_RETURN to short-circuit failure; long since fixed.

This page sits in the Script & Authorization section — The stack VM that decides whether a UTXO is spendable — opcodes, templates, and modern script trees. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
1 OP_RETURN Bug (Historical) — at a glance
SCRIPT
OP_RETURN is a Bitcoin Script opcode in the FLOW family. Its stack effect is → FAIL. Fail the script immediately; in outputs, creates a provably unspendable data carrier. Early bug allowing scripts to push 1 then OP_RETURN to short-circuit failure; long since fixed.
Why it exists
DESIGN
OP_RETURN exists because Branching gives scripts conditional spending paths — multi-sig fallbacks, Lightning HTLC timeout branches, hash-time-locked contracts.
Mechanism
HOW IT WORKS
Every UTXO is locked by a scriptPubKey — the output's locking script. To spend it, you provide a scriptSig (or witness) containing data that satisfies the lock. The node concatenates them, runs the combined script on a stack machine, and accepts the spend if and only if execution finishes with a single truthy value on the stack. 1 OP_RETURN Bug (Historical) contributes a specific stack effect within that process — opcodes either push, pop, copy, hash, branch, or verify, and they do so left-to-right deterministically.
1. The script is parsed into a sequence of opcodes and push-data items. 2. Execution starts with an empty stack and an empty alt-stack. 3. Each opcode runs in order — push opcodes add to the stack, others consume the top items and may push results. 4. Conditional opcodes (OP_IF/OP_NOTIF/OP_ELSE/OP_ENDIF) branch execution. 5. Final state: a single non-zero (truthy) value on top → the spend is authorised. Anything else (empty stack, false, error) → the script fails and the tx is rejected.
OP_RETURN — stack effect + canonical use
EXAMPLE
Opcode : OP_RETURN Family : FLOW Stack effect: → FAIL Behaviour : Fail the script immediately; in outputs, creates a provably unspendable data carrier. Open /playground in another tab and search for OP_RETURN. Drag the opcode in, watch the stack visualisation step through it against any combination of inputs you choose.
FAMILY
Belongs to the FLOW family of Script opcodes — siblings share validation rules and historical evolution.
STACK EFFECT
Exactly → FAIL. Every full node enforces the same effect, byte-for-byte.
ACTIVE
Active on mainnet today; every spend that uses it is being validated by every full node.
CONSENSUS-CRITICAL
OP_RETURN's behaviour is consensus rule — a node implementing it differently would fork off the network.
Things that catch people out
PITFALLS
  • OP_RETURN is FATAL — any script execution that reaches it fails. In outputs it produces a provably unspendable "data carrier".

Other terms from Script & Authorization — click any to read its page:
TERMINOLOGY
1 OP_RETURN Bug (Historical)
Early bug allowing scripts to push 1 then OP_RETURN to short-circuit failure; long since fixed.
Script
Bitcoin's purpose-built stack language; every locking and unlocking script is a script program.
Stack
The single LIFO data structure all script execution operates on; no variables, no registers.
Locking Script
The scriptPubKey on an output; specifies the spending conditions.
Unlocking Script
The scriptSig/witness in an input; provides the data that satisfies the lock.
Redeem Script
In P2SH, the script whose HASH160 appears in the output; revealed at spend time and then executed.
Witness Script
In P2WSH, the script whose SHA256 is committed in the output; placed at the end of the witness stack.
Script Execution
Sequential stepping through opcodes, mutating the stack until either a valid truthy stack remains or the script fails.