# Unreachable addresses in Bitcoin GETADDR responses **URL:** https://bnoc.xyz/t/unreachable-addresses-in-bitcoin-getaddr-responses/155 **Category:** Observations **Tags:** addrman, p2p **Created:** [July 16, 2026, 7:29pm UTC](https://bnoc.xyz/t/unreachable-addresses-in-bitcoin-getaddr-responses/155 "2026-07-16T19:29:31Z") **Posts on this page:** 1 **Showing post:** 2
### Author: ![jorisstrakeljahn](https://bnoc.xyz/user_avatar/bnoc.xyz/jorisstrakeljahn/32/275_2.png) [@jorisstrakeljahn](https://bnoc.xyz/u/jorisstrakeljahn) #### Post date: [July 19, 2026, 9:42pm UTC](https://bnoc.xyz/t/unreachable-addresses-in-bitcoin-getaddr-responses/155/2 "2026-07-19T21:42:32Z")
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](https://github.com/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. | new table (hal/len) | pre-flood (Feb to early Apr) | during flood (May to mid-Jul) | after the Jul 15 drop | | --- | --- | --- | --- | | size | 65.3-65.5k, already full | 65.5k, full | 65.5k, full | | entries with gossip timestamp 7d | 71-76% | mostly 95-97%\[1\] | falling, 72-78% on Jul 19 | | daily endpoint turnover | 1-1.5%/day | 0.3-0.5%/day\[2\] | 0.4-0.5%/day | ![addrman_freshness_vs_churn](https://bnoc.xyz/uploads/default/original/1X/a6e04d3ad0fcbaac328dc29ecfe2d3414c20e169.png) 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](https://drive.google.com/drive/folders/1-Ot7Whi1L1ElBNvvRkoUxOyZd4NdIEvs) (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_survival](https://bnoc.xyz/uploads/default/original/1X/8db08bf6440fe789a9900e9cad088b24ec1bb471.png) 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](https://github.com/jorisstrakeljahn/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. --- _[View the full topic](https://bnoc.xyz/t/unreachable-addresses-in-bitcoin-getaddr-responses/155)._