The Filter Debate has finally been upgraded to a soft fork.
Sunday afternoon, an anonymous account with no previous history (named “Dathon Ohm”) sent an email to the Bitcoin Development mailing list with a link to PR #2017, a new soft fork proposal by the anonymous poster to implement transaction filters at Bitcoin’s consensus level.
Get these headlines directly to your inbox: subscribe to Blockspace.
“…it has become necessary to move forward on luke-jr’s ML proposal to temporarily limit arbitrary data at the consensus level,” the anon writes.
TL;DR: The so-called “Reduced Data Temporary Softfork” proposes a change that would allow the Bitcoin network to filter certain transactions at the consensus level instead of the relay (or mempool) level. It’s a soft fork proposal that is the mirror image of ideas floated by Ocean CEO, Bitcoin Core developer, and leading Bitcoin NFT critic Luke Dashjr.
The proposal does not technically have a BIP number yet, but Luke has said he would give it number 444.
Here’s a not-too-technical breakdown of what’s being proposed and the feedback to the push to activate the Reduced Data Temporary Softfork.
The filter soft fork downgrades Bitcoin, but it wouldn’t block all arbitrary data
On a technical level, the PR limits the currently popular ways of embedding arbitrary data into bitcoin. (Bitcoin script is the programming language that defines how bitcoin can be spent – i.e., a transaction’s spending conditions).
In Bitcoin script, you can “push” small amounts of arbitrary data. The soft fork proposal would limit the size of those pushes and ban the opcodes necessary to construct them (such as OP_IF).
It also puts a cap on other somewhat esoteric ways of embedding data, such as in the taproot control block. You might remember when I wrote about Labitbus this past summer. This filter would put a stop to those cute little guys.
It would also invalidate the taproot annex and OP_SUCCESS, both somewhat niche things but which have been proposed as potential additional ways to put data in Bitcoin.
Basically, there are dozens of known ways to put arbitrary data into Bitcoin and this makes it incrementally more difficult to do it in the most popular 5 or 6 techniques.
My thoughts: the only effective way to fight “spam” on Bitcoin is to filter it out at the consensus level. However, this is an endless cat-and-mouse game. For example, Peter Todd already put the entire text of the PR in a transaction that would not be filtered out by the PR.
This demonstrates the futility of attempting to completely filter arbitrary data from Bitcoin when there is economic demand for consensus valid transactions.
Proactive or reactive activation?
Typically, developers assign a soft fork a date far off in the future for activation and devise a process to signal that the Bitcoin ecosystem is ready and willing to upgrade by that date.
The timeline proposed in the filter soft fork PR suggests an activation date in February 2026. This “proactive” soft fork, where the signal date is announced ahead of time, is pretty common for Bitcoin.
The proposal also suggests activation via a reactive soft fork, which is, candidly, really weird and incredibly stupid.
The reactive method proposes that if there is “offensive” material that gets into a Bitcoin block, the Bitcoin ecosystem (primarily indicating miners and pools) would roll back the Bitcoin blockchain and reorg the chain prior to the offensive block.
Yes, that is correct, this PR proposes reorging Bitcoin according to an ambiguous, unspecified heuristic for determining what information is offensive enough to warrant a rollback.
There are over two dozen mentions of legality and morality in the PR, concluding that the methodology to determine what is worthy of rolling back Bitcoin should be based upon what is legal in the United States of America.
And then who is in charge of monitoring & coordinating the rollback when it happens? Does Luke… *ahem* “Dathon” just tweet about it when it happens?
“This is just a soft fork, not a hard fork”
I’ve seen some claims that “this is just a hard for, not a soft for” on social media, including from Luke Dashjr himself. But this is just misleading.
The proposal is a soft fork, but if the soft fork does not have majority hashrate support, it could turn into a chain split. Users often get confused about the difference between a hard and soft fork and think that soft forks don’t result in chain splits.
For example, F2Pool founder Chun Yen indicates F2 would not support BIP-444. So if other miners did, this could create a chain split, and hypothetically, if F2 is a bellwether for how other mining pools will react, whatever chain OCEAN supports would lose out in the market.
Some glaring problems with the filter soft fork
It’s worth noting how quickly this PR #2017 has received a BIP number. Well, it hasn’t formally been assigned a number, but it has all but been blessed with one.
BIPs repo maintainer Luke Dashjr has conspicuously dragged his feet for months on other popular proposals, namely OP_CAT, because they “did not have broad support.”
Luke repeatedly appeals to procedure, particularly when justifying his actions as git maintainer.
But now, a new anonymous account spins up a PR and Luke immediately fast tracks it to receiving a BIP number within hours, even though the PR has not followed the very procedures Luke historically cited as reason to not assign numbers.
BIP-444 also breaks several things people are already using Bitcoin for – things widely considered to be monetary such as BitVM and Miniscript (which would affect companies with legitimate, non-inscriptions-based businesses like Anchorwatch).
The proposal also appears to confiscate or freeze some coins, such as coins held in large multisigs or secured by certain miniscript solutions. So the proposal in it’s current form would actually confiscate some funds used exclusively for monetary & self-custody transactions.
Lastly, this proposal likely does not have anything but minor support from miners (the Ocean team is likely marooned on this one).
Blockspace has reached out to several mining pools and none have received any formal letter nor formal communication on this matter from any Ocean employees.
However, Greg Maxwell and Jameson Lopp both make the claim that Ocean employees have pushed for informal meetings on the subject. This would also corroborate the story that The Rage reported weeks ago.
It seems unlikely that the filter soft fork has any real legs
Currently, our assessment is that it is extremely unlikely that BIP-444 has any real legs. It is widely opposed by the Bitcoin developer community and currently has more hashrate explicitly opposing it than supporting it.
This could change if certain actors – likely Ocean-affiliated – leverage traditional legal channels to pressure pools into perceived regulatory compliance.
I would hope that the Bitcoin community strongly opposes such tactics.
Update:
The github issue has been temporarily locked by BIPs editor Jon Atack “to give people time to cool down”.
The proposal author Dathon recently informed the mailing list that they are “working on a new draft of the BIP” based on feedback.
