OP_PUSHDATA4 - Pushing Up to 4GB (Theoretical)
6. OP_PUSHDATA4 — Pushing Up to 4GB (Theoretical)
Overview
OP_PUSHDATA4 is the largest push opcode in Bitcoin Script, capable of specifying a data length of up to 2^32 - 1 bytes (approximately 4 gigabytes). It occupies opcode byte 0x4e and uses a 4-byte little-endian length field. In any practical sense, this opcode is entirely theoretical — Bitcoin's consensus rules make it impossible to use for any meaningful data push under current protocol rules.
Opcode Format
Format: 0x4e <length:4 bytes little-endian> <data:length bytes>
Theoretical push of 70000 bytes (0x00011170 = 0x70 0x11 0x01 0x00):
0x4e 0x70 0x11 0x01 0x00 <70000 bytes of data>
Theoretical maximum push (4GB - 1 byte):
0x4e 0xFF 0xFF 0xFF 0xFF <4294967295 bytes>
Why It Is Purely Theoretical
Bitcoin's consensus rules make OP_PUSHDATA4 effectively unusable for large data:
Constraint 1 - Stack element size limit:
Maximum bytes in a single stack element: 520 bytes
(enforced since Bitcoin 0.3.x, consensus-critical)
Constraint 2 - Script size limit:
Maximum bytes in any script: 10,000 bytes
Constraint 3 - Transaction size limit:
Maximum standard transaction: 100,000 bytes (standardness)
Maximum consensus transaction: ~1MB (block weight limit)
Constraint 4 - Minimal push rule (BIP 62):
OP_PUSHDATA4 should only be used for lengths > 65535
But element size cap is 520 bytes — contradiction
Given these constraints, OP_PUSHDATA4 cannot legally push any data without violating the 520-byte element size limit. If a script contains OP_PUSHDATA4 with a length ≤ 65535, it violates BIP 62. If it specifies any length > 520, it violates the element size consensus rule. There is no valid intersection.
Historical Presence
OP_PUSHDATA4 exists because Satoshi designed the original Script with a maximalist push API that covered the entire 32-bit address space. At Bitcoin's genesis, the element size limits that make this opcode impossible to use had not yet been established. The opcode was included "just in case" larger pushes were ever needed.
Interpreter Implementation
// From src/script/interpreter.cpp
case OP_PUSHDATA4: {
if (pc + 4 > pend)
return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
nSize = ReadLE32(&pc[0]); // Read 4-byte little-endian length
pc += 4;
break;
}
// Then the general size check:
if (nSize > MAX_SCRIPT_ELEMENT_SIZE) // MAX_SCRIPT_ELEMENT_SIZE = 520
return set_error(serror, SCRIPT_ERR_PUSH_SIZE);
The interpreter reads the 4-byte length field successfully, but then immediately fails the MAX_SCRIPT_ELEMENT_SIZE check if the specified length exceeds 520 bytes — which it always will if using OP_PUSHDATA4 in a BIP 62-compliant manner.
Summary Table: Push Opcode Comparison
Opcode Byte Length Field Max Push Practical Max
OP_0 0x00 none 0 bytes 0 bytes
Direct push 0x01-0x4b implicit 75 bytes 75 bytes
OP_PUSHDATA1 0x4c 1 byte 255 bytes 255 bytes (but ≤520)
OP_PUSHDATA2 0x4d 2 bytes 65535 bytes 520 bytes
OP_PUSHDATA4 0x4e 4 bytes ~4GB UNUSABLE (theoretical)
TeachMeBitcoin is an ad-free, open-source educational repository curated by a passionate team of Bitcoin researchers and educators for public benefit. If you found our articles helpful, please consider supporting our hosting and ongoing content updates with a clean donation: