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.
| 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 |
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.
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!