# Addrman age distribution
**URL:** https://bnoc.xyz/t/addrman-age-distribution/130
**Category:** Observations
**Tags:** addrman
**Created:** [May 20, 2026, 5:14pm UTC](https://bnoc.xyz/t/addrman-age-distribution/130 "2026-05-20T17:14:55Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@stratospher](https://bnoc.xyz/u/stratospher)
#### Post date: [May 20, 2026, 5:14pm UTC](https://bnoc.xyz/t/addrman-age-distribution/130/1 "2026-05-20T17:14:55Z")
was curious about the age distribution of different addresses in the addrman new and tried tables of different peers in [peer.observer](https://peer.observer/)
\*image plotted by claude
kane is the tor/i2p only node. kane’s plot is interesting - all nodes except kane have fresher new table (more recent timestamps) and staler/older tried table. ~~so maybe kane hasn’t been receiving fresh ADDR gossip but is still actively connecting to peers which keeps tried table fresh?~~
also compared alice’s current addrman with a few older snapshots I had (last week, nov 2025, aug and sep 2024). it’s interesting that the older snapshots had lots more 2 week - 1 month old addresses in the new table compared to the recent snapshots.
I did cross-check claude’s script that it was computing the buckets (\<1h, 1-6h, 6-24h, .. etc..) correctly from each snapshot’s own reference time - basically the newest entry in the addrman is chosen as the reference.
\*this also plotted by claude
---
### Author:  [@stratospher](https://bnoc.xyz/u/stratospher)
#### Post date: [May 21, 2026, 4:31am UTC](https://bnoc.xyz/t/addrman-age-distribution/130/2 "2026-05-21T04:31:11Z")
> [@stratospher](#):
>
> so maybe kane hasn’t been receiving fresh ADDR gossip but is still actively connecting to peers which keeps tried table fresh?
sorry, this was incorrect. it’s expected behaviour in tor/i2p-only node’s addrman that tor addresses can at max occupy 1/4th new table and i2p addresses another 1/4th. so that’s why we’re seeing only 1/2 the new table being fresh.
if we do the netgroup calculation - tor/i2p addresses have only 16 possible netgroups and only 256 buckets possible in new table (256/1024 = 1/4 new table occupied). see [this writeup](https://github.com/stratospher/blogosphere/blob/main/netgroups.md#bucketing-algorithm-in-addrman) in case anyone’s interested.
---
### Author:  [@b10c](https://bnoc.xyz/u/b10c)
#### Post date: [May 21, 2026, 9:46am UTC](https://bnoc.xyz/t/addrman-age-distribution/130/3 "2026-05-21T09:46:40Z")
> [@stratospher](#):
>
> also compared alice’s current addrman with a few older snapshots I had (last week, nov 2025, aug and sep 2024). it’s interesting that the older snapshots had lots more 2 week - 1 month old addresses in the new table compared to the recent snapshots.
I think this might be related to the current address flooding happening on the network.
> [@/python-bitcoinlib:0.12.2/ client getting addr-ratelimited (since 2026-04-10)](https://bnoc.xyz/t/python-bitcoinlib-0-12-2-client-getting-addr-ratelimited-since-2026-04-10/116):
>
> Since 2026-04-10 at about 16:30 UTC I’ve seen multiple IPv4 addresses connect to my monitoring nodes gossiping addresses via addr (and not addrv2) at a higher rate. These addresses are frequently rate-limited. IPs are: [130.60.24.200](https://ipinfo.io/130.60.24.200) (uzh.ch - University of Zurich) [3.102.33.26](https://ipinfo.io/3.102.33.26) (AWS New Zealand) [3.98.91.234](https://ipinfo.io/3.98.91.234) (AWS Canada) [51.20.80.202](https://ipinfo.io/51.20.80.202) (AWS Sweden) … My node erin is receiving about 40 addresses per minute now. Looking at the addrman of erin, the seems to be only the normal ba…
My observation there was:
> [@/python-bitcoinlib:0.12.2/ client getting addr-ratelimited (since 2026-04-10)](https://bnoc.xyz/t/python-bitcoinlib-0-12-2-client-getting-addr-ratelimited-since-2026-04-10/116/3):
>
> At 2026-04-13T13:47:00Z I received a `addr` message with exactly 10 entries. All timestamps were recent (not older than 10min). The IPs seemed reasonable from locations where real nodes could be hosted / run from, the ports were mostly 8333, and the services seemed to be reasonable ones too.
This is likely updating the timestamps in our tables.