A Bitcoin developer embedded a 66-kilobyte picture inside a single transaction with out utilizing OP_RETURN or Taproot.
The transaction adopted consensus guidelines. Anybody can confirm the bytes utilizing customary node software program. Martin Habovštiak did not do that to make artwork, however to show that closing one information doorway would not take away the aptitude, it simply modifications the place bytes conceal.
The demonstration lands amid Bitcoin’s most contentious governance combat in years. One faction desires stricter filters to maintain “spam” off the blockchain.
One other argues that harsh restrictions push folks into worse behaviors and benefit giant miners. Habovštiak’s experiment supplies proof for the second place: filtering redirects fairly than stopping them.
What truly occurred
Habovštiak’s write-up features a transaction ID and verification methodology.
Customers can run bitcoin-cli getrawtransaction, then xxd -r -p to reconstruct the file. The development avoids the 2 pathways most cited in information storage debates: the OP_RETURN area that Bitcoin Core not too long ago relaxed, and Taproot’s witness construction that enabled many inscriptions.
Bitcoin transactions are bytes. Nodes implement that bytes comply with structural guidelines, akin to legitimate signatures, correct formatting, and legit spending situations.
They do not implement that bytes “imply cash solely.” If somebody constructs legitimate transaction bytes that additionally kind a legitimate picture file, the community shops and relays them.
Bitcoin can discourage sure information patterns via software program defaults. It can not stop them with out straight confronting miners’ financial incentives.
The excellence no person explains
Bitcoin operates with two layers of guidelines. Consensus guidelines decide what blocks are legitimate. Coverage guidelines decide what transactions particular person nodes relay and what miners usually settle for into mempools by default.
| Rule layer | What it controls (plain English) | What it will probably’t assure | Why it issues right here |
|---|---|---|---|
| Consensus guidelines | What makes blocks/tx legitimate | Can’t implement “money-only which means” | If it’s legitimate, it may be mined |
| Coverage / standardness | What nodes relay / mempools settle for by default | Could be bypassed | Filters add friction, not certainty |
| Miners’ inclusion | What will get into blocks | Incentives override preferences | Charges can “purchase” inclusion |
| Direct submission pipelines | Bypasses relay community | Concentrates entry | “Pay-to-play” danger (Slipstream-type routes) |
Coverage can sluggish habits, increase friction, and impose prices. It can not assure prevention if a transaction stays consensus-valid and pays ample charges.
Miners can embrace any consensus-valid transaction, particularly when it reaches them via paths that bypass common node relay.
OP_RETURN dimension limits have all the time been coverage decisions, not consensus partitions. Bitcoin Core has traditionally handled these as standardness nudges, with builders arguing that harsh limits push folks into worse encodings, akin to stuffing information into outputs that seem spendable, bloating the UTXO set that each node should keep.
Habovštiak’s demonstration makes this summary argument concrete. Cap one methodology, and engineering effort flows towards one other.
The pay-to-play downside
Even when many nodes refuse to relay “non-standard” transactions, financial incentives create workarounds. Mining swimming pools settle for transactions straight, bypassing the relay community. Providers explicitly launched for this exist already.
MARA’s Slipstream operates as a direct submission pipeline for “giant or non-standard” transactions that nodes typically exclude from mempools even after they comply with consensus guidelines. The service routes round defaults fairly than breaking guidelines.
This creates a centralization vector that stricter filters could amplify. When common nodes will not relay sure transaction varieties, solely miners and specialised providers can reliably land them in blocks.
At 10 satoshis per digital byte, one megabyte of blockspace prices roughly 0.1 BTC. At 50 satoshis per byte, roughly 0.5 BTC. The “ban” query turns into “what’s going to folks pay?”
BIP-110 and the governance battlefield
The demonstration arrives as Bitcoin debates BIP-110, a proposal to quickly limit data-carrying transaction fields on the consensus degree for roughly one yr.
| Subject / space | What BIP-110 proposes (plain English) | What it’s making an attempt to stop | Predominant tradeoff / danger |
|---|---|---|---|
| New output scripts | New scriptPubKeys > 34 bytes invalid (besides OP_RETURN allowance) | Knowledge stuffed into outputs | Danger of pushing information elsewhere |
| OP_RETURN exception | OP_RETURN allowed as much as 83 bytes | Small provable notes | Critics: nonetheless doesn’t “ban information” |
| Payload limits | Caps sure pushed information components (normal 256-byte ceiling with exceptions) | Giant embedded blobs | Workarounds could emerge |
| Witness stack components | Limits witness factor sizes (normal 256 bytes) | Inscription-style payloads | May redirect to worse encodings |
| Length framing | Momentary (~1 yr) | Tactical slowdown | Implies “no clear everlasting repair” |
| Second-order impact | If information shifts into UTXO-like outputs | Keep away from long-term node burden | Backfire danger: UTXO bloat will increase |
The draft would make new output scripts exceeding 34 bytes invalid, apart from OP_RETURN outputs, which may be as much as 83 bytes. It additionally proposes limits on payload sizes and witness stack components, typically capping them at 256 bytes with slim exceptions.
Supporters body BIP-110 as a measure that protects node operators from runaway storage prices.
Critics warn about negative effects and implementation dangers. The proposal represents an escalation from policy-level filtering to consensus-level restriction, a shift carrying governance implications past the speedy technical query.
Habovštiak’s experiment feeds straight into this debate. It demonstrates that even consensus restrictions face stress to adapt. He notes BIP-110 may invalidate his particular building, but additionally that he may produce options utilizing completely different encodings.
The underlying dynamic persists: squeeze one sample, and incentives plus ingenuity push information elsewhere.
The momentary framing, one yr fairly than everlasting, acknowledges this actuality implicitly. A everlasting change would require confronting tougher questions concerning the sustainability of enforcement.
A brief measure admits the issue could lack a clear technical answer, solely tactical administration with a restricted shelf life.
The worst-behavior downside
Proscribing widespread information pathways can backfire by pushing utilization towards encodings that impose larger community prices.
When builders create outputs that look spendable to hold arbitrary information, they improve the UTXO set, which is the database of unspent outputs each full node should keep in accessible storage.
UTXO progress represents a extra persistent burden than witness information or OP_RETURN payloads, which may be pruned. An output that encodes a picture file stays within the UTXO set till somebody spends it, probably indefinitely.
The node value accumulates fairly than growing old away.
This explains Bitcoin Core’s historic reluctance to impose harsh limits on OP_RETURN. The choice is not essentially higher. Filters that appear protecting can improve long-term working prices for nodes, undermining the decentralization aim they intention to protect.
Three paths ahead
The enforcement economics recommend three eventualities.
The primary path maintains the established order: worth it, do not ban it. Arbitrary information persists, ruled primarily by charge markets. When blockspace turns into scarce, data-heavy transactions are naturally priced out. The lever turns into financial fairly than technical.
The second path tightens coverage filters whereas leaving consensus unchanged. Knowledge shifts towards harder-to-filter encodings and direct-to-miner submission. Centralization danger rises as a result of solely miners and specialised pipelines can reliably verify these transactions.
The third path implements consensus restrictions, akin to these outlined in BIP-110. Well-liked patterns could quickly decline, however adaptation continues as new encodings emerge. Collateral harm will increase if limits push information into outputs that bloat the UTXO set.
Governance danger escalates as contentious consensus modifications increase coordination challenges and the potential for community splits.
What decides the end result
Three indicators sign which situation materializes.
First, miner habits. Do mining swimming pools proceed accepting non-standard transactions via direct channels? Providers like Slipstream exist particularly for this, as their sustained operation reveals miner priorities.
Second, governance trajectory. Does BIP-110 collect significant adoption past debate? The proposal requires coordinated activation throughout a decentralized community, making political viability as necessary as technical advantage.
Third, second-order results. Do restrictions push extra information into encodings that improve node burden? UTXO progress charges throughout coverage tightening durations would offer empirical proof.
The uncomfortable actuality
For those who oppose on-chain information storage past monetary transactions, Habovštiak’s demonstration delivers an uncomfortable message: you in all probability cannot ban it.
You’ll be able to worth it via charge markets. You’ll be able to discourage it via coverage defaults. You’ll be able to increase friction via implementation complexity.
However full prevention requires both accepting financial constraints you can not management or implementing consensus restrictions that carry their very own dangers.
Bitcoin validates transaction construction, not which means. The protocol would not distinguish between “cash transactions” and “information transactions” as a result of that distinction requires interpretation that the community can not carry out.
The true debate is not whether or not Bitcoin can technically stop arbitrary information, because the demonstrated reply is “not simply, and maybe in no way.”
The talk is which tradeoffs the community accepts: centralization towards miners who bypass filters, governance danger from contentious consensus modifications, or larger long-term prices from worse encoding decisions.
Habovštiak’s picture proves the filters do not work as marketed. What comes subsequent is determined by whether or not Bitcoin’s customers and builders settle for that actuality or proceed pursuing technical options to what more and more seems to be an financial and governance downside.
