A conflict is observable before settlement, but a successful double-spend requires the victim to deliver value for one transaction while another wins the accepted chain history. A replaced wallet payment, an accidental fee bump and an unsuccessful conflict are therefore not automatically fraud. Risk differs sharply between zero-conf races and replacement of already confirmed blocks.
Every transaction input names a previous output by txid and output index. Two transactions conflict when at least one input names the same still-unspent outpoint but their transactions are not jointly valid. A node evaluating a block checks that each input exists and has not already been spent earlier in that chain history or elsewhere in the same block. Only one branch of the conflict can survive in a valid UTXO set; the attack is not duplication of satoshis but an attempt to make a recipient act on the losing branch. [Bitcoin whitepaper — Transactions, Timestamp Server and Calculations] [Bitcoin Developer Guide — Transactions] [Bitcoin Core — validation.cpp]
Before mining, there is no global mempool or consensus ordering. Peers can first receive different conflicts because of propagation, topology, fee policy, package state or eclipse/isolation, and a transaction absent from one mempool may exist in another. First-seen behavior is relay policy, not a promise that miners must confirm the first transaction. A merchant who sees a txid has evidence that one signed candidate reached its backend, not evidence that every node saw it or that it will win a block. [Bitcoin Developer Guide — Payment Processing] [Bitcoin Core — Mempool Replacements]
Replace-by-fee deliberately permits a node to replace mempool conflicts that satisfy its fee and anti-DoS rules; full-RBF became Bitcoin Core's default policy in version 28. A sender may use it legitimately to raise a stuck payment's fee while preserving the recipient output, or may redirect value. Consensus treats both candidates as ordinary transactions and accepts whichever valid history is mined. Thus an RBF signal, replacement or fee bump is not itself proof of fraud, while a non-signaling transaction is not safe for zero-conf acceptance. [Bitcoin Core — Mempool Replacements] [BIP 125 — Opt-in Full Replace-by-Fee]
In a race attack, a spender sends one transaction to the merchant and a conflicting transaction toward miners or other peers, hoping the merchant releases irreversible goods before a block chooses the conflict. Success depends on propagation, the merchant's network view, miner selection and delivery timing; multiple listening nodes may improve detection but cannot create deterministic finality. The labels race, Finney and Vector76 describe threat scenarios, not transaction fields or separate consensus rules. [Bitcoin Developer Guide — Payment Processing] [Karame et al. — Misbehavior in Bitcoin]
A Finney-style attacker with mining capability first mines privately a block containing the self-paying conflict, then offers the same UTXO to a merchant as a zero-conf payment and publishes the withheld block after receiving goods. The attack only works if the private block remains usable and becomes accepted before an honest competing block invalidates the plan, so it sacrifices or risks mining revenue. Waiting for the merchant payment to enter a validated block defeats the classic zero-conf sequence, though later chain-rewrite risk remains. [Bitcoin whitepaper — Transactions, Timestamp Server and Calculations] [Karame et al. — Misbehavior in Bitcoin]
After a payment is confirmed, a competing transaction cannot merely replace it in mempools: an alternative valid branch must omit the payment, include the conflict and accumulate more chainwork than the recipient's active chain. A reorganization can also arise without fraud from near-simultaneous blocks or software/network incidents; only if someone gains value by making the conflicting spend win is it a successful double-spend against that victim. Wallets may show negative confirmations and walletconflicts when the winning chain confirms the alternative. [Bitcoin Core — Validation] [Bitcoin Core — validation.cpp] [Bitcoin Core RPC — gettransaction]
An attacker's hashrate share, the number of confirmations and the value recoverable determine the stochastic race between private and honest work. Less than 50% does not mean zero probability; sustained majority hashrate makes catching up increasingly likely but does not let miners forge signatures, spend arbitrary UTXOs, exceed issuance rules or make invalid blocks acceptable to full nodes. Costs include hashpower, energy, foregone honest rewards, block-race risk, liquidity and detection; revenue may include the reversed payment and market positions, so simple rental-price estimates are incomplete. [Bitcoin whitepaper — Transactions, Timestamp Server and Calculations] [Rosenfeld — Analysis of Hashrate-Based Double Spending] [Garay, Kiayias and Leonardos — The Bitcoin Backbone Protocol]
Additional confirmations force a replacement branch to redo more accumulated work and generally lower success probability under the model's assumptions. There is no universal safe number: a coffee, car, exchange deposit and irreversible cross-border withdrawal expose different values, attacker incentives and recovery options. The often-quoted six confirmations is a convention, not consensus. A policy should also account for current hashrate distribution, unusual reorgs, backend trust, eclipse risk and whether delivery can be delayed or reversed. [Bitcoin Developer Guide — Payment Processing] [Rosenfeld — Analysis of Hashrate-Based Double Spending]
A backend can watch its own full node for conflicting mempool spends, use gettxspendingprevout, track walletconflicts, compare the active tip and alert on confirmation loss. Extra peers or independent nodes reduce blind spots, but absence of a detected conflict is weak evidence because an attacker can withhold it or route it elsewhere. Explorers share their own node view and can lag. Detection helps a merchant stop delivery; it cannot force miners to choose the merchant's transaction or make zero-conf equivalent to confirmation. [Bitcoin Core RPC — gettransaction] [Bitcoin Core RPC — gettxspendingprevout] [Karame et al. — Misbehavior in Bitcoin]
For onchain settlement, validate with a controlled full node, bind the order to the exact txid, outputs and amount, require a depth proportional to loss, pause on reorg or conflict and separate credited balance from withdrawable balance. Avoid treating an unconfirmed change descendant as independent of its parent. Lightning addresses fast recurring payments differently: a confirmed funding outpoint anchors a channel and revocation/penalty or modern commitment rules govern offchain state; zero-conf channels deliberately trust the funder and do not eliminate the underlying funding double-spend risk. [BOLT 2 — Peer Protocol] [Bitcoin Optech — Zero-conf channels]
For the clearest picture, read this entry together with Transaction, Confirmation, Mempool, Proof of Work, Replace-by-Fee (RBF), Bitcoin. The reverse links also lead from Confirmation, Replace-by-Fee (RBF), Byzantine Generals Problem, Eclipse attack.