If #26847 gets merged, addrman will maintain counts of addresses stored on the new & tried tables, broken down by network. This is useful information for monitoring the state of our addrman when we run it with different network configs on mainnet.
Currently when running a node, we can get a rough estimate into this information using the cli argument -addrinfo. However, this is just an estimate because it uses the RPC endpoint getnodeaddresses, which calls through to Addrman::GetAddr. Although this logic path skips the addr caching logic we apply for results propagated to the p2p network, it still applies some logic to filter results. For example it removes addresses that meet the IsTerrible attributes. It also doesn’t distinguish between the new and tried tables.
So, I recommend we expose the raw counts to provide a better picture of addrman’s workings, especially since addrman & network integrations are particularly hard to test via our automated tooling. We can breakdown the counts by network & new vs tried.
There are a few different options for how we can expose this information. I expect this feature to primarily be used by bitcoin core contributors or super-users that understand bitcoind’s inner workings. Thus, I suggest we expose it as a new, hidden RPC. That enables exposing the information to devs without having to guarantee a stable RPC interface over future versions. The name of the RPC can be something generic like addrmaninfo, to allow for future extensions for other debugging information.
For more historic context around bitcoin cli’s -addrinfo and conversation about cli vs RPC, see #21595. If we do end up implementing a new RPC endpoint, we could consider reworking the cli to use these values directly rather than trying to compute them with partial information.
