Due to its decentralized nature, bitcoin can’t rely on a master authoritative source to prevent double-spending, when an attacker tries to spend some money more than once. Anyway, various defensive strategies have been implemented to minimize chances for such a fraudulent activity to happen in the bitcoin network.
One particular approach, described by the Bitcoin Wiki as a Brute
force attack, can be attempted by an attacker with relatively high mining hashrate,
but not necessarily above 50% level. The attack would follow this pattern:
1. The attacker submits a transaction to the network which
pays the merchant.
2. At the same time, he will immediately start to privately
mine his own blocks, where he will include the double-spending transaction
instead of the one where he pays the merchant. But if he manages to find a new
block, he will not broadcast it to the network.
3. The merchant will wait for 6 confirmations and then sends
the product. But if the attacker managed to mine more than 6 blocks at this
time, he can release his own private fork to the network, and since he has the
longest chain, other nodes would accept it and the original transaction will
get rejected. This way, the attacker gets both the merchant product and also his
bitcoins back.
It might seem that such an attack is statistically unlikely
to happen, but when we suppose, that the attacker possess for example 25% of
the network hashpower, the probability that he will mine 7 blocks in a row is 0.25^7 = 0.006%. This looks like a very small probability, but with block time being
10 minutes, mining 7 block in a row will happen approximately once per four
months.
Fortunately, there is another measure implemented in the Bitcoin
protocol, which eliminates the possibility of such an attack. In the Protocol
rules description at Bitcoin wiki, it is listed as a Rule 13 for “block”
messages:
13. Reject [a block] if
timestamp is the median time of the last 11 blocks or before
This can be interpreted in a following way: If the attacker
will try to mine his own private blockchain fork, other nodes will almost
certainly reject it, if his length is more than 6 blocks, since the timestamp
of the first such mined block will be almost certainly older than the median
time of the last 11 mined blocks. Replacing 6 or less blocks is possible, but
when attacker tries to replace 7 or more blocks, the first one will be too old
to be accepted.
TL;DR: Six bitcoin confirmations
is not an arbitrary number. If payee accepts a transaction with less than six
confirmations, it is possible that the attacker, even without a majority of the
hashpower, can launch a brute force attack by mining his private blockchain
fork and reverse the transaction. With six or more confirmations, such an attack
will be rejected by the Protocol rule 13 described above.
Note for programmers:
The check is implemented in the method GetMedianTimePast() and called
in method AcceptBlock(), file main.cpp:
bool CBlock::AcceptBlock(CValidationState &state, CDiskBlockPos *dbp)
{
...
// Check
timestamp against prev
if (GetBlockTime() <= pindexPrev->GetMedianTimePast())
return state.Invalid(error("AcceptBlock()
: block's timestamp is too early"));
...
}
