How to Unstick a Bitcoin Transaction: RBF and CPFP Explained

When a $BTC transaction is broadcast to the network with a fee that is too low, it can remain unconfirmed in the mempool indefinitely. Senders and receivers can resolve this by increasing the economic incentive for miners to process the transfer. The two primary mechanisms for unsticking a transaction are Replace-by-Fee (RBF) and Child-Pays-for-Parent (CPFP).

The Mempool and Transaction Fees

Bitcoin nodes hold unconfirmed transactions in a staging area called the mempool. Miners select transactions from the mempool to include in the next block, prioritizing those that offer the highest fee rate. Fee rates are calculated in satoshis per virtual byte (sats/vByte), matching the transaction's physical data size against the miner's financial reward ¹.

If network congestion increases after a transaction is broadcast, the prevailing fee rate rises. Transactions with previously acceptable fee rates get pushed down the priority queue. If the fee rate is significantly lower than the current clearing rate, the transaction stalls. It remains valid but unconfirmed until congestion clears or it is dropped from node mempools entirely ².

Replace-by-Fee (RBF) Explained

Replace-by-Fee (RBF) is a protocol mechanism that allows a sender to replace an unconfirmed transaction with a new version that pays a higher fee ³. Under the opt-in RBF standard formalized in BIP-125, the sender flags the initial transaction to indicate it can be replaced.

When a transaction is stuck, the sender crafts a new transaction using the same inputs but directs a larger portion of the funds to miner fees, reducing the change output. The sender then broadcasts this replacement. Because the new transaction conflicts with the original by spending the same inputs, nodes accept the new one and discard the old one, provided the new transaction pays a higher absolute fee and a higher fee rate ³.

RBF is highly efficient because it does not require additional block space. It merely swaps a low-fee transaction for a high-fee equivalent. However, RBF can only be executed by the sender, as it requires the private keys associated with the transaction's inputs.

Child-Pays-for-Parent (CPFP) Explained

Child-Pays-for-Parent (CPFP) is an alternative method used when RBF is unavailable or when the receiver wants to expedite the transaction. CPFP relies on the fundamental rule of Bitcoin UTXOs: a transaction cannot be confirmed unless all its parent transactions are also confirmed ¹.

In a CPFP scenario, the receiver (or the sender, if they received a change output) takes the unconfirmed output from the stuck transaction and uses it as an input in a brand-new transaction. This new "child" transaction includes an exceptionally high fee. Miners evaluating the mempool will see the high-fee child, but protocol rules dictate they must also mine the low-fee "parent" to claim the child's fee ². Miners calculate the combined fee rate of the parent and child transactions, known as the package fee rate, and mine both simultaneously if the package rate is competitive.

CPFP consumes more block space than RBF because it requires broadcasting a second, entirely separate transaction. Consequently, it is generally more expensive than RBF, but it offers flexibility by allowing receivers to unstick incoming funds.

Worked Example: Calculating a CPFP Fee

Executing CPFP requires calculating the effective fee rate across two transactions. Assume a parent transaction is stuck in the mempool. It has a size of 250 vBytes and pays a fee of 2,500 satoshis, resulting in a fee rate of 10 sats/vByte.

Due to network congestion, the current clearing rate for the next block is 50 sats/vByte. To unstick the parent, the child transaction must pay enough to raise the average of both transactions to 50 sats/vByte.

Assume the new child transaction will be 150 vBytes in size. The total size of the package (parent + child) is 400 vBytes.

To achieve a package rate of 50 sats/vByte, the total fee for the package must be: 400 vBytes * 50 sats/vByte = 20,000 satoshis.

The parent transaction already pays 2,500 satoshis. Therefore, the child transaction must pay the remainder: 20,000 satoshis - 2,500 satoshis = 17,500 satoshis.

The child transaction's individual fee rate will be artificially high (17,500 / 150 = 116.6 sats/vByte) to subsidize the parent's low rate.

RBF vs. CPFP: Which to Choose?

The choice between RBF and CPFP depends on network conditions, wallet software, and participant roles.

Senders should generally use RBF if their wallet supports it and the original transaction was flagged as replaceable. RBF is cheaper and does not clutter the blockchain with extra transactions.

Receivers must use CPFP. If a merchant or individual is waiting on a slow inbound payment, they can spend the unconfirmed output to themselves, attaching a high fee to force the confirmation. Senders can also use CPFP if they forgot to enable opt-in RBF, provided the stuck transaction included a change output directed back to their wallet.

Common Misconceptions

• Stuck transactions mean lost funds. A transaction pending in the mempool has not transferred any funds. If it never confirms, the nodes eventually drop it, and the funds remain freely spendable in the sender's wallet.
• RBF is a double-spend attack. While RBF creates a conflicting transaction, it operates within strict protocol rules designed to prevent fraud. It is a legitimate fee-bumping mechanism, not a malicious exploit.
• Miners process transactions sequentially by time. Miners prioritize profitability, not the timestamp of the broadcast. A transaction broadcast seconds ago with a high fee will be mined before a transaction that has sat in the mempool for days with a low fee.

What to Watch

Wallet developers increasingly automate fee management to shield users from manual RBF or CPFP calculations. As block space demand fluctuates, modern infrastructure defaults to opt-in RBF and provides simple "bump fee" buttons. Institutional custodians and exchanges heavily rely on CPFP to sweep user deposits efficiently during high-fee environments, batching multiple unconfirmed parents into a single high-fee child to optimize operational costs.