rewrite this title with good SEO Is Bitcoin’s Anti-Spam Fork Already Dead? Insider Drops Bombshell On BIP-110

This is a guest post by Jason Hughes, VP of Development and Engineering at Ocean Mining. Opinions expressed are entirely his own and do not necessarily reflect those of BTC Inc. or Bitcoin Magazine. The article originally appeared on X.com and has been published with the permission of the author. 

Let me start off by saying I’m not pro BIP110, and I’m not anti-BIP110. If it actually succeeds as something that gains true consensus within the network and ends up being enforced by a majority of the network… cool. If so, then we’ll go with it because the network has spoken and accepted it, and all nodes, including non-BIP110 nodes, will be pulled along for the ride. Unfortunately for proponents of the proposal, that simply isn’t currently the case by any measurable metric, nor does it appear to have a trajectory suggesting that will change, either. 

There’s been a lot of misleading information about this whole thing, especially in the context of mining. A few quick key bullet points to briefly counter some hyperbole from proponents: BIP110 is NOT inevitable. It CAN fail. BIP110 can and will cause a chain split/fork in a minority hashrate situation. BIP110 is NOT without risk to miners choosing to adopt it. Miners not supporting BIP110 are not suddenly mining “invalid” blocks just because a proposal that isn’t yet adopted simply exists. You’re not a bad person or evil simply because you don’t like or support BIP110. (The fact that I feel the need to point out that last part is actually kind of sad…)

I was going to write a long post to help keep miners informed about things they need to remain aware of as this all plays out… before realizing I already did so months ago, as a document I authored that I had hoped could be put out as a miner education piece at OCEAN. Sadly, it never got published. So I went ahead and updated it, and well, here it is.

Again, keep in mind this was written months ago, intended to be as agnostic as possible in an effort to make it acceptable as a corporate post. That effort failed, so I’m posting it as a personal document today instead. As a miner making important decisions about your operations, you need to be aware of all of this without the sugarcoating and, frankly, outright misleading information coming from some of the BIP110 proponents.  You must be vigilant and decide what’s right for you. 

While there is certainly some misleading information from the opposition as well, nothing I’ve seen is nearly as egregious as the extremely premature claims of victory and accompanying hyperbole pushed by the BIP110 side. Summarizing my doc a bit, my personal suggestion to miners is this: Signal if you support BIP110. Do not signal if you don’t support BIP110 or don’t care. Either way, monitor the network on/around/before block 961632. 

If you continue to see non-signaling blocks from major pools, you can be reasonably certain they’re not going to suddenly decide later to throw away millions of dollars’ worth of revenue to backtrack and signal for BIP110. If they do, by some chance, start to signal for BIP110, you should monitor that and consider switching as required to stay on the heaviest chain. The key point is that, realistically, only one side can win. It’s either BIP110 succeeds, and miners not on the BIP110 side fail, or BIP110 fails, and miners on the non-BIP110 side succeed. 

Moving on, let’s dive into a small fraction of my rationale. 

QUICK FACT: Between 7 and 15% of Bitcoin Nodes are signaling support for BIP110.

Depending on which centralized crawler you look at… no way to know for sure [how many BIP110 nodes are signaling support]. My personal private crawler puts this number much lower, but that’s a discussion for another day. Suffice it to say, I think it’s logical and correct to say that even 15% is not a majority. 

“But Jason! UASF got Segwit activated with fewer nodes!” 

Yep, because many miners, merchants, users, etc., all actually wanted Segwit. There was tremendous economic and community weight behind it. Without rehashing that whole thing, as plenty of resources on the topic from before BIP110 are worth a read, suffice it to say that BIP110 and Segwit activations are not quite comparable, as many have already pointed out. Segwit, for example, went into its UASF territory with around 1/3rd of the network’s hashrate already signaling support. With that kind of backing, the UASF to help push the MASF over the tipping point made a lot of sense. It doesn’t make sense here for BIP110.

QUICK FACT: 0.6% of blocks over the past 60 days have signaled support for BIP110.

[0.6% is a] pretty stark contrast to even Segwit’s low baseline support. Yes, I know it’s increased slightly in the past couple of weeks, but no new entrants. Just more clearly rented hashrate from one of the same small proponents.

Something to keep in mind is that mining BIP110 signaling blocks via DATUM on OCEAN carries virtually no risk to the miner up until the fork point at block 961632. The cost is negligible, as you’re effectively guaranteed to recoup rental costs, etc.

It’s awesome that the ability to do so exists, and I wouldn’t have it any other way… but just something to keep in mind when weighing signaling from such blocks in the grand scheme of things from a risk-reward, money-on-the-table perspective.

“But Jason! Miners have no incentive to signal until the last minute!”

I also see no evidence to suggest that this could be the case. Subjectively, I disagree with the premise, as it’s not in a mining pool’s best interest to destabilize the network in such a way.  Part of the reason for early signaling and lock-in periods is to help coordinate upgrades in a smooth fashion. Waiting until the last minute negates that benefit entirely. I see no compelling rationale or upside to doing so.

Continuing on this, as part of my personal node monitoring setup, I specifically monitor nodes known to belong to various entities, such as other mining pools, exchanges, large lightning nodes, merchants, etc. A supermajority of which are monitored with explicit permission and confirmation/coordination.

QUICK FACT: All major mining pools I monitor are currently running some variant of Bitcoin Core v30 or v31 (except OCEAN). 

Expanding on that, most [mining pools] have updated their nodes since the proliferation of BIP110’s release, even since the release of Knots 29.3. Additionally, it is known that many mining pools run modified versions of their node software to facilitate various requirements of their specific infrastructure. Such changes would need to be ported to a BIP110-compatible client, tested, evaluated, and deployed ahead of time. I currently see no evidence that this is the case currently.

As far as I can tell, the pools are aware but ignoring. 

“But Jason! Miners don’t determine consensus! Nodes do! Otherwise, they’ll just cancel halvings!”

This is one of the funniest and most ridiculous arguments I’ve heard from the pro-BIP110 crowd.  Comparing a consensus change that can be unilaterally enforced upon the network by miners and accepted by 100% of existing nodes (a soft fork), with a hard fork which no existing node will accept… is disingenuous at best. T

ightening rules (like BIP110): Soft fork, can be enforced by miners if they choose to do so. Loosening rules (like canceling a halving): Hard fork, can not be enforced by miners without effectively 100% buy-in from the entire network… which isn’t likely to happen. Comparing the two is, bluntly, just stupid.

“But Jason! If you don’t upgrade to the latest consensus rules, you’re insecure! You’ll lose funds! You’ll mine invalid blocks! You’ll [insert additional hyperbole here]!”

This would be true of a consensus change that has, well, consensus. While BIP110 has made a valiant effort to gain that consensus, it has yet to have any measurable majority at what is now arguably the 11th hour. Not in nodes, not in hashrate, not in the social layers (consensus.health has a cool visual there where you’ll find me in the middle).

If somehow BIP110 gains 51%+ of the network hashrate on/before block 961632… then, alright. It’s enforced, since as a soft fork a majority of miners can unilaterally enforce it in the absence of a fully adopted URSF (effectively a misnomer, as this would kind of be a hard fork).

“But Jason! It can’t gain consensus by already having consensus! You have to give it a chance!”

Firstly… no I don’t, even though I have.  Second, it’s a rushed proposal that never had the time to even try and gain real consensus. It’s been 7 months since the release of the first BIP110 client. There’s ~3 weeks to go before “mandatory” signaling starts as of now (less by the time you read this). 90% of the time available has passed with no change in overall sentiment from any relevant players. If it hasn’t gained sufficient adoption in the past 7 months, it’s not likely to do so in the next 3 weeks.

“But Jason! CSAM! CSAM! Pedophiles! CSAM!”

I’ll be the first to say, even I personally overstated the risk here early on when Core proposed its OP_RETURN change. I personally expected something particularly egregious to hit the chain almost immediately, and to the best of my knowledge, that’s not yet happened. Could it still happen? Yeah, I suppose.

But considering from a technical perspective, byte-for-byte the same contiguous arbitrary data can provably end up stored in the current chain or the BIP-110 chain without much issue… this particular argument for BIP-110 falls pretty flat to me at this point.

Do I want CSAM in the chain? Of course not. Am I a pedophile if I don’t support BIP110? Also not.

Concluding Thoughts

I could continue to go on and on and on, but I’ll stop here. I’ve wasted enough time on this. I’m sure I’ve done plenty to annoy both sides of the BIP110 debate at this point, as I don’t adopt either stance. I’m sure I’ll catch flak from all angles simply for daring to speak my mind on it.

Overall, I mostly think it was silly to approach addressing a real problem (the OP_RETURN default change in Bitcoin Core) with the maximum anti-spam manifesto based soft fork proposal… which provably cannot stop spam, arbitrary data, etc. 🤦‍♂️ (Yes, I know, proponents will claim it’s not about spam… and will also make semantic arguments that it does stop data as well… neither of which appears to be correct.)

I’ll close with the concession that I could be wrong. I’m not Nostradamus, and I can’t accurately predict the outcome with 100% certainty.  I can only go by what the data tells me, and so I give BIP110’s success less than a 5% chance of actually succeeding… and I consider that generous. You can take my opinions on this however you wish, but I highly recommend you don’t discount the actual data points, remain vigilant, and do what’s best for you and your mining revenue. Don’t be gaslit by either side of the debate, and make your own decisions.

Here’s a link to the same document linked above for ease of access.