§The spam fight · the facts, the data, the sources

BIP-110: The Plan To Clean Up Bitcoin

What it changes, whether it works, and what it would cost. Both sides put as hard as they go, every claim backed by a chart, a clip, or a line of code you can check yourself.

BIP-110 is 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 are deciding whether to turn it on right now.

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.

How to use this page

Every claim here is something you can check. The charts link to live data. The quotes link to the timestamped clip. The code claims link to the actual pull request. The full source list is at the bottom, so you never have to take anyone's word for it.

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.

The case for the fork

Bitcoin's chain has drifted into a data dump. This grabs the wheel for one year to turn it back towards money, with rules that expire on their own if it was a mistake.

The case against

Turning the wheel doesn't change the destination, because the data just takes another route in. All it would really prove is that Bitcoin can be changed with enough pressure, or a legal threat, and that's a lesson you can't unteach.

The question underneath

Nobody thinks this stops the spam, not even the developer leading it. So the real fight is whether Bitcoin is something anyone should be steering at all, or whether the whole point is that nobody can.

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.

Bitcoin's spam storms, and what happened to each one 2011 2013 2014 2015 ×4 2017 2020 2023 passed passed passed passed passed passed this one Every wave before this burned itself out. Source: Jameson Lopp, "A History of Bitcoin Transaction Dust & Spam Storms".
Spam comes in waves and every one has passed · check the full catalogue at blog.lopp.net

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.

Storage to run a Bitcoin node · 2009 to 2026 200 400 600 800 GB SegWit Taproot Inscriptions + BRC-20 ~750 GB 2009 2013 2017 2021 2026
The blockchain has grown every year since 2009 · hover any year · live chart at blockchain.com

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.

YearTotal on diskAdded that yearWhat happened
20110.9 GB0.8 GB
20124.6 GB3.8 GB
201314 GB9.3 GB
201428 GB14.4 GB
201555 GB26.1 GB
201697 GB42.3 GB
2017150 GB52.7 GBSegWit activated (Aug). No jump.
2018198 GB48.5 GBActually a bit less than 2017.
2019256 GB57.9 GB
2020318 GB62.4 GB
2021383 GB64.7 GBTaproot activated (Nov). No jump.
2022446 GB62.7 GBFlat, 14 months after Taproot.
2023537 GB91.7 GBInscriptions and BRC-20 begin (Jan). The one real step-up.
2024627 GB89.2 GB
2025710 GB83.1 GBAlready easing.
2026754 GB44.3 GBPart-year, to July.

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.

The ownership list (UTXO set) · millions of entries 50 100 150 200M ~85M before ~189M peak ~167M, easing flat for years 2016 2018 2020 2022 2024 now
Flat for years, then doubled in the craze, now self-healing · hover any point · pre-2023 approximate, live chart at mainnet.observer

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.

Images vs tokens: what actually did the damage

An inscription is a data file, a picture say, crammed into the cheap witness space. Ugly, but it prunes away, so it only bloats the size chart above, not the ownership list. (An "Ordinal" is a different thing entirely, just a numbering scheme for individual satoshis, and it costs the chain nothing.)

BRC-20 "tokens" are the real culprit. They're extra outputs that point at inscription data (stored as bulky JSON), and each one lands in the ownership list, the part no node can ever prune. That pile of outputs is what doubled the list.

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"
And the third chart: fees

Right now transaction fees are at multi-year lows. The blocks are full, but full of cheap data nobody's bidding much for, so anything gets in for pennies. Whatever the panic says, there's no bidding war for space today. Check it live at bitinfocharts.

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.

The two lists, in plain English

Think of Bitcoin as two lists. One is who owns what, right now. Every node keeps it and checks every payment against it. Developers call it the UTXO set. Here it's the ownership list.

The other is the proof attached to each payment, the signatures that say "this is mine to spend." That's the witness. Your node needs it to check a payment, but once checked, it never has to sit in the ownership list forever.

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 being the accidental one back in March 2013, which is part of why it's a risk rather than a certainty. At 55%, it's real, not hypothetical.

Question one, answered

It bans one trick, for a year. A temporary consensus rule, forced through at a low bar, aimed at today's most common way for the JPEGs to get onto Bitcoin.

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. In 2017, SegWit made witness space cheap, on purpose, because that data doesn't have to live in the ownership list forever. In 2021, Taproot removed an old size limit, also on purpose, because the reason for it had been solved.

Nobody built them as a pair, but together they made data much cheaper. In early 2023 the inscription craze kicked off, whole images crammed into the cheap witness space.

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. Weeks later the same trick got a second job, minting pretend BRC-20 tokens, and that flooded the ownership list.

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 number the whole thing turns on

0.4%

Not four percent. Nought point four. That's the extra cost to a spammer after BIP-110 blocks today's method. And Peter Todd, a veteran Core dev, made it impossible to miss. He buried the entire BIP-110 document onto the chain without breaking one of BIP-110's own rules. The rule meant to stop data couldn't even stop its own rulebook.

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?

Miners have to switch it on. Here's where they are. 55% needed to activate ↑ actual miner signalling A soft fork like this normally waits for ~95%. BIP-110 lowered the bar to 55%, and still can't get near it.
Miner signalling has stayed a long way short of the 55% needed · check the live rate at bip110.org/monitor

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.

Question two, answered

Barely. But it might pass anyway. On the numbers it barely dents the spam, and its sharpest critic proved that. Will it activate? On today's support, no. But soft forks look dead until the week they don't.

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.

A rounding error for the spammer, a permanent load on your node

How much dearer it makes spamming~0.4%
What it can add to your node, forever+95%

These are two different sums, both Martin's. The 0.4% is how little the rule actually deters a spammer, the same number from the last section. The 95% is what happens to your node in one worked example: shut out of the cheap, prunable bin, the junk reshapes into a fake coin that lands in the ownership list, the one thing no node can ever delete. He pays pennies. You store it for good.

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.

Three fixes. Every one left the network carrying more.

The compliant spam is bigger. Martin built a version of his junk picture that obeys every BIP-110 rule. It came out larger than the one the rule was meant to stop.

The recovery-wallet fix is bigger. The strongest objection to the fork is that it breaks the inheritance wallets real families use, where a backup key takes over if the owner goes quiet for a year. That got patched. The patch works. It just makes those wallets' scripts fatter.

The dodge round the filter is bigger. Draw up a filter to catch today's spam and you beat it by adding a few throwaway instructions. Those instructions actually run, so the dodge is harder on your node than the spam it's dodging.

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.

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
mempool.space showing recent blocks at roughly 0 to 1 sat per vByte and a transaction-fee panel: No Priority 0.2 sat per vByte for about 2 cents, up to High Priority at 2 sat per vByte. Minimum fee 0.10 sat per vByte.
Fees are measured in sats per vByte, the price for each little unit of block space. See it live at mempool.space.
  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
mempool.space transaction page for Martin's transaction. Features row shows SegWit ticked, Taproot struck through, RBF. The transaction is flagged Non-Standard. Fee rate 2.03 sats per vByte, 20,554 confirmations.
The Features row is the proof: SegWit yes, Taproot struck through, and the whole thing flagged Non-Standard. A real picture, on Bitcoin, with none of the thing everyone blames.
  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
How to read knotslies.com

Martin laid the whole thing out, with the commands, on knotslies.com. It's dense, so here's the map. The top proves the picture is real and needs no Taproot and no OP_RETURN. The middle answers every "yeah but" one at a time. The end has the part that matters most for this page: a BIP-110-compliant version of the same spam, which comes out bigger, with a script to verify it on a test network yourself.

You don't have to trust him, and that's his whole point. Every claim on that page is a command you can run.

knotslies.com · the proof, and how to check it yourself
The top of knotslies.com: an abstract explaining a 66KB contiguous image was stored on Bitcoin without OP_RETURN or Taproot, a court-analogy joke about splitting up illegal content, the image of Luke-Jr, and the bitcoin-cli command to verify it on your own node.
Martin's write-up, built the same way this page is: here's the claim, here's the command, go and check it. Read it at knotslies.com.

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
The BIP-110 specification on bips.dev: title Reduced Data Temporary Softfork, the abstract, and the seven numbered consensus rules, including rule 7, that Tapscripts executing OP_IF or OP_NOTIF are invalid.
The seven rules are right there. Rule 7 is the famous one: it bans the OP_IF switch the pictures ride in on. Read the whole spec at bips.dev/110.

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
GitHub pull request 27832, titled doc: Clarify -datacarriersize, add -datacarriersize=2 tests, marked Merged, 2 files changed. The diff shows the help-text string reworded while the underlying value MAX_OP_RETURN_RELAY is identical before and after.
The title starts with doc:, Core's own tag for a text-only change. Two files. And the actual limit, MAX_OP_RETURN_RELAY, is identical in the red line and the green line. See it yourself at github.com.

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.

Could it freeze your coins? The honest answer

For almost everyone, no. Normal wallet, hardware wallet, Lightning, all fine. Only a tiny group on one very advanced custom setup is affected, and even then the coins aren't gone. The rule expires in a year and anything created before it switches on is exempt forever.

Not from a critic, either. Here's the fork's own champion, asked point-blank, refusing to oversell the danger.

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.

Question three, answered

A precedent, not your coins. Both sides see a genuine danger. They just can't agree which is worse: teaching Bitcoin to filter what it carries, or leaving the door wide open.

The three questions, all answered

1 · What does it change?Bans one trick. For a year.
2 · Can it work?Barely. But it might pass anyway.
3 · What could it break?A precedent. Not your coins.

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.

How to read the "Capture" claims

Both sides agree on the events, the merged pull requests, the documents, the meetings. They dispute the motive. One camp reads an open, messy, contentious process. The other reads the same facts as choreographed. The documented events are in the sources below. The "capture" conclusion is one contested reading, so weigh it as an allegation, not a proven fact.

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.

Hold your own keys. Real Bitcoin, that you control, with your own twelve words. Not an ETF, not company shares, those are a paper IOU where someone else holds the keys.

Run a node, the software that checks Bitcoin's rules for itself, trusting nobody. In a fight exactly like this, you get a vote no miner or government can override, plus real privacy. It's free on an old laptop, or a plug-and-play box like a Start9 (5% off with code STRAIGHTUP).

Actually spend it. Here's how that ties straight back to this fight. 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.

Want to go further? Grab a Bitaxe, a tiny open-source miner, and point it at a decentralised pool. You help spread out who builds the blocks, the exact thing Wuille said keeps him up at night. And a handful of people on these 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.

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

See it yourself

Don't take a single line of this on trust. Here's where to look.

The spam-comes-in-waves history is in Jameson Lopp's catalogue of every storm since 2011. The three charts are all live: chain size, the ownership list (UTXO set), and fees.

The proposal itself is public: read the BIP-110 spec on GitHub, and watch the live miner signalling at bip110.org. Every developer quote above is linked to the exact video and timestamp below.

If a number here is wrong, the primary source will show it. That's the point of listing them.

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.

"All it does is crudely look at the ways people are stashing arbitrary data... make them impossible for a year."

Bitcoin Mechanic · lead advocate for the fork · What Bitcoin Did, ~3:02 ↗ YouTube

"Who's driving this thing? What direction are we going? It's grabbing the wheel and saying, all right, we're turning around."

Bitcoin Mechanic · What Bitcoin Did, ~46:04 ↗ YouTube

"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 ↗ YouTube

On the freeze-your-coins claim: "The technically true answer is yes. But... no one actually is. The conditions are so unbelievably contrived... everything gets grandfathered in."

Bitcoin Mechanic · What Bitcoin Did, ~42:54 ↗ YouTube

On what happens if the fork loses: "I basically would just withdraw from the space... I would lose the love for it."

Bitcoin Mechanic · What Bitcoin Did · human-cost section (exact time to be added) ↗ Watch on YouTube

The witness is cheaper because "it never enters the UTXO set. It's just needed at validation time, and then you don't need it anymore."

Pieter Wuille · author of SegWit and Taproot · long-form interview (exact time to be added) ↗ Watch on YouTube

His biggest worry: "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 · long-form interview (exact time to be added) ↗ Watch on YouTube

"I don't want to be involved anymore in future consensus changes to Bitcoin. Period." (And on that era: "Not fun.")

Pieter Wuille · long-form interview, ~1:23:17 ↗ YouTube

"One of the most invasive protocol changes ever proposed." (On the Knots data-limit forks. Same clip, he also puts inscription data near 30% of recent chain growth.)

Murch (Mark Erhardt) · Core developer · Tone Vays & Jimmy Song, "Knots vs Core v30" Pt IV, ~2:27 ↗ YouTube

The data and the charts

Claim aboveLive source
Chain size ~750 GB; more than a quarter of recent growth is inscription data, all of it prunable blockchain.com · Blockchain Size
The ownership list (UTXO set) roughly doubled in the craze, driven by BRC-20 tokens, now easing back mainnet.observer · UTXO set size
Fees at multi-year lows; blocks full of low-fee data, no bidding war for space bitinfocharts · BTC transaction fees
Spam comes in waves since 2011, four in 2015 alone, every one passed Lopp · A History of Bitcoin Dust & Spam Storms
The 2015 flood that knocked ~10% of nodes offline Bitcoin Wiki · 2015 flood attack
You can't filter spam out: a JPEG hidden inside a valid private key BitMEX Research · The Unstoppable JPG
"Embrace the fee market... spam budgets do not last forever" BitMEX Research · Removing Bitcoin's Guardrails
Miner signalling: a small fraction of the 55% needed (live figure at the monitor) bip110.org · live monitor · pool breakdown

The proposal and the code

  • The spec itself: BIP-110 on GitHub, and the plain-language bip110.org. The rules, the grandfathering ("no deadline to move existing funds"), and the activation parameters are all here.
  • How it activates: a modified soft-fork rollout, threshold 55% of miners (1109 of 2016 blocks), mandatory-signalling window around early August 2026, full activation expected around 1 September 2026, and auto-expiry roughly a year later. Dates are block-height estimates. Check bip110.org for the live count.
  • The rushed-client story: Blockspace, "Bitcoin developers take shots at buggy BIP-110 client" (Dec 2025). The first release failed tests its own author had written.
  • The bug, and the fix: the consensus bug was patched in the v0.3 release (Feb 2026), and an independent code audit then called the consensus implementation clean. This is why I don't treat the bug as a live danger.

Both sides, in their own words

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

  • The Citadel21 "Capture" series by Hodlonaut, a partisan investigation into how informal power over Bitcoin Core was assembled (the parts, "The Network", "The Lever" and "The Merge", are on the Citadel21 site). It's an opinion piece, so treat the motive claims as allegations, not documented intent.
  • The other half of the picture: Core's first public independent security audit, on the networking layer, by Quarkslab (funded by Brink, coordinated by OSTIF), which found no serious vulnerabilities. Capture is a claim about power and funding, not broken code.

Go deeper

  • The full video on this, with all the clips cut in: link coming the moment it's live.
  • The definitive book on how a Bitcoin fork fight actually plays out is Jonathan Bier's The Blocksize War. If you want to understand why "who wins a fork" is decided by users and nodes, not just miners, start here.
  • Still got the "yeah, but" objections about Bitcoin itself? I've answered the most common ones, with the charts to check, in the Skeptic's Guide.

FAQ

What is BIP-110 in simple terms?

BIP-110 is a proposed change to Bitcoin's core rules that would block the most common way people stuff pictures and tokens onto the blockchain. It bans a code switch called OP_IF from being used that way, caps a few data sizes, and does it temporarily, for about a year. It's a consensus change, the deep kind that every node has to enforce, in the same category as SegWit and Taproot.

Would BIP-110 freeze my Bitcoin?

For almost everyone, no. Standard wallets, hardware wallets and Lightning are all fine. Only a tiny group using one very advanced custom setup could be affected, and even then the coins aren't lost. Anything created before the rule switches on is exempt forever, and the rule itself expires after about a year. Even the fork's biggest advocate calls the risk "unbelievably contrived."

Will BIP-110 actually activate?

On today's numbers, no. It needs 55% of miners to switch it on, and signalling has stayed a long way short of that, a small fraction of the bar rather than anything close to it. But soft forks have a history of looking hopeless right up until miners suddenly fold, so nobody can rule it out. The mandatory-signalling window is expected around early August 2026, with full activation possible around September 2026 if support appears.

Does BIP-110 actually stop the spam?

Barely. Independent analysis by a Bitcoin code reviewer found it adds only about 0.4% to a spammer's cost, because it blocks one method while leaving the cheap block space that caused the problem untouched. To make it really bite you'd have to tighten it so far it breaks ordinary transactions. Supporters argue the point isn't the cost, it's changing the direction Bitcoin drifts in.

Is Bitcoin Core "captured"?

It depends what you mean. There's a real investigation arguing a small, funded circle gained outsized influence over Bitcoin's main software, and the events it cites are documented. But "capture" is a claim about power and funding, not broken code, and Core's code passed its first independent security audit with no serious vulnerabilities. Both sides agree on the events and disagree on the motive, so it's best read as a contested interpretation, not a proven fact.