Bitcoin transaction fees and virtual size

Four numbers on a payment screen

A wallet might show 70,000 sats sent, a transaction size of 200 virtual bytes, a selected fee rate of 5 sats per virtual byte, and a total fee of 1,000 sats. Each number answers a different question.

The payment amount is value assigned to the recipient. Virtual size measures transaction resource usage under Bitcoin’s weight accounting. Fee rate expresses how much fee is offered per virtual byte. Total fee is the input/output difference.

For our invented example:

200 vB × 5 sat/vB = 1,000 sats

This is arithmetic, not a quote from the live fee market. A real wallet estimates a rate according to observed conditions and its own policy, and actual inclusion is uncertain.

The amount is not the payload size

Compare two imagined transactions. One pays 20,000 sats using several inputs. Another pays 2,000,000 sats using one input. The larger payment can have a smaller virtual size. Transaction structure and spending types matter; the recipient amount alone does not determine how many bytes the transaction uses.

The analogy is a parcel label: the declared value of a package is not its physical weight. The analogy stops there—Bitcoin fees are not postal tariffs, and no central carrier guarantees delivery at a posted price.

Why virtual bytes exist

BIP 141 defines weight using a base serialization and a total serialization that includes witness data:

weight = base_size × 3 + total_size
vsize  = ceil(weight / 4)

If a hypothetical transaction has a base size of 100 bytes and total size of 250 bytes, its weight is 550 weight units. Divide by four to get 137.5, then round up: 138 virtual bytes.

At an illustrative 5 sat/vB, multiplying 138 by 5 gives 690 sats. A transaction paying 690 sats with that virtual size has an effective rate of 5 sat/vB. The example sizes are supplied teaching inputs, not the measured serialization of a real transaction.

The rounding step matters when weight is not a multiple of four. So does the unit: sats, sat/vB, bytes and weight units cannot be substituted for each other just because the numbers look plausible.

Relay policies, transaction dependencies, replacement, and miner selection make inclusion more complicated than sorting a list of standalone fee rates. This lesson establishes the accounting needed to read an estimate; it does not predict when a payment will confirm.

Catch a unit error

Calculate these two estimates:

Virtual size	Example rate	Expected fee
140 vB	3 sat/vB	420 sats
280 vB	3 sat/vB	840 sats

The second transaction pays twice the fee at the same rate because it consumes twice the virtual size. Now change only the recipient value in the description, leaving the serialized structure and virtual size unchanged. The multiplication does not change.

For a builder exercise, implement Math.ceil(weight / 4) and check weights 549, 550 and 552. Expected virtual sizes are 138, 138 and 138. At 553, the expected result becomes 139.

Before using such a helper in production, validate inputs and choose a numeric representation that safely handles your permitted ranges. Keep fee estimation separate from this size-conversion function.