Half of Bitcoin's reachable nodes are on Tor: why do they hide their addresses?

Satoshi Nakamoto wrote to Nicholas Bohm, a British lawyer whose node had stopped connecting after he installed a new router:

You should set your router to forward port 8333 so you can receive incoming connections. If you’re not set up to receive incoming connections and nobody else who’s online is, then you can’t connect. It would also help solve the “(not accepted)” issues.

Seventeen years later, on October 3, 2026, at 03:41 UTC, a crawler that walks the network from node to node found 25,501 Bitcoin addresses it could connect to. 12,524 of them ended in .onion. Half of the network that accepts incoming connections now answers at an address that names no country, no provider, and no house, and that works without any port opened on a router. Two things about that number are not obvious from the number: what exactly it counts, and why so many node operators keep their IP address out of it.

1. What the 12,524 counts

The snapshot breaks the 25,501 addresses down by network:

Each row of the snapshot is an address, not a machine. A node that accepts connections over both an IPv4 address and an onion address is listed twice, once under each. Exposing one node over several networks appears in Bitcoin Core’s own documentation, as a warning: an operator who needs the identities to stay unlinkable should not do it. The snapshot has no way to say how many computers stand behind the 25,501 rows.

The count also leaves out every node that accepts no incoming connections at all. The crawler finds nodes by asking reachable nodes for their address lists and connecting to what it is told; a node that only dials out is never on the list. That is the setup Satoshi described from his own side in January 2009, when he told Hal Finney he could not receive incoming connections “from where I am”. It is also, today, the default of at least one home-node product (§3).

The counter itself changed hands this year. The address bitnodes.io, home of the Bitnodes crawler whose figures the press has quoted for years, now forwards to btcnodes.io, which runs a fork of the Bitnodes code created in May 2026. And the Tor row is the one most exposed to the counting itself. In July 2024 the Tor figure on bitnodes.io fell by about 10,000 over ninety days while the node counts of Luke Dashjr and 21 Ninja showed no such drop; Murch, answering on Stacker News, read it as the crawler’s way of tracking onion nodes having “hit a snag.”

2. From one proxy line to half the network

The Tor side of Bitcoin starts with a single line. In the December 2009 release notes for Bitcoin 0.2, among Satoshi’s own contributions: “Proxy support for use with TOR.” That let a node reach the network through Tor. It did not give the node an onion address of its own, and a month later, in the thread “TOR and I2P”, Satoshi explained why onion addresses were rare:

There aren’t many .onion addresses in use for anything because the user has to go through a number of steps to create one. Configure TOR to generate a .onion address, restart TOR, configure it with the generated address. Perhaps this is intentional to keep TOR so it can’t be integrated into file sharing programs in any sufficiently automated way.

Those steps were automated in February 2016. Bitcoin Core 0.12.0 began using Tor’s control port to create an onion service by itself whenever Tor was running and the node was listening, “without manual configuration.” Four years later the count was still small:

The counts behind that timeline come from different hands and are not one series. Each is a separate point:

The jump of January 2020, from about two hundred onion nodes to about two thousand in two weeks, has no recorded cause. Bitcoinist, reporting it at the time, wrote that “it remains unknown why.” The same article noted that the onion count had tripled for about two weeks in mid-2019 before falling back. Whatever happened in January 2020 did not fall back.

3. Why hide the address

Three different reasons sit inside the onion half, and the record shows each of them separately.

An IP address ties a node to its transactions. In May 2014, Alex Biryukov, Dmitry Khovratovich, and Ivan Pustogarov published a method that links Bitcoin users’ pseudonyms to the IP addresses their transactions come from, including users behind home routers. Satoshi had already pointed his users toward Tor, in the email in which he took the word “anonymous” off the bitcoin.org homepage and added Tor instructions in its place:

Also, anonymous sounds a bit shady. I think the people who want anonymous will still figure it out without us trumpeting it.

A listening node publishes where it is. The crawler’s public node list, which anyone can query without an account, gives each IPv4 node a hostname, a city, a country, a latitude and longitude, and the name of its network provider. For a node in a data center, that entry names the data center. For a node in a living room, it names the internet provider and the town. An onion entry gives none of these; its provider field reads “Tor network.”

An onion address needs no open port. This is the problem Bohm had in 2009. Tor’s own documentation describes onion services as needing no open ports, because “they punch through NAT” and “only establish outgoing connections.” A node behind a home router that the owner never opens can still accept connections, as long as it accepts them through Tor. Home-node products built this into their defaults. Umbrel’s first configurations, from August 2020, bound Bitcoin Core to an internal address, sent its outgoing connections through Tor, and published its P2P port only as an onion service: such a node could be reached through Tor and through nothing else. Umbrel’s current Bitcoin app, rebuilt in 2025, goes further and accepts no incoming connections by default, which keeps a new Umbrel node out of the count altogether.

The record does not say how many of the 12,524 come from each reason, or from any one product. Why anyone runs a node in the first place, for no reward, is traced in who runs Bitcoin’s nodes, and why.

4. What hiding costs

Tor solves the port and the address and introduces dependencies of its own. In October 2014 Biryukov and Pustogarov followed their first paper with “Bitcoin over Tor isn’t a good idea,” showing that a low-resource attacker can gain control over the information flow between users who choose Bitcoin over Tor. BIP 324 cites that paper when it explains why nodes connected only through Tor are cheaper to eclipse. Bitcoin Core’s Tor documentation adds that a node listening on Tor still listens on its other interfaces, and that someone who knows the node’s address can connect to it over the clear net.

The dependency showed in January 2021. A bug in Tor’s v3 onion services took them down for a few hours on January 9 and again on January 10, and the onion nodes counted by Bitnodes fell to 122 before recovering to 2,581 by January 13. For those hours, a node reachable only through Tor was not reachable.

In 2009 Satoshi told Bohm to open a port, and in 2010 he listed the three chores that kept onion addresses rare. Both are now done by software on the owner’s behalf, so the 12,524 is the size of a default: the number of addresses whose owners never had to touch the router Bohm had to open, and whose location stays off a public list as a side effect. It is not a count of 12,524 people hiding from someone. What the count cannot tell me is how many machines stand behind those addresses, or whose they are.