BIP-110: The Plan To Clean Up Bitcoin

BIP-110 was a proposed change to Bitcoin's core rules. For one year it would block the most common way pictures and tokens get written onto the chain, then switch itself off.

Miners were asked to turn it on this summer. They didn't, and on 8 August its supporters split off onto a chain of their own.

Both camps agree the monkey-picture JPEGs clogging Bitcoin are junk. That was never the argument.

The fight is whether a rule can actually stop them, and what trying would cost the network.

This page settles that with the evidence, not opinion. Three plain questions, every number linked to a live chart, every quote to the exact clip, every claim about the code to the line on GitHub.

Update, September 2026: what actually happened

This page was written in July, before the vote was in. Here's how it ended.

Miners never came close. In the last two-week window before the deadline, 51 blocks out of 2,016 signalled for it: 2.53%, against the 55% it needed.

So on 8 August, at block 961,632, the nodes running BIP-110 rejected the rest of the network and carried on alone. The main Bitcoin chain didn't notice, and kept producing a block every ten minutes as it always does.

The breakaway chain had almost no miners, so it managed two blocks and stalled. On 30 August it changed its mining algorithm from SHA-256 to one called BLAKE2b, so it no longer runs on Bitcoin's mining hardware at all.

The rest of this page is the argument as it stood before the split. I've left it as written, because the question underneath it hasn't gone away.

The lay of the land

Two camps.

On one side, Team Knots, who say Bitcoin is money, the junk data clogging it up is an attack, and it has to be stopped. On the other, Team Core, who say you can't stop it without breaking things, so spend your energy elsewhere.

Here's the bit everyone forgets in the shouting. Both sides think the monkey-picture JPEGs stuffed into Bitcoin are rubbish.

That was never the disagreement.

The two positions are laid out below, each put as hard as it goes. The developers quoted by name, Mechanic, Wuille, Murch, are real, from sourced clips linked at the end.

Question zero: is the spam even a problem?

Everyone's fighting over how to stop the spam. Almost nobody asks the first question.

Is it even a problem?

Because none of this is new. Bitcoin has had spam storms since 2011.

Four in the summer of 2015 alone, one big enough to knock about a tenth of the network's nodes offline. Every single one passed.

The fad burns out, the spammers get bored or priced out, and they move on. Jameson Lopp, no fan of this fork, catalogued the lot.

His line is blunt. They're just burning their money.

So is 2023's inscription wave any different? Don't guess.

Here's the actual data.

The chart everyone points at to scare you

First, the big one. The total size of the blockchain, which is the storage you need to run your own full node.

It's about 750 GB now, and yes, it only ever goes up.

Now look at what the line does at the two moments people love to blame. SegWit in 2017.

Taproot in 2021. Nothing.

No kink, no jump. The slope just carries on.

That's the tell. If those upgrades had opened some floodgate, you would see it right here.

You don't.

The chain has grown every single year Bitcoin has existed, because it's an append-only ledger. That isn't spam running wild.

It's just what a growing record does. Here's the same story as a table.

The one real step-up came in 2023, when the inscription fad kicked in, lifting yearly growth from around 62 GB to about 90. A bump, not an explosion.

And it's already easing off.

Better still, every byte of this prunes away. Your node keeps only a few gigs no matter how big the full chain gets.

So the scariest-looking chart is the one that costs you almost nothing. On this, Core is right.

The chart that does cost you: the ownership list

Now the one that matters. The ownership list, the coins every node has to keep forever and can't prune.

During the craze it roughly doubled, and this time it was BRC-20 tokens doing it.

That's the genuine cost, no pretending otherwise. But look at the left of that chart.

For years the list barely moved. It only doubled when one specific fad turned up, and it's already receding now that fad is dying.

So why is it receding? Because the token fad is burning out, like every fad before it.

People stopped minting and trading them, the leftover dust is slowly being spent and swept up, and the list shrinks back on its own. No fork.

No committee. The market did it.

This is not new, and it's not what Bitcoin is for

Worth saying plainly, because it's the whole point. Bitcoin is money.

It works best when it's actually used as money.

What you're watching with the JPEGs and the tokens is the oldest trick there is. Dress up a gamble as the next big thing, and lure in people chasing a quick buck.

Tulips did it. Penny stocks did it.

ICOs and NFTs did it. Now it's blockchain "tokens." It always burns hot, then burns out, and the people left holding it are the ones who lose.

Bitcoin doesn't need re-engineering to survive that. It needs to be used as money, so real payments outbid the junk for the space.

BitMEX Research put the market's answer bluntly.

If an attacker or spammer wants to outbid other users, they can and we should embrace that reality. Spam budgets do not last forever and many of the people investing in blockchain images are likely to collectively lose millions of dollars. People will learn hard lessons and then Bitcoin will be stronger from it.BitMEX Research · "Removing Bitcoin's Guardrails"

Their fair comeback: waves pass, but each one leaves permanent junk behind. True.

Except that permanent junk is the prunable, harmless kind, and you can't filter it anyway.

BitMEX Research proved that. They buried a whole JPEG inside a private key, consensus-valid, impossible to block.

You can't filter your way out of spam. You can only outgrow it.

This whole war is being fought over a fire that, going by every fire before it, is already burning out.The one line to keep in your back pocket

Question one: what does BIP-110 actually change?

Almost nobody explains this cleanly. Stick with me for ninety seconds and you'll understand it better than most of the people arguing about it.

Bitcoin has two kinds of rule.

Policy rules are like local planning permission, polite and breakable. Consensus rules are like the laws of physics, every node enforces them or your block is invalid.

The last big fight was a planning-permission change. BIP-110 is the deeper kind, a consensus change, the same category as SegWit and Taproot.

Much bigger deal.

So Bitcoin charges exactly four times less for witness space. It's the cheapest storage on the network.

And that's exactly where the data-stuffers hide their pictures, using a little on-off switch in the code called OP_IF. These are inscriptions.

BIP-110's main move is simple.

Ban that switch from being used that way. It also caps a few sizes, and welds shut a door the last fight had just opened, though the real way in stays open, because that one can't be closed.

Here's the developer who champions the fork, Bitcoin Mechanic, describing it in his own words.

All it does is crudely look at the ways people are stashing arbitrary data in Bitcoin at the moment and make them impossible for a year. It doesn't pretend they won't find other ways of doing that.Bitcoin Mechanic · lead advocate for BIP-110 · What Bitcoin Did, ~3:02

Notice he calls it crude himself. That honesty runs through the whole fork.

Two things make it unusual. First, it's temporary.

Switch it on, it runs about a year, then switches itself off. Knots calls that a safety feature.

Lopp's answer: there's nothing more permanent than a temporary solution.

Second, it doesn't ask miners nicely.

A change like this normally waits for the overwhelming majority; Bitcoin's last fork, Taproot, asked for around ninety percent of miners. BIP-110 sets the bar at 55%, and its nodes reject blocks they don't like rather than ignore them.

Force it in at 55% and the other 45% aren't stragglers. They're nearly half the network.

If they dig in and keep mining their own version, the chain splits in two.

There's no clean precedent for a split forced this way. The nearest is the accidental one in March 2013, which is part of why this is a risk rather than a certainty.

At 55%, it's real, not hypothetical.

In the end it split with nowhere near 55%. The full story is at the top of this page.

Question two: can it actually work?

Both sides here are cleverer than the internet gives them credit for. It starts with a fight over one word.

Is this even a bug?

Quick history.

1. 2017, SegWit. Made witness space cheap, on purpose, because that data doesn't have to live in the ownership list forever.
2. 2021, Taproot. Removed an old size limit, also on purpose, because the reason for it had been solved.
3. Early 2023, inscriptions. Whole images crammed into the cheap witness space. Nobody built those two upgrades as a pair, but together they made data much cheaper.
4. Weeks later, BRC-20. The same trick got a second job minting pretend tokens, and that flooded the ownership list.

It's tempting to say those upgrades made it possible. They didn't.

The data could always get in, which Martin's no-Taproot picture later proves. They made it cheaper, and at most an hour's less coding.

So, exploit or design decision? The man who built both upgrades, Pieter Wuille, backs the deliberate half.

The low price wasn't a slip.

But here's the line both sides blur. Pricing it cheap on purpose is not the same as foreseeing someone would cram pictures through it.

The design was deliberate. The abuse of it was not.

Now the real question. Can a rule even stop it?

You already know the shape of the answer. You can't filter your way out, only outgrow it.

But let's do it properly, because the pro side isn't stupid.

Martin Habovštiak, one of the people who actually review Bitcoin's code, did the maths. Ban the trick, force the junk into smaller pieces, count everything.

The extra cost to a spammer?

The supporters' comeback is fair. Nobody serious claims it stops data for good.

The point isn't the decimal, it's the direction. For years every change made stuffing data easier.

This is the first attempt to turn that around.

The counter is just as fair. It doesn't touch the thing that caused all this, the cheap, plentiful block space.

Block one method and the junk reshapes into smaller pieces and keeps flowing. It's like junk mail.

Outlaw one flyer design and the postage's still cheap, so they switch format.

The pro side's best comeback is "just tighten the rule until it hurts." Habovštiak ran that too. Even the maximum sane tightening only lifts that cost to one or two percent.

To really bite, you'd have to shrink the limit so far it breaks normal signatures and freezes ordinary coins.

So it barely moves the needle, and you can't crank it up without breaking Bitcoin for everyone. Which leaves the last question here.

Will it even switch on?

Dead on arrival, then? Not so fast, say supporters.

Silence isn't a no. Most miners aren't against this, they're ambivalent, and ambivalence to a consensus rule usually means going along with it.

Soft forks are one of those things that just look insane and stupid, and then suddenly they win. That's the game theory of it.Bitcoin Mechanic · What Bitcoin Did, ~54:41

The example is 2017, when a user-forced soft fork looked exactly this hopeless right up until the big miners folded. The counter: 2017 isn't this.

Back then users and businesses were loudly behind it. This time the support just isn't there.

And it was rushed. The first release client failed tests its own author had written, and a real consensus bug sat in it for months.

To be fair, that was patched in early 2026, well before any activation, and an independent reviewer later called the code clean. But you don't want to be digging fundamental bugs out of consensus code after a client has already shipped.

The part that flips it: BIP-110 makes the spam bigger

Here's the part almost nobody says out loud. The rule doesn't just fail to shrink the spam.

On the network that matters, it grows it.

Follow one spammer through it. He wants to put 100 bytes of junk on the chain.

BIP-110 caps the cheap, prunable bin at 83 bytes, so his junk no longer fits.

So he splits it. A chunk gets dressed up as a fake coin in a brand new output.

The rest goes in the bin. The junk is still on the chain, he just posted it in two envelopes instead of one.

The junk's still on the chain. But watch where the cost actually lands.

That maths isn't guesswork. It's the work of Martin Habovštiak, one of the developers who reviews this code.

He worked it through byte by byte and published the lot on knotslies.com, so nobody has to take his word for it. We'll check his receipts, off the chain, in a moment.

And it keeps happening. Every time someone patches a problem this fork creates, the patch makes something else bigger.

So the honest summary of the mechanism is short. It doesn't stop the junk.

It reshapes it, charges the spammer pennies, and hands your node more to carry. That is the opposite of the thing it was sold to do.

But isn't the real worry whole files, not cost?

Here's the fork's strongest card, and it isn't the price. It's that Bitcoin can hold a whole file in one piece, a picture or a document, sitting there for good.

For a lot of people that's the real fear, and it's a fair one to put on the table.

So does BIP-110 stop it? No. The same picture that killed the Taproot story kills this one too.

Start with what the rule actually bans.

OP_IF is a plain on/off switch that has sat in Bitcoin for years, doing ordinary jobs.

Wallets that need more than one key. Wallets that hand control to a backup after a set time.

The data crowd worked out it was also a tidy way to wrap a file, and rule 7 bans that one use.

But the file never needed the switch. Martin Habovštiak's 66KB image is on the main chain right now, in one piece, with no OP_IF, no OP_RETURN and no Taproot.

You'll pull it off the chain with your own hands in the next section.

That switch has honest jobs, which is the part the fork skips over. The same kind of backup-key wallet from the section above leans on it because it's leaner than the alternatives.

Ban it and those real transactions quietly get bigger too.

There's a cleverer version of the file worry, the one about "parsing."

It says that without the OP_IF wrapper, a node can't reassemble the scattered bytes back into a real file.

Martin's image is the answer, sitting on the chain. One command pulls it off and it opens as a working picture, with no wrapper anywhere in it.

Don't take anyone's word for it. Check the lot in five minutes.

This is the whole point of the page. Every claim above is something you can see for yourself, right now, without trusting me or any developer.

Here's exactly where to look.

1 · See the "flood" for yourself: it's a ghost town

The scariest word in this fight is "flood." So go and look at the actual traffic. Open mempool.space and find the Transaction fees box.

mempool.space · the current price to get into a block

1. Read the number on the left, No Priority. Today it's about 0.2 sats per vByte, so an ordinary payment costs a couple of pence.

2. Now look at the blocks along the top. They're packed full, but clearing at a sat or two per vByte. Full blocks, at almost no cost. That only happens when nobody's competing for the space.

3. That's the tell. The blocks aren't empty, they're stuffed with near-worthless data that got in for pennies, because there isn't enough real demand to bid the price up.

The man leading the fork said the quiet part himself.

I'm stunned at how much of a ghost town the blockchain actually is. We're paying naught point four one sats a vByte to get transactions in the chain.Bitcoin Mechanic · lead advocate for the fork · What Bitcoin Did, ~24:51

Which points straight at the fix that needs no fork at all. Fill those blocks with real payments instead of cheap junk, and a spammer has to outbid every one of them.

Use Bitcoin as money and the junk prices itself out.

2 · Pull the spam off the chain with your own hands

The story everyone repeats is that Taproot, the 2021 upgrade, is what let pictures onto Bitcoin. Martin proved that wrong in the most direct way possible.

He put a 66KB image on the main chain using no Taproot and no OP_RETURN, and left it there for anyone to check.

Open his transaction on mempool.space and read the badges.

mempool.space · Martin's picture-transaction, on the main chain

1. Look at Features. "Taproot" is crossed out. This 66KB image needs no Taproot at all, which kills the "Taproot let it in" story on the spot.

2. Want to actually see the image? Right-click this raw transaction link, save it with a .tiff ending, and open it. The transaction is the picture.

3. Running your own node? Martin gives you the one command to pull and decode it yourself, no website in the middle:

   bitcoin-cli getrawtransaction b8cc570e…8bd8d4be | xxd -r -p > luke.tiff

knotslies.com · the proof, and how to check it yourself

3 · Read the actual rule, in the actual spec

You don't need a developer to tell you what BIP-110 says. The proposal is public and short.

Open it at bips.dev/110 and read the numbered rules yourself.

bips.dev/110 · the proposal, in its own words

Two lines in that document settle arguments people are still having. On whether it works, the proposal says it itself.

Does this proposal solve spam completely? No. It is impossible to solve spam completely, and typically spam is best fought with policy filters, not consensus.BIP-110 specification · its own Rationale section

Read that twice.

The rulebook says it won't stop the spam, that nothing can, and that the right tool is the gentle kind of rule. Which is the exact opposite of what this is.

And on why it only asks 55% of miners instead of the usual 90-odd, the spec is just as blunt.

Since rejecting data storage is a matter of urgency, and since this softfork is temporary and expires after one year, a lower threshold is ideal.BIP-110 specification · on the 55% bar

So "temporary" isn't the safety feature it's sold as. By the document's own words, temporary is the trade that let them drop the bar.

It's the discount.

4 · The one receipt everyone talks about, and nobody reads

The loudest claim in this whole fight is that Core secretly rewrote a setting Luke wrote, then used the rewrite to bin his fix. It's the one accusation you can check yourself in about ninety seconds, so let's.

Open the pull request everyone points at, PR #27832, and look at what actually changed.

github.com · PR #27832, the "cover-up," in full

They reworded the help text and touched a test. The number that sets the actual limit is the same before and after.

It's the label that changed, not the box.

That clears nobody of anything bigger. But the smoking gun everyone cites turns out, when you open it, to be a wording fix its own author tagged "doc." That's why the page hands you the link instead of the conclusion.

Question three: what could it break?

This is the part that actually matters, and it cuts both ways.

Start with the side effects of doing it.

The critics' worry is the precedent. The moment Bitcoin's rules start judging a transaction by what it contains, not just whether it's valid, a line's been crossed that can't be uncrossed.

Prove to the world Bitcoin can be filtered on demand, and you've handed every government a reason to demand it. It's why even a Core dev, Murch, puts it bluntly.

One of the most invasive protocol changes ever proposed.Murch (Mark Erhardt) · Core developer · on the Knots data-limit forks

Now the claim that needs care, because getting it wrong is exactly the fear-mongering to avoid. Some say BIP-110 could freeze your coins.

The technically true answer is yes. But it'd be misleading to just say that, because no one actually is. The conditions are so unbelievably contrived, and everything gets grandfathered in.Bitcoin Mechanic · What Bitcoin Did, ~42:54

When the fork's own champion is that careful not to oversell the danger, that tells you something.

Now the side effects of not doing it, and this is the pro side's strongest ground. When this junk needs mining, it gets done through private, out-of-band deals with a handful of giant pools.

The more the network leans on those backroom deals, the more mining power collects in fewer hands. That concentration is the real capture.

And a neutral legend backs it.

Third-party mempools, business deals with all the big miners but not the small ones. Front running as a service. An enormous centralising force.Pieter Wuille · author of SegWit and Taproot · on his biggest worry

That's the man who built SegWit and Taproot, no dog in this fight. Notice what he's warning about.

It isn't images. It's power, a few big pools becoming the only way to get mined.

But here's the catch. This is a threat about who controls mining, and BIP-110 is a rule about data.

Stopping the spam might ease one reason those private deals happen, but it doesn't fix the centralisation itself. So even on their best ground, the fork is only a nudge.

The fight underneath the fight

There's a fourth thing underneath all this. What the fight is really about isn't JPEGs.

It's whether the small group who maintain Bitcoin's main software can be trusted at all.

There's a whole investigation, called Capture, arguing a tight, funded circle around Core quietly ended up deciding whose code and whose objections mattered. Have some questionable things gone on inside Core?

Probably. It's people, it's a workplace.

But there's the other half. Last year, Core's code got its first independent security audit on the networking layer.

No serious vulnerabilities found.

So when people scream "Core is captured," be careful. Capture is a claim about power and funding, not broken code.

That distinction is everything, and almost nobody makes it.

There's a human cost, too. The abuse aimed at anyone who weighs in on this publicly is relentless.

Now imagine being an actual developer and taking it for years.

Pieter Wuille, who built SegWit and Taproot, has stepped back from proposing any new change at all.

I don't want to be involved anymore in future consensus changes to Bitcoin. Period.Pieter Wuille · What did that era feel like? "Not fun."

And it isn't only his side. Asked what happens to him if the fork loses, Mechanic says he'd basically withdraw from the space and lose the love for it.

Two people on opposite sides, both a step from walking away.

There's a good thing buried in it, though. The shouting looks like Bitcoin breaking.

It's closer to the opposite.

A system with no boss argues like this precisely because nobody can quietly force anything through. The noise is the immune system working.The takeaway

So what can you actually do?

Everyone's crowded at the loud door, the fork.

Meanwhile the quiet door has been swinging open the whole time. You can make Bitcoin genuinely harder to capture, starting tonight, and it has nothing to do with winning a comment thread.

1. Hold your own keys. Real Bitcoin that you control, with your own twelve words. Not an ETF and not company shares, because those are a paper IOU where somebody else holds the keys.
2. Run a node, the software that checks Bitcoin's rules for itself and trusts nobody. In a fight exactly like this you get a vote no miner or government can override, plus real privacy. Free on an old laptop, or a plug-and-play box like a Start9 (5% off with code STRAIGHTUP).
3. Actually spend it. The more Bitcoin gets used as real money, the more a spammer has to outbid real payments for the same block space. Use it and the market prices the junk out on its own. No fork, no committee.
4. Go further, if you fancy it. Grab a Bitaxe, a tiny open-source miner, and point it at a decentralised pool. You help spread out who builds the blocks, which is the exact thing Wuille said keeps him up at night.

And a handful of people on those little boxes have genuinely won a whole block.

The fight is loud. The building is quiet. Getting one shop nearby to accept Bitcoin does more for it than winning any argument about BIP-110 ever could.The takeaway

What the evidence adds up to

Strip out the noise and the trade is simple. BIP-110 patches the fallout of one soft fork with another, forced through at a rushed 55% bar, to do a job its own side admits it can't finish, and it risks splitting the chain to try.

On the evidence, the case against is the stronger one. Its loudest champion calls it crude and won't promise it passes.

The reviewer who did the hardest maths showed it barely touches the spam, and a veteran dev then buried the whole proposal on-chain without breaking one of its own rules. And 55% is nowhere near the roughly 90% Bitcoin's last fork asked for.

None of that makes the fork's side wrong about the problem. Bitcoin drifting from money, and mining power collecting in fewer hands, are both real.

Respect the worry. Question the method.The bottom line

There's no clean rule that fixes those worries. The thing that helps most is power spread across thousands of nodes, not a change forced through by a few at the point of a split.

Then the network answered. Miners stayed away, the split came anyway, and the main chain carried on as if nothing had happened.

That's the point about nodes spread across thousands of hands. Nobody had to win the argument for Bitcoin to keep working.

But none of this needs taking on trust. Every number, quote and line of code is below.

Go and check it.

Every source, in one place

Everything cited above, laid out so you can go straight to the primary source and decide for yourself.

A note on the clips. Timestamps marked with a "~" are approximate. Every quote is lightly tightened for delivery, so if a word matters to you, watch the clip and check it against what's actually said.

The developer clips

Hit "Play clip" to watch the exact moment right here, no leaving the page. Or use the YouTube link to open it there. Timestamps with a "~" are approximate.

The data and the charts

The proposal and the code

Both sides, in their own words

The "Capture" investigation (read as one contested reading)