Future of CJDNS support #36041

issue mzumsande opened this issue on August 20, 2026

mzumsande commented at 3:29 PM on August 20, 2026: contributor
CJDNS support was added in v23.0 (#23077, released in early 2022).

Unfortunately, it never got much traction among users, in spite of a meaningful amount of work that was put into it:
- I recently tried -onlynet=cjdns out of curiosity on mainnnet, never got more than 4 peers. Today, I got 3 peers. There are 11 fixed seeds, so many of them appear to be offline.
- In the past, usually the complicated setup (one had to manually find an initial peer) was seen as the reason why there are so few nodes. However, this was improved some time ago (documented in #34811), but it doesn't seem to have made much of an effect so far.
- Maintenance cost is not zero: CJDNS is not cleanly separable from IPv6, leading to the necessity of the -cjdnsreachable and MaybeFlipIPv6toCJDNS workarounds. Especially the latter has been the source of multiple bugs and fixes.
Maybe we could try to advertise cjdns more, so that more people know that it is an option, and that it is no longer hard to set up.

I think that for a network to justify continued support, it should reach more interest at some point, especially because cjdns-only nodes (which is discouraged after #35963) would be in danger of being eclipsed. As a rough number, I feel that the number of nodes should be at least in the low triple digits.

What do other people think about this? Should a network meet certain criteria to keep being supported, and should we consider removing cjdns support at some point if nothing changes?

fyi @vasild @jonatack
151henry151 commented at 4:34 PM on August 20, 2026: contributor

Not sure if this has been considered, but could the threshold be grounded in eclipse cost, roughly how many nodes an attacker would need to fill a cjdns-only node's 8 full-relay and 2 block-relay-only outbounds? That might give a criterion that generalizes to future networks.
achow101 commented at 5:22 PM on August 20, 2026: member

Looking at my seeder's database, it currently has only 25 CJDNS nodes in its database, of which 22 have been reached, and of those, only 7 are marked "good".
sipa commented at 7:43 PM on August 20, 2026: member

Concept ACK on deprecating CJDNS support.

In addition to low raw node count numbers there, I question the value of a network where connections need to be manually established in practice anyway. Something quite close can be achieved using -addnode with less configuration overhead.
0xB10C commented at 11:56 PM on August 20, 2026: contributor

I'm running a couple of nodes reachable via CJDNS (primarily for monitoring), and the maximum number of connections to CJDNS nodes I had on one of these nodes was 5 at the same time. I don't know if these connections were to my nodes, but seeing the numbers here makes it sound like they were.

Unless there's going to be a lot more usage of CJDNS, I don't think it's worth maintaining it for much longer.
maflcko added this to the milestone 33.0 on Aug 21, 2026
maflcko removed this from the milestone 33.0 on Aug 21, 2026
maflcko added this to the milestone 32.0 on Aug 21, 2026
maflcko commented at 5:28 AM on August 21, 2026: member

As a rough number, I feel that the number of nodes should be at least in the low triple digits.

Agree. The ratio of num_users/num_devs for a feature should be ~100+. Looks like here it is less than 1, when discounting test-only nodes from devs? Maybe a release note can be added to 32.x that the feature is planned to be removed in 33.x?
fanquake commented at 7:56 AM on August 21, 2026: member

Concept ACK on deprecation / removal.
brunoerg commented at 5:11 PM on August 21, 2026: contributor

Concept ACK
jonatack commented at 5:30 PM on August 21, 2026: member
Auto-peering in CJDNS was added in January 2025 (changelog).

Before that, it was necessary to find a friend to access the network, an extra step that Tor and I2P did not require, and a fastidious one.

The documentation in Bitcoin Core was updated to describe auto-peering 5 months ago, in the latest release of Bitcoin Core. I don't see any mention of this doc update in the v31.0 or 31.1 release notes. It seems unsurprising if awareness of the new feature is currently low.

The path to increased adoption is:
- Awareness.
- Easy one-click support in popular node software packages like Raspiblitz, Umbrel, Start9, etc. Since auto-peering was added, this should now be much easier to implement.
- Need: optional, but possible, for instance if both Tor and I2P were to go down at the same time.
Both the Tor and I2P networks have seen sustained, severe attacks in the past.

At the moment, the value of CJDNS is that of a backup option. Even if not used yet, good to have.

I am willing to maintain support for it, elsewhere or here.
stickies-v commented at 10:30 AM on August 24, 2026: contributor

Concept ACK
151henry151 commented at 11:18 PM on August 24, 2026: contributor

Concept NACK on deprecation: I just set up CJDNS on my pruned node (IPv4/IPv6/CJDNS, not -onlynet=cjdns), now inbound-reachable at [fcfb:b37a:6e61:4772:dbb2:1d0c:fdc1:d3c4]:8333. Setup only took a few minutes. @jonatack, count me in for maintenance work.
willcl-ark commented at 8:18 AM on August 25, 2026: member

Concept ACK on removing CJDNS.

Whilst I do conceptually like CJDNS, I don't think we can ignore that we've probably never had more than 10 nodes concurrently running on it (if the current count of 7 above is accurate, it's probably 0xb10c, mzumzande, jonatack and one or two other experimenting devs), and at that point it's clear that, as a source of bugs, it's pretty much just a maintenance burden at this point.

For me CJDNS' most attractive properties are its full decentralised DHT model, NAT traversal, and lower latency (than our other alternative networks).

Although Tor is somewhat centralised via its directory authorities, I2P has a more decentralised model in its distributed netDB approach. Tor and I2P both also traverse NAT well (via their onion and SAM proxies). So at the end we are left primarily losing CJDNS' superior latency, and a network type. In practice, with current adoption numbers, those benefits are almost never realised, while the maintenance cost remains.

CJDNS ~ trades off anonymity for latency as sender and receiver are visible to all (routing) hops. This makes it much less attractive for use-cases such as "bitcoin is banned in my country and I want to run a node" than Tor for example, as an ISP may be able to use traffic analysis to determine that it's bitcoin traffic you are running, even if they can't decrypt the exact content.

Both the Tor and I2P networks have seen sustained, severe attacks in the past.

Is there something that protects CJDNS from this type of attack vs those networks, or is it that "it's too small/unused to bother to attack"?
willcl-ark added the label Brainstorming on Aug 25, 2026
willcl-ark added the label Net on Aug 25, 2026
mzumsande commented at 12:40 PM on August 26, 2026: contributor

Maybe a release note can be added to 32.x that the feature is planned to be removed in 33.x?

Maybe a release note that mentions both the easier setup, but also the low number of peers and also says that it will get depreciated in a future version if the number of peers doesn't increase significantly? That way users get a chance to start running it, in case there is actual interest out there (also among non-devs). I don't think we need to remove it in 33.x already, giving it a little more time seems fine to me.