Total nodes Loading
bitnodesBitnodes estimates the relative size of the Bitcoin peer-to-peer network by finding all of its reachable nodes.
This page reports network health data for reachable ASNs, which are ASNs that have at least one reachable IPv4/IPv6 Bitcoin node. Data points are collected whenever a new network snapshot is available, which occurs approximately every 10 minutes. BGP alerts are promptly displayed within 10 seconds of detection and will be automatically cleared after 1 hour if they are not persistent.
Each autonomous system (AS) is associated with a unique autonomous system number (ASN) and consists of a group of IP prefixes that fall under the control of a single administrative entity, such as an Internet Service Provider (ISP). ASNs are crucial for determining the most efficient routes for network traffic using Border Gateway Protocol (BGP), which enables the Internet to operate as a global, interconnected network.
A diverse range of ASNs is essential for the Bitcoin peer-to-peer network to maintain its decentralized nature, a key characteristic that sets it apart from traditional financial systems. This diversity also enhances the network's resiliency against potential threats, making it more difficult for bad actors to disrupt the network by targeting a single point of weakness.
Page is updated automatically on new snapshot. Time since last snapshot: 0s
NODES | COUNTRY | ||
---|---|---|---|
UPTIME 50% | LATENCY 50% | ||
FULL NODES | PRUNED NODES | ||
IPV4 NODES | IPV6 NODES | ||
IPV4 ROA % | IPV6 ROA % |
AS25668 ADJACENT PEERS | WII (AS32097), HURRICANE (AS6939) |
---|
Reachable ASN | ASN that contains at least 1 reachable Bitcoin node. |
---|---|
Latency 50% | 50th percentile (median) ping message round-trip time in milliseconds. |
Uptime 50% | 50th percentile (median) uptime in hours from persistent connections. |
Block 50% | 50th percentile (median) latest block inv propagation time in milliseconds. |
Height 50% | 50th percentile (median) block height delta from consensus height. |
IPv4 ROA % | Percentage of IPv4 nodes covered by ROA (Route Origin Authorization) IPv4 prefixes for the ASN. |
IPv6 ROA % | Percentage of IPv6 nodes covered by ROA (Route Origin Authorization) IPv6 prefixes for the ASN. |
Adjacent peers | Adjacent peering ASNs that contain at least 1 reachable Bitcoin node. |
BGP alert | This ASN is originating an IP prefix owned by another ASN during the past hour. |
BGP alert | Another ASN is originating an IP prefix owned by this ASN during the past hour. |
One threat to the Bitcoin peer-to-peer network's security that is often overlooked is Border Gateway Protocol (BGP) hijacking. In a BGP hijacking attack, an attacker manipulates BGP routes to redirect traffic intended for a Bitcoin node to a malicious node under the attacker's control. This can lead to the interception and manipulation of Bitcoin block or transaction messages, potentially resulting in financial losses. Adding to this risk, Bitcoin traffic is unencrypted by default, making it susceptible to interception and manipulation by attackers who gain access to the network traffic.
BGP hijacking attacks can occur anywhere along the path between a Bitcoin node and its peers, so it is important for Bitcoin node operators to be able to monitor for any suspicious routing changes, both within their own autonomous system (AS) and in the ASes of their peers.
A BGP hijack in the operator's own AS1 (Fig. 1) could redirect traffic away from the legitimate Bitcoin node ₿1 while a hijack in the destination AS2 (Fig. 2) could redirect traffic intended for the Bitcoin node ₿2 to a malicious node under the attacker's control.
To mitigate the risk of BGP hijacking attacks, it is important to have monitoring tools in place that can detect and alert network operators to any unusual routing changes. However, existing monitoring tools may not be suitable for Bitcoin node operators as they are primarily designed for general network operations. Hence, a specialized monitoring tool, such as Bitnodes BGP alert, is necessary in surfacing possible BGP hijacking attacks affecting the Bitcoin network.
Bitnodes uses rpki-client to periodically (hourly) fetch the latest Route Origin Authorizations (ROAs) from each of the five Regional Internet Registries (RIRs), i.e. AFRINIC, APNIC, ARIN, LACNIC, RIPE, and consolidate them into a single JSON file:
{ "metadata": {.., "buildtime": "2023-01-01T00:00:00Z", ..}, "roas": [ {"asn": "AS14061", "prefix": "134.209.0.0/16", "maxLength": 24}, .. ] }
All IP prefixes from the JSON file are stored in a database and treated as Validated ROA Payload (VRP) for up to 24 hours. Bitnodes uses RIPE Routing Information Service Live (RIS Live) to receive live BGP announcement messages. For each announcement message:
{ 'peer': '27.111.230.35', 'peer_asn': '133210', 'path': [133210, 9498, 14061], 'announcements': [{'next_hop': '27.111.228.40', 'prefixes': ['134.209.144.0/20']}], .. }
Bitnodes queries its VRP database to validate each of the prefixes in the message:
Query output | Outcome |
---|---|
Prefix in the message matches a VRP record. The match can be equal or prefix being more specific with its prefix length no greater than the matching VRP's max. length. | VALID |
Origin AS in the message did not match the matching VRP record or prefix in the message is more specific than the matching VRP's max. length. | INVALID |
No matching VRPs. | UNKNOWN |
If the validation outcome is marked as INVALID, the reachable ASN on the origin AS end will trigger an alert labeled as BGP alert, and the reachable ASN on the VRP's AS end will trigger an alert labeled as BGP alert, for a duration of up to one hour from the time of the last INVALID validation. It is important to note that the presence of these alerts should not automatically be interpreted as indicative of a BGP hijack. They could potentially result from temporary misconfigurations or other benign causes. Additional analysis is almost always warranted, including but not limited to monitoring for anomalous changes in ping latency, block propagation time, or an increase in block height delta from consensus height.
Be part of the Bitcoin network by running a Bitcoin full node, e.g. Bitcoin Core.
Use this tool to check if your Bitcoin client is currently accepting incoming connections from other nodes. Port must be between 1024 and 65535.