Transaction Size
Bytes, Weight, and Virtual Bytes
You can measure the size of a bitcoin transaction in 3 ways:
- Bytes (b) – Transaction size on disk.
- Weight Units (wu) – For fitting transactions in to a block.
- Virtual Bytes (vB) – For comparing fee rates between transactions.
Bytes is the most straightforward unit. It's used for measuring any amount of data on a computer.
Weight Units and Virtual Bytes are measurements unique to bitcoin. They both measure the size of a transaction in terms of bytes too, but they give a discount to some parts of the transaction data and are used when calculating how many transactions can fit inside a block.
1. Bytes (b)
This is the natural way to measure the size of a transaction. It's just a transaction's actual size in terms of how many bytes of space it takes up.
Bytes are used when measuring how big a transaction is when it's being sent across the network, or how much space it takes up on disk (e.g. when stored in blockchain files).
Measuring the size of a transaction in bytes was more important when the block size limit was also measured in bytes (1,000,000 bytes, or 1 megabyte). However, the block size limit is now based on weight instead.
Example
Transaction: 30dcd74b7fd8a585db3b2beddd4a7fc0edcfe9b8a1bac9abee695648659f8a6a
01000000000101dd40a8d7f105055e781afa632207f5d3c4b4f4cad9f0fb320d0f0aa8e1ba904b0000000000ffffffff021027000000000000160014858e1f88ff6f383f45a75088e15a095f20fc663f841c0000000000001976a9142241a6c3d4cc3367efaa88b58d24748caef79a7288ac02483045022100d66341c3e6ce846b92bedcf9bc673ab8e47b770c616618eb91009e44816f4c2f0220622b5ebf6afabee3f4255bbcb84609e1185d4b6b1055602f5eed2541e26324620121022ed6c7d33a59cc16d37ad9ba54230696bd5424b8931c2a68ce76b0dbbc222f6500000000Size: 226 bytes
There are 226 bytes in this transaction.
You can check this for yourself, because every 2 hexadecimal characters represents 1 byte.
Typical transaction sizes
The size of a transaction in bytes mostly depends on how many inputs and outputs are in the transaction. Here are the average sizes for typical transactions (with standard P2PKH locking scripts on the outputs):
- Inputs: 1, Outputs: 1 = 191 or 192 bytes
- Inputs: 1, Outputs: 2 = 225 or 226 bytes (most common)
- Inputs: 2, Outputs: 1 = 338 or 339 bytes
- Inputs: 2, Outputs: 2 = 373 or 374 bytes (very common)
The more inputs and outputs there are in a transaction, the bigger it gets.
There is no limit to how big a transaction can be in terms of bytes, other than the fact that it needs to be able to fit inside a block.
2. Weight Units (wu)
Every transaction has a weight measurement. This measurement was introduced in the segregated witness upgrade. A transaction's weight is calculated by multiplying the size (in bytes) of different parts of the transaction by either 4 or 1:
| Field | Multiplier |
|---|---|
| version | x4 |
| marker | x1 |
| flag | x1 |
| input | x4 |
| output | x4 |
| witness | x1 |
| locktime | x4 |
This therefore gives a discount to the witness data.
Example
Transaction: 30dcd74b7fd8a585db3b2beddd4a7fc0edcfe9b8a1bac9abee695648659f8a6a
01000000000101dd40a8d7f105055e781afa632207f5d3c4b4f4cad9f0fb320d0f0aa8e1ba904b0000000000ffffffff021027000000000000160014858e1f88ff6f383f45a75088e15a095f20fc663f841c0000000000001976a9142241a6c3d4cc3367efaa88b58d24748caef79a7288ac02483045022100d66341c3e6ce846b92bedcf9bc673ab8e47b770c616618eb91009e44816f4c2f0220622b5ebf6afabee3f4255bbcb84609e1185d4b6b1055602f5eed2541e26324620121022ed6c7d33a59cc16d37ad9ba54230696bd5424b8931c2a68ce76b0dbbc222f6500000000Size: 226 bytes
Weight: 574 weight units (116 x 4 + 110 x 1)
There are 226 bytes in this transaction. Out of those, 116 bytes are non-witness data so they get multiplied by 4, and 110 bytes are witness data so they get multiplied by 1. Add those together and you get 574 weight units.
Block Limit (4,000,000 weight units)
The weight measurement is important because blocks can hold up to 4,000,000 weight units of transaction data.
So when miners fill up their candidate blocks with transactions, they use transaction weight to determine how many transactions they can fit in their block.
Using bytes for transaction sizes and the block limit was more straightforward. But this new weight measurement introduces fairness to the cost of spending outputs.
Why does witness data weigh less?
Because it helps to bring more of a balance between the cost of creating an output and the cost of spending an output (in terms of transaction fees).
The amount of data required to unlock an output (i.e. signature data) is unfairly larger than the amount of data required to put a lock on an output in the first place. So the new weight measurement brings the "size" of outputs and inputs in a transaction more in line with each other.
3. Virtual Bytes (vBytes, vB)
The virtual size of a transaction is the same as its weight divided by 4.
Or to put it another way, instead of multiplying some parts of a transaction by 4 to create a discount for the witness data, you discount the witness data directly by multiplying it by 0.25 instead:
| Field | Multiplier |
|---|---|
| version | x1 |
| marker | x0.25 |
| flag | x0.25 |
| input | x1 |
| output | x1 |
| witness | x0.25 |
| locktime | x1 |
So "weight" and "virtual size" provide the same measurement, just with different units. But using virtual bytes makes it easier to compare the fee rate of new segwit transactions with the fee rate of legacy transactions (which had previously used sats-per-byte).
A legacy transaction will be the same size in bytes as it is in vbytes.
A block can hold 1,000,000 virtual bytes.
Example
Transaction: 30dcd74b7fd8a585db3b2beddd4a7fc0edcfe9b8a1bac9abee695648659f8a6a
01000000000101dd40a8d7f105055e781afa632207f5d3c4b4f4cad9f0fb320d0f0aa8e1ba904b0000000000ffffffff021027000000000000160014858e1f88ff6f383f45a75088e15a095f20fc663f841c0000000000001976a9142241a6c3d4cc3367efaa88b58d24748caef79a7288ac02483045022100d66341c3e6ce846b92bedcf9bc673ab8e47b770c616618eb91009e44816f4c2f0220622b5ebf6afabee3f4255bbcb84609e1185d4b6b1055602f5eed2541e26324620121022ed6c7d33a59cc16d37ad9ba54230696bd5424b8931c2a68ce76b0dbbc222f6500000000Size: 226 bytes
vSize: 143.50 virtual bytes (116 x 1 + 110 x 0.25)
There are 226 bytes in this transaction. Out of those, 116 bytes are non-witness data so they get multiplied by 1, and 110 bytes are witness data so they get multiplied by 0.25. Add those together and you get 143.50 virtual bytes.
As you can see, the weight and vsize calculations work in the same way.
Why do we use vbytes?
So why have both weight and vbytes? Why not calculate the weight of a transaction by multiplying some parts by 0.25 and just use that instead?
In other words, why have two measurements that do the same thing?
Because virtual size is fractional when computed accurately. Weight is an integer. We only use integers in consensus code.
You see, working with fractional numbers on computers can often lead to rounding errors, which is why in Bitcoin we prefer to work with whole numbers when performing critically important calculations. Integer arithmetic always returns consistent and reliable results, whereas floating point arithmetic does not.
So in summary:
- Weight Units — Used internally when working out how many transactions can fit in to a block.
- Virtual Bytes — Used by humans when comparing the different fee rates on transactions.
Resources
- BIP 141 (Transaction size calculations)
- Is there a difference between bytes and virtual bytes (vbytes)?
- Thanks to luke-jr for explaining to me on IRC how multiplying non-witness data by 4 helps to create a balance between the costs of creating and spending UTXOs.