Bitcoin Transaction Fees Explained: sats/vB, Mempools, and Fee Bumping

A Bitcoin transaction spends one or more unspent transaction outputs and creates new outputs. The difference between the total value of its inputs and outputs is the transaction fee. The fee is collected by the miner whose block includes the transaction. It is not a percentage that the protocol deducts from the amount sent, and it is not the same thing as a wallet provider's service charge.

Transactions compete for limited block space. A miner building a block can consider the fees offered by transactions and how they depend on one another. A higher fee rate can make a transaction more attractive when other conditions are similar, but it does not reserve a fixed place in the next block. The eventual outcome depends on the fee market, transaction dependencies, miner selection, and whether the transaction reaches the relevant nodes.

This guide is about on-chain Bitcoin transactions using the Bitcoin network. An exchange withdrawal can include an exchange's own charge, and a Lightning payment uses a different transaction path and fee structure. A wallet may combine several cost items on one screen, so identify whether a displayed number is the network fee, a service fee, or both. Bitcoin.org's fee guide explains the relationship between transaction size, sat/vB, and block-space demand.

The total fee is the number of satoshis paid for the transaction. The fee rate expresses that fee in satoshis per virtual byte, written sat/vB. Divide the total fee by the transaction's virtual size to get the rate; multiply the virtual size by the chosen rate to estimate the total fee. Wallets often let you choose or review a rate because transactions of different sizes can pay different totals at the same rate.

For example, suppose a hypothetical transaction is 140 vB and uses 25 sat/vB. Its fee is 140 × 25 = 3,500 satoshis. Since 1 BTC equals 100,000,000 satoshis, 3,500 sats is 0.000035 BTC. If the same-size transaction instead used 40 sat/vB, the fee would be 5,600 sats, or 0.000056 BTC. These figures demonstrate the arithmetic; they are not current fee estimates or a recommendation.

A fee rate is not the transaction's percentage cost relative to its payment amount. Two transactions sending different BTC amounts can have the same fee if their virtual sizes and fee rates are the same. A small payment can cost more than a larger one if it needs more input data or uses a higher fee rate. The change output matters too: when the inputs exceed the payment, the transaction may return the difference to the sender as change, and that extra output takes space.

Bitcoin wallets generally calculate fees using virtual size, or vsize, rather than just counting every serialized byte equally. Under SegWit, transaction data has a weight. BIP 141 defines the transaction weight as three times the base size plus the total size, where total size includes witness data. In shorthand, weight = 3 × base size + total size; vsize = weight ÷ 4, rounded up to the next whole virtual byte. The formula accounts for the different weight assigned to witness data; it is not simply the raw file size.

Inputs and outputs contribute different amounts of data. An input must refer to a previous output and provide data that satisfies its spending conditions. The exact size depends on the output type and the unlocking data, including signatures. An output specifies a value and a locking script. As a result, a transaction with several small inputs can be larger than one with a single input even if both send the same total amount.

The number of inputs can matter especially when a wallet combines many small received outputs to fund a payment. The transaction must spend each selected output, and each input adds data. A wallet may also create a change output, adding more bytes. Different address and script types can have different sizes, and signature lengths can vary. A displayed “typical transaction” size is therefore only an example, not a fixed size for every Bitcoin payment.

The wallet's estimate may change when you select different coins, add recipients, choose a different change address type, or change the fee rate. This is why checking only the payment amount is not enough. The transaction's composition determines its vsize; the fee rate determines how many satoshis are offered for each vB. BIP 141 defines the virtual-size calculation used to account for witness data.

After broadcast, a transaction may be held in the memory pool, or mempool, of nodes that have received and accepted it. A mempool is a node's local set of unconfirmed transactions, not a single synchronized queue shared by the entire network. Nodes can see transactions in a different order, apply different relay policies, have different capacity limits, or not receive a particular transaction at all.

Miners choose transactions for candidate blocks from the transactions they know about, subject to consensus rules and their selection policies. Transactions that spend outputs created by other unconfirmed transactions have dependencies. In those cases, a miner may assess a parent together with one or more descendants rather than treating each transaction as an independent entry with a standalone rate. This can make a simple “rank number” shown by a third-party website incomplete or temporary.

When more users compete for space, the fee rates likely to be included sooner can rise. When demand eases, transactions with lower rates may become more competitive. The amount of competition and the transactions already known to a wallet or node can change quickly. A transaction appearing in one explorer or wallet's mempool view does not prove that every miner or node has the same view.

A transaction not shown as confirmed is still unconfirmed; the label alone does not mean it is lost or invalid. Depending on node policies and changing mempool conditions, an unconfirmed transaction can stop appearing in one node's mempool and may later be rebroadcast or accepted again. If your wallet still lists it as pending, do not assume that its inputs are already available for another payment. Review the transaction status and the wallet's official instructions before attempting another spend.

A wallet may present fee options such as economy, normal, or priority, or show a target number of blocks. These are estimates of what fee rate may be competitive under observed conditions. Bitcoin Core's fee-estimation documentation describes an approximate rate intended to begin confirmation within a target when the estimator has enough history. If recent data is insufficient, an estimate may be unavailable. Other wallets and services can use different data, models, refresh intervals, and target definitions.

A “next block” target does not mean that inclusion is promised in the next block. The transaction can arrive after the conditions used for the estimate have changed, and new higher-fee transactions can compete for space. A block can also include transactions with dependencies that affect selection. The target is an input to an estimate, not a contract with a miner.

Check when the fee quote was refreshed and whether the wallet shows the rate or only a total. If the transaction is not urgent, a lower rate can be a deliberate choice to wait, but the time to confirmation is uncertain. If it is time-sensitive, compare the wallet's estimate with a current fee source and understand what the wallet will do if conditions change. Raising the fee “just in case” can cost more without guaranteeing a particular block.

A rate quoted by an estimator also does not determine the minimum rate every node will accept for relay. Relay policy, mempool limits, wallet settings, and confirmation estimates answer related but different questions. Bitcoin Core's mempool design document describes how transaction dependencies affect selection and replacement policy. Do not treat one software release or one node's policy as a permanent network-wide rule.

Replace-by-fee, or RBF, is a way to replace an unconfirmed transaction with a conflicting transaction that pays a higher fee, when the wallet and relevant node policies allow it. The replacement spends at least one of the same inputs, so the conflicting versions cannot both confirm as valid spends of that same input. A wallet may provide a “bump fee” control, but the option, its requirements, and the resulting fee depend on the wallet and the transaction.

Do not rely on an old rule of thumb that a transaction must always advertise RBF in a particular way before it can be replaced. Bitcoin Core's current policy documents full RBF as the default policy since version 28.0 and state that signaling is no longer required for replacement under that policy. Other nodes, wallets, services, or older software can behave differently. A wallet's button being unavailable does not mean that every node shares the same policy; it may reflect the wallet's own limitations or the transaction structure.

A replacement generally needs to satisfy more than “add one satoshi.” Under Bitcoin Core's current policy, it must pay at least the combined absolute fees of the original transactions, cover the replacement's additional relay bandwidth, and improve the mempool's fee-rate diagram. Linked transactions can make the calculation more involved than simply choosing a higher number. The current replacement policy describes the conditions.

RBF is not an undo button and it does not reverse a confirmed transaction. It is a competing unconfirmed spend. A recipient who treats an unconfirmed payment as final can face replacement risk, which is why an unconfirmed transaction is not equivalent to a confirmed payment. For a transfer you are receiving, follow the recipient service's confirmation policy instead of assuming that the first version seen will be the one confirmed.

Child pays for parent, or CPFP, uses a new child transaction that spends an output of an unconfirmed parent. The child can offer a high enough fee rate that a miner has an incentive to include both transactions together. The combined fee and combined virtual size are relevant; the child does not erase the parent's fee or make the two transactions free to combine.

A wallet needs control of a suitable unconfirmed output and support for constructing the child. The parent-child relationship, relay and package policies, and miner selection all matter. The combined fee may be greater than the fee you would have chosen for a single transaction, and inclusion is still not guaranteed. Do not create a child transaction manually unless you understand which output it spends and how the wallet manages change.

RBF and CPFP solve related but different situations. RBF creates a conflicting version of a pending transaction. CPFP adds a dependent transaction that may improve the incentive to mine the parent-child package. A wallet may support one, both, or neither. Bitcoin Core's mempool design and version-specific policy determine what a node accepts, so these are mechanisms, not promises about confirmation time.

An exchange may set a withdrawal charge in its own fee schedule. It can be fixed, adjusted periodically, or reflect how the exchange handles batches of customer withdrawals. That amount need not equal the fee rate for one individually broadcast transaction. An exchange might group withdrawals into one transaction, while a self-custody wallet usually builds a transaction for the outputs you selected.

Before withdrawing, inspect whether the screen lists a withdrawal charge, the amount that will arrive, and the destination network. Do not infer that the exchange's fee reveals the live sat/vB rate. If a platform labels a charge “network fee,” it may still be a platform-calculated amount rather than a direct fee estimate for your specific transaction. Check the platform's published schedule and preview details.

The reverse also matters: a wallet may show the network fee without any provider charge. A Bitcoin on-chain fee is paid by the transaction that is included in a block; the wallet interface does not collect it as a percentage of the transfer. If you are comparing an exchange withdrawal with an on-chain wallet send, compare what the recipient receives, the selected network, and the separate fee lines. For network and address checks before sending, use the crypto transfer checklist. For how Ethereum calculates its distinct gas fee, see the Ethereum gas fee guide.

Before confirming a Bitcoin payment, check the network, recipient address, amount, total fee, and fee rate if the wallet shows it. Confirm whether the payment is an on-chain Bitcoin transaction or a different route. Look at the fee preview after selecting recipients and inputs, because changing the transaction can change its virtual size and therefore its total fee at the same rate.

If a transaction is pending, identify whether the wallet supports RBF or CPFP and what conditions apply before acting. Do not resend the same payment as a separate transaction without understanding whether the original could still confirm. Keep the transaction ID and check its status in your wallet or a trusted block explorer. If the transaction disappeared from one service, that alone does not establish that it was confirmed, canceled, or safe to replace.

A useful decision is to choose a rate that matches your urgency and ability to wait, while recognizing that no rate quote promises a block. If the fee seems unusually high, inspect the input count and output structure; the transfer amount itself does not explain the size. If the wallet shows only a total, open its detail view or documentation to see which fee items are included. The numbers in this article are hypothetical examples, not a live quote.