Transaction fees, and what block space costs

A wallet does not know the future, so it estimates. The usual approach is to ask one or more connected nodes for their view of the mempool and to derive a rate from it. Bitcoin Core exposes an estimate that answers a specific question: what rate would be needed for a transaction to be confirmed within a given number of blocks, based on how the pool has behaved recently. The wallet picks a target — the next block, three blocks, six blocks — and uses the corresponding estimate.

The estimate is a forecast, and it can be wrong in both directions. If demand falls after the transaction is broadcast, the chosen rate turns out to have been generous and the sender overpaid. If demand rises, the rate turns out to have been too low and the transaction waits. This is not a flaw in the estimation so much as a property of a market where the price is discovered continuously and the supply of block space arrives in discrete lumps roughly every ten minutes.

Wallets differ in how much of this they expose. Some present a small set of named targets — economy, normal, priority — and translate them into rates behind the scenes. Others let the user set a rate directly. Either way, the underlying decision is the same: how much is it worth to be included sooner, given what is currently competing for the same space.

The fee market is a straightforward auction with an unusual supply curve. Supply is fixed per block and arrives on a schedule that the difficulty adjustment holds near ten minutes on average. Demand varies enormously: a surge of activity, a popular application, or a backlog of pending transactions can push the clearing rate up by an order of magnitude within hours, and it can fall back just as quickly once the backlog clears.

Because supply cannot expand to meet demand, the adjustment happens entirely through price and through waiting. When the mempool is crowded, transactions that bid below the prevailing rate are pushed out of the next block and into later ones. Miners, selecting by fee rate, fill each block from the top of the pool downward. The result is a distribution of waiting times rather than a single answer: a transaction at a given rate might confirm in the next block or in several, depending on what else arrives in the meantime.

This is also why fee spikes tend to be self-correcting. A high rate discourages marginal transactions, some senders defer, and the backlog that caused the spike is worked off. The market does not reach an equilibrium so much as oscillate around one, and the oscillation is visible in any mempool explorer as a rate that rises and falls through the day.

A sender who has already broadcast a transaction at too low a rate is not stuck permanently. Bitcoin provides two mechanisms for raising a fee after the fact, and they are covered on the replace-by-fee and child-pays-for-parent page. The transaction lifecycle page covers how a transaction reaches a block once its fee is competitive.