What are Bitcoin Transaction Fees?

Bitcoin is a peer-to-peer electronic cash system with no central authority. There is no company, bank, or payment processor managing transactions or setting prices for their processing. Instead, transaction processing and prioritization runs as a free and open market, and transaction fees are how that market operates.

What are Bitcoin Transaction Fees?

When you send bitcoin, you are competing with every other proposed transaction for space in the next block. Miners, who produce blocks and secure the network, are free to include any transactions they choose. Because they collect the fees attached to every transaction they include, they are naturally incentivized to prioritize the ones paying the highest rate. Your fee is not a service charge to an intermediary. It is a bid in an open auction, paid directly to the miner who wins the right to produce the next block.

This is also part of bitcoin's long-term security model. As the block subsidy (the newly created bitcoin awarded to miners per block) decreases over successive halvings towards the terminal inflation rate of zero, transaction fees are expected to make up a growing share of miner revenue. Fees are not an afterthought. They are how bitcoin sustains its security without relying on inflation.

How are Bitcoin Transaction Fees Calculated?

Bitcoin transaction fees are not based on the financial value of what you are sending. Sending 1 bitcoin does not cost more in fees than sending 0.001 bitcoin. What determines the fee is how much data your transaction requires, measured in virtual bytes (vbytes).

The amount of space in Bitcoin's blocks is intentionally limited. Bitcoin's block size cap exists to keep the full transaction history small enough that regular computers can store and verify it, which is what keeps bitcoin decentralized and resistant to central control. Because that space is scarce and every transaction competes for it, fees are priced per vbyte.

Fees are not explicitly stated anywhere in a bitcoin transaction. The fee is implicit, calculated as the difference between the total value of the inputs and the total value of the outputs. Whatever is not assigned to an output is collected by the miner as the fee.

A transaction that spends many inputs requires significantly more data than a simple one-input, one-output transaction. Each input contains a signature proving you are authorized to spend that UTXO, and signature data is the largest component of any transaction. A transaction with ten inputs has ten signatures, ten times the data, and will cost roughly ten times as much at the same fee rate as a single-input transaction for the same payment amount.

Transaction size comes from three components:

• Fixed overhead: approximately 10 to 11 vbytes regardless of inputs or outputs
• Outputs: 31 to 43 vbytes each, depending on address type
• Inputs: the main variable, since each input requires a signature

Input size varies by address type:

The main difference arises from SegWit's witness discount. Since BIP-141 activated in August 2017, signature data in SegWit transactions is counted at one-quarter the weight of non-signature data, which reduces the vbyte cost of every signature. A standard one-input, two-output P2WPKH transaction is approximately 141 vbytes. The equivalent P2PKH transaction is approximately 226 bytes. At 20 sats/vbyte, that difference is 1,700 satoshis in fees per transaction.

The number of UTXOs consumed in a transaction multiplies this further. A transaction spending 10 P2WPKH inputs is approximately 612 vbytes more than a transaction spending 1 P2WPKH input for the same payment amount. At 50 sats/vbyte, that is 30,600 satoshis in additional fees driven entirely by input count. Consolidating small UTXOs during low-fee periods reduces this cost before it arises. Bitcoin UTXO Management covers consolidation strategy in full.

Fees are measured in sats/vbyte, not as a percentage of the transaction's value. A fee that looks large in satoshi terms can represent a very low rate on a large multi-input transaction, while a fee that looks small can be adequate for a compact single-input transaction. What matters is the rate, not the absolute satoshi amount. Setting a flat satoshi fee rather than a fee rate is unreliable for this reason.

How Do I Choose the Right Fee?

Choosing the right fee rate is about finding the balance between confirmation speed and cost. Overpaying wastes satoshis on fees that were never necessary, while underpaying risks your transaction sitting in the mempool for a long time or getting stuck indefinitely if congestion rises after you broadcast.

The right rate depends entirely on current mempool conditions, which shift constantly. Before sending, check mempool.space to see what the current market rate is for the confirmation window you need. The mempool article covers how to navigate mempool.space in greater detail, including how to read projected blocks and interpret congestion.

Always set a fee rate (sats/vbyte) rather than a flat satoshi amount, and enable opt-in replace-by-fee (RBF) on every transaction. RBF costs nothing upfront and preserves the ability to increase the fee rate if the transaction stalls. Setting a moderate rate with RBF enabled is better than overpaying on every send as a precaution.

How to target the right fee rate for your situation:

• Next block (in ~10 minutes): Look at the fee rate of transactions in the first projected block on mempool.space, then check how many subsequent blocks share a similar rate. If the next several blocks are all priced at roughly the same level, matching that rate may place you hours away rather than one block away. Exceeding the current next-block rate more meaningfully increases your likelihood of getting into that first block.

• 2 to 6 blocks (20 to 60 minutes): Look at the second through sixth projected blocks and target a fee rate in that range. Appropriate for most routine payments where confirmation within the hour is acceptable but next-block speed is unnecessary.

• 1 to 12 hours: Look deeper into the projected queue and target a lower rate. Useful if you want to avoid peak hours and are comfortable waiting. Be aware that conditions can change after you broadcast and you may end up waiting longer than anticipated.

• Low priority (hours to days): Going lower still is possible if you are genuinely indifferent to timing. This can be appropriate for self-transfers, consolidations, or cold storage moves during quiet periods. Accept the risk of a longer wait or being evicted if congestion rises and the mempool clears its floor rate.

Beyond fee rate selection, Bitcoin UTXO Management is the other lever. Reducing the number of inputs in a transaction reduces its size in vbytes, which reduces the absolute fee at any fee rate. Keeping UTXOs consolidated, using SegWit or Taproot addresses, and avoiding unnecessary change outputs all lower the cost of every future transaction before you even open the fee rate dialog.

Coldcard devices display the total fee and the implied fee rate from the PSBT before signing. The fee is calculated from the difference between inputs and outputs using the PSBT's input UTXO data, independently of what the coordinator reports. Verifying the fee on the device screen before confirming is a security check: a tampered PSBT could route excess value to an attacker's address under the label of a fee.

What is Replace-by-Fee (RBF)?

If a transaction is stuck in the mempool because the fee rate you set is too low for current conditions, replace-by-fee (RBF) lets you fix it by broadcasting a replacement that pays more. The replacement uses the same inputs, which prevents double-spending, and reallocates value from the change output to the fee. To be accepted as a valid replacement, it must pay a higher absolute fee and a higher fee rate than the original. Nodes that accept the replacement remove the original from their mempool.

Opt-in RBF requires the original transaction to signal BIP-125, which is done by setting input sequence numbers to 0xFFFFFFFD or lower. Wallets that support RBF include this signal when the option is enabled. Full RBF, enforced by an increasing number of Bitcoin Core nodes, accepts replacements regardless of whether the original signalled the flag.

The workflow for RBF in Sparrow Wallet with Coldcard is straightforward. You create the original transaction with "Enable Replace-by-Fee" checked, then if it is stuck as unconfirmed for a long time, select "Bump Fee" in Sparrow to create the replacement. You then sign the replacement with Coldcard and broadcast via Sparrow. The process requires signing the replacement transaction, which Coldcard handles in the same way as any other transaction.

You can use RBF when the original transaction was sent with the flag enabled and the current fee rate is insufficient for the required confirmation time. RBF requires the sender to hold the inputs. The recipient cannot use RBF on an incoming transaction.

What is Child-Pays-for-Parent (CPFP)?

Child-pays-for-parent (CPFP) is the other fee-bumping tool, and unlike RBF it can be initiated by the recipient. In bitcoin, a transaction that spends an output from another unconfirmed transaction is called a child, and the unconfirmed transaction it depends on is the parent.

Miners cannot include the child without first including the parent, which is what makes the child's fee relevant to the parent's confirmation. By broadcasting a child transaction that pays a high enough fee, you give miners an incentive to confirm both together.

Miners consider the combined fee rate of parent and child, calculated as total fees divided by combined size in vbytes. When that combined rate reaches the clearing threshold, miners include both in the same block.

The fee the child must pay depends on the parent's shortfall. If the parent paid 2 sats/vbyte and the current clearing rate is 20 sats/vbyte, the child must compensate for that deficit across the combined size. Sparrow Wallet calculates the required child fee automatically when a target combined rate is entered, removing the need to do this arithmetic manually.

You can use CPFP when the original transaction did not signal RBF, or when the recipient wants to accelerate an incoming payment. In Sparrow, right-click the unconfirmed transaction, select "Child Pays for Parent," set the target fee rate, and sign the child transaction with Coldcard. The combined package confirms once the child's fee is sufficient.