Segwit Block Size and Block Weights
This is an old topic, nevertheless, I felt it must be shared, as Is still hear some confusions about Block Sizes and Block Weights after the Segwit was implemented.
To understand these, we must first understand the basic what changes to transaction structure were done after Segwit.
Transactions before and after Segwit
- Before Segwit: Every transaction has a transaction-hash, input script, script signatures, and outputs. (Note: There are many other fields but only these are important to the current discussion)
- After Segwit: Input Scripts and Script Signatures for every transaction, which in Segwit is replaced with EMPTY and OP_TRUE. The input script and script signature are replaced in another section called Witness. Witness is optional to store. It means you have the option to store or not store the Witness. It may raise a question, that if you don’t store the witness, how can you verify the transaction? In fact, we cannot. If you don’t store/download the witness, you cannot verify the transaction and your node will treat this transaction as an airdrop. By the time I am writing this, 90% of the nodes are Segwit and rest 10% are not. That means, these 10% nodes don’t store witnesses.
Segwit Transactions in Block
As known, each Merkle Root is the hash of transactions taken two at a time. As mentioned before, the witness, which is nothing but the input script and script signature is separated from the transaction itself. A separate Witness trie is now constructed which is appended at the end of the Coinbase Transaction. Just like Transaction Trie, witnesses also have Witness Trie. Witness Trie Root is also now included in the block header.
As mentioned before, Witnesses are optional. This means that Witness Trie, which is represented in Green Color in the diagram can be removed/not-downloaded if you are running a non-segwit or legacy node. This was done to ensure that Segwit was backward compatible, hence it was soft-fork
Transaction Sizes and the concept of Transaction Weights
After segwit was introduced a new concept of weights was introduced.
A segwit transaction was divided into two parts:
- Segwit Part of Transaction: The witness of a transaction is classified as segwit part of a transaction.
- Non-Segwit Part of Transaction: All the other parts of transactions except witness are classified as Non-Segwit part of a transaction.
That implies, that a Segwit Transaction has two parts, which are Segwit part and Non-Segwit part, whereas Non-Segwit transaction has only one part (which is by default a Non-Segwit part of a transaction)
The weight of any transaction is defined by a simple formula:
3*(non-segwit-part-of-transaction) + 1*(segwit-part-of-transaction)This implies, that if a transaction is a legacy transaction, it has more weight as all the part of it is a non-segwit-part-of-transaction
A block weight is defined as the sum of weights of all transactions in the block.
Block Size, Segwit Block Size and Block weight
Now a block can now contain legacy transactions as well as segwit transactions.
Before we proceed ahead, we must know, the simple definitions of the three terms. (Note: These are rough definitions, only for simpler explanation):
- Block Size: Sum of sizes of all non-segwit data in a block + headers.
- Segwit Block Size: Sum of sizes of all non-segwit data in block + Sum of all segwit data in block + headers
- Block weight: Sum of weights of all transactions in a block.
Bitcoin imposes a rule of 1MB max size on Block Size, not Segwit Block Size. As of the time when I am writing this article, a sample block here has a size of 1204.232 Kb. This refers to Segwit Block Size. If the segwit data is removed from this block, the Block Size will be less than 1Mb. The max block weight can be 4MBU
The underlying diagram illustrates how a block can have segwit and non-segwit transactions, and how Block Size, Segwit Block Size and Block Weight is calculated. (In this case 2 Segwit Transactions and 4 Non-Segwit Transactions)
That indicates that til the size of the legacy block is less than 1MB, it is a valid block on the chain. Where the segwit block size can be more than 1MB, but it must ensure that block weight is less than 4MB.
We can equate the diagram as follows:
legacy_block_size = ∑(size_of_non-segwit-data_of_each_transaction)segwit_block_size = legacy_block_size + ∑(size_of_segwit-data_of_each_transaction)
For a block, it non_segwit_weight and segwit_weight is defined as
non_segwit_weight = 3*∑(size_of_non-segwit-data_of_each_transaction)segwit_weight = 1*∑(size_of_segwit-data_of_each_transaction)block_weight = non_segwit_weight + segwit_weight
For a block to be valid
legacy_block_size <= 1 MB
block_weight <= 4MBUConclusions and Rest:
- If you run a Segwit node, you will receive the segwit blocks which may be more than 1MB, whereas if you run a non-segwit node all the witnesses from the segwit block will be trimmed off and the block becomes a legacy block. This legacy block will be less than 1MB.
- Segwit was a soft fork that means not changing from legacy node to segwit will still make your node a valid and up to time on the chain. However, you will not be able to verify the validity of segwit transactions in that block.
- For a non-mining node, segwit was a benefit as now more transactions were fit into the block as witnesses were removed.
- However, this was not universally accepted as some among the community were not comfortable with Segwit, as some of the nodes won’t have witnesses/signatures. This resulted in chain splitting and created BCH (Bitcoin Cash). BCH now has an adjustable block size.
- Just like legacy addresses, Segwit addresses also exists. For legacy addresses, P2PKH and P2SH stand for “Pay to Public Key Hash” and “Pay to Script Hash” respectively. For Segwit addresses, P2WPKH and P2WSK stand for “Pay to Witness Pubkey Hash” and “Pay to Witness Script Hash” respectively. How each address is made shall be discussed in another article.
Contact me @ www.akshaymeher.info for any further doubts.