Transaction Replacement: RBF, Cancellations, and Fee Bumping

When your transaction sits unconfirmed in the mempool for hours, you're not helpless—you're holding a power most people don't know exists.

Replace-by-fee is one of those Bitcoin features that reveals something profound about how the network actually operates. It's not a bailout mechanism or a cheat code. It's an acknowledgment of economic reality, built into the protocol itself. When you broadcast a Bitcoin transaction, you're not issuing a command. You're making an offer. And like any offer in a competitive marketplace, you can sweeten the deal if your first bid isn't getting attention.

Let's start with the fundamental problem RBF solves. You send a transaction with what seems like a reasonable fee. Maybe you checked a fee estimator, maybe you eyeballed recent blocks, maybe you just went with your wallet's default. But the mempool is a living thing. It shifts. Suddenly there's a surge of activity—an NFT mint on a Bitcoin layer, a major exchange doing consolidation, whatever. Your transaction, which seemed adequately priced five minutes ago, is now buried under thousands of higher-paying transactions. Miners are rational actors. They're going to include transactions that pay them the most. Your payment is sitting there, valid but ignored, like an auction bid that's been outbid.

Without replace-by-fee, you'd just have to wait. And wait. Maybe your transaction confirms in the next block. Maybe it takes six hours. Maybe it takes three days. Maybe it eventually drops out of most mempools entirely and you have to rebroadcast, hoping conditions improve. That's not a broken system, exactly, but it's inflexible. RBF introduces agency.

Here's how it works mechanically. When you create a transaction, there's a field called sequence number in each input. Originally this was intended for something else entirely—Satoshi had this notion of payment channels way back, though it never worked quite as envisioned. The sequence number got repurposed. If you set it below the maximum value—specifically, below four billion two hundred ninety four million nine hundred sixty seven thousand two hundred ninety five, if we're being precise—you're signaling that this transaction is replaceable. That's it. That's the flag. It's opt-in. You're saying, I might change my mind about the terms here.

Once that signal is set, you can create a new version of the same transaction. Same inputs, but you're changing something. Usually you're increasing the fee. You might adjust the outputs—maybe taking a bit less of your own change output to fund the higher fee. You broadcast this new version. It has the same inputs as the original, which means both transactions are trying to spend the same coins. Only one can confirm. Nodes that receive your replacement will see the higher fee, recognize the RBF signal on the original, and accept the new one into their mempool, dropping the old one. Miners see a more profitable transaction and preferentially include it. Your payment accelerates.

Think of it like a silent auction where you can see you're losing and slide a revised bid across the table. The auctioneer isn't required to accept it, but when your new bid is better, why wouldn't they?

Now, this creates interesting patterns on chain and in mempools. One thing you'll see is chains of replacement. Someone broadcasts transaction A, then replaces it with B, then replaces B with C. Each step increases the fee by enough to be worth the relay. There's actually a rule about this—the replacement must pay more in absolute fees, not just a higher fee rate, and the increase must be enough to compensate for the bandwidth of relaying the new transaction. You can't just bump by one satoshi. The network has anti-spam protections.

You'll also see strategic behavior. Some users broadcast with deliberately low fees and RBF enabled, waiting to see if it confirms cheaply, knowing they can bump if needed. It's rational if you're not in a rush. Why overpay if you don't have to? You're essentially testing the market, ready to adjust.

The cancellation case is particularly interesting. Can you truly cancel a Bitcoin transaction? Not exactly, but you can make it irrelevant. If you want to cancel, what you actually do is replace the transaction with one that sends all the funds back to yourself. Same inputs, but instead of paying someone else, you're paying your own wallet, minus the fee. If this replacement confirms, the original payment never happens. The coins moved, but only in a circle. To the outside observer, it looks like you sent money to yourself with a weirdly high fee, but functionally, you've canceled the original intent. There's nuance here, though. The recipient might have already seen the original transaction. They might be watching. If they're depending on that payment, seeing it replaced with a self-send is going to raise questions. Reputation matters. This is useful for genuine mistakes, not for reversing debts you've decided you don't want to honor.

There's also a more aggressive form of replacement called full RBF, where nodes accept replacements even without the sequence signal. This is controversial. The original RBF is opt-in; the sender chooses to make their transaction replaceable. Full RBF says any transaction can be replaced if someone offers enough fee. Some node operators run this policy because they believe it reflects economic reality—miners will include higher-fee transactions regardless of signaling. Others argue it breaks a kind of social contract for users who specifically didn't opt in. As of now, most of the network still operates on opt-in RBF, but full RBF exists in pockets, and that matters. If even some miners use it, zero-confirmation transactions become even less trustworthy.

Which brings us to what this all means for receiving payments. If someone pays you and the transaction is unconfirmed with RBF enabled, you should not consider that payment final. They can replace it. Maybe they'll replace it with a higher fee version that still pays you—a bump. Or maybe they'll replace it with a version that doesn't pay you at all—a cancellation attempt. Until that transaction has confirmations, you're trusting, not verifying. For small casual payments this might be fine. For anything significant, wait for confirmations. This has always been true, but RBF makes it explicit.

On-chain, RBF leaves subtle traces. You might see the same inputs consumed in different transactions, but only one made it into a block. The others existed, were valid, were propagated, but were ultimately orphaned by the replacement that confirmed. Blockchain explorers sometimes show these if they were watching the mempool closely. It's a reminder that what we see on chain is the final state, not the full history of negotiation that happened in the mempool.

Transaction accelerators and fee bumping services use RBF under the hood, or they use CPFP—child pays for parent—which is a different technique where you spend an unconfirmed output with a high-fee transaction, incentivizing miners to include the parent. RBF is cleaner when you control the inputs. CPFP is useful when you're the recipient and want to speed up someone else's payment to you.

What RBF teaches us, beyond its technical utility, is that Bitcoin operates on incentives, not commands. Nothing is final until miners include it and the network builds on top. The mempool is a market. Your transaction is a bid. If your bid isn't competitive, you can revise it. The system doesn't care about your urgency or your intentions. It cares about the economics. RBF gives you a tool to participate in that market dynamically. It's not a bug that you might need to bump your fee. It's the system working as designed, revealing the price of block space in real time.

See you Tuesday.

The mempool is a negotiation, and your first offer doesn't have to be your last.