Zero-Conf Bitcoin: The Complete Guide to Unconfirmed Transactions
Everything you need to know about 0-conf on Bitcoin: how unconfirmed transactions work, the double-spend problem, RBF, and why accepting transactions before confirmation is both possible and risky.
Zero-confirmation (0-conf) refers to accepting a Bitcoin transaction as valid before it has been included in a block. When someone sends you Bitcoin, the transaction enters the mempool, a waiting area for unconfirmed transactions. It only becomes "confirmed" when a miner includes it in a block and adds that block to the blockchain.
Standard advice recommends waiting for confirmations. One confirmation averages 10 minutes; for larger amounts, merchants typically wait 3 to 6 confirmations (30 minutes to an hour). 0-conf means skipping this wait. The transaction is in the mempool and visible, but not yet mined. This is faster but introduces risk.
How Bitcoin Transactions Work
1. Transaction creation
A sender creates a transaction that references their unspent transaction outputs (UTXOs) as inputs, specifies the recipient address(es), amount(s), and a fee for the miner. The sender signs this transaction with their private key.
2. Broadcast to the network
The signed transaction is broadcast to the Bitcoin network. Nodes receive it, validate it (checking signatures and ensuring inputs are unspent), and propagate it to other nodes. Within seconds, the transaction reaches most of the network.
3. Waiting in the mempool
Valid transactions sit in the mempool until a miner picks them up. Miners prioritize transactions with higher fees. During congestion, low-fee transactions can wait hours or days. During quiet periods, even low-fee transactions get confirmed in the next block.
4. Confirmation
A miner creates a block containing your transaction, solves the proof-of-work puzzle, and broadcasts the block. Now your transaction has one confirmation. Each subsequent block adds another confirmation, making the transaction progressively harder to reverse.
Why confirmations matter: With each confirmation, reversing a transaction becomes exponentially more expensive. After 6 confirmations (roughly an hour), an attacker would need to outpace the entire network's hashrate to rewrite history. For most purposes, this is considered final.
The Double-Spend Problem
The risk with 0-conf is the double-spend attack. Here is how it works:
- An attacker sends Bitcoin to a merchant (Transaction A)
- The merchant sees Transaction A in their mempool and delivers goods or services
- The attacker broadcasts a conflicting transaction (Transaction B) that spends the same inputs but sends the Bitcoin elsewhere
- If Transaction B gets mined instead of Transaction A, the merchant loses their payment
This is not theoretical. Double-spend attacks have occurred in the wild, particularly against merchants accepting 0-conf for physical goods or services.
The race attack
In a race attack, the attacker broadcasts two conflicting transactions simultaneously: one to the merchant and one to miners. If the miner receives the attacker's preferred transaction first, the merchant loses.
The Finney attack
Named after Bitcoin pioneer Hal Finney, this attack requires the attacker to be a miner (or collaborate with one). The attacker pre-mines a block containing a transaction that sends coins back to themselves. They then spend those same coins at a merchant, wait for the goods, and immediately broadcast their pre-mined block to invalidate the merchant's transaction.
Double-spend success rates
Studies have shown varying success rates for double-spend attacks. A 2014 study found that race attacks succeeded about 25% of the time against unprepared merchants. With better propagation and monitoring, success rates dropped. Today, a well-connected node sees the first transaction within seconds and will reject the conflicting one, making simple race attacks harder.
But harder does not mean impossible.
Replace-by-Fee (RBF)
In 2016, Bitcoin Core introduced BIP 125: Replace-by-Fee. RBF allows a sender to replace an unconfirmed transaction with a new one that pays a higher fee. The intent was to help users unstick transactions during fee spikes.
The impact on 0-conf was significant.
Opt-in RBF
Initially, RBF was opt-in. A transaction signaled RBF capability by setting a specific sequence number on its inputs. Merchants could detect this flag and refuse to accept RBF-signaling transactions at 0-conf, since the sender explicitly reserved the right to replace them.
Full RBF
In 2022, Bitcoin Core added support for "full RBF" (mempoolfullrbf), which allows nodes to accept replacements for any transaction, regardless of whether it signaled RBF. As of 2023-2024, a growing percentage of the network runs full RBF. This makes detecting "safe" 0-conf transactions harder, since even transactions that did not signal RBF can now be replaced by a sufficiently motivated attacker who finds a node willing to relay the replacement.
Full RBF changes the game: With full RBF gaining adoption, the assumption that non-RBF-signaling transactions are "safe" to accept at 0-conf is weakening. Any unconfirmed transaction can potentially be replaced.
A Brief History of 0-Conf
0-conf has been debated since Bitcoin's early days.
Satoshi's view
In a 2010 forum post, Satoshi Nakamoto described a scenario for accepting 0-conf payments at a vending machine, suggesting that for small amounts, the risk was acceptable:
"I believe it will be possible for a payment processing company to provide as a service the rapid distribution of transactions with good-enough checking in something like 10 seconds or less."
Satoshi Nakamoto, Bitcoin creator, 2010
Satoshi envisioned that for small, time-sensitive payments, specialized services could monitor the network and provide assurance quickly enough for practical use.
Early adoption
In Bitcoin's early years, many merchants accepted 0-conf for small purchases. Transaction volume was low, fees were negligible, and the attack surface was small. Coffee shops and online merchants experimented with instant Bitcoin payments.
Growing skepticism
As Bitcoin's value grew, so did the incentive for attacks. High-profile double-spends, the introduction of RBF, and increased mempool congestion made 0-conf riskier. Many payment processors moved to requiring at least one confirmation, or stopped accepting on-chain Bitcoin entirely in favor of custodial solutions.
The Layer 2 era
Lightning Network and other Layer 2 solutions emerged partly to solve the confirmation delay problem. Lightning payments settle in milliseconds, providing the instant finality that 0-conf could not reliably offer on L1, though they introduce their own complexity around channel liquidity management. Newer protocols like Spark eliminate channels entirely. Today, most instant Bitcoin payments happen on Layer 2 protocols rather than relying on 0-conf at the base layer.
When 0-Conf Makes Sense
Despite the risks, 0-conf can be practical in specific scenarios:
Small amounts
If the transaction value is small, the cost of executing a double-spend attack may exceed the benefit. Paying $5 in Bitcoin for a coffee is probably safe at 0-conf, because few attackers will orchestrate an attack for $5.
Trusted senders
When you know and trust the sender, 0-conf is safer. An exchange withdrawing to your wallet is unlikely to double-spend you. A verified customer with a reputation at stake is lower risk than an anonymous counterparty.
High-fee transactions
Transactions with high fees are likely to be included in the next block. If a sender paid a significant fee, they are signaling intent to confirm quickly. Replacing such a transaction would require paying an even higher fee.
Digital goods with recourse
If you are delivering digital goods and can revoke access, 0-conf risk is manageable. Accept the payment, deliver the goods, and revoke if the transaction fails to confirm. This works for subscriptions, software licenses, and similar products.
| Scenario | 0-Conf Risk Level | Notes |
|---|---|---|
| $5 coffee, anonymous customer | Low | Attack cost exceeds value |
| $50 meal, known customer | Low | Trusted sender, small amount |
| $500 electronics, anonymous | High | Attractive target, physical goods |
| $5000 exchange deposit | Very High | Large amount, strong attack incentive |
| Digital subscription, any amount | Medium | Revocable if double-spent |
Risk Mitigation Strategies
If you choose to accept 0-conf, several strategies can reduce risk:
Real-time mempool monitoring
Run a well-connected Bitcoin node that sees transactions quickly. Monitor for conflicting transactions. If you detect a double-spend attempt (two transactions spending the same inputs), reject the transaction immediately.
Propagation analysis
Analyze how quickly and widely the transaction propagated across the network. A transaction seen by many nodes quickly is harder to replace than one seen by few. Services like mempool.space provide visibility into transaction propagation.
Fee analysis
Check if the transaction pays an adequate fee for current mempool conditions. A transaction paying 10x the minimum fee is more likely to confirm and less likely to be replaced.
Velocity limits
Limit the total value of 0-conf transactions you accept within a time window. If you accept $100 of 0-conf transactions per hour, your maximum loss is capped even if every transaction is a double-spend.
Tiered acceptance
Implement different policies for different amounts. Accept 0-conf instantly for transactions under $20, require 1 confirmation for $20 to $200, and require 3 confirmations for larger amounts.
The Trust Spectrum
Bitcoin's confirmation model exists on a spectrum of trust and finality:
| State | Finality | Trust Required | Use Case |
|---|---|---|---|
| 0-conf (mempool) | None | High trust in sender | Coffee, small retail |
| 1 confirmation | Probabilistic | Moderate | Medium transactions |
| 3 confirmations | Strong | Low | Larger purchases |
| 6 confirmations | Very strong | Minimal | Exchanges, high-value |
| 100+ confirmations | Essentially final | None | Settlement, cold storage |
The right choice depends on your risk tolerance, the value at stake, and the relationship with the counterparty. There is no universally correct answer.
Modern Solutions
Several approaches have emerged to provide instant Bitcoin payments without the risks of raw 0-conf:
Lightning Network
Lightning provides instant, final payments through payment channels. Once a Lightning payment completes, it is irrevocable. No confirmation wait, no double-spend risk. The tradeoff is the need to maintain channels and liquidity.
Custodial payment rails
Services like exchanges and payment processors can provide instant internal transfers by updating database balances rather than on-chain transactions. When both parties use the same custodian, payments settle instantly. The tradeoff is custodial risk.
Liquidity provider fronting
A newer approach: liquidity providers evaluate incoming transactions and front the value immediately if the transaction meets their risk criteria. The LP absorbs the double-spend risk in exchange for a fee or strategic benefit. Users get instant availability while maintaining self-custody of the resulting funds.
Layer 2 protocols
Beyond Lightning, various Layer 2 solutions offer instant settlement while inheriting Bitcoin's security model. Spark, for example, uses a statechain model with Schnorr-based threshold signatures to enable instant transfers without channels. These protocols move frequent transactions off-chain while preserving the ability to settle to Bitcoin L1 if needed.
Spark's approach: Spark is exploring a solution that combines mempool monitoring, risk scoring, and LP fronting to enable instant Bitcoin deposits that become immediately spendable on a Bitcoin Layer 2. If you are interested in instant Bitcoin settlement, reach out to learn more.
The Bottom Line
0-conf on Bitcoin is a tradeoff between speed and security. In the early days, it was common practice. Today, with RBF, higher values, and more sophisticated attackers, the risks are better understood.
For small transactions with trusted senders, 0-conf can still make sense. For larger amounts or anonymous counterparties, waiting for confirmations remains the safer choice.
The future of instant Bitcoin payments likely lies not in better 0-conf risk management at L1, but in Layer 2 solutions that provide true instant finality. Lightning, Spark, and other protocols are building toward a world where you do not have to choose between speed and security.
This article is for educational purposes only. It does not constitute financial or security advice. Always do your own research before accepting unconfirmed Bitcoin transactions.