Finney Attack Definition

A Finney attack is a double-spend trick where a miner secretly mines a block that sends coins back to themselves, then pays a merchant with the same coins using a different transaction. If the merchant accepts the unconfirmed payment, the attacker finally broadcasts the secret block, which erases the merchant’s transaction from the chain. 

Origin of the Name

The attack is named after Hal Finney, an early Bitcoin developer and the first person to receive a Bitcoin. He outlined how a miner could pre-mine a block and later use it to invalidate a payment that a merchant accepted without confirmations.

Conditions That Make It Possible

This attack needs three things to line up:

1. The attacker must be a miner who can include their own transaction in a privately mined block,
2. The victim accepts zero-confirmation payments, and
3. The attacker can keep the pre-mined block private until after the victim accepts payment. When any of these pieces are missing, the window for the attack narrows a lot.

How It Works, Step by Step

1. The attacker creates a transaction from Address A to their own Address B and mines a valid block that includes it, but does not broadcast the block.
2. Using the same coins at Address A, the attacker pays a merchant at Address C.
3. Once the merchant hands over goods based on that unconfirmed payment, the attacker broadcasts the secret block. The network accepts the pre-mined block, and the merchant’s transaction is dropped as if it never happened.

How It Differs From a Race Attack

In a race attack, two conflicting transactions are broadcast at roughly the same time, and the “faster” one that gets confirmed wins. In a Finney attack, the attacker already holds a valid private block ready to publish, which gives them a head start against the merchant’s transaction that has not yet reached confirmation. Both rely on merchants taking unconfirmed payments, but the setup and timing are different.

Practicality and Risk

Finney attacks are feasible only for miners and depend on lucky timing. They are generally less practical than majority-hashrate attacks and become harder as merchants tighten their confirmation rules. Still, they illustrate why accepting zero-confirmation payments carries real risk.

Defenses and Good Practice

• Wait for confirmations. The simplest fix is to wait for multiple block confirmations before treating a payment as final. Large payments should wait longer. 
• Use safer payment flows for small buys. For quick, low-value payments, consider off-chain or instant-settlement options that settle on-chain later, reducing exposure to zero-conf tricks. 
• Monitor and assess risk. Real-time monitoring and conservative policies for high-value transactions lower the chance of being caught by timing games.