Bitcoin Fee Estimation: Fee Rate, vBytes and Targets

Bitcoin fee estimation turns a confirmation target and transaction size into a fee-rate forecast. A wallet cannot know the exact fee required for the next block, so it relies on observed confirmation behavior, local mempool data and a target such as “within six blocks.” The result is not a quote or guarantee.

Fee rate, fee and virtual size

Bitcoin transaction fees are usually chosen from a fee rate and transaction size.

fee = fee rate × virtual size

Wallets commonly display fee rate in satoshis per virtual byte, or sat/vB. Bitcoin Core’s estimatesmartfee returns a rate in BTC per 1,000 virtual bytes, so applications must convert units carefully.

Virtual size accounts for the witness discount introduced with SegWit. Two transactions that move the same amount of bitcoin can have different virtual sizes because they use different numbers and types of inputs and outputs.

The amount being sent does not directly set the network fee. A transaction spending many small UTXOs can be larger and cost more than a transaction spending one large UTXO.

What Bitcoin Core estimates

Bitcoin Core 30.0 documents estimatesmartfee as estimating the fee rate needed for a transaction to begin confirmation within a requested number of blocks, if possible.

The required conf_target is a number from 1 to 1,008. The node can return:

• feerate, when it has an estimate;
• blocks, the target actually used;
• errors, when it cannot produce an estimate.

The requested target can be clamped to the range for which the node has enough history. A new or poorly connected node may not have enough observations to estimate any target.

An application should handle a missing estimate explicitly. Treating it as zero can create a transaction that remains unconfirmed.

Economical and conservative modes

Bitcoin Core exposes two named modes.

Economical responds more quickly to falling fee conditions and may choose a lower rate. It can carry more risk of missing the target when congestion rises.

Conservative uses a longer horizon and is less responsive to short-term drops. It may overpay compared with the economical estimate but aims to reduce the risk of underestimating.

The right mode depends on the payment. A time-sensitive withdrawal and a wallet consolidation do not have the same urgency.

Do not convert these modes into promises such as “guaranteed next block.” Miners choose transactions, blocks have limited space and new transactions keep arriving.

Mempool state is local

Each node maintains its own mempool according to its policy and the transactions it has received. Two nodes can therefore see different backlogs.

A public fee website can be useful for context, but its recommendation is not the same as the estimate from the node that will create or broadcast the transaction. Record the source and time if a payment system overrides its wallet’s estimate.

Mempool conditions can change between construction, signing and broadcast. Long offline-signing workflows should refresh the funding proposal when possible rather than assuming an old rate remains appropriate.

Inputs and outputs drive size

A Bitcoin transaction spends unspent transaction outputs, or UTXOs. The Bitcoin developer guide explains that every input spends a previous output and every new output waits to be spent later.

A wallet choosing coins needs enough inputs to cover:

• the payment outputs;
• the fee;
• usually a change output.

More inputs usually mean more virtual bytes. Script type also matters. A rough calculator that counts only recipients will miss the cost of the inputs.

Coin selection can also create or avoid small change. If change would be uneconomical to spend later, the wallet can use a different selection or add the remainder to the fee, subject to its policy.

A worked calculation

Suppose a signed transaction has a virtual size of 180 vB and the wallet chooses 12 sat/vB.

180 vB × 12 sat/vB = 2,160 satoshis

At 35 sat/vB:

180 vB × 35 sat/vB = 6,300 satoshis

The bitcoin amount sent can be identical in both cases. The fee changes because the selected rate changes.

This example is illustrative. It is not a live fee recommendation.

Confirmation targets are probabilities

A target of six blocks means the estimator is selecting a rate associated with confirmation within that horizon under its model and observed history. It does not reserve space in a future block.

A responsible interface should show:

• the selected fee rate;
• estimated total fee;
• virtual size;
• confirmation target;
• estimate mode;
• estimate source and time;
• whether the transaction can be fee-bumped;
• any maximum-fee guardrail.

The label should say “estimated,” not “will confirm.”

Fee bumping needs a policy

If a transaction remains unconfirmed, a wallet may be able to raise its effective fee.

Replace-by-fee, or RBF, creates a replacement transaction under network policy. Child pays for parent, or CPFP, spends an output from the original transaction with a high enough fee that miners have an incentive to include the package.

Those mechanisms have different ownership and wallet requirements. Before broadcasting, record whether the transaction signals replaceability and whether the sender or recipient controls a suitable output.

Webtamine’s Bitcoin PSBT guide shows why an offline or multisignature workflow must carry the proposed inputs, outputs and fees through several signers. A replacement may require the same approval process again.

Set guardrails before automation

An automated withdrawal service should not blindly accept any estimator output.

Useful controls include:

• minimum and maximum fee rates;
• maximum total fee;
• maximum fee as a proportion of the payment;
• transaction-size limit;
• alert when the estimate is unavailable;
• separate policies for urgent and non-urgent payments;
• approval for unusually expensive consolidation;
• idempotent withdrawal creation;
• monitoring for transactions that miss their target.

A maximum can protect against extreme or malformed values, but an excessively low cap can prevent a valid urgent payment. The system should fail clearly and route the case for review.

Test the unit conversions

Common implementation errors include:

• treating BTC/kvB as sat/vB;
• confusing virtual bytes with raw bytes;
• rounding a rate down too early;
• applying the rate to the payment amount;
• ignoring the change output;
• building the transaction with a different set of inputs after estimating;
• displaying one rate while the signed transaction uses another.

Test with known transactions and inspect the final signed virtual size. Do not claim hands-on performance unless the test was actually run and documented.