What is a Finney Attack?
A Finney attack is a specialized double-spending technique against merchants who accept payments on zero confirmations (i.e., the moment a transaction appears in the mempool, before it is mined into a block). Named after Hal Finney — the cryptographer and early Bitcoin pioneer who first described it in a 2011 Bitcointalk post — the attack requires the perpetrator to be a miner (or to control hash power). The attacker secretly pre-mines a block that sends their coins back to themselves, then hands the same coins to a merchant in a regular transaction, and finally publishes the pre-mined block, which overrides the payment to the merchant.
The Finney attack is significant because it shows that accepting zero-confirmation transactions is never truly safe on a proof-of-work chain, even if the merchant is well-connected. It is the canonical demonstration of why “wait for confirmations” is the rule for any non-trivial Bitcoin payment.
How a Finney Attack Works / Technical Details
The attack exploits the asymmetry between a transaction sitting in the mempool and a fully mined block. A mined block is the truth; a mempool transaction is only a candidate for truth.
Step by Step
- Pre-mine in secret. The attacker mines a block (does not broadcast it) in which they transfer their own coins from Address A to Address B, both under their control.
- Spend the same coins. With the secret block held back, the attacker sends the same coins from Address A to the merchant, in a normal transaction that lands in the mempool.
- Deliver goods fast. The merchant, seeing the payment in the mempool, accepts it on zero confirmations and hands over goods (typically digital goods, gift cards, or anything instantly delivered).
- Publish the secret block. The attacker now broadcasts their pre-mined block. Because it was mined first, it becomes part of the main chain.
- Merchant’s payment is orphaned. The block that pays the merchant (step 2) conflicts with the pre-mined block (step 1) that pays the attacker’s Address B. The merchant’s transaction is rejected as a double-spend.
Why Only Miners Can Do It
The attack requires producing a valid block, which demands hash power. A non-miner cannot pre-mine anything. This makes Finney attacks rare in practice — but a miner (especially a large pool) could attempt them opportunistically, particularly against merchants accepting 0-conf.
Probability and Economics
The attacker’s cost is the opportunity cost of withholding a block: while they secretly mine block N+1, they cannot collect the reward for it on the public chain until they publish. If they fail to defraud a merchant during that window, they simply publish the block and collect the normal reward, losing only the small time advantage. The risk to the attacker is therefore low, which is precisely why it is a credible threat to 0-conf merchants.
Notable Examples and Context
Hal Finney’s Original Post (2011)
Finney described the attack not to enable fraud but to warn merchants that zero-confirmation acceptance is unsafe. His analysis made clear that even a “well-connected” merchant can be defrauded, because the attacker’s secret block is valid the moment it is published.
0-Conf and BCH Debates
The Finney attack became a central talking point in debates over zero-confirmation transactions, especially in the Bitcoin Cash community, where some advocates pushed for “safe” 0-conf. The Finney vector remains a fundamental limit: nothing in the base protocol can guarantee a 0-conf payment will confirm.
Related Vectors
The Finney attack is one family of double-spend. Others include:
- Race attack — broadcast two conflicting transactions and hope one merchant gets paid from a different mempool partition
- Vector76 — a hybrid of race and Finney targeting exchanges
- 51% / majority attack — reorganize confirmed blocks (far more expensive)
How to Protect Against Finney Attacks
For Merchants
- Wait for confirmations. The single most effective defense. After 1 confirmation, a Finney attack becomes an expensive reorg; after 6 confirmations, it is economically infeasible for any reasonable attacker.
- For instant-delivery goods, treat 0-conf as probabilistic. Require additional verification for high-value items, or use payment processors that monitor the network for conflicting transactions and double-spend alerts.
- Green-address-style services or watchtowers that detect conflicting spends in the mempool can flag attempted double-spends before confirmation.
Understanding the Risk Tiers
| Value / Speed | Recommended Confirmations |
|---|---|
| Coffee, digital micro-goods | 0-conf acceptable (small loss risk) |
| Consumer electronics, gift cards | 1–3 confirmations |
| Real estate, cars, large transfers | 3–6+ confirmations |
| Exchange deposits | 3–6+ confirmations |
The larger and faster the payout, the more confirmations a Finney-class attack warrants.
Frequently Asked Questions
Q: Can a Finney attack happen on Ethereum? A: The mechanism is Bitcoin-specific (secret block withholding). Ethereum’s ~12-second blocks and finality model change the economics, but the broader lesson — don’t treat an unconfirmed transaction as final — applies to any chain.
Q: Is the Finney attacker guaranteed to profit? A: No. They only profit if they can defraud a merchant during the brief window before publishing their block. If not, they publish anyway and simply collect the normal block reward, losing only the time advantage.
Q: Does waiting for one confirmation stop it? A: Largely yes. After one confirmation, overriding the merchant’s payment requires reorganizing a confirmed block, which is a far more expensive majority-hash-power attack rather than a cheap Finney trick.