Bitcoin transaction fees and the mempool: how fees are set and why they spike

A fee is whatever the sender leaves on the table

A Bitcoin transaction does not have a fee field. It spends some coins it controls, called inputs, and it creates new coins for the recipients, called outputs. Whatever value goes in and does not come out is the fee, and the miner who packs the transaction into a block keeps it. That is the whole mechanism. If the inputs add up to a little more than the outputs, the difference is the fee, whether the sender meant it or not.

Because an input has to be spent in full, most transactions include a change output that sends the surplus back to the sender. The developer documentation puts it plainly: the full value of the included inputs must be spent or given to a miner as a transaction fee. Wallets do this arithmetic for you, which is why fees feel like a separate line item even though, on the ledger, they are simply the gap between what went in and what came out. Our article on UTXOs explains why coins work this way.

The fee is also the miner’s only payment for including your transaction in particular. The rest of a miner’s income, the block subsidy, arrives regardless of which transactions the block contains, and it halves on a fixed schedule. So when a miner chooses what to put in a block, fees are the part that varies, and the documentation is candid that it is ultimately up to each miner to choose the minimum fee they will accept.

Calculate total fee from size and fee rate

At an illustrative 8 sat/vB, a 200-vbyte transaction pays 1,600 satoshis. A 400-vbyte transaction at the same rate pays 3,200. The payment’s bitcoin amount does not enter this multiplication.

Input types, signatures and outputs affect transaction weight and virtual size. Fee estimates change with the expected signed transaction, so compare total fee and rate separately. A higher rate can improve competitiveness without guaranteeing inclusion.

The mempool is every node’s own waiting room, and no two are identical

A mempool is a node’s local set of accepted, unconfirmed transactions. Nodes can receive different transactions and apply different configurations, so an explorer reports its own observation rather than a single universal queue.

Bitcoin Core can remove entries when they are old or when the pool exceeds its configured size. The cited v29.0 implementation includes Expire and TrimToSize, with descendant handling and a rolling minimum fee after size-based eviction.

Eviction is not consensus cancellation. It does not revoke a signature or prove that every peer has forgotten the transaction. If its inputs remain spendable, someone may rebroadcast it, so an unrelated second payment can still create a duplicate payment.

Fees spike because demand moves and block space does not

Blocks have limited capacity, while pending demand changes. Miners choose which valid transactions to include, and dependent transactions can make package economics differ from an isolated transaction’s rate.

Relay floors, dynamic mempool minimums and incremental replacement requirements are different node policies. Their values depend on the software version and configuration; one historical sat/vB setting is not a permanent network-wide tariff.

A wallet can use observed conditions and a desired confirmation target to estimate a fee. The funded transaction’s actual virtual size determines the total fee, and the estimate does not reserve a place in a future block.

Replace-by-fee: how a stuck transaction gets unstuck

RBF proposes a conflicting transaction spending at least one of the same outputs. The wallet must be able to construct and authorize it, and receiving nodes apply their replacement policies. Historical opt-in signaling in BIP-125 is not an immutable consensus requirement.

The cited Bitcoin Core 29.0 bumpfee RPC documents wallet restrictions and a required fee increase. Replacement rules depend on the implementation and version, and an accepted mempool replacement does not guarantee confirmation.

CPFP instead spends a suitable unconfirmed output with a child whose fee can improve the combined package rate. Either the recipient or a sender controlling change may be able to construct it. The parent must precede the child in the accepted chain, possibly within the same block.

Both techniques require the relevant spending authority, sufficient input value and supported wallet and relay behavior. Neither reverses a payment that is already confirmed in the accepted chain.