Index
Addrman health can be thought of as a combination of 3 aspects of all addresses inside addrman: reachability health + eclipse resistance health + the ability to evict addresses from addrman without unfairly evicting, or mass evicting, addresses that could still become useful.
1. Reachability health
The more reachable addresses we hold, the more of our connection attempts succeed. The more unreachable ones we hold, the fewer — attempts get spent on addresses that will never answer. The two checks below ask that from both sides: our own connection history, and a third party's view of the same addresses.
| Successful connections > Attempted but failed connections | If this is true, yay! Our addrman has much more reachable addresses | |
| Reachability of our addrman IP addresses according to 3rd party bitnod.es snapshot | > 30% reachable means we hopefully have much more reachable IPs. bitnod.es doesn't have I2P/CJDNS data btw — so ignored. |
2. Eclipse resistance health
No single entity should dominate who we end up connecting to. An eclipse attack doesn't need to break anything — if enough of the addresses we hold belong to one party, every connection we make lands back on them. The checks below look for one party holding too large a share of our addresses (addrman counts everything in the same /16 as one party).
| There aren't many IPs with multiple ports (>5 ports) | <50 such IPs - then it's a good thing. Otherwise, these IPs would have taken nice good slots in the addrman + would be hard to evict if they are kept on being refreshed | |
Not many addresses with nRefCount > 1 |
Not normal addrman trend in clearnet | |
| There aren't netgroups which we attempt to connect much more often than others | over-dialled + over-connected netgroup | |
| There is no 1 source netgroup influencing a large number of the addresses we end up picking and connecting to | Largest source netgroup in tried |
3. Ability to evict addresses from addrman — without over-evicting
Addrman is a fixed size, so nothing new gets in unless something old goes
out — only if we evict stale IP addresses can we insert newer ones. Eviction
(IsTerrible) cuts both ways: too little and the tables silt up with stale
gossip and nothing new gets in, too much and we throw away peers that were merely offline
for a while — and an attacker who can push our own addresses over the
IsTerrible line gets us to clear the way for theirs. Ideally what we want here
should be a steady trickle and not a flood. The checks below look at how much of addrman is
evictable right now, and how fresh the addresses are overall.
| isTerrible | >10% is unusual in current addrman. Something is happening in the P2P network (ex: addr spam attack stopped and many addresses getting stale) | |
| Median age | Too fresh (<3 days) isn't good - it's the quality of gossip being tampered by someone in the P2P network. If it's too old - node is probably offline/not participating in address relay. |
1. General stats
1.1 Age distribution
1.2 Network distribution
1.3 new table nRefCount distribution
in new table an address:port can occupy upto 8 slots. usually on clearnet nodes nRefCount can reach 2 for a few ip addresses. anything more is an unusual trend.
1.4 Service flag distribution
1.5 Tor exit IPs
for testing #35578 — a node behind a SOCKS5 proxy might self advertise the tor exit's IP, so exits land in addrman as fresh entries gossiped from many sources.
2. Reachability stats
2.1 our connection attempts
Connection history
Attempted is every entry with evidence of a dial: a recorded success, a recorded failure, or both. Successful and unsuccessful partition it.
Share of each table by nAttempts
ADDRMAN_RETRIES and ADDRMAN_MAX_FAILURES.Share of each table by time since last success
2.2 Reachability according to bitnod.es
No reachable-node data alongside this page. Run
./refresh-reachable.sh in this directory and reload — it writes
reachable-data.js, which loads automatically from then on.
The page cannot download it itself: the host sends no
Access-Control-Allow-Origin, so a browser blocks the request.
Ports are not part of the join: the bitnod.es export lists exactly one port per address, so it cannot corroborate a second one.