Bitcoin Network Power Struggle Over Anti-Spam Proposal

A technical dispute over Bitcoin’s anti-spam direction has turned into a broader fight over who speaks for the network. The latest flashpoint is a proposal tied to stricter filtering of arbitrary data transactions, alongside accusations that visible node support has been overstated or “faked” through counting methods that do not reflect unique operators. The debate matters because it reaches beyond software preferences into Bitcoin’s governance model, relay policy, and the credibility of node-based signaling.

Bitcoin’s policy fight intensified after Bitcoin Core 30.0, released on October 10, 2025, raised the default -datacarriersize to 100,000 bytes and allowed multiple OP_RETURN outputs in a standard transaction, a change Core says effectively removes the old practical cap because transaction size limits become the binding constraint first. That policy shift, documented in the official 30.0 release notes, gave fresh momentum to developers and node operators arguing for stricter anti-spam filters. At the center of the latest clash are claims that support for anti-spam alternatives has been exaggerated by node counts that can be duplicated or do not map cleanly to independent economic actors.

October 2025 Policy Shift Triggered the Latest Split

The immediate catalyst is Bitcoin Core’s decision to loosen default relay policy for OP_RETURN data. In the official release notes for version 30.0, Core states that the default data-carrier size rose to 100,000 bytes and that multiple OP_RETURN outputs are now standard for relay and mining. Core also notes that users can still override the setting with -datacarriersize=83 to restore the previous limit. That distinction is important: the change is a default policy choice, not a consensus rule change, which means nodes can still run stricter local policies without forking Bitcoin.

Opponents of the looser default argue that the change makes it easier to relay non-financial data and weakens informal anti-spam norms. Supporters counter that arbitrary data was already possible through other transaction constructions and that moving data into provably unspendable outputs can reduce UTXO bloat. That argument also appears in public discussion around the OP_RETURN change, where advocates said old limits created incentives to hide data in less transparent ways.

23,153 Public Nodes Do Not Equal 23,153 Independent Voices

The “faked support” accusation centers on measurement, not just ideology. Coin Dance explicitly says it filters duplicate nodes by address and omits non-listening nodes to provide a better, though not guaranteed, picture of decentralization. Even with that adjustment, public-node counts remain an imperfect proxy for governance because one operator can run multiple nodes, many nodes sit behind hosting providers, and economically important actors such as exchanges, custodians, merchants, and miners are not weighted by simple node totals.

Bitnodes offers a different lens. Its leaderboard snapshot from February 8, 2026 listed 5,755 ranked reachable IPv4/IPv6 nodes by Peer Index, illustrating how “reachable” public nodes are only a subset of the broader network. The gap between Bitnodes’ reachable-node view and Coin Dance’s broader public-node summary shows why raw counts can produce conflicting narratives. A campaign that cites one dataset without explaining its methodology can make support look stronger or weaker than it is.

That is the strongest factual basis for claims that support can be “faked”: not necessarily by fabricating software binaries, but by presenting node tallies as if they were one-person-one-vote endorsements. In Bitcoin, they are not. Node software distribution can signal sentiment, yet it does not by itself activate consensus changes, guarantee miner adoption, or prove backing from unique stakeholders.

Why OP_RETURN Became the 100,000-Byte Fault Line

OP_RETURN has long been the visible battleground because it is the standard mechanism for embedding provably unspendable data in Bitcoin outputs. Before version 30.0, Bitcoin Core enforced a much smaller default limit. After the October 2025 release, the default rose to 100,000 bytes, which Core says effectively uncaps the setting in practice because transaction size becomes the real ceiling first.

For anti-spam advocates, that change crossed a symbolic line. They argue that even if arbitrary data storage was already possible, making larger OP_RETURN payloads standard by default lowers friction and normalizes non-monetary use. Critics of stricter filtering answer that relay policy cannot fully stop determined users, and that fragmented local filtering could create inconsistent propagation without solving the underlying incentive problem.

Two Paths Are Emerging as 2026 Debate Hardens

One path is continued policy pluralism: Bitcoin Core keeps looser defaults, while Knots and other alternatives offer stricter relay settings for operators who want them. The other path is escalation, where node operators try to use software distribution, peer disconnection, or public pressure to marginalize rival policy choices. Public reporting in early 2026 shows that even some critics of arbitrary-data usage oppose turning the fight into a consensus-level battle, warning that credibility costs could outweigh any filtering gains.

What comes next depends less on slogans than on adoption by economically relevant participants. If miners, exchanges, payment processors, and large routing nodes converge on one relay norm, that norm gains practical weight. If they do not, Bitcoin may continue with a patchwork of local policies. For now, the verifiable data show a real split in public-node software, a documented policy change in Core 30.0, and a valid reason to treat headline node-support claims with caution.