Bitcoin Monitoring

The following charts on the Bitcoin Peer-to-Peer Network are based on measurements conducted for research purposes. Our methodology is described in a technical report. Our monitor nodes are located in Germany, results may differ for other locations. This site shows plots about: If you have comments, questions, or suggestions please contact us.

Nodes

Connection Count

Change plot range: [day] [week] [month] [quarter] [year] [all]
Raw Data Download: [raw data (0)] [raw data (1)]

Description: We operate three monitor peers that try to establish connections to all reachable peers of the Bitcoin P2P network. Two monitors are located in the network of KIT, a third monitor is located in Berlin. The total number of connections includes all connections to IPv4 and IPv6 addresses. The number of sybil connections is simply the difference between the total number of connections and the number of unique IP addresses we are connected to. As peers may be dual stacked (i.e., reachable via IPv4 and IPv6), the total number of unique reachable peers is most likely lower than what the plot suggests. The total size of the Bitcoin network, however, also includes non-reachable peers and is therefore much bigger.


Distribution of Connection Durations

Change plot range: [day] [week] [month] [quarter] [year] [all]
Raw Data Download: [raw data (0)] [raw data (1)]

Description: This plot shows the share of peers connected to our monitor nodes for at least a certain amount of time. E.g., more than 90% of peers are connected for at least one hour. Again, we do not know how long other peers remain in the network, only how long they are connected to our peers.


Churn

Change plot range: [day] [week] [month] [quarter] [year] [all]
Raw Data Download: [raw data (0)] [raw data (1)]

Description: Here, churn means how many connections are established or closed per hour to each of our monitor nodes. We do not know how many peers actually join or leave the network. Peaks in this plot are most likely caused by an interruption of our internet connection.


IPv6 Tunnel

Change plot range: [month] [year] [all]

Description: Analysis of incoming IPv6 connections showing the use of IPv6 tunnel mechanisms (6to4 and Teredo). These tunnel mechanisms are used by peers that connect from an IPv4 address to our IPv6 address. While these mechanisms were used in the first years of the monitoring, today almost all incoming IPv6 connections are native IPv6 connections.


User Agents

Version Strings

Change plot range: [month] [year] [all]

Description: Announced Version strings.


Version ID

Change plot range: [month] [year] [all]

Description: Announced VersionIDs.


Services

Change plot range: [month] [year] [all]

Description: Announced Services.


Whois

Country

Change plot range: [week] [month] [year] [all]

Description: Number of peers per country.


AS Description

Change plot range: [week] [month] [year] [all]

Description: AS Description.


Observed Addresses

Unique Addresses per Day

Change plot range: [week] [month] [quarter] [year] [all]

Description: Number of unique addresses observed in unsolicted ADDR messages per day. The number of unreachable addresses is an estimate of the number of unreachable peers in the Bitcoin P2P network (see Research).


Propagation of Transactions and Blocks

INV per Hour

Change plot range: [week] [month] [year] [all]
Raw Data Download: [raw data (0)]

Description: This plot shows the total number of INV messages received per hour. No blockchain information is used here (i.e., it does not matter whether a transaction is included in a block or not).


Current Block Propagation Delay Distribution

Raw Data Download: [raw data (0)]

Description: The elapsed time between the first reception of an INV message announcing a new block and the subsequent receptions from other peers is shown here. This plot does not show when network peers receive blocks, only when they announce new blocks to our monitor peers. Blocks that were relayed by fewer than 50 % of the peers are ignored.


Block Propagation Delay History

Change plot range: [month] [year] [all]
Raw Data Download: [raw data (0)]

Description: Based on above data we calculated the time it takes until 50% (90% resp.) of network peers announce a specific block.


Current Transaction Propagation Delay Distribution

Raw Data Download: [raw data (0)]

Description: The elapsed time between the first reception of an INV message announcing a new transaction and the subsequent receptions from other peers is shown here. This plot does not show when network peers receive transactions, only when they announce new transactions to our monitor peers. Transactions that were relayed by fewer than 50 % of the peers are ignored.


Transaction Propagation Delay History

Change plot range: [month] [year] [all]
Raw Data Download: [raw data (0)]

Description: Based on above data we calculated the time it takes until 50% (90% resp.) of network peers announce a specific transaction.


Latency

Current Latency Distribution

Raw Data Download: [raw data (0)] [raw data (1)]

Description: CDF of the current measured latency using ICMP/TYP SYN Pings and Bitcoin Pings.


Latency History

Change plot range: [month] [year] [all]
Raw Data Download: [raw data (0)] [raw data (1)]

Description: Median Latency over time using ICMP/TYP SYN Pings and Bitcoin Pings.


Activity on the Bitcoin Network

Announcements per Peer

Raw Data Download: [raw data (0)]

Description: A considerable number of peers on the Bitcoin P2P network do not relay transactions or blocks to our monitor peer. This plot shows for each peer (x-axis) the number of announced hashes per hour.


Announcements per Hash

Raw Data Download: [raw data (0)]

Description: This plot shows for each hash (x-axis) the number of announced peers that announced that hash per hour.


Host Heatmap



Other Bitcoin Monitoring Sites

P2P Network

Bitnodes
Bitcoin Stats

Other (Mining, etc.)

Network Hashing Rate
Mempool Observer
blockchain.info
and many, many more...

License

Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License. Here you can find an example how to cite this work.


Misc

We would like to thank Martin Florian from the Weizenbaum Institute for the Networked Society for hosting one of our monitor nodes.
This work was supported by the German Federal Ministry of Education and Research (BMBF) within the project KASTEL IoE in the Competence Center for Applied Security Technology (KASTEL), by bwFileStorage, and by LSDF Online Storage. It was performed by the Decentralized Systems and Network Services Research Group at KIT.

Contact