Replace-by-fee

Fee estimates go stale, so bitcoin lets a sender rewrite a payment that has not been mined yet. The replacement must pay the original's whole fee again plus at least one extra satoshi per virtual byte, so bumping is never free. For you the practical rule is blunt: nothing unconfirmed is settled, and only the sender can bump.

How it works

Replacement is a relay policy, not a consensus rule, which is why its behavior has changed twice without any fork.

BIP125 defined the opt-in version and Bitcoin Core shipped it in 0.12.0 on February 23, 2016. A sender flagged willingness to be replaced by setting the sequence number on at least one input to 0xfffffffd or lower, and nodes would then forward a conflicting transaction that paid more. Wallets that did not set the flag produced payments their own users could not repair.

That distinction is gone. Bitcoin Core 28.0, released in October 2024, switched the -mempoolfullrbf default to on, so a well connected node now forwards a higher paying conflict regardless of what the first transaction signaled. Any wallet screen still promising that an unflagged payment "cannot be replaced" is describing a network that no longer exists.

Four conditions decide whether a node accepts the swap, and they exist to stop replacement being used to flood the network with free rewrites:

• The replacement must pay a higher absolute fee than every transaction it evicts, not merely a higher fee rate.
• It must also pay an extra amount of at least the incremental relay fee, which defaults to 1 satoshi per virtual byte multiplied by the size of the new transaction.
• It may not pull in unconfirmed inputs that the original did not already spend.
• It may not evict more than 100 transactions at once, counting the descendants of everything it conflicts with.

The absolute fee rule is the one that surprises people. A replacement that trims a large transaction down to a smaller one at a better rate can still be rejected, because the fee total went down. Note also that you pay the new fee, not both: the original is discarded and never mined, so the old fee is never collected.

Bitcoin Core exposes this as the bumpfee RPC, and most desktop wallets wrap it in a button labeled "increase fee" or similar. The usual mechanism is to shrink the change output by the extra fee amount, which is why a payment that sent an entire balance with no change left cannot be bumped without adding another input.

Why this matters when you buy bitcoin

The moment replacement becomes your problem is the moment you withdraw from an exchange to your own wallet, or send from that wallet to someone else.

Sending from your own wallet is the good case. If you picked a fee rate at 2am and the mempool woke up, open the transaction and bump it. Choose a wallet that offers the button before you need it: this is a normal feature in Bitcoin Core, Sparrow, Electrum and Trezor Suite, and a missing feature in plenty of phone wallets that pick the fee for you and give you no way back.

Withdrawing from an exchange is the bad case. The exchange built that transaction, it holds the keys to the inputs, and only it can replace it. Support desks generally will not, because their withdrawal batches serve dozens of customers at once. Your only lever from the receiving side is child pays for parent, which works because the coin arriving to you is spendable the moment it exists, even unconfirmed.

Receiving is where replacement changes how you should behave. A seller on a peer to peer marketplace, a face to face trade, or a bitcoin ATM operator who releases goods on an unconfirmed payment is trusting a transaction that anyone with a mempool can watch being replaced. Full replacement being the default means the old advice, that an unflagged transaction was safe to accept at zero confirmations, is retired. Wait for a block. For amounts that matter, wait for several.

Bumping a 3 sat/vB withdrawal that stalled

Suppose you send 0.05 BTC from your own wallet with one native SegWit input and two outputs, one to the recipient and one for change. That transaction is about 141 virtual bytes, and at 3 sat/vB it carries a fee of 423 satoshis.

The next morning the cheapest confirming rate is 20 sat/vB and your payment has not moved. You bump. The replacement is the same 141 virtual bytes, so 20 sat/vB means a fee of 2,820 satoshis, taken out of the change output rather than out of the recipient's amount. The policy floor for this replacement is the original 423 satoshis plus 1 sat/vB across 141 bytes, which is 564 satoshis, so 2,820 clears it comfortably.

You do not pay 3,243 satoshis. You pay 2,820, and the first version dies unmined. The recipient still receives exactly 0.05 BTC, and the transaction id changes, so if you have already given someone the old id you need to send them the new one.

Where this gets expensive is when there is no change output left to shrink. Then the wallet has to add another input, the transaction grows to roughly 209 virtual bytes, and the same 20 sat/vB now costs 4,180 satoshis.

Replace-by-fee vs double spend

Replace-by-fee and a double spend attempt use the same mechanism and differ only in where the money ends up. A replacement usually keeps the same recipient and takes the extra fee out of change. A double spend rewrites the outputs so the coins go back to the sender or somewhere else entirely, and the merchant who handed over goods gets nothing.

No node can tell the difference, because both are simply conflicting transactions and the higher paying one wins. That is the whole argument for waiting on confirmations rather than trusting the label your wallet puts on an incoming payment. The protection is depth in the chain, not the sender's stated intent.