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.
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.
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.
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.
Description: Announced Version strings.
Description: Announced VersionIDs.
Description: Announced Services.
Description: Number of peers per country.
Description: AS Description.
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).
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).
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.
Description: Based on above data we calculated the time it takes until 50% (90% resp.) of network peers announce a specific block.
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.
Description: Based on above data we calculated the time it takes until 50% (90% resp.) of network peers announce a specific transaction.
Description: CDF of the current measured latency using ICMP/TYP SYN Pings and Bitcoin Pings.
Description: Median Latency over time using ICMP/TYP SYN Pings and Bitcoin Pings.
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.
Description: This plot shows for each hash (x-axis) the number of announced peers that announced that hash per hour.
This work is licensed under a Creative Commons Attribution 4.0 International License.
Here you can find an example how to cite this work.
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.