The mempool is not a queue: how fees buy block space

The short answer

A transaction confirms because a miner chose it. Miners choose by fee rate, meaning fee divided by the space the transaction takes up, out of whatever set of unconfirmed transactions their own machine holds when they build a block. That set is the mempool, and the important word is the possessive: it is theirs, not everyone's.

There is no queue, no ticket, no position in line, and nothing tracking a transaction between broadcast and block.

There is no such thing as "the" mempool

Every node that relays transactions keeps its own pool of unconfirmed ones, and no two are identical. Bitcoin Core's policy documentation says so in the first line: these rules are "local to the node and configurable", and they apply to unconfirmed transactions only (doc/policy/README.md).

Nodes differ for ordinary reasons: they started at different times, heard about transactions in different orders over different peer sets, have different limits configured, and some run software with different relay rules entirely. So a "pending" transaction is not in a state the network agrees on. It is present on some machines and absent on others, and the mempool chart on a block explorer is one node's view rather than an authority.

Fee rate, not fee

Block space is capped by weight, not by byte count: at most 4,000,000 weight units per block (BIP 141, and SegWit and what a block weighs has that accounting in full). Divide weight by four, round up, and you get virtual bytes, the unit fees are quoted in. A block therefore holds about 1,000,000 vB, and a byte in the witness costs a quarter of one outside it.

A miner filling a finite block wants the most fee per unit of space, so the sort key is sats per virtual byte and the total fee is nearly irrelevant.

A pays nearly four times as much and loses. In the space A wants, a miner can fit fifteen transactions like B and collect 120,000 sats. A large fee attached to a large transaction is a low bid. It is also the mechanism under every fee spike the network has had, including the one in May 2023, and the reason sweeping up a pile of small outputs is cheap advice and an expensive transaction.

Since Bitcoin Core 31.0, released 20 April 2026, the unit being sorted is not always one transaction: related transactions are grouped into "chunks", a parent and the children that only make sense alongside it, and blocks take the highest rate chunks first (doc/policy/mempool-design.md). The principle is unchanged. Highest rate per unit of space, first.

Relay policy is stricter than consensus

A block is valid if it satisfies the consensus rules. A transaction is relayed if it also satisfies the node's policy, which is a separate and narrower set applied "before submitting them to the mempool", and, in the README's words, "not applied to transactions in blocks."

Three policy rules cause most of the surprises. Defaults as of Bitcoin Core 31.0:

• Minimum relay fee. Below -minrelaytxfee a node will not accept a transaction at all. The default was 1 sat/vB for years and was lowered to 0.1 sat/vB in version 30.0 on 13 October 2025, with the warning that until the lower default is widely adopted, transactions built at those rates "are not guaranteed to propagate or confirm".
• Dust. An output worth less than it would cost to spend is refused. At the default dust feerate of 3,000 sat/kvB that threshold is 546 sats for a legacy output and 294 sats for a P2WPKH one (src/policy/policy.cpp). One narrow exception exists: a zero fee transaction may create a single dust output if a child in the same package spends it.
• Standardness. Script forms outside a known list, transactions over 400,000 weight units, oversized scriptSigs and unrecognised transaction versions are all declined (src/policy/policy.h).

None of these make a transaction invalid. A miner who receives one by another route can put it in a block and every node will accept that block, because policy stopped applying the moment it was mined. That gap is the whole subject of the 2025 argument over the OP_RETURN relay default, which produced a signed statement on relay policy from 31 contributors. A transaction can be perfectly valid, perfectly signed, and simply not carried.

Mempools forget

A mempool is a memory buffer with a size limit, 300 MB by default. When it fills, the node evicts the worst chunk it holds and raises its own minimum acceptance rate to the rate it just evicted plus a small increment, so the same transaction cannot walk straight back in. That floor decays on a half-life once space frees up. Anything unconfirmed after -mempoolexpiry hours is dropped, and the default is 336 hours, two weeks (src/kernel/mempool_options.h).

So a low-rate transaction does not wait indefinitely, and the busiest nodes drop it first, during exactly the periods when it would need luck to confirm. Until it is mined, a transaction is not stored anywhere permanent. The copy that survives is in the sending wallet, which is why wallets rebroadcast and why a transaction can reappear days after it seemed gone.

Getting unstuck

Two mechanisms, with different requirements and different bills.

Replace by fee, RBF

Broadcast a new transaction spending at least one of the same inputs, paying more. Bitcoin Core 31.0 accepts the replacement under four conditions: it pays "an absolute fee of at least the sum paid by the original transactions"; the difference covers the replacement's own bandwidth at the incremental relay feerate, 0.1 sat/vB by default; it conflicts with no more than 100 clusters; and "the feerate diagram of the mempool must be strictly improved". For a transaction with no unconfirmed relatives that last condition reduces to the intuitive rule: higher fee and higher rate than the one it replaces.

Note what is gone. BIP 125 made replacement opt-in, signalled by an input sequence number below 0xfffffffe, and its rule 1 required that signal. Full replace-by-fee became the default in Bitcoin Core 28.0 in October 2024, and the switch to turn it off was removed in 29.0. A wallet promising that its transactions cannot be replaced is describing an old default rather than a rule.

RBF needs the keys behind the original inputs, so only the sender can do it.

Child pays for parent, CPFP

Spend an output of the stuck transaction with a new transaction paying a high rate. The child cannot confirm before the parent, so a miner who wants the child has to take the parent with it, and the pair is judged on their combined fee over their combined size.

CPFP is available to whoever holds one of the outputs, which often means the receiver rather than the sender. The price is that the child pays for its own virtual bytes as well as lifting the average of the pair, so rescuing a large low-rate parent with a small child is expensive. The parent also has to be in the miner's mempool at all. Package relay covers part of that gap by letting a low fee or zero fee parent travel with its child, and 31.0 widened it beyond the restricted transaction type it first applied to.

Why fee estimation is genuinely hard

An estimator is not looking anything up. It is forecasting what strangers will bid over the next few blocks, and the demand is not observable in advance: a mint, an exchange consolidating outputs, a rush of withdrawals, none of it is announced.

Bitcoin Core's estimator watches how long transactions in each fee rate bucket historically took to confirm, over three time horizons, and answers a confirmation target with a rate that worked before. Saved estimates are discarded after 60 hours, since older data may no longer describe the network.

Blocks also do not arrive on schedule. Ten minutes is an average, not a cadence, and a slow stretch leaves the same demand stacked behind fewer of them. An estimate is a probability, and a wallet showing "confirms in 1 block" for a fixed price is rounding a distribution into a promise.

What none of this does

A high fee rate does not buy a guarantee. It buys a good position in a sort each miner performs independently, on their own copy of the pending set, under their own policy. Nobody is obliged to include a transaction, and there is no refund for losing.

Nothing can cancel a broadcast transaction either. A conflicting replacement competes rather than deletes: if a miner already holds the original and mines it before the replacement arrives, the original is the one that confirms. Wallet buttons labelled "cancel" are sending a replacement that pays the funds back to the sender.

And none of it touches ownership or issuance. Fees decide the order in which transactions are written down. They do not change who controls a coin, and they have no effect on the 21 million limit or the schedule that approaches it. The auction is over space in the next block, and over nothing else.

Sources

• Bitcoin Core policy docs: README, mempool design and limits, mempool replacements
• Bitcoin Core release notes: 31.0, 30.0, 29.0, 28.0
• Bitcoin Core contributors, statement on relay policy, 6 June 2025
• BIP 125, opt-in full replace-by-fee signalling
• BIP 141, block weight and virtual transaction size