First check what pending actually means
An unconfirmed Bitcoin transaction has not yet been included in a block. Replace-by-fee (RBF) attempts to replace it with a competing transaction. Child-pays-for-parent (CPFP) adds a second transaction that spends one of its outputs. Neither method guarantees a confirmation time.
Start with the transaction ID, the network used and the confirmation count. A withdrawal waiting inside an exchange may not have been broadcast yet. A transaction already confirmed on Bitcoin may still be awaiting that exchange's deposit-credit process. Increasing a miner fee does not fix an internal account hold.
For an on-chain transaction, record its fee in satoshis, virtual size in vbytes and fee rate in sat/vB. A mempool is a node's collection of unconfirmed transactions, not a single global waiting list. Explorer visibility shows what that service sees; it is not a promise of inclusion in the next block.
Use this guide for ordinary Bitcoin on-chain payments. Lightning channel transactions, multisignature arrangements and other networks need their own wallet instructions. You can complete the worked exercise without connecting a wallet or spending funds.
Who can use RBF or CPFP?
If you control the original transaction's inputs, check your wallet for a supported fee-increase option. RBF creates a replacement sharing an input with the original. They conflict: both cannot spend that input in the same valid chain.
If you control an unconfirmed output, CPFP may be available. That can be the recipient's output or the sender's change. The child depends on its parent, so miners considering the package need enough combined fees for both transactions.
A custodial balance is different from controlling an output's spending keys. If an exchange controls the pending withdrawal or receiving address, contact its support through the official app or site; you cannot assume your personal wallet can fee-bump that output.
Waiting remains an option when the payment is not urgent, but there is no universal completion deadline. Choose based on urgency, available wallet features and the total additional cost. Avoid creating an unrelated second payment merely because the first looks slow.
RBF: review a replacement before signing
In Trezor Suite's documented workflow, open the pending transaction, choose Speed up and review the replacement. In Electrum's desktop documentation, eligible history entries offer Increase Fee. Labels and eligibility depend on wallet version and transaction type; a missing button is not an invitation to import your recovery words into an unfamiliar tool.
Check the destination, recipient amount, total fee and change before approval. Bitcoin Core's bumpfee documentation explains that the extra fee can come from reduced change or added inputs. Added inputs can change transaction size, so the original size is not automatically the replacement size.
A replacement must satisfy applicable relay and fee policies. Wallets can impose further restrictions; for example, the documented Bitcoin Core command rejects some transactions whose outputs have already been spent by another wallet or mempool transaction.
Do not confuse an opt-in flag with a guarantee against replacement. Bitcoin Core made full RBF the default in version 28 and removed the option to disable it in version 29. Wallet interfaces may still restrict which transactions they can replace. After broadcasting, record the replacement's new transaction ID and check its status.
Worked example: compare the total fees
Assume a fictional pending parent is 200 vB and pays 400 sats: 400 ÷ 200 = 2 sat/vB. For arithmetic practice, choose a target of 10 sat/vB. This is an invented target, not a live fee recommendation. Assume no other unconfirmed ancestors or descendants.
RBF option: suppose the wallet estimates a replacement size of 220 vB. At 10 sat/vB its fee would be 2,200 sats. That is 1,800 sats more than the original fee. If this replacement confirms instead of the original, the on-chain fee is 2,200 sats, not 400 + 2,200. Only the winning conflicting transaction is included.
CPFP option: suppose the child is 150 vB. Parent plus child is 350 vB, requiring 350 × 10 = 3,500 sats in combined fees for this target. The parent already contributes 400, so the child needs 3,100 sats. Its own rate is about 20.67 sat/vB, while the combined rate is exactly 10.
Setting only the child's rate to 10 sat/vB would pay 1,500 sats on the child. Combined with the parent, that is 1,900 ÷ 350 ≈ 5.43 sat/vB. It misses the intended package target. The useful formula is: child fee = target package rate × combined virtual size − parent fee.
These are two alternative scenarios, not steps to perform in sequence. In this example RBF costs less overall, but wallet eligibility, output value, other unconfirmed relatives and policy requirements can change the available choice. Have the wallet validate the real transaction; a worksheet is not a relay acceptance test.
- Bitcoin Core: replacement fees, change and wallet restrictions ↗
- Blockstream: RBF, conflicting transactions and package fees ↗
- Bitcoin developer guide: spending outputs and transaction fees ↗
CPFP: check the output and the whole package
Electrum documents a Child pays for parent action for eligible unconfirmed history entries. The child spends an output you control; a sender needs suitable change, while a recipient needs control of the received output. There must be enough value to pay the fee and create a valid output.
Inspect which output is being spent, the new destination, the amount left and the combined fee estimate. Parent and child must be valid and reach miners that can include them; a high child fee alone does not guarantee propagation or confirmation. Other unconfirmed ancestors make the simple two-transaction worksheet incomplete.
For a support request, provide the public transaction ID and relevant status through the provider's official channel. Never provide recovery words or private keys. Sharing a transaction ID can also reveal financial activity, so do not post it publicly just to ask a general question.
Can I cancel a pending Bitcoin payment?
Some wallets offer a cancellation attempt that creates a conflicting transaction paying back to an address you control. Electrum calls its option Cancel (double-spend). The label does not mean the network can recall a payment on demand: the original may confirm before the replacement wins.
RBF cannot undo a transaction that is already confirmed. Removing a transaction from your wallet view, or seeing it disappear from one explorer, is not proof of network-wide cancellation. Do not promise a recipient that funds have been recovered until the relevant confirmed transaction and outputs establish the result.
Keep the original and replacement IDs together in your records. For CPFP, retain both parent and child IDs instead. This distinction helps avoid treating a replacement as two payments, or overlooking the second fee in a parent-and-child pair.
Five-minute practice: choose and verify
Write down a second fictional parent: 250 vB, fee 750 sats. You control a change output and can create a 150 vB child. With a hypothetical combined target of 8 sat/vB, calculate the required child fee before reading the answer.
Answer: combined size is 400 vB and target fees are 400 × 8 = 3,200 sats. Subtract the parent's 750 sats: the child needs 2,450 sats. Its own rate is about 16.33 sat/vB. A child paying only 8 sat/vB would contribute 1,200 sats, leaving the combined rate at 1,950 ÷ 400 = 4.875 sat/vB.
Now change just one condition: the pending payment is an exchange withdrawal, and you control neither the original inputs nor a receiving output. The arithmetic remains valid as an exercise, but it does not give you authority to construct either transaction. The next action is checking the withdrawal record and contacting the custodian.
Save a short decision note: transaction state, who controls the relevant keys, chosen option, estimated total cost and what evidence would show completion. If those fields are unclear, resolve them before signing. This is an original paper exercise, not a claim that a wallet or fee estimate was tested with live funds.
- The transaction is on Bitcoin and still unconfirmed, rather than an internal exchange hold.
- The wallet supports the chosen operation for these inputs or outputs.
- Destination, recipient amount, change and total fee have been reviewed.
- The estimate includes the replacement size or all relevant package transactions.
- The new transaction IDs and confirmation status are recorded; no deadline is guaranteed.
Sources & further reading
- Bitcoin Core: replacement fees, change and wallet restrictions
- Bitcoin Core 29.0: full RBF policy
- Electrum: unconfirmed transactions, fee increases and CPFP
- Trezor: increasing a pending Bitcoin transaction's fee
- Blockstream: RBF, conflicting transactions and package fees
- Blockstream: transaction creation and broadcast
- Bitcoin developer guide: spending outputs and transaction fees
- Bitcoin Core: local mempool state and virtual size
Educational content. Examples are illustrative. Protocols, products and rules can change; consult the linked documentation for current details.