The ultra-resilient bitcoin network is the world's largest distributing computing project in terms of raw computational power, having long ago surpassed 1 exaFLOPS (1,000 petaFLOPS) – over eight times the combined speed of the top 500 supercomputers.

Although since increasing to an amazing 3.2 zettaFLOPS (3,200 exaFLOPS), the project was quietly removed from Wikipedia's list of distributed computing projects. This is probably due to the fact that the exaFLOPS estimate breaks down with bitcoin's specialized ASICs, since they are not capable of floating-point operations.

Instead, the estimate may be used for estimating how well other supercomputers and distributed networking projects would be able to mine bitcoin, since supercomputers have the capability to perform the integer operations used in hashing.

Therefore, today's fastest supercomputer, China's Tianhe-2 with a performance of 33.86 Pflop/s, would measure at about 0.001% of the bitcoin network.

As bitcoin matures and starts to compete with legacy retail payments networks like Visa and MasterCard, and wholesale networks like Swift, the health of the decentralized network becomes vital to its performance capabilities.

Community site Bitcoin.org does an excellent job of maintaining the historical archive of network status alerts and vulnerabilities.

The assembled report below lists the critical statistics for monitoring the ongoing health of the distributed bitcoin network, covering the measurements important for reachability, scalability, security and transaction processing speed.

Bitnodes estimates the size of the bitcoin network by finding all the reachable nodes in the network. The current methodology involves sending getaddr message recursively to find all the reachable nodes in the network starting from a set of seed nodes. It performs this polling every 24 hours and displays the results on a world heat map of countries, including rankings and version of bitcoin reference client.

The Bitnodes Project launched in April 2013 with the Bitcoin Foundation’s sponsorship as a community resource. The project's latest report can be seen here.

The information exchange in the bitcoin network is all but instantaneous. Exactly how fast is information being propagated in the network though? Maintained by BitcoinStats, the propagation evolution chart shows the 50th percentile of the inv-messages received by peers (ie: the plot shows the time since a transaction or block enters the network until a majority of nodes has received and processed it).

DNS seeds are used by almost all bitcoin clients to identify a set of nodes to connect to when starting. The seeds are run by volunteers using a multitude of mechanisms to ensure the returned seeds represent a good sample of nodes currently online.

Except for bitseed.xf2.org, the seeds aim to return nodes that are currently online and reachable. Also provided by BitcoinStats, the chart shows results from regular bootstrap attempts using the seeds with the plot representing the average hourly connection success rate for each of the seeds. The closer to 100%, the better the seed is.

An auxiliary chart with response time of DNS seeds to queries is also provided, which indicates the response times in milliseconds (ms) elapsed between sending the query and receiving a response.

Provided by developer Pieter Wuille, this series of graphs display hashing difficulty and the estimated number of terahashes per second (computation speed) that the network is performing for various time windows (1 terahash equals 1,000 gigahashes).

Calculated by dividing maximum target by current target where target is a 256-bit number, difficulty measures how difficult it is to find a new block compared to the easiest it can ever be. Difficulty adjusts every 2,016 blocks (or two weeks) and to find a block, the SHA-256 hash of a block’s header must be lower than or equal to the current target for the block to be accepted by the network.

This pie chart from Organ Ofcorti is an estimation of hash rate distribution amongst the largest mining pools at a weekly interval. It is important to monitor because the integrity of the network depends on a single actor not exceeding 50% of the overall hashing power.

A table of solved block statistics lists all statistics that can be derived from the number of blocks a hash rate contributor has solved for the past week. Block attributions are either from primary sources such as those claimed by a particular pool website, or secondary sources such as coinbase signatures, or known generation addresses.

When dependent on secondary sources only, data may be inaccurate and miss some blocks if a particular block-solver has gone to some trouble to hide solved blocks and this will result in an underestimate of the block-solver hash rate.

An alternate chart across 24-hour, 48-hour and four-day time horizons is provided by Blockchain.

Produced by Coinometrics, this metric attempts to measure the likelihood and prevalence of bitcoin miners engaged in a subset behavior of the 'Selfish Mining' strategy, as described by Ittay Eyal and Emin Gün Sirer in their paper, Majority is not Enough: Bitcoin Mining is Vulnerable.

Since the bitcoin protocol relies on miners following the rules laid out by the software, as soon as miners have found a block they need to announce it to the network.

Selfish mining defies this rule, because certain miners, once they have found a block, can withhold it from the network and start working on their next block. Once they have a number in their hidden chain, they can release them to invalidate the blocks that the network thought were part of the main chain.

The lower the probability that at least k (actual distribution) blocks will be found in the time represented by the first bucket, the more likely that miners are engaging in quick succession behavior under the Selfish Mining strategy.

Coinometrics explains:

Orphaned blocks are valid blocks which are not part of the main bitcoin block chain. They can occur naturally when two miners produce blocks at similar times or they can be caused by an attacker with enough hashing power attempting to reverse transactions.

Initially accepted by the majority of the network, orphaned blocks are those that are rejected after proof of a longer block chain is received that doesn't include that particular block. In other words, a user could see a transaction as having one confirmation and then revert to zero confirmations if a longer blockchain was received that didn't include the transaction.

Blockchain maintains a real-time monitor for double spends detected in the last 500,000 transactions utilizing a 10-minute cache. This could be used to alert users to potentially malicious transactions on the network.

Blockchain also maintains this live updating list of new bitcoin transactions waiting to be included in a block. The monitor displays total number of unconfirmed transactions, including total fees and total size in kilobytes.

This measures the average (mean) amount of time in minutes that it takes for a transaction to be accepted into a block. Reasonable estimates differ on the amount of time and confirmations for a transaction to be considered cleared and ‘good’, but that appropriate risk level would be associated with the transaction’s value.

The block chain total size is important because of the storage space considerations as it grows as well as the time it takes for initial synchronization after installing the reference client for the first time. This measurement shows total size of all block headers and transactions not including database indexes.

Measured here in fractions of a megabyte, the block size will become a heated debate once the bitcoin network starts approaching its current throughput limit of approximately seven transactions per second.

Ultimately important for scalability, the stated block size limit will have to be increased, linked to another variable, or remain the same with more confirmations pushed off chain, each path having corresponding implications for decentralization of the system.

Please let us know in the comments section below if we have omitted any measurement critical to network operations or if any references are out-dated.

Follow Jon Matonis on Twitter.