Is Bitcoin Prone To Double-Spending Problem?
The key feature that made Bitcoin survive where its predecessors failed was the ability to solve the “double-spending” problem in the distributed-decentralized network on the global scale. But as with almost everything in life, the double-spending resiliency guarantee has limits.
There are multiple know attack vectors know for Bitcoin network like Race attack, Vector76 attack, Finney attack, Alternative history attack or well-known Majority (51% ) attack.
Race, Vector76, Finney and Alternative history attack vectors are significantly mitigated by waiting for more confirmations. For example, “Alternative history attack” in case the attacker controls 10% of hashing power available in the network is after six confirmations in the range < 0.1%.
The reason behind these attack vectors are possible is the property of “lottery-based” algorithms — e.g., Proof of Work in Bitcoin. The winner eligible to create new block is selected based on some “decentralized lottery” process . In Bitcoin by searching for a correct nonce to get hash of the mined block header lower than specific k (starting with certain number of zeros). The “k” here controls complexity of solving the “cryptographic riddle”. It is adjusted based on the actual computational power behind the network to set average block frequency to ~10 minutes.
What can happen there are multiple winners and therefore valid blocks sent to network at a virtually same time?
Valid blocks are accepted and appended to ledger by full nodes. The blockchain ledger is no longer linear list of blocks/transactions but starts to have branches. The ledger eventually converges back to single linear ledger by selecting the longest chain as the main chain and abandoning other branches. Transactions that appear only in branches are orphaned and get back to miner’s mempools.
If we are accepting bitcoin payments, then we are interested in a measure called latency to finality. Latency to finality is time to wait to get high enough probability, e.g., < 0.1% that the transaction is not going to be reversed). In blockchains using lottery-based consensus algorithms is relatively high. E.g., in bitcoin six blocks with one block per ~10 minutes => ~1 hour.
The finality of a transaction in blockchains using lottery-based consensus algorithms is a probabilistic measure. It is basically a function of a number of confirmations (or time)*.
Such attack vectors do no apply to “voting based” algorithms like RBFT or BFT-SMaRt. The block getting enough votes (potentially through multiple rounds based on consensus algorithm) is finalized. Therefore the transaction is immediately finalized and cannot be reverted. The finality in voting-based consensus algorithms is not probabilistic function. The disadvantage is that these algorithms do not scale so well, because more information has to be exchanged during consensus.
If you are accepting crypto payments for your services, then you have to understand the underlying platform and set your risk model accordingly. Trusting 0 confirmations is probably ok for a coffee payment, but might not be appropriate for if we talk about larger transfers of money.
Happy block-chaining
— Lukas
