I also came across these hosts while investigating a discontinuity in the AS-level concentration metrics on the ASmap dashboard.
After bitnodes.io went offline, I changed the data source for the dashboard to bitnod.es. The first bitnod.es snapshot used by the dashboard is from May 22. At that point, the combined share of the five largest ASes jumps, and AS63949 (Linode) becomes the largest AS by observed clearnet host count.
The difference is also visible in the underlying snapshots, including the btcnodes snapshot:
| Source |
Snapshot |
Clearnet hosts |
AS63949 hosts |
Share of population |
| historical bitnodes.io |
2026-04-23 |
8,515 |
18 |
0.2% |
| bitnod.es |
2026-05-22 |
9,599 |
1,029 |
10.7% |
| btcnodes |
2026-05-22 |
9,371 |
1,027 |
11.0% |
As Crypt-iQ noted above, these hosts have been visible since at least February 2025. Since bitnod.es and btcnodes both contain roughly the same population, I did not understand why the historical bitnodes.io exports contained almost none of them. I therefore checked the public crawler code, but that raised another question for me.
In the public ayeowch/bitnodes ping.py, the first keepalive ping is sent no earlier than 60 seconds after the connection is established:
self.ping_delay = 60
self.min_ping_delay = 60
self.max_ping_delay = 600
But in my probes, these AS63949 hosts disconnected after about 30 seconds of idle time, matching what b10c noted above. Since the public export is built from opendata, which contains currently open connections, this offers a straightforward explanation for why the historical bitnodes.io exports usually missed them.
What I do not understand is why btcnodes still contains these hosts even though its public ping.py and default ping configuration match the original ayeowch code (brunneis/btcnodes fork). bitnod.es states that it also uses the same crawler, but I cannot find its production code, so I cannot make the same comparison. My best guess is that the worker-pool state, reconnect cadence, production deployment, or export process differs from the historical bitnodes.io deployment. These are only guesses, though. Does anyone have a better explanation?
For the dashboard, I decided to exclude hosts matching this signature from the operator-concentration metrics because counting them as ordinary Bitcoin nodes would distort those metrics.
I would be interested in how others in this thread would handle these hosts in network-wide node counts or concentration metrics, and whether anyone can explain the difference between the historical bitnodes.io exports and the newer datasets.
