Bitcoin Spam - Why We Can't Stop It

Not all data on Bitcoin is equal — and you can’t fully stop arbitrary data from landing on-chain. Where it goes (UTXO set, witness, or OP_RETURN) changes the cost to nodes. Here’s the map, the myths, and the trade-offs.

Start with data paths Why it can’t be stopped Key takeaways

01 · Anatomy

Where data can live in a transaction

A Bitcoin transaction has inputs, outputs, and (with SegWit) a separate witness area. People have used all three places to embed data. Select each path below to see where it sits and why the cost to the network differs.

⛓

A Bitcoin transaction

txid · simplified view

Select a data path below to highlight it
Inputs
prevout
UTXO being spent…
scriptSig / witness
signatures · unlock data
Outputs
vout 0 · payment
P2WPKH / P2TR · spendable
vout 1 · fake pubkey / dust
looks spendable · stays in UTXO set
vout n · OP_RETURN
provably unspendable · prunable

Relative long-term cost to nodes

Rough comparison of ongoing burden — not fee cost to the sender. Fees and incentives are a separate story.

UTXO set spam
Highest
Witness data
Moderate
OP_RETURN
Lowest

02 · Policy, not consensus

Core v30 did not “blow open” OP_RETURN

A common claim is that Bitcoin Core version 30 suddenly allowed huge data dumps for the first time. The reality is quieter and more technical: it changed default relay policy, not the consensus rules that define what is a valid Bitcoin block.

The myth

“v30 opened the floodgates to unlimited spam”

The story goes that a hard limit was protecting Bitcoin, and Core removed it — so now the chain will fill with junk that was previously impossible.

  • Implies consensus rules changed
  • Implies large OP_RETURNs were impossible before
  • Implies miners and nodes all enforced one shared “ban”
The reality

Default policy shifted after the old norm had already eroded

Bitcoin has always allowed large OP_RETURN data at the consensus level (bounded by transaction and block size). The old ~80-byte figure was a standardness / relay default — a gentleman’s agreement among many nodes, not a law of the protocol.

  • Miners could always include non-standard transactions in blocks
  • Large OP_RETURNs were already being relayed and mined in practice
  • v30 mostly aligns default relay with what the network was already doing

OP_RETURN standardized as a safer data outlet

Core 0.9 encouraged OP_RETURN so people would stop stuffing unspendable fake outputs into the UTXO set. A small default size limit was a mild deterrent, not a consensus cap.

The “gentleman’s agreement” frays — on chain

For years the largest OP_RETURN in each window sat near the old ~80-byte relay norm. Then large OP_RETURNs began landing in blocks well before Core v30 — via miners and non-default relay paths. The informal filter was no longer a reliable gate.

Default datacarrier policy relaxed

Default -datacarriersize rose dramatically (on the order of 100 KB aggregate), and multiple OP_RETURN outputs became standard for relay. Operators can still configure policy. Consensus limits (block weight, tx size) remain the real ceiling.

Evidence: large OP_RETURNs were already being mined

Charts from Bitcoin Core contributor L0rinc (@L0RINC) plot the largest unspendable OP_RETURN in successive block windows. The takeaway is chronological: the spikes show up in the data before the v30.0 release line — so the policy change followed existing usage rather than inventing it.

“Bitcoin Core v30’s OP_RETURN policy change isn’t obvious to many: it didn’t create large OP_RETURN usage, it reacted to usage that already existed by removing a gate that wasn’t actually working.”

Chart: Largest unspendable OP_RETURN scriptPubKey size by block height, log scale. Flat near 80 bytes for years, then large spikes from 2024, with Core v30.0 release marked after that pre-existing usage.
Largest OP_RETURN per block window (log scale) After early experiments, max sizes hug the old ~40–80 byte norms for years. From roughly block 800k+ (2024), multi‑kilobyte and larger OP_RETURNs appear repeatedly — still left of the dashed “Core v30.0 release” line (2025‑10‑13). Large payloads were already in blocks before the default policy change.
What the Y-axis shows Largest unspendable OP_RETURN scriptPubKey size in each ~2,016-block window — not total OP_RETURN volume. Spikes mean “someone got a very large one mined,” which is enough to show the gate was permeable.
What “gate” means Default standardness (~80 bytes) mostly governed relay among default Core nodes. Miners (and alternate relay) could still include non-standard transactions. Once that path was in regular use, the sticker on the door was not the real constraint.
Why this matters Debates about v30 often treat the old limit as if it still defined what could land on chain. Chain data shows otherwise: the gentleman’s agreement had already failed in practice before the default was updated.
📜

Consensus vs policy

Consensus decides what blocks are valid for everyone. Policy decides what your node relays and mines by default. Confusing the two leads to overstated claims about “opening” the network.

⛏️

Miners already had the last word

If a miner is paid enough, non-standard transactions can land in a block. Relay defaults only slow propagation; they do not rewrite economic reality. The charts above are what that looks like in practice.

🔧

Nodes still choose

Individual operators can tighten or loosen filters. v30 changes the default shipped by Core — it does not force every node into one configuration forever.

03 · Impossibility

You can’t stop spam on Bitcoin

A widespread misconception is that “spam” is mainly a software-governance problem: if Core developers (or node runners) would only lock down the right fields, large or contiguous data could be kept off the chain. That is not how a programmable money protocol works. It is not merely hard to stop arbitrary data — it is impossible without breaking Bitcoin’s ability to verify payments.

The misconception

“Engineers can just ban the data fields”

If we restrict OP_RETURN, ban inscription envelopes, shrink push sizes, or filter “weird” scripts, the story goes, spam disappears. The remaining problem is only political will among developers.

  • Treats data embedding as one feature to turn off
  • Assumes each new filter closes the book permanently
  • Misses that money already is structured bytes
The reality

Valid payments are already arbitrary bytes

Every transaction is data. Pubkeys, hashes, scripts, signatures, and witness stacks are long strings of bytes that nodes must accept if they satisfy consensus rules. Anyone who can arrange those bytes can encode images, text, or other payloads — without a special “spam API.”

  • Many independent embedding techniques exist
  • Banning one path shifts demand to others
  • Workarounds are often more harmful to nodes

Common ways people embed data

These are not exotic exploits. They are rearrangements of fields Bitcoin already needs for payments, contracts, and script flexibility.

Witness · medium harm

Taproot / inscription envelopes

Ordinals-style inscriptions hide payloads in witness data inside a script path that is revealed when spent. Large blobs can ride along with a payment — and large ones were already standard to relay. See the inscriptions section →

UTXO · worst harm

Fake pubkeys & fake hashes

Encode data as if it were a public key or script hash. Outputs look potentially spendable, so nodes keep them in the UTXO set. This is among the worst places for spam: permanent, shared database cost.

Scripts · variable

Script & witness packing

Push large chunks into scripts, split across inputs, or arrange stack items so that after a trivial transform you recover a file. Consensus still sees “a script,” not “an image ban.”

UTXO · worst harm

Dust & unspendable-looking outputs

Many tiny or trick outputs can carry structured data while bloating the UTXO set. Filters that push users here make the node cost worse, not better.

Format games

Contiguous packing tricks

Clever layout can make long runs of payload bytes sit contiguously in the serialized transaction — even when people claim “Bitcoin doesn’t allow contiguous data” outside narrow cases.

OP_RETURN · least harm

Explicit data outputs

Provably unspendable, prunable, not kept as coins. Still uses block space — but avoids the permanent UTXO tax. This is the least bad slot if data will be written anyway.

Demonstration: contiguous image on-chain

knotslies.com documents a mainnet proof: more than 66 kB of contiguous image data (a TIFF) embedded in a transaction — without relying on the usual “this is the one spam feature” story.

Open knotslies.com →
Payload ~66 kB contiguous TIFF; the raw transaction bytes are the image file
Not OP_RETURN No OP_RETURN required — banning it would not have blocked this construction
Not Taproot Uses SegWit v0 paths, not an “inscription-only” Taproot trick
Verifiable Anyone can pull the raw tx from their own node and open it as a TIFF

The point is not the image content. The point is structural: if someone can park a contiguous multi‑dozen‑kilobyte file in payment-shaped data, then debates that treat spam as “one opcode we forgot to lock” are missing the design of the system.

You can verify on a node with something like: bitcoin-cli getrawtransaction <txid> | xxd -r -p > file.tiff — hex decode only, no special “extract spam” tool. Details and the exact txid are on the site.

Because

Spam cannot be eliminated

Too many byte paths; each ban is a temporary detour, not a permanent wall.

Therefore

Where it lands matters

Pushing users into fake keys or UTXO junk taxes every node forever.

So

Prefer the least harmful slot

If data will be written anyway, OP_RETURN is the least bad place — prunable, not a coin.

🎯

Harm reduction, not celebration

Preferring OP_RETURN is not saying “fill the chain with files.” It is saying: we do not want spammers forced into the worst possible place (UTXO-set pollution and other forever-cost tricks). When demand for on-chain data exists, policy that only blocks the clean outlet often increases total harm. The realistic goal is to keep monetary use primary via fees and block space — and, when data appears, to keep it out of the UTXO set.

04 · Witness data

Inscriptions: the elephant already in the room

Long before debates about Core v30 and larger OP_RETURN defaults, Bitcoin already had a widely used path for putting large files on-chain: inscriptions, typically via the Taproot inscription envelope. Understanding that path is essential — because much of the “OP_RETURN will open the floodgates” anxiety ignored what was already standard, already relayed, and already used at massive scale.

📦

What an inscription is

In the usual Ordinals-style construction, arbitrary data (images, text, JSON, etc.) is placed in the witness of a Taproot script-path spend, wrapped in a recognizable “envelope” of opcodes (often described as an OP_FALSE OP_IF … OP_ENDIF-style pattern with an ord marker). When the input is spent, that witness data is published on-chain as part of a normal-looking payment flow.

⚖

Why it scales so large

Witness data is discounted in the block weight rules (the so-called witness discount / non-witness penalty). Combined with standard transaction size limits, that made very large payloads practical — on the order of ~400 kB for a single inscription transaction under standard relay rules — without needing a special OP_RETURN policy change.

🖼️

It already happened at scale

Millions of inscriptions — including vast numbers of images — have already been written to the chain using this method. This is not a hypothetical future risk invented in 2025. It is established usage that miners included and the network stored for years.

The double standard

“100 kB OP_RETURN is the crisis”

Much of the post-v30 rhetoric treated a higher default OP_RETURN carrier size (on the order of 100 kB aggregate) as if it were a sudden opening of Bitcoin to large data.

  • Focuses on one data outlet (OP_RETURN)
  • Sounds like a new capability the network never had
  • Often skips what was already standard in the witness
What was already true

~400 kB inscriptions were already standard to relay

Even prior to Core v30, inscription-sized witness payloads up to roughly 400 kilobytes could already propagate as standard transactions under ordinary relay policy — constrained mainly by standard transaction weight/size, not by the old ~80-byte OP_RETURN culture.

  • Larger than the OP_RETURN default people fretted about
  • Already used for millions of on-chain images and files
  • Lived in witness data (not the UTXO set forever like fake keys)
Inscriptions (pre-v30, standard)
~400 kB

Typical upper end for a large standard inscription-style witness payload under existing size/weight limits — already relayed and mined at scale.

OP_RETURN debate (v30)
~100 kB

Order of magnitude of the OP_RETURN default people treated as catastrophic — while a larger, already-standard witness path had been in production for years.

Figures are approximate and about policy/weight ceilings, not a promise every inscription is 400 kB. The comparison is about what the network would already relay.

Would BIP-110 “fix inscriptions”?

Proposals like BIP-110 aim to constrain popular data patterns at the consensus layer (push sizes, certain Taproot structures, and so on). Even if such rules activated, they would not end witness data carrying — they would mainly force a format change.

Target Today’s recognizable envelope and large contiguous pushes become harder or invalid under the proposed rules
Response Inscribers change the script layout — split pushes, different opcodes, other witness packing — same payload in the witness
Extra cost On the order of ~0.4–0.5% more data/overhead in adapted schemes — not a meaningful deterrent
Stated intent Some inscription / data protocols have already said they would adapt cheaply if filters or soft-fork limits land

If the goal is “no large files in blocks,” a small encoding tax does not get you there. People who already pay blockspace fees for images will pay half a percent more. If the goal is “don’t force data into worse places,” then chasing one witness envelope while leaving demand intact is the same cat-and-mouse problem described in you can’t stop spam.

Witness inscriptions are still generally less harmful than UTXO-set spam — but fretting over a 100 kB prunable OP_RETURN while shrugging at a larger, already-standard witness market is an inconsistent standard of “what actually matters.”

Already true

~400 kB witness data

Standard-relay inscriptions predate the OP_RETURN panic — and were used millions of times.

Limits adapt

BIP-110 ≠ end of spam

Change the envelope; keep the witness. ~0.5% extra cost is not a stop sign.

Consistent view

Judge by harm, not brand

Compare UTXO vs witness vs OP_RETURN — not “feels like spam” vs “has a protocol name.”

05 · Harm reduction

Why OP_RETURN is the least harmful place for data

Preferring OP_RETURN is not the same as celebrating blockchain storage. Given that spam cannot be fully stopped, it is harm reduction: if data will be written anyway, channel it where nodes pay the smallest long-term cost — not into the UTXO set.

1

It is prunable

Because the output is provably worthless as a coin, software can drop the attached data after the block is validated. Pruned nodes and archival policies can treat it differently from spendable outputs. Fake-key UTXO spam cannot be pruned the same way — nodes must keep tracking those “coins.”

2

The script interpreter does not read the payload as code

OP_RETURN fails the script immediately. Everything after it is data, not a program the node must carefully execute. That makes the output’s meaning unambiguous: this is not money waiting to be spent.

3

It does not bloat the UTXO set

The UTXO set is the hot path of Bitcoin validation. Keeping it lean matters for decentralization — smaller machines can still run full nodes. OP_RETURN was introduced in the first place so data would not live forever in that set.

scriptPubKey · simplified 
// A normal payment output (spendable → UTXO set)
OP_DUP OP_HASH160 <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIG

// An OP_RETURN data output (unspendable → not a UTXO)
OP_RETURN <your bytes here>
// ↑ interpreter stops · output is provably dead · prunable
⚠

Least harmful ≠ free

OP_RETURN still uses block space and bandwidth. It competes with payments for limited capacity. “Least harmful” describes node database cost, not a free pass for unlimited junk.

🎯

Incentives still rule

If OP_RETURN is restricted too tightly while demand for data exists, users route around it — often into worse patterns. Policy that ignores incentives can increase harm, not reduce it.

06 · Propagation

The limits of filtering

A misconception shared by users of both Bitcoin Core and Bitcoin Knots is that default mempool filters can effectively stop “spam” from spreading across the network and reaching miners. That picture is incomplete — and Libre Relay is one clear reason why.

The misconception

“My node’s filters keep spam off the network”

If enough people run Core or Knots with strict defaults, the story goes, non-preferred transactions never propagate. Miners never see them. Problem solved at the edge.

  • Treats your local policy as a global firewall
  • Assumes one client’s defaults define the whole graph
  • Ignores peers that deliberately relay more liberally
The reality

Relay is a graph — not a single switch

Bitcoin’s peer-to-peer network is a mesh. Transactions only need some path from the sender toward miners. A minority of well-connected nodes with looser policy can carry traffic that stricter nodes refuse to forward.

  • Filters shape your mempool and what you relay
  • They do not rewrite other people’s software
  • Once a miner has the tx, default filters elsewhere no longer matter for inclusion
🔀

What Libre Relay is

Libre Relay is a fork of Bitcoin Core by Peter Todd. It removes many of the restrictive standardness filters that default Core (and stricter setups like Knots) use, and it preferentially peers with other Libre Relay nodes so those transactions keep a reliable path through the network.

📡

Why a small set of nodes is enough

You do not need majority adoption. A handful of well-connected Libre Relay nodes can accept a non-default transaction, gossip it among themselves, and hand it off to ordinary peers — including Core and Knots nodes that will at least learn about or forward related traffic depending on policy — until it reaches miners willing to include it.

🧱

Filters still do something local

Running filters is not “fake.” They control your bandwidth, mempool, and what you help relay. The limit is claiming they can unilaterally decide what the whole network can carry when alternative relay paths exist.

How a filtered transaction still moves

Simplified view: Libre Relay keeps a preferential backbone so non-default txs are not stuck behind a wall of default drop policies.

Libre Relay Core (default) Knots Miner
LR
Accepts & relays
LR
Preferential peer
LR
Preferential peer

↓ preferential peering · small well-connected set

LR
Talks to everyone

↓ public P2P — not miner-only

Core
May drop on policy
Knots
Stricter filters
Mine
Can include if paid
Step 1

Tx enters Libre Relay

A transaction that default Core or Knots would reject is accepted by a Libre Relay node.

Step 2

Preferential peering

It hops across other Libre Relay nodes that deliberately stay connected to each other — a backbone for non-default policy.

Step 3

Reaches the broader network

Those nodes also talk to ordinary peers. The transaction is not sealed inside a private miner pipe; it propagates on the public P2P graph.

Step 4

Miners can pick it up

Any miner (or template provider) that sees and accepts it can include it. Default filters elsewhere do not veto the block.

💬

Not “just direct miner submission”

A common talking point is that Libre Relay is merely a fancy way to submit transactions straight to miners. That understates how it works. Libre Relay nodes connect to and propagate transactions across the broader peer-to-peer network — including toward regular Bitcoin Core and Knots nodes — not only down a private line to a pool. Preferential peering among Libre Relay nodes makes that path reliable; it does not mean the rest of the network is bypassed entirely.

⚖

What this means for the spam debate

Arguments that treat default filters as a network-wide kill switch overstate their power. Filters are local preferences. As long as alternative relay software and economic demand exist, strict defaults alone cannot guarantee that certain transaction types never reach a block.

🧩

Core, Knots, and Libre Relay

Core ships one set of defaults. Knots often ships stricter ones. Libre Relay ships looser ones with preferential peering. Users can choose any of them — but no single choice rewrites everyone else’s mempool. That plurality is why “just filter harder” is not a complete network strategy.

07 · Summary

What actually matters

  • ✓ Location beats volume slogans. A megabyte in the UTXO set is a different problem from a megabyte in a prunable OP_RETURN or a witness blob.
  • ✓ UTXO bloat is the structural worst case — permanent, shared, and paid by every full node forever.
  • ✓ Inscriptions already put large data on-chain. Taproot envelopes allowed on the order of ~400 kB under standard relay before Core v30 — while much of the panic focused on ~100 kB OP_RETURN. Millions of images were already inscribed.
  • ✓ BIP-110-style limits do not end inscriptions. Change the witness script layout; keep the payload. Stated workarounds cost on the order of ~0.4–0.5% extra — not a deterrent.
  • ✓ You cannot engineer spam out of Bitcoin. Payments are bytes; inscriptions, fake keys, script packing, and demos like the ~66 kB contiguous TIFF on knotslies.com show data will find a path.
  • ✓ OP_RETURN is the least harmful data slot when data is going on-chain: prunable, non-executable tail, no UTXO entry — better than driving users into worse workarounds.
  • ✓ Core v30 is a policy default change after large OP_RETURNs were already being mined (see the on-chain charts). The old informal limit had stopped working as a global filter. Consensus rules about max block size did not suddenly vanish.
  • ✓ Default filters are not a network firewall. Libre Relay (and similar paths) show that a minority of well-connected peers can still propagate transactions stricter nodes drop — including across the public P2P graph, not only via private miner submission.
  • ✓ Fees and block space remain the real scarce resource. Technical filters can nudge local behavior; they cannot repeal demand, alternative relay, or miner incentives.