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)

Under BIP 125’s original relay rules, a transaction had to be signaling RBF to be replaceable: it sets at least one input’s nSequence below 0xfffffffe, which flags “I may be replaced.” (Signaling matters less today: Bitcoin Core has defaulted to full RBF — relaying replacements even for non-signaling transactions — since v28 in 2024, 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.

The architect’s lens

Fee-bumping is a deliberate feature of treating a broadcast as a bid, not a commitment:

• Why does it exist? Because a broadcast transaction is a proposal in a fee market, not a settled action — RBF and CPFP exist so you can raise the effective fee rate of a stuck transaction and bid your way above the block’s cut line.
• What problem does it solve? Under-paid, stranded transactions. RBF (BIP 125) replaces a stuck tx with a higher-fee conflict spending the same inputs; CPFP lets a receiver attach a high-fee child so a miner must pull the parent in too (ancestor-package evaluation).
• What are the trade-offs? RBF makes the zero-conf double-spend trivial — a merchant who hands over goods on an unconfirmed payment can be robbed by a conflicting replacement — and the same primitives enable transaction pinning against time-sensitive Lightning transactions.
• When should I avoid it? Don’t lean on fee-bumping (or trust zero-conf) when settlement must be final now for something you can’t claw back — wait for confirmations, or use a different model like Lightning’s pre-signed penalty states.
• What breaks if I remove it? A stuck transaction would have no escape but to wait or be evicted — no way to participate in the fee auction after broadcast — and wallets lose the standard tool for un-sticking funds during congestion.

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?

Show answers

1. There’s no global queue — each node keeps its own mempool of valid-but-unconfirmed transactions, and miners independently fill a block with the highest fee-per-vbyte transactions first. Agreement comes from the confirmed chain, not from any shared pending list.
2. RBF (Replace-By-Fee). You broadcast a replacement that spends (at least one of) the same inputs but pays a higher fee, so it conflicts with the original — only one can confirm, and miners take the higher-fee one. It’s the clean fix because you’re editing your own proposal.
3. CPFP (Child-Pays-For-Parent). You spend an output of the stuck transaction in a new child that pays a high fee; since a child can only be mined after its parent, a miner who wants the juicy child fee must include the parent too. Miners evaluate the ancestor package as one blended fee rate.
4. At t+0 the attacker pays the merchant with a normal-fee, RBF-signaled transaction; the merchant sees it in the mempool and releases goods. Seconds later the attacker broadcasts a conflicting transaction spending the same input back to themselves at a higher fee. Miners prefer the higher-fee conflict, so the replacement confirms and the merchant’s payment becomes permanently invalid — goods gone, no coins.
5. Because a mempool transaction is only a proposal, not settled money — it can be replaced (RBF), out-raced, or Finney-attacked before it confirms. Seeing a transaction is not the same as it being final; agreement in Bitcoin is the confirmed chain, never the mempool, so wait for confirmations on anything you can’t claw back.