Unreachable addresses in Bitcoin GETADDR responses

# · Daniela Brozzoni · #1 · 16 Jul 2026, 19:29 UTC

In the past few months we saw many unreachable addresses being gossipped on the p2p network (see this thread or this one). This refers to unsolicited ADDR messages, but I wondered if we could find some more information on what’s happening by looking at nodes’ GETADDR responses instead.

I am interested to see the percentage of unreachable addresses returned by each node in a GETADDR response. This could tell us two different things:

• how much the recent address flooding may have affected the addrman tables of otherwise well-behaved nodes.
• whether unreachable addresses are being spread only through unsolicited ADDR messages, or also through nodes’ responses to GETADDR.

(The latter is a bit harder to see… If you see a node responding only with unreachable addresses, maybe it’s trying to spam the network, or maybe it’s simply a victim of such spam!)

For now I have a lot of data and not many conclusions. I’ll be off for a few days, so I wanted to post what I have

First, disclaimer: I usually use virtu’s p2p-crawler to crawl the network, but it needs python 3.9 to run, and was missing some features I needed. I ended up having Claude Opus 4.8 and GPT-5.6 rewrite most of the crawler, and I have not fully reviewed the resulting code yet. Don’t trust this data too much, it might be completely off.

The crawl run took ~8 hours, starting at 19:13 UTC on 15/07/2026 and ending at 03:12 UTC on 16/07/2026. It seems that during that time the number of unique addresses in unsolicited ADDR messages dipped significantly.

For each address observed during the crawl, I recorded one of three outcomes:

• reachable: I connected and completed the Bitcoin handshake;
• unreachable: the address was valid, but I could not connect to it;
• handshake failed: I established a connection, but could not complete the Bitcoin handshake.

I reached 21,837 nodes:

I also found 671,825 unique unreachable addresses:

I also found 1,353 addresses where the connection succeeded but the handshake failed:

Putting everything together:

I recorded the ADDR messages received after sending GETADDR to each reachable peer, and calculated the percentage of unreachable addresses in each peer response.

For this analysis, I excluded peers that returned fewer than 10 addresses, so the filtered sample contains 19,859 peers.

Percentage of unreachable addresses per getaddr response:

Percentage of handshake-failed addresses per getaddr response:

This is… interesting. First of all, the majority of the spam is composed of addresses we can’t even reach, not addresses we can reach but can’t complete the handshake (I was expecting this, but wanted to double check).

And, more interestingly, the percentage of unreachable addresses in the nodes responses is alarmingly high! More than 70% of the peers in the filtered sample return >80% of unreachable addresses in their responses.

We can double check this by looking at some nodes addrmans. I looked at peer.observer’s nodes + two of my own nodes (fusillo and spaghetto^[1]), and calculated the % of unreachable addresses in the new/tried table.

It appears that the new tables are full of unreachable addresses. To try and put these numbers in perspective:

• it’s normal to have unreachable addresses in our addrman - nodes come and go all the time!
• To promote an address to the tried table, we must have successfully connected to it at least once. This means that fake addresses that have never corresponded to a reachable node cannot enter the tried table. Currently, roughly 30% to 50% of the addresses in the tried table are unreachable.

Meaning, 90% of unreachable in the new table is likely higher than usual, but not catastrophic.

(It would be great if we could have some historic data on this!)

Lastly, I wondered: can we get some additional information by looking at the node versions in each percentage bucket? Which versions seem more affected?

I have not looked too deeply into this yet, so I have not found many particularly interesting patterns. Here is a dump of the data I have. I included every user agent with at least 50 responses across buckets, and grouped every family that wasn’t Core or Knots into an Other category.

For each user agent, I am showing the number of responses, its share of the bucket, and how common it is overall, to see whether any version is overrepresented in a particular percentage bucket.

And that’s it! I would love it if someone tried to reproduce all of this - I’m not very confident in the data I found, and I’m sure a few bugs slipped in somewhere

1. Yes, I named my nodes after Italian pasta. I am very pleased with myself. ↩︎

# · Strakeljahn · #2 · 19 Jul 2026, 21:42 UTC

This might be some of the historic data you were asking about:

b10c archives daily getrawaddrman snapshots of the two demo.peer.observer nodes (hal and len) in bitcoin-data/getrawaddrman, going back to 2026-02-02 (gap: Feb 15 to Mar 3, hal until Mar 11).
I don’t have access to the production nodes from your table, so I worked with what’s public.

I replayed the git history and computed the metrics below from the snapshots alone. The snapshots contain no connection outcomes, so none of this is a reachability measurement.

addrman_freshness_vs_churn1800×1116 166 KB

Since the tables were already full in February, the flood shows up in composition, not size. The 7d timestamp share climbed from late April and crossed 95% in early May.

The same signal shows up in the getrawaddrman export deadmanoz shared on the BNOC datashare (four nodes, daily snapshots 2026-03-05 to 2026-06-10). The two VPS nodes follow the same curve: 71% baseline, above 97% by mid-May. The two home nodes, which are not reachable for inbound clearnet connections, started from a lower baseline (47-50%, they see less gossip overall) and peaked at 75%. So the flood clearly reached them through their outbound peers too, but with visibly less intensity than nodes accepting inbound. Those series end in May/June though.

What I find most interesting: turnover fell to a third of pre-flood levels and has stayed there after Jul 15. Of the new entries present on Jun 1, 81-83% are still there today. Of the Jul 14 set, 97.7% (hal only, len has no snapshots Jul 14-17). The flood population just sits there, so GETADDR pollution lags the injection I think.

addrman_cohort_survival1800×936 93.2 KB

If the injection really stopped around Jul 15, addrman’s 30-day horizon makes a testable prediction: these entries become “IsTerrible” as their timestamps age, and GETADDR responses filter terrible entries, so the pollution you measured should decline substantially by roughly mid-August. The slots themselves only get freed when a colliding address overwrites a terrible entry, a restart doesn’t purge them either, so the tables will look polluted much longer I guess. If GETADDR pollution does not recede on that timescale, something is still refreshing the timestamps.

As a separate present-day cross-check (not a join against the addrman data):
I’ve been archiving DNS seed responses and full seeds.txt crawler dumps since early July in bitcoin-seeder-data. In the Jul 19 dumps, 91% of fish.foo’s and 94% of achow101’s tracked endpoints have never completed a version handshake from their vantage points (both run dnsseedrs, which drops never-successful entries after >10 failed tries, so this is a rolling window, not a lifetime count).
But applying your unreachable-endpoint classification to the full Feb-Jul history would be much stronger than my seeder cross-check.
Hope this helps!

1. brief dips below 95% in late June; the deeper one (len, 80%) follows a snapshot gap and looks like node downtime. ↩︎

2. excluding two restart-like events (May 29, Jul 1) where both nodes lost and refilled 1-3k slots within days. ↩︎