"Spot the Sybil Attack"
Lopp's chart reveals a suspicious surge in BIP-110 signaling nodes
THE CHART
On March 23, Jameson Lopp tweeted a Smart Wicked Bitcoin chart showing 10,361 BIP-110 signaling nodes alongside 22,362 Core v30 and 11,997 Knots nodes. The BIP-110 line surges sharply — far beyond actual Knots adoption. Coin Dance (correcting for duplicates) shows only 5,193 Knots nodes out of 23,189 total.
THE TOR TELL
Among Knots nodes: 3.6:1 Tor-to-IPv4 ratio vs 1.7:1 for non-Knots nodes. Tor addresses are practically free to spin up — you don't need a unique IP, a datacenter, or even a static address. The skewed ratio is a classic Sybil fingerprint.
LOPP'S POINT
"Reachable-node signaling carries no economic weight." Running a listening Bitcoin node costs cents per hour. Running a miner costs real energy. This is precisely why Bitcoin's consensus mechanism is proof-of-work, not proof-of-node-count.
The Hard Evidence
willcl_ark's Bitcoin crawler quantifies the Sybil attack
3,312
IPv4 BIP-110 nodes
3,058
In 12 IP /16 ranges
254
Genuine IPv4 nodes
METHODOLOGY
Will Clark (Bitcoin Core contributor) ran dnsseedrs, an independent network crawler. Among the 3,312 IPv4 BIP-110 nodes, 3,058 cluster into just 12 /16 IP ranges (~255 nodes each) — suggesting single-operator control across datacenter IP blocks. The full "good" BIP-110 count is higher once Tor and IPv6 nodes are included.
CONTROL GROUP
Applying the same methodology: 1 Bitcoin Core node and 0 Bitcoin Knots nodes flagged. The Sybil clustering is exclusive to BIP-110 signaling nodes.
92.3%
of IPv4 BIP-110 nodes are likely Sybils
Miner Signaling Reality
Fake node momentum vs actual activation progress
3 BLOCKS IN CURRENT PERIOD
Period 467 (current): 3 of 1,840 blocks have signaled BIP-110 (0.2%). The signalers: OCEAN (234 Alberta) — 2 blocks, and OCEAN (Barefoot Mining) — 1 block (Bob Burnett, who builds his own templates via Ocean's DATUM protocol). Previous period (466): 0 of 2,016. Every major pool — Foundry, AntPool, F2Pool, ViaBTC, Marathon, Luxor — shows 0% signaling.
NO MAJOR POOL SUPPORT
F2Pool co-founder Wang Chun publicly condemned BIP-110. Adam Back called it "an intentional literal downgrade" and a "rug-pull." Foundry (581 blocks, 0%), AntPool (337, 0%), F2Pool (197, 0%), ViaBTC (175, 0%) — all silent.
THE MATH
Activation requires 55% of blocks in a 2,016-block period. Current: 0.2%. The only signalers are solo miners on Ocean with custom templates. At this rate, activation is mathematically impossible.
0.2%
3 / 1,840 blocks · 55% threshold · all from Ocean solo miners
What This Teaches Us
SOCIAL ENGINEERING, NOT TECHNICAL ATTACK
Node counts contribute exactly zero to BIP-9 activation. But the 2.38% Knots figure was trumpeted in media as a "growing movement." Inflating node counts is a narrative attack — manufacturing the appearance of grassroots support. If you have to fake your support metrics, you don't have support.
THE CONVERGENCE
• Fake nodes — 92% of BIP-110 nodes are suspected Sybils
• No major pool support — 3 solo-miner blocks in the current period
• Consensus bugs — cache poisoning bug found in Knots implementation
• Bypassable rules — 66KB TIFF embedded without OP_RETURN or Taproot
• Prominent defections — former supporters walking away
• Empirical data — mempool.space report shows OP_RETURN limits don't work
• No major pool support — 3 solo-miner blocks in the current period
• Consensus bugs — cache poisoning bug found in Knots implementation
• Bypassable rules — 66KB TIFF embedded without OP_RETURN or Taproot
• Prominent defections — former supporters walking away
• Empirical data — mempool.space report shows OP_RETURN limits don't work
PRECEDENT
During the SegWit2x debate, Bitcoin Unlimited inflated node counts via Sybil nodes. It didn't help — miners and economic nodes decided the outcome. History repeats.
ProductionReady Client
The OP_RETURN war escalates: a 501(c)(3) funding an alternative Bitcoin client
WHAT IS IT
A US public charity launched March 23, 2026. Board: Jimmy Song, Samson Mow, Parker Lewis, John W. Ratcliff. Mission: fund an alternative Bitcoin client built on Core's codebase that reverses the burden of proof for changes — modifications require "overwhelming support" before merging. Endgame: protocol ossification.
BORN FROM THE OP_RETURN WAR
Core v30 removed the 80-byte OP_RETURN limit. Knots surged from ~2% to ~15% of nodes. ProductionReady would restore the data limit. On BIP-110: "not expected to be included given the lack of broad user consensus." Same consensus rules as Core — policy fork, not chain fork.
THE DEBATE
For: Implementation diversity, node operators voting with their feet, checks on Core development process.
Against: Board of public figures not protocol devs, Knots already fills the niche, fragments scarce review effort, escalates policy disputes into infrastructure.
Against: Board of public figures not protocol devs, Knots already fills the niche, fragments scarce review effort, escalates policy disputes into infrastructure.
THE BIGGER QUESTION
If relay policy disagreements spawn competing implementations, what happens during an actual consensus debate? Is this healthy ecosystem diversification or the beginning of political balkanization of Bitcoin development?