The Finney attack, and the zero-confirmation assumption

The first assumption is zero-confirmation acceptance. If the merchant waits for even one confirmation, the attack fails: the prepared block would have to be published before the merchant's transaction confirms, and once the merchant's transaction is in a block the conflict is resolved against the attacker. The entire attack is a bet that the merchant treats an unconfirmed transaction as final.

The second assumption is that the attacker can mine a block at all. The attack requires the attacker to be a miner, because only a miner can produce the prepared block. A merchant that knows its customer is not a miner, or that a miner would have to be the counterparty, can discount the risk. This is why the attack is described as a merchant risk rather than a network risk: it targets a specific counterparty, not the ledger.

The third assumption is that the merchant cannot identify the attacker. The prepared block pays the attacker, so the coins are traceable to the address the attacker controls, and the merchant that recorded the payer's identity has a record of who took the goods. The attack is profitable only when the value released exceeds the cost of being identified and refused service in future.

The defence is confirmation depth, and it is a decision the merchant makes rather than a rule the protocol enforces. A merchant that waits for one confirmation has closed the Finney attack, because the attacker's prepared block can no longer conflict with a transaction that is already confirmed. The cost of waiting is latency, and the merchant trades that latency against the value at risk. A coffee purchase and a car purchase do not warrant the same number of confirmations.

The attack is worth understanding because it is the cleanest illustration of why "unconfirmed" is not the same as "settled". The double spending page sets out the confirmation-depth argument in full, and the race attack page covers the variant that does not require the attacker to be a miner.