Understanding Fees and Remedies for a Stuck Bitcoin Transaction
How fee rates, replacement transactions and child transactions affect an unconfirmed on-chain payment, and what to verify first.
By Avery ColePublished 10/16/2026, 8:11:01 PM UTC
education·4 min read
BTC / SLOPESPAYMENTS ↗
Concept illustration / BTC Slopes
Sponsored disclosure: Avery Cole is a fictional BTC Slopes editorial persona. This article was researched and drafted with AI assistance from the linked public sources. No interviews or firsthand transaction testing were conducted. This is general technical education, not personalized financial advice.
A Bitcoin payment that remains unconfirmed needs a diagnosis before it needs another fee. The useful questions are whether the transaction reached the network, what fee rate it offers, and who can authorize a replacement or spend one of its outputs. This concerns on-chain transactions; Lightning routing and receiving capacity are separate problems.
Two common remedies are replace-by-fee, or RBF, and child-pays-for-parent, or CPFP. They change different transactions and require different control over the funds.
Read the fee rate
A transaction's total fee does not tell the whole story. Fee rate expresses the fee relative to its virtual size, commonly in satoshis per virtual byte, or sat/vB. Bitcoin Core distinguishes virtual size from serialized byte size because witness data receives a discount. Its mempool inspection documentation reports virtual size and the transaction's base fee separately.
For illustration, 1,000 sats spread across 200 vB is 5 sat/vB; across 500 vB it is 2 sat/vB. Neither calculation uses the amount sent to the recipient. These are arithmetic examples, not current fee recommendations.
A wallet's confirmation estimate is also conditional. Core's fee-estimation documentation describes an approximate rate for confirmation within a target number of blocks. It can return an error when observations are insufficient. Its result uses BTC/kvB, so anyone comparing raw software output with a wallet's sat/vB display must check units.
Block targets are not appointments. Blocks arrive about every ten minutes on average, with individual intervals varying unpredictably; demand for block space also changes. A higher fee can improve competitiveness without reserving space in a particular block. Bitcoin.org's confirmation explanation
RBF replaces the original transaction
RBF submits a competing transaction spending at least one of the same inputs. For an ordinary payment, this is generally a sender-side option: receiving an output does not give the recipient authority to sign a replacement spending the sender's inputs.
Core's fee-bumping command can fund the increase by reducing change or adding inputs. It produces a new transaction ID. It also refuses a bump when the wallet or mempool contains a transaction spending an output of the original. Wallet capabilities and transaction history therefore matter alongside the fee. Core bumpfee documentation
Older explanations often say the original must have opted into RBF. That is no longer a universal rule. The official download page lists Bitcoin Core 31.1 as the latest stable release on October 9. Its version-pinned replacement policy records full-RBF as the default since version 28 and says signaling is no longer required. Replacement still has fee and other policy requirements. A wallet's available buttons and other nodes' policies may differ; a missing opt-in flag is not a promise that an unconfirmed payment cannot be replaced.
CPFP spends an output of the original
CPFP keeps the parent transaction and adds a child that spends one of its outputs. The child cannot confirm without its parent, giving miners a reason to consider their combined fees. A recipient may be able to spend the incoming output; a sender may be able to spend change. Both require wallet support and control of an eligible output. Electrum's CPFP explanation
Consider a simplified parent of 200 vB paying 200 sats, plus a child of 100 vB. To bring the pair to 10 sat/vB, their combined 300 vB needs 3,000 sats, so the child supplies 2,800 sats. Merely setting the child itself to 10 sat/vB would leave the pair at 4 sat/vB.
That illustration assumes no other unconfirmed dependencies and is not a guarantee of acceptance or confirmation. Core's package policy describes combined-fee calculations and restrictions on the transactions submitted together. More complicated transaction chains require more than this two-transaction arithmetic.
Check before attempting either method
First, establish the current transaction ID and status in a synchronized wallet. Look for confirmations, conflicts or a replacement ID before making a separate payment. Core's transaction-status documentation exposes these distinctions. A replacement may leave the original ID unconfirmed while the payment proceeds under another ID.
Second, distinguish a node's view from a network-wide verdict. Each node applies its own transaction-relay policy. Absence from one explorer does not establish that a payment is canceled. Check the wallet's broadcast status and any unconfirmed dependencies before attributing the delay entirely to price.
Finally, review the proposed transaction's recipient, amount, change and total fee before authorizing anything. Diagnostic help never requires handing a website or stranger the recovery phrase that controls the wallet. Bitcoin.org's backup guidance
The practical distinction is control: RBF replaces a spend, while CPFP spends its output. Establish which transaction exists, who can sign, and what the full fee would be before choosing a remedy.
Batching can reduce a sender’s transaction costs, but recipients still need to identify their own output, check deductions and understand the shared public record.
October 16–17 releases fix asset-payment handling and urge affected operators to update, highlighting the operational work behind multi-asset Lightning payments.