Bitcoin over Reticulum
A sidecar that lets unmodified Bitcoin Core nodes peer with each other over Reticulum, a networking stack that uses public keys instead of IP addresses.
Problem. Bitcoin nodes leak information at the network layer. Peers see each node‘s IP address, listening nodes need an open port that crawlers can map, and spy nodes record which IP first announced a transaction. On-chain privacy tools don’t address any of this.
How it works. The sidecar is one Python program with two modes. On the node being reached, serve registers a Reticulum destination and forwards each incoming link to Bitcoin Core on localhost. On the connecting node, connect listens on a local port, and each TCP connection from Bitcoin Core becomes a Reticulum link. Bitcoin Core is not modified: its configuration only binds to, or connects to, 127.0.0.1, so the sidecar is the only path in or out.
Reticulum addresses are hashes of public keys, packets carry no sender address, and links are encrypted with forward secrecy. Each machine runs its own Reticulum transport node. Links can run over TCP, Wi-Fi, HaLow, LoRa or serial, mixed in one network, without changes to the sidecar.
What was tested. Two regtest nodes on separate machines, connected only through a Reticulum transport node running on a phone, with all links over TCP. Blocks and transactions relay between the nodes, each node‘s only peer is localhost, and syncing stops when the transport node stops and resumes when it restarts.
Limits. Over the internet, Tor provides stronger anonymity: a node’s TCP neighbor learns its IP address, and routers see destination hashes. Radio transmitters can be located physically. LoRa can carry transactions and block headers, but not full blocks. Peers are currently configured by destination hash rather than discovered automatically.
Next steps. Peer discovery from Reticulum announces, a single-packet anonymous transaction broadcast, and testing over real radio links.