Why Your Replacement Transaction Gets Accepted by Some Nodes and Rejected by Others

You broadcast a transaction. Fee felt fine. Then the network fills up, an hour ticks by, and you fire off a higher-fee replacement, watching your wallet cycle through statuses that don't quite agree with each other. Some nodes took it. Others didn't. You're staring at the screen wondering if the mempool is broken.

It isn't. There's just no single rulebook.

The Mempool Is Not a Shared Database

This surprises people who picture Bitcoin as one unified system. The mempool, short for memory pool, is the holding area where unconfirmed transactions wait for a miner to pack them into a block. Every node maintains its own, locally, in RAM. No central mempool exists. Tens of thousands of independent ones do, each running on whatever policy rules ship with that node's software version.

When your wallet says a transaction is "in the mempool," it means some nodes have it. Possibly most. But not all, and certainly not under identical rules about what happens next.

Replace-by-Fee: The Basic Mechanic

Bitcoin's consensus rules say nothing about transaction replacement. That's a policy layer, not a protocol layer. The idea behind Replace-by-Fee (RBF) is simple: if a higher-fee version of a transaction spending the same inputs arrives, a node can evict the original and hold the replacement instead. Miners prefer higher fees; the network benefits from honest fee signaling. Clean in theory.

Bitcoin Core, the reference implementation, introduced opt-in RBF via BIP 125. The rules it enforces are specific:

  1. The replacement must signal replaceability (sequence number below 0xFFFFFFFE on at least one input).
  2. It must pay a higher absolute fee than the original.
  3. It must increase the fee rate by at least the minimum relay fee, 1 sat/vbyte by default.
  4. It cannot add more than 100 new unconfirmed ancestors.
  5. It must not evict more than 100 transactions total from the mempool.

Fail any one of those five and Bitcoin Core rejects the replacement. Silently. Your wallet may not explain why.

Here's a concrete scenario. Alice broadcasts a transaction spending a UTXO: 200 satoshis in total fees, 2 sat/vbyte, 100 vbytes, RBF signal set. Network congests. She bumps to 500 satoshis total, 5 sat/vbyte. Bitcoin Core nodes accept it: absolute fee up (200 to 500), fee rate up by more than 1 sat/vbyte, signal present. The original is evicted.

Bob, same wallet, same day, forgot to enable RBF signaling. His replacement fails at rule one. Full stop.

Where Implementations Diverge

Bitcoin Core's opt-in RBF is not the only approach, and this is where it gets genuinely interesting.

Bitcoin Knots ships with stricter defaults on several fronts, including tighter spam controls. Its RBF behavior broadly mirrors Core, but operators can tune it aggressively, meaning a Knots node with custom settings might reject replacements that Core would forward without hesitation.

Full-RBF became a serious conversation inside the Core development community because opt-in RBF has a gap: if a sender doesn't signal replaceability, default-configured nodes treat that transaction as final. Full-RBF removes that distinction. Any transaction can be replaced if the economics work. Bitcoin Core shipped a `mempoolfullrbf` option that node operators can enable, defaulting to off. As more operators flip it on, the network's effective behavior shifts without any consensus change.

This is the crux. It's not that different teams made mistakes. They hold genuinely different views about what the mempool is for.

One school argues the mempool should function as a reliable queue: a merchant who sees an unconfirmed transaction should be able to treat it as a reasonable signal of intent. Zero-confirmation acceptance depends on some predictability, and opt-in RBF preserves a class of transactions that don't signal replacement, giving merchants a weaker but real assurance.

The other school says that assurance is illusory. A miner can always include any valid transaction they want. The mempool is not a contract, and full-RBF simply makes the fee market more honest while reducing the attack surface of pinning, where a malicious actor deliberately keeps a low-fee transaction in place to block a dependent transaction from being replaced.

I think the second school is right on the economics. But I also think dismissing zero-conf use cases as naive is too easy when the merchants relying on them aren't wrong about the math, just wrong about the guarantee.

Both positions are coherent. The implementations reflect that disagreement exactly.

Pinning: The Problem That Replacement Policy Was Supposed to Solve (and Sometimes Makes Worse)

Pinning deserves its own moment because it illustrates how policy rules interact in non-obvious ways, and because it matters directly to anyone running Lightning.

A pinning attack works like this. Carol and Dave have a Lightning channel. Dave wants to force-close and broadcasts a commitment transaction. Carol, acting adversarially, has already broadcast a low-fee child transaction spending one of the outputs. Under BIP 125 rule 5, a replacement can't evict more than 100 transactions. If Carol has constructed a large enough transaction tree hanging off that output, Dave's higher-fee replacement is blocked: evicting it would require touching more than 100 transactions, which Core's policy forbids.

Carol's pin costs her almost nothing. The damage to Dave can be severe if a time-locked output expires before he gets confirmed.

The Lightning development community has spent considerable effort designing around this. CPFP carve-outs, anchor outputs, proposed changes like package relay: all of it exists partly because the current RBF rules create exploitable gaps. Different node implementations handle these edge cases differently, which is why a Lightning operator's choice of underlying Bitcoin node software is not a trivial config decision. It is, in practice, a security parameter.

What Node Operators Actually Configure

If you run a node, the relevant knobs in Bitcoin Core's `bitcoin.conf` are:

  • `mempoolfullrbf=1` enables full-RBF, making all transactions replaceable regardless of signaling.
  • `mempoolexpiry` sets how many hours an unconfirmed transaction sits before being dropped (default 336, two weeks).
  • `minrelaytxfee` sets the floor fee rate a transaction must meet to be relayed at all.
  • `maxmempool` caps total mempool size in megabytes (default 300 MB); when full, lowest-fee transactions get evicted first.

None of these change what gets into a block. Miners make that call. But they shape what propagates across the network, which in practice heavily influences what miners see.

So: stuck transaction, your own node. If you're above the 85th fee percentile for current mempool depth, you're almost certainly fine and just waiting for block space. Below that, a well-formed RBF bump is the cleanest fix available.

The Honest Complication

A common misconception is that choosing a "better" node implementation solves the replacement problem. It doesn't, for a simple reason: your transaction's fate depends not just on your node's policy, but on the policies of every node it propagates through on the way to miners. Broadcast a full-RBF replacement, but the path to major mining pools runs mostly through nodes that haven't enabled `mempoolfullrbf`, and your replacement may never reach the miner's mempool at all.

Full-RBF adoption is a coordination problem, not a software setting. A minority of nodes enabling it doesn't make the network behave as if it's universal. It creates a patchwork where outcomes depend on topology.

Think of it like a rumor spreading through a crowd where each person applies different rules about which stories they'll repeat. Your transaction is the rumor. Policy rules are the social norms of each person in the crowd. Some pass it along. Some don't. A few will pass along the corrected version if you offer a better story.

And here's the question worth sitting with: if the only thing every participant actually agrees on is what's in the block, what exactly is the mempool promising you?

Blocks are consensus. Everything before that is negotiation, and the terms of that negotiation vary by node, by software version, and by whatever configuration choices a stranger made when they set up their machine.