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.
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.
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.
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.
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.
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.
| Year | Total on disk | Added that year | What happened |
|---|---|---|---|
| 2011 | 0.9 GB | 0.8 GB | |
| 2012 | 4.6 GB | 3.8 GB | |
| 2013 | 14 GB | 9.3 GB | |
| 2014 | 28 GB | 14.4 GB | |
| 2015 | 55 GB | 26.1 GB | |
| 2016 | 97 GB | 42.3 GB | |
| 2017 | 150 GB | 52.7 GB | SegWit activated (Aug). No jump. |
| 2018 | 198 GB | 48.5 GB | Actually a bit less than 2017. |
| 2019 | 256 GB | 57.9 GB | |
| 2020 | 318 GB | 62.4 GB | |
| 2021 | 383 GB | 64.7 GB | Taproot activated (Nov). No jump. |
| 2022 | 446 GB | 62.7 GB | Flat, 14 months after Taproot. |
| 2023 | 537 GB | 91.7 GB | Inscriptions and BRC-20 begin (Jan). The one real step-up. |
| 2024 | 627 GB | 89.2 GB | |
| 2025 | 710 GB | 83.1 GB | Already easing. |
| 2026 | 754 GB | 44.3 GB | Part-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.
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.
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"
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.
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.
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?
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?
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.
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
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.
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.
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.
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.
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.
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.
Want to actually see the image? Right-click this raw transaction link, save it with a
.tiffending, and open it. The transaction is the picture.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
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.
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.
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.
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.
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.
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
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.
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."
"Who's driving this thing? What direction are we going? It's grabbing the wheel and saying, all right, we're turning around."
"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."
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."
On what happens if the fork loses: "I basically would just withdraw from the space... I would lose the love for it."
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."
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."
"I don't want to be involved anymore in future consensus changes to Bitcoin. Period." (And on that era: "Not fun.")
"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.)
The data and the charts
| Claim above | Live 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
- Against (Team Core / neutral): Jameson Lopp, "A Layman's Guide to BIP-110", the fullest critical write-up (chain-split risk, frozen-UTXO edge cases, "reckless").
- For (Team Knots): the full Bitcoin Mechanic interview on What Bitcoin Did, the clearest case for the fork from its loudest advocate.
- The neutral builder: the long-form Pieter Wuille interview, the man who built the upgrades this whole fight is about.
- The devs debating it live: Tone Vays and Jimmy Song with Murch, "Knots vs Core v30" Part IV.
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.