The Attachment Problem

BIP-110 and the limits of protocol purity

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.