Race Attack

A race attack is a double-spend attempt targeting merchants who accept zero-confirmation Bitcoin transactions. The attacker sends two conflicting transactions simultaneously: one to the merchant and one back to themselves. Only one can be confirmed in the blockchain. The attacker wins if miners confirm the version that returns funds to the attacker before the merchant notices anything is wrong.

How a Race Attack Is Executed

The attacker creates two transactions that spend the same Bitcoin inputs. The first transaction sends funds to the merchant. The second transaction redirects those same funds to an address the attacker controls. Both transactions hit the network at roughly the same time.

Different nodes see different transactions first, depending on network propagation paths. Some miners receive the merchant-directed transaction. Others receive the attacker's redirect. Whichever version a miner picks up first is the one they attempt to include in the next block. If the attacker's version wins the race, the merchant's transaction becomes invalid and is rejected by the network.

The attacker collects whatever they purchased from the merchant and keeps the Bitcoin. The merchant has no recourse.

Why This Attack Works Against 0-Conf Merchants

A merchant who waits for even one block confirmation eliminates virtually all race attack risk. Once a transaction is included in a block, replacing it requires controlling 51% of the network's hash power, which makes it economically infeasible for all but the most resourced attackers.

The attack only works when a merchant releases goods or services immediately upon seeing an unconfirmed transaction. Physical goods, digital downloads, and in-person purchases are the most common targets. A coffee shop accepting Bitcoin and handing over the drink before the transaction confirms is a viable target. An exchange that holds a deposit until it confirms is not.

How to Defend Against Race Attacks

The defenses are straightforward, but each involves a tradeoff with user experience.

• Wait for one confirmation. One block confirmation, roughly 10 minutes on Bitcoin, eliminates the attack entirely for all practical purposes.
• Use Lightning Network. Payments over Lightning Network are cryptographically final at the moment of settlement. There is no mempool step that an attacker can exploit.
• Check for RBF signaling. Transactions flagged with Replace-by-Fee signaling are explicitly designed to be replaceable. Refusing RBF-flagged transactions at point of sale blocks the easiest version of this attack.
• Monitor the mempool. Specialized software can detect if a conflicting transaction was broadcast alongside the one directed at your address. If two transactions spending the same inputs appear simultaneously, that is a strong signal of a race attack in progress.

Race Attack vs. Finney Attack

These two double-spend types are often confused. A race attack involves two transactions broadcast simultaneously without any mining pre-work. A Finney attack requires the attacker to also be a miner who pre-mines a block containing their own redirect transaction, then broadcasts the merchant-directed transaction and immediately publishes the pre-mined block. The Finney attack is more powerful but requires significant mining resources. The race attack requires nothing but two conflicting signed transactions and a willing merchant.

Sources

https://bitcoin.org/en/developer-guide#detecting-forks
https://mempool.space
https://lightning.network/lightning-network-paper.pdf

‍