Future of CJDNS support #36041

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.

fanquake commented at 9:08 AM on September 9, 2026: member

Opened #36202 with a rel note to document this for 32.x (which can be adjusted in the wiki).

fanquake removed this from the milestone 32.0 on Sep 9, 2026

fanquake added this to the milestone 33.0 on Sep 9, 2026

fanquake commented at 9:39 AM on September 9, 2026: member

Assuming we document this for 32.x, I've moved the milestone to 33.x, so we can revisit the state of the node numbers.

achow101 referenced this in commit af83bacdf9 on Sep 9, 2026

jonatack commented at 8:28 PM on September 9, 2026: member

the state of the node numbers

I would submit that this is both a misleading metric and an irrelevant one.

Misleading for the reasons I gave in #36041 (comment).

Irrelevant because the value is not in the current use, as it is currently not perceived as urgently needed, but rather in the optionality that having this additional network provides.

Much greater effort is being put into, say, asmap. Which to be clear, I have nothing against.

Like cjdns, the value is in its potential use, not the current numbers.

jonatack commented at 8:46 PM on September 9, 2026: member

For me CJDNS' most attractive properties are its full decentralised DHT model, NAT traversal, and lower latency (than our other alternative networks). @willcl-ark I think this is a more interesting discussion and fundamentally the only relevant one. It makes sense to discourage/warn/remove cjdns only if it is considered not to provide value even when more widely adopted.

willcl-ark commented at 8:46 PM on September 9, 2026: member

the value is not in the current use, as it is currently not perceived as urgently needed, but rather in the optionality that having this additional network provides.

Sure I'd agree that the value includes potential future use. For example a government restricting Bitcoin would make alternative networks much more important than current adoption suggests, and having support already available would be essential.

The point being made though is that preserving that option has an ongoing cost, including changes to shared networking code and the bugs those interactions introduce. We need to weigh the additional resilience CJDNS provides alongside Tor and I2P against that cost. Low current usage on its own might not be sufficient grounds for removal, but potential future usefulness isn't necessarily either sufficient grounds for retaining every alternative network indefinitely.

Perhaps the question can be reframed as "what restrictions or failures do we expect CJDNS to withstand that IPv4/IPv6, Tor and I2P would not, and how much maintenance are we willing to take on to preserve that additional resilience?"

willcl-ark commented at 8:47 PM on September 9, 2026: member

@jonatack I see we posted together! I agree that's probably the pertinent question (which I tried to reframe in my earlier response)

jonatack commented at 8:51 PM on September 9, 2026: member

Perhaps the question can be reframed as "what restrictions or failures do we expect CJDNS to withstand that IPv4/IPv6, Tor and I2P would not

Yes.

how much maintenance are we willing to take on to preserve that additional resilience

I think (a) this is somewhat exaggerated, and removal may cause more bugs and work than keeping it, and (b) more generally, where they conflict, I would err a bit more on the side of the users and network than that of making the code marginally nicer to deal with.

I agree that's probably the pertinent question

Yes!