Block weight

From Bitcoin Wiki
Revision as of 05:11, 23 August 2017 by Theymos (talk | contribs) (Detailed example)
Jump to: navigation, search

Prior to SegWit, there was a max block size of 1MB. After SegWit, the concept of max block size was removed and replaced with max block weight. The current max block weight is 4MB.

Definition of block weight

Normally, each byte in a transaction counts as 4 bytes of block weight. However, if a byte is part of the SegWit witness area, then it receives a discount, and only counts as 1 byte of block weight.

For example, let's say that you've previously received 0.5 BTC to SegWit address A, and 0.5 BTC to legacy address B. Now consider a transaction sending both of these amounts to some address C. The data unrelated to the transaction inputs are always non-witness data counted as 4 bytes/byte. In particular, address C doesn't matter, and can be SegWit, non-SegWit, or anything. The input data related to address A will, except for a constant amount of overhead, be witness data counted as 1 byte/byte. The input data related to address B is non-SegWit, and so will be counted as 4 bytes/byte. When we say "input data", we primarily mean the signatures and public keys in the scriptSig.

Conversion to real sizes

It is a common misconception that SegWit somehow makes transactions smaller, but this is incorrect. A 300-byte transaction is 300 bytes on-disk and on-wire. SegWit just counts those bytes differently toward the 4MB weight limit.

The maximum size of a block is nearly equal to the max block weight, so currently 4MB. This is not somehow "made-up" size; the maximum block is really 4MB on-disk and on-wire. However, this maximum should not usually be reached.

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 about 2.3MB typical blocks if all transactions were SegWit transactions.

Detailed example

Consider this transaction:

Data Description Raw byte count Type (multiplier) Section total weight Running total weight
01000000 Version 1 4 Non-witness (4x) 16 16
00 SegWit marker 1 Witness (1x) 1 17
01 SegWit flag 1 Witness (1x) 1 18
01 Number of inputs (1) 1 Non-witness (4x) 4 22
15..56 Previous output hash 32 Non-witness (4x) 128 150
03000000 Previous output index (3) 4 Non-witness (4x) 16 166
17 Script length (23 bytes) 1 Non-witness (4x) 4 170
16..28 Script: P2SH-enclosed P2WPKH witness program 23 Non-witness (4x) 92 262
ffffffff Sequence 4 Non-witness (4x) 16 278
01 Output count (1) 1 Non-witness (4x) 4 282
9caef50500000000 Output value (0.99987100 BTC) 8 Non-witness (4x) 32 314
19 Output script size (25) 1 Non-witness (4x) 4 318 Script: DUP HASH160 0x1d7c... EQUALVERIFY CHECKSIG 25 Non-witness (4x) 100 418
02 Number of stack items for input 0 (2) 1 Witness (1x) 1 419
48 Size of stack item 0 (72) 1 Witness (1x) 1 420
304...ab01 Stack item 0, signature 72 Witness (1x) 72 492
21 Size of stack item 1 (33) 1 Witness (1x) 1 493 Stack item 1, pubkey 33 Witness (1x) 33 526
00000000 Locktime (0) 4 Non-witness (4x) 16 542

The transaction's real size on disk and over the network is 218 bytes, the size in bytes of the whole transaction expressed above in hexadecimal. The weight is always greater than the real size, in this case 542 bytes.

It is not possible to create exactly-equivalent legacy transactions for SegWit transactions. If BTC is sent to a SegWit address, then it must be spent in a SegWit input. However, for comparison, a similar 1-input, 1-output legacy transaction would be about 191 bytes. The legacy transaction would consume 0.0191% of a 1MB legacy block, while this transaction consumes 0.0136% of a SegWit block, a reduction of 34%. Different transaction types can have much greater reductions.

You may notice that the transaction size has increased a little -- 218 bytes vs 191 bytes -- but most/all of the overhead is redundant data which could be removed. For example, if you have the witness, then you can compute the 23-byte P2SH script. If necessary, this data could be removed before transmitting the transactions: this would be a change to the P2P protocol which wouldn't even require a softfork.