0-confirmation

A transaction where a merchant provides a product or service before the transmission of the bitcoins has been confirmed by a miner and added to the blockchain. This can carry the risk of double spending. When bitcoins are sent to an address but the transaction is not yet included in a block, it is considered a zero-confirmation transaction. The on-average confirmation time of ten minutes may be too long for many everyday purchases. Therefore some merchants will take funds that have arrived in their wallet as adequate proof that the transaction has taken place and conclude the sale. This can carry the risk known as a 51% attack or a double spend attack. An attacker can make a payment, wait until the merchant accepts some number of confirmations and provides the product or service. The attacker then starts mining a parallel chain of blocks starting with the block preceding the transaction. This parallel blockchain then includes another transaction that spends the same bitcoins on some other address. When the parallel chain becomes more difficult, it is considered a main chain by all nodes and the original transaction becomes invalid. Having more than half the total hashrate guarantees the possibility to overtake a chain of any length, hence the name of the attack. (Strictly speaking it is “more than 50%, not 51%.) Furthermore, even 40% of hashrate allows for double spending, but the chances are less than 100% and diminish exponentially with the number of confirmations that the merchant requires. This attack is considered theoretical as possessing more than 50% of the hashrate might be much more expensive than any gain from a double spend. Another variant of an attack is to disrupt the network by mining empty blocks, thereby censoring all transactions. An attacked can be mitigated by blacklisting blocks that most “honest” miners consider abnormal. Under normal conditions miners and mining pools do not censor blocks and transactions as this may diminish trust in Bitcoin and thus their investment. A 51% attack is also mitigated by using checkpoints that prevent reorganization past the certain block.