Bring your laptop if you have a Bitcoin Core node set up on it, and don't hesitate to have the documentation resources open that follow below.

What is I2P?

I2p is an anonymizing network, offering a simple layer that identity-sensitive applications can use to securely communicate. All data is wrapped with several layers of encryption, and the network is both distributed and dynamic, with no trusted parties.

I2P connections have a "source address" -- it is certain that the peer who connects from a given I2P address to us possesses the private key that corresponds to that I2P address. This can be used for white-listing "friends." It is a stronger guarantee than IP addresses (which can be spoofed by your ISP, for instance).

What is CJDNS?

CJDNS is an encrypted IPv6 network that uses public-key cryptography for address allocation and a distributed hash table for routing. It builds an end-to-end encrypted IPv6 mesh network that utilizes the fc00::/8 address space (reserved IPv6 range) and a friend-of-a-friend network topology. It is like a distributed, shared VPN with multiple entry points where every participant can reach any other participant.

Compared to IPv4/IPv6, CJDNS provides end-to-end encryption and protects nodes from traffic analysis and filtering.

Used with Tor and I2P, CJDNS is a complementary option that can enhance network redundancy and robustness for both the Bitcoin network and individual nodes.

Why use multiple Bitcoin peer-to-peer networks?

Using multiple networks provides potentially better decentralization, network robustness and censorship resistance, e.g. I2P or CJDNS may be operational when Tor isn't or has degraded operation, while not degrading relative privacy/fingerprinting compared to running Tor alone.

Each network has different characteristics. For instance, Tor is widely used but somewhat centralized, which can lead to problems (consensus node attacks, DoS, censorship, etc). Recently, various forms of DoS have been ongoing for nearly half a year now (see https://status.torproject.org/issues/).

I2P can be fairly slow in latency (similar to Tor), and unlike Tor, connections have a source address. However, since the upcoming v24 release, Bitcoin Core automatically generates a new transient address for every outbound I2P peer connection when listening is off, i.e. when your node doesn't accept inbound connections (-i2pacceptincoming=0).

CJDNS is generally quite fast but does not hide the sender and the recipient from intermediate routers. It was designed to be used with a friend-of-a-friend topology. It builds an overlay network which traverses NAT (Network Address Translation), exposing all ports of every node to every other node within the network. Those who are used to relying on NAT to protect their devices may find this troublesome.

Overall, it is good to have options and redundancy. I've found both I2P and CJDNS to work very well for my nodes alongside Tor, and they generally show the first peer connections on node startup.

There are also security considerations with running only Tor, i.e. -onlynet=onion.

Sybil/Eclipse attacks: If you only make random Tor connections, you're much more vulnerable to Sybil attacks. As Tor addresses may be created at no cost, an attacker can potentially flood the network with many Tor nodes and take all of your node's outbound connection slots.

If all of your connections are controlled by a Sybil attacker, they can prevent you from seeing confirmed transactions and, with more difficulty, even trick your node into falsely reporting a transaction as confirmed on the blockchain with the most cumulative chainwork.

This can be alleviated by making manual -addnode connections to trusted peers, as a connection to a single honest peer is enough to thwart an attempted eclipse attack. (It can also be alleviated with IPv4/IPv6 connections -- particularly when using the -asmap configuration option -- due to the cost of obtaining IPs in many networks.)

Network Partitioning: If too many nodes use -onlynet=onion, it could become difficult for onion nodes to communicate with clearnet, I2P, and CJDNS nodes, preventing the Tor network from seeing recent transactions and blocks. It is essential that some nodes access multiple networks.

Bonus info:

Historically, on mainnet the Bitcoin Core P2P listening port has been 8333 -- Bitcoin Core had a strong preference for only connecting to nodes that listen on that port.

Since Bitcoin Core v23, that preference was removed, because connections over clearnet involving port 8333 make it easy to detect, analyze, block or divert Bitcoin P2P traffic before the connection is even established (at TCP SYN time).

RESOURCES

BIP 155:
- https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki

Bitcoin Core Tor, I2P and CJDNS documentation:
- https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md
- https://github.com/bitcoin/bitcoin/blob/master/doc/i2p.md
- https://github.com/bitcoin/bitcoin/blob/master/doc/cjdns.md

Monitoring your Bitcoin Core node from the command line with three open windows:
- a window for the debug log
- a window with a live CLI -getinfo dashboard: $ watch --no-title --interval 10 ./src/bitcoin-cli -rpcwait -getinfo
- a window with a live CLI -netinfo dashboard (network connections): $ watch --no-title --interval 4 ./src/bitcoin-cli -rpcwait -netinfo 4

Run the following for -netinfo help: $ ./src/bitcoin-cli -netinfo help

Note:
- watch is built into Linux as the watch(1) command.
- with macOS, watch can be installed using brew, i.e. $ brew install watch
- adjust the --interval (in seconds) and --no-title arguments as you prefer

You can also check the number of peers your node knows by network type by running: $ ./src/bitcoin-cli -rpcwait -addrinfo