Bitcoin Core considers dropping encrypted routing support as poor node health exposes users to eclipse attacks
Bitcoin Core developers are debating whether to deprecate CJDNS, an encrypted peer-to-peer routing protocol, after discovering only seven functional nodes in the entire network, a pool so thin it may expose users to eclipse attacks that isolate nodes from the blockchain. The decision carries implications for privacy-focused node operators and signals growing concern about maintaining obsolete infrastructure within the protocol’s reference implementation.
- Only seven nodes classified as operationally sound across entire CJDNS network, down from 22 reached addresses in seeder database
- Martin Zumsande reported finding just three to four CJDNS peers despite Bitcoin Core shipping 11 fixed CJDNS seeds by default
- Developers considering deprecation warning in version 32.x followed by removal in 33.x, though timeline remains unconfirmed
- 7 Good CJDNS nodes versus 22 total reached addresses in seeder database
- 3-4 Peers found by developer despite 11 fixed CJDNS seeds shipped by default
- 100-999 Triple-digit node count threshold proposed by Zumsande to justify continued support
Bitcoin Core maintainers are confronting a hard infrastructure question: whether to retain optional CJDNS support as a privacy feature or remove it as a security liability. The encrypted routing layer, designed to offer anonymity benefits for node operators unwilling to expose their IP addresses on the clearnet, has deteriorated into a sparsely populated network vulnerable to targeted attacks.
Andrew Chow, a Bitcoin Core contributor, examined seeder data showing only seven nodes meeting strict operational standards, a figure that prompted frank discussion about whether maintaining the protocol still serves users or simply creates maintenance burden and security risks.
The debate, unfolding in Bitcoin Core issue #36041, represents a reckoning over which features deserve space in the reference implementation when their user base has contracted sharply.
Seven functional nodes expose CJDNS users to concentrated eclipse attack surface
The technical foundation for removing CJDNS rests on network health metrics that paint a bleak picture. When Andrew Chow analyzed one seeder database, a snapshot tool that crawls and validates reachable nodes, he found 25 CJDNS addresses initially recorded, 22 that could be reached, and only seven that passed strict operational filters.
Those filters, implemented in Chow’s DNSSeedrs implementation, check port reachability, advertised network services, protocol version, chain height synchronization and rolling reliability across multiple time windows. A node must clear all those bars to be classified “good,” which explains the dramatic falloff from 22 reached to seven validated.
Martin Zumsande, the developer who opened the issue, conducted independent testing and found even bleaker results from an end-user perspective: attempting to connect to CJDNS peers yielded only three to four actual connections, despite Bitcoin Core’s default configuration shipping 11 fixed CJDNS seeds.
That disparity between shipped seeds and actual functional peers illustrates how sharply the network has contracted. The seeder database captures one crawler’s view at one moment in time, so the true global CJDNS population may be slightly larger, but Zumsande’s practical experience as a node operator suggests the network’s functional capacity has collapsed to near-unusable levels.
This thin peer pool creates acute vulnerability to eclipse attacks, a class of network assault where an attacker monopolizes all outbound connections from a target node and shapes its view of the blockchain.
Bitcoin Core normally maintains eight full-relay outbound connections and two block-relay-only connections, with occasional variations.
On CJDNS, where the known address set is tiny and public, an attacker has a concentrated target: a determined adversary with control over even a handful of the seven good nodes could plausibly surround a CJDNS-only node and feed it false transaction and block data.
Bitcoin Core’s own documentation already discourages exclusive CJDNS operation for this reason, warning that nodes may exhaust the few known addresses and become susceptible to Sybil attacks where a single attacker operates multiple fake peer identities.
Zumsande proposes low triple-digit threshold to define minimum viable CJDNS network
Rather than frame the problem as a vague complaint about “low usage,” Zumsande offered a concrete metric: somewhere in the low triple digits, roughly 100 to 999 nodes, might justify continued CJDNS support. That specific benchmark gives maintainers a numerical pole to argue around instead of debating indefinite qualitative decline.
At seven good nodes, the network sits orders of magnitude below that threshold, even allowing for undercounted nodes the seeder may have missed.
Contributors have suggested grounding any CJDNS retention decision in the cost of filling Bitcoin Core’s standard outbound connection slots.
The logic is straightforward: if a CJDNS-only node cannot reliably acquire the eight to ten peers it needs, maintaining those slots empty defeats Bitcoin Core’s network resilience design. A node forced to reuse the same few addresses repeatedly becomes easier to eclipse precisely because its peer universe is so constrained.
One contributor framed the question as whether Bitcoin Core should keep CJDNS address handling purely as a fallback mechanism or deprecate it entirely, given that the thin peer pool may have already crossed the point of providing meaningful anonymity or eclipse protection.
Bitcoin Core considering phased CJDNS deprecation with 32.x warning and 33.x removal
The proposed implementation timeline would spread CJDNS deprecation across two release cycles, matching Bitcoin Core’s practice of providing advance notice for breaking changes. Andrew Chow and other contributors have suggested issuing a deprecation warning in version 32.x, alerting users that CJDNS support will be removed in version 33.x.
That timeline would give remaining CJDNS operators months to migrate alternative infrastructure or accept that privacy-focused node operation on Bitcoin would require other tools outside the reference implementation.
As of August 23, however, the deprecation timeline remained a proposal rather than a decided course. Issue #36041 sat open in Bitcoin Core’s 32.0 milestone with no implementation branch or pull request yet filed, meaning maintainers had not formally committed to the phased removal approach.
The discussion continues to weigh the costs of supporting a near-moribund network feature against the costs of breaking node operators who have built workflows around CJDNS privacy properties.
The unresolved question cuts to a broader tension within Bitcoin development: whether reference implementation features should be trimmed based on usage metrics, or whether niche privacy tools deserve preservation even with minimal user bases.
CJDNS was never a consensus-critical component, Bitcoin Core implements it as optional peer-to-peer transport and address handling outside the blockchain’s validation rules, which technically simplifies removal.
Yet removal would signal that Bitcoin’s lead development team views infrastructure maintenance costs as a legitimate reason to sunset privacy features, a precedent with implications for other rarely used but anonymity-oriented code paths.
Bitcoin Core maintainers have not yet scheduled a formal decision or filed a pull request to implement the deprecation timeline. The debate’s next inflection point will come when a developer submits code to add a 32.x warning message, forcing the maintainer group to vote on whether they accept the premise that seven functional CJDNS nodes constitutes grounds for removal, or whether the network’s decentralization properties warrant continued support despite eclipse risks and maintenance burden.
