Bitcoin transaction stuck or unconfirmed? Why it happens and how to speed it up

You sent bitcoin an hour ago, the wallet says “pending”, and a block explorer shows the transaction as unconfirmed. An hour becomes a day. Has it gone missing?

Almost certainly not. A stuck bitcoin transaction is usually a fee problem, and there are standard ways to deal with it. This guide explains what’s happening and what you can do, whether you’re the sender or the receiver.

Where your transaction is waiting

When you send bitcoin, your wallet broadcasts the transaction to the network. Nodes check it and keep it in a waiting area called the mempool (memory pool) until a miner includes it in a block. Bitcoin.org says new blocks are added about every 10 minutes on average, but block discovery is probabilistic: a confirmation can arrive much sooner or much later.

Each block has limited space, so miners have to choose which waiting transactions to include. They generally choose the ones that pay the most.

Why fees matter so much

Bitcoin.org explains the basics:

• Fees vary over time with demand for space in the blockchain.
• The fee is not related to the amount you send. It’s relative to the number of bytes in the transaction. Bitcoin.org notes you could send 100,000 bitcoins for the same fee as 1 bitcoin.
• Transactions that are larger in bytes, such as those spending many small amounts you received earlier, or using multisig, can cost more.
• If your transaction pays a fee below what the network is currently prioritizing, the first confirmation may take considerably longer.

So the usual cause of a stuck transaction is simple: you paid a fee rate that was fine when you sent it, or that your wallet guessed too low, and then demand went up.

Option 1 for senders: replace-by-fee (RBF)

Replace-by-fee lets you send a new version of the same transaction with a higher fee, replacing the stuck one.

It’s described in BIP 125, a Bitcoin Improvement Proposal. Its authors explained the problem: many nodes wouldn’t replace a transaction in their mempool with another spending the same coins, which made it difficult to adjust a transaction after unexpected confirmation delays. BIP 125 let wallets signal that a transaction could be replaced.

The main rules in BIP 125 include:

• the replacement must pay an absolute fee at least as high as the original;
• it must also pay for its own bandwidth at or above the node’s minimum relay fee, so the fee has to go up by a meaningful amount.

What’s changed since: Bitcoin Core’s mempoolfullrbf option let nodes accept replacements without requiring the BIP 125 signal. In version 28.0 its default changed to on, and in version 29.0 the option was removed, with the release notes describing full replace-by-fee as the standard behavior. In practice, whether you can bump a fee still depends on your wallet: it needs a “bump fee” or “speed up” option, and you need to control the coins being spent.

How to do it: in a wallet that supports it, open the pending transaction and look for “Bump fee”, “Speed up” or “Increase fee”. Choose a higher fee rate and confirm.

Option 2 for receivers: child pays for parent (CPFP)

If you’re receiving a stuck transaction, you can’t change the sender’s fee. But you can spend the incoming coins yourself.

Since Bitcoin Core 0.13.0, the mining software selects transactions based on their fee rate including unconfirmed ancestors. In the release notes’ words, a low-fee transaction can become more likely to be selected if a high-fee transaction that spends its outputs is relayed.

That’s child pays for parent: you create a new transaction (the child) that spends the unconfirmed coins (from the parent) with a generous fee. To collect the child’s fee, a miner has to include the parent too.

How to do it: some wallets offer CPFP directly. Otherwise, you can send the unconfirmed incoming coins to another address you control with a high enough fee to cover both transactions.

Senders can use CPFP too, by spending their own change output from the stuck transaction.

A worked example

These numbers are made up to show the arithmetic. Fees are set as a rate, in satoshis per virtual byte (sat/vB):

Bumping with RBF. Your transaction is 141 vbytes and paid 2 sat/vB, a fee of 282 sats. If transactions are now confirming at around 10 sat/vB, a replacement at 10 sat/vB would pay 1,410 sats. Under BIP 125, the replacement must pay at least the original’s absolute fee plus enough for its own relay, so the new fee always has to be clearly higher.

Bumping with CPFP. A miner looks at the parent and child together:

So the child must pay 3,300 sats for the pair to average 10 sat/vB. CPFP usually costs more than RBF, because you’re paying for the parent’s bytes as well as your own.

Behind the scenes: mempool limits and package relay

Each node keeps its own mempool, with limits. In Bitcoin Core’s current code:

• the mempool’s default maximum size is 300 MB;
• transactions expire after 336 hours (two weeks) by default;
• the default minimum relay fee is 100 satoshis per 1,000 virtual bytes, or 0.1 sat/vB.

A node can also have a mempool minimum fee rate, and a transaction below it may not be accepted. Bitcoin Core 28.0 addressed part of this with limited package relay: a low-fee parent can now travel together with its child as a package, even if the parent alone is below the node’s mempool minimum. The release notes warn that this is limited to one parent and one child, and not yet reliable against deliberate attacks.

Version 28.0 also introduced TRUC transactions (BIP 431), an opt-in set of rules designed to make fee bumping more reliable.

Option 3: wait

If you’re not in a hurry, waiting often works. Demand rises and falls, and a transaction that’s stuck at a busy time may confirm when the network is quieter.

If it never confirms, nodes eventually drop it. In Bitcoin Core, the reference node software, the default mempool expiry is 336 hours, or two weeks. After that, a node running the default settings forgets the transaction, and your wallet may let you spend the coins again. Other nodes may have different settings, and someone could rebroadcast it, so don’t assume it’s gone just because one explorer stops showing it.

How to avoid stuck transactions

1. Check the fee before you send. Bitcoin.org notes that most wallets it lists add what they think is an appropriate fee and let you review it.
2. Pick a fee rate for your urgency. If speed matters, pay more; if it can wait, a lower rate may be fine.
3. Use a wallet that supports fee bumping, so you have a way out.
4. Consolidate small amounts when fees are low, because spending many small inputs later makes transactions bigger in bytes.
5. For small, frequent payments, consider the Lightning Network, which Bitcoin.org describes as a payment layer on top of bitcoin with near-instant payments that typically cost less than a cent.

Watch out for “unstick” scams

A stuck transaction is a stressful moment, and scammers know it. No legitimate service needs your seed phrase, your keys or remote access to your device to speed up a transaction. Fee bumping is done from your own wallet. See seed phrase security and fake crypto apps and phishing.

For more on sending safely and on confirmations, see how to send crypto safely, what is a 51% attack? and what is bitcoin?