No code has been removed and no final decision has been made, but persistently low adoption metrics have pushed Bitcoin Core contributors to re-examine the practical security and engineering trade-offs of maintaining legacy overlay networks inside the main Bitcoin client — a debate now centered on whether the encrypted routing network CJDNS still justifies its place in the reference implementation.

Seven “good” nodes trigger a broader infrastructure audit

The technical discussion began in an open GitHub issue, where developers questioned whether Bitcoin Core should continue supporting an encrypted routing layer that sees almost no documented real-world traffic. The core objective of adding alternative network transport layers to Bitcoin is redundancy: preventing any single point of network-level failure or censorship. Redundant routes only function, however, if an active mesh of peers participates on the underlying network.

During automated testing of a CJDNS-only node setup, Core developer Marco Falke reported that his instance was unable to establish connections with more than three or four distinct peers at any given time. Following up on that observation, another contributor queried an established network seeder database — the bootstrap services that hand freshly started nodes their first peer addresses — containing 25 known CJDNS addresses. Of the 25 addresses tested, 22 responded to basic handshakes, but only seven met the technical criteria required to be classified as reliable “good” peers for active block and transaction propagation.

A single seeder query does not represent an absolute census of every operating node across the entire CJDNS ecosystem; private, non-advertised nodes and unindexed peers may still exist outside public seeder lists. Even so, the numbers underscore a serious practical reality: an overlay network with fewer than a dozen accessible routing targets fails to provide the operational redundancy required of a resilient production node. For scale, long-running public crawls have counted Tor-advertised reachable Bitcoin nodes in the low thousands, against the 25 addresses held by the CJDNS seeder.

Understanding CJDNS: encrypted IPv6 routing vs. consensus rules

CJDNS is an encrypted IPv6 mesh-network overlay that uses public-key cryptography for address allocation and distributed routing. Outside Bitcoin, the protocol is best known as the routing layer of Hyperboria, a volunteer-run community mesh network. Bitcoin Core added native CJDNS support in version 23.0 in 2022, letting node operators route peer traffic over CJDNS alongside IPv4, IPv6, Tor and I2P.

According to Bitcoin Core’s documentation, CJDNS encrypts traffic end to end and can make traffic analysis and filtering harder. It is not, however, an anonymity network in the same sense as Tor: intermediate CJDNS routers can still see the cryptographic source and destination addresses of the packets they forward.

The proposal concerns only how Bitcoin Core finds and connects to peers. Removing CJDNS support would not change block validation, mining, script rules or transaction formats; nodes would continue enforcing the same Bitcoin consensus rules.

The security mechanics of an eclipse attack

In Bitcoin node security, network transport and peer selection are directly tied to data integrity. Encryption hides packet contents from third parties, but it does not protect a node from being fed false or delayed information if its selection of peers is too restricted. Thin peer pools undermine security by making it dramatically easier for malicious actors to isolate and manipulate CJDNS-only nodes.

The primary threat to isolated nodes is an eclipse attack. In an eclipse attack, an adversary compromises or controls all of the peer connections established by a target node. By surrounding the target node completely, the attacker effectively partitions it from the legitimate global Bitcoin network. From that vantage point, the attacker can manipulate the victim’s view of the blockchain by delaying block announcements, censoring specific incoming transactions, or attempting double-spend attacks against unconfirmed transactions.

Under standard IPv4, IPv6 or Tor routing, Bitcoin Core mitigates eclipse attacks by establishing multiple independent connections across diverse netgroups and network ranges; by default the software keeps eight outbound full-relay connections open at once. When a node operates exclusively over a network with only seven reliable peers — fewer than those default outbound slots — the total pool of available connections is far too small: an attacker needs very few resources to monopolize all incoming and outgoing connections of a CJDNS-only node, turning an intended security fallback into a significant single point of failure.

Code complexity and the case for deprecation

In addition to low adoption figures and security concerns, developers advocating for removal emphasize the ongoing maintenance burden that CJDNS code imposes on the overall Bitcoin Core software repository.

Unlike standard protocol handlers, the CJDNS integration is not completely isolated from standard IPv6 connection logic. Because CJDNS uses specially formatted IPv6 addresses, the codebase requires custom handling logic, dedicated launch arguments such as -cjdnsreachable, and specialized edge-case workarounds. Over time, developers have noted that these custom logic paths introduce bug risks and complicate routine refactoring of the networking stack. The transport layer is also under active development, with the BIP 324 encrypted v2 transport shipped as an option in version 26.0 and enabled by default in version 27.0 — new connection code arriving while legacy paths like CJDNS are reassessed.

Several Core contributors have offered a “Concept ACK” toward deprecating the protocol. In open-source Bitcoin Core development terminology, a “Concept ACK” indicates that a contributor agrees with the high-level goal of a proposal; it does not constitute a final vote, a code merge, or an immediate commitment to remove the feature.

The case for long-term emergency reserves

On the other side of the issue, developers urging caution argue that node utility should not be judged exclusively by current traffic metrics. Contributor Jon Atack pointed out that automated CJDNS peer discovery was only integrated into Core in early 2025. Prior to that update, node operators had to manually configure peer addresses — a process that created a significant barrier to entry compared with the single-click setups available for Tor or I2P.

Proponents argue that CJDNS’s low usage numbers stem from a lack of user awareness and limited integration in popular turn-key node software distributions, rather than a lack of underlying value. If major public anonymizing networks like Tor or I2P were to experience centralized blocking, infrastructure outages, or nation-state-level filtering, alternative mesh protocols like CJDNS could provide a vital emergency fallback channel for maintaining peer connections.

Atack has also volunteered to personally maintain the CJDNS integration code, addressing concerns regarding developer overhead. Core contributors must now decide whether to preserve an alternative transport route for edge-case emergencies or streamline the codebase by removing low-usage network logic.

What a potential removal means for node operators

If Bitcoin Core ultimately removes native CJDNS integration in a future release, the software will simply stop managing CJDNS peer connections internally within the application tier. The change would not prevent operators from running CJDNS externally at the operating system level, nor would it alter how the broader Bitcoin network processes transactions.

Bitcoin Core removals typically follow a slow, documented arc — deprecation is flagged in release notes and code is dropped only in a later major release, on the project’s roughly six-month release cadence — so the markers to watch are the GitHub thread, any formal deprecation pull request, and whether the automated peer discovery added in 2025 moves adoption numbers before maintainers decide.

For the vast majority of node operators who rely on standard IPv4, IPv6, Tor or I2P connections, the removal of CJDNS would pass completely unnoticed. The ongoing discussion reflects Bitcoin Core’s rigorous engineering philosophy: every line of code must justify its existence through proven security and active utility.

This article is provided for informational purposes only and does not constitute investment advice.

Source: Coindoo