Bitcoin Core Weighs Dropping CJDNS Over Thin Peer Pool

Bitcoin Core contributors are discussing whether to deprecate CJDNS after a seeder snapshot showed a small usable address pool and some nodes reporting only three to four peers. The conversation is recorded in Issue #36041 in the Bitcoin Core repository and the issue remained open in the 32.0 milestone as of Aug. 23, 2026.

Andrew Chow reported that one seeder database listed 25 CJDNS addresses, reached 22 of them and classified seven as “good.” Issue author Martin Zumsande reported his CJDNS node found three to four peers and suggested a peer pool in the low triple digits as a possible threshold for continued support. Several contributors proposed adding a warning in a 32.x release and planning removal in 33.x; there was no implementation branch or pull request attached to the issue at that time.

The seeder uses a stricter “good” label than simple reachability. In Chow’s DNSSeedrs implementation, a node must pass checks on port, advertised network service flags, protocol version, chain height and rolling reliability across multiple time windows with minimum attempt counts. That set of checks can explain why a crawler contacts 22 addresses while only seven meet the filters.

Bitcoin Core maintains eight full-relay outbound connections and two block-relay-only connections, with occasional feeler or extra block-relay slots. On a transport with a small, known address set, an attacker needs fewer resources to occupy those outbound slots and shape a node’s view of the network, which raises concerns about eclipse attacks. Bitcoin Core documentation already cautions against running as CJDNS-only because a node might not fill outbound slots and could repeatedly try the same addresses.

CJDNS can be used alongside IPv4, IPv6, Tor and I2P to provide alternative routes. The CJDNS 22.1 release added DNS-seeded auto-peering on Jan. 8, 2025, removing the need for manual peer addition. Bitcoin Core merged updated setup documentation on March 30, 2026, and on Aug. 18, 2026 it added explicit language discouraging CJDNS-only operation because the address pool remained too small to reliably fill outbound slots. The effect of those changes on the overall CJDNS peer population has not been measured.

If maintainers proceed with deprecation, planned changes would remove CJDNS address handling and connection options while leaving consensus and block-validity rules unchanged. The main operational impact would affect users of the -cjdnsreachable and -onlynet=cjdns flags; inbound and manually added CJDNS connections would remain possible under current behavior until any removal is merged.

The open issue documents a small observed peer set, several contributors expressing support for deprecation and one proposed release sequence. The full cost of mounting an eclipse attack against a CJDNS-only node remains unquantified because factors such as address availability, selection algorithms, crawler reliability gates and occasional extra outbound connections affect actual exposure. For now, Bitcoin Core continues to support CJDNS while maintainers discuss whether to keep address handling and connection options for the transport.