OP_EQUAL - Byte-for-Byte Equality

1. OP_EQUAL — Byte-for-Byte Equality

Overview

OP_EQUAL is one of the most fundamental and frequently used opcodes in the Bitcoin Script language. It performs a precise, byte-for-byte comparison of the top two items on the stack and returns a boolean result. Unlike high-level language equality operators that may perform type coercion, implicit conversions, or semantic comparisons, OP_EQUAL is ruthlessly literal — if every single byte of the two items does not match exactly, the result is false.

Opcode value: 0x87 Hex: 87

How It Works

When OP_EQUAL is executed by the Bitcoin Script interpreter, it pops the two topmost elements from the stack, compares them byte by byte, and pushes either 0x01 (true) or 0x00 (false) back onto the stack. The stack is not terminated — execution continues, and the result can be used by subsequent opcodes.

Stack before: [ <item_A> <item_B> ]
                               ↑ top
OP_EQUAL executes:
  - Pops item_B (top)
  - Pops item_A
  - Compares byte-by-byte
  - Pushes 0x01 if equal, 0x00 if not

Stack after: [ <0x01 or 0x00> ]

A Concrete Script Example

Consider a simple Pay-to-Script-Hash (P2SH) style verification where a preimage is checked against a known hash commitment:

scriptPubKey:
  OP_HASH256 <expected_hash> OP_EQUAL

scriptSig:
  <preimage>

Combined execution:

Stack: [ ]

OP_HASH256 → Stack: [ HASH256(preimage) ]
  <expected_hash> pushed → Stack: [ HASH256(preimage) <expected_hash> ]
  OP_EQUAL → Stack: [ 0x01 ]  (if match)

In this pattern, OP_EQUAL is the final arbiter — it decides whether the provided preimage hashes to what was committed. If the result is 0x01, and the script evaluation concludes here, the transaction is valid (because the final stack item is truthy).

Byte-for-Byte Semantics

The phrase "byte-for-byte" deserves careful emphasis. Bitcoin Script items on the stack are raw byte arrays. They have no inherent type. A number, a hash, a public key, a signature — all are just sequences of bytes at the stack level. OP_EQUAL does not care about any semantic meaning. It just checks:

• Are the lengths the same?

• Is every byte at every index identical?

If both answers are yes → 0x01. Otherwise → 0x00.

Example 1: Trivially equal
  Item A: 0xDEADBEEF
  Item B: 0xDEADBEEF

Result: 0x01

Example 2: Different lengths
  Item A: 0xDEAD
  Item B: 0xDEADBEEF

Result: 0x00

Example 3: Same length, different bytes
  Item A: 0xDEADBEEF
  Item B: 0xDEADBEF0

Result: 0x00

Example 4: Empty items (both empty byte arrays)
  Item A: 0x (empty)
  Item B: 0x (empty)

Result: 0x01 ← both empty, trivially equal

Numeric Representation Pitfall

One of the most important subtleties of OP_EQUAL relates to how numbers are represented on the Bitcoin Script stack. Bitcoin Script uses a variable-length little-endian encoding called CScript integer encoding (also called minimally-encoded integers or Script number encoding). The number 1 can be represented as 0x01. The number 256 is 0x0001. But due to this variable-length encoding, the same integer might have multiple valid byte representations depending on how it was pushed or computed.

Consider the integer 0 (zero):
  Representation A: 0x (empty byte array)  ← canonical zero in Script
  Representation B: 0x00                    ← a byte array containing a zero byte

OP_EQUAL comparison:
  Item A: 0x   (empty, CScript zero)
  Item B: 0x00 (single zero byte)

Result: 0x00 ← NOT EQUAL! They are different byte arrays.

OP_NUMEQUAL comparison:
  Same items, treated as integers → both represent 0

Result: 0x01 ← EQUAL numerically

This is a critical distinction that has been the source of bugs and confusion in Script development. OP_EQUAL would report them as unequal, while OP_NUMEQUAL would report them as equal. Choosing the wrong opcode can lead to scripts that are permanently unspendable.

Role in Standard Transaction Types

OP_EQUAL appears prominently in P2SH (Pay-to-Script-Hash) outputs:

P2SH scriptPubKey:
  OP_HASH160 <20-byte-script-hash> OP_EQUAL

Spending flow:
  1. scriptSig provides <serialized_redeem_script> and other data
  2. OP_HASH160 hashes the serialized redeem script
  3. OP_EQUAL checks if the hash matches the commitment
  4. (P2SH validation then separately executes the redeem script)

In the BIP16 P2SH specification, the final OP_EQUAL does not immediately terminate execution — the P2SH validation layer adds an additional step where the redeem script itself is deserialized and executed. But at the raw Script level, OP_EQUAL simply compares and pushes a boolean.

Error Conditions

OP_EQUAL will cause script failure if there are fewer than two items on the stack when it executes. This results in an immediate script failure and transaction invalidity.

Error case:

Stack: [ ]

OP_EQUAL → Script fails: stack underflow

Summary

OP_EQUAL is the backbone of hash-commitment-based Bitcoin contracts. It is simple, deterministic, and operates entirely on raw byte arrays. Its lack of type awareness is both its strength (predictability) and its danger (easy to misuse with numeric values).