The Default Is the Message

Editor’s note: This is the first piece in an ongoing FF2K investigation. We are not endorsing BIP-110, Bitcoin Core’s OP_RETURN policy change, Bitcoin Knots, or the CAPTURE thesis. We are mapping the incentives, evidence, and governance questions behind the fight.

Bitcoin is having a fight about bytes, which means Bitcoin is not really having a fight about bytes.

The visible argument is about OP_RETURN, Bitcoin Core v30, Bitcoin Knots, and BIP-110, a proposed temporary soft fork that would restrict several ways people embed arbitrary data into Bitcoin transactions. That version of the story is technical enough to make normal people leave the room and political enough to keep Bitcoin people screaming in it.

The cleaner summary goes like this: Bitcoin Core changed its default relay policy so larger and multiple OP_RETURN outputs are standard by default. BIP-110 supporters say that change normalized spam and pushed Bitcoin toward becoming a generic data-storage layer. BIP-110 opponents say the proposal is a dangerous censorship fork wrapped in anti-spam language.

Both sides have a point. Both sides also have incentives. Convenient how that works.

The deeper fight is over defaults. Not consensus, not exactly. Defaults. Bitcoin Core did not make large OP_RETURN transactions valid. They were already valid under consensus rules. Core changed what its dominant implementation would relay and mine by default. That sounds boring until you remember that defaults are how most users experience power.

Relay policy may not be consensus, but defaults are propaganda with a config file.

WHAT CHANGED

Bitcoin Core PR #32406, opened by Greg Sanders and merged by Gloria Zhao on June 9, 2025, changed Bitcoin Core's default OP_RETURN relay policy. In Bitcoin Core v30, `-datacarriersize` defaults to `100,000`, which the release notes describe as effectively uncapping the old limit because the maximum transaction size limit is hit first. Multiple OP_RETURN outputs are now permitted for relay and mining. Users who want the prior behavior can set `-datacarriersize=83`.

That is the Core-side factual baseline. This was not a consensus change. A transaction that was valid before remained valid after. A block containing those transactions was not made valid by Core v30. What changed was standardness: whether Bitcoin Core's default policy treats those transactions as normal enough to relay.

The distinction matters, but it does not end the argument.

Core defenders frame the change as harm reduction. Their view is that if people are going to put data on Bitcoin anyway, OP_RETURN is one of the least bad places to put it. OP_RETURN outputs are provably unspendable and do not enter the UTXO set. If relay policy refuses those transactions, users can still go around public relay through miners, private submission services, alternate relay software, or worse transaction patterns that create spendable-looking junk outputs every node must track.

That is not a crazy argument. In fact, it is probably the strongest argument Core has.

MARA's Slipstream service is a useful exhibit. Launched in 2024, Slipstream lets users submit large or non-standard Bitcoin transactions directly to MARA's mining infrastructure. That is the world Core developers are pointing at: if public relay refuses consensus-valid transactions that miners will mine anyway, block inclusion starts to look less like a public network and more like business development.

But the critic's answer is also strong: if nonstandard OP_RETURN use was already rare, why move the dominant default to 100,000 bytes? Why not keep the old limit, improve documentation, or move in smaller steps? Why did the compromise preserve the knob but change the default?

There it is. The whole fight in miniature.

User choice still exists. Default authority moved.

WHAT BIP-110 TRIES TO DO

BIP-110, also called the Reduced Data Temporary Softfork, is a draft consensus soft fork by Dathon Ohm. It proposes a temporary, roughly one-year restriction on several forms of arbitrary data embedding.

The core restrictions include:

BIP-110 would do several things: new output scripts over 34 bytes would be invalid, except OP_RETURN outputs up to 83 bytes; pushed data and witness items over 256 bytes would be invalid, with limited exceptions; undefined witness or Tapleaf versions would be restricted during deployment; Taproot annexes, large Taproot control blocks, OP_SUCCESS opcodes, and executed OP_IF / OP_NOTIF in Tapscripts would be restricted.

BIP-110's public site frames the proposal as a temporary correction to distorted incentives and a way to refocus Bitcoin on its purpose as sound, permissionless money.

Supporters see this as an emergency brake. They argue that Bitcoin should be money first, not a settlement layer for Runes, Ordinals, BRC-20s, bridges, image blobs, or whatever the next speculative circus calls itself after a branding consultant has a rough weekend.

Opponents see BIP-110 as something else: a consensus-level attempt to censor transactions based on subjective purpose. Jameson Lopp's critique argues that BIP-110 is technically brittle, politically dangerous, and carries chain-split risk. He also argues that Bitcoin's neutrality is not a slogan; it is the thing that lets enemies use the same money without asking permission.

This is the cleanest version of the split:

BIP-110 supporters think Bitcoin needs an immune response.

BIP-110 opponents think that immune response looks a lot like autoimmune disease.

THE DATA DOES NOT GIVE EITHER TRIBE A PARADE

If you want the simple Twitter version, stop here. Core normalized spam. BIP-110 is censorship. Pick a flag, yell at strangers, become content.

The data is more irritating than that.

Mempool Research's OP_RETURN report says nonstandard OP_RETURN usage has not increased since Bitcoin Core v30. It also says most recent OP_RETURN outputs were already standard under pre-v30 policy. Recent OP_RETURN activity was mostly tied to Runes, and those Runes outputs were largely standard under the old rules. The largest recent nonstandard OP_RETURN byte-volume spike happened in May 2025, before v30.

That hurts the easy anti-Core claim that v30 immediately opened a giant OP_RETURN floodgate.

It also hurts the easy Core claim that the default change had an obvious urgent harm-reduction payoff. If nonstandard OP_RETURN usage was tiny and already not rising, critics can reasonably ask: what exact harm required changing the default now?

Core's best answer is not about OP_RETURN counts alone. It is about UTXO bloat and private miner paths.

Mempool Research's UTXO Set Report, using a snapshot at block 892,385 on April 14, 2025, found 173,190,861 UTXOs and an approximately 11 GB disk footprint under default compaction/indexing settings. It reported that 49.1% of all UTXOs held less than 1,000 sats, mostly Taproot, likely related to data embedding schemes, inscriptions, or ordinal-theory transfer schemes. It also notes that OP_RETURN outputs never enter the UTXO set.

That is the harm-reduction case with teeth. Fake spendable outputs are not just ugly. They create state that every node has to carry until those outputs are spent, which some may never be.

The block-size picture adds another wrinkle. Mempool Research's block-size report says average chain growth accelerated from 1.11 MB per block after SegWit up to block 770,000, to 1.69 MB per block after block 770,000, a 52% increase. It ties the jump to sustained block-space demand and inscriptions.

So yes, arbitrary data demand is real. Yes, node burden is real. Yes, OP_RETURN is cleaner than fake UTXOs. And yes, a 100,000-byte default in the reference client still sends a social signal.

If you came here for a team sport, sorry. Reality is being rude again.

CAPTURE CHANGES THE SUBJECT

Hodlonaut's CAPTURE series is important because it changes the question.

It is not merely an argument that the OP_RETURN merge was wrong. It is an argument that the merge exposed how informal power works around Bitcoin Core: funding networks, contributor status, maintainer discretion, moderation, social legitimacy, and the difference between having an opinion and having a merge button.

That is a more dangerous frame for Core than "this policy was bad."

Bad policy can be defended, reverted, revised, or contextualized. A legitimacy crisis is stickier. Once users believe the room is managed, every merge looks like a meeting they were not invited to.

Hodlonaut's Article Three launch post described CAPTURE as "an investigation across four articles into how informal power over Bitcoin Core was assembled, exercised, and defended." That is not OP_RETURN analysis. That is a power map.

The Core-side response is predictable and not entirely wrong: Bitcoin Core is an open-source project, not a parliament. Technical review is not supposed to become a referendum every time Twitter gets mad. If non-contributors can veto changes through outrage, then Core development becomes hostage to whoever can assemble the loudest mob.

But the critic's response is also not wrong: when one implementation dominates the network, its defaults are not ordinary software preferences. They become the closest thing Bitcoin has to an official recommendation, even if everyone involved insists there is no such thing.

That is the governance smell.

Bitcoin has no CEO, no board, no legislature, no formal constitutional court. Excellent. Very decentralized. Now who decides what ships in the dominant client?

The answer is not "nobody."

EVERYBODY HAS AN ANGLE

The phrase sounds cynical. It is not. Incentives are not proof of corruption. They are the weather system around every decision.

Core contributors and maintainers have incentives. They want Bitcoin to remain neutral, technically coherent, and resistant to subjective transaction filtering. They do not want policy knobs that miners route around anyway. They do not want public relay weakened while private miner submission becomes the premium lane. They also do not want GitHub review reduced to a vibes-based plebiscite.

That is the best version.

The risk is that this becomes a priesthood problem. A technical culture can be open in theory and socially closed in practice. If enough users believe their objections only count when translated into the dialect of Core review, then "open source" starts to feel like a velvet rope.

BIP-110 supporters have incentives too. They want Bitcoin to be money, not a catch-all data layer. They want to force a referendum on Core defaults. They want to make node adoption and UASF pressure a counterweight to maintainer authority. Some also want to litigate Taproot, inscriptions, and what counts as a bug versus a permitted use of script.

That is the best version.

The risk is that purity turns into a loaded gun. A controversial soft fork with low miner support is not a blog post. It can create chain-split risk, wallet risk, market confusion, and reputational damage even if the people pushing it believe they are defending Bitcoin.

Miners have an angle. Fees are fees. Direct submission services create relationships and revenue. But miners also do not want to be seen as the casino bouncers for Bitcoin data spam if the social consensus turns against them.

Ordinals, Runes, and data-protocol builders have an angle. They want access to block space and resistance to rule changes that kill their products. They are also convenient villains, and convenient villains are narrative candy. Bad for your teeth.

Funders and developer institutions have an angle. Brink, Chaincode, OpenSats, Spiral, Blockstream, and other pieces of the funding ecosystem all sit near the question CAPTURE is poking: does professionalized Bitcoin development make Core stronger, or does it concentrate legitimacy inside a socially aligned class?

Careful here. Funding ties are not corruption receipts. Guilt by association is cheap, and cheap work is how bad journalism gets made. But funding and status do shape incentives. If Bitcoiners are not allowed to ask how, then the decentralization branding department is getting high on its own supply.

THE HARD QUESTION FOR EACH SIDE

For Core defenders, the hard question is this:

If the old OP_RETURN limits were ineffective and nonstandard OP_RETURN usage was already tiny, why did the default need to change to 100,000 bytes?

Not why was it technically defensible. It was. Not why is OP_RETURN cleaner than UTXO junk. It is. Why that default, in that dominant implementation, amid that level of public opposition?

For BIP-110 supporters, the hard question is this:

If data demand mutates around restrictions, and if miner support remains low, why risk a consensus fight that may fail or split legitimacy without clearly solving the problem?

Not why is arbitrary data annoying. It is. Not whether Bitcoin should prioritize money. It should. Why this soft fork, with these Taproot restrictions, on this timeline?

Those are the interviews that matter.

Ask Core what metric would prove the OP_RETURN change worked: fewer fake-output UTXOs, less private submission, better compact block reconstruction, better fee estimation, something else?

Ask BIP-110 proponents what metric would prove success: lower chain growth, lower UTXO growth, lower fees, fewer inscriptions, or simply a cultural reset?

Ask miners how much nonstandard transaction volume they see through private channels. Ask Mempool Research for reproducible data. Ask funders what influence means when influence is informal. Ask everyone what evidence would change their mind.

Then watch who answers the question and who recites the brand statement.

THE DEFAULT IS THE MESSAGE

The mistake is treating "policy versus consensus" as the end of the conversation.

It is the start.

Bitcoin Core can say, accurately, that relay policy is local. Nodes can configure their own limits. Miners can mine any consensus-valid transaction. Users can run Knots. Nobody has to run Core.

But defaults are how power hides in plain sight. Most people do not run custom policy. Most people do not inspect GitHub review threads. Most people experience Bitcoin through defaults chosen by someone else.

That does not mean Core is captured. It means Core is powerful enough that people will fight over whether it is captured.

BIP-110 may be a bad idea. It may be technically brittle. It may be too aggressive. It may be the wrong tool for the wrong fight at the wrong time.

Bitcoin Core's OP_RETURN change may also be technically reasonable, publicly documented, and still politically combustible because the default did more than relay transactions. It told users what the reference client considered normal.

That is the story.

Bitcoin's spam war is really a fight over defaults, legitimacy, and who gets to call their incentives "technical."

Everybody says they are protecting Bitcoin.

The useful question is from whom, and at what price.

HELP US REPORT THIS

FF2K is looking for primary sources and on-record interviews from Bitcoin Core contributors involved in PR #32406, BIP-110 supporters and critics, Bitcoin Knots users and operators, miners and mining pools, Mempool/data researchers, wallet developers, node operators, funders, and Ordinals/Runes/data-protocol builders.

We are especially interested in reproducible OP_RETURN, UTXO, and witness-data analysis; direct miner submission data; Core PR review process details; funding or institutional influence claims; technical cases for or against BIP-110; and evidence that would change your mind.

Contact FF2K with the subject line: BIP-110 / OP_RETURN. Bring receipts. Screenshots are nice; primary sources are better.

SOURCE NOTES

Primary source bundle: Bitcoin Core 30.0 release notes; Bitcoin Core PR #32406; BIP-110 specification and public site; Jameson Lopp’s BIP-110 critique; Mempool Research OP_RETURN, UTXO Set, and Block Size reports; MARA Slipstream announcement; hodlonaut / Total Knot CAPTURE Articles One, Two, and Three.

- Trent Jones