The race attack, and why propagation decides it

The first assumption is zero-confirmation acceptance, exactly as in the Finney attack. If the merchant waits for a confirmation, the race is over before it starts: the merchant's transaction is in a block, and the conflicting transaction can never be mined. The attack is a bet that the merchant treats an unconfirmed transaction as final.

The second assumption is a propagation advantage. The attacker must get its transaction to a miner before the merchant's transaction does. That depends on how the attacker is connected, how the merchant broadcasts, and how quickly the two transactions travel. An attacker on a well-connected node with a direct path to a large miner has an advantage; an attacker on a slow connection does not.

The third assumption is that the merchant does not detect the conflict. A merchant that watches the mempool for a conflicting spend of the same output can see the race in progress and refuse to release the goods. The attack works against a merchant that checks only that the payment it received is valid, not that no conflicting spend exists.

The primary defence is confirmation depth: a merchant that waits for one confirmation has removed the race, because the network has already ordered the two transactions and only one of them can be in the chain. The secondary defence is mempool monitoring. A merchant that watches for a conflicting spend of the output it was paid can see the attacker's transaction arrive and hold the goods until the conflict is resolved.

The race attack and the Finney attack are the two ways to double spend against a merchant that accepts zero confirmations. The Finney attack page covers the variant that requires the attacker to be a miner, and the double spending page sets out the confirmation-depth argument that closes both.