Double spending does not mean creating new bitcoins. A sender produces two transactions trying to spend at least one shared source of previously received funds. Both can circulate, but both cannot be valid in the same history. Accepting payment without confirmation, or zero-conf, means acting before it is clear which version will prevail.
Suppose Tom has one previously received output worth 100,000 sat, the smallest units of bitcoin. Such an unspent output is called a UTXO. He prepares a payment sending Alice 99,000 sat and leaving 1,000 sat as a fee. He could also sign a different transaction spending that same UTXO and sending the money elsewhere. Both refer to the same source of funds, so they conflict. It is not like copying a file: a Bitcoin node, a computer checking the rules, will not allow the same output to be spent twice in one valid chain. Fraud would succeed if Alice handed over goods for the first payment but the accepted history ultimately contained the second. The attack does not create a copy of satoshis; Alice relied on the losing version. Technically, each input refers to a previous output by its transaction identifier, txid, and output number. Together these form an outpoint. [1] [3] [7]
Alice may see an incoming payment within seconds. That does not mean it has been recorded in a block. A Mempool is a node’s local store of unconfirmed transactions; there is no global Mempool or consensus-defined order in which all Bitcoin nodes receive them. Another node may have received the conflicting version first or not yet seen Alice’s version at all. A first-seen policy favors the first version received when relaying transactions. It is not a promise that miners will put it in a block. A wallet screenshot or txid alone therefore does not prove settlement. What matters is the specific payment’s state in a reliably verified chain. [2] [5]
Alice might instead be sending an honest payment that has been waiting for a long time. Replace-by-Fee (RBF) allows an unconfirmed transaction to be replaced, usually by one paying a higher fee. The recipient may still receive the same amount even though the txid changes. The replacement uses at least some of the same funds, so it technically conflicts with the original without anyone trying to cheat the recipient. What matters is the replacement’s content and circumstances, not the RBF label alone: transaction replacement and a fee increase do not prove fraud. The same mechanism can, however, redirect funds elsewhere. Full-RBF has been the default rule in Bitcoin Core since version 28; it does not require the original transaction to signal replaceability. Replacements still have to meet the node’s fee and anti-abuse rules. A lack of RBF signaling therefore does not make an unconfirmed payment irreversible. [5] [6] [15]
A payment gains a confirmation when it enters a valid block accepted by a node. Later blocks usually make replacing that history harder, reducing the risk of successful fraud. There is no safe count for every situation, however. Losing a coffee payment differs from handing over a car or releasing a large exchange withdrawal. The often-cited six confirmations are a convention, not a Bitcoin rule. Recipients should consider value, possible remedies, unusual chain behavior and the quality of their information source. Isolating a node, known as an Eclipse Attack, can distort its network view. Waiting therefore belongs alongside verification, not in place of it. [2] [10]
A node switching to another valid branch is called a reorganization. Proof of Work demonstrates the work required to produce blocks; a branch’s accumulated work is called chainwork. After confirmation, a conflicting transaction can no longer simply displace the payment from the Mempool. An alternative valid branch must omit the original payment, include the second spend and accumulate more work, known as chainwork, than the recipient’s active chain. A chain reorganization can also occur without fraud, for example when blocks are mined almost simultaneously or software or the network fails. A double-spend against the victim succeeds only when the attacker gains value because the conflicting transaction wins. For the losing wallet transaction, Bitcoin Core may display a negative confirmation count in confirmations and related conflicts in walletconflicts. [4] [7] [8]
Hashrate is the rate of computation during mining. A greater share can help in a race over history, but grants no exemption from other rules. The chance of a privately mined branch catching up with the honest chain depends, among other things, on the attacker’s share of the network’s computing power and the number of confirmations. The value the attacker could gain mainly affects whether the attack is worthwhile. A share below 50% does not mean no chance of success; a sustained majority greatly increases the chance of catching the other branch. Even a majority does not let miners forge signatures, spend other people’s UTXOs, break issuance rules or force full nodes to accept an invalid block. Assessing an attack means accounting for computing power, energy and the rewards forgone by not mining honestly. Available capital, the risk of failure and the possibility of being detected also matter. Returns can also include gains from financial market positions, so the cost of renting mining equipment alone is not enough for an estimate. [1] [10] [12]
Race here means a contest of timing: the recipient and miners may see different transactions first. In a race attack, the payer sends one transaction to the merchant and a conflicting transaction to miners or other nodes. The aim is to make the merchant hand over goods irreversibly before a block selects one version. The outcome depends on transaction propagation, the merchant’s view of the network, miners’ selection and the time of delivery. More independent nodes monitoring the network improve conflict detection but cannot guarantee irreversible settlement. The names race, Finney and Vector76 describe attack scenarios, not transaction data fields or different consensus rules. [2] [11]
A Finney attack is a named scenario in which the attacker controls mining as well as payments. It is not a wallet’s ordinary fee-bumping behavior. In a Finney attack, an attacker with mining capability first mines a block privately containing a conflicting transaction that returns the value to the attacker. The attacker then uses the same UTXO to pay a merchant who accepts payments without confirmation and publishes the hidden block after receiving the goods. The plan succeeds only if the block remains usable and the network accepts it before an honest competing block defeats the preparation. The attacker therefore risks the block reward and mining costs. Waiting for the merchant’s transaction to enter a validated block interrupts this classic sequence but does not remove the risk of a later chain reorganization. [1] [11]
RPC is a node’s programmatic interface. The names below are specific commands and fields for payment-system developers, not another kind of confirmation. The merchant’s system can use its own full node to monitor conflicting spends in the Mempool, call gettxspendingprevout, read walletconflicts, compare the latest block of the active chain and warn of lost confirmations. More connected or independent nodes reduce blind spots, but the absence of a detected conflict is weak evidence of safety: an attacker can withhold the conflicting transaction or send it elsewhere. A block explorer shows its own node’s view and may lag. Detecting a conflict allows the merchant to stop delivery. It cannot force miners to choose a particular transaction or make an unconfirmed payment equivalent to a confirmed one. [8] [9] [11]
As a recipient, check the actual incoming payment, its destination, amount and confirmations. A receipt supplied by the sender cannot replace that. Your own full node lets you verify the rules directly; if you use a service, understand whose information and custody you rely on. A merchant system should connect an order to specific outputs and track replacements too. A conflict or lost confirmations should pause irreversible delivery. A later payment spending unconfirmed change depends on the original transaction; it is not independent proof that the first payment is safe. Lightning Network enables fast payments through channels funded by Bitcoin transactions. Channel participants exchange signed commitment transactions that record how the funds are divided. When updating the channel, they give the other party secret data that enables a penalty if they later publish an outdated state; this invalidation of the old state is called revocation. Protection depends on detecting and responding to such an attempt in time. This is a different mechanism from handing over goods for an unconfirmed blockchain transfer. A channel opened without confirmation, a zero-conf channel, deliberately trusts its funder and does not remove the risk of double-spending that funding. [13] [14]
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, Reorg, Stale Block, Replace-by-Fee (RBF).