<p>Shorter answers:</p>

<ul>
<li>The number of confirmations you "should" require for a transaction is entirely up to you.
<ul>
<li>OK, that's not particularly helpful, I know.  For me, looking at the current environment, I'm not planning on doing anything that would justify forcing a wait for any more than 2 confirmations under normal circumstances*.</li>
</ul></li>
<li>The level of security that you get by waiting for <em>n</em> number of confirmations is basically constant.
<ul>
<li>If at some point in the past, you made an informed decision that <em>n</em> number of confirmations was "good enough", then <em>n</em> should be just as good enough today, possibly better.</li>
</ul></li>
</ul>

<p>Longer answers:</p>

<ul>
<li>When I make the claim about 2 confirmations, I'm betting against the existence of an entity X who would be able to make the following sequence of events happen (YMMV):
<ol>
<li>X sends me some number of Bitcoins in a transaction that spends some output A.</li>
<li>That transaction is included in a block accepted by the network at height h (confirmation #1)</li>
<li>A block is accepted by the network building on top of that one at height h+1 (confirmation #2)</li>
<li>I do the thing that entity X paid me those Bitcoins to do.</li>
<li>An alternative chain of at least two other valid blocks, including heights h and h+1, is announced to the network and spends output A to some other place, probably owned by X.</li>
<li>The newer chain is built upon (most likely, but not necessarily, by X him/herself: miners, especially those that got the coinbase rewards from the honest chain, will tend to work on the honest chain for no other reason than it's what they saw first), locking in the double-spend.</li>
</ol></li>
<li>Building off the previous note, <em>n</em> confirmations sets the bar for being able to successfully pull off a double-spend attack at a level that increases <strong>exponentially</strong> with <em>n</em>.
<ul>
<li>If I think it's unrealistic to expect someone to be able to reliably and cost-effectively do this under normal circumstances* at <em>n</em>=2, requiring <em>n</em>=3 feels a bit paranoid, and don't even get me started about <em>n</em>=6.</li>
<li>Furthermore, even if someone were capable of doing this, they would have to stand to gain more from their victims than some significant proportion of the block rewards before even <strong>attempting</strong> it.</li>
<li>The opportunity cost of a failed attempt is the sum of all the block rewards that the would-be attacker could have received if he/she participated in the network honestly.</li>
</ul></li>
</ul>

<p>Some thoughts about major hashrate increases and lucky bursts:</p>

<p>Even if the network hits an extremely lucky streak and several blocks are mined in the course of a very short time, the expected amount of work it would take for an attacker to reverse a buried transaction stays the same.  In this way, lucky streaks (and overall increased hashrate) by honest nodes actually <strong>increase</strong> security, whereas lucky streaks are <strong>required</strong> for an attacker with &lt;50% of the network hashrate.</p>

<p>Where an increase in network hashrate becomes a bigger concern is when this increase tends to favor a single entity (which could itself be a group of entities).  As this entity gets a higher and higher share of the total network hashrate, reversing transactions buried 6 confirmations deep in the chain becomes a more and more realistic proposition.  According to the calculation from Satoshi's original whitepaper, an attacker with 45% of the network hashrate would have a 30% chance ((.45 / .55) ** 6) of being able to "catch up" from being 6 blocks behind and reverse your supposedly "confirmed" transaction.  So, on average, with those odds (which are high enough to make a lot of people on-edge), this attacker would have to stand to gain more than 70% of the rewards from 6 consecutive blocks in order for this attack to be worth it.</p>

<p>Why is <em>n</em>=6 the recommendation?  I don't know.  My out-of-the-blue guess is that this made a lot more sense back at a time when someone with a lot of extant general-purpose CPU/GPU power could more easily generate blocks than today.  Today, since so much of the honest network hashrate is running specialized computing devices (ASICs), the network hashrate has risen so dramatically that it's unfeasible to expect there to be an untapped reserve of computing power that can come out of the blue and overtake the network at large (which is why I've said "possibly better" above).</p>

<p>Why would MtGox wait more than 6 or even 8 confirmations before accepting incoming transactions?  I don't know, but it doesn't surprise me; that organization never really struck me as having a deep understanding of Bitcoin, despite how important it was to their business and despite the apparent fact that they were running bitcoind with in-house customizations.</p>

<p>*Normal circumstances assume there's no network anomaly going on like the <a href="https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki" rel="nofollow" title="BIP 0050: March 2013 Chain Fork Post-Mortem">hard fork of March 2013</a>, we're not talking with HUGE transaction volumes, and I have no reason to believe the major mining pools are collectively out to get me.</p>

CC BY-SA 3.0
2014-04-20T23:59:12.730Z
2014-04-20T23:59:12.730Z
Joe Amenta
<p>Right now, the number of blocks created is increasing at a rapid rate.  In addition I tried to import coins into a MtGox account and noticed that even after 8 confirmations the funds aren't available.</p>

<p>Traditionally, the funds were available after 6 confirmations.</p>

<p>After thinking about this, it makes sense that if many blocks are claimed in multiple successions and not enough time has passed, it may be reasonable to wait a period of time before accepting the transaction.</p>

<ul>
<li><p>My question is: What is the formula that should be used when counting the number of confirmations required for a tx?</p></li>
<li><p>Should I take into consideration the rate of change? ...over what period?</p></li>
</ul>

<p>This question seems to be relevant during the increase in hashes coming from the new ASIC line from BFL and Avalon.</p>

CC BY-SA 3.0
2013-03-26T23:07:47.153Z
Are you asking about what to do when difficulty is volatile or what to do when hashrate is volatile?
Nick ODell
CC BY-SA 3.0
2013-03-26T23:44:04.993Z
@NickODell - I think I see your point.  Hashrate (block creation) can vary even with a constant difficulty that never changes.  Whereas difficulty is the "macro" view, block creation rate is the "micro/confirmation" view.  Perhaps I should rephrase.  What is a better term: hashrate or block rate?
makerofthings7
<confirmations><difficulty><asic>
How many confirmations is enough if block creation rate is volatile?
makerofthings7
# How many confirmations is enough if block creation rate is volatile?

(Asked by: username_0 on 2013-03-26)

Right now, the number of blocks created is increasing at a rapid rate. In addition I tried to import coins into a MtGox account and noticed that even after 8 confirmations the funds aren't available.

Traditionally, the funds were available after 6 confirmations.

After thinking about this, it makes sense that if many blocks are claimed in multiple successions and not enough time has passed, it may be reasonable to wait a period of time before accepting the transaction.

* My question is: What is the formula that should be used when counting the number of confirmations required for a tx?
* Should I take into consideration the rate of change? ...over what period?

This question seems to be relevant during the increase in hashes coming from the new ASIC line from BFL and Avalon.

**Tags:** confirmations, difficulty, asic

> **Comments:**
> **username_1**: Are you asking about what to do when difficulty is volatile or what to do when hashrate is volatile?  
> **username_0**: @username_1 - I think I see your point.  Hashrate (block creation) can vary even with a constant difficulty that never changes.  Whereas difficulty is the "macro" view, block creation rate is the "micro/confirmation" view.  Perhaps I should rephrase.  What is a better term: hashrate or block rate?  

---

## 1 answers

### Answer by username_2 on 2014-04-20. Score: 1

Shorter answers:

* The number of confirmations you "should" require for a transaction is entirely up to you.
  + OK, that's not particularly helpful, I know. For me, looking at the current environment, I'm not planning on doing anything that would justify forcing a wait for any more than 2 confirmations under normal circumstances\*.
* The level of security that you get by waiting for *n* number of confirmations is basically constant.
  + If at some point in the past, you made an informed decision that *n* number of confirmations was "good enough", then *n* should be just as good enough today, possibly better.

Longer answers:

* When I make the claim about 2 confirmations, I'm betting against the existence of an entity X who would be able to make the following sequence of events happen (YMMV):
  1. X sends me some number of Bitcoins in a transaction that spends some output A.
  2. That transaction is included in a block accepted by the network at height h (confirmation #1)
  3. A block is accepted by the network building on top of that one at height h+1 (confirmation #2)
  4. I do the thing that entity X paid me those Bitcoins to do.
  5. An alternative chain of at least two other valid blocks, including heights h and h+1, is announced to the network and spends output A to some other place, probably owned by X.
  6. The newer chain is built upon (most likely, but not necessarily, by X him/herself: miners, especially those that got the coinbase rewards from the honest chain, will tend to work on the honest chain for no other reason than it's what they saw first), locking in the double-spend.
* Building off the previous note, *n* confirmations sets the bar for being able to successfully pull off a double-spend attack at a level that increases **exponentially** with *n*.
  + If I think it's unrealistic to expect someone to be able to reliably and cost-effectively do this under normal circumstances\* at *n*=2, requiring *n*=3 feels a bit paranoid, and don't even get me started about *n*=6.
  + Furthermore, even if someone were capable of doing this, they would have to stand to gain more from their victims than some significant proportion of the block rewards before even **attempting** it.
  + The opportunity cost of a failed attempt is the sum of all the block rewards that the would-be attacker could have received if he/she participated in the network honestly.

Some thoughts about major hashrate increases and lucky bursts:

Even if the network hits an extremely lucky streak and several blocks are mined in the course of a very short time, the expected amount of work it would take for an attacker to reverse a buried transaction stays the same. In this way, lucky streaks (and overall increased hashrate) by honest nodes actually **increase** security, whereas lucky streaks are **required** for an attacker with <50% of the network hashrate.

Where an increase in network hashrate becomes a bigger concern is when this increase tends to favor a single entity (which could itself be a group of entities). As this entity gets a higher and higher share of the total network hashrate, reversing transactions buried 6 confirmations deep in the chain becomes a more and more realistic proposition. According to the calculation from Satoshi's original whitepaper, an attacker with 45% of the network hashrate would have a 30% chance ((.45 / .55) \*\* 6) of being able to "catch up" from being 6 blocks behind and reverse your supposedly "confirmed" transaction. So, on average, with those odds (which are high enough to make a lot of people on-edge), this attacker would have to stand to gain more than 70% of the rewards from 6 consecutive blocks in order for this attack to be worth it.

Why is *n*=6 the recommendation? I don't know. My out-of-the-blue guess is that this made a lot more sense back at a time when someone with a lot of extant general-purpose CPU/GPU power could more easily generate blocks than today. Today, since so much of the honest network hashrate is running specialized computing devices (ASICs), the network hashrate has risen so dramatically that it's unfeasible to expect there to be an untapped reserve of computing power that can come out of the blue and overtake the network at large (which is why I've said "possibly better" above).

Why would MtGox wait more than 6 or even 8 confirmations before accepting incoming transactions? I don't know, but it doesn't surprise me; that organization never really struck me as having a deep understanding of Bitcoin, despite how important it was to their business and despite the apparent fact that they were running bitcoind with in-house customizations.

\*Normal circumstances assume there's no network anomaly going on like the [hard fork of March 2013](https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki "BIP 0050: March 2013 Chain Fork Post-Mortem"), we're not talking with HUGE transaction volumes, and I have no reason to believe the major mining pools are collectively out to get me.


---

