Uptime and other service performance levels

Question

Other payment networks have scheduled maintenance periods as well as unscheduled outages but Bitcoin's network, being decentralized, can have varying service levels depending on:

• which versions of the software and which nodes are used
• the nature of the transactions (e.g., microtransactions or those originating from an eWallet sans fee, etc.)
• several other factors.

What are key performance measurements that can be made for the Bitcoin network, and how can they be measured? If measurements are being made already, where are they available?

Answer 1

You seem to conflate several issues in your question. If you are just talking about "uptime", which your question title implies, then speed of transaction propagation or confirmation is not relevant. As long as your node is can connect to other nodes and send/receive data, the network is "up". If you send transactions that require fees and they don't confirm for a long time, that's your problem, not the network's.

That said, the "gist" of your question, about network health, transaction processing speed, etc, is not unimportant. There is a bunch of useful data on this site, dedicated to monitoring the bitcoin network: http://bitcoinstatus.rowit.co.uk/ that would probably get you started in the right direction. :)

Answer 2

Confirmation time of received transactions is a key service level measurement.

For someone processing transactions with their own custom client, it's mostly up to them as to when they consider a transaction confirmed, as there's a trade off between speed and risk.

Multi-node listening allows a reasonable level of confidence that a double spend hasn't been performed, but it doesn't protect against a Finney attack.

Because a Finney attack is difficult and risky to perform (the attacker risks losing the reward for a solved block), it would only be worth bothering with a particularly large transaction. This means the level of service differs by transaction.

A table indicating confirmation time (and thus service level) would go something like this (figures are educated guesses; perhaps someone can measure it an update the answer at some point):

Transaction size    Risk of Finney attack    Confirmation technique        Confirmation time
Small               Very Low                 Multi-node listening          <3 Seconds
Large               High                     2+ Block confirmations        20+ minutes, on average
Very large          Very High                Many (x) block confirmations  x*10 minutes

Obviously it's open to interpretation as to what is "small" and "large". As previously stated, the trade off between speed and risk will help determine a suitable balance for each scenario.