This guide explains Bitcoin Core getnetworkinfo RPC in plain English. It shows what the command does, what its result means and what it cannot prove.
TL;DR
- What it is: Bitcoin Core 0.16.0 getnetworkinfo returned a broad view of P2P configuration and state: software and protocol versions, local service flags, transaction-relay preference, time offset, connection count, network-active state, IPv4, IPv6 and onion reachability and proxies, relay and replacement fee floors, advertised local addresses and warnings. Some fields exposed sensitive topology.
- Why it matters: getnetworkinfo is the central P2P-state summary, but safe interpretation depends on role, policy, privacy and chain context. Restrict the response and verify service outcomes rather than trusting one healthy-looking field.
- Current position: Bitcoin Core 0.16.0 getnetworkinfo returned a broad view of P2P configuration and state: software and protocol versions, local service flags, transaction-relay preference, time offset, connection count, network-active state, IPv4, IPv6 and onion reachability and proxies, relay and replacement fee floors, advertised local addresses and warnings.
Bitcoin Core getnetworkinfo RPC in simple English
Bitcoin Core getnetworkinfo RPC: Each IPv4, IPv6 or onion entry reports limited, reachable, proxy and credential-randomisation state. Empty proxy values and reachability have precise local meanings.
Simple example
A node operator is checking Bitcoin Core getnetworkinfo RPC. Combine with peer details, best-tip age, headers and warnings before gating mining or financial services.
Key terms in plain English
- BIP:
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- Bitcoin Core:
- Widely used software that validates Bitcoin and can provide wallet, network and operator tools.
- RPC:
- A command that software sends to a node to request information or a local action.
- Mempool:
- A node’s changing local collection of valid, unconfirmed transactions.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
Version and protocol
version and subversion identify the software while protocolversion describes P2P negotiation capability. Inventory exact builds and avoid treating a familiar subversion string as cryptographic attestation. Verify binaries and supported upgrade paths separately.
Services and relay
localservices encodes offered capabilities and localrelay shows whether transaction relay was requested from peers. Decode bit flags with version-appropriate definitions. A false relay preference may be intentional for block-only roles and should not be called a generic outage.
Connections and activity
connections counts peers while networkactive indicates whether P2P networking is enabled. A non-zero count does not prove useful relay or chain freshness. Combine with peer details, best-tip age, headers and warnings before gating mining or financial services.
Networks and proxies
Each IPv4, IPv6 or onion entry reports limited, reachable, proxy and credential-randomisation state. Empty proxy values and reachability have precise local meanings. Protect this output because it can reveal routing choices and privacy boundaries.
Fees and policy
relayfee is the local minimum relay fee and incrementalfee is the minimum increment used for mempool limiting or BIP 125 replacement, historically in BTC/kB. These are policy parameters, not universal network prices. Pin units and compare effective configuration.
Addresses, time and warnings
localaddresses contains advertised addresses, ports and relative scores; timeoffset reports network-adjusted offset; warnings carries operational alerts. Redact addresses from ordinary logs, monitor material clock deviation and route warnings to humans rather than dropping them.
Scenario matrix
Test networking enabled and disabled, direct and proxy routes, limited networks, relay on and off, wrong fee configuration and warning states. Confirm secrets are absent from reports and that monitoring distinguishes privacy-preserving intentional limits from accidental loss of connectivity. Build a revision-pinned evidence pack on an isolated node, wallet or protocol harness.
Frequently asked questions
What is the main point of Bitcoin Core getnetworkinfo RPC?
Bitcoin Core getnetworkinfo RPC: Each IPv4, IPv6 or onion entry reports limited, reachable, proxy and credential-randomisation state.
For Bitcoin Core getnetworkinfo RPC, what should a beginner know about version and protocol?
version and subversion identify the software while protocolversion describes P2P negotiation capability.
For Bitcoin Core getnetworkinfo RPC, what should a beginner know about services and relay?
localservices encodes offered capabilities and localrelay shows whether transaction relay was requested from peers.
For Bitcoin Core getnetworkinfo RPC, what should a beginner know about connections and activity?
connections counts peers while networkactive indicates whether P2P networking is enabled. A non-zero count does not prove useful relay or chain freshness.
Conclusion
getnetworkinfo is the central P2P-state summary, but safe interpretation depends on role, policy, privacy and chain context. Restrict the response and verify service outcomes rather than trusting one healthy-looking field.
Primary sources
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.