Bitcoin Core getaddednodeinfo RPC: Manual Peer Audit Guide

This guide explains Bitcoin Core getaddednodeinfo RPC in plain English. It shows what the command does, what its result means and what it cannot prove.

Optional node filter

Without an argument the call returns every added node; with a node string it targets the supplied entry. Match the exact representation originally passed to addnode, including hostname or port. Normalising too early can merge distinct configured names or miss a retained entry whose DNS now resolves differently.

Onetry exclusion

One-off connection attempts are explicitly absent from this list. An empty result therefore does not prove no manual connection was attempted or remains active. Correlate getpeerinfo, logs and the incident timeline when investigating an onetry peer, and avoid using this RPC alone as an exhaustive connectivity inventory.

Connected flag

connected indicates whether the added entry currently has a connection. It does not prove handshake quality, service suitability, recent block relay or chainwork agreement. Alert separately on management intent and operational usefulness so a persistently connected but stale peer is not reported healthy.

Resolved addresses and direction

When connected, addresses shows the actual server endpoint and inbound or outbound direction. Compare hostname resolution with approved expectations and detect address changes or unexpected inbound state. Keep private topology out of broadly accessible dashboards and retain only the evidence required for network operations.

Added peer protections

Peers added manually can receive protection from some ordinary disconnection logic and may have different service requirements. Review why each entry exists, its expiry or owner and its diversity contribution. Stale manual peers should be removed through a controlled addnode action, not tolerated because the connection flag is true.

Topology audit

Combine added-node data with peer protocol version, services, ping, bytes, last block, network, ASN and chainwork evidence. Ensure mining nodes retain multiple independent outbound paths. A manual list concentrated under one operator or network can increase eclipse risk even when every endpoint is reachable.

How specialists test it

Operators test the command on a non-production node first. They check a normal reply, an invalid request, a timeout and a restart. This shows what the response means and prevents one local result from being mistaken for a network-wide outcome.

Conclusion

getaddednodeinfo is a manual-peer inventory, not a peer-health verdict. Reliable monitoring combines its configured and connected state with resolved endpoints, negotiated services and independent chain-quality evidence.