Weight units

Bitcoin was released with an implicit maximum block size limit of 32 mibibytes (32 MiB), which was the maximum allowed size of a P2P protocol block message.[2] Effective block 79,400 (7 September 2010), this became an explicit limit of 1 megabyte (1 MB).[3]

In both cases, to calculate how much a transaction or other data counted towards these maximum block size limits, you simply put the data in the format used by the P2P protocol's block message and counted the bytes.

The introduction of a soft-fork segregated witness (segwit) idea in late 2015[4] meant that the transaction format could be extended with new fields that would be excluded from the historic block size limits—allowing an increase in the maximum block size. But that increase was only possible in a soft fork if the new fields contributed less towards the maximum block size than the fields in the original transaction format.

Although some people complained about that being unfair[5], many Bitcoin Protocol developers considered discounting the new fields to be advantageous.[6][7] The new fields store witnesses, which are transaction signatures and other data necessary to authenticate the spender of certain bitcoins. Witnesses do not need to be stored by all full nodes after they are processed, unlike other parts of a transaction, so they have less effect on the cost of node operation and (arguably) warrant a discount.

This introduction of a discount for certain fields in certain transactions lead to the development of the weight unit which allows easy comparison between transactions that contain the discounted fields and those that don't. Weight units were designed to be fully backwards compatible with all previous versions of Bitcoin Core even though blocks created after segwit activated may include up to almost four times as much data as they could previously.

For backwards compatibility with software using the earlier bytes metric[8], virtual size (vsize) was introduced. A unit of vsize is equal to four weight units. Some developers call a unit of vsize by the name of vbyte[9] because the number of bytes and vbytes in a transaction are identical for legacy transactions.

Transactions that don't use segregated witness (segwit) are currently called legacy transactions. For these transactions, calculating the number of weight units in a transaction is as easy as putting the transaction into the format used in a P2P protocol block message, counting the number of bytes, and multiplying by four.

For example, at the time of writing (January 2018), the most commonly seen transaction template in the block chain is a legacy transaction with one input (using P2PKH with a compressed pubkey) and two P2PKH outputs, or about 226 bytes. Here's a byte map of that transaction template:

To change from bytes to weight units, we simply scale everything up by a factor of four:

At 904 weight, to include the above transaction in a block consumes 0.0226% of the available maximum block space.

To convert from weight units to vbytes, divide the total by four. For legacy transactions, this means that vbytes are equal to bytes.

Transactions that use segregated witnesses are called segwit transactions. For these transactions, calculating the number of weight units in a transaction is more complicated.

• The transaction is put into the format used by a P2P protocol block message (segwit-enabled)
• Each byte of the segwit marker, flag, and witness fields counts as one weight unit
• Each byte of the other fields in the transaction counts as four weight units

For example, the segwit equivalent to the P2PKH transaction analyzed in the legacy section above would be a transaction with one input (using P2WPKH) and two P2WPKH outputs, or about 222 bytes. Here's a byte map of that transaction template with the segwit-specific fields highlighted in blue:

To change from bytes to weight units, we use the method described above where the highlighted fields stay the same size but the other fields are multiplied by four. When displayed at the same scale, this makes it appear that the segwit fields have shrunk:

At 561 weight units, to include the above transaction in a block consumes 0.014025% of the available maximum block space, a 61% reduction compared to the equivalent legacy transaction described previously. The exact amount of space saved by converting from legacy transactions to segwit transactions will vary depending on various transaction details.

To convert from weight units to vbytes, divide by four. For the example transaction above, this makes the transaction 140.25 vbytes. Note that fractional vbytes are possible, but they may not be compatible with legacy applications that expect only integer values, so it is recommended[10] to round up. For example, Bitcoin Core reports this transaction as having a vsize of 141 vbytes.

Possibly because of the vbytes metric, it is a common misconception that segwit somehow makes transactions much smaller—but this is incorrect. A 300-byte transaction is 300 bytes on-disk and over-the-wire. Segwit just counts those bytes differently toward the maximum block size of 4M weight units.

The maximum size of a block in bytes is nearly equal in number to the maximum amount of block weight units, so 4M weight units allows a block of almost 4M bytes (4MB). This is not a somehow "made-up" size; the maximum block size is really almost 4MB on-disk and over-the-wire. However, this maximum can only be reached if the block is full of very weirdly-formatted transactions, so it should not usually be seen.

The typical size of a block depends on the make-up of transactions in that block. As of 2017, the average transaction make-up would lead to blocks with 4M weight units being about 2.3MB in size if all transactions were segwit transactions.

0100000000010115e180dc28a2327e687facc33f10f2a20da717e5548406f7ae8b4c8
11072f85603000000171600141d7cd6c75c2e86f4cbf98eaed221b30bd9a0b928ffff
ffff019caef505000000001976a9141d7cd6c75c2e86f4cbf98eaed221b30bd9a0b92
888ac02483045022100f764287d3e99b1474da9bec7f7ed236d6c81e793b20c4b5aa1
f3051b9a7daa63022016a198031d5554dbb855bdbe8534776a4be6958bd8d530dc001
c32b828f6f0ab0121038262a6c6cec93c2d3ecd6c6072efea86d02ff8e3328bbd0242
b20af3425990ac00000000