A fresh soft-fork concept billed as a “temporary” fix for non-monetary data on Bitcoin has ignited one of the sharpest developer rows since the blocksize wars, with critics decrying the move as censorship theater—and, more explosively, as an attempt to force changes under the specter of legal liability.
The proposal—submitted on Oct. 24, 2025, to the Bitcoin Improvement Proposals (BIPs) repository as “Reduced Data Temporary Softfork”—seeks to “temporarily limit arbitrary data at the consensus level.” Authored by contributor “dathonohm,” it explicitly cites an earlier mailing-list idea from longtime developer Luke Dashjr and frames the effort as a short-run measure while longer-term designs are pursued. The pull request was labeled “New BIP,” with discussion organized around two activation paths described as “proactive” and “reactive.”
Although many in the debate refer to the document as “BIP-444,” the draft in the repository has not been assigned a number and still appears as “bip-????.mediawiki.” Even so, the conversation quickly escaped the confines of GitHub and the dev mailing list, morphing into a full-blown culture clash on X.
An ‘Attack On Bitcoin’?
At the core is a claim familiar from the inscription/Ordinals fights of 2023–2024: Bitcoin is “a monetary network,” not “an arbitrary data transfer protocol.” Supporters argue that constraining arbitrary payloads is about protocol purpose, not adjudicating content. In the draft’s discussion, the author stresses that limiting data avoids turning Bitcoin into “a content moderation system,” and contends that permissive data storage risks centralization and stigma if the chain becomes known as a venue for illegal material. “Node operators shouldn’t have to defend hosting arbitrary data just to participate in a monetary network,” one passage reads.
The draft also floats a one-year horizon by anchoring the rules to a specific block height. In the PR discussion, a reviewer asked why the document blocks at “987424,” noting that if the intent is “to have it be a year out,” the magic number should be explained in an FAQ because height would drift during debate. The author replied to “see the deployment section,” underscoring that the change is designed to expire.
What the change actually does is still being refined in the thread, but the direction is clear: clamp down on overt channels for large data blobs—explicitly OP_RETURN—and close obvious hiding spots in tapscript. One reviewer challenged the scope, noting that if the point were merely OP_RETURN, the draft would not also touch “MAST and OP_IF,” revealing that the specification aims beyond legacy datacarriers to curtail more expressive script paths that can be abused for storage.
That breadth—combined with the document’s rhetoric—sparked immediate blowback. “Luke is being very clear that he expects his soft-fork to get adopted due to legal threats,” said cryptographer Peter Todd.
He also amplified a separate line of attack: that the change could perversely create a censorship-based double-spend vector. “BIP-444 creates a ‘C-SCAM’ attack where you use censoring reorgs to double spend,” Todd wrote, echoing BitMEX Research’s warning that a malicious actor could embed illegal content on-chain “to cause a re-org and succeed with their attack,” thereby creating “an economic incentive for onchain CSAM.”
Galaxy’s head of research Alex Thorn weighed in even more bluntly: “this is explicitly an attack on bitcoin… however it’s also incredibly stupid.” Long-time Bitcoin developer Matt Corallo summarized the cultural dissonance with acid irony: “Bitcoin devs: ‘we have to be really careful…’ This BIP: ‘YOLO’.”
Bitcoin devs: “we have to be really careful when designing forks to ensure there is never even remotely any risk that funds are effectively seized by fork activation. That would set a terrible precedent and risk Bitcoin’s longevity”
This BIP: “YOLO” https://t.co/52nc0BlcPR
— Matt Corallo 🟠 (@TheBlueMatt) October 27, 2025
Todd also claimed to have demonstrated the futility of the approach. “Done with a decade old script that doesn’t even use segwit, let alone taproot… 100% standard and fully compatible with [Luke Dashjr’s] BIP-444,” he wrote alongside a transaction said to contain the entire text of the proposed BIP.
Done with a decade old script that doesn’t even use segwit, let alone taproot.
100% standard and fully compatible with @LukeDashjr‘s BIP-444. https://t.co/Ab7t82KYrk
— Peter Todd (@peterktodd) October 26, 2025
The episode underscores a technical reality the draft itself acknowledges: there will “always be ways to hide data,” which is precisely why the author frames the goal as raising costs, eliminating overt lanes, and—crucially—signaling that large unencrypted files are not a supported use case, thereby “minimizing legal liability for users who run nodes.”
If adopted, the proposal would have immediate implications for protocols that piggyback on witness/script space for non-monetary payloads—Ordinals-style inscriptions foremost among them—at least for the lifetime of the temporary fork. Critics counter that treating such activity as “abuse” is a normative move masquerading as neutrality, and that activating even a temporary fork which can strand funds or encourage censoring reorgs destroys a hard-won norm: forks must never set a precedent where funds can be effectively seized or transactions retroactively delegitimized.
At press time, BTC traded at $115,743.
Featured image created with DALL.E, chart from TradingView.com
Editorial Process for bitcoinist is centered on delivering thoroughly researched, accurate, and unbiased content. We uphold strict sourcing standards, and each page undergoes diligent review by our team of top technology experts and seasoned editors. This process ensures the integrity, relevance, and value of our content for our readers.
#Bitcoin #Devs #Clash #Soft #Fork #Proposal #Combat #Spam