The Queue That Doesn't Always Respect Your Bid

You paid three times the recommended rate. You leaned back. The transaction was supposed to sail through in the next block, and instead you're watching the clock tick past ten minutes, twenty, an hour, while other transactions that paid less have long since confirmed.

Not a glitch. The mempool is doing exactly what it's designed to do, just not in the way most guides bother to explain.

How Miners Actually Pick Transactions

Bitcoin miners don't process transactions in the order they arrive. They build blocks to maximise revenue, which means they sort pending transactions by fee rate: satoshis paid per virtual byte (sat/vB) of transaction data, not the total fee in absolute terms.

Here's the wrinkle most people skip. A transaction's size in virtual bytes is not fixed. It depends on the number of inputs and outputs, the script type, and whether SegWit or Taproot addresses are involved. A simple send from a single Taproot input to one recipient might weigh around 57 vB. A transaction consolidating eight old legacy inputs to one output could weigh 1,200 vB or more.

Consider two transactions sitting in the mempool at the same moment:

  • Transaction A: total fee of 3,000 satoshis, size of 250 vB. Fee rate: 12 sat/vB.
  • Transaction B: total fee of 800 satoshis, size of 57 vB. Fee rate: 14 sat/vB.

Transaction B gets picked first. Every time. A miner filling a 1 MB block wants the highest fee-rate density, not the biggest individual tip. Think of it like a courier van packing parcels: a small, well-paying package beats a bulky low-margin one even if the bulky one's sticker price is higher.

This is the single most common misunderstanding about Bitcoin fee priority, and it costs people real money.

What the Mempool Actually Looks Like

The mempool is the waiting room: a pool of unconfirmed transactions held by each full node, waiting to be included in a block. Its size fluctuates constantly. During quiet periods it can clear almost entirely, with only a few hundred transactions waiting. During congestion events, it can swell to hundreds of thousands of transactions representing many megabytes of backlog.

Miners typically sort their mempool by fee rate and fill blocks from the top down, stopping when the block weight limit (4 million weight units under SegWit rules) is reached. Any transaction below the current clearing fee rate gets bumped to the next block, or the one after, or whenever congestion eases.

The catch: miners are not all running identical software with identical settings. Some mining pools apply minimum fee thresholds. Some reserve a small slice of block space for lower-fee transactions, out of policy or to keep the mempool from becoming a pure auction. A transaction you'd expect to be excluded might sneak through depending on which pool mines the next block.

Still, the dominant logic is fee rate. Everything else is noise around the edges.

Three Scenarios Where Your High Fee Fails You

The CPFP trap. Suppose you receive a transaction from someone who paid 2 sat/vB, far too low to confirm. You then spend that output in a new transaction, paying 50 sat/vB. Miners see these as a package: to include your spend, they must first include the parent. The combined fee rate of both transactions, calculated together, may still fall short of the threshold. Your generous fee is being dragged down by a parent you didn't send. Child-Pays-For-Parent (CPFP) is the official rescue mechanism, but it only works when the combined package rate clears the bar.

The RBF timing problem. Replace-By-Fee lets a sender rebroadcast a transaction with a higher fee to bump the original out of the mempool. But if a miner picks up the original in the fraction of a second before your replacement propagates across the network, both can briefly coexist in different nodes' mempools. The replacement wins eventually. The window, though, creates brief and maddening ambiguity.

Mempool clearing between submission and mining. You submitted during peak congestion, paying 40 sat/vB, a rate that was genuinely high at the time. Two hours later the mempool drains, and the clearing rate drops to 3 sat/vB. You overpaid significantly. Frustrating, but manageable. The reverse is the real danger: you set a fee based on a quiet mempool, a wave of transactions floods in, and your 4 sat/vB suddenly looks underdressed.

What People Get Wrong About "Recommended" Fees

Fee estimation tools sample recent blocks and try to predict what rate will clear in the next one, two, or six blocks. Backward-looking models. Applied to a forward-looking problem.

The better ones (Bitcoin Core's built-in estimator, mempool.space fee estimates) weight recent data heavily and flag uncertainty. The worse ones average the last few blocks and call it done. The real-world variance between those two approaches is significant, and most people have no idea which category their wallet falls into.

Here's a worked example. Two people, Priya and Marcus, submit transactions on the same afternoon. Priya's wallet queries a live mempool API and suggests 18 sat/vB. Marcus uses an older wallet with a static fee table that suggests 10 sat/vB. Both transactions enter the mempool within minutes of each other. If the mempool stays calm, Marcus confirms in the next block too. If a surge hits, Priya is in and Marcus waits hours. Same afternoon, meaningfully different outcomes, and neither of them did anything wrong. The difference is entirely the quality of the fee estimate.

Ever watched a "slow" transaction confirm before your "fast" one? That's fee rate versus absolute fee confusion, playing out in real time.

How to Actually Control Confirmation Speed

A few things that genuinely help:

  • Set fees in sat/vB, not total satoshis. Any wallet that hides this number is hiding the only number that matters.
  • Use SegWit or Taproot addresses. Their transactions are lighter in virtual bytes, so the same sat/vB rate costs you less in absolute terms. A Taproot send is roughly 40% lighter than an equivalent legacy P2PKH transaction.
  • Check the live mempool before sending, not just the wallet's default estimate. Tools like mempool.space show the current fee-rate histogram, letting you see exactly which rate clears in the next block versus the next hour.
  • Understand RBF before you need it. If your wallet supports opt-in Replace-By-Fee (signalled in the transaction itself), you can raise your fee later. If it doesn't, you're waiting or hoping for CPFP.

The mempool is not a post office where you pay for express and receive express. It's a commodities pit where the price of urgency shifts by the minute, and the unit of currency is satoshis per byte, not satoshis per transaction. Get the unit wrong, and a generous fee still leaves you waiting while someone who paid less, but paid smarter, is already confirmed.