TL;DR: A Bitcoin transaction fee depends on the transaction's virtual size and the fee rate, rather than a percentage of the payment. Two wallets can quote different fees for the same amount because they spend different inputs or create different outputs. Check the recipient amount, input total, change, virtual size, and fee rate together. The calculations below explain a quote; they do not predict a guaranteed confirmation time or recommend a live fee.
You enter a payment amount, select a speed, and receive a fee quote. The amount is familiar. The fee often seems arbitrary. One wallet says the payment costs a few hundred satoshis; another asks for several thousand. Increasing the payment amount might barely change the quote, while sending a smaller amount from a different wallet costs more.
The useful question is what the wallet is actually building. Bitcoin spends existing transaction outputs. A wallet's displayed balance is a sum of available pieces, and constructing a payment means choosing pieces, satisfying their spending conditions, and creating new outputs. The number and type of those pieces affect the transaction's size. The price of that size is the fee rate.
This workbook separates those variables. All numerical transactions are hypothetical, with explicitly assumed sizes. They are intended for checking arithmetic and understanding tradeoffs, not as serialized transaction templates. The technical references are Bitcoin's specifications and Bitcoin Core 30.0 RPC documentation, checked for this article on October 10, 2026.
Begin with the conservation equation
A transaction's fee is the difference between the value of its inputs and the value of its outputs. If the inputs sum to 120,000 satoshis, the recipient receives 100,000, and a change output returns 18,500 to the sender, the fee is 1,500. There is no additional on-chain fee output paid to a special service address. The transaction leaves that difference available as a transaction fee. Bitcoin's developer documentation explains the input-output relationship and the role of change. Bitcoin developer guide: Transactions
That equation gives you a way to audit a quote without trusting the wallet's speed label. Add every recipient output and every change output. Subtract the sum from the input total. The result should agree with the fee the wallet presents. A payment can have several recipients, so checking only the most prominent amount on the confirmation screen is insufficient.
Separate the recipient amount from the amount deducted from your balance. In the example, the recipient gets 100,000 and the sender's net balance decreases by 101,500. If a service subtracts the fee from the recipient amount instead, entering 100,000 might deliver only 98,500. These are different payment agreements even though both screens can display the same entered amount.
Bitcoin Core's transaction-funding interface makes this distinction explicit through an option for subtracting fees from selected outputs. It also reports the funded transaction's fee. The interface is useful evidence that fee allocation is a construction choice, rather than a necessary consequence of how much a person typed into an amount box. Bitcoin Core 30.0: walletcreatefundedpsbt
Consider a bill requiring an exact 100,000-satoshi receipt. A wallet setting that deducts fees from the payment can create an underpayment. For a transfer between your own wallets, that shortfall might simply mean a smaller received balance. The same arithmetic has different consequences because the receiving agreement differs. Before comparing fees, make the requested outcome identical.
Virtual size measures the transaction, not the payment
Bitcoin's Segregated Witness specification defines transaction weight from base size and total serialized size. Virtual size is weight divided by four, rounded upward to a whole virtual byte. A virtual byte, usually abbreviated vB, is the denominator in common wallet fee rates. It is not necessarily one byte in a downloaded transaction file. BIP 141: Transaction size calculations
Suppose a transaction has a weight of 561 units. Dividing by four gives 140.25, so its virtual size is 141 vB. At an assumed rate of 8 satoshis per virtual byte, an exact rate-times-size calculation gives 1,128 satoshis. If the transaction's final fee is 1,128, dividing the fee by 141 recovers 8 sat/vB.
The rounding step matters when reconciling small differences. A calculation using 140.25 as the virtual size produces a different total from one using the defined integer size. There can also be a difference between a wallet's estimate before signing and the completed transaction. Keep estimated and final values separate instead of declaring every discrepancy an error.
A payment of 20,000 satoshis and a payment of 2,000,000 satoshis can have the same virtual size if their transaction structures match. In that case, applying the same fee rate gives the same fee. The smaller payment has a higher fee as a percentage of its amount, but the network fee did not become a percentage charge. The percentage is a useful affordability measure derived after construction.
Conversely, a modest payment can require many inputs. Imagine a wallet built from repeated small receipts. Its total balance might comfortably cover the payment, yet the transaction needs enough input records to collect that value. The wallet with a single larger output can potentially fund the same payment with less transaction data. The amount alone cannot explain the difference.
This is why a price comparison based on payment value can mislead. Asking how much it costs to send a certain quantity of bitcoin leaves out the pieces being spent. A better comparison includes an estimated virtual size and the chosen rate. Once those are visible, the fee becomes a multiplication problem followed by a construction review.
Convert the units before comparing quotes
A satoshi is one hundred-millionth of a bitcoin. A fee rate of 0.00010 BTC per thousand virtual bytes therefore means 10,000 satoshis per thousand virtual bytes, or 10 sat/vB. The conversion requires both the bitcoin-to-satoshi factor and the thousand-byte factor. Omitting either can produce a dramatic error.
Bitcoin Core's fee-estimation RPC reports its estimate in BTC per thousand virtual bytes. Its transaction-funding RPC documents both a snake-case fee-rate argument in sat/vB and a differently capitalized argument in BTC/kvB. The names look similar while their units differ. Anyone integrating these interfaces should use the documentation for the actual version and method, rather than copying a value between fields. Bitcoin Core 30.0: estimatesmartfee, Bitcoin Core 30.0: walletcreatefundedpsbt
For an ordinary user, the equivalent trap occurs when one screen gives a total in bitcoin and another gives a rate in sat/vB. A total of 0.00002000 BTC is 2,000 satoshis. If the transaction is 200 vB, its effective rate is 10 sat/vB. That is comparable to a displayed 10 sat/vB rate; the two numbers are not competing totals.
Write the unit beside every intermediate number. Start with fee in satoshis, size in virtual bytes, and rate in satoshis per virtual byte. Convert to fiat only after the transaction arithmetic is clear. A currency conversion adds another variable, including its timestamp, without changing the transaction's fee in satoshis.
A quote can seem to rise even when the satoshi fee is unchanged if the displayed exchange rate changes. It can also fall in fiat while the transaction consumes more satoshis. Those are different explanations for the same visible movement. Saving the underlying fee and rate lets you distinguish wallet construction from currency presentation.
Three quotes for one recipient
Assume a recipient must receive exactly 100,000 satoshis. Consider three hypothetical drafts, each with an assumed final virtual size. Draft A uses one input and creates recipient and change outputs. Draft B uses four inputs and also creates change. Draft C uses one input whose value matches the recipient amount plus the intended fee, allowing the draft to omit change.
| Draft | Assumed virtual size | Assumed rate | Fee | Recipient receives |
|---|---|---|---|---|
| A: one input, change | 140 vB | 12 sat/vB | 1,680 sats | 100,000 sats |
| B: four inputs, change | 344 vB | 12 sat/vB | 4,128 sats | 100,000 sats |
| C: one input, no change | 109 vB | 12 sat/vB | 1,308 sats | 100,000 sats |
These assumed sizes illustrate the arithmetic, not universal sizes for any address type. Real scripts, signatures, output types, and serialization determine the completed result. To reproduce a quote, use the wallet's actual size estimate or the final decoded transaction rather than treating the table as a lookup chart.
Draft B costs 2,448 satoshis more than A at the same rate. That difference follows entirely from the assumed extra size: 204 vB multiplied by 12. The explanation is input selection, not a more expensive speed setting. If A and B are labeled identically, their different absolute fees can still be coherent.
Now change A's rate to 30 sat/vB without changing its size. The fee becomes 4,200 satoshis. That is close to B's original total, but it represents a different tradeoff. A uses less space and offers a higher rate; B uses more space at a lower rate. A total-fee ranking hides this distinction.
Draft C appears best on price, but the exact-value input may not exist in the wallet. It cannot be conjured by changing a setting. If the available input exceeds the recipient amount plus a reasonable fee, omitting change can simply donate the excess as a larger fee. A smaller transaction is not automatically cheaper if its input-output difference is poorly controlled.
That last point is worth calculating. An input of 110,000 and a single recipient output of 100,000 leaves a 10,000-satoshi fee. Even at 109 vB, its effective rate is approximately 91.74 sat/vB. Omitting the change output saved size while overpaying the assumed 12 sat/vB target. Always reconcile size savings with the value left over.
Coin selection creates a present cost and a future shape
An unspent transaction output, or UTXO, is a previously created output that remains available to spend. Your wallet may control many such outputs. Coin selection chooses which of them fund a new transaction. Bitcoin Core exposes available unspent outputs through its wallet RPC, while its funding interface can choose inputs automatically or accept specified ones. Bitcoin Core 30.0: listunspent
The current fee is only one consequence of that choice. Spending a large input can create a new change output; spending several small ones can reduce the number of small pieces left in the wallet. The best immediate quote and the preferred future balance structure need not coincide. This is a bookkeeping tradeoff that becomes visible when you list the resulting outputs.
Suppose a wallet holds outputs valued at 105,000, 60,000, and 50,000 satoshis. For a 100,000-satoshi payment, the first output might cover the payment and a modest fee. Combining the other two provides 110,000 but requires two input records. Depending on the actual scripts and fee rate, both can produce valid drafts with different fees and change values.
There is no universal command to always spend the largest or smallest output. The decision can depend on the required payment, actual input costs, privacy preferences, and future plans. A user checking a wallet should ask why extra inputs were included, particularly if the payment could have been covered by a smaller set. The answer may be deliberate or may reveal an unexpected setting.
Labels help make the choice legible. If one output comes from a business receipt and another from personal savings, a wallet total obscures that separation. Spending them together creates a single transaction involving both. Even without drawing broad conclusions about blockchain surveillance, the visible transaction itself combines those pieces. Do not assume a fee-saving choice preserves your preferred accounting boundaries.
Manual coin control is therefore more than a low-fee switch. It gives a user responsibility for selecting funds and understanding the remaining balance. Before approving a manually selected draft, inspect whether the wallet added more inputs automatically. A selection screen and a completed funded transaction can differ if the application is allowed to fill a shortfall.
Small outputs can be expensive to spend
To reason about an input, separate its value from its marginal spending cost. Assume an additional input adds 68 vB to a hypothetical transaction. At 2 sat/vB, the added fee is 136 satoshis. At 40 sat/vB, it is 2,720. The same input has a very different economic contribution under those assumptions.
If that input is worth 2,000 satoshis, including it at the higher rate consumes more in added fee than the value it brings. That is an economic observation about the assumed transaction, not a claim that the output ceased to exist or became invalid. Its usefulness can change with the spending conditions and future fee rate.
Now imagine ten such outputs. Their nominal total is 20,000 satoshis. At an assumed marginal cost of 2,720 each, collecting all ten adds 27,200 to the fee. A balance display can accurately show their values while still failing to communicate the cost of accessing those values in a particular transaction.
Do not confuse this calculation with a fixed dust threshold. Dust rules concern transaction policy and output characteristics; economic spending cost is a calculation involving the rate and the actual spending size. The word dust is often used loosely in wallet discussions, so asking which meaning is intended prevents a technical label from substituting for arithmetic.
The practical consequence is to inspect the number of pieces before making small on-chain transfers a routine habit. Many receipts can create future input work. A service that sends numerous tiny payouts changes the user's balance structure even when its payout total is attractive. Compare the receipt pattern and the likely spending pattern as two stages of one process.
Consolidation is a transaction with its own tradeoffs
Consolidation means spending multiple outputs into fewer new outputs you control. In a hypothetical example, collecting eight pieces today creates one larger piece for a later payment. The potential saving arises because the many input records are paid for at today's assumed rate rather than a possibly higher later rate. There is still a fee today.
Use a two-stage comparison. Assume consolidation adds 500 vB of input-related size at 2 sat/vB, costing 1,000 satoshis for that part. If the same input-related size would otherwise be paid at 30 sat/vB, its later cost would be 15,000. The difference is 14,000, before accounting for transaction overhead, outputs, the eventual spend, and uncertainty about future rates.
That arithmetic does not prove consolidation is worthwhile. You may never need all those pieces in one later payment. You may prefer separate funds for accounting purposes. The later rate may remain low. The consolidation output itself must eventually be spent. A useful comparison specifies which future transactions are being replaced, instead of treating every small output as a future liability with a known price.
A stronger reason can be operational predictability. If a planned payment has a deadline, preparing funds in a simpler shape may make its later construction easier to understand. The relevant goal is an intelligible future draft, not speculation about fee markets. Record the cost of the preparatory transaction as part of the payment process rather than forgetting it when comparing wallets.
Consolidation also combines the source outputs in a visible transaction. For someone who keeps funds separated, that can be a reason to leave them alone. A wallet that offers a tidy balance does not necessarily preserve the distinctions that mattered to its owner. Evaluate the transaction graph and the bookkeeping purpose alongside the fee calculation.
A confirmation target is an estimate, not a reservation
Fee-estimation interfaces use a target measured in blocks. Bitcoin Core's estimator can return an estimate and a block target, and can report errors if it lacks sufficient information. Its documented modes use different observation horizons. The output is an estimate drawn from observations, rather than a purchased appointment in a particular future block. Bitcoin Core 30.0: estimatesmartfee
For a deadline-sensitive payment, distinguish the desired confirmation window from the wallet's label. A label such as fast does not explain the target, estimator, or observation time. Two providers can both use that label while making different estimates. Ask what the label means before concluding that one wallet charges a premium for an equivalent service.
A useful quote includes when the estimate was obtained. Saving a screenshot without the timestamp can make an accurate historical quote look inexplicable later. Network conditions can change between draft creation, signing, broadcast, and confirmation. The quote is a decision made with information available at one point, not a timeless property of the payment.
If the wallet supports changing a pending transaction's fee, review the replacement draft as a new accounting object. Bitcoin Core's fee-bumping RPC documents constraints and can alter change or add inputs. Increasing the rate is therefore not necessarily the only change to inspect. Bitcoin Core 30.0: bumpfee
Suppose an original hypothetical transaction pays 1,680 satoshis and a replacement pays 4,200. If the recipient remains at 100,000 and input total is unchanged, the extra 2,520 must come from change. If another input appears, check the new input total and outputs as well. The replacement's higher fee should remain explainable through the same conservation equation.
Separate a provider's charge from the transaction fee
A withdrawal quote from a custodial provider can describe something different from a self-custody wallet's transaction draft. The provider might present a fixed withdrawal charge, while the eventual on-chain transaction includes several customers' withdrawals. Without the provider's own fee terms and the transaction details, you cannot assume the amount charged to one customer equals that transaction's network fee.
This matters when making comparisons. Suppose one hypothetical service charges 3,000 satoshis to withdraw 100,000, and a self-custody draft pays 1,680 for the same delivered amount. That comparison describes the customer's cost in each route. It does not establish that the service constructed a transaction at a higher fee rate. The service's charge may include a pricing policy you cannot recover from the blockchain alone.
For a transaction with several recipients, the total fee also does not identify each recipient's contractual share. A hypothetical batch paying 6,000 satoshis and containing ten payments has an arithmetic average of 600 per payment. That average is not a rule imposed by Bitcoin. Recipients can have different agreements with the sender, and the sender's internal allocation can differ from a simple division.
Record three separate quantities when necessary: the amount requested, the amount received, and the provider charge. Then record the network transaction fee if it is relevant and available. These fields let you answer both the customer question, how much did this transfer cost me, and the technical question, how was this transaction priced. Merging them creates a number that answers neither precisely.
There is a similar issue with wallet interface estimates that include a service fee as an additional output. The input-output difference still determines the transaction fee, while that service output is a recipient of value. A larger deduction from your balance can therefore have two components. Reviewing all outputs exposes the distinction. A headline labeled total cost is useful only when you can see what it includes.
Read the signing screen as a compact invoice
Before signing, a coherent invoice identifies the recipient, amount delivered, selected funds, returned change, total fee, and size or rate when the wallet provides them. These fields serve different purposes. The address establishes destination; the outputs establish distribution; the fee explains the value difference; the rate relates that difference to transaction size.
Begin with the exact recipient agreement. Then identify change as funds returning to your control, using the wallet's own verification process. Do not label an unfamiliar output as change merely because its value seems plausible. A correct arithmetic total cannot establish that an output belongs to you. Arithmetic and destination verification answer separate questions.
Compare the final signing screen with the draft you intended to approve. A higher fee might result from a refreshed rate, additional inputs, or a changed output. Each explanation has a corresponding visible field. If the application hides those fields, its simplicity has limited your ability to distinguish these causes. That is a product constraint worth recognizing.
After confirmation, retain the transaction identifier and the final fee alongside your payment record. If a quoted estimate differed from the completed transaction, the saved draft can help explain why. For business records, separate the amount delivered from the fee incurred. Combining them into one expense may be convenient, but it removes information needed for later reconciliation.
The best fee comparison ends with a sentence precise enough to check: this draft delivers this amount, spends these inputs, returns this change, and pays this fee for this virtual size. Once you can say that, a wallet quote becomes reviewable. You can choose urgency, balance structure, and accounting preferences with the actual transaction in view.