Two Bitcoin transactions with the same total byte count can have different virtual sizes. BIP141 defines a weight calculation that treats base transaction data and witness data differently. When a wallet expresses a fee rate in satoshis per virtual byte, the denominator therefore needs the virtual-size calculation rather than an assumption about the file’s total length. Bitcoin BIP141: Segregated Witness, transaction weight and virtual size
Follow the evidence
Trace how the event could reach markets, then inspect a competing explanation.
Compare explanations
Switch lenses to see what each account explains—and what remains uncertain.
WFN analysis: an invented transaction with a base size of 100 bytes and total size of 220 bytes has weight of 520 units: three times 100, plus 220. Dividing by four gives 130 virtual bytes. If its assumed total fee is 650 satoshis, the illustrative fee rate is five satoshis per virtual byte. Using the raw 220-byte count as the denominator would instead give about 2.95 satoshis per byte. That is another ratio, not a correction to the virtual-byte rate. Both calculations use the same hypothetical fee; their difference comes entirely from the unit. A comparison that shortens both labels to fee rate can therefore conceal a denominator mismatch. Rounding can matter too. A hypothetical weight of 521 units yields 130.25 before rounding and a virtual size of 131. The upward rounding step is part of the definition, rather than a display preference. These examples illustrate the formula only; they do not represent signed transactions, measured wallet behavior or observations of the current mempool.
WFN analysis: an invented transaction with a base size of 100 bytes and total size of 220 bytes has weight of 520 units: three times 100, plus 220. Dividing by four gives 130 virtual bytes. If its assumed total fee is 650 satoshis, the illustrative fee rate is five satoshis per virtual byte. Using the raw 220-byte count as the denominator would instead give about 2.95 satoshis per byte. That is another ratio, not a correction to the virtual-byte rate. Both calculations use the same hypothetical fee; their difference comes entirely from the unit. A comparison that shortens both labels to fee rate can therefore conceal a denominator mismatch. Rounding can matter too. A hypothetical weight of 521 units yields 130.25 before rounding and a virtual size of 131. The upward rounding step is part of the definition, rather than a display preference. These examples illustrate the formula only; they do not represent signed transactions, measured wallet behavior or observations of the current mempool.
For a transaction review, record the identifier, total fee, calculated virtual size and fully labelled rate. If comparing estimates from different wallets, also retain their observation times and target assumptions. A lower total fee can coexist with a higher fee rate when the transaction sizes differ. Rate and total cost answer distinct questions and should remain separately visible. A displayed rate is also separate from the transaction’s confirmation history. Claims about how quickly a payment was included need the actual transaction and block record. This explainer supplies the size arithmetic needed to interpret a rate. It reports no live network congestion, recommended bid, mining policy guarantee or assurance that two superficially similar payments will have identical processing times.
The protocol definitions behind the denominator
BIP141 defines transaction weight as three times the base transaction size plus the total transaction size. Base size uses serialization without witness-related data; total size includes the transaction’s full serialization. Virtual transaction size is weight divided by four, rounded upward to the next integer. Bitcoin BIP141: Segregated Witness, transaction weight and virtual size
The proposal also distinguishes the witness structure from the transaction’s other data. That separation explains why total bytes and virtual bytes need not match. These definitions describe serialization and accounting; they do not provide a current fee recommendation or promise that a transaction paying a particular rate will enter the next block. Bitcoin BIP141: Segregated Witness, transaction weight and virtual size
Check the unit before comparing two fee displays
WFN analysis: an invented transaction with a base size of 100 bytes and total size of 220 bytes has weight of 520 units: three times 100, plus 220. Dividing by four gives 130 virtual bytes. If its assumed total fee is 650 satoshis, the illustrative fee rate is five satoshis per virtual byte.
Using the raw 220-byte count as the denominator would instead give about 2.95 satoshis per byte. That is another ratio, not a correction to the virtual-byte rate. Both calculations use the same hypothetical fee; their difference comes entirely from the unit. A comparison that shortens both labels to fee rate can therefore conceal a denominator mismatch.
Rounding can matter too. A hypothetical weight of 521 units yields 130.25 before rounding and a virtual size of 131. The upward rounding step is part of the definition, rather than a display preference. These examples illustrate the formula only; they do not represent signed transactions, measured wallet behavior or observations of the current mempool.
Keep cost, size and confirmation status in separate fields
For a transaction review, record the identifier, total fee, calculated virtual size and fully labelled rate. If comparing estimates from different wallets, also retain their observation times and target assumptions. A lower total fee can coexist with a higher fee rate when the transaction sizes differ. Rate and total cost answer distinct questions and should remain separately visible.
A displayed rate is also separate from the transaction’s confirmation history. Claims about how quickly a payment was included need the actual transaction and block record. This explainer supplies the size arithmetic needed to interpret a rate. It reports no live network congestion, recommended bid, mining policy guarantee or assurance that two superficially similar payments will have identical processing times.