user145: Why is 6 is the number of confirmations that is considered secure? I haven't found any mathematical explanation or otherwise that explains why it is 6 and not 5 or 7. Is there a historical reason for 6? Is there a specific way to calculate it so 6 is just a number that was chosen?

user2059: With more confirmations probability of making a successful double-spend decrease. While it is possible to perform a double-spend with less than 51% of hashing power it requires one to be luckier than the rest of the miners, ie. solve blocks faster than others. This will go on forever (to be correct: it is very unlikely) so the attacker will not be able to fork the whole chain. With pools until very recently controlling 30-40% of total hashing power the 6-confirmation rule would not have been safe if the pool operator had decided to commit a malignant act. 

user575: The figure of 6 blocks is completely arbitrary. It is based on the assumptions that the attacker will not amass more than 10% of the network hashrate, and that a negligible chance of 0.1% for successfully double-spending is acceptable.
A more detailed analysis of this is available at Analysis of Hashrate-Based Double-Spending

user145: Here are some of the relevant sections from Satoshi's paper:
http://bitcoin.org/bitcoin.pdf
"11. Calculations
We consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain.  ... The race between the honest chain and an attacker chain can be characterized as a Binomial Random Walk.  The success event is the honest chain being extended by one block, increasing its lead by +1, and the failure event is the attacker's chain being extended by one block, reducing the gap by -1. ... The probability of an attacker catching up from a given deficit is analogous to a Gambler's Ruin problem. ...
p = probability an honest node finds the next block
q = probability the attacker finds the next block
qz = probability the attacker will ever catch up from z blocks behind

Given our assumption that p > q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases.  With the odds against him, if he doesn't make a lucky lunge forward early on, his chances become vanishingly small as he falls further behind ... the attacker's potential progress will be a Poisson distribution ... To get the probability the attacker could still catch up now, we multiply the Poisson density for each amount of progress he could have made by the probability he could catch up from that point.
Converting to C code..
include <math.h>
double AttackerSuccessProbability(double q, int z)
{
    double p = 1.0 - q;
    double lambda = z * (q / p);
    double sum = 1.0;
    int i, k;
    for (k = 0; k <= z; k++)
    {
        double poisson = exp(-lambda);
        for (i = 1; i <= k; i++)
            poisson *= lambda / i;
        sum -= poisson * (1 - pow(q / p, z - k));
    }
    return sum;
}

Running some results, we can see the probability drop off exponentially with z.
"

user307: Many people misquote Satoshi paper and assume 6 is some hard value.
Satoshi's paper outlines the number of confirmations necessary to be 99.9% sure (less than 1 in 1000 chance of success) that an attacker couldn't build a longer chain to reverse the transaction.
http://bitcoin.org/bitcoin.pdf
P < 0.001
q=0.10   z=5
q=0.15   z=8
q=0.20   z=11
q=0.25   z=15
q=0.30   z=24
q=0.35   z=41
q=0.40   z=89
q=0.45   z=340

p is the chance of attacker eventually getting longer chain and reversing a transaction (0.1% in this case).
q is the % of the hashing power the attacker controls.
z is the number of blocks to put the risk of a reversal below p (0.1%).
So you can see if the attacker has a small % of the hashing power 6 blocks is sufficient.  Remember 10% of the network at the time of writing is ~100GH/s.  However if the attacker had greater % of hashing power it would take increasingly longer to be sure a transaction can't be reversed.
If the attacker had significantly more hashpower say 25% of the network it would require 15 confirmation to be sure (99.9% probability) that an attacker can't reverse it.
If the attacker has q of >50% ("the 51% attack") then given unlimited time the attacker will inevitably end up with the longest chain.
On edit: to clarify the "unlimited time" the chain with the higher hashrate will inevitably end up the longest however probability still comes into play.  We can not say with 100% certainty how long it will take at best we can provide a confidence interval.  If the attacker is just barely faster than the good miners (51% vs 49%) then it can take a very long time for an attacker to overcome a deficit of 6 blocks.  The more the attacker dominates (i.e. 70% vs 30%) the quicker the shorter the 95% confidence interval is reached.

user153: I believe this is addressed in page 8 of Satoshi's Bitcoin paper when showing the probability of an attacker catching up.
The wiki states: 

"Only 6 blocks or 1 hour is enough to make reversal computationally impractical."  

The key word is "impractical".  
The important sentence in Satoshi's paper is: 

"Assuming the honest blocks took the average expected time per block, the attacker's potential progress will be a Poisson distribution".  

So, it is not that someone couldn't create the worlds first and own a $50 million ASIC farm, so as to have the ability to overtake the blockchain from a fork six blocks prior but that doing so would be a.) a massive undertaking, b.) obvious to all and c.) terrifically unprofitable to the attacker.

145: <p>Why is 6 is the number of confirmations that is considered secure? I haven't found any mathematical explanation or otherwise that explains why it is 6 and not 5 or 7. Is there a historical reason for 6? Is there a specific way to calculate it so 6 is just a number that was chosen?</p>
 2059: <p>With more confirmations probability of making a successful double-spend decrease. While it is possible to perform a double-spend with less than 51% of hashing power it requires one to be luckier than the rest of the miners, ie. solve blocks faster than others. This will go on forever (to be correct: it is very unlikely) so the attacker will not be able to fork the whole chain. With pools until very recently controlling 30-40% of total hashing power the 6-confirmation rule would not have been safe if the pool operator had decided to commit a malignant act. </p>
 575: <p>The figure of 6 blocks is completely arbitrary. It is based on the assumptions that the attacker will not amass more than 10% of the network hashrate, and that a negligible chance of 0.1% for successfully double-spending is acceptable.</p>

<p>A more detailed analysis of this is available at <a href="https://bitcoil.co.il/Doublespend.pdf">Analysis of Hashrate-Based Double-Spending</a></p>
 145: <p>Here are some of the relevant sections from Satoshi's paper:
<a href="http://bitcoin.org/bitcoin.pdf" rel="noreferrer">http://bitcoin.org/bitcoin.pdf</a></p>

<p>"11. Calculations
We consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain.  ... The race between the honest chain and an attacker chain can be characterized as a Binomial Random Walk.  The success event is the honest chain being extended by one block, increasing its lead by +1, and the failure event is the attacker's chain being extended by one block, reducing the gap by -1. ... The probability of an attacker catching up from a given deficit is analogous to a Gambler's Ruin problem. ...</p>

<p>p = probability an honest node finds the next block
q = probability the attacker finds the next block
qz = probability the attacker will ever catch up from z blocks behind</p>

<p><img src="https://i.stack.imgur.com/s1tlh.png" alt="equation"></p>

<p>Given our assumption that p > q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases.  With the odds against him, if he doesn't make a lucky lunge forward early on, his chances become vanishingly small as he falls further behind ... the attacker's potential progress will be a Poisson distribution ... To get the probability the attacker could still catch up now, we multiply the Poisson density for each amount of progress he could have made by the probability he could catch up from that point.</p>

<p>Converting to C code..</p>

<pre><code>include &lt;math.h&gt;
double AttackerSuccessProbability(double q, int z)
{
    double p = 1.0 - q;
    double lambda = z * (q / p);
    double sum = 1.0;
    int i, k;
    for (k = 0; k &lt;= z; k++)
    {
        double poisson = exp(-lambda);
        for (i = 1; i &lt;= k; i++)
            poisson *= lambda / i;
        sum -= poisson * (1 - pow(q / p, z - k));
    }
    return sum;
}
</code></pre>

<p>Running some results, we can see the probability drop off exponentially with z.
"</p>
 307: <p>Many people misquote Satoshi paper and assume 6 is some hard value.</p>
<p>Satoshi's paper outlines the number of confirmations necessary to be 99.9% sure (less than 1 in 1000 chance of success) that an attacker couldn't build a longer chain to reverse the transaction.</p>
<p><a href="http://bitcoin.org/bitcoin.pdf" rel="nofollow noreferrer">http://bitcoin.org/bitcoin.pdf</a></p>
<pre><code>P &lt; 0.001
q=0.10   z=5
q=0.15   z=8
q=0.20   z=11
q=0.25   z=15
q=0.30   z=24
q=0.35   z=41
q=0.40   z=89
q=0.45   z=340
</code></pre>
<p>p is the chance of attacker eventually getting longer chain and reversing a transaction (0.1% in this case).
q is the % of the hashing power the attacker controls.
z is the number of blocks to put the risk of a reversal below p (0.1%).</p>
<p>So you can see if the attacker has a small % of the hashing power 6 blocks is sufficient.  Remember 10% of the network at the time of writing is ~100GH/s.  However if the attacker had greater % of hashing power it would take increasingly longer to be sure a transaction can't be reversed.</p>
<p>If the attacker had significantly more hashpower say 25% of the network it would require 15 confirmation to be sure (99.9% probability) that an attacker can't reverse it.</p>
<p>If the attacker has q of &gt;50% (&quot;the 51% attack&quot;) then given unlimited time the attacker will inevitably end up with the longest chain.</p>
<p>On edit: to clarify the &quot;unlimited time&quot; the chain with the higher hashrate will inevitably end up the longest however probability still comes into play.  We can not say with 100% certainty how long it will take at best we can provide a confidence interval.  If the attacker is just barely faster than the good miners (51% vs 49%) then it can take a very long time for an attacker to overcome a deficit of 6 blocks.  The more the attacker dominates (i.e. 70% vs 30%) the quicker the shorter the 95% confidence interval is reached.</p>
 153: <p>I believe this is addressed in page 8 of Satoshi's <a href="http://bitcoin.org/bitcoin.pdf" rel="noreferrer">Bitcoin paper</a> when showing the probability of an attacker catching up.</p>

<p>The <a href="https://en.bitcoin.it/wiki/FAQ#Why_do_I_have_to_wait_10_minutes_before_I_can_spend_money_I_received.3F" rel="noreferrer">wiki</a> states: </p>

<blockquote>
  <p>"Only 6 blocks or 1 hour is enough to make reversal computationally impractical."  </p>
</blockquote>

<p>The key word is "impractical".  </p>

<p>The important sentence in Satoshi's paper is: </p>

<blockquote>
  <p>"Assuming the honest blocks took the average expected time per block, the attacker's potential progress will be a <a href="http://en.wikipedia.org/wiki/Poisson_distribution" rel="noreferrer">Poisson distribution</a>".  </p>
</blockquote>

<p>So, it is not that someone couldn't create the worlds first and own a $50 million ASIC farm, so as to have the ability to overtake the blockchain from a fork six blocks prior but that doing so would be a.) a massive undertaking, b.) obvious to all and c.) terrifically unprofitable to the attacker.</p>
