Bitcoin Core Questions a Privacy Network With Seven Healthy Nodes
Bitcoin Core developers are currently debating whether to keep support for CJDNS, an encrypted peer-to-peer routing protocol, after automated network checks revealed a surprisingly small population of active nodes.
While no code has been removed and no final decision has been made, the low adoption metrics have forced contributors to re-examine the practical security and engineering trade-offs of maintaining legacy overlay networks inside the main Bitcoin client.
Key Takeaways
- A recent seeder database check found only seven “good” CJDNS nodes, highlighting minimal active adoption on the network.
- Thin peer pools undermine security by making it dramatically easier for malicious actors to isolate and manipulate CJDNS-only nodes.
- Developers are weighing code complexity and bug risks against keeping an alternative routing network available during emergencies.
- The proposal concerns node networking and transport protocols only; it does not affect block validation, transaction rules, or core consensus.
Seven “good” nodes trigger a broader infrastructure audit
The technical discussion began in an open GitHub issue when 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 to guarantee redundancy, preventing any single point of network-level failure or censorship. However, redundant routes only function if there is an active mesh of peers participating 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 the observation, another contributor queried an established network seeder database containing 25 known CJDNS addresses. Out 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.
It is important to understand that 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. Nevertheless, the low numbers underscore a serious practical reality: an overlay network with fewer than a dozen accessible routing targets fails to provide the operational redundancy required for a resilient production node.
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. 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.
Bitcoin Core’s documentation says CJDNS encrypts traffic end to end and can make traffic analysis and filtering harder. It is not an anonymity network in the same sense as Tor, however: intermediate CJDNS routers can still see the cryptographic source and destination addresses of 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.
A 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 this 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. But when a node operates exclusively over a network with only seven reliable peers, 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 failure vector.
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, 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 like -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.
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 to single-click Tor or I2P setups.
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.
Furthermore, Atack 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 decides to remove 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.
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 simply 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.
Kosta has reported on cryptocurrency markets and blockchain infrastructure since 2020, bringing over six years of hands-on experience in the crypto industry built through daily tracking of markets, trends, and emerging blockchain developments. Specializing in Bitcoin on-chain analysis, institutional ETF flows, and digital asset price action, his work at Coindoo has been cited by other news agencies and consistently covers market developments with a focus on data-driven reporting across Bitcoin, Ethereum, Solana, and XRP. Over the years, Kosta has contributed to multiple crypto media outlets in different regions, authoring over 6,000 articles across the sector. His reporting spans cryptocurrency markets and the broader fintech industry, tracking not only price action but also the technological and regulatory forces shaping the ecosystem. To support his analysis, Kosta actively leverages on-chain data and metrics from leading platforms such as Santiment, Glassnode, and CryptoQuant, enabling deeper, evidence-based market insights. He believes in the power of transparency and the data that underpins the blockchain ecosystem. His academic background in Marketing Management from Denmark further complements his analytical approach, adding a strong understanding of communication strategy and content positioning to his work.
