Two people send the same amount of BTC, but their wallets quote different fees. The selected fee rate is not the only possible reason. One transfer spends a single previous output, while the other uses several. The transaction size changes even though the recipient amount is identical. It helps to separate the wallet balance, selected input count and rate per virtual byte.
A balance does not describe the next transaction
Bitcoin represents funds as unspent outputs from previous transactions, or UTXOs. To make a new spend, the wallet selects suitable outputs as inputs. It does not have to spend every available UTXO in every transfer.
Many small receipts can mean that several inputs are needed for a particular payment. However, the number of past deposits alone cannot determine the next fee: selection depends on available outputs, their types, the amount and wallet behavior. Examine the specific transaction being prepared.
| Parameter | Meaning | Assumption to avoid |
|---|---|---|
| Transfer amount | The BTC quantity intended for the recipient | The same amount always produces the same size |
| Input count | How many previous outputs are being spent | It always equals every receipt in the wallet |
| Output count | New destinations for funds, including change | One recipient always means one output |
| Rate in sat/vB | The chosen payment per virtual byte | The rate alone guarantees confirmation time |
An input or change output is not an extra service charge
When a selected output exceeds the amount needed, the transaction may contain a separate change output. That does not mean the recipient received two payments or that an exchange added an undisclosed service. Review outputs in the context of the particular transaction.
Do not assume an unfamiliar output is your change merely because of its position in a list. Use information from your own wallet to establish ownership. The local calculator below does not inspect addresses or determine who owns an output.
Why SegWit uses a virtual size
BIP141 defines transaction weight using base data and witness information. Virtual size is weight divided by four, rounded upwards. Consequently, the ordinary serialized byte count and the virtual byte count can differ.
This is not one universal multiplier for every transaction. Input and output types matter, as do signature data. Applying a single simplified โbytes per inputโ figure to every wallet can produce an incorrect estimate.
The limits of this article's model
The tool assumes native P2WPKH inputs with empty scriptSig fields and P2WPKH outputs only. For each input it assumes a 72-byte signature including the signature hash type byte, plus a 33-byte compressed public key. This is a size assumption, not verification of an actual signature.
The calculation includes CompactSize counters and the additional witness information. It does not model other address types, mixed inputs, additional scripts or actual UTXO selection. If these assumptions do not match, do not treat the result as an exact prediction of a real transaction.
An educational comparison of one and ten inputs
With two outputs under these assumptions, one input produces a virtual size of 141 vB; ten produce 753 vB. At a hypothetical rate of 5 sat/vB, the calculated fees are 705 and 3765 satoshis. These figures demonstrate arithmetic. They are not a live network rate or a recommendation to select that fee.
If the rate multiplied by virtual size gives a fraction of a satoshi, the tool rounds the calculated payment upwards to a whole satoshi. It does not construct a transaction, check node acceptance rules or assess the probability of inclusion in the next block.
Check where the 753 virtual bytes come from
For ten inputs and two outputs, the parameters belong specifically to this teaching model. The base part occupies 482 bytes; witness including marker and flag occupies 1082. Weight applies different multipliers to those parts.
| Calculation component | Operation | Result |
|---|---|---|
| Base part | 482 ร 4 | 1928 weight units |
| Witness, marker and flag | 1082 ร 1 | 1082 weight units |
| Total weight | 1928 + 1082 | 3010 |
| Virtual size | Round 3010 / 4 upward | 753 vB |
The actual serialized size in this example is 1564 bytes. That is a different number: it cannot replace virtual size in the illustrated multiplication by sat/vB.
Checks before sending funds for a swap
- Select the network and deposit details of your own order.
- Inspect the wallet estimate for that specific send.
- Distinguish the recipient amount, sending fee and possible change.
- Check whether the sending platform charges its own withdrawal fee instead of using the model shown here.
- Review the order's current limits and conditions before confirming.
Sending costs in your wallet and an exchange quote are separate layers. For KOT.CASH, inspect the selected order and the service terms. This guide does not promise availability of every route or replace checking the estimated amount to receive.
The calculator requires no address, seed phrase or wallet connection. It helps explain differences between estimates, but it does not choose an optimal rate, consolidate outputs or send funds. Confirm final details in the wallet or service that prepares your actual transaction.
Estimate one Bitcoin transaction size model
Native P2WPKH only. Assumed 72-byte signature including sighash and 33-byte public key. Does not identify actual input types or counts, construct a transaction or predict confirmation. The calculation runs on your device; nothing you enter is sent anywhere.