You sent the transaction two hours ago. The fee market moved while it sat there, unconfirmed, and now every block goes by without picking it up. You want to bump the fee. Whether you can depends entirely on a policy decision baked into software running on thousands of machines you don't control.

That's the Replace-by-Fee question.

Two Policies, One Mempool

Replace-by-Fee (RBF) lets a sender broadcast a second version of an unconfirmed transaction, spending the same inputs, at a higher fee. Miners, incentivised by fees, generally prefer the higher-paying version. The original gets evicted. Simple in theory. In practice, Bitcoin nodes don't all agree on which transactions they'll accept as replacements, and that disagreement is the whole story.

Opt-in RBF (codified in BIP 125) works like a permission slip. The original transaction signals replaceability by setting one of its input sequence numbers to 0xfffffffd or lower. Nodes following opt-in rules will only consider a replacement valid if that signal was present from the start. No signal, no replacement. The sender has to plan ahead.

Full RBF drops that requirement entirely. A node running full RBF policy will accept a higher-fee replacement for any unconfirmed transaction, regardless of whether the original opted in. The signal becomes irrelevant. Only the fee-rate threshold matters.

Those thresholds aren't arbitrary. Bitcoin Core's default rules require a replacement to pay a higher absolute fee than the transaction it displaces, and a fee rate at least 1 satoshi per virtual byte above the original. Both conditions must hold simultaneously. Miss either one and the replacement gets rejected at the policy layer before it ever reaches a miner.

What Actually Happens at the Node Level

Picture two nodes on the network: one running opt-in policy (the historical default), one running full RBF (enabled via the `-mempoolfullrbf=1` flag in Bitcoin Core, available since version 24.0).

Alice broadcasts an original transaction, 10,000 satoshis in fees, sequence number set to 0xffffffff. She deliberately did not opt in. She then broadcasts a replacement at 15,000 satoshis.

The opt-in node checks the original's sequence number, finds no signal, drops the replacement. From that node's perspective, the original is still valid. Alice's bump goes nowhere, at least through that node.

The full RBF node receives the same replacement. Does it pay more in absolute fees? Yes. Higher fee rate? Yes. It accepts the replacement, evicts the original, and relays the new version to its peers.

Now you have a split mempool. Different nodes hold different versions of Alice's transaction, like two referees calling the same play opposite ways and neither one blinking. Miners see whichever version their own node accepted. Whoever mines the block commits one version permanently. The other vanishes.

This is not a bug. It's the expected consequence of node-level policy diversity.

The Merchant Problem, Spelled Out

Opt-in RBF was introduced partly as a compromise with merchants who accepted zero-confirmation transactions. The logic: if a customer's transaction doesn't carry the opt-in signal, the merchant could treat it as unlikely to be replaced. Not guaranteed safe, but statistically safer than a signalled transaction.

Full RBF breaks that reasoning. If enough mining hashrate runs full RBF, the absence of an opt-in signal provides no meaningful assurance.

Consider a concrete scenario. A small online vendor, call him Marco, accepts zero-conf payments for digital downloads because his customers hate waiting. He checks that incoming transactions don't carry the opt-in signal and considers that sufficient. His node runs standard opt-in policy. His customer, who knows about full RBF nodes and has software to exploit them, sends a non-signalling transaction. Marco delivers the download. The customer then broadcasts a conflicting transaction at twice the fee rate through full-RBF-connected nodes. If miners pick it up before the original confirms, Marco is out the revenue entirely.

Marco's counterpart, a merchant who waits for one confirmation regardless, is unaffected by this debate. One confirmation is one confirmation. The RBF policy argument is exclusively about the zero-conf use case.

I'll say it plainly: zero-conf was always probabilistic, never guaranteed. Full RBF makes that probability worse for non-signalling transactions. Opt-in RBF made it slightly better, but it was never actually safe, and anyone who told merchants otherwise did them a disservice.

What Miners See, and Why Propagation Matters

Miners receive transactions through their node's mempool. If a miner's node runs opt-in policy, it may never see the replacement Alice tried to send. If it runs full RBF, it sees the higher-fee version and has obvious incentive to mine it.

So ask yourself: what happens as full RBF adoption grows among well-connected nodes, particularly those with direct peering to mining pools? The replacement reaches more miners. The effective difference between opt-in and full RBF collapses. At some adoption threshold, the opt-in signal becomes performative rather than functional, a courtesy wave that nobody's watching.

That threshold is genuinely unknown. No clean census of live node policies exists. Researchers probe it, estimates circulate, but the number shifts as operators upgrade software or flip flags. Any specific percentage quoted should be treated as a snapshot, not a constant.

One rule that is consistent across both policies: a replacement must not add new unconfirmed inputs that weren't in the original. This prevents a replacement from pulling in a fresh UTXO to cover the fee bump while expanding the transaction's mempool footprint in ways that complicate accounting. The rules exist to keep replacement economically rational for miners, not merely convenient for senders.

The Flag Is Not a Guarantee

Something operators get wrong: enabling `-mempoolfullrbf=1` on your node doesn't mean your replacement transactions will succeed. It means your node will accept and relay replacements for non-signalling transactions. Whether the replacement actually reaches enough miners to confirm depends on the rest of the network.

Running full RBF is, in practice, a bet on adoption. The more nodes and mining pools that run it, the more effective it becomes. The fewer that run it, the more isolated your node's behavior.

Opt-in RBF remains the default for a reason I find defensible: it's the conservative choice, preserving backward compatibility with software and workflows built around the original BIP 125 assumptions. Defaulting to the least disruptive option while the network figures out what it wants is not timidity. It's engineering.

The mempool has always been a policy battleground, not a protocol truth. What's confirmed is fact. Everything before that block is negotiation, and the terms keep changing.