RBF (Replace-by-Fee) and CPFP (Child-Pays-for-Parent) are two protocol-level methods for accelerating a stuck Bitcoin transaction by raising its effective fee rate in the mempool. RBF replaces the original transaction with a higher-fee version that spends the same inputs, while CPFP attaches a new high-fee child transaction to an unconfirmed output, giving miners an incentive to confirm both together. The choice between them depends on whether you control the sending wallet or only an output from the stuck transaction, and whether the original was broadcast with a replaceable signal. This guide covers diagnosis, method selection, step-by-step execution, fee math, edge cases, and what to do when neither method is available.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources include BIP 125 (opt-in full Replace-by-Fee signaling) as published on the Bitcoin BIPs repository (github.com/bitcoin/bips), Bitcoin Core release notes for versions 28.0 and 31.0 documenting full-RBF default activation and cluster mempool limits, and Bitcoin Optech topic pages for RBF and CPFP technical specifications. Fee rate mechanics and mempool behavior referenced from mempool.space live data. All technical details independently verified against protocol documentation current as of April 2026.
Why is your Bitcoin transaction stuck and how do you diagnose it?
A Bitcoin transaction gets stuck when its fee rate in satoshis per virtual byte falls below the threshold miners are currently accepting for block inclusion. The network prioritizes transactions by fee rate, not total fee, so a large payment with a low sat/vB rate will wait longer than a small payment with a high rate. Diagnosing the problem means checking your transaction's fee rate against current mempool demand.
Fee rate vs total fee
Fee rate equals total fee divided by transaction virtual size (vsize in virtual bytes). Miners maximize revenue by selecting the highest fee-rate transactions that fit in the next block. A 300-byte transaction paying 600 satoshis (2 sat/vB) will sit behind a 150-byte transaction paying 1,500 satoshis (10 sat/vB) because miners evaluate rate, not absolute amount. This is why your Bitcoin transactions may be pending even if the total fee seemed reasonable when you broadcast it.
Mempool conditions change constantly
The mempool fee market fluctuates based on network demand. A 5 sat/vB transaction might confirm in the next block during quiet periods or remain pending for days during congestion. Historical data from 2024-2025 shows fee rates ranging from 1-2 sat/vB during calm periods to over 200 sat/vB during peak demand events. You can check current conditions in real time at mempool.space (source: Mempool.space).
Five things to check before taking action
Transaction ID (txid): locate your txid in your wallet and look it up on a block explorer.
Current fee rate: check the sat/vB displayed by the explorer or calculate it as total fee divided by vsize.
Replaceable flag: look for "RBF enabled" or "Replaceable" in your wallet or the explorer listing.
Outputs you control: determine whether you control the change output (sender) or the receiving output (recipient).
Wallet type: confirm whether you are using a self-custody wallet or a custodial service, since custodial services control the private keys and signing authority.
When waiting is rational
If your fee rate is within 50% of the current one-hour estimate and you do not urgently need confirmation, waiting may be the simplest approach. Mempool congestion often clears overnight or during weekends. Very low fee-rate transactions (below 1 sat/vB) may take days, but they typically confirm eventually or get purged from the mempool after approximately two weeks with default node settings, returning your UTXO management to spendable status.
How does RBF (Replace-by-Fee) work?
RBF lets the sender replace an unconfirmed transaction with a new version that pays a higher fee rate, using the same inputs but with an increased miner fee. The replacement transaction supersedes the original in the mempool, and only one version will ever confirm. Since Bitcoin Core version 28.0 (released in 2024), full RBF is enabled by default, meaning nodes accept replacements for any unconfirmed transaction regardless of whether the original signaled BIP 125 opt-in replaceability (source: Bitcoin Optech).
BIP 125 replacement rules
The replacement must meet specific criteria. It must pay a strictly higher fee rate than the transaction it replaces. It must also pay a higher absolute fee to cover at least the minimum relay fee for its own size plus the size of any transactions it evicts from the mempool. It must spend at least one of the same inputs as the original. These rules prevent abuse while allowing legitimate fee bumping.
Full RBF vs opt-in RBF
Before Bitcoin Core 28.0, RBF replacements were only accepted for transactions that explicitly signaled replaceability through the nSequence field (opt-in RBF per BIP 125). Full RBF removes this restriction at the node policy level, accepting replacements for any unconfirmed transaction. In practice, this means you can now attempt to replace a stuck transaction even if your wallet did not set the RBF flag at broadcast time, provided the nodes and miners you reach run full-RBF policy. Most of the network has been upgraded to full-RBF-capable software as of early 2026.
Does RBF cancel the original transaction?
Not exactly. RBF replaces the pending transaction in the mempool. Once the replacement propagates, nodes drop the original and keep the higher-fee version. The original transaction ceases to exist in most nodes' mempools, but technically this is replacement rather than cancellation. There is a small window where the original could confirm if a miner who has not seen the replacement finds a block first.
Simulated cancellation via RBF
You can use RBF to effectively cancel a payment by replacing it with a transaction that sends all funds back to your own wallet, minus the replacement fee. This is sometimes called "cancel via RBF." It works only if the original has not yet been confirmed and your replacement propagates widely before the next block.
How do you execute an RBF fee bump step by step?
Open your wallet, locate the pending transaction, select the fee-bump option, set a new fee rate based on current mempool estimates, verify the outputs remain correct, then broadcast the replacement. The process takes under two minutes in most wallets that support RBF. The critical verification step is confirming that the recipient address and amount remain unchanged before you sign.
Step 1: Locate the unconfirmed transaction
Open your Bitcoin wallet (Sparrow, Electrum, Bitcoin Core, or any wallet with RBF support). Find the pending transaction in your history. Verify it shows "Unconfirmed" or "Pending" status.
Step 2: Initiate the fee bump
Look for a button labeled "Bump fee," "Increase fee," "Speed up," or "Replace." If this option does not appear, your wallet may not support RBF or the transaction may have already been confirmed. Confirm you are building a replacement that reuses the same inputs, not creating a separate unrelated transaction.
Step 3: Set the new fee rate
Check current mempool fee estimates at mempool.space or use your wallet's built-in estimator. Choose "Next block" for urgent confirmation or "Within 1 hour" for moderate priority. The new fee must exceed the original fee rate and the original absolute fee.
Step 4: Verify outputs before broadcasting
Confirm the recipient still receives the same amount at the same destination address. Verify the change output returns to your wallet. Some wallets may adjust outputs to cover the higher fee from the change amount; this is normal as long as the recipient amount is unchanged.
Step 5: Broadcast and monitor
Sign and broadcast the replacement. Note the new txid, which will differ from the original. Monitor Bitcoin confirmations status on a block explorer. If you shared the original txid with the recipient for tracking, inform them of the new one.
Common RBF failure modes
The replacement may fail to propagate if you set the fee increase too small (must exceed minimum relay fee increment). Some wallets do not support constructing replacements. If RBF is not possible because your wallet lacks the feature or the transaction already has descendants in the mempool, CPFP via your change output is the alternative.
How does CPFP (Child-Pays-for-Parent) work?
CPFP accelerates a stuck transaction by creating a new high-fee child transaction that spends an output from the unconfirmed parent, giving miners an economic incentive to confirm both together as a package. Miners evaluate transaction packages, not just individual transactions; to claim the child's fee, they must include the parent. Anyone who controls an output from the stuck transaction can initiate CPFP (source: Bitcoin Optech).
Package fee rate
The effective priority is determined by the combined fee rate of parent and child. Total package fee equals parent fee plus child fee, divided by the combined vsize of both transactions. If the parent pays 2 sat/vB and the child pays enough to bring the combined rate to 20 sat/vB, both transactions enter the priority range for near-term block inclusion.
Who can use CPFP
The sender can use CPFP by spending the change output from the stuck transaction. The receiver can use CPFP by spending the payment output they received. This makes CPFP the only self-service option when you are the recipient of a low-fee transaction you did not send. Your wallet must allow spending unconfirmed funds, which not all wallets enable by default.
Package and cluster limits
Bitcoin Core enforces limits on chains of unconfirmed transactions. As of Bitcoin Core 31.0 (2025), the older ancestor and descendant limits of 25 transactions were replaced by cluster-based mempool limits capping clusters at 64 transactions and 101 kB total size (source: GitHub). In practice, you are unlikely to hit these limits for a simple CPFP operation, but they become relevant if the stuck transaction already has many unconfirmed descendants.
How do you calculate and execute a CPFP fee bump?
Calculate the child transaction's required fee by determining the target package rate, multiplying by the combined vsize of parent and child, then subtracting what the parent already pays. Create a transaction spending the unconfirmed output with that fee, then broadcast it. The parent txid remains unchanged, and both transactions should confirm together.
CPFP fee math example
Given a parent transaction of 150 vB paying 300 satoshis (2 sat/vB) and a target package rate of 20 sat/vB for next-block confirmation, with an estimated child transaction size of 100 vB:
Total package vsize: 150 + 100 = 250 vB. Total fee needed: 250 x 20 = 5,000 satoshis. Parent already pays: 300 satoshis. Child must pay: 5,000 - 300 = 4,700 satoshis. Child effective rate: 4,700 / 100 = 47 sat/vB.
Set your child transaction fee to approximately 4,700 satoshis or target 47+ sat/vB in your wallet's fee selector.
Step 1: Enable unconfirmed spending
Access your wallet's settings or coin control feature. In Electrum, navigate to Preferences then Transactions and enable "Spend unconfirmed." In Sparrow, coin control is available by default. Other wallets may label this differently.
Step 2: Select the correct UTXO
Identify the unconfirmed output you control from the parent transaction. If you are the recipient, select the payment you received. If you are the sender, select your change output. Confirm you are selecting an output from the stuck transaction specifically, not a different UTXO.
Step 3: Create the child transaction
Initiate a new payment spending the selected unconfirmed output. The destination can be another address you control (consolidating funds to yourself) or a legitimate outgoing payment. Set the fee rate high enough to achieve your target package rate using the formula above.
Step 4: Verify and broadcast
Verify that the child fee makes economic sense. If the output is 2,000 satoshis and the required fee is 3,000 satoshis, CPFP is not practical because the fee exceeds the output value. Sign and broadcast the child transaction. Monitor both parent and child txids; they should confirm together in the same block.
When should you use RBF vs CPFP?
Use RBF when you are the sender, your wallet supports replacement, and you want the simplest and cheapest option. Use CPFP when you are the recipient, when RBF is not available, or when you only control an output rather than the sending wallet. RBF is more efficient because it does not require additional block space for a separate child transaction, saving roughly 30-90% in overhead fees compared to CPFP.
Decision by scenario
Sender with replaceable transaction: use RBF. Open your wallet, bump the fee to current next-block estimates, broadcast. This is the default choice for senders.
Sender without RBF support or non-replaceable transaction: use CPFP via your change output if one exists. Create a new transaction spending the change with a fee high enough to lift the package rate.
Recipient waiting for an incoming payment: use CPFP. Spend your unconfirmed receiving output in a new high-fee transaction, even if you are just sending it to another address you control.
Exchange withdrawal stuck: contact the exchange first. If they cannot help and your receiving wallet supports spending unconfirmed funds, attempt CPFP from your receiving output. You cannot RBF an exchange's transaction because you do not control their wallet.
Multisig or business wallet: coordinate with co-signers. RBF requires enough signers to authorize the replacement. CPFP requires whoever controls the relevant output. Operating a multisig wallets setup adds coordination overhead to either method.
Efficiency comparison
RBF replaces the original transaction in place without adding data to the block. CPFP adds a second transaction, consuming additional block space. For a sender who can use either method, RBF produces a lower total fee because the replacement transaction is the same size as the original (or very close), while CPFP adds roughly 100+ vB for the child transaction. From a miner's perspective, both methods achieve the same goal of increasing the effective fee rate.
What are the risks and edge cases when accelerating transactions?
Fee bumping carries risks including overpaying during volatile mempool conditions, accidentally altering recipient amounts, and creating transaction chains that complicate future spending. Third-party accelerator services introduce privacy and fraud risks. Understanding these edge cases before you act prevents making a stuck transaction situation worse.
Do not alter the recipient amount
When constructing an RBF replacement, some wallets take the additional fee from the change output automatically. Verify the recipient still receives the expected amount. Reducing the recipient's payment to cover a higher fee changes the terms of the transaction and could constitute fraud in a commercial context.
Third-party accelerator services
Some services claim to accelerate transactions by submitting them directly to Bitcoin mining pools. Legitimate mining pool accelerators (historically offered by pools like ViaBTC) depend on that pool finding the next block. Paid accelerators offer no guarantee. Many services are outright scams that take payment and do nothing. All of them require you to share your txid, which reveals financial activity. Exhaust RBF and CPFP first before considering any accelerator.
Multiple conflicting broadcasts
Do not broadcast conflicting transactions from different wallets hoping one confirms. This creates propagation issues and may cause confusion for the recipient. If you need to attempt both RBF and CPFP, coordinate so the child transaction spends an output from the replacement rather than the original.
When to stop trying and wait
Consider waiting instead of repeated fee bumps if your fee rate is near the six-hour mempool estimate, the payment is not time-sensitive, each bump costs meaningful additional fees, or mempool congestion is visibly clearing. I have seen operators burn through more in repeated bumps than the original fee shortfall warranted, simply because they were reacting to mempool snapshots rather than watching the trend over a few hours. Patience is a legitimate strategy when the fee gap is small.
Dust outputs and economic viability
If the output you want to spend in a CPFP child is smaller than the fee required to lift the package, the operation is not worth executing. A 1,500-satoshi output that needs a 3,000-satoshi child fee is a net loss. Calculate before committing. This threshold shifts with mempool conditions, so what is uneconomical today may become viable when fees drop.
Frequently asked questions
What is the fastest way to speed up a Bitcoin transaction?
If you are the sender and your wallet supports it, RBF is the fastest method because it replaces the stuck transaction in the mempool without requiring a second transaction. Check your wallet for a "Bump fee" or "Increase fee" option, set the new rate to match current next-block estimates, and broadcast. If RBF is not available or you are the recipient, CPFP achieves the same result by attaching a high-fee child transaction to an unconfirmed output you control.
How do you know if your transaction is RBF-enabled?
Check your wallet's transaction details for a label reading "Replaceable," "RBF," or "RBF enabled." Block explorers like mempool.space also display this flag on the transaction page. Since Bitcoin Core 28.0 made full RBF the default node policy, most nodes now accept replacements regardless of signaling, but your wallet software still needs to support constructing the replacement transaction for you to execute the bump.
Can the receiver speed up a transaction they did not send?
Yes. The receiver can use CPFP by spending their unconfirmed payment output in a new high-fee child transaction. This incentivizes miners to confirm the parent and child together. The receiver's wallet must support spending unconfirmed funds, and the output must be large enough that the child fee does not consume an impractical portion of its value.
Can you use both RBF and CPFP on the same stuck transaction?
Sometimes. The sender can attempt RBF while the receiver attempts CPFP independently. Whichever results in block inclusion first takes effect. If the sender broadcasts an RBF replacement, any CPFP child spending an output from the original becomes invalid because the original transaction no longer exists in the mempool. Coordinate with the other party to avoid wasted fees.
Will a transaction accelerator service always work?
No. Accelerators depend on the specific mining pool finding the next block, which is probabilistic. Many paid accelerators offer no refund if they fail, and a significant number of services advertising acceleration are outright scams. RBF and CPFP are protocol-level mechanisms that work with any miner, making them more reliable than any third-party service.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources include BIP 125 (opt-in full Replace-by-Fee signaling) as published on the Bitcoin BIPs repository (github.com/bitcoin/bips), Bitcoin Core release notes for versions 28.0 and 31.0 documenting full-RBF default activation and cluster mempool limits, and Bitcoin Optech topic pages for RBF and CPFP technical specifications. Fee rate mechanics and mempool behavior referenced from mempool.space live data. All technical details independently verified against protocol documentation current as of April 2026.
This article is for informational purposes only and does not constitute financial advice. Cryptocurrency trading involves substantial risk of loss. Past performance does not guarantee future results. Always conduct your own research and consider your financial situation before trading. BloFin does not guarantee the accuracy of third-party data referenced herein.