Bitcoin Fee Estimation: How to Set the Right Transaction Fee

How Bitcoin Fees Work

Bitcoin transaction fees are paid to miners for including your transaction in a block. Unlike traditional payment networks with flat fees, Bitcoin fees are based on the size of your transaction data (measured in virtual bytes or vBytes), not the amount being sent.

A simple transaction sending from one input to one output might be 140 vBytes, while a transaction with many inputs could be 500+ vBytes. The fee rate (satoshis per vByte) determines how quickly miners will pick up your transaction. Higher fee rates get confirmed faster because miners prioritize the most profitable transactions.

Using estimatesmartfee

Bitcoin Core's estimatesmartfee command is the primary tool for fee estimation. It takes a target number of blocks and returns the recommended fee rate:

bitcoin-cli estimatesmartfee 6

This asks: what fee rate should I pay to get confirmed within 6 blocks (roughly 1 hour)? The response includes the feerate in BTC/kvB (kilobyte, not kilo-vByte).

The command accepts a conf_target from 1 to 1008 blocks. Lower targets mean faster confirmation but higher fees. For most use cases: 1-2 blocks for urgent payments, 6 blocks for normal, 12-24 blocks for low-priority, and 144+ blocks (1+ day) for batched operations.

The optional estimate_mode parameter lets you choose between CONSERVATIVE (higher estimates, less likely to underpay) and ECONOMICAL (lower estimates based on shorter history). Use CONSERVATIVE for important payments and ECONOMICAL for transactions where slight delays are acceptable.

Reading the Mempool

For more granular fee analysis, you can examine the mempool directly. getmempoolinfo gives you an overview: how many transactions are waiting, the total size in bytes, and the minimum fee rate the mempool is accepting.

The mempoolminfee field is particularly useful — if the mempool is full, this value rises above the default minimum relay fee, meaning very low-fee transactions won't even be accepted by nodes.

For deeper analysis, getrawmempool with verbose=true returns every transaction in the mempool with its fee, size, and dependency information. This data lets you build a precise picture of the current fee market.

Fee Bumping with RBF

If you set a fee too low, Replace-By-Fee (RBF) lets you increase it after broadcasting. This requires the original transaction to be marked as replaceable (sequence number < 0xfffffffe).

The bumpfee command takes the original txid and creates a replacement transaction with a higher fee. You can specify a target confirmation time or an explicit fee rate.

Best practice: always create transactions with the replaceable flag enabled. The cost is zero, and it gives you an escape valve if the fee market moves against you.

Fee Optimization Strategies

Several strategies can significantly reduce your transaction costs:

UTXO consolidation — when fees are low (weekends, holidays), consolidate many small UTXOs into fewer large ones. This reduces the input count (and therefore the size and fee) of future transactions.

Batching — instead of sending 10 separate transactions, combine them into one transaction with 10 outputs. The overhead of a single transaction is amortized across all payments.

SegWit — always use native SegWit (bech32) addresses. They produce smaller transaction data than legacy or wrapped SegWit formats, directly reducing fees.

Timing — the fee market has predictable patterns. Fees tend to be lowest on weekends and during off-peak hours in US/European time zones. For non-urgent transactions, waiting for a dip can save 50-80% on fees.