They are separate network paths for Bitcoin node communication: Tor uses a SOCKS proxy and onion services, I2P uses tunnels through the SAM interface, and CJDNS is an encrypted IPv6 overlay; these mechanisms change neither transactions, the blockchain nor consensus and do not by themselves guarantee user anonymity.
An anonymity network addresses transport between nodes, not the contents of a Bitcoin transaction. It can hide an ordinary IP address from the counterparty or make path observation harder, while public amounts, address links, timing and on-chain heuristics remain separate problems. [5]
Bitcoin Core can route outbound connections through a Tor SOCKS proxy and create a Tor v3 onion service for inbound connections. Since version 22.0 it ignores Tor v2 addresses; a misconfiguration can let DNS or clearnet traffic bypass the intended route, so the combination of -proxy, -onion, -onlynet, -bind and firewall rules matters. [1]
I2P connections use an external I2P router with a SAM interface, usually at 127.0.0.1:7656. Bitcoin Core has supported I2P since version 22.0 and by default creates a persistent I2P address and key when accepting connections; with -i2pacceptincoming=0 it uses a transient address for each outbound connection, although the I2P counterparty sees the initiator's address. [2]
CJDNS is an encrypted IPv6 overlay with addresses in fc00::/8 and public-key-based routing. Bitcoin Core has supported it since version 23.0 through -cjdnsreachable; the documentation explicitly warns that CJDNS does not conceal sender and recipient from intermediate routers and that relying on it alone is unwise when few peers are available. [3]
BIP 155 introduced sendaddrv2 and addrv2 messages with variable-length addresses and separate network IDs for Tor v3, I2P and CJDNS. A node can therefore store and gossip those endpoints; announcing an address alone does not prove that the node uses that network or carried particular traffic through it. [4]
Using several networks at once can improve availability and make an eclipse or partition attack harder because the node has distinct paths to peers. The same setup can link identities that appear separate: an adversary can compare uptime, behavior, jointly announced addresses, or traffic on the clearnet and overlay network. [1]
Tor, I2P and CJDNS make different trade-offs in latency, available peer count, endpoint visibility and Sybil resistance. An onlynet mode can limit leakage onto another network, but a smaller peer set can slow synchronization and increase dependence on a few nodes; no option fixes wallet mistakes or blockchain analysis. [3]
Verification must inspect actual sockets and node state: getnetworkinfo, -netinfo, -addrinfo and getpeerinfo show local addresses, known endpoint counts and concrete connections. In addition to Bitcoin Core configuration, inspect the running Tor or I2P router, CJDNS interface, DNS path, binds, firewall, and whether both inbound and outbound traffic really use the intended network. [2]
For the clearest picture, read this entry together with Bitcoin Privacy, Full Node, Bitcoin Core, Dandelion++, Transaction, Lightning Routing. The reverse links also lead from Paralelní Polis, Reusable Proofs of Work, Mix Network, Sybil Attack.
01Does Tor make a Bitcoin transaction anonymous?+
No. Tor can hide a node's network path or ordinary IP address, but the transaction is still recorded publicly on the blockchain. Coin selection, address reuse, amounts, timing and a link to an exchange can identify a user even when Tor works correctly.
02Which anonymity network is best for Bitcoin?+
There is no single answer without a threat model. Tor has the broadest support, I2P offers a different internal network, and CJDNS is a fast encrypted overlay that does not conceal endpoints in the same way. Verified configuration, independent peer count and limits on identity correlation matter more than the label.