RBF, CPFP & the Zero-Confirmation Myth

A transaction you broadcast is not a committed action. It’s a proposal sitting in miners’ mempools, competing for block space against everyone else’s proposals. If you under-paid the fee, it can sit there for hours or days — or fall out of mempools entirely. This page covers the two tools for rescuing a stuck transaction, and the dangerous myth that grows in the gap before confirmation.

First principle: the mempool is a fee market

There is no global queue. Each node keeps its own mempool of valid-but-unconfirmed transactions. Miners are economically rational: they fill the ~4 million weight units of a block with the transactions paying the most fee per virtual byte (sat/vB), highest first. (We cover vbytes and weight in the UTXO-set page and SegWit accounting.)

mempool, sorted by fee-rate (sat/vB):
  ███████████ 120  ─┐
  ████████     80   ├─ included in the next block (top of the market)
  █████        45  ─┘
  ── block boundary ──
  ██           18   ← waits
  █             3   ← may wait days, or be evicted

If your transaction is below the cut line, it waits. To move it up, you must somehow raise the effective fee rate. There are exactly two ways.

Tool 1 — Replace-By-Fee (RBF, BIP 125)

RBF replaces a stuck transaction with a new one that pays a higher fee. The replacement spends (at least one of) the same inputs, so it conflicts with the original — only one can ever confirm.

Original:   spend UTXO_A → pays 3 sat/vB     (stuck)
Replacement: spend UTXO_A → pays 50 sat/vB    (conflicts; this one wins)

A transaction must be signaling RBF to be replaceable under standard relay rules: it sets at least one input’s nSequence below 0xfffffffe, which flags “I may be replaced.” (Modern wallets increasingly do full RBF, replacing even non-signaling transactions, because miners can always choose the higher-fee conflict regardless of the flag.)

BIP 125 imposes rules so replacement can’t be used to spam the network for free — notably the replacement must pay a higher absolute fee and cover the relay cost of everything it evicts.

Use RBF when: you are the sender and you control the inputs. It’s the cleaner, cheaper fix — you’re editing your own proposal.

Tool 2 — Child-Pays-For-Parent (CPFP)

What if you’re the receiver of a stuck transaction? You didn’t create it, so you can’t replace it. But you can spend its output in a new transaction (the child) that pays a high fee — and since a child can only be mined after its parent, a miner who wants the juicy child fee must include the parent too.

   Parent (3 sat/vB, stuck)  ──►  output you control
                                        │
                                        ▼
   Child (spends that output, pays 150 sat/vB)
   ───────────────────────────────────────────
   Miner evaluates the PACKAGE:
     combined fee ÷ combined size = attractive  → mines parent + child together

Miners evaluate ancestor packages, so they see the parent+child as one bundle with a blended fee rate. The child effectively “drags” the parent into a block.

Use CPFP when: you can’t replace the transaction (you didn’t make it, or it wasn’t RBF-signaling) but you can spend one of its outputs.

Quick decision guide

• I sent it, it has an unspent change output → RBF (replace it).
• I’m receiving it / can’t replace it, but I can spend an output → CPFP (push it from below).
• A common professional move: wallets attach a small anchor output specifically so CPFP is always possible later. Lightning’s modern commitment transactions do exactly this.

The zero-confirmation myth

Now the dangerous part. Because there’s a gap between broadcast and confirmed, merchants are tempted to accept a payment the moment they see it in the mempool — “zero-conf.” It feels fine: the transaction is right there, signed and valid. It is not safe, and RBF makes the risk explicit rather than theoretical.

Scenario — the coffee-shop double-spend

t+0s   Attacker pays the shop 0.01 BTC, RBF-signaled, normal fee. Shop sees it, hands over coffee.
t+5s   Attacker broadcasts a CONFLICTING tx: same input, 0 to the shop,
       0.01 BTC back to themselves, higher fee.
t+10m  Miners prefer the higher-fee conflict. The replacement confirms.
       The shop's payment is now permanently invalid. Coffee gone, no coins.

The attacker never broke any rule. They used a normal, supported feature (RBF) exactly as designed. The shop’s mistake was treating an unconfirmed proposal as settled money.

Even without RBF, zero-conf was never safe — a Finney attack or a race attack (covered in Famous incidents & attacks) achieves the same double-spend. RBF just makes it trivial.

Rule of thumb

Seeing a transaction is not the same as it being final. Each confirmation makes reversal exponentially more expensive (see Satoshi’s synthesis). For small in-person amounts some merchants accept the risk knowingly; for anything you can’t claw back (shipping goods, selling for cash, crediting another account), wait for confirmations.

So how does Lightning do instant payments safely?

It doesn’t rely on zero-conf. Lightning makes payments final off-chain using pre-signed, penalty-enforced channel states — a fundamentally different settlement model than “trust the mempool.” That’s the subject of timelocks & HTLCs.

A second-order weapon: transaction pinning

RBF and CPFP can be turned against a victim. Pinning is an attack where an adversary deliberately attaches a large, low-fee child to a shared transaction so that the rules (e.g. BIP 125 limits, or package size limits) make it expensive or impossible for the honest party to fee-bump in time. This is a live threat to Lightning, where time-sensitive transactions must confirm before a timelock expires. We cover it in Famous incidents & attacks.

The thread

How does this help untrusting strangers agree on one ledger? The fee market is the mechanism that rations the scarce resource (block space) without a central scheduler — strangers bid, miners sort by price. RBF/CPFP are how you participate in that auction after the fact. And the zero-conf myth is the reminder that “agreement” in Bitcoin is the confirmed chain, never the mempool.

Check your understanding

1. Why is there no single global queue of pending transactions?
2. You’re the sender of a stuck, RBF-signaled transaction. Which tool do you reach for, and what makes it work?
3. You’re the receiver of a stuck transaction you can’t replace. Which tool, and why does a miner cooperate?
4. Walk through how an attacker double-spends a zero-conf payment using RBF, step by step.
5. Why is “I can see the transaction in my node’s mempool” not a safe basis for releasing goods?