BIP 110 and the issue of Bitcoin blocking the way

Author: Kyle Santiago

Source: https://privkey.substack.com/p/bitcoin-has-a-squatter-problem-bip

Imagine you've built a highway. Its purpose, of course, is to transport people and goods from point A to point B, as quickly and cheaply as possible.

Now, some people have discovered they can park their RVs on this highway, one after another, treating it like a free parking lot. Of course, they pay—the highway toll—but other drivers are stuck in traffic, unable to move despite paying the toll, forced to burn more gas, and wondering how the highway they helped build has become a parking lot.

This is what's happening with Bitcoin right now. BIP 110 is a "no parking" sign.

What's happening on Bitcoin

Bitcoin was designed to achieve one thing at its finest: the ability to transfer value without anyone's permission. No bank permission, no government permission, and no intermediary permission is needed. It's peer-to-peer electronic cash—this is stated in the white paper.

In 2022, a clever hacking technique was discovered: by exploiting a feature of Taproot (Bitcoin's latest upgrade), hackers could insert data of any format into Bitcoin transactions, such as images (JPEG format), videos, and even entire documents. They called this technique "inscriptions." Overnight, the Bitcoin blockchain became a dumping ground for monkey images and memes.

(Translator's note: Bitcoin's consensus rules have never prevented users from writing data unrelated to Bitcoin's cryptographic security to the blockchain, either directly or in a disguised form. However, prior to Taproot, various writing methods were subject to size limitations at the consensus level and/or transaction propagation restrictions. The Taproot upgrade removed the size limit on witness script objects, and inscriptions leveraged this to achieve the first unrestricted data writing method that is neither limited in size (no file fragmentation required) nor in propagation.)

Here's the problem: every Bitcoin node on Earth must download, verify, and store this data. Forever .

Those who uploaded 4MB images to the Bitcoin blockchain only paid the miners a one-time fee. Once the miners received their fee, they were free to do nothing. But what about the thousands of volunteer nodes? They bear the storage, bandwidth, and verification costs for the entire lifecycle of Bitcoin without receiving any clear reward.

This isn't a free market working as expected; it's a market failure. Those dumping data gain perpetual, uncensorable storage space spread across the globe. And those who increase this storage space are never asked if they want it, and will never be compensated. Economists call this an " externality ." Ordinary people call it a "free-rider."

The painful part is that the vast majority of us support Taproot because it improves multi-signature (wallet) functionality. It allows complex spending conditions, such as multi-signature and time-locked backup paths, to be hidden until they are actually used. This results in smaller transactions, lower fees, and better privacy for real users. That's why it's so exciting. Nobody has ever mentioned that Taproot's benefit lies in offering discounts when uploading images to the blockchain.

(Translator's note: In the inscription method, unqualified data is part of the witness script of the transaction input. The witness script receives a discount when calculating the nominal volume, incurring lower fees compared to other fields of the same transaction size. This discount stems from the Segregated Witness upgrade and makes sense from a verification cost perspective, as the same number (volume) of Segregated Witness signatures are cheaper to verify than traditional signatures. However, block verification incurs not only computational costs but also storage costs. As the volume of unqualified data increases and the proportion of signature volume decreases, the situation deviates from the general scenario that justifies this discount.)

But this is exactly what happened. By using OP_FALSE OP_IF opcode combination in plaintext, data was stuffed into a portion of the Taproot witness script that wouldn't be executed, thus gaining a 75% fee discount (due to the way Segregated Witness calculates witness data volume). A scaling technique was transformed into an anti-scaling technique. Since 2023, the size of the UTXO set has doubled. Synchronizing new nodes has become noticeably slower since synchronizing blocks from 2023.

(Translator's note: Inscription methods do not directly cause UTXO set bloat. One factor contributing to the significant UTXO set bloat since 2023 is the popularity of off-chain smart contract protocols that use inscription methods.)

Bitcoin Core could have patched this vulnerability in 2023 when inscriptions were just becoming popular, but they didn't. Instead, by 2025, they had relaxed the propagation restrictions on OP_RETURN outputs. BIP 110 is the fix they refused to release.

(Translator's note: This refers to the fact that, starting with Bitcoin Core v30.0, one of the default transaction forwarding rules—that a transaction can carry at most one OP_RETURN output, with a size of no more than 82 bytes—has been relaxed to allow multiple OP_RETURN outputs, with no requirement on the total size. An OP_RETURN output is a transaction output that cannot be spent and therefore will not enter the UTXO set; it can be used to carry unrestricted data.)

What does BIP 110 need to do?

Putting aside the technical jargon, what BIP 110 is trying to do is simple: temporarily limit the amount of data you can stuff into a single field of a Bitcoin transaction to 256 bytes.

Background information:

• A Bitcoin address is 34 bytes.
• A cryptographic signature on Bitcoin is 64-72 bytes.
• A 2048-bit public key can fit into 256 bytes of space.
• A JPEG image can require thousands or even millions of bytes.
• 256 transactions

256 bytes is enough for any imaginable financial transaction. But it's not enough to embed a monkey emoji.

This is the whole idea behind BIP 110: retain what Bitcoin needs to function as a currency and plug the loopholes that would turn Bitcoin into a hard drive.

This proposal also blocks the measurement of other smuggled data, such as the abuse of OP_IF branches in scripts to hide data (these conditional branches are skipped) and the use of the undefined Taproot Annex as an unrestricted field. Each rule targets an interface that has been used to embed non-financial data into the blockchain.

Moreover, there's something most people overlook: it's temporary . BIP 110 will automatically expire after one year. If the Bitcoin community deems it a mistake, they don't need to do anything; it will simply disappear. No second vote, no action required—it will terminate automatically.

Isn't this a form of censorship?

No. There's a significant difference.

"Censorship" means blocking valid transactions based on the sender's identity or destination. BIP 110 doesn't care who you are, where you live, or what you're buying. It doesn't block any monetary transactions. It doesn't have blacklisted addresses, and it doesn't require identity verification.

It simply disables some unexpected features that don't align with the design goals.

To illustrate, imagine your email provider allows 25MB of attachment space per email. Is that censorship? Clearly not. It's a design choice to make the system work for its intended purpose—communication—and not for people to use it as a file-sharing service.

Limiting a single Bitcoin transaction to 256 bytes conveys the same idea. It's a design choice to make the entire network work for its intended purpose—currency—and not to let people treat it as a shared hard drive.

In reality, if you truly care about censorship resistance, you should support BIP 110. This is because when inscription overabundance causes transaction fees to skyrocket, ordinary people will find it unaffordable to send on-chain transactions. They will be pushed to use custodial services, such as exchanges, payment processors, and custodial wallets. Furthermore, custodial services may be subject to censorship, regulation, freezing, and shutdown.

Data bombardment will not only compete with payment transactions, but will also actively undermine the censorship resistance that gives Bitcoin its value.

"So many signatures? The wallet developer says it will mess up multi-signature!"

One of the most persistent concerns regarding BIP 110 is that it threatens Taproot multisignature devices, especially those designed for privacy—where the signer's key is not exposed to external observers. Such devices are important because Nunchuk, Liana, and Sparrow are actively working to establish Taproot multisignature as the standard for privacy-preserving, self-managed devices.

Well then: the wallet developers themselves have clarified it. When Nunchuk was asked about the impact of BIP 110 on their users, their technical analysis was very clear.

First, the vast majority of multi-signature devices today use traditional or segregated witness addresses. BIP 110 has no effect on them.

Secondly, the Taproot privacy benefit that excites everyone—multiple public keys are aggregated into one, so external observers cannot distinguish between multi-signature and single-signature transactions—comes from the Shcnorr and MuSig signature schemes. Nunchuk confirmed that BIP 110 has no impact on MuSig.

Third, the only potentially affected area is high-level Taproot Miniscript scripts, which use OP_IF opcode in the leaves of the script tree. However, as Nunchuk himself points out, this is a compiler-level concern, not a wallet-level one. The fix is ​​simple: split OP_IF branch into a dedicated leaf, which is best practice in Taproot script design.

Now, let's be realistic: BIP 110's fix isn't without its costs. Take a simple corporate finance example: First, Alice must sign anyway; second, either Bob is a co-signer, or the time lock is unlocked. In a script using OP_IF , the time lock branch that isn't executed only takes up 5 bytes in the revealed script; but splitting it into two Taproot leaves requires adding a 32-byte Merkel evidence to the control block of the spending script. Paying 32 bytes just to hide 5 bytes. In certain wallet configurations, OP_IF is indeed cheaper.

The significance of these things lies in the fact that Miniscript, the tool that standardizes the construction of these wallets, is one of the most important engineering projects on Bitcoin. Self-custody is the cornerstone of everything: Layer 2 protocols, privacy tools… If you can't safeguard your own coins at the base layer, they all mean nothing. The evolution of Bitcoin custody from single-signature to multi-signature, and then to decremental multi-signature using time locks (where the spending requirement gradually decreases so that the successor or partner can recover the funds) is a natural trajectory. Miniscript enables such devices to interoperate between wallet software, and this is not a nitpicking concern.

BIP 110's detailed explanation directly acknowledges this trade-off. Its stance is that temporarily requiring users to split OP_IF branch into taproot script tree leaves, even if it occupies a few extra bytes, is worthwhile. It sends a clear signal: Bitcoin is a currency, not a data storage platform. Whether this argument is reasonable is debatable. However, it's wrong for anyone to tell you that BIP 110 has no impact on wallet developers; similarly, it's wrong for anyone to say that this burden is disastrous.

A reminder: it will automatically expire after one year. If the community deems it a misguided call to action, these restrictions will automatically disappear without anyone having to lift a finger.

Conclusion: If you are using a multi-signature wallet or plan to migrate to the Taproot multi-signature wallet for privacy reasons, BIP 110 will not affect you.

"What about the funding for that motivation?"

This is the biggest psychological fear (FUD) surrounding BIP 110, so let's confront it head-on.

One criticism is that BIP 110 might freeze or confiscate people's Bitcoin. Let's examine the circumstances under which this would have such an effect. The following five conditions must be met simultaneously :

1. Coins are locked in Taproot (P2TR) output.
2. The currency is locked using pre-signed transactions.
3. The currency must be confirmed by a block and spent within the one-year deployment period of BIP 110.
4. The specific leaf script used to spend it violates BIP 110 (it contains the OP_IF opcode, or is below level 7 in the script tree).
5. There is no other way to spend these coins: key paths cannot be used, and there are no other valid leaf scripts in the script tree.

As long as any one of the conditions is false, the funds will be completely unaffected.

How rare is this scenario? Almost impossible. The vast majority of Bitcoin users haven't even used Taproot output. Even among those who have, almost none would use such a deep script tree or intentionally use invalid leaf scripts. And even if they did, they almost always have a key path as a backup spending method.

But BIP 110 goes even further to protect users:

• UTXOs created before activation will be treated as exceptions . The new rules only apply to outputs created after the fork is activated. Existing coins will not be affected.
• There is a two-week grace period between the soft fork lock and activation, so people using these rare configurations have time to transfer their funds.

Is there anyone, under what circumstances, even theoretically, who might be affected? In very extreme cases, perhaps. But these situations are extremely rare, like worrying about a meteorite hitting your house when it's already on fire. The inscription overload is that fire, having already burned 37% of the block space and driven away many ordinary users; that's the truly critical issue.

(Translator's note: The figure "37%" appears multiple times in the text, but the author does not explain how it was calculated. Readers can obviously find instances where the percentage is larger or smaller.)

Here's another very telling point: critics never argued that BIP 110 would destroy inscription. They jumped straight to the hypothetical inheritance scheme. That's a default assumption. They knew inscription was an attack on the network, not a legitimate use, so they didn't even bother to defend it. The only remaining argument is based on an extremely complex scenario: someone who is a highly skilled expert, capable of constructing script trees deeper than 8, with OP_IF conditions in leaf scripts, spending coins with pre-signed time-locked transactions, while simultaneously ignoring the widely discussed soft forks on their network.

"Won't this hurt innovation? What about BitVM?"

BitVM and similar protocols use large taproot script trees, which theoretically could indeed violate the 128-leaf (7-level script tree) limit of BIP 110. This is a genuine trade-off, and BIP 110 proponents have openly acknowledged this.

But let's look at this issue from another perspective:

• Citrea is the first sidechain based on BitVM, launching in 2025. However, their bridging contract already uses Taproot outputs and is within the limitations of BIP 110. Protocols requiring Bitcoin should not be developed on the data writing interface disabled by BIP 110.
• BIP 110 will last for one year. Any protocols that clearly require a larger script tree can continue development on the testnet and sidechain.
• The restrictions will expire automatically. No one will need to pay a price to regain their previous abilities.

The issue isn't about "what BIP 110 sacrifices," of course it does. The question is: "Is it worth enduring a year of inconvenience for this experimental protocol in order to protect Bitcoin's core function as a currency?"

If Bitcoin's block space is forever occupied by data storage, there may not be a usable currency network left for BitVM to develop.

"Someone has already written the entire BIP onto the blockchain!"

Yes, a well-known Bitcoin developer did this to show his opposition: he included the entire text of BIP 110 in a Bitcoin transaction. Ironically, this actually helped BIP 110, rather than attacked it.

This event demonstrates that you can still embed data into the Bitcoin blockchain by cutting it into small segments and distributing it across multiple fields in a transaction. Indeed, BIP 110 doesn't say it can ban data embedding. It only says it should make such operations inconvenient and expensive , so expensive that it's no longer worthwhile to do it on a large scale.

You could say this: theoretically, you could move a sofa through a window. But if you remove the front door, most people won't even consider moving the sofa inside. Those who insist on using the window will pay a high price for this privilege, and it will require a lot of effort.

Now, inscriptions are like a moving truck passing through the front door. BIP 110 is closing the door. Can someone determined enough still manage to stuff data in? Of course. But large-scale, arbitrary data dumping, such as occupying 37% of the block space, becomes economically unfeasible.

Therefore, the purpose of BIP 110 is not to completely eradicate Bitcoin, but to make its position clearer: it is a monetary network, not a storage platform. Please respect this.

"Won't this cause the chain to break?"

Perhaps, but every soft fork in Bitcoin's history carries this risk.

Segregated Witness (SegWit) introduces the risk of blockchain splitting. Taproot is no exception. This risk exists with any consensus change, including BIP 110. The question isn't whether a blockchain split is possible , but rather under what circumstances it might occur.

If BIP 110 lacks economic support, the nodes supporting it will stagnate. They will remain on what they believe to be the last valid block, waiting for a signal block that will never arrive. The main chain will continue producing blocks as if nothing has happened. In this case, there will be no chain split, and no one will be harmed. In other words, BIP 110 has quietly failed.

If BIP 110 receives substantial economic support, with exchanges, businesses, and users all backing it, miners will face the same choice as during Segregated Witness: mine blocks backed by the majority of economic power, or mine blocks that are increasingly rejected. In 2017, over 80% of nodes forced the last dissenting voice (Bitmain) to back down before UASF (User Activated Soft Fork). The miners' defection wasn't driven by ideology, but by economic incentives that left them with no other option.

BIP 110 hasn't garnered as much support yet. The percentage of supported nodes is gradually increasing, but it's still only in the single digits, and no major exchanges have publicly endorsed it. Economic consensus is forming, but it's not yet guaranteed. This is where the significance of running a node becomes apparent: it's a way to send signals.

One more thing: expressing support requires no cost to miners. It merely changes the value of a single bit. Remaining silent, however, creates a long-tail risk as support gradually increases. Even if the probability of activation is small, when the cost is zero, compliance becomes the default rational choice. Once large mining pools express their support, a "prisoner's dilemma" arises—no one wants to be the last one on the wrong side.

In the worst-case scenario, a persistent blockchain split could occur—two blockchains competing against each other. This has never happened in the history of Bitcoin soft forks. Not even once. The losing side always returns. The one-year expiration of BIP 110 makes a long-term split even less likely: even if they clash head-on, the limitations of BIP 110 will automatically disappear.

The real question that no one is asking

In all the back-and-forth communication about technical details, the truly neglected issue was:

If Bitcoin isn't a currency, then what is it?

Currently, 37% of block space is used to store data completely unrelated to payments. Node operators voluntarily decentralize Bitcoin, yet they have to subsidize this storage with their own computer hardware and bandwidth. Transaction fees for ordinary transactions exceed what should be paid. Developers' attention, which should be focused on the Lightning Network, privacy, scalability, and improved user experience, is consumed by the endless debate about what kind of data should be allowed to be written to the blockchain.

BIP 110 cannot answer all questions. It also cannot eradicate spam. It never said that.

All it did was give Bitcoin a year to breathe. It gave developers a year to focus on improving currency performance instead of playing whack-a-mole with data write vulnerabilities. Node operators also had a year to avoid being forced to download and store these ever-growing piles of images. During this year, the network could send a clear signal: Bitcoin is first and foremost a currency. Everything else is secondary .

What if the community decides that the restriction is wrong a year later? Then it will automatically expire and will no longer cause harm.

What you can do

If you also believe that Bitcoin should prioritize its monetary function, then you can:

• Run a BIP 110 node . This activation client is built on top of Bitcoin Knots v29.2 and can be downloaded from bip110.org . Currently, over 1,800 nodes have indicated support.
• Contact your mining pool . Miners have indicated they can expedite activation, but regardless, nodes supporting it will activate BIP 110 at block height 965,664. Request your mining pool operator to indicate support using a semaphore bit of 4. Accelerated activation requires 55% miner support, which is easier to achieve than the usual 95%.
• Speak up . The vast majority of opinions opposing BIP 110 come from people who have benefited from the inscription or haven't read the actual proposal. Share this article to spark discussion.

Bitcoin survived the block size wars and the SegWit2x conspiracy, defeating every Altcoin that claimed to replace it. It could certainly survive a year without data overload.

The only question is whether we care about it enough.

- - -

BIP 110, written by Dathon Ohm, was assigned a BIP number on December 3, 2025. A full technical description can be found at bips.dev/110 . Discussions in the Bitcoin developer mailing list can be found here .

(over)