Bitcoin Core contributors are weighing whether an optional network transport provides valuable insurance or has become a liability too costly to retain. Discussion around issue #36041 is evaluating whether CJDNS address handling should be removed entirely or kept as a fallback mechanism.
During open discussions, Bitcoin Core member Andrew Chow noted that a seeder database held 25 CJDNS addresses, reached 22, and classified only seven as good. Issue author Martin Zumsande reported observing only three to four peers despite Bitcoin Core shipping with 11 fixed CJDNS seeds. These metrics have prompted support for deprecation and a proposal to warn users in version 32.x before removing the feature in 33.x.
The current timeline remains a proposal, and the issue remains open without an active implementation branch or pull request. CJDNS operates outside Bitcoin's consensus system as an optional peer-to-peer transport and address handling feature.
Understanding the Active Node Pool
The discrepancy between reached addresses and good nodes stems from strict technical filters applied by seeders. In Chow's implementation, a node must pass checks for its port, advertised network service, protocol version, chain height, and rolling reliability across multiple time windows with minimum attempt counts. This filtering explains why 22 addresses could be reached while only seven cleared the quality threshold.
Zumsande suggested that a low-triple-digit number of nodes might justify continued support, giving maintainers a concrete benchmark to debate. However, the cost of an eclipse attack—where an attacker isolates a node by monopolizing its network view—remains unquantified in public discussions.
Bitcoin Core documentation already discourages CJDNS-only operation, warning that nodes running exclusively on the network may fail to fill outbound connection slots and become more susceptible to Sybil and eclipse attacks. While CJDNS 22.1 introduced DNS-seeded auto-peering to reduce setup friction, the impact on the active peer population has not been measured.
Impact on Operators
The stakes differ significantly depending on how operators configure their nodes:
- CJDNS-only operators: Face the thin-pool risks and potential susceptibility to eclipse attacks highlighted in updated documentation.
- Mixed-network operators: Use CJDNS for optional route diversity alongside IPv4, IPv6, Tor, and I2P, allowing them to rely on alternative automatic paths if the CJDNS network lacks sufficient peers.
Any future deprecation would alter transport settings and connection options without modifying Bitcoin's block-validity or consensus rules. The changes would directly impact operators utilizing the -cjdnsreachable flag or limiting automatic outbound connections via -onlynet=cjdns. As the debate continues, CJDNS remains supported in Bitcoin Core pending further action on the open issue.
