Bitcoin Transaction Fees

Buying scarce block space

A transaction fee is the difference between input and output value. Wallets express competitiveness as sats per virtual byte because miners generally optimize revenue against limited block weight.

Mempools are local

Each node maintains its own view of valid unconfirmed transactions. Fee estimators infer likely inclusion from recent blocks and mempool conditions; they cannot guarantee an exact confirmation time.

Name the layer and the actor. Wallets create transactions, nodes check rules, miners propose blocks, and Lightning peers manage channels.

Use available tools

Replace-by-fee can rebroadcast an enabled transaction with a higher fee. Child-pays-for-parent may incentivize confirmation of a transaction chain. Batching multiple payments and consolidating at quiet times can reduce future footprint.

Why the market works the way it does

Each block has room for about 4 million weight units, and blocks arrive roughly every ten minutes regardless of demand. When more transactions want in than fit, miners take the highest fee rates first and the rest wait.

The result is an auction that repeats every block: in quiet weeks a couple of satoshis per virtual byte clears in the next block, and in a rush — a price move, an exchange outage, a new token protocol writing data to the chain — the same position costs hundreds.

The historical fee explorer on this site shows those episodes and how quickly each one subsided.

Calculating what you will pay

Fee equals virtual size times fee rate. A typical single-input, two-output native SegWit payment is about 140 virtual bytes; at 10 sat/vB that is 1,400 sats, at 100 sat/vB it is 14,000. A legacy transaction with the same shape is about 225 vB. A consolidation spending twenty small inputs is well over 1,000 vB and should be done when rates are low.

The amount sent does not enter into it: moving one bitcoin and moving one dollar's worth from the same inputs cost the same. The UTXO planner on this site gives the size for any input and output mix.

Reducing fees without waiting forever

Use a native SegWit or Taproot wallet, whose inputs are the smallest. Batch several payments into one transaction with many outputs rather than several transactions. Consolidate small inputs during a quiet weekend so a later urgent payment needs only one. Set a low rate with replace-by-fee enabled and raise it only if the wait becomes a problem. Use Lightning for small, frequent payments.

And read the mempool before sending: a backlog that has been growing for hours will not clear at yesterday's rate, while one that is draining will.

Test the payment path carefully

Use a small payment to learn how invoices, liquidity, routing, timeouts, and channel backups behave. Keep the on-chain recovery path clear before depending on a Lightning wallet.