Saturday, January 18, 2014

Bitcoin transactions: Why it is recommended to wait for at least six confirmations?


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"));

...
}