Fee estimation
Fee estimation is the process by which a wallet or node predicts the fee rate that will get a transaction confirmed within a target number of blocks. Bitcoin does not have a protocol-level fee. Miners select transactions from the mempool by policy, typically preferring higher fee rates. An estimate is therefore a forecast of the competitive fee market, not a consensus value. It is related to but distinct from the broader topic of Transaction fees.
Early Bitcoin clients used a static default fee. As block space became scarce, that default was either wasteful or insufficient. Bitcoin Core replaced it with an estimator that observes how long transactions at various fee rates actually take to confirm, and wallets query that estimator when they build a transaction. Third-party services publish fee recommendations from their own mempools. Those figures can differ from a local node's estimate because mempools and policy are not globally identical. After SegWit, estimates are usually expressed as satoshis per virtual byte (related to Weight units), not per raw serialized byte.
Bitcoin Core's long-standing estimator is CBlockPolicyEstimator. When a transaction enters the local mempool, the node records its fee rate in an exponentially spaced bucket. When the transaction later confirms, the estimator records how many blocks elapsed between first sighting and inclusion. Transactions that leave without confirming are recorded as failures. Moving averages over short, medium, and long horizons let old data decay. To answer a confirmation target of n blocks, the estimator walks from high fee-rate buckets toward lower ones and returns a rate at which a sufficient fraction of observed transactions confirmed within the target (with checks at n/2 and 2n). The estimatesmartfee RPC exposes this for targets from 1 to 1008 blocks. Conservative mode uses a longer history and tends to return a higher rate; economical mode tracks recent drops more closely and risks underpaying. The returned rate is at least the node's mempool minimum and minimum relay fee. A node without enough history cannot produce a reliable estimate.
Historical confirmation tracking can lag a sudden collapse in demand or under-react to a spike. Some wallets take the maximum of the Core estimate and a rate derived from the current mempool. Lightning and other time-sensitive protocols often use a short target and conservative mode, or they overshoot. On-chain wallets that can use Replace by fee may start with an economical estimate and bump later. Related package and child-pays-for-parent policies affect what fee is needed in practice; see Package relay.