<jonatack>
glozow: hardcoded dns seeds, can do if achow101 doesn't. i have a cjdns node that was removed due to it becoming a pruned node, but it's back to full archival now.
<jonatack>
"For the most part, manual peering is no longer required because cjdns auto peers from a DNS seed by default. However, if you want to ensure your node will always be connected to another node, or if you want to disable DNS seeding, then you need to do manual peering."
<jonatack>
cjdns v22.1 has been released and now includes auto-peering, which can simplify installation for bitcoin nodes (by no longer needing to do the "find a friend" step and add them to your conf file) and may more easily enable adding one-click cjdns support to node-in-a-package software
2024-08-26
<bitcoin-git>
bitcoin/master af550b3 Ava Chow: makeseeds: Support CJDNS
<bitcoin-git>
[bitcoin] jonatack opened pull request #30085: p2p: detect addnode cjdns peers in GetAddedNodeInfo() (master...2024-05-fix-cjdns-detection-in-GetAddedNodeInfo) https://github.com/bitcoin/bitcoin/pull/30085
2024-05-07
<bitcoin-git>
[bitcoin] vasild closed pull request #22563: addrman: treat Tor/I2P/CJDNS as a single group (master...addrman_per_group_bucketing) https://github.com/bitcoin/bitcoin/pull/22563
2024-04-18
<cjd>
2. Cjdns uses an Allocator structure (i.e. talloc) and Libuv does not shutdown synchronously so it is the cause of asynchronous onFree hook in the allocator which created an enormous amount of complexity
<cjd>
Hello Folks, I understand there was some discussion about removal of Libev from Core and the topic came up that I am working on getting Libuv out of cjdns - the choice to move away from Libuv is not exactly a negative for Libuv, but the way it has been used in the context of cjdns is not ideal at all.
<laanwj>
jonatack: interesting; i'd assume something like cjdns does actually need high performance networking, which is a good reason to use a library like libuv (eg to abstract various fancy OS-specific completion mechanisms), that said, if they're going the rust route there's plenty of other options
<jonatack>
"Cjdns running with Rust/Tokio based UDP Interface for the first time ever. Only thing left to do is port Pipe / PipeServer (i.e. unix socket / windows named pipe based interface) and then I can finally yank Libuv from the codebase." https://twitter.com/cjdelisle/status/1779990853844373820
<laanwj>
yes re: CJDNS and manual configuration, it's just as much work as setting up a wireguard connection manually
2024-03-20
<emzy>
I always needed to add other CJDNS "gateways" because I could not connect to the old. No idea what the issue was. Maybe changing home IP. FIW it was not woking for long without repeating attention.
<sipa>
vasild: i think a difference between CJDNS and I2P is the (by design) manual configuration needed for CJDNS
<vasild>
minimum amount of people to run bitcoin node on CJDNS. I was going to suggest this on https://github.com/bitcoin/bitcoin/issues/29618 where the OP pushes for p2p-v2-only option as if the presence of v1 connection is harmful and talks about environments where Tor and I2P are blocked. Surely, if CJDNS becomes popular it will be blocked as well :)
<vasild>
willcl-ark: laanwj: sipa: lightlike: My node has 1 p2p connection to a CJDNS node and in my addrman there are 2 (!?) CJDNS addresses. It works, but is not popular. One usecase for it could be in environments where Tor and I2P are blocked by a firewall/gov/isp/whatever and the operator still wants to hide the fact that they are running bitcoin node from their ISP. But for this it needs some
<willcl-ark>
laanwj: No I didn't manage to get CJDNS set up yet, as in actually connected into the network. Investigations into searching for peers to get bootstrapped led me to github, reddit etc. where there just seemed to be folks proclaiming it as dead (years ago), and mentioning Yggdrasil as a maintained/alive alternative L2 overlay project.
<achow101>
my crawler so far hasn't found any cjdns nodes, except the one I seeded it with
<sipa>
but in the case of CJDNS the benefit is pretty tiny
<sipa>
but there are perhaps expectations that matter; given how tiny the CJDNS-intersect-Bitcoin network is, choosing for example to run CJDNS-only would be an absolutely terrible idea
<lightlike>
"the amount of code dedicated to cjdns support is minimal (it's mostly just IPv6), i dont think it's that much of a maintenance burden?" Imo it's mostly the "MaybeFlipIPv6toCJDNS" hack that has caused some headaches (and is still not fixed everywhere I think).
<lightlike>
my experience with CJDNS is that it worked well and fast, but there were almost no other peers using it (<10 when I last checked).
<laanwj>
agree, i had a bitcoin node on cjdns, but it's a long time ago
<laanwj>
willcl-ark have you used yggdrasil? at least superficially it looks very similar to cjdns, as a custom mapping of public keys to IPv6; but it uses the `200::/7` range instead of `fc00::/8`
<laanwj>
the amount of code dedicated to cjdns support is minimal (it's mostly just IPv6), i dont think it's that much of a maintenance burden? that said, if no one uses it, there's no point
<brunoerg>
I think CJDNS doesn't have so many dev activity since 2020
<sipa>
i don't think CJDNS has really ever been functional
<willcl-ark>
Is CJDNS still relatively functional? It seems to me that the project is pretty much unmaintained -- about 10 bugfix commits in 2023 so I have some reservations about the maintenance burden vs usefulness. Browsing the subreddit also seems to indicate that most development (and users?) have migrated to Yggdrasil, and I'm wondering if we should consider a similar migration in the future?
2024-01-31
<bitcoin-git>
[bitcoin] achow101 merged pull request #26859: fuzz: extend ConsumeNetAddr() to return I2P and CJDNS addresses (master...ConsumeNetAddr_I2P_CJDNS) https://github.com/bitcoin/bitcoin/pull/26859
<bitcoin-git>
bitcoin/master b851c53 Vasil Dimov: fuzz: extend ConsumeNetAddr() to return I2P and CJDNS addresses
2023-11-16
<jon_atack>
achow101: I've been working on a more minimal changeset of 5 fixes backed by unit tests. I think the CJDNS ones are uncontroversial and can wait, as very few people use that network at the present time.
2023-11-02
<stickies-v>
we'll also be hosting a review club around the testing guide btw, so what we have done before is let attendees peer with each other (e.g. for CJDNS)
<vasild>
What about p2p encryption for Tor/I2P/CJDNS peers? Does that make sense? I guess no?
2023-08-17
<jon_atack>
2023-08-17T03:35:25.306155Z [scheduler] [net_processing.cpp:5170] [operator()] [net] Protecting from eviction last remaining cjdns outbound peer=36 that relays transactions: [fc70:704d:b268:cdbf:d622:ea9f:db12:859e]:8333 (outbound-full-relay)
2023-06-09
<bitcoin-git>
bitcoin/master 11bb31c Jon Atack: p2p: "skip netgroup diversity of new connections for tor/i2p/cjdns" follow...
2023-06-01
<bitcoin-git>
bitcoin/master 6fce5dd Marnix: doc: update getnodeaddresses for CJDNS, I2P and Tor and rm link
2023-04-20
<bitcoin-git>
bitcoin/master f5c8788 Jon Atack: p2p: update manual tor/i2p/cjdns mainnet seeds for 25.x
2023-04-18
<bitcoin-git>
[bitcoin] jonatack opened pull request #27488: p2p: update manual tor/i2p/cjdns mainnet seeds for 25.x (master...2023-04-hardcoded-seeds-update) https://github.com/bitcoin/bitcoin/pull/27488
2023-04-13
<bitcoin-git>
[bitcoin] achow101 merged pull request #27374: p2p: skip netgroup diversity of new connections for tor/i2p/cjdns (master...followup-27264) https://github.com/bitcoin/bitcoin/pull/27374
<bitcoin-git>
bitcoin/master b5585ba stratospher: p2p: skip netgroup diversity of new connections for tor/i2p/cjdns networks
<gribble>
https://github.com/bitcoin/bitcoin/issues/27374 | p2p: skip netgroup diversity of new connections for tor/i2p/cjdns by stratospher · Pull Request #27374 · bitcoin/bitcoin · GitHub
<gribble>
https://github.com/bitcoin/bitcoin/issues/27374 | p2p: skip netgroup diversity of new connections for tor/i2p/cjdns by stratospher · Pull Request #27374 · bitcoin/bitcoin · GitHub
<gribble>
https://github.com/bitcoin/bitcoin/issues/27374 | p2p: skip netgroup diversity of new connections for tor/i2p/cjdns by stratospher · Pull Request #27374 · bitcoin/bitcoin · GitHub
2023-04-02
<vasild>
Is it: "a configuration where exactly one -onlynet= is given and it is one of tor, i2p or cjdns"?
2023-03-30
<bitcoin-git>
[bitcoin] stratospher opened pull request #27374: p2p: skip netgroup diversity of new connections for tor/i2p/cjdns (master...followup-27264) https://github.com/bitcoin/bitcoin/pull/27374
2023-03-09
<jonatack>
Seems like a good reminder to host a mirror of the binaries (and the git repo?), say, on tor/i2p/cjdns
<bitcoin-git>
[bitcoin] vasild opened pull request #26859: fuzz: extend ConsumeNetAddr() to return I2P and CJDNS addresses (master...ConsumeNetAddr_I2P_CJDNS) https://github.com/bitcoin/bitcoin/pull/26859
2022-11-16
<jonatack>
these weren't rare occurences, at least in my testing, they were frequent. note that i use a vpn, have tor/i2p/cjdns peers, and some addnode manual peers with colleagues on the other side of the world.
2022-10-27
<jonatack>
lightlike: yes. i have manual conns with tor, i2p and cjdns for instance.
2022-09-25
<robertspigler>
How can I debug cjdns?
2022-09-21
<bitcoin-git>
[bitcoin] fanquake merged pull request #26145: [24.x] init: abort if i2p/cjdns are chosen via -onlynet but are unreachable (24.x...202208_onlynet_init) https://github.com/bitcoin/bitcoin/pull/26145
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #26145: [24.x] init: abort if i2p/cjdns are chosen via -onlynet but are unreachable (24.x...202208_onlynet_init) https://github.com/bitcoin/bitcoin/pull/26145
<bitcoin-git>
bitcoin/master 97f865b fanquake: Merge bitcoin/bitcoin#25989: init: abort if i2p/cjdns are chosen via -only...
<bitcoin-git>
[bitcoin] fanquake merged pull request #25989: init: abort if i2p/cjdns are chosen via -onlynet but are unreachable (master...202208_onlynet_init) https://github.com/bitcoin/bitcoin/pull/25989
<bitcoin-git>
bitcoin/master a8a9ed6 Martin Zumsande: init: Abort if i2p/cjdns are chosen via -onlynet but unreachable
<bitcoin-git>
bitcoin/master 68209a7 Martin Zumsande: rpc: make addpeeraddress work with cjdns addresses
2022-09-16
<vasild>
in my addrman: total: 68234, ipv4: 46391, onion: 11491, ipv6: 10237, i2p: 111, cjdns: 4
<bitcoin-git>
[bitcoin] mzumsande opened pull request #25989: init: abort if i2p/cjdns are chosen via -onlynet but unreachable (master...202208_onlynet_init) https://github.com/bitcoin/bitcoin/pull/25989
2022-09-01
<lightlike>
vasild: agree, but do you think it's worth making a PR to change just this? (considering that addpeeraddress RPC is debug-only and mostly for functional tests, which don't currently add cjdns addresses)
<vasild>
hmm, should we emit a startup warning or even abort startup if -onlynet=cjdns is given without -cjdnsreachable?
<vasild>
"I'm not sure what I did wrong" -- maybe you tried -onlynet=cjdns but without -cjdnsreachable?
<jonatack>
25 of 27 yesterday after the meeting, 24 of 27 now, various ip/tor/i2p/cjdns, some of them are peers that i know. but i'd like to look at it in more detail, e.g. breakdown by network or peers that i know versus unknown ones
2022-04-05
<bitcoin-git>
[bitcoin] laanwj merged pull request #24710: Add concrete steps in doc/cjdns.md to easily find a friend (master...doc-cjdns-how-to-find-a-friend) https://github.com/bitcoin/bitcoin/pull/24710
<bitcoin-git>
bitcoin/master 19538dd Jon Atack: Add concrete steps in doc/cjdns.md to easily find a friend
<bitcoin-git>
bitcoin/master 6a02355 Jon Atack: Add and improve informational links in doc/cjdns.md
<bitcoin-git>
bitcoin/master fe66dad laanwj: Merge bitcoin/bitcoin#24710: Add concrete steps in doc/cjdns.md to easily ...
<jonatack>
sipa: thanks (context, vasild are i were discussing this, i pinged him to add cjdns to the release notes, he used 23.x in the link, and i then mentioned to maybe go with master for the case that #24710 isn't backported to 23.x... anyway, no big deal)
<bitcoin-git>
[bitcoin] jonatack opened pull request #24710: Add concrete steps in doc/cjdns.md to easily find a friend (master...doc-cjdns-how-to-find-a-friend) https://github.com/bitcoin/bitcoin/pull/24710
2022-03-28
<jonatack>
Done. My intentions were only to fill in missing docs (CJDNS) and fix up incorrect ones.
<jonatack>
stickies: thanks for working on this! There have been only three CJDNS nodes that have been stable these past months. For the testing guide I would suggest using the ones added to the DNS seeds in #24166
<stickies-v>
Is anyone running a somewhat stable node on CJDNS and willing to somewhat commit to keep it up and running for a few weeks, until after RC testing is finished? There are already a few addresses listed in #23077 but since it's been a few months since that PR I'm not sure they're still in use, and of course the more the better to spread the load.
2022-03-17
<jonatack>
Guest58: yes sorry, I noticed that cjdns isn't in the release notes draft but didn't intend to suggest that it was an answer to your question.
<laanwj>
no, cjdns is not a privacy network, this is well-known, its usecase is for mesh networks, I2P and Tor are supported privacy overlay networks
<jonatack>
right, the reason i mention the cjdns testing is also that there are more moving parts, platforms, cases and possible issues that may not have been seen yet
<jonatack>
(e.g. convert the I2P testing section for v22 to CJDNS)
<bitcoin-git>
[bitcoin] jonatack opened pull request #24555: doc: create initial doc/cjdns.md for CJDNS how-to documentation (master...cjdns-doc) https://github.com/bitcoin/bitcoin/pull/24555
2022-03-02
<bitcoin-git>
[bitcoin] laanwj merged pull request #24165: p2p: extend inbound eviction protection by network to CJDNS peers (master...protect-inbound-cjdns-peers-from-eviction) https://github.com/bitcoin/bitcoin/pull/24165
<bitcoin-git>
bitcoin/master f7b8094 Jon Atack: p2p: extend inbound eviction protection by network to CJDNS peers
<bitcoin-git>
bitcoin/master 0a1bb84 Jon Atack: test: add tests for inbound eviction protection of CJDNS peers
2022-02-04
<jonatack>
(i2p 160, cjdns 4)
<laanwj>
apparently we didn't do a hardcoded seeds update for 22.0 (at least not for ipv4/ipv6, and we don't really have an automated way to generate hardcoded seeds for torv3/i2p/cjdns yet)
2022-02-03
<laanwj>
i hope cjdns.md will help some people find friends :p
<jonatack>
vasild and i are coordinating to propose a doc/cjdns.md for v23 as well
<laanwj>
we might want to mention more explicitly that cjdns is not an open overlay network like I2P and Tor
<m011>
If I understand correctly, "find a friend" is literal. To be able to connect to the CJDNS network, you first need to find trusted peers willing to share the connection.
<vasild>
adding doc/cjdns.md has been on my todo for some time...
<laanwj>
m011: as i've been trying to say all the time, you *first* need to ensure your connectivity to CJDNS, so have a running cjdns daemon and cjdns nodes, only then bitcoin core will work over it and will be able to connect to bitcoin cjdns nodes
<sipa>
@m011 You need a means of connection to the cjdns network (hyperboria). How you get that is your own responsibility.
<m011>
sipa: Got it. But without these step (2 and 3 in the doc - which is to connect to other peers), will CJDNS work with Bitcoin Core ?
2022-01-26
<jonatack>
m011: once you are connected to the cjdns network, then running the following will work: ./src/bitcoin-cli addnode fcc7:be49:ccd1:dc91:3125:f0da:457d:8ce onetry
<jonatack>
i might write some getting started info, i.e. doc/cjdns.md
<jonatack>
m011: both of the cjdns seed nodes are up
<laanwj>
yes, addnode should work with a cjdns address, and no, i am not running cjdns myself
<m011>
Got it. But should `addnode` work? Do you have any public CJDNS that I can add for a test?
<laanwj>
it's extremely unlikely you'd automatically get cjdns addresses at this point, it's not in a release yet, any cjdns bitcoin nodes are running the master branch
<sipa>
It could take forever to get outbound CJDNS peers. I don't think the outbound logic preferentially selects those over IPv4 or IPv6.
<laanwj>
you'd debug it like any kind of network interface, so you could try to ping some known addresses on the CJDNS network (with "ping6"), as well as the ones added in that PR, you could also try opening TCP connections with netcat (nc -v addr port)
<m011>
So it should take a while to automatically get CJDNS addresses? Even though the 12 outbound connections are filled by ipv4 (or tor) ?
<sipa>
I assume that the number of CJDNS nodes on the network is extremely low, so that's not surprising.
<m011>
I'm not familiar with CJDNS and not sure how to debug it, I started the node with -cjdnsreachable=1 but I've only been getting ipv4 addresses.
<laanwj>
CJDNS is simply another network interface from the viewpoint of the application, so if bitcoin can't connect, there's a large chance something is wrong at a lower level
<laanwj>
can you ping the address? or other addresses on the CJDNS network?
<sipa>
Alternatively, you can use -addnode or the addnode RPC to force a connection to one of them, if you have a CJDNS address of someone you want to connect to.
<sipa>
If CJDNS addresses get rumoured on the network, your node may decide to connect to them.
<m011>
Yes. `systemctl status cjdns` shows `Active: shows active (running)`
<sipa>
Do you have cjdns running?
<m011>
The CJDNS document says that I need to find trusted peers and send them a specific credential for each peer. That's it ?
<m011>
How can node connect to CJDNS peers? IS there a tutorial ?
<bitcoin-git>
[bitcoin] jonatack opened pull request #24166: p2p, contrib: add cjdns hardcoded seeds and update the i2p seeds (master...update-hardcoded-seeds) https://github.com/bitcoin/bitcoin/pull/24166
<bitcoin-git>
[bitcoin] jonatack opened pull request #24165: p2p: extend inbound eviction protection by network to CJDNS peers (master...protect-inbound-cjdns-peers-from-eviction) https://github.com/bitcoin/bitcoin/pull/24165
2021-11-15
<bitcoin-git>
[bitcoin] sipa closed pull request #23175: Add CJDNS network to -addrinfo and -netinfo (master...add-cjdns-to-addrinfo-and-netinfo) https://github.com/bitcoin/bitcoin/pull/23175
<bitcoin-git>
bitcoin/master 5bd40a3 Jon Atack: cli: add cjdns network to -addrinfo and -netinfo
<bitcoin-git>
bitcoin/master caf8b26 W. J. van der Laan: Merge bitcoin/bitcoin#23175: Add CJDNS network to -addrinfo and -netinfo
<stick>
I see there is CJDNS being added to bitcoin-core
2021-10-08
<jonatack>
on a node running ip/onion/i2p/cjdns
<laanwj>
looks like the precompiled freebsd package for cjdns doesn't work on my server, it crashes with "illegal instruction" because it uses vxorps %xmm0,%xmm0,%xmm0 which is... avx
<jamesob>
cjdns testers: are running cjdnsroute with sudo? anyone figure out a clever way of avoiding that, or just yolo?
2021-10-05
<vasild>
I added the routing manually with "route add -6 fc00::/8 fc00::1", not sure if this is supposed to be done automatically by cjdns or not
<vasild>
laanwj: I am using cjdns on freebsd from ports. There is a useful script peerStats used to check which nodes are you connected to which is not installed by the port, so I call it via /usr/ports/net/cjdns/work/cjdns-cjdns-v21.1/tools/peerStats
2021-10-04
<sipa>
i have a publicly reachable cjdns router running now, and seems i can connect to it
<laanwj>
i'd like to set up CJDNS again as well, but lost all my peers from last time i used it [which was years ago], back then i don't think they had public nodes you had to go on IRC and ask for peers :-)
<sipa>
(over cjdns)
<bitcoin-git>
[bitcoin] jonatack opened pull request #23175: Add CJDNS network to -addrinfo and -netinfo (master...add-cjdns-to-addrinfo-and-netinfo) https://github.com/bitcoin/bitcoin/pull/23175
<jonatack55>
*in the /tools directory in cjdns repo root
<jonatack55>
also TIL from vasil about the tools like ./tools/peerStats in the cjdns repo root
<vasild>
it seems that cjdns does not come with hardcoded seeds
<jonatack55>
(restart of cjdns, restart of bitcoind wasn't needed)
<sipa>
i have cjdns installed, but then saw this stuff about hyperboria, and gave up
<jonatack55>
yay, vasild and i are connected via bitcoind over cjdns
<jonatack55>
getnetworkinfo networks returns cjdns reachable true, local_addresses returns that address after the other ones
<jonatack55>
vasild: i think i'm running bitcoind with a cjdns service at [fc32:17ea:e415:c3bf:9808:149d:b5a2:c9aa]:8333
<vasild>
I don't think it should try to connect to some fc00::/8 address by default only because -cjdnsreachable=1 is present. If it tries (e.g. due to addnode=fc...) and cjdns is not running, then connecting to that node will timeout, same as if the node alone is down.
<jonatack>
thanks! that could be, i am just getting started with it. fwiw, -cjdnsreachable=1 with cjdns not running made bitcoind appear to halt/become unresponsive, but only tried that once so far.
<jonatack>
vasild: is your cjdns node up?
2021-09-24
<prayank>
vasild: I read your response in the CJDNS PR. Agree with almost everything. It makes sense. However wanted to know your thoughts on GNUnet.
2021-09-23
<vasild>
one of those Sock'ification PRs needs a rebase, but I decided to ignore it until I submit the cjdns PR
< prayank>
vasild: Interesting PR. Change looks quite obvious for Tor and i2p. Not sure about CJDNS. Although there must be some reason it wasn't done until now, would like to read comments from others who understand p2p and networking better.
< bitcoin-git>
[bitcoin] vasild opened pull request #22563: addrman: treat Tor/I2P/CJDNS as a single group (master...addrman_per_group_bucketing) https://github.com/bitcoin/bitcoin/pull/22563
< vasild>
CNetAddr::GetGroup() and the places where it is called are build around the assumption that it is easier to obtain addresses with common prefix (e.g. belonging to one IP subnet). However this assumption is not true for Tor, I2P and CJDNS addresses. Is there any work or plan to resolve this?
2021-02-25
< jonatack>
vasild: thanks! above all, looking for feedback on the protection allocation ratios between regular, onion, localhost (and soon i2p, and maybe cjdns) peers, i went for the simplest thing but it maybe protects too many localhost and onion peers
2021-02-08
< wumpus>
interesting! highlights for me were RISC-V/secure architectures (CheriBSD was interesting, a POSIX veriant using pointer capabilities for memory safety throughout), overlay networks and P2P (point of note for me was "yggdrasil" which is inspired by CJDNS but does some things differently), open source CAD tools, and update about openwifi (open software/hardware wifi)
2021-01-19
< jonatack>
shesek: i'm responsible for both issues you reported :) i recently added a functional test for NET_UNROUTABLE in test/functional/feature_proxy.py that does assert on getpeerinfo#network returning "unroutable". maybe it should be added to the getpeerinfo help that currently states "Network (ipv4, ipv6, or onion) the peer connected through"...along with i2p and cjdns maybe as well
< sipa>
which reminds me: we can't put torv3/i2p/cjdns in version messages, so those will never receive any mentions
< wumpus>
cjdns not because it uses IPv6 addresses in a range we consider local / unroutable?
< sipa>
sdaftuar: i2p/cjdns do not get rumoured by the current code, at all
2020-09-16
< vasild>
Wrt the next bip155/torv3 PR, assuming #19845 gets merged - #19031 has two more commits "net: CAddress & CAddrMan: (un)serialize as ADDRv2" (+193/-15) and "net: advertise support for ADDRv2 via new message" (+129/-8). Then we will have done BIP155 - will gossip torv3/i2p/cjdns addresses if we receive them (even though we may not be able to make use of them yet). After that we need one more change
2020-04-29
< vasild>
wumpus: dongcarl: anyway, I plan to spend full time on BIP155/addrv2/torv3/i2p/cjdns, modulo distractions :)
< vasild>
Right! Netmasks do not make any sense in the new types too: torv3, i2p, cjdns.
2019-07-19
< sipa>
it will just fail to deserialize entirely if it contains torv3/i2p/cjdns
< dongcarl>
sipa: Ah... So if I understand you correctly, this way disk serialization of ipv4, v6, and torv2 will be in the older format... Which means if I generate a peers.dat in a newer client and feed it to an older one, the older client will pick up everything except torv3, i2p, and CJDNS?
< cjd>
For cjdns, I used the first 4 bytes of the seed as the test id
2018-12-31
< cjd>
This is funny, 4 years ago bitcoin could only possibly work on little endian (probably only on i386/amd64) and cjdns had nice endian swapping macros and all of that
2018-06-01
< wumpus>
gmaxwell: that's true; the differece is that cjdns runs as a network interface, so from the viewpoint of the application it's simply IPv6 networking. OTOH it's possible to set up the firewall to do the same with TOr, so I'm not sure it's a useful distinction for this.
< gmaxwell>
I suspect it should, since you can't reach them unless you use CJDNS? so it's like onion embedded tor?
< wumpus>
I wonder if CJDNS should get its own network id, the reason I'm not sure is because they're explicitly IPv6 addresses
2017-04-11
< wumpus>
though I think it's mainly exit nodes that helped tor gain adoption, it's hard to get critical mass for an isolated network, as cjdns, i2p etc have found out
2015-11-14
< wumpus>
(but cjdns does recommend starting it as root, which was one of the things that put the idea in my head, but they need it for tun setup)