Bitcoin Core contributors are debating whether a thinly used encrypted routing transport is worth keeping when only seven nodes pass reliability checks.
Back
Bitcoin Core weighs CJDNS removal as 7 good nodes raise risk
Bitcoin Core weighs deprecating CJDNS routing after a seeder found only seven good nodes, exposing CJDNS-only operators to eclipse attacks.
"One seeder database held 25 CJDNS addresses, had reached 22 and classified only seven as good," Andrew Chow, Bitcoin Core member, said in the open GitHub issue #36041.
Martin Zumsande, the issue author, reported seeing only three to four peers despite Bitcoin Core shipping with 11 fixed CJDNS seeds. The proposal suggests warning users in a 32.x release before planning removal in 33.x, though the version sequence was posed as a question. As of Aug. 23, the issue remained open in the 32.0 milestone with no implementation branch or pull request attached.
The thin peer pool could make CJDNS-only nodes easier to surround in an eclipse attack, where an attacker monopolizes a node's connections to shape its view of the network. Bitcoin Core normally maintains eight full-relay outbound connections and two block-relay-only connections, and a contributor suggested grounding any CJDNS threshold in the cost of filling those slots.
Seven good nodes from one seeder snapshot
The seeder numbers describe one crawler's database at one point in time. The global CJDNS population may be larger because the figure covers only that crawler's database.
The seeder applies "good" as a stricter technical filter than reachability. In Chow's DNSSeedrs implementation, a node must pass checks covering its port, advertised network service, protocol version, chain height and rolling reliability. The reliability tests use several time windows and require minimum attempt counts. That explains how the seeder could reach 22 addresses while classifying only seven as good.
Zumsande's node found just three or four peers, and he offered low triple digits as a rough level that might justify continued support. The low-triple-digit benchmark was Zumsande's alone, giving maintainers a number to argue over instead of only a general complaint about low usage.
Peer-count arithmetic alone leaves the eclipse cost unknown. A successful eclipse depends on more than the ten regular outbound slots. Address availability, address selection, crawler reliability gates and occasional extra outbound connections all affect practical exposure. The measured pool supports a concentration concern for CJDNS-only nodes, while the cost of exploiting that concern remains unquantified.
Redundancy depends on how CJDNS is used
CJDNS offers a different proposition when it is one path among several. Bitcoin Core's documentation presents it as a complementary option alongside IPv4, IPv6, Tor and I2P, allowing a node to keep another route available if one network has problems.
That option has become easier to use. CJDNS 22.1 introduced DNS-seeded auto-peering on Jan. 8, 2025, making manual peer addition optional. Bitcoin Core then merged updated setup documentation on March 30, 2026, replacing obsolete manual-peering instructions with the newer flow. Bitcoin Core merged another documentation change on Aug. 18, 2026, explicitly discouraging CJDNS-only use because the address pool remained too small to fill outbound slots reliably.
A future deprecation would remove transport settings while leaving block-validity rules unchanged. Bitcoin Core added full CJDNS support in version 23.0 as a P2P networking feature. The debate is confined to address handling and connection options; Bitcoin's consensus and block-validity rules sit outside its scope.
The directly affected operators would be those using -cjdnsreachable, which tells Bitcoin Core to treat the relevant IPv6 range as CJDNS, or -onlynet=cjdns, which limits automatic outbound connections to that transport. The same option can currently be combined with other networks, while inbound and manually added connections remain available under -onlynet.
Issue #36041 remains open, with the warning and removal sequence recorded only as a proposal. It shows a small observed peer set, multiple expressions of support for deprecation and one proposed release sequence. It also shows why a usage count alone is an incomplete test: backup capacity is most valuable before a primary route fails, but a backup network that fails to fill connections may offer less resilience than its presence in the code suggests.
Bitcoin Core still supports CJDNS. A merged warning or removal pull request would change the status of the debate. Seven good nodes makes the transport-diversity tradeoff measurable and leaves the removal choice open.
This article is for informational purposes only and does not constitute investment advice.
