|
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.
Monitoring network health
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.
 Source: Bitnodes
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.
 Source: BitcoinStats
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.
 Source: BitcoinStats
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.
 Source: Organ OfCorti
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.
 Source: Coinometrics
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:
"One way to estimate the likelihood of such a strategy
being implemented is to measure the distribution of the time between
blocks against the expected distribution. The rate of creation of
bitcoin blocks is determined by how quickly the first miner solves for a
hash meeting the difficulty requirements of the protocol. Every attempt
to meet this difficulty has a set probability of being correct. By
definition, the probability is independent between hashes. As a result
the rate at which blocks are generated should follow an exponential
distribution."
 Source: Blockchain
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.
 Source: Blockchain
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.
 Source: Blockchain
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.
 Source: Blockchain
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.
 Source: Blockchain
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.
| |
