How does the mechanism work?
Transaction weight counts base data more heavily than witness data. Virtual size is weight divided by 4, rounded up. A satoshi is one hundred-millionth of a bitcoin. These units let wallets express fees without long decimal BTC amounts.
Adding inputs or outputs can change size. A larger payment amount alone does not necessarily make a transaction larger. The actual input types, scripts and witness data matter, so a diagram cannot replace a final transaction-size calculation.
The units also make comparisons reproducible. If someone reports a fee without a virtual size, you cannot calculate its effective rate. If someone reports a rate without a size, you cannot calculate the total cost. Ask for both and label whether the size is estimated or final. A displayed fee can be numerically correct while answering a different question from the one you intended. For dependent transactions, the relevant comparison may involve combined fees and combined virtual sizes. Keep that package calculation separate from the single-transaction multiplication, and never average rates without accounting for their different sizes.
What would you see in an example?
Use an invented transaction with a virtual size of 140 vbytes and a fee rate of 5 satoshis per vbyte. The fee is 700 satoshis. If the size becomes 200 vbytes at the same rate, the fee becomes 1,000 satoshis. These are arithmetic examples, not current network quotes or suggested rates.
How do weight units become a rounded virtual size?
The weight formula is base size multiplied by 3, plus total serialized size. Equivalently, count base bytes four times and witness-only bytes once. Virtual size is the ceiling of weight divided by 4. The ceiling matters because a fraction of a vbyte is not discarded. Keep the unit attached at each step so bytes, weight units and satoshis do not become interchangeable.
Take an invented transaction with base size 100 bytes and total size 250 bytes. Its weight is 100 × 3 + 250 = 550 weight units. Its virtual size is ceiling(550 / 4), or 138 vbytes. At an illustrative fee rate of 5 sat/vB, a fee target is 690 satoshis. These values demonstrate the protocol formula; they are not a quote for a particular payment.
If the same transaction instead weighs 552 units, its virtual size is still 138 vbytes. At 553 units it becomes 139 vbytes. Rounding the weight conversion first and then multiplying by the rate gives an explicit target. If a fractional rate produces a fractional satoshi result, round the final target up to a whole satoshi. A transaction’s actual fee remains the input-minus-output difference.
Separate an estimated target from the effective rate of a finished transaction. If the actual fee is 700 satoshis and final size is 140 vbytes, the effective rate is exactly 5 sat/vB. A change in signature length, input selection or output construction can change the estimate. The fee calculator performs the arithmetic you enter and makes no claim that those inputs describe a finished transaction.
Common misunderstandings
A fee rate is not a percentage of the amount sent. A small payment with many inputs can require more weight than a larger payment with fewer inputs. Input and output structure explain the measurement.
A high rate does not buy a consensus guarantee about timing. Relay policies, dependencies and miner selection still matter. Nor is a weight unit a byte of storage in every context. Keep the weight formula visible instead of replacing all size terms with an unqualified word like size.
Check yourself
Does weight 561 become 140 or 141 vbytes?
Reveal the answer
141 vbytes. Divide by 4 and round up. At an invented 2 sat/vB, that size corresponds to a 282-satoshi fee target.
What does this diagram leave out?
A fee rate does not reserve a place in a universal queue or promise a confirmation time. Nodes and miners apply their own policies, and competing transactions change. A size estimate before signing may differ from the final transaction. Treat the fee and payment amount as distinct checks.
Which primary sources explain the rules?
Sources: Segregated witness specification; Transaction developer reference.
Sources: Weight and virtual transaction size.