The Attachment Problem

Suppose that in the early days of email, a faction had grown worried about protocol purity. Email exists to replace paper correspondence. It carries messages cheaply and globally, and its usefulness depends on staying focused on that job. Then someone invents the file attachment.

The purists object. Attachments consume bandwidth and storage out of all proportion to a letter. They can carry photographs, software, databases, pornography, pirated books, or anything else expressible in bytes. An email system that turns into a general file-transfer system may stop working well as mail. Compliant servers, they propose, should reject attachments.

The difficulty arrives immediately. An attachment is data. Encode the file as text, paste it into the message body, and the rule is satisfied while the file arrives intact. Prohibit that encoding and there is another. Wherever a protocol lets the sender choose enough bits freely, those bits carry whatever the sender wants them to carry.

The purist concedes as much: attachments cannot be stopped completely, but servers should at least reject the obvious ones.

That concession is close to the position BIP-110 ended up defending.

Keeping Bitcoin pure

BIP-110, the Reduced Data Temporary Softfork, proposed a year of tightened consensus rules aimed at the many ways arbitrary data can be packed into Bitcoin transactions. It came out of the long dispute over inscriptions and other uses of blockspace that are not payments.

Its rules are syntactic. New output scripts longer than 34 bytes become invalid unless they begin with OP_RETURN, in which case 83 bytes are allowed. Data pushes and witness items are capped at 256 bytes. Taproot control blocks are bounded. Tapscripts containing OP_SUCCESS opcodes are invalid even when those opcodes never execute, and tapscripts that run OP_IF or OP_NOTIF are invalid regardless of which branch is taken.

OP_IF is a conditional. It has no more to do with images than a semicolon does. It appears on the list because the standard inscription envelope wraps its payload in an unexecuted OP_FALSE OP_IF block, which makes the opcode a reliable marker of a use someone wants gone.

The case for restriction goes well beyond distaste for JPEGs. Blockspace is scarce, and nodes bear real costs to validate, relay, sync, and often archive the chain. If those costs climb far enough, running an independent node becomes something only well-resourced operators do, and decentralization erodes with it. Any serious response to BIP-110 has to grant that.

The proposal answers that worry by regulating structures that correlate with a disfavored application. Bitcoin’s consensus rules can see syntax. They can tell an OP_RETURN output from a witness item, a signature from a script path, one transaction shape from another. They cannot see what any of it means. A string of bits might be a payment condition, a cryptographic commitment, a JPEG, a manifesto, an encrypted archive, or several of these at once, and nothing in validation discloses which. Checking structure and cryptographic conditions does not give a node access to intent.

Ban the encoding, keep the information

Restrictions of this kind are not nothing. Prohibit a convenient embedding method and that method stops working. Uses too marginal to justify a more expensive workaround disappear, because the effective price of storing data has gone up.

For everything else, the incentive simply moves. Users shift to encodings that remain valid and look less like what they are. Obvious encoding, restriction, alternative encoding, further restriction, and the alternatives grow steadily more disguised at every round. BIP-110’s own FAQ acknowledges the pattern: data can still be split into smaller pieces or disguised, such schemes are better handled in relay policy than in consensus, and the proposal never aimed to eliminate spam outright.

That is the objection, conceded in advance. The policy reduces to permit data when it serves an accepted financial function, reject it when the sender is really trying to store something else. Nodes are never asked to recognize a JPEG. They are asked to enforce a proxy, and each round of enforcement selects for whatever reproduces the same use through syntax the proxy misses.

The vocabulary is doing work the argument has not. “Spam” in email names a relation. It means unsolicited and bulk: cheap for the sender, costly for a recipient who never agreed to receive it, and nothing in the bytes decides it. Filtering targets that relation, which is why it weighs volume and reputation over content. An inscription is none of those things. Its creator pays the clearing price for the space it takes, and the miner who includes it accepts the trade. Strip out the relation and only the content type is left, the one dimension the original sense of the word never cared about.

The mail server faces this exactly. It can reject a MIME attachment. It cannot stop anyone from Base64-ing the same file into the body unless it begins chasing representations of content, at which point it has stopped eliminating attachments and started choosing which attachment encodings are convenient.

The result can be perverse. Transparent storage is easy to spot and gets restricted, while equivalent storage tucked inside plausible-looking transaction structures survives. The optimization target has shifted from do not store arbitrary data to store arbitrary data less legibly. Concealment is now subsidized. Whatever demand survives the price increase has been handed a reason to move into more complicated structures chosen precisely because they clear the rule. An email standard that banned attachments while leaving message bodies untouched would not put fewer files on the wire. It would produce uglier ones.

The script means the script

Pressed on whether users will simply spread payloads across multiple fields, the BIP grants that steganography cannot be prevented and argues that it need not be. Size limits force the data to be non-contiguous and to sit inside structures carrying some other intended meaning, and as far as Bitcoin is concerned that other meaning is what the bytes mean. The payload surfaces only under a reinterpretation performed elsewhere, by code that could in principle turn any data into any other data. Bitcoin’s meaning is well defined; the spammer’s is imposed from outside.

The claim is that consensus fixes meaning. A byte string forming a valid script means the script, whatever a decoder recovers downstream.

Run that argument on the mail server. A Base64 body is a well-formed sequence of ASCII characters, which is exactly what SMTP says it is, and the photograph appears only when a decoder outside the protocol reinterprets it. On this reasoning email has never transmitted an image, and the attachment problem was an illusion from the start. The argument establishes only that protocols have their own level of description, which nobody disputed. Costs attach to the substrate: every node downloads and validates the bytes, the network relays them, and archival nodes keep them for as long as the chain is served, none of which turns on which description is authoritative. Insisting that Bitcoin’s meaning is the real one leaves the consumption where it was, and leaves node operators hosting a JPEG that consensus has certified is a script.

Bitcoin is not email

Blockspace is far scarcer and costlier than mail storage, and the fee market does not internalize every downstream cost of data inclusion. A transaction pays once for inclusion, while the resulting chain growth imposes bandwidth, synchronization, and archival costs elsewhere in the network for as long as the chain is served. All true.

Arbitrary-data users still cannot manufacture blockspace. Capacity is fixed by consensus, so the chain has a hard ceiling on its growth rate whether blocks fill with payments, inscriptions, or both. BIP-110 does not lower that ceiling; it reallocates space beneath it.

Nor does anyone defending ordinary Bitcoin use hope that blocks stay empty. Payments filling every block would count as blockspace working, not as a storage emergency. The alarm sounds when the same bounded capacity is bought by the wrong buyer.

Displacement is what fee markets are for. If data users fill blocks, they bid against everyone else for fixed capacity and raise the price of it. Where fees fail to price some secondary externality, the fix is to identify and bound that resource directly. Maximum block weight is a resource rule. Bounded script execution is a resource rule. Anti-DoS limits are resource rules. Bitcoin has plenty of them, and they hold because they describe quantities a node can measure.

This use consumes too much of a scarce resource is an engineering claim. This use should not have access to the resource even under identical technical limits and at the same market price is a claim about desert, and it carries a hidden premise: that some purposes deserve Bitcoin’s scarce resources and others do not, independent of whether their users obey the same constraints and pay the same price. That is a claim about what Bitcoin is for.

Protocols do not have intentions

Successful protocols routinely outgrow what their designers had in mind. Email was for messages and acquired attachments, calendars, notifications, and authentication flows. HTTP was for retrieving hypertext documents and became the transport layer for most of modern computing. A protocol that can be composed in ways its designers never foresaw is a protocol that worked.

Which is why a protocol’s rules and its supposed purpose come apart. Rules are enforceable: a block may not exceed a weight, a script may consume only so much computation, a transaction must satisfy stated cryptographic conditions. Purpose is not, and a rule written to enforce one has to find something else to grip.

The coordination test

BIP-110 got an unusually concrete test. Its modified activation path asked for 55% miner signaling, 1,109 blocks out of 2,016. It received 51, roughly 2.53%, essentially all from a single pool. Mandatory signaling began at block 961,632 on 8 August 2026. Nodes enforcing the new rules rejected blocks that failed to signal, the rest of the network went on mining them, and the enforcing branch produced blocks 961,632 and 961,633 before stopping. Within a day the main chain was more than a hundred blocks ahead.

Hashpower does not settle whether a design is sound, and a two-block chain refutes nothing technical. The split measured something else: the distance between how loud a position is and how many people will pay to hold it. The constituency for enforcing Bitcoin’s intended purpose turned out to be far larger than the coalition willing to run a chain that did.

Nothing had stopped them from leaving. A chain with the desired rules has always been available. Writing the ruleset costs nothing and requires nobody’s permission; what it does not come with is the users, the liquidity, the hashpower, or the price. It would deliver everything the purity case asks for, permanently, with no threshold to clear and no expiry. The proposal was engineered instead to carry the existing chain along: a lowered signaling bar, a mandatory signaling window, grandfathered UTXOs so that no coin could be stranded. What the purists wanted was not a pure chain. It was this one.

BIP-110 is explicit that data users should take their content elsewhere, listing Nostr, IPFS and BitTorrent as the appropriate venues. The advice is good and runs in both directions with equal force, and both sides decline it for the same reason. The ruleset was never the scarce thing. A chain that sheds uses also sheds fees, security budget, and the monetary premium that made its blockspace worth fighting over, which is why the contested asset is always the ledger everyone else is already on.

Postscript

Bitcoin needs constraints. Validation cannot demand unlimited computation, blocks cannot grow without bound, nodes must survive denial-of-service attempts, and scarce resources need prices and ceilings. Rules of that kind describe what is being consumed, and a node can check them without knowing anything about why.

Trouble starts when a rule uses syntax to stand in for approved and disapproved meanings carried by the same substrate. Email did not stop being email when someone attached a photograph. The attachment used a general capability already latent in the protocol, and it made the system more useful. Bitcoin does not stop being a monetary network because people keep finding further things that fit inside a transaction.

If those uses cost too much, constrain the cost. If instead the rule holds that these bytes are fine for our purposes and not for yours, the protocol is being asked to enforce a distinction it cannot observe.

And whenever that happens, the attachment comes back as Base64.

Appendix: Bitcoin Has Already Run the Attachment Experiment

The attachment analogy is not merely hypothetical. Bitcoin has already encountered the same incentive problem repeatedly: restrict an obvious channel for arbitrary data, and users move the data into a less obvious channel that may be worse for the network.

OP_RETURN was a pressure valve

Before OP_RETURN became standard, protocols that wanted to commit arbitrary data to Bitcoin could disguise it inside outputs that looked spendable. That was especially undesirable because apparently spendable outputs could remain in the UTXO set, imposing a continuing state burden on validating nodes.

Bitcoin Core 0.9 therefore standardized small OP_RETURN outputs in 2014. The point was not to endorse blockchain data storage. It was to give unavoidable data a representation that could be recognized as provably unspendable and excluded from the UTXO set. Lopp describes it explicitly as a “pressure valve”: if users are going to put data on-chain anyway, give them a way to do so that damages the system less.

The alternative was exactly the attachment problem. Make transparent data carriage inconvenient and the bytes do not necessarily disappear. They migrate into structures intended for something else.

The same dynamic resurfaced in 2025. Bitcoin Core developers concluded that the roughly 83-byte OP_RETURN relay-policy limit was no longer preventing larger data commitments. Protocols such as Citrea were routing around it with less desirable constructions, including permanently unspendable outputs that burdened the UTXO set. Core 30 relaxed the relay restriction without changing consensus. The change reacted to data use that already existed rather than creating a new capability.

This is the subsidy for obfuscation in practice. Restrict the clean representation and sufficiently valuable uses select for dirtier ones.

BIP-110 had the same problem before it activated

BIP-110 did not need to activate for developers to demonstrate circumvention. Its own rationale acknowledged that arbitrary data could still be fragmented or disguised, and the broader debate produced working examples of data embedded in transactions that remained compatible with the proposed restrictions.

That matters because the relevant claim was never that every BIP-110 rule was ineffective. Restricting a particular syntax really does make that syntax unavailable. The question is what happens to the underlying application.

Bitcoin’s history gives a consistent answer:

restrict one representation → users find another → the restriction increasingly selects for concealment rather than absence.

BIP-110 therefore confronted the same problem as the hypothetical mail server. Rejecting MIME attachments is technically easy. Preventing arbitrary files from being represented inside otherwise valid messages is another problem entirely.

Transparent data can be cheaper than disguised data

The distinction between “monetary” and “non-monetary” data also fails as a proxy for resource cost.

An explicit OP_RETURN output is visibly unspendable. Nodes do not need to retain it in the UTXO set. Data disguised inside transaction structures that appear spendable can impose a greater persistent state burden even though the syntax looks more like an ordinary financial transaction. Lopp notes that this resource asymmetry was part of the original reason for introducing OP_RETURN and part of the later argument for relaxing its relay limits.

So the supposedly purer representation can be the more expensive one.

This reverses the intuitive argument for semantic restriction. If the objective is to minimize node costs, the network should prefer representations that expose their resource characteristics clearly. Penalizing conspicuous arbitrary data can instead push the same information into structures that are harder to identify and more costly to maintain.

The engineering question is therefore not:

Is this transaction really being used for money?

It is:

What measurable resources does this transaction consume?

Bitcoin can answer the second question. It cannot reliably answer the first.

Consensus and policy are different tools

Bitcoin also developed an institutional compromise around precisely this distinction. For years, consensus rules remained relatively permissive while node relay and standardness policies could discourage transaction forms without making them globally invalid. Miners ultimately decided what entered blocks, while fees priced scarce blockspace and relay policy handled local network-abuse concerns.

That separation matters. Relay policy can change as circumvention strategies and network conditions change. Consensus rules are vastly more expensive to reverse and determine whether nodes remain on the same chain at all.

BIP-110 attempted to move restrictions motivated by application-level use into consensus. Yet its own acknowledgment that disguised data remains possible illustrates why such heuristics fit poorly there. A syntactic proxy whose effectiveness depends on how adversaries currently encode information is exactly the sort of rule likely to require continual adaptation.

The fork result

The eventual fork also warrants one correction to the main text. The BIP-110 branch did not stop after two blocks. It ultimately produced four blocks, all reportedly mined by a small miner identifying itself as Roughnecks. OCEAN was the only mining pool publicly supporting BIP-110, but the four blocks themselves came from Roughnecks.

That changes none of the governance argument. The branch still failed almost immediately as an economically viable alternative. But the factual record should say four blocks, not two.

Bitcoin has therefore run the attachment experiment more than once. Transparent data channels were restricted, users routed around the restrictions, and developers sometimes responded by reopening the cleaner channel because the workaround was worse.

The attachment did not disappear.

It came back as Base64.