Bitcoin Core contributors are weighing whether a thinly used network transport offers valuable insurance or has become a liability too costly to retain.
In the open CJDNS support discussion, Bitcoin Core member Andrew Chow said one seeder database held 25 CJDNS addresses, had reached 22 and classified only seven as good. The issue author, Martin Zumsande, reported seeing only three to four peers even though Bitcoin Core ships with 11 fixed CJDNS seeds.
Those figures have prompted support for deprecation and a suggestion that Bitcoin Core warn users in a 32.x release before planning removal in 33.x. But that version sequence was posed as a question. As of Sunday, Aug. 23, the issue remained open in the 32.0 milestone, with its Development section empty of an implementation branch or pull request.
Bitcoin Core implements CJDNS as optional peer-to-peer transport and address handling, outside Bitcoin’s consensus system. Issue #36041 instead asks whether Bitcoin Core should keep CJDNS address handling as a fallback when the thin peer pool may also make CJDNS-only nodes easier to surround.
Bitcoin Core’s seven good nodes capture 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.
Only seven of the 22 reached addresses cleared the good-node filters, leaving the usable pool shallow. 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. Bitcoin Core normally maintains eight full-relay outbound connections and two block-relay-only connections, with an occasional feeler or extra block-relay-only connection. A contributor suggested grounding any CJDNS threshold in the cost of filling those regular slots and eclipsing a CJDNS-only node.
An eclipse attack isolates a node by monopolizing the peers that shape its view of the network. On a transport with a small known address set, an attacker has a more concentrated target. Bitcoin Core’s current CJDNS documentation already discourages CJDNS-only operation because a node may fail to fill its outbound slots, repeatedly try the few addresses it knows and become more susceptible to Sybil attacks.
A successful eclipse depends on more than the ten regular outbound slots. The public discussion leaves the full attack cost unquantified. 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.
Those changes reduced setup friction. Any effect on Bitcoin’s CJDNS peer population remains unmeasured. 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.
CJDNS-only and mixed-network operators therefore face different stakes. A CJDNS-only operator faces the thin-pool risk that the documentation now warns about. A mixed-network operator uses CJDNS for optional route diversity and can retain other automatic paths even when CJDNS has few peers.
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, according to the documentation.
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.
