Bitcoin developer and educator Jimmy Song has watched every major protocol fight in Bitcoin play out over the past decade. BIP-110, a proposal to restrict data embedding on the base layer while allowing the rule to expire after one year, initially looks like a narrow technical dispute about byte limits.

The conversation moves beyond byte limits to broader questions about how Bitcoin’s rules are decided, how decentralized governance operates in practice, and how the network handles disagreements when consensus is uncertain.

Why the Decision Process Around BIP-110 Matters More Than the 100,000 Byte Limit

The surface argument about BIP-110 is technical: should OP_RETURN, the Bitcoin output field designed for unspendable data, carry 80 bytes or 100,000 bytes? Bitcoin Core developers moved to raise the default relay limit. Opponents, led publicly by Luke Dashjr and others, pushed back hard. 

One camp wants no restrictions at all, arguing Bitcoin should remain neutral to all use cases. The other wants data embedding blocked entirely, arguing block space exists for monetary transactions and nothing else.

Song's objection lands somewhere different from both camps. 

How BIP-110 works: Simple restrictions that preserve all monetary use cases while limiting data abuse | Source: BIP-110.org

Song's objection is not to the 100KB limit itself, that remains in place. His objection is to how Core handled the user configuration option along the way. The sequence, as he describes it:

• Removed entirely: Core first took away the “-datacarriersize” option, meaning users could no longer set their own relay policy on their own node

• Deprecated: After pushback, the option was brought back but marked as deprecated meaning Core signalled it still intended to remove it in a future version, giving users the option back with, while reserving the right to take it away again

• Restored: The deprecated status was then reversed, returning the option to users.

Song highlighted that "their [Bitcoin Core's] first move was to remove the option altogether and make it so that users couldn't even set that, was highly controversial for a good reason. I think users like having the ability to restrict what gets relayed because it's their node. 

And then the next move was to just deprecate it and then finally take out the deprecated status of that feature. All those steps were backing off of the thing that they really wanted to do."

Bitcoin Core, BIP-110, and the Debate Over Who Controls Protocol Changes

Song found that "the developers basically said, if we believe as a developer community that this change is beneficial, then who cares what the users think. Which is, I think, not a great precedent. I think users should have a say in that." 

That Core eventually restored the option told Song something important about where power actually sits he explained how "I think that in that sense it was good because they [Bitcoin Core] were listening to users, because ultimately it's the users that run nodes." 

Jimmy Song on the 100KB Limit: “The Actual Change Isn’t That Big a Deal”

On the 100KB limit itself, Song is measured explaining how: "the actual change isn't that big a deal. You still have the four megabyte block weight limit. And so that means that at most it can be four megabytes, but that's highly unusual, you would need a very specific type of transaction. I think on average it's actually two megabytes. The bigger thing is the decision process around that."

What made the debate visible at all was not a formal announcement. 

It was Luke Dashjr and others starting to shout about it publicly. Song is candid that most Bitcoin users were not watching the GitHub issues and IRC channels where these discussions were happening:

Song commented "I don't think it was nearly as prominent until Luke and Mechanic sort of started shouting about it."

How Raising the Cost of Data Embedding Changes Behaviour: Even Without Eliminating It

A common criticism of BIP-110 is that determined spammers will always find a way around relay restrictions. If someone is motivated enough and willing to pay the fees they can route transactions directly through miners or use alternative technical paths to embed data on-chain. Song argues that this critique misunderstands how incentives work in Bitcoin. 

The goal is not necessarily to eliminate behavior entirely, but to make it less profitable.

Song's response to that criticism is direct, explaining that "all economics is at the margins. Somebody that's super determined and has infinite resources will always get something done, that's not the real question here. It's about the marginal user, the people that are doing it because they're making money. If there are more barriers, it suddenly becomes less profitable and they stop doing it."

He rejects the idea that a rule must stop every actor to be worthwhile. Song says "if there's like a hundred people that spam and you prevent fifty of them, that's still worth a while. But if the threshold is that you have to get all one hundred people to stop or otherwise it's not worth doing, I'm not sure I'd buy that argument."

The OP_RETURN Alternative Debate

Some developers have argued that expanding OP_RETURN gives data-heavy protocols a cleaner outlet, potentially reducing pressure on the UTXO set.

Song is skeptical that actors intentionally storing data on-chain would necessarily migrate to a more orderly option. Song points to the Stamps protocol, which deliberately used bare multisig outputs, as evidence that some participants are not looking for a sanctioned alternative.

"It's kind of like somebody spraying graffiti on your house and you're saying, here's a nice blank wall next to it. Are the vandals going to necessarily listen? I personally don't think so." Song later added that there is, however, at least one concrete case where a larger OP_RETURN field could help. The ZK rollup project Citrea needed roughly 120–160 bytes for proof data and split it between OP_RETURN and fake public keys that permanently entered the UTXO set.

Song acknowledges the example, while noting that it remains rare.

"That's about the only one that I know of that would move from a fake pub key to OP_RETURN. It's the only one anyone's come up with as an example."

UTXO Set Count 80M to 180M to ~160M | Source: Newhedge

Does BIP-110 Rug Everyone Who Built on Bitcoin Inscriptions?

One of the sharpest objections to BIP-110 is not technical, it is about trust. Developers and businesses built products on top of Taproot and Ordinals in good faith, working within the rules Bitcoin allowed at the time. 

BIP-110 would remove the foundation those products depend on, mid-flight. 

Song does not dress it up: "For the inscription people, yeah, you're rugging them. And that's their explicit sort of thing, rug the spammers is their rallying call for BIP-110."

Every image on this screen is permanently embedded in the Bitcoin blockchain. These are the builders and creators BIP-110 will target directly | Source: ordinals.com

The counter-argument from BIP-110 supporters is that the one-year expiry gives builders a defined exit window rather than a permanent door close. Whether that framing holds depends entirely on which side of the trade you are on. 

BIP-110 Introduces Something Bitcoin Has Never Had: A Consensus Rule With an Expiry Date

Resistance existed in 2017, but the opposing camp made their own coin and left. The mechanism for resolving genuine disagreement within a single chain has never been stress-tested. Song put it plainly: "This is the first time we're going to test that and see where it goes."

BIP-110 Key points | Source BIP-110.org

A one-year expiry on a consensus rule is a new category. 

Song explains why the idea has merit, and why the risk is real at the same time: "The idea of a temporary soft fork is that if it ends up being some sort of a dud, then you always have the option of going back. If you don't do that, if you have a permanent soft fork, the problem is if the feature ends up being something that people don't like, there's no real way to go back. You have to continuously support that feature more or less forever."

Bitcoin Soft Fork History: P2SH, SegWit, and Taproot each activated with broad consensus behind them. None carried an expiry date. BIP-110 would be the first to do both activate without consensus and expire after one year

Inscription builders who have locked funds in Taproot-dependent constructs get a defined window. After a year of hostile conditions, the expectation is that they might leave:

Song says "if you're hostile to the Ordinals protocol for a year, they would go to some other chain or do something else. And that's enough to indicate to them, we're hostile to this particular type of transaction. So doing it in this way can be a way to kick them out without necessarily changing the protocol that much, because if it expires after a year you haven't really changed anything and it's still backwards compatible."

Could Bitcoin's Rules Ever Be Used to Reject Transactions Based on Who Sends Them?

A harder question exists underneath the BIP-110 debate. 

If the network can reject transactions based on how block space is being used, could the same logic eventually apply to who is sending them, an OFAC sanctions list enforced at the protocol layer, for example. 

Song does not dismiss the concern, but he reframes where the real risk sits: "there's no allowing anything on a decentralised network. Anyone can go do this at any time. I can go and make a soft fork whenever I want. If a determined minority wants to do something like this, they totally can."

The mechanism for resisting a hostile soft fork is URSF, an incompatible counter-fork designed to split the chain on activation 

Song walks through how it works: "a URSF is essentially an incompatible soft fork to BIP-110 that runs as a counter. You have a different soft fork which requires a BIP-110 incompatible transaction in the first block after it activates, so that they go off on their own. You essentially have two different chains. One client follows one chain, the other client follows the other chain, and all the clients before just follow whichever one is longer."

Song suggested that the market would ultimately decide which chain survives in such a scenario. BIP-110 is less clear-cut, which is exactly why running this experiment now has value: "we don't want to find out the first time when an OFAC sanctions list soft fork happens. We want to find out ahead of time so we know how to handle it. Better to find out now."

Win, Lose, or Split: The Network Learns How Contested Activation Works

Song does not arrive at a strong position on whether BIP-110 should activate. His interest is in what the fight itself teaches. 

On the spam question, "will it eliminate it entirely? No. Will it reduce spam by some percentage? I think so. Because it'll cost more. At a minimum, all the Inscriptions people would have to have some other method of doing it. And that's a cost to anyone running Inscriptions."

Inscription 121707823: A whitepaper permanently embedded in the Bitcoin blockchain | Source: ordinals.com

Whether that reduction justifies the disruption depends on a success metric the proposal's advocates have not clearly defined. Song went on to say "I think it'll ultimately result in a much higher Bitcoin price once it resolves. Understanding more about a system gives people a lot more certainty about how it'll behave in the future."

Stamp #1263514 a poem by artist Logik, permanently on the Bitcoin blockchain. Created September 2025 | Source: stampchain.io

Neutral Rules vs Targeted Behaviour

During the interview, a question was raised directly: if BIP-110 rejects transactions commonly used for inscriptions, does that start to resemble a centralized platform deciding which applications are allowed? Song pointed out that every soft fork restricts something but that is not what makes BIP-110 unusual:

"The big thing about this particular soft fork is that it doesn't have consensus. That's a much bigger deal."

Song was equally direct on what BIP-110 means for anyone who built on Taproot since 2021 they are being explicitly targeted. In his words, the rallying call from BIP-110 supporters is to rug the spammers. For the builders, there is no meaningful difference between being called a spammer and being treated like one.

Unlike a centralised system, you cannot simply remove what people have already built on. The moment you do, you break everything constructed on top of it, as Max Sanchez of Hemi noted independently, which adds weight to this interview.

BIP-110 is asking Bitcoin to do exactly that. Whether the one year expiry changes that calculation is a question every builder on the network will have to answer for themselves.