• Understanding Bitcoin’s RBF Policy: Why Replace-by-Fee Is Actually Good for Users
  • What RBF Actually Does
  • The Legitimate Use Case: Fee Jumping
  • The “Fraud” Claim Is Wrong
  • The Full RBF Replaceability Spectrum
  • Key Takeaways

§Understanding Bitcoin’s RBF Policy: Why Replace-by-Fee Is Actually Good for Users

Replace-by-fee (RBF) is one of Bitcoin’s more misunderstood features. Critics often claim it enables fraud — paying with Bitcoin and then replacing the transaction to pay less. In practice, RBF is a critical tool for efficient fee markets and user sovereignty. Here’s the accurate picture.

§What RBF Actually Does

When you broadcast a Bitcoin transaction, it goes into the mempool as “unconfirmed.” Under normal Bitcoin rules, once broadcast, the transaction is final — you can’t replace it with a different transaction spending the same inputs.

RBF changes this: with RBF enabled, your wallet can broadcast a replacement transaction that spends the same inputs but with a higher fee. Miners will优先 pick the higher-fee transaction, and the original becomes invalid.

This sounds like a problem. It isn’t, for two reasons: (1) you can only replace transactions you created, and (2) the replacement must pay a higher fee, so it’s economically motivated only by urgency.

§The Legitimate Use Case: Fee Jumping

The most common legitimate use: you broadcast a transaction during low fees, but the mempool gets congested and your transaction is stuck. With RBF, you can broadcast a replacement with a higher fee — no need to wait for it to expire or have the recipient refund you.

Without RBF, the options are worse: wait for the transaction to confirm (could be days), ask the recipient to initiate a refund (complicated), or use a “child pays for parent” transaction (expensive).

RBF is the clean solution to fee estimation uncertainty.

§The “Fraud” Claim Is Wrong

The fraud scenario goes: “Alice buys coffee, pays with Bitcoin, then RBF to send the BTC to herself instead, effectively stealing the coffee.”

Why this doesn’t work: the merchant’s wallet can require RBF to be disabled as a condition of accepting payment. Most merchant payment processors do this. If you send a non-RBF transaction to a merchant, it can’t be replaced. The transaction is either confirmed or invalid — no middle ground.

Additionally, merchants typically wait for 1-6 confirmations before delivering high-value goods. By the time a fraudulent RBF would matter, the original transaction is already in a block.

§The Full RBF Replaceability Spectrum

Bitcoin Core’s RBF policy is more nuanced than simple replace/not replace:

• Full RBF (BIP 125): any transaction signaling RBF can be replaced
• First-Seen-Safe (FSS) RBF: can only replace your own transactions if the replacement pays at least as much to the original recipients
• Opt-in RBF: the sender signals RBF willingness, but nodes can choose whether to honor it

Most wallets use opt-in BIP 125 signaling, which means the fraud scenario requires both the sender’s wallet to support RBF and the receiving node to honor the replacement signal.

§Key Takeaways

• RBF lets users replace stuck transactions with higher-fee versions — a legitimate and important tool
• The “pay and replace” fraud requires merchant to accept RBF transactions and not wait for confirmation
• High-value merchant transactions almost universally require zero-RBF and confirmations before delivery
• RBF enables more efficient fee markets: users don’t need to overpay to ensure confirmation
• The controversy is mostly theoretical — practical fraud via RBF is extremely rare

⚡ If this was useful, a zap is always welcome. tomford@rizful.com