Bitcoin OP_RETURN Data Storage: The 80-Byte Limit and the Push for Arbitrary Data

Bitcoin's OP_RETURN opcode was designed as a pressure valve: a way to embed small amounts of data in transactions without permanently bloating the UTXO set. For over a decade, Bitcoin Core enforced an 80-byte standardness limit on OP_RETURN outputs, restricting what the peer-to-peer relay network would propagate. That limit was effectively removed in Bitcoin Core v30.0, released on October 10, 2025, triggering one of the most heated governance debates in Bitcoin's history.

This article traces the full arc: why OP_RETURN exists, how the 80-byte limit was set, how Ordinals and BRC-20 rendered it irrelevant, and the philosophical battle between those who view Bitcoin as money and those who see it as a general-purpose data layer.

Why OP_RETURN Exists

Before OP_RETURN became a standard transaction type, users were already embedding data in Bitcoin transactions. The most common methods involved encoding arbitrary bytes into fake public key hashes or abusing opcodes like OP_CHECKMULTISIG to stuff data into multisig scripts. These outputs looked like normal payments but were actually unspendable, because no one held private keys corresponding to the fabricated addresses.

The problem was the UTXO set. Every unspent transaction output must be tracked by every full node, typically in RAM for fast validation. Fake addresses created permanent entries in this set because nodes had no way to know the outputs were unspendable. As more protocols embedded data this way, the UTXO set grew with entries that would never be spent.

OP_RETURN solved this by making outputs provably unspendable. Bitcoin Script immediately halts execution when it encounters OP_RETURN, so nodes know the output can never be spent and discard it from the UTXO set. The data still exists in the blockchain, but it does not impose an ongoing memory cost on nodes.

Key distinction: OP_RETURN data lives on the blockchain permanently but is prunable from the UTXO set. Fake-address data also lives permanently on the blockchain and consumes UTXO set memory indefinitely. OP_RETURN is strictly less harmful to node operators.

History of the Size Limit

Bitcoin Core v0.9.0, released on March 19, 2014, introduced OP_RETURN as a standard transaction type. The release notes were explicit: "This change is not an endorsement of storing data in the blockchain." The initial limit was 40 bytes of data per output, deliberately restrictive.

From 40 to 80 bytes

The 40-byte limit was raised to 80 bytes in Bitcoin Core v0.11.0 (July 2015). This was sufficient for embedding cryptographic hashes (32 bytes for SHA-256), protocol identifiers, timestamps, and small metadata payloads. Protocols like Omni Layer (originally Mastercoin) used OP_RETURN extensively for token issuance, including Tether's original USDT on Bitcoin.

Bitcoin Core v0.12.0 (February 2016) further refined the limit to allow multiple data pushes within a single OP_RETURN output, with a total script size cap of 83 bytes (80 bytes of usable data plus 3 bytes of opcode overhead). This remained the default for nearly a decade.

Policy vs. consensus: a critical distinction

The 80-byte limit was never a consensus rule. It was a standardness policy: a set of local rules that Bitcoin Core nodes apply when deciding whether to accept a transaction into their mempool and relay it to peers. Any transaction violating policy is simply not forwarded, but it remains perfectly valid at the consensus level. If a miner includes a non-standard transaction in a block, every node on the network will accept that block without complaint.

This distinction matters because it means the 80-byte limit was always a soft deterrent, not a hard cap. Anyone with a direct relationship to a mining pool could submit arbitrarily large OP_RETURN transactions and have them mined. Services like Marathon Digital's Slipstream explicitly offered this, creating a two-tier system where well-connected actors bypassed limits that constrained ordinary users.

How Ordinals and BRC-20 Bypassed the Limit

The debate over OP_RETURN's size limit became largely academic after January 2023, when Ordinals Inscriptions demonstrated that witness data offered a far more efficient vector for on-chain data embedding.

The inscription mechanism

Inscriptions embed arbitrary data (images, text, HTML, video) in the witness portion of Taproot (P2TR) transactions. The technique uses a two-phase commit-reveal process. The commit transaction creates a Taproot output committing to a script that contains the data. The reveal transaction spends that output via the script path, forcing the full inscription data to appear in the witness stack.

The data itself is wrapped in an OP_FALSE OP_IF ... OP_ENDIF envelope inside the Taproot script. Because OP_FALSE ensures the OP_IF block is never executed, the envelope is a no-op from Script's perspective. But the data is permanently recorded on-chain in the witness.

Why Taproot enabled this

Two protocol changes converged to make inscriptions possible. SegWit (August 2017) introduced the witness discount, making witness data four times cheaper than non-witness data in terms of block weight. Non-witness data costs 4 weight units per byte; witness data costs just 1. This means a block can accommodate approximately 4 MB of witness data versus roughly 1 MB of non-witness data.

Taproot (activated November 2021) removed the 10,000-byte script size limit for Tapscript, allowing script-path spends to contain much larger scripts. Combined with the witness discount, this created an avenue for embedding up to approximately 4 MB of data per block at a fraction of the cost of OP_RETURN embedding.

The cost paradox: OP_RETURN data sits in non-witness space, costing 4 weight units per byte and capped at 80 bytes by policy. Inscription data sits in witness space at 1 weight unit per byte with no practical size limit. The "restricted" method was four times more expensive per byte than the unrestricted alternative.

BRC-20 tokens

BRC-20, introduced by pseudonymous developer Domo in March 2023, built a fungible token standard on top of inscriptions. Tokens are managed by inscribing JSON data onto individual satoshis. Three operations define the protocol: deploy (create a token with name, max supply, and mint limit), mint (issue tokens), and transfer (move tokens between addresses).

Unlike ERC-20 on Ethereum, BRC-20 has no on-chain smart contract logic. Off-chain indexers parse inscription JSON to reconstruct balances and validate transfers. All data is stored in witness data via inscription envelopes, never touching OP_RETURN at all.

Comparing Data Embedding Approaches

Bitcoin now has several distinct vectors for embedding data on-chain, each with different cost profiles, storage characteristics, and impacts on node operators.

From a node operator's perspective, OP_RETURN and witness-based inscriptions are roughly equivalent: both occupy block space but do not inflate the UTXO set. The primary difference is cost: the witness discount makes inscriptions significantly cheaper per byte of data embedded.

The Taproot annex

Defined in BIP 341, the Taproot annex is an optional field in the witness structure of SegWit v1 inputs, identified by its first byte being 0x50. It currently has no defined purpose and was reserved for future protocol upgrades. All Taproot and Tapscript signatures must commit to the annex value if present.

Because the annex has no consensus-level size limit, it represents another potential vector for data embedding. Proposals have suggested using it for fee-dependent timelocks, template commitments, and replay protection. The annex became a point of contention in the data-filtering debate, with BIP 110 explicitly proposing to prohibit its use.

The Core v30 Change

The path to removing the OP_RETURN size limit was contentious and stretched across multiple years of debate.

The proposal timeline

In July 2023, developer Peter Todd submitted PR #28130 proposing removal of the OP_RETURN size limit from standardness policy. The PR was closed without merging. In April 2025, Todd revisited the idea with PR #32359, sparking intense debate. Critics accused Todd of quietly reintroducing a failed proposal. Developer Jason Hughes called for Todd's "excommunication" from Bitcoin development.

The change that was ultimately merged came through PR #32406, titled "uncap data carrier by default," merged on June 10, 2025 by maintainer Gloria Zhao. Gregory Sanders authored a supporting analysis document detailing the rationale.

What changed technically

Bitcoin Core v30.0, released October 10, 2025, made four key changes to OP_RETURN handling:

• The -datacarriersize default was raised from 83 bytes to 100,000 bytes, effectively bounded only by the standard transaction size limit
• Multiple OP_RETURN outputs per transaction became standard (previously only one was relayed)
• The -datacarrier flag was deprecated but remains functional for operators who want to disable OP_RETURN relay entirely
• Node operators retain full local control and can configure stricter limits via the same flags

The core argument from proponents was that the existing caps "pushed users toward more harmful, unprunable alternatives or direct miner submission," creating a policy that achieved the opposite of its stated goal. By making OP_RETURN the path of least resistance, data would flow into the most node-friendly format.

The Philosophical Divide

The OP_RETURN debate is a proxy for a deeper question about Bitcoin's identity. Two coherent but incompatible worldviews drive the dispute.

Bitcoin is money

The "monetary purist" position holds that Bitcoin's primary function is as sound money and that block space should be reserved for financial transactions. The most prominent advocate is developer Luke Dashjr, who maintains Bitcoin Knots, an alternative node implementation with stricter transaction filtering. Dashjr co-founded the OCEAN mining pool, which enforced data filters to reject inscriptions and large OP_RETURN outputs.

This camp views NFTs, inscriptions, and arbitrary data as "spam" that degrades Bitcoin's utility as a payment system. Developer Jimmy Song called the OP_RETURN limit removal something that would "age like a bad tattoo." The concern is not just philosophical: larger transactions compete for scarce block space, potentially driving up fees for ordinary financial transactions.

Bitcoin is a data layer

The pragmatist position holds that Bitcoin cannot and should not attempt to filter transaction content. Peter Todd, who led the push to remove limits, argued that the 80-byte cap was ineffective since users were already bypassing it through inscriptions and direct miner submission. Gregory Sanders framed the change as ensuring Bitcoin is "governed by transparent, minimal rules rather than editorial preference."

Gloria Zhao, the maintainer who merged the change, argued that existing limits created a "two-tier system" favoring well-connected actors with direct mining pool relationships over ordinary users. If data embedding is going to happen regardless, channeling it into the prunable, UTXO-friendly OP_RETURN format is better for the network than pushing it into witness data or fake addresses.

The Knots counter-movement

Bitcoin Knots' node share grew dramatically through 2025, reaching roughly 23-25% of public Bitcoin nodes by early 2026. The node implementation enforced a much stricter OP_RETURN limit of approximately 42 bytes, well below even the original 80-byte Core default. OCEAN mining pool's adoption of Knots-style filtering contributed to the growth.

BIP 110 and the Activation Attempt

The most aggressive response to Core v30 was BIP 110, a proposal for a temporary consensus-level soft fork restricting data embedding. Authored by Dathon Ohm with contributions from Luke Dashjr, the initial draft was completed on October 24, 2025, two weeks after Core v30's release.

What BIP 110 proposed

Unlike the old 80-byte policy rule, BIP 110 sought to impose consensus-level restrictions that no miner could bypass:

• OP_RETURN outputs limited to 83 bytes
• Data pushes and witness stack elements capped at 256 bytes
• Taproot annex usage prohibited
• Control blocks restricted to 257 bytes
• Various Tapscript opcodes (OP_SUCCESS variants, OP_IF/OP_NOTIF) restricted

The restrictions were designed to be temporary, active for approximately one year (52,416 blocks), with a reduced activation threshold of 55% miner signaling rather than the standard 95% used for permanent consensus changes.

The failed activation

BIP 110 entered its mandatory signaling period at block 961,632 in August 2026. Miner support peaked at 2.53%, with all 51 signaling blocks coming from OCEAN mining pool. On August 8, 2026, a brief chain split occurred when a small group mined 2 blocks on the BIP-110 chain before stopping. The fork stalled at block height 961,633 and never progressed further. Over 99% of hashrate remained on the main chain.

The aftermath was significant. On August 9, 2026, developer Mark Erhardt filed a motion to remove Luke Dashjr as a BIP editor, citing conflict of interest over BIP 110 and minimal editorial contributions. Dashjr's name was struck from BIP 3 (the editors list). He subsequently announced a sabbatical from OCEAN.

Implications for Block Space Economics

The removal of the OP_RETURN limit has direct implications for block space demand economics. With OP_RETURN data costing 4 weight units per byte versus inscription's 1 weight unit per byte, OP_RETURN embedding actually pays more fees per byte of data stored. From a fee market perspective, this benefits miners and contributes to Bitcoin's long-term security budget.

The counterargument is that any non-financial use of block space, regardless of fee contribution, competes with monetary transactions. In periods of high demand, data embedding can push fee rates above levels that make small-value payments uneconomical on the base layer. This dynamic strengthens the case for Layer 2 protocols that settle off-chain and minimize their on-chain footprint.

The pruning advantage: OP_RETURN outputs are discarded from the UTXO set and can be pruned by nodes running in pruned mode. Inscription witness data is similarly prunable after validation. Both are dramatically better than fake-address encoding, which creates permanent, unprunable UTXO entries.

Off-Chain Alternatives

The entire OP_RETURN debate underscores a fundamental tension in Bitcoin's design: the base layer has limited throughput, and every byte of data competes for the same scarce resource. Layer 2 protocols offer a way out of this zero-sum dynamic by moving activity off-chain while preserving Bitcoin's security guarantees for settlement.

Spark's statechain model avoids on-chain data bloat entirely. Off-chain transfers on Spark change who can authorize spending a UTXO without broadcasting any transaction to the blockchain. No data is embedded in outputs, witnesses, or annexes. Block space is consumed only when users enter or exit the protocol, preserving on-chain capacity for settlement transactions rather than data storage.

This approach sidesteps the OP_RETURN debate altogether. Rather than arguing about how much data should be allowed in blocks, protocols like Spark, Lightning, and Cashu reduce the demand for block space in the first place. The less block space Layer 2 users consume, the more capacity remains for settlement, anchoring, and whatever data embedding the market demands.

For developers building on Bitcoin, the Spark SDK provides tools for off-chain transfers, token issuance, and Lightning interoperability without requiring any on-chain data embedding. For a deeper comparison of scaling approaches, see our analysis of Bitcoin Layer 2 tradeoffs and rollup vs. state channel architectures.

Where the Debate Stands

As of late 2026, the practical question is settled: Bitcoin Core v30 ships with an effectively uncapped OP_RETURN limit, and the only consensus-level attempt to restrict data embedding (BIP 110) failed with minimal miner support. Node operators can still configure local policies, but the network-wide default permits large data payloads in OP_RETURN outputs.

The philosophical question remains unresolved. The purist camp argues that normalizing data storage erodes Bitcoin's monetary identity and sets a precedent for treating block space as cheap storage. The pragmatist camp argues that Bitcoin's censorship resistance means content filtering is inherently futile: users will always find the cheapest data embedding path, and policy should channel that behavior into the least harmful format.

What both sides agree on is that block space is finite and valuable. The disagreement is over who gets to decide how it is used: protocol developers setting policy defaults, miners selecting which transactions to include, or the fee market itself. Bitcoin's history suggests the fee market wins in the end.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.