<p>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.</p>

<p>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: <a href="http://bitcoinstatus.rowit.co.uk/" rel="nofollow">http://bitcoinstatus.rowit.co.uk/</a> that would probably get you started in the right direction. :)</p>

CC BY-SA 3.0
2011-10-15T22:43:45.790Z
I've modified the title and question to also inquire about other metrics as well.
Stephen Gornick
CC BY-SA 3.0
2011-10-17T12:59:40.287Z
@StephenGornick I would remove uptime from your question title and simply indicate in question that "since uptime is 100% for a distributed network what OTHER metrics can be measured to calculate performance".  Since the genesis block bitcoin uptime has been absolutely 100%.  As long as their is a single node receiving and hashing transactions it will remain 100%.  In other word uptime will always be 100% until Bitcoin is no longer used.
DeathAndTaxes
CC BY-SA 3.0
2011-10-02T22:10:27.790Z
2011-10-02T22:10:27.790Z
nanotube
<p>Confirmation time of received transactions is a key service level measurement.</p>

<p>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.</p>

<p><a href="https://bitcoin.stackexchange.com/a/3246/516">Multi-node listening</a> allows a reasonable level of confidence that a double spend hasn't been performed, but it doesn't protect against a <a href="https://bitcoin.stackexchange.com/a/729/516">Finney attack</a>.</p>

<p>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.</p>

<p>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):</p>

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

<p>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.</p>

CC BY-SA 3.0
2012-08-15T01:34:32.393Z
2012-08-15T01:44:27.280Z
2017-04-13T12:47:36.647Z
Highly Irregular
<p>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:</p>

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

<p>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?</p>

CC BY-SA 3.0
2011-10-15T22:58:01.207Z
Here's an example of a metric that others are interested in as well.  http://bitcoin.stackexchange.com/questions/1557/speed-of-operations-in-the-bitcoin-network
Stephen Gornick
<network><performance>
Uptime and other service performance levels
Stephen Gornick
# Uptime and other service performance levels

(Asked by: username_0 on 2011-10-02)

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?

**Tags:** network, performance

> **Comments:**
> **username_0**: Here's an example of a metric that others are interested in as well.  http://bitcoin.stackexchange.com/questions/1557/speed-of-operations-in-the-bitcoin-network  

---

## 2 answers

### Answer by username_1 on 2011-10-02. Score: 2

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. :)

> **Comments:**
> **username_0**: I've modified the title and question to also inquire about other metrics as well.  
> **username_2**: @username_0 I would remove uptime from your question title and simply indicate in question that "since uptime is 100% for a distributed network what OTHER metrics can be measured to calculate performance".  Since the genesis block bitcoin uptime has been absolutely 100%.  As long as their is a single node receiving and hashing transactions it will remain 100%.  In other word uptime will always be 100% until Bitcoin is no longer used.  

---

### Answer by username_3 on 2012-08-15. Score: 1

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](https://bitcoin.stackexchange.com/a/3246/516) allows a reasonable level of confidence that a double spend hasn't been performed, but it doesn't protect against a [Finney attack](https://bitcoin.stackexchange.com/a/729/516).

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.


---

