Bitcoin developer hides a 66KB image in a transaction to expose a governance blind spot vulnerable to spam
تكنلوجيا اليوم
2026-03-01 15:45:00
A Bitcoin developer embedded a 66-kilobyte image inside a single transaction without using OP_RETURN or Taproot.
The transaction followed consensus rules. Anyone can verify the bytes using standard node software. Martin Habovštiak didn’t do this to make art, but to prove that closing one data doorway doesn’t remove the capability, it just changes where bytes hide.
The demonstration lands amid Bitcoin’s most contentious governance fight in years. One faction wants stricter filters to keep “spam” off the blockchain.
Another argues that harsh restrictions push people into worse behaviors and advantage large miners. Habovštiak’s experiment provides evidence for the second position: filtering redirects rather than preventing them.
What actually happened
Habovštiak’s write-up includes a transaction ID and verification method.
Users can run bitcoin-cli getrawtransaction, then xxd -r -p to reconstruct the file. The construction avoids the two pathways most cited in data storage debates: the OP_RETURN field that Bitcoin Core recently relaxed, and Taproot’s witness structure that enabled many inscriptions.
Bitcoin transactions are bytes. Nodes enforce that bytes follow structural rules, such as valid signatures, proper formatting, and legitimate spending conditions.
They don’t enforce that bytes “mean money only.” If someone constructs valid transaction bytes that also form a valid image file, the network stores and relays them.
Bitcoin can discourage certain data patterns through software defaults. It cannot prevent them without directly confronting miners’ economic incentives.
The distinction nobody explains
Bitcoin operates with two layers of rules. Consensus rules determine what blocks are valid. Policy rules determine what transactions individual nodes relay and what miners typically accept into mempools by default.
| Rule layer | What it controls (plain English) | What it can’t guarantee | Why it matters here |
|---|---|---|---|
| Consensus rules | What makes blocks/tx valid | Can’t enforce “money-only meaning” | If it’s valid, it can be mined |
| Policy / standardness | What nodes relay / mempools accept by default | Can be bypassed | Filters add friction, not certainty |
| Miners’ inclusion | What gets into blocks | Incentives override preferences | Fees can “buy” inclusion |
| Direct submission pipelines | Bypasses relay network | Concentrates access | “Pay-to-play” risk (Slipstream-type routes) |
Policy can slow behavior, raise friction, and impose costs. It cannot guarantee prevention if a transaction remains consensus-valid and pays sufficient fees.
Miners can include any consensus-valid transaction, especially when it reaches them through paths that bypass regular node relay.
OP_RETURN size limits have always been policy choices, not consensus walls. Bitcoin Core has historically treated these as standardness nudges, with developers arguing that harsh limits push people into worse encodings, such as stuffing data into outputs that appear spendable, bloating the UTXO set that every node must maintain.
Habovštiak’s demonstration makes this abstract argument concrete. Cap one method, and engineering effort flows toward another.
The pay-to-play problem
Even when many nodes refuse to relay “non-standard” transactions, economic incentives create workarounds. Mining pools accept transactions directly, bypassing the relay network. Services explicitly launched for this already exist.
MARA’s Slipstream operates as a direct submission pipeline for “large or non-standard” transactions that nodes often exclude from mempools even when they follow consensus rules. The service routes around defaults rather than breaking rules.
This creates a centralization vector that stricter filters may amplify. When regular nodes won’t relay certain transaction types, only miners and specialized services can reliably land them in blocks.
At 10 satoshis per virtual byte, one megabyte of blockspace costs approximately 0.1 BTC. At 50 satoshis per byte, roughly 0.5 BTC. The “ban” question becomes “what will people pay?”
BIP-110 and the governance battlefield
The demonstration arrives as Bitcoin debates BIP-110, a proposal to temporarily restrict data-carrying transaction fields at the consensus level for approximately one year.
| Field / area | What BIP-110 proposes (plain English) | What it’s trying to prevent | Main tradeoff / risk |
|---|---|---|---|
| New output scripts | New scriptPubKeys > 34 bytes invalid (except OP_RETURN allowance) | Data stuffed into outputs | Risk of pushing data elsewhere |
| OP_RETURN exception | OP_RETURN allowed up to 83 bytes | Small provable notes | Critics: still doesn’t “ban data” |
| Payload limits | Caps certain pushed data elements (general 256-byte ceiling with exceptions) | Large embedded blobs | Workarounds may emerge |
| Witness stack elements | Limits witness element sizes (general 256 bytes) | Inscription-style payloads | Might redirect to worse encodings |
| Duration framing | Temporary (~1 year) | Tactical slowdown | Implies “no clean permanent fix” |
| Second-order effect | If data shifts into UTXO-like outputs | Avoid long-term node burden | Backfire risk: UTXO bloat increases |
The draft would make new output scripts exceeding 34 bytes invalid, except for OP_RETURN outputs, which can be up to 83 bytes. It also proposes limits on payload sizes and witness stack elements, generally capping them at 256 bytes with narrow exceptions.
Supporters frame BIP-110 as a measure that protects node operators from runaway storage costs.
Critics warn about side effects and implementation risks. The proposal represents an escalation from policy-level filtering to consensus-level restriction, a shift carrying governance implications beyond the immediate technical question.
Habovštiak’s experiment feeds directly into this debate. It demonstrates that even consensus restrictions face pressure to adapt. He notes BIP-110 could invalidate his specific construction, but also that he could produce alternatives using different encodings.
The underlying dynamic persists: squeeze one pattern, and incentives plus ingenuity push data elsewhere.
The temporary framing, one year rather than permanent, acknowledges this reality implicitly. A permanent change would require confronting harder questions about the sustainability of enforcement.
A temporary measure admits the problem may lack a clean technical solution, only tactical management with a limited shelf life.
The worst-behavior problem
Restricting popular data pathways can backfire by pushing usage toward encodings that impose higher network costs.
When developers create outputs that look spendable to carry arbitrary data, they increase the UTXO set, which is the database of unspent outputs every full node must maintain in accessible storage.
UTXO growth represents a more persistent burden than witness data or OP_RETURN payloads, which can be pruned. An output that encodes an image file remains in the UTXO set until someone spends it, potentially indefinitely.
The node cost accumulates rather than aging away.
This explains Bitcoin Core’s historical reluctance to impose harsh limits on OP_RETURN. The alternative isn’t necessarily better. Filters that seem protective can increase long-term operating costs for nodes, undermining the decentralization goal they aim to preserve.
Three paths forward
The enforcement economics suggest three scenarios.
The first path maintains the status quo: price it, don’t ban it. Arbitrary data persists, governed primarily by fee markets. When blockspace becomes scarce, data-heavy transactions are naturally priced out. The lever becomes economic rather than technical.
The second path tightens policy filters while leaving consensus unchanged. Data shifts toward harder-to-filter encodings and direct-to-miner submission. Centralization risk rises because only miners and specialized pipelines can reliably confirm these transactions.
The third path implements consensus restrictions, such as those outlined in BIP-110. Popular patterns may temporarily decline, but adaptation continues as new encodings emerge. Collateral damage increases if limits push data into outputs that bloat the UTXO set.
Governance risk escalates as contentious consensus changes raise coordination challenges and the potential for network splits.
What decides the outcome
Three indicators signal which scenario materializes.
First, miner behavior. Do mining pools continue accepting non-standard transactions through direct channels? Services like Slipstream exist specifically for this, as their sustained operation reveals miner priorities.
Second, governance trajectory. Does BIP-110 gather meaningful adoption beyond debate? The proposal requires coordinated activation across a decentralized network, making political viability as important as technical merit.
Third, second-order effects. Do restrictions push more data into encodings that increase node burden? UTXO growth rates during policy tightening periods would provide empirical evidence.
The uncomfortable reality
If you oppose on-chain data storage beyond financial transactions, Habovštiak’s demonstration delivers an uncomfortable message: you probably can’t ban it.
You can price it through fee markets. You can discourage it through policy defaults. You can raise friction through implementation complexity.
But full prevention requires either accepting economic constraints you cannot control or implementing consensus restrictions that carry their own risks.
Bitcoin validates transaction structure, not meaning. The protocol doesn’t distinguish between “money transactions” and “data transactions” because that distinction requires interpretation that the network cannot perform.
The real debate isn’t whether Bitcoin can technically prevent arbitrary data, as the demonstrated answer is “not easily, and perhaps not at all.”
The debate is which tradeoffs the network accepts: centralization toward miners who bypass filters, governance risk from contentious consensus changes, or higher long-term costs from worse encoding choices.
Habovštiak’s image proves the filters don’t work as advertised. What comes next depends on whether Bitcoin’s users and developers accept that reality or continue pursuing technical solutions to what increasingly appears to be an economic and governance problem.
