Why bitcoin transactions can be slow

Bitcoin is conceived with an average block time ≈ 10 minutes, but this is an average, not a guarantee. If your transaction is stuck, a crowded mempool and/or too low a byte fee are almost always to blame. Add to this the recipient's requirements for the number of confirmations, the size of the transaction itself (in virtual bytes) and the wallet policy - and you get noticeable differences in delivery time.

In short: where does it come from "slowly"

1. Crowded mempool. When there are more unconfirmed transactions than "fit" into the nearest blocks, an auction of commissions begins.

2. Low fee rate (sat/vB). Miners take into the transaction block with the highest price for a virtual byte - not the total amount of the commission.

3. Large transaction by weight. Many inputs (UTXO), old address formats (Legacy) → higher weight → more expensive/longer at the same fee rate.

4. Variability of block time. Intervals "natively" fluctuate: it can be obtained in 20 seconds, or maybe in 40 + minutes.

5. Recipient policies. Exchanges/services are waiting for 1-6 confirmations and sometimes more during peak hours.

6. Wallet restrictions. Not everyone supports RBF/CPFP, does not know how to adequately overestimate fee, put a "economical" profile by default.

How it works "under the hood"

Mempool - a buffer of unconfirmed transactions in all nodes. Nodes can discard transactions that are too cheap.

Transaction weight is measured in vB (virtual bytes). Inclusion is affected by the price per vB (sat/vB).

The block has a weight units limit, so miners sort by sat/vB benefit, forming an "entry threshold" to the nearest block.

RBF (Replace-By-Fee) allows the sender to replace an unconfirmed transaction with a higher fee version.

CPFP (Child-Pays-For-Parent) allows the recipient/owner of the exit to speed up confirmation: spend the resulting "parent" exit by putting a high commission on the "child" transaction.

Frequent causes of delays and what to do

Reason	What it looks like	Decision
Low sat/vB set	"Hanging" for hours/days	If supported - RBF with increased fee; otherwise, wait or ask the recipient to do CPFP
Peak load (mempool full)	The "threshold" in the block has risen sharply	Wait for the decline; raise fee to the current level; for the future - send out of spikes
Many inputs (UTXO consolidation)	Transaction "thick," expensive to speed up	Consolidate UTXO in advance when the mempool is empty; use SegWit/bech32
Legacy-addresses	More weight under equal conditions	Switch to bech32 (bc1... )/SegWit → less weight and commission
Tough exchange policy on confirmations	The block already has, but no enrollment	Check requirements (1-6 + conf); wait; for the future - translate earlier/via Lightning
Wallet without RBF/CPFP	You cannot "throw" the commission	Use a wallet with RBF; for incoming - negotiate CPFP

Practice: how to properly evaluate the commission

1. See not the "satoshi commission," but the price per weight - sat/vB.

2. Select the target by confirmations (in the next block/in 1-3 blocks/sparingly).

3. Consider the weight of the transaction. Many inputs = above vB → need the highest price per vB for the same speed.

4. Use SegWit/bech32. This reduces weight without additional risks.

5. Keep stock on fee. Especially if you send at the time of peak load.

Speeding Up Stuck Translations: Working Methods

1) RBF (Replace-By-Fee)

Available if the original transaction was marked as replaceable.

Send a "replacement" with a higher sat/vB. Nodes and miners will prefer the new version.

2) CPFP (Child-Pays-For-Parent)

Suitable when you control the exit from the "parent" transaction.

Create a "child" with a very high sat/vB to make the total package profitable for the miner.

3) Accelerator pools (optional)

Some mining pools offer paid/partner accelerators. Assess the risks and conditions.

How to reduce the risk of delays in advance

Use bech32 (bc1...) and SegWit - less weight = cheaper and faster at the same price per vB.

Consolidate UTXO during quiet periods (low fees): Combine small entrances into one.

Plan your time. Send transfers outside of peaks (when the mempool is unloaded).

Set an adequate fee profile. For "next block" - pay market price per vB.

Choose a wallet with RBF and manual commission setup. It's hard to control speed without that.

Discuss the recipient's requirements. If the exchange is waiting for 3-6 confirmations, take this into account in the deadline.

For small/term payments, consider Lightning (if supported by both parties).

Lightning and L2 as' plan B'

Lightning Network gives transfers in seconds and pennies, but requires support from the sender and recipient, and also has channel limits.

Some sites accept BTC through Lightning or through custodial integrations - this is a good option for urgent small amounts.

For the ETH - L2 ecosystem (Arbitrum/Optimism/Polygon): If you translate stablecoins/tokens instead of BTC, it can be faster and cheaper.

Check sheets

Before sending BTC

Recipient address verified; bech32 format is preferred.
The wallet supports RBF and manual sat/vB selection.
I understand the required confirmations from the recipient (exchange/service).
Adequate fee rate selected for Next Block/1-3 Block target.
No dozens of small UTXOs; if necessary, consolidation in advance.

If the transaction is "stuck"

Checked it in the browser (whether there are conflicts/replacements, how much time is in the mempool).
RBF is available → has sent a higher sat/vB replacement.
CPFP is possible → has created a high fee child.
If nothing, I'm waiting for the load to drop; notified the recipient of the status/plan.

Common mistakes and how to avoid them

Mistake	Why bad	What to do
Focus on "fee amount," not sat/vB	Miners care about price per byte, not absolute amount	See sat/vB, consider the weight of the transaction
Legacy addresses and heap of inputs	Thick Transaction, Low Priority	Move to SegWit/bech32, consolidate UTXO in advance
Wallet without RBF	Nothing to accelerate	Choose wallets with RBF/CPFP
Dispatch "during rush hour"	Overpayment or delay	Plan time, bet market fee
Ignoring the recipient's claims	"No money," although 0 conf is already there	Find out how many confirmations you need in advance

FAQ (short)

How much is "normal" to wait for confirmation?

At quiet time and with adequate sat/vB - 10-60 minutes (1-3 confirmations). During peak hours - longer.

If I put a huge commission - will it be instant?

There are no guarantees due to the variability of the block time, but the chances of getting into the next block are sharply higher.

Is it possible to "drop" the commission after sending?

Yes, if the transaction was RBF-replaceable. Otherwise, only CPFP (if you control the received output), or wait.

Why doesn't the exchange enroll if my transaction is already on the block?

The exchange may require multiple confirmations. It's her risk policy.

Slow bitcoin transfers are not a "network breakdown," but a pattern of market auction of commissions and limited bandwidth of blocks. Control sat/vB, use SegWit/bech32, schedule time, keep RBF/CPFP on hand and consider recipient rules. Then your BTC transactions will be as predictable as possible - without unnecessary nerves and protracted "Pending."