The Case Against BIP110
by Satonymous
2026-June-11 UTC
This is to state the case against BIP110, and to bring awareness to various identified vulnerabilities and flaws with the planned BIP110 chain.
There is an upcoming bitcoin fork known as BIP110 which takes place in August 2026. Although the miners signalling support for this is currently less than 1%, the supporters of BIP110 even if not the majority, are very outspoken online on their support for BIP110, much more so than those against BIP110. Support of BIP110 I am claiming mainly results from a lack of awareness of the truth, lack of adequate technical understanding of Bitcoin, and in believing fallacies as they are misled by well known influencers. For if people knew the truth and knowledgable, they would be against BIP110, which I am explaining here. I've been into Bitcoin from the very early days, and a long time cypherpunk, one cannot say that I am against Bitcoin's use for monetary purposes only, nor unknowledgeable about Bitcoin. I've seen this before and this feels very similar to the segwit battle and the resulting junk-coin which forked off of Bitcoin known as bcash. It is no coincidence that people with technical understanding of Bitcoin and technical competence are against BIP110. BIP110 support generally comes from people who are newer to Bitcoin or lack a technical understanding of Bitcoin.
The very short summary of this article is this. Being against BIP110 is not supporting spam. BIP110 does not fix anything as it claims to. BIP110 is a planned permanent hard-fork that will be incompatible with Bitcoin, instead of a temporary soft-fork as it claims to be. The BIP110 chain will have numerous flaws and vulnerabilities as detailed below. What I am saying here is not opinion but rather fact which can be verified.
A brief simplified explanation of BIP110, BIP110 is a set of new Bitcoin rules which define what transactions are and are not allowed. Its intent is to temporarily stop non-monetary spam transactions, and these restrictions are in place for one year after which the restrictions are lifted again. BIP110 would activate for nodes running BIP110 if at least 55% of mined Bitcoin blocks signal for BIP110 support, otherwise BIP110 nodes are hard-forking themselves in August 2026 regardless of miner support to create a new coin called BIP110-coin to compete with Bitcoin.
And now my case against BIP110 explained;
- Opposition to BIP110 is not supporting spam.
The majority of BIP110 critics are not pro-spam, and the debate of BIP110 vs. anti-BIP110 is not a matter of pro-spam vs. ani-spam. Rather, critics of BIP110 are against it because they realize it does not fix anything as it claims to, and that it is being poorly implemented. This is a case of the claimed cure being worse than the problem itself. BIP110 supporters use fallacies that appeal to emotion rather than logic, combined with falsely framing the BIP110 debate as being pro-spam vs. anti-spam instead of whether BIP110 itself is a good idea or not. Even if BIP110 were a good idea, its implementation is flawed. - BIP110 does not fix anything as it claims to.
Reason 1- BIP110 filters are only temporary. After a year of activation, BIP110-coin will be exactly like Bitcoin again for better or worse, except that BIP110-coin will be worth nothing or very little, and be incompatible with Bitcoin as a result of its own self-inflicted fork. Although the changes that BIP110 claims to do are temporary, the fork is permanent. This temporary implementation of the filters makes the permanent hard-fork pointless.
Reason 2- BIP110 does not actually stop spam. Someone already figured out how to spam a blockchain with images in a way that bypasses BIP110 filters. (source: knotslies DOT com) - BIP110 is a planned permanent hard-fork, not a temporary soft-fork. BIP110 promoters are misleading people.
- BIP110 will be incompatible with Bitcoin after the fork.
This will be problematic because when BIP110 users try to make Bitcoin payments, in their alternate reality they think they made a Bitcoin payment but they actually did not because they are on a different chain, they will end up losing their BIP110 coins. Likewise, if someone is using BIP110-coin and falsely saying they are accepting Bitcoin for payments, they will end up claiming that a sender did not send them payment when the sender actually did pay them (using Bitcoin). BIP110 users will have to choose to either keep using Bitcoin, or to use BIP110-coin due to the lack of replay protection. Without distinction between BIP110 chain and the Bitcoin chain being communicated by both the sender and recipient of a transaction, these described problems will come up. Bitcoin users will continue to call the non-BIP110 chain as Bitcoin, and so the only way forward is for BIP110 users to admit that BIP110 will be its own coin and to call it what it is, BIP110-coin. People who choose to use BIP110-coin will opt into a chain with no market cap, no value, and of no use as no known exchanges or businesses are planning on accepting BIP110-coin. BIP110-coin will also be incompatible with the current lightning network, and so BIP110-coin users would have to create their own new lightning network. - BIP110 being a temporary set of filters, demonstrates a lack of technical confidence and a lack of testing. It was made temporary because of lack of confidence in the effects it may have.
- BIP110 is a scam.
BIP110-coin and its supporters will falsely claim that their new coin is the real Bitcoin when it is not and will not be. This deception may even cause confusion to people and may cause people to be scammed out of their money by buying fake Bitcoin (BIP110-coin). BIP110-coin is a planned altcoin that is already trying to deceive people into thinking it is Bitcoin. - Core did not make any changes to Bitcoin to allow for spam.
Although this is unrelated to BIP110, I am mentioning this as an example of one of the many fallacies that many BIP110 supporters claim. Many BIP110 supporters think that maintainers of Core (Bitcoin's most popular node implementation) made new changes to the Bitcoin protocol rules to allow for spam. This is not true. There never was an OP_RETURN size limit for Bitcoin transactions, and Core did not remove the ability for nodes to set OP_RETURN size limits for transactions in their mempools. I'm not defending Core here, I'm just pointing out one of the many fallacies and misunderstandings that are used to get people to support BIP110. I personally do not support the removal of the default mempool policy limiting OP_RETURN though it still remains an option for nodes even if not the default. It is an error to say that Core removed the ability for nodes to control their mempool policy regarding OP_RETURN and that Core removed the OP_RETURN limit at the protocol level. But again, the scope of this article is not about Core vs. other implementations. Rather, it is about the flaws with the proposed solution known as BIP110. - BIP110-coin will be on a broken and vulnerable minority chain with 4 identified vulnerabilities and flaws with the BIP110 chain.
As of now, less than 1% of miners are signalling support for BIP110. In a few months BIP110 nodes will no longer acknowledge the majority of Bitcoin blocks and BIP110 nodes will only acknowledge BIP110 blocks. This means that BIP110 will become its own coin, BIP110-coin.
1: Because BIP110-coin has no planned abrupt difficulty adjustment, the difficulty requirement on BIP110-coin blocks will be significantly higher than the amount of hashrate on BIP110-coin. As a result, BIP110-coins blocks will take at least 16 hours on average to confirm assuming that BIP110-coin hard-forks with the current miner support of less than 1%. It will also take the BIP110-coin chain almost 4 years just to reach the difficulty adjustment period to bring the confirmation time of BIP110-coin transactions back down to 10 minutes. For nearly 4 years, BIP110-coin will take 16-17 hours just for one confirmation of a transaction if miner support does not increase.
2: Then if BIP110-coin eventually lasts long enough to reach the difficulty adjustment period without any increase of hashrate, it would be a significant (99%) drop in difficulty requirement making BIP110-coin vulnerable to 51% attacks, orphaned blocks, double spends, and transaction censorship.
Even if more miner support did eventually come over to BIP110, that would create other issues which I will proceed to explain,
3: BIP110 is already destined to be the minority chain compared to Bitcoin by its planned hard-fork with currently less than 1% of miner support. Even if BIP110-coin were to eventually gain more miner support, the longer time goes on after the fork, the harder and harder it becomes for it to ever become the longest chain due to a lack of immediate difficulty adjustment upon fork activation. The Bitcoin chain would grow faster than the BIP110 chain.
4: Even if the BIP110 chain were to implement an immediate difficulty adjustment upon fork activation, it would with certainty make itself permanently incompatible with the Bitcoin blockchain and never be able to become the longest blockchain due to mining and building on blocks below Bitcoin's difficulty requirement. The sudden drastic drop of BIP110 difficulty would also make it immediately vulnerable to 51% attacks sooner rather than delaying that vulnerability by almost 4 years.
There is no way for BIP110 to win without a majority of miner support pre-activation, and its planned hard-fork without majority consensus is its own self-inflicted suicide.
In summary, BIP110 does not actually fix anything, and even if BIP110 was a good idea, it is dead on arrival due to its flawed implementation. BIP110 supporters are failing to see these flaws and how they will be self-inflicting destruction upon themselves. BIP110 is irresponsible and misleading, and I fear many will fall victim to it. Many people who are not really tech-savvy are following the BIP110 promotion by influencers online without realizing the disastrous consequences that BIP110 will have on their funds and well-being.
Why do you think that the debate has been so plagued with people misunderstanding each other?
That's by design, both camps are funded by the same hidden hand, the one pushing for covenants
Both camps exist to be divided such that when their leaders get the unification signal there will be few unfactioned left to resist.
This is observable in how BIP-110 forces a wedge directly into the conservative faction of Bitcoin. By making BIP-110 a "User-Activated Soft Fork" (UASF), it forces purists to choose between aggressive protocol intervention or letting the chain bloat. The Result being the unified front against base-layer changes is broken.
Once the taboo of forcing a soft fork via minority signaling is normalized, the psychological barrier to activating covenants is completely gone. The precedent changes from never changing the base layer to changing it when the base layer when the crisis is big enough.
I feel dense, but whose is the hidden hand?
That's what I want to know. Conspiracy theories are great but ultimately useless. Let's define the camps. Who are the actors and what are their motivations? Shadowy cabals are great and all but I'd really like to hear the specifics.
Going out on a limb here: there aren't any specifics.
Both camps are just masses of people with various motivations acting and reacting to an ever changing landscape of ideas and convictions. Bitcoin mururations (ref: starlings) if you will.
Conspiracies aren't theories, they are facts, a predictable outcome of incentives
#1509782
Where there is an incentive to organize to effect change, there is an organization working to effect change
Conspiracy is a mode of action, psyops are used to illicit reaction
Yep, those are words. Was looking for some specifics. Who exactly is "they" pulling the strings of the two camps? Who is behind the curtain? Who is the invisible hand controlling us?
The lines between intelligence agencies and industry are blurry, same way that industries use regulation to protect against competition. The government is just a giant corporation where industry colludes.
If the large entities get their way and enable Bitcoin delegation, it gives leverage to their existing systems of control.
Think withdrawing your Bitcoin from an exchange, if they use covenants they can revoke your coin after you've withdrawn or make sure you don't send it to someone they don't like... Fake L2's getting acquired by the big banks... Stablecoins that trace back to your Bitcoin stack after you sell on a "DEX"... coordinators everywhere conducting surveillance...
The possibilities with covenants are endless, none of them good.
How so? I still supply the withdrawal address, which means I specify the locking script?
You think they won't let me withdraw unless I withdraw to a cucked address? Seems like no one would bother doing that. And it would just become a thing where if you buy on an exchange, you know you can't actually get the bitcoin, which means anyone who wants actual bitcoin won't buy on exchanges.
I don't see how the possibilities with covenants are so endless. Receiver's produce addresses, if the person won't send to my address, it's no different than a bcasher saying they can't send to my address.
Once the option is available it will become required, no exchange will be allowed to operate if they allow withdrawals to non-cucked outputs. Regulatory capture all over again.
You may not like it, but most will accept it graciously, under the guise of being protected from account hacks or scams. Non-covenant coins will become the exception, eventually you may not even be able to sell it for dollars in any meaningful amount. Sorry Scoresby Jr, no family vacation this year, Daddy has black market coins.
Larping with p2p exchanges can be fun if you're into frivolities, but that's not what moves the coin market.
It's exactly the same as colored coins and other anti-fungibility schemes Bitcoiners used to rail against when they weren't distracted by shit like BIP-110
Which is exactly why the vaults use-case for covenants is retarded, but that's a separate matter.
EXACTLY. See the case of Spark.... first they introduce it slowly to make people comfortable and "excited" to use it, then baaaam wil lbe required all over and with a full KYC.
You paint a grim picture of things. I don't see it playing out this way. But perhaps it comes down to how big a market will the black market be. If it gets big enough, the point becomes moot. As much as governments love their authority, it's hard to keep tabs on billions of humans. Unless we build ourselves a nice cage.
In any case, Scoresby jr wil just have to go on vacation to the yakuza opium dens and calabrian wine cellars of the mafia.
It doesn't have to be this way, Bitcoiners could just stop being retarded for a minute and not bandwagon jump when some NGO soy-dev says they should support an OP_Code that will delegate their coins.
Larping with p2p? What's wrong with p2p? (And please stop using metaphors...)
This is the real joke of it all.
OP_0 OP_IFin p2sh scriptsigs will simply thrive on a BIP-110 upgraded chain. The only way I see that not happening is if there is a permanent fork and the BIP-110 side fails to overtake the ossified version in exchange rate. Then, the BIP-110 can have their utopian version of Bitcoin, in isolation.At least that wouldn't benefit from the witness discount.
Be careful of what fee pressure you wish for (also it can go into p2wsh too)
All these flags are so visible and open just look for Saylors and politicians being the party interested in directing the spirits of something they do not control, but that make it seem like they do. Every nocoiner comes across them when he enters the bitcoin universe, the amount of shit about bitcoin sold on the common network is abundant. Now there are those to divided those who pass through without paying attention for the shit.
That's it. What do you think is bad here ?
Thanks for asking.
RDTS only allows one OP_RETURN output, so that would mean that any systems that embed more than 80 bytes of data in outputs would be forced to use unspendable payment outputs for anything in excess of 80 bytes (like the example that started this debate). Also, what if we want to introduce a PQ-safe output scheme next year that needs more than 34 bytes in its output script?
Seems pointless for reducing data insertion as stack items are already limited to 520 bytes and multiple 256-byte pushes would still be allowed, otoh, such a low limit would probably be incompatible with some future soft forks, e.g., PQ-signature schemes which might need drastically larger public keys and signatures.
Breaks our upgrade hooks for introducing new output types, e.g., if the P2MR proposal were to gain steam in the next ~14 months.
Breaks another upgrade hook, and is unused.
It can only have 128 leaves if all of them are at a depth of 7, which makes the control block 258 bytes. Most P2TR script trees are unbalanced binary trees (think Huffman trees) to make the more likely leaf scripts have smaller control blocks.
So, we don’t need OP_IF, because we can split up scripts into multiple leaves, but then we also limit script trees to a depth of 7? Seems unnecessary and dumb, but most people can probably make due with depth 7. This might be the least offensive rule, yet.
Breaks more upgrade hooks, in a time when some covenant proposals actually had been gaining a little momentum.
Making
OP_IFinvalid is an absolute no-go. Beyondif(…)being the most basic conditional statement in every programming language under the sun, there are a number of projects that have rolled out Miniscript support in mainnet, and Miniscript is known to generate leaf scripts withOP_IFin some circumstances. Since script leaves do not become visible unless used, and most P2TR outputs with more complex spending conditions have an “everyone signs” keypath fallback, it cannot be ruled out that users have deployed wallet patterns based onOP_IFto mainnet. Since we cannot determine whether who such people might be and therefore cannot ensure that all such people are aware, have updated their software, and have migrated away from such wallet patterns, and it generally cannot be prevented that senders reuse past scripts that used such a pattern, this must be considered to break user space on principle. RDTS proponents have argued that this is acceptable, Bitcoin protocol designers generally seem to consider this indefensible.Some further thoughts:
The entire soft fork is based on only processing the first part of what protocol developers have been telling filter proponents for years: policy can be undermined by a tolerant minority, so it is infeasible to establish more strict policies against collaborating senders and miners—transaction patterns can only be effectively forbidden at the consensus level. However, consensus changes move slowly enough that data enthusiasts can easily preempt new consensus rules if their fad hasn’t jumped the shark by itself by then.
RDTS forbids inscriptions and large OP_RETURNs. Meanwhile, inscriptions have diminished to a minuscule portion of blockspace and large OP_RETURNs are basically non-existent, while still almost have the blockspace is going towards other NFT transactions (now based on Runes which RDTS will accept). Numerous ways to embed data even under RDTS rules have been demonstrated.
When someone proposes a consensus change, it is on them to convince the ecosystem that the benefits are worth the cost. The default position is that the status quo is maintained. This consensus change proposal is poorly motivated, recklessly designed, and irresponsibly championed. The doubtful benefits drastically fall short of the downsides and costs.
whether who -> who
almost have -> almost half
BIP 110 compatible blocks are compatible with the current consensus rules. BIP 110 narrows the rules, instead if expanding them. That, by definition makes it a soft fork, not a hard fork the anonymous poster claims.
Soft- vs. hard- fork debates are always a bit unclear. Generally yes, making the rules more strict is a soft-fork and making the rules less strict is a hard fork. But I would argue the test should be: Do existing nodes need to upgrade to remain interoperable with the nodes running the new software? If yes, then that's a hard-fork.
From what I gather, the BIP110 fork would be a hard-fork for two reasons. The BIP110 nodes will reject non-conforming blocks after the August fork date. So they effectively hard-fork themselves off the network. Then they hard-fork themselves again when they revert their previously added filtering rules.
I think this is a terminology issue rather than a disagreement. It’s a soft fork. Existing nodes would not need to upgrade to remain interoperable with BIP110, if it got adopted. If BIP110 had majority support, nodes would follow along just fine. Only miners would, but that’s normal for soft forks. Soft forks enacted by a hashrate minority do lead to a permanent chainsplit.
Image from this explanation on BSE
Usually nodes would disconnect peers that offer an invalid block, so I suspected the same in the past, but some RDTS proponent informed me that RDTS explicitly allows peers to offer blocks that would be valid under the old rules, so I don’t think the RDTS nodes will disconnect from the P2P network immediately.
I disagree with this characterization. Adding more restrictions is a soft fork. Adding restrictions with a limited time frame is still a restriction, not a loosening of rules.
Terminology is extremely important if you want to have meaningful communication.
This should read: Only miners would …have to upgrade…
Sheesh. I should stop moving around sentences after throwing together a first draft for a comment.
Yeah, I also noticed this odd conflation in the OP. Clearly, the rules proposed by BIP 110 constitute a soft fork. However, with the minority hashrate in support the implementing nodes would likely be permanently split from the best chain onto their own chaintip. Since the difficulty would be prohibitive at their current support level (let’s generously say 1% ~> 200 weeks to the first difficulty adjustment), if they double down, they’d likely then follow up with a hardfork that either reduces the difficulty or changes the PoW mechanism.
You should read about UASF vs MASF. UASFs can lead to chain splits.
I am talking about the definition of hard and soft forks in my comment.
Thank you. I have not seen anyone technical supporting BIP110. It is all influencers, misled people, and bots. People who maintained Core for years are against it and it’s for a reason. If you read the mailing list and GitHub, there is plenty of evidence as to why. The reasons presented for supporting this BIP are outright lies and it doesn’t solve any problems it claims to solve.
Doesn't change much, but there's a 4x limit on difficulty adjustments, so the difficulty would drop by 75%, not 99%:
// Verify that the difficulty isn't growing too fast; an adversary with // limited hashing capability has a greater chance of producing a high // work chain if they compress the work into as few blocks as possible, // so don't let anyone give a chain that would violate the difficulty // adjustment maximum. if (!PermittedDifficultyTransition(m_consensus_params, next_height, m_last_header_received.nBits, current.nBits)) { LogDebug(BCLog::NET, "Initial headers sync aborted with peer=%d: invalid difficulty transition at height=%i (presync phase)\n", m_id, next_height); return false; }source
See also this Bitcoin StackExchange question.
I believe the maximum difficulty adjustment drop per period is 25%. So it would take multiple periods of 2016 blocks to lower the difficulty enough to reach the target average of 10 minutes. So 4 years, 3 years, 2 years, 1.5 years, etc...
Apologies, this is incorrect. The actual max. decrease is by a factor of 0.25 (25%). So 4 years, then 1 year, then 3 months, etc.
Oh, just mentioned this myself in #1509975
The difficulty can adjust up to a factor of 4 in either direction. If they activated with 1% of the hashrate (and they maintained the same hashrate indefinitely), they’d take about 200 weeks to reach the first difficulty adjustment, then 50 weeks to reach the next, then 12.5 weeks to reach the third, then 3.125 weeks for the fourth, then they’d be back to 10 minute blocks. So, it would only take an expected 265.625 weeks or slightly over 5 years to get back to the normal block cadence. — Good thing many RDTS proponents seem to be open to a blockspace reduction. ;)
Mandatory signaling starting at the beginning of a difficulty period is pretty detrimental to a soft fork attempt with such low hashrate support. A bunch of RDTS proponents have lately been mentioning that they’d be open to “firing the miners if the majority of them is malicious”, so it sounds like they are seeding support for a proof-of-work change when their mandatory signaling period goes as poorly as expected.
I’m against their bib it’s not sexy
std::destroy_at(Tp *location) WIDE SHOT orange glimmer in static dust TILT informally settled mining rigs on fire CROSSFADE memory pool filters, congested PAN Miners hooked on blue X_RAY batteries of knots in bellies FADE TO women and children (in picture frames) DESTROY DATA:EXIT_SUCCESS std::future_status::timeoutHere read this :https://github.com/bitcoin/bips/blob/master/bip-0110.mediawiki
than come back to see what you wrote
Troll alert! As typical for trolls, the wall of text is 100 times longer than the specification of the BIP-110 (a.k.a RDTS, which is about 10 sentences in total): https://bip110.org.