A new chart from Jameson Lopp has reopened one of Bitcoin’s oldest internal debates: whether visible node counts reflect real support for a rule change.
The immediate flashpoint is BIP-110, a draft proposal that would temporarily impose much tighter consensus-level limits on non-monetary data, following Bitcoin Core 30’s loosening of the default OP_RETURN policy.
Lopp says the node surge behind it may be Sybil-inflated (i.e., artificially boosted by a single actor running many nodes to simulate broader support).
| Signal | What it can show | What it cannot prove |
|---|---|---|
| Public reachable node count | Visible distribution of software on the network | Real economic support for a rule change |
| Non-listening / private nodes | Broader adoption beyond public-facing nodes | Whether the operators matter for activation |
| Miner signaling | Hashrate support for activation | Full support from exchanges, wallets, users |
| Node surge on one client or BIP | Growing interest or coordination | That support is organic rather than cheaply manufactured |
The node chart that started it
Lopp shared a chart captioned “Spot the Sybil Attack” showing the BIP-110 signaling line rising sharply while the Bitcoin Knots line whipsawed.
Current data from Coin Dance shows 23,189 public Bitcoin nodes, with 17,961 running Bitcoin Core and 5,193 running Bitcoin Knots, after correcting to omit duplicate and non-listening nodes.
Knots account for roughly 22% of the public-reachable set. The amount is well short of parity with Core.
The numbers look different depending on the dashboard used. Smart Wicked Bitcoin, the platform from which Lopp drew his chart, tracked 22,362 Core v30 nodes, 11,997 Knots nodes, and 10,361 BIP-110 signaling nodes as of Mar. 23.
That gap between Coin Dance’s publicly available count and the one used by the Smart Wicked Bitcoin team exists because the two platforms measure different universes. Coin Dance corrects for duplicates and non-listening nodes, while Smart Wicked Bitcoin’s broader count includes both listening and non-listening nodes.
The same network can appear either modestly tilted or dramatically surging, depending on methodology.
Bitnodes’ own documentation provides a source-backed reason to treat large all-node totals with caution, regardless of intent: its global-node estimates are described as rough counts that may include spurious nodes gossiped by non-standard or malicious peers.
Lopp’s complaint is precise and architectural. In his BIP-110 explainer, he argues that reachable-node signaling carries no economic weight, that thousands of nodes can be spun up cheaply, and that Tor addresses are “practically free.”
His framing sees a cluster of nodes signaling without economic stake behind them as a governance theater manufactured at low cost.
Lopp also draws an explicit parallel to earlier Bitcoin governance battles, Bitcoin Unlimited and SegWit2x, where visible node counts were used to argue for consensus support that never translated into actual network adoption.
His core point is that Bitcoin’s governance runs on economic weight, such as miners, exchanges, and wallet operators, which reachable-node tallies cannot represent.
A surge in BIP-110 signaling nodes, even a genuine one, leaves the question of activation entirely open.
Core 30 and the OP_RETURN loosening
The trigger for BIP-110 was Bitcoin Core 30.0, released Oct. 10, 2025.
Its release notes confirmed that the default -datacarriersize was raised to 100,000, effectively removing the old limit, and that multiple OP_RETURN outputs are now permitted for relay and mining.
For the anti-spam camp, that policy shift crossed a line: loosening defaults at the node level felt like an endorsement of arbitrary data storage on the Bitcoin network.
BIP-110 is the reaction and was filed in the BIPs repository as “Reduced Data Temporary Softfork,” authored by Dathon Ohm.
The proposal would tighten data limits at the consensus layer.
The specification sets a 34-byte cap on new output scripts except for OP_RETURN outputs up to 83 bytes, limits data pushes and witness elements to 256 bytes, invalidates Taproot control blocks over 257 bytes, and disallows OP_SUCCESS opcodes plus executed OP_IF and OP_NOTIF in Tapscript during deployment.
The BIP also credits Luke-Jr with original drafting and advice.
The activation design is what elevates it into a governance fight. BIP-110 uses a modified version of BIP9 with a 55% signaling threshold and a maximum activation height around Sept. 1, 2026.
| Topic | Current / post-Core 30 backdrop | BIP-110 proposal |
|---|---|---|
| OP_RETURN policy | Default -datacarriersize raised to 100,000; multiple OP_RETURN outputs allowed for relay/mining |
OP_RETURN limited to 83 bytes |
| Output scripts | Looser policy environment after Core 30 | New output scripts capped at 34 bytes, except OP_RETURN |
| Data pushes / witness elements | Broader data flexibility | Capped at 256 bytes |
| Taproot control blocks | Larger constructions possible | Capped at 257 bytes |
| Tapscript behavior | Existing upgrade flexibility | OP_SUCCESS invalid; executed OP_IF / OP_NOTIF disallowed during deployment |
| Activation design | Standard soft-fork expectations usually imply much broader consensus | Modified BIP9 with 55% threshold and mandatory signaling |
| Supporters’ case | Bitcoin drifting toward arbitrary-data use | Restore monetary focus, reduce spam |
| Critics’ case | Policy dispute could remain at node level | Risks chain split, constrains Taproot, overweights signaling optics |
A soft fork that activates at 55% miner signaling leaves 45% of hashrate potentially producing blocks that the activated chain would reject, making the chain-split risk more than theoretical.
Alongside the Sybil concern, there are concrete reasons BIP-110-related nodes became easier to deploy in early 2026.
On Feb. 6, myNode released version 0.3.41, which added “Bitcoin Knots + BIP110 Custom Bitcoin Version” as an install option.
A RaspiBlitz pull request on Feb. 19 updated its Knots installer to download and run a BIP110-enabled build.
The official BIP-110 site lists simplified install paths across Start9, Umbrel, myNode, Parmanode, and Docker, and explicitly encourages users to run signaling nodes to demonstrate support.
The surge likely reflects some combination of genuine opt-in adoption, easier platform distribution, private non-listening node installs, and Sybil-style inflation.
The chart surfaces the question, while the data behind it leaves the answer open.
The stakes beyond the signaling fight
BIP-110 carries technical consequences that run deep into Bitcoin’s Taproot architecture.
The draft would temporarily invalidate advanced Taproot constructions that rely on OP_SUCCESS upgrade hooks, restrict the execution of OP_IF and OP_NOTIF in Tapscript, and cap control blocks at 257 bytes.
The proposal and the BIP-110 site both acknowledge the tradeoffs.
BitVM-style large Taptrees would need to wait, wallets producing arbitrary Miniscript would require updates, and in narrow edge cases, some funds could be frozen or lost during the deployment window. The site describes that risk as extremely unlikely and says pre-activation UTXOs remain exempt.
Supporters, such as Ohm, frame those constraints as temporary and worth tolerating to restore Bitcoin’s monetary focus.
The bear case centers on a coordination failure. If the 55% threshold proves insufficient to bring miners and economic actors along, the result is a failed soft fork and a network that spent months arguing over signaling optics. At the same time, the real governance question stayed unanswered.
Bitcoin has been here before. The difference this time is that Core changed the defaults first, BIP-110’s proponents are running a coordinated node distribution campaign across multiple platforms, and the activation threshold is low enough to make the chain-split scenario concrete.
Whether the surge represents a genuine coalition or an inflated signal, the argument it has triggered is the same one that has defined Bitcoin’s governance fights for a decade: who counts, who gets counted, and who decides.