Bitcoin Has a Squatter Problem. BIP 110 Is the Eviction Notice.
Why a temporary soft fork is the most important thing happening in Bitcoin right now, and why the FUD about it is dead wrong.
Imagine you built a highway. Its purpose: move people and goods from point A to point B, fast and cheap.
Now imagine someone figured out they could park RVs on that highway, wall-to-wall, and use it as free storage. They’re paying a small toll to the on-ramp operator, sure, but every other driver on the road is stuck in traffic, paying higher tolls, burning more gas, and wondering why the highway they helped build is now a parking lot.
That’s what’s happening to Bitcoin right now. And BIP 110 is the “No Parking” sign.
What actually happened to Bitcoin
Bitcoin was designed to do one thing extraordinarily well: move value without permission from anyone. No banks. No governments. No middlemen. Peer-to-peer electronic cash. It’s right there in the white paper.
In 2022, someone discovered a clever hack. By exploiting a feature of Taproot (Bitcoin’s latest upgrade), they could shove arbitrary data like JPEGs, videos, and entire files into Bitcoin transactions. They called them “inscriptions.” Overnight, Bitcoin’s blockchain became a dumping ground for monkey pictures and meme tokens.
Here’s the problem: every single Bitcoin node on earth has to download, verify, and store that data. Forever.
The person uploading a 4MB image to Bitcoin pays a one-time fee to a miner. That miner pockets the fee and moves on. But the tens of thousands of volunteers running nodes? They eat the storage cost, the bandwidth cost, and the verification cost for the rest of Bitcoin’s existence, and they get nothing.
This isn’t a free market working as intended. It’s a market failure. The person dumping data gets permanent, uncensorable, globally-replicated storage. The people providing that storage were never asked and never compensated. Economists call this an externality. Normal people call it freeloading.
And here’s what makes it sting: most of us supported Taproot because it makes multisig better. It was designed so that complex spending conditions, like requiring multiple keys, or having timelocked fallback paths, could be hidden off-chain until needed. That means smaller transactions, lower fees, and better privacy for real financial use. That’s why it was exciting. Nobody pitched Taproot as a way to upload JPEGs to the blockchain at a discount.
But that’s exactly what happened. Inscriptions exploit Taproot’s witness structure by using OP_FALSE OP_IF to shove data into script paths that are never actually executed, collecting a 75% fee discount along the way because of how SegWit weights witness data. A scaling technology got turned into an anti-scaling technology. The UTXO set more than doubled from 2023 onward. Syncing a new node now hits a wall at 2023 and crawls.
Bitcoin Core could have closed this loophole in 2023 when inscriptions first exploded. They didn’t. Instead, in 2025, they made it worse by blowing open OP_RETURN limits. BIP 110 is the fix they refused to ship.
What BIP 110 actually does
Strip away the technical jargon and BIP 110 does something simple: it temporarily caps how much data you can stuff into a single field of a Bitcoin transaction at 256 bytes.
For context:
A Bitcoin address fits in 34 bytes
A cryptographic signature fits in 64–72 bytes
A 2048-bit public key fits in 256 bytes
A JPEG image needs thousands to millions of bytes
256 bytes is more than enough for any financial transaction imaginable. It is not enough to embed a picture of a monkey.
That’s the whole idea. Keep everything money needs. Remove the loophole that turned Bitcoin into a hard drive.
The proposal also closes a few other data-smuggling tricks, like abusing OP_IF branches to hide skipped data in scripts, and exploiting the undefined Taproot annex as an unlimited data field. Each rule targets a specific vector people use to shove non-financial data into the chain.
And here’s the part most people miss: it’s temporary. BIP 110 auto-expires after one year. If the Bitcoin community decides it was a mistake, they literally have to do nothing and it goes away on its own. No second vote required. No action needed. It just stops.
“Isn’t this censorship?”
No. And this distinction matters.
Censorship means blocking valid transactions based on who sent them or where they’re going. BIP 110 doesn’t care who you are, where you live, or what you’re buying. It doesn’t block any monetary transaction. It doesn’t blacklist addresses. It doesn’t require identity verification.
What it does is disable an unintended feature that was never designed to exist.
Here’s an analogy: your email provider has a 25MB attachment limit. Is that censorship? Of course not. It’s a design decision that keeps the system functional for its intended purpose, communication, by preventing people from using it as a file-sharing service.
Bitcoin limiting data pushes to 256 bytes is the same thing. It’s a design decision that keeps the network functional for its intended purpose, money, by preventing people from using it as a distributed hard drive.
In fact, if you care about censorship resistance, you should support BIP 110. Here’s why: when inscription spam drives fees through the roof, regular people can’t afford to make on-chain transactions anymore. They get pushed to custodial services like exchanges, payment processors, and hosted wallets. And custodial services can be censored, regulated, frozen, and shut down.
Data spam doesn’t just compete with payments. It actively undermines the censorship resistance that makes Bitcoin valuable in the first place.
“But what about multisig? Wallet developers say it breaks things!”
One of the most persistent concerns around BIP 110 is that it threatens Taproot multisig setups, particularly the privacy-preserving kind where keys aren’t revealed to outside observers. This matters because tools like Nunchuk, Liana, and Sparrow are actively building toward a future where exchanges and large holders use Taproot multisig as the standard for private self-custody.
Here’s the thing: the wallet developers themselves have clarified this. When Nunchuk was asked directly about the impact of BIP 110 on their users, their technical breakdown was clear on three points.
First, the vast majority of multisig usage today runs on legacy or SegWit addresses. BIP 110 has zero impact on any of it.
Second, the Taproot privacy gains everyone is excited about, where multiple keys aggregate into one so that no observer can distinguish a multisig from a single-sig transaction, come from MuSig and Schnorr signatures. Nunchuk confirmed that MuSig is not impacted by BIP 110.
Third, the only area with any potential impact is advanced Taproot Miniscript that uses OP_IF inside tapleaves. And as Nunchuk themselves pointed out, that’s a compiler-level concern, not a wallet-level one. The fix is straightforward: split OP_IF branches into separate tapleaves, which is already best practice for Taproot script design.
Now, to be fair: that fix isn’t always free. Take a simple business treasury policy: Alice must always sign, and then either Bob co-signs or a timelock kicks in as a fallback. With a single OP_IF script, the unexecuted timelock branch is only about 5 bytes of revealed script. Split it into two Taproot leaves and you add a 32-byte Merkle proof to the control block. You’re paying 32 bytes to hide 5. In certain wallet configurations, OP_IF is genuinely cheaper.
This matters because Miniscript, the tool that standardizes these kinds of wallet constructions, is one of the most important engineering projects in Bitcoin. Self-custody is the cornerstone of everything: Layer 2 protocols, privacy tools, all of it is meaningless if you can’t secure your coins on the base layer. The evolution from single-sig to multisig to decaying multisig with timelocks, where security gradually relaxes so heirs or business partners can recover funds, is the natural trajectory of Bitcoin custody. Miniscript makes that future interoperable across wallets. It is not a niche concern.
BIP 110’s own specification acknowledges this tradeoff directly. Its position: temporarily requiring users to split OP_IF branches into separate tapleaves, even at a modest byte cost, is worth it to send an unambiguous signal that Bitcoin is money, not a data storage platform. That’s a defensible argument. But anyone telling you there’s zero cost to wallet developers is wrong, and anyone telling you the cost is catastrophic is also wrong.
And remember: it auto-expires after one year. If the community decides it was the wrong call, the restrictions disappear on their own without anyone lifting a finger.
The bottom line: if you’re using multisig today, or planning to move to Taproot multisig for privacy, BIP 110 does not stand in your way.
“But what about frozen funds?”
This is the biggest piece of FUD floating around, so let’s address it head-on.
Critics claim BIP 110 could freeze or confiscate people’s bitcoin. Let’s look at what would actually have to be true for that to happen. All five of these conditions would need to be met simultaneously:
The coins are in a Taproot (P2TR) output
The coins are locked in a pre-signed transaction
The coins must be both confirmed and spent during the one-year deployment window
The specific Tapleaf being used to spend them violates one of BIP 110’s rules (contains OP_IF or sits deeper than 7 levels in the Taptree)
There is no other way to spend the coins: no keypath, no other valid Tapleaf in the tree
If even one of those conditions isn’t met, the funds are completely fine.
How likely is this scenario? Extraordinarily unlikely. The vast majority of Bitcoin users don’t use Taproot at all yet. Of those who do, almost none use deep Taptrees or exotic Tapleaf constructions. Of those who do, almost all have a keypath spend available as a backup.
But BIP 110 goes even further to protect users:
UTXOs created before activation are completely exempt. The new rules only apply to outputs created after the fork activates. Your existing coins are untouched.
There’s a two-week grace period between lock-in and activation, giving anyone with edge-case setups time to move their funds.
Could someone, somewhere, theoretically be affected? In the most extreme edge case, maybe. But we’re talking about a scenario so unlikely it’s like worrying about a meteor hitting your house while your house is on fire. The fire, inscription spam consuming 37% of block space and pricing regular users out of the network, is the actual emergency.
And here’s the part that’s quietly revealing: critics never argue that BIP 110 would break inscriptions. They skip straight to hypothetical inheritance schemes. That’s a tacit admission. They know inscriptions are an attack on the network, not a legitimate use case, so they don’t even bother defending them. The only argument left is a scenario so convoluted it requires someone to be simultaneously expert enough to build a depth-8 Taptree with OP_IF conditions and pre-signed timelocked transactions, yet oblivious enough to ignore a widely-discussed soft fork activating on the network they depend on.
“Won’t this hurt innovation? What about BitVM?”
BitVM and similar experimental protocols use large Taptrees that could theoretically bump against BIP 110’s 128-leaf limit. This is a real tradeoff, and supporters of BIP 110 acknowledge it openly.
But let’s put it in perspective:
BitVM is experimental. It’s not in production. It’s being developed on testnet and signet.
BIP 110 lasts one year. BitVM developers can continue all their work on testnets and sidechains.
The restriction expires automatically. No one needs to do anything for BitVM to regain full mainnet capability.
The question isn’t “does BIP 110 have any tradeoffs?” Of course it does. The question is: “Is one year of mild inconvenience for experimental protocols worth protecting Bitcoin’s core function as money?”
If Bitcoin’s block space becomes permanently dominated by data storage, there may not be a functional monetary network left for BitVM to build on.
“But someone already fit the whole BIP on-chain!”
Yes, a prominent Bitcoin developer did exactly this as a protest, embedding the entire BIP 110 text into Bitcoin transactions. And ironically, it’s actually a point in favor of BIP 110, not against it.
What the stunt demonstrated is that you can still embed data on Bitcoin by breaking it into small chunks spread across many transaction fields. And that’s true. BIP 110 doesn’t claim to make data storage impossible. It claims to make it impractical and expensive enough that it’s no longer worth doing at scale.
Think of it this way: you can technically move a couch through a window. But when you remove the front door, most people stop trying to move couches into the building. The few who are determined enough to do it through the window are paying a steep cost in effort and fees for the privilege.
Right now, inscriptions are walking through the front door with a moving truck. BIP 110 closes the door. Can a determined person still smuggle data in? Sure. But casual, industrial-scale data dumping, the kind that fills 37% of block space, becomes economically unviable.
The point isn’t perfection. The point is making Bitcoin’s position clear: this is a monetary network, not a storage platform. Act accordingly.
The real question nobody’s asking
Here’s what gets lost in all the technical back-and-forth:
If Bitcoin isn’t money, what is it?
Because right now, 37% of Bitcoin’s block space is being used to store data that has nothing to do with payments. Node operators, the volunteers who make Bitcoin decentralized, are subsidizing this storage with their own hardware and bandwidth. Fees for normal payments are higher than they need to be. And developer attention that should be going toward Lightning, privacy, scaling, and UX improvements is instead being consumed by an endless debate about what kind of data should be allowed on-chain.
BIP 110 doesn’t answer every question. It doesn’t solve spam forever. It doesn’t claim to.
What it does is buy Bitcoin one year of breathing room. One year where developers can focus on monetary improvements instead of playing whack-a-mole with data exploits. One year where node operators aren’t forced to download and store an ever-growing pile of JPEGs. One year where the network sends an unambiguous signal: Bitcoin is money first. Everything else is secondary.
And if, after that year, the community decides the restrictions were wrong? They expire automatically. No harm done.
What you can do
If you agree that Bitcoin should prioritize being money:
Run a BIP 110 node. The activation client is built on Bitcoin Knots v29.2 and is available at bip110.org. Over 1,800 nodes are already signaling support.
Talk to your mining pool. Miners decide whether this activates. Ask your pool operator to signal bit 4. The threshold is 55%, which is far more achievable than the usual 95%.
Spread the word. Most of the opposition to BIP 110 comes from people who profit from inscriptions or haven’t read the actual proposal. Share this article. Have the conversation.
Bitcoin has survived the block size wars, the SegWit2x coup attempt, and every altcoin that claimed to replace it. It can survive a one-year timeout on data spam.
The only question is whether we care enough to act.
BIP 110 was authored by Dathon Ohm and assigned its number on December 3, 2025. The full technical specification is available at bips.dev/110. The Bitcoin developer mailing list discussion can be found here.