As the filter feud rages on, we finally got a release client in-hand to review for Bitcoin Improvement Proposal (BIP) 110, the Reduced Data Softfork that would create a consensus mechanism to scrub arbitrary data on bitcoin such as inscriptions.
Up until now, the filter softfork has seen a lot of mudslinging with little actual code in the wild. Now, we actually have some code to apply to the proposal, and Bitcoin developers are tearing it apart.
The following is a technical report from Blockspace’s Charlie Spears. Catch up to all our technical coverage by subscribing to the Blockspace podcast on Spotify, Apple, or YouTube!
The reduced Data Temporary Soft Fork (BIP 110) explained
Late October, pseudonymous developer Dathon Ohm proposed and led a campaign for the so-called Reduced Data Temporary Soft Fork. Basically, this update would limit many of the commonly used methods for embedding arbitrary data on Bitcoin. (It was initially referred to as BIP 444 but was officially given the BIP number 110 recently).
This kicked off endless debate among terminally-online Bitcoiners about how such a fork could or couldn’t work and in particular a debate about the activation method (Bitcoin upgrades that make big changes (like SegWit, Taproot, and other soft forks) necessitate coordination for activation in order to prevent chain splits or other disruptions, whereas minor changes don’t require an activation method).
Regardless of how you want to activate a fork, you will need to have the software ready to run in order to do it. This is where an activation client comes in.
An activation client is the modified software that implements the new consensus rules (i.e., executes the fork). It is the way Bitcoin network users coordinate to all fork at the same time. An activation client is typically software that runs like normal today, but it includes a predetermined time (called a flag day) in the future when it will upgrade and enforce the new fork.
The activation client is crucial software, so it typically goes through multiple early versions and iterations called release clients so that other developers can run it on different machines, in different environments.
It’s important to get the activation client right because otherwise you could end up with serious consensus issues such as a chainsplit or nodes forking themselves off the network that never intended to.
If mining pools are also running bad activation clients, you could even have serious issues with bitcoin even working – imagine bitcoin blocks grinding to a halt and the network scrambling to get itself back on track.
Bitcoin developers poke holes in BIP 110 client
Last week, Dathon finally dropped the activation client for BIP 110 (previously BIP 444).
It’s a fork of Luke Dashjr’s Bitcoin Knots client, which is itself a fork of Bitcoin Core, and implements a User Activated Soft Fork mechanism where the users reject blocks from miners who have not updated to the new client (in contrast to a Miner Activated Soft Fork, where the miners reject invalid blocks).
The feedback on the activation client was… overwhelmingly negative.
Basically, BIP 110 is rife with bugs to a degree that it calls into question the technical capabilities of the author, Dathon, to sufficiently spearhead development of an activation client.
This is separate from ideological views of whether to filter transactions: criticisms are exclusively technical in nature. The code itself simply isn’t good to run.
To understand what’s going on I solicited the help from Anchorwatch founder Rob Hamilton, who spent the weekend diving deep into testing (and proposing fixes to) the release candidate.
What’s broken in the BIP 110 client?
To answer the header’s question, A LOT.
BIP 110 fails multiple tests from multiple developers – crucial tests that Dathon designed himself are failing.
Developers typically design tests to mimic real-world scenarios that their software will encounter. They make sure the software does what it intends to do and can function in a multitude of scenarios.
Hamilton explains that activation release clients such as this one aren’t just your typical run-of-the-mill software. While they may undergo small fixes, developers typical release clients with the tacit expectation that the code already works and reviewers are verifying that it works.
However the opposite is happening – developers appear to be verifying that we don’t know if the code works.
“For any client which would have a signed binary, no testing should fail. Tests fail all the time when developing new features, but before creating a release candidate it is expected that all tests currently pass” Hamilton said in an interview with Blockspace.
Many of the testing failures surfaced from the client’s raison d’être, such as whether or not the activation client’s could even execute a User Activate Soft Fork.
“It’s “very possible [the client] could still have consensus bugs,” he added.
“It’s important to note that the tests [used] to verify [whether] the UASF logic was applied correctly were failing [and] were written by Dathon himself.”
It’s unclear at this time what’s causing the issues, but the short version is that we cannot be sure that users running the code will successfully fork Bitcoin. More so, we can’t be sure that users running this code don’t also accidentally fork themselves off the new network.
We don’t even know for sure that they can fork currently. (And that’s kind of the entire point of an activation client).
Hamilton has posited some possible reasons for the failures, but it’s still very early and unclear what the exact problems are.
It is common to put out future versions of a release client with minor bugs fixed, so if BIP 110 is to proceed, we should expect Dathom (or someone else) to fix them.
But the whole saga has not inspired confidence.
BIP 110 and the parable of Segwit2x
Could the problem lie in Dathon’s use of an LLM to help vibe code the release client? Could it be that the tests themselves are bad? Is there some library the code relies on that breaks something? Developers have floated all of these questions about the activation client, but we don’t know the answers at this time.
I’d be remiss if I did not point out the comparison to the failed Segwit2x fork attempt in 2017 where Bitcoin developers refused to sign onto a fork, leaving a single developer (Jeff Garzik) in charge of the activation client.
At the time, the software running Segwit2x failed spectacularly upon launch despite users claims of having significant bitcoin miner and exchange support.
Regardless, prominent pro-filter voices are proudly running the new software. One user reports that 40% of their peers are running the activation client already.
So I’ve got to ask: if a fork happens and no one notices because they live in an echochamber, did it even happen?
Header image from Michael Ford’s X post on a failed BIP 110 test.
