How to speed up a stuck Bitcoin transaction

Why transactions get stuck

Miners fill each block with the transactions that pay them the most per unit of block space. That price is the fee rate, measured in satoshis per virtual byte (sat/vB). A block holds roughly one million virtual bytes and one is found every ten minutes on average, so when more people want to transact than will fit, the fee rate needed to get in rises, sometimes within minutes.

A transaction sent with a fee rate that was fine an hour ago can fall behind a wave of better-paying ones. It then waits in the mempool (the queue of unconfirmed transactions each node keeps) until the fee level comes back down to it, or until you raise its fee.

First, check where it stands

Paste the transaction ID into the Bitcoin transaction accelerator. It shows the fee rate you paid, how far that is from the current fee levels, whether the transaction signals RBF, and whether it depends on another unconfirmed transaction. That tells you which fix applies and what fee rate to aim for.

• Fee rate paid against the next-block rate. If you are only slightly below, the backlog may clear on its own within hours.
• The RBF signal. A transaction signals that it can be replaced when at least one input has a sequence number below 0xfffffffe. Most modern wallets set it by default.
• Unconfirmed parents. If your transaction spends an output that is itself unconfirmed, miners judge the pair together, and the slow parent may be the real problem.

Option 1: replace-by-fee (you sent it)

Replace-by-fee (BIP 125) lets the sender broadcast a new version of the transaction that spends the same coins with a higher fee. Nodes swap the old version for the new one and miners pick up the better-paying version. Only one of the two can ever confirm, so the payment is never made twice.

In most wallets this is a button (“Bump fee”, “Speed up” or “Increase fee”) on the unconfirmed transaction; Sparrow, Electrum, BlueWallet and Bitcoin Core all support it. The replacement must pay a higher fee rate and a higher total fee than the original, plus a little extra for its own size, so wallets suggest a new rate for you.

Option 2: child-pays-for-parent (you received it, or RBF is not available)

Miners do not look at transactions one by one; they look at a transaction together with the unconfirmed ancestors it needs. If you control an output of the stuck transaction (the payment you received, or the sender’s change) you can spend it in a new “child” transaction with a generous fee. To collect the child’s fee, a miner has to include the parent too.

The child has to pay enough to lift the average fee rate of both transactions to your target:

child fee = target rate × (parent size + child size) − parent fee

For example, a 200 vB parent that paid 400 sats (2 sat/vB) needs, for a 20 sat/vB package with a 110 vB child, a child fee of 20 × 310 − 400 = 5,800 sats, about 53 sat/vB on the child alone. The accelerator does this calculation with the real sizes.

Option 3: wait, or rebroadcast

If the fee you paid is close to the current level, waiting is often the cheapest fix: demand swings through the day and week, and backlogs clear. If your transaction has vanished from some nodes’ mempools (because they filled up and dropped the lowest-paying transactions), rebroadcasting it puts it back in front of miners. Rebroadcasting does not change the fee, so it only helps in that case.

Some mining pools also sell out-of-band acceleration: for a separate payment, the pool includes your transaction in blocks it finds. It works only when that pool finds a block, and it usually costs well above what a fee bump would.

Avoiding it next time

• Check the current fee levels before sending, and choose a fee for how soon you actually need confirmation.
• Leave RBF switched on in your wallet so you can bump the fee later.
• Use SegWit or Taproot addresses: their inputs take less block space, so the same fee rate costs fewer satoshis.
• Avoid spending coins you received that are still unconfirmed, unless you mean to pay for them with CPFP.