Glossary

Finney Attack

A double-spend attack where a miner pre-mines a block containing a conflicting transaction and releases it after receiving goods.

Key Takeaways

  • A Finney attack is a double-spend technique where a miner pre-mines a block containing a self-paying transaction, spends the same coins at a merchant who accepts zero-confirmation transactions, then broadcasts the withheld block to invalidate the merchant's payment.
  • The attack requires the attacker to have mining capability, making it far more difficult than a simple race attack. No confirmed Finney attack has ever been documented in the wild.
  • Waiting for even a single block confirmation completely defeats this attack, which is one reason Layer 2 solutions like Lightning and Spark exist for instant settlement without zero-conf risk.

What Is a Finney Attack?

A Finney attack is a type of double-spend attack against Bitcoin merchants who accept unconfirmed transactions. Named after Hal Finney, one of Bitcoin's earliest contributors and the recipient of the first-ever Bitcoin transaction from Satoshi Nakamoto, this attack exploits the gap between when a transaction appears in the mempool and when it receives its first block confirmation.

Finney described this attack vector on the Bitcointalk forum in 2011, not to advocate for it, but to help the community understand why accepting zero-confirmation payments carries inherent risk. The attack demonstrates a fundamental property of proof-of-work blockchains: until a transaction is included in a confirmed block, it is not truly settled.

Unlike simpler double-spend methods, the Finney attack requires the attacker to be a miner (or have access to mining infrastructure). This requirement makes it significantly harder to execute but also makes it a more reliable attack against merchants who rely solely on mempool visibility as proof of payment.

How It Works

The Finney attack follows a precise sequence that exploits the time between block discovery and block propagation:

  1. The attacker, who controls mining hardware, creates a transaction sending coins from address A to address B (both controlled by the attacker). This transaction is never broadcast to the network.
  2. The attacker includes this A-to-B transaction in a block template and begins mining. Eventually, the attacker finds a valid block containing this transaction, but does not broadcast it.
  3. With the pre-mined block in hand, the attacker visits a merchant and creates a second transaction spending the same coins from address A to the merchant's address C.
  4. The merchant sees the A-to-C transaction in the mempool and, accepting it at zero confirmations, delivers the goods or service.
  5. Immediately after receiving the goods, the attacker broadcasts the pre-mined block containing the A-to-B transaction. The network accepts this valid block, and the merchant's A-to-C transaction becomes invalid because the coins were already spent.

The result: the attacker keeps both the goods and the cryptocurrency. The merchant is left with an invalidated transaction and no payment.

Why Mining Is Required

The Finney attack fundamentally depends on the ability to produce a valid block and control when it is broadcast. Only miners can do this. A non-mining user cannot create blocks, so they cannot withhold one for strategic release. This distinguishes the Finney attack from a race attack, where any user can attempt to broadcast two conflicting transactions simultaneously.

The attacker does not need majority hashrate. Even a miner with a small fraction of total network hashrate can attempt this attack whenever they happen to find a block. However, lower hashrate means longer waits between block discoveries and fewer opportunities to execute.

The Timing Constraint

The critical window for a Finney attack is the time between when the attacker finds their block and when the next honest miner finds a competing block. If another block is found and propagated first, the attacker's withheld block becomes stale (orphaned), and the attack fails. With Bitcoin's average block time of roughly 10 minutes, this window is probabilistic: the attacker must complete the merchant transaction before the next block arrives.

Attack timeline:

[Attacker finds block] ---> [Visit merchant] ---> [Receive goods] ---> [Broadcast block]
         |                                                                      |
         |<----------- Must complete before next honest block arrives ---------->|
         |                                                                      |
    Block withheld                                              Merchant payment invalidated

Probability of Success

Several factors determine whether a Finney attack succeeds:

  • Attacker hashrate percentage: a miner with 1% of total hashrate finds roughly 1 in 100 blocks. With 10%, roughly 1 in 10. Higher hashrate means more frequent opportunities.
  • Transaction speed: the attacker must complete the entire merchant interaction (payment, delivery) before the next block is mined by an honest miner. This favors digital goods or fast physical transactions.
  • Stale block risk: if the attack fails, the attacker loses the block reward (currently 3.125 BTC after the April 2024 halving). At current prices, this opportunity cost can exceed $200,000 per attempt.
  • Merchant confirmation policy: the attack only works against merchants accepting zero-confirmation transactions. Even one confirmation completely defeats it.

The economic calculus strongly discourages Finney attacks in practice. The cost of a failed attempt (a lost block reward worth hundreds of thousands of dollars) almost always exceeds the value of goods that can be obtained through the attack. This makes the attack irrational for any miner acting in economic self-interest.

Comparison with Other Double-Spend Attacks

The Finney attack is one of several double-spend strategies, each with different requirements and capabilities:

CharacteristicFinney AttackRace Attack51% Attack
Mining requiredYes (any amount)NoYes (>50% hashrate)
Target0-conf transactions0-conf transactionsConfirmed transactions
Defeated by 1 confirmationYesYesNo
DifficultyHighLowExtremely high
Cost of failureBlock reward lostNegligibleEnormous
ScopeSingle transactionSingle transactionMultiple transactions

A related variant called the Vector76 attack combines elements of both the Finney and race attacks. The attacker pre-mines a block (like a Finney attack) while also using network propagation tricks to achieve a double-spend against merchants who wait for one confirmation. This hybrid approach is even more complex to execute and carries additional risk of chain reorganization failure.

Countermeasures and Defenses

Merchants and payment processors can protect against Finney attacks through several strategies:

Wait for Confirmations

The most effective defense is the simplest: require at least one block confirmation before considering a payment final. A single confirmation means the transaction has been included in a block accepted by the network, making a Finney attack impossible. For high-value transactions, merchants commonly require 3 to 6 confirmations. For a deeper analysis of confirmation security thresholds at various attacker hashrate levels, see the research on zero-confirmation Bitcoin transactions.

Mempool Monitoring

Sophisticated payment processors monitor the mempool across multiple nodes in real time, watching for conflicting transactions that might indicate a double-spend attempt. While this cannot fully prevent a Finney attack (since the conflicting transaction is hidden inside an unmined block), it can detect race attacks and other suspicious patterns.

Reject RBF-Signaling Transactions

Transactions signaling Replace-by-Fee (RBF) explicitly allow replacement with a higher-fee version. Merchants accepting zero-conf should reject RBF-flagged transactions, as they are trivially replaceable. With full RBF now deployed in Bitcoin Core, this consideration has made merchants generally more cautious about zero-confirmation acceptance.

Value-Based Risk Assessment

The economics of a Finney attack make it irrational for low-value transactions. Risking a block reward worth over $200,000 to steal a $20 coffee makes no sense. Merchants can apply risk tiers: accept zero-conf for small purchases (where the attack cost vastly exceeds the gain) and require confirmations for higher-value sales.

Use Layer 2 for Instant Settlement

For merchants who need instant finality without waiting for block confirmations, Layer 2 solutions provide cryptographic settlement guarantees. The Lightning Network settles payments in seconds with cryptographic proof, eliminating zero-conf risk entirely. Spark extends this further by enabling instant settlement for both Bitcoin and stablecoins without the channel management overhead of Lightning. For an overview of these solutions, see the research on the state of the Lightning Network in 2026.

Has a Finney Attack Ever Succeeded?

No confirmed Finney attack has ever been documented on Bitcoin or any other major cryptocurrency. Multiple sources, including academic surveys of double-spend attacks, confirm that the attack remains purely theoretical. The combination of mining requirements, precise timing, high opportunity cost, and the declining prevalence of zero-conf acceptance makes it impractical.

The formal analysis in "Two Bitcoins at the Price of One? Double-Spending Attacks on Fast Payments in Bitcoin" (Karame et al., 2012) provided the most rigorous study of both race and Finney attacks, confirming the theoretical viability but practical difficulty of the approach.

Why It Matters Today

While the Finney attack poses minimal practical risk in 2026, it remains important as a conceptual foundation for understanding Bitcoin's security model:

  • It illustrates why confirmations exist and why unconfirmed transactions are not final.
  • It demonstrates the economic security model of proof-of-work: attacks have quantifiable costs that scale with the block reward and hashrate.
  • It motivates the development of Layer 2 protocols that provide instant finality without relying on zero-conf trust assumptions.
  • It helps developers and merchants make informed decisions about payment acceptance policies and confirmation requirements.

Bitcoin's hashrate has grown to over 800 EH/s, making individual mining increasingly difficult. Professional payment processors employ sophisticated risk analysis for the small number of use cases that still accept zero-conf. And for genuine instant payments, Layer 2 solutions have become the standard: the Lightning Network and protocols like Spark provide cryptographic settlement guarantees that eliminate double-spend risk entirely, without requiring any on-chain confirmations. For a deeper comparison of Bitcoin's transaction lifecycle and confirmation mechanics, see the Bitcoin transaction lifecycle explained.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.