The Debate Over CJDNS Support in Bitcoin Core
Bitcoin Core contributors are currently deliberating the future of CJDNS, an optional network transport protocol integrated into the software to provide path diversity. While originally intended as a backup to traditional IPv4, IPv6, and Tor networks, recent data suggests that the CJDNS peer pool has shrunk to critically low levels. Developers are now weighing whether the maintenance of this feature is justified or if its sparse user base has transformed it into a security liability that should be deprecated in upcoming releases.
A Dwindling Network of Peers
The discussion was sparked by findings from contributors like Andrew Chow and Martin Zumsande, who noted a significant lack of reliable CJDNS nodes. Out of 25 known addresses in one seeder database, only seven met the strict "good node" criteria, which includes checks for protocol version, chain height, and rolling reliability. Zumsande reported seeing as few as three or four active peers during operation, far below the typical eight outbound connections Bitcoin Core attempts to maintain. This shallow pool makes it difficult for nodes to reliably fill their outbound slots, undermining the very redundancy the protocol was meant to provide.
Security Concerns and Eclipse Risks
The primary technical concern involves the risk of eclipse attacks, where an attacker isolates a node by monopolizing all of its peer connections. In a network with a tiny address set, an attacker has a much easier time surrounding a target. Bitcoin Core’s documentation already discourages CJDNS-only operation for this reason, noting that such nodes are highly susceptible to Sybil attacks. While the transport layer serves as a "complementary path" for most, the cost of maintaining the code and protecting users from these vulnerabilities may soon outweigh the benefits of keeping the transport active.
The Path Toward Deprecation
As of the latest discussions, a proposal is on the table to warn users of CJDNS deprecation in version 32.x, with a full removal planned for version 33.x. It is important to note that this debate is strictly limited to peer-to-peer networking and address handling; removing CJDNS would have no impact on Bitcoin’s consensus or block-validity rules. While some argue that backup capacity is most valuable before a primary route fails, others contend that a backup network unable to fill even basic connection slots offers a false sense of security rather than true resilience.
