<blockquote>
<p>Normally I heard that the bitcoin blocksize is 1MB, but with the Segwit update the blocksize can be up to 4mb, so we should say that the blocksize is 4MB, right?</p>
</blockquote>
<p>Before the activation of segwit, the block was limited to 1,000,000 bytes. This limit got replaced by a blockweight limit of 4,000,000 weight units (WU) with the activation of segwit. A byte of witness data contributes 1 WU and a byte of non-witness data contributes 4 WU towards the limit. Theoretically, the block could therefore be up to 4,000,000 bytes if it was composed of witness data exclusively. In practice, even blocks consisting only of segwit transactions are expected to end up in the range of 2.1–2.7¹ MB because of the non-witness data that transactions always have. Blocksize is therefore no longer the correct term for the limit, rather we should say that <em>&quot;the blockweight limit is 4 MWU&quot;</em>.</p>
<blockquote>
<p>Moreover legacy nodes only receive the input and output data of segwit transactions. How do the legacy nodes verify the validity of segwit transactions. The legacy node can verify it during propagation from a segwit node, but how does it work for propagation between two legacy nodes, where the segwit data is missing completely?</p>
</blockquote>
<p>The transaction id (txid) of segwit transactions is calculated from the stripped transaction, i.e. the transaction data excluding the witness data. This has two effects: One, legacy nodes use the same identifier for segwit transactions as full nodes. Two, the txid of an unsigned transaction is the same as from the signed transaction (useful for setting up smart contracts, e.g. LN channels). When a legacy node requests a segwit transaction, the other node recognizes that the requesting node is on an outdated version and provides them with the stripped transaction. Legacy nodes can relay the stripped transaction among each other as well. To cover the signatures, segwit transactions additionally have a witness transaction id (wtxid) which covers the full data of the signed transaction. Segwit blocks also need to commit to the signed transactions, though! To that end, a second Merkle tree is built from the wtxids. The Merkle root of the wtxid tree is stored as the &quot;witness commitment&quot; in an OP_RETURN output on the coinbase transaction. This is in addition to the regular Merkle root in the block header that commits to the txids of the transactions and remains readable to legacy nodes.</p>
<p>Legacy nodes arrive at the same UTXO set, because stripped transactions specify which UTXO get spent in the inputs, and which new UTXO get created. Since legacy nodes do not know about the witness data, they cannot check the signatures of segwit transactions. Therefore, legacy nodes are not fully validating nodes (full nodes) that enforce all rules of the Bitcoin protocol independently (specifically, they don't enforce segwit's rules). The segwit transactions appear as valid to the legacy nodes, since the inputs appear to be &quot;anyone can spend&quot; to their dated understanding of the Bitcoin protocol rules.</p>
<hr />
<p><sub>¹On 2022-08-11 block 748,918 achieved a size of 2,765,062 B, exceeding that estimated range for the first time by including a lot of 2-of-3 P2WSH inputs. H/T @bordalix for pointing this out.</sub></p>

CC BY-SA 4.0
2020-09-01T22:25:38.377Z
2022-08-11T17:46:22.677Z
2022-08-11T17:46:22.677Z
Murch
<p>Normally, I heard that the bitcoin blocksize is 1MB, but with the Segwit update the blocksize can be up to 4MB, so we should say that the blocksize is 4MB, right? Moreover legacy nodes only receive the input and output data of segwit transactions. How do the legacy nodes verify the validity of segwit transactions. The legacy node can verify it during propagation from a segwit node, but how does it work for propagation between two legacy nodes, where the segwit data is missing completely? Thank you</p>

<segregated-witness><transaction-verification><blocksize><relay>
What's the blocksize limit after segwit and how do legacy nodes deal with segwit transactions?
Anh Dũng Lê
# What's the blocksize limit after segwit and how do legacy nodes deal with segwit transactions?

(Asked by: username_0 on 2020-09-01)

Normally, I heard that the bitcoin blocksize is 1MB, but with the Segwit update the blocksize can be up to 4MB, so we should say that the blocksize is 4MB, right? Moreover legacy nodes only receive the input and output data of segwit transactions. How do the legacy nodes verify the validity of segwit transactions. The legacy node can verify it during propagation from a segwit node, but how does it work for propagation between two legacy nodes, where the segwit data is missing completely? Thank you

**Tags:** segregated-witness, transaction-verification, blocksize, relay


---

## 1 answers

### Answer by username_1 on 2020-09-01. Score: 6 | Accepted answer

> Normally I heard that the bitcoin blocksize is 1MB, but with the Segwit update the blocksize can be up to 4mb, so we should say that the blocksize is 4MB, right?

Before the activation of segwit, the block was limited to 1,000,000 bytes. This limit got replaced by a blockweight limit of 4,000,000 weight units (WU) with the activation of segwit. A byte of witness data contributes 1 WU and a byte of non-witness data contributes 4 WU towards the limit. Theoretically, the block could therefore be up to 4,000,000 bytes if it was composed of witness data exclusively. In practice, even blocks consisting only of segwit transactions are expected to end up in the range of 2.1–2.7¹ MB because of the non-witness data that transactions always have. Blocksize is therefore no longer the correct term for the limit, rather we should say that *"the blockweight limit is 4 MWU"*.

> Moreover legacy nodes only receive the input and output data of segwit transactions. How do the legacy nodes verify the validity of segwit transactions. The legacy node can verify it during propagation from a segwit node, but how does it work for propagation between two legacy nodes, where the segwit data is missing completely?

The transaction id (txid) of segwit transactions is calculated from the stripped transaction, i.e. the transaction data excluding the witness data. This has two effects: One, legacy nodes use the same identifier for segwit transactions as full nodes. Two, the txid of an unsigned transaction is the same as from the signed transaction (useful for setting up smart contracts, e.g. LN channels). When a legacy node requests a segwit transaction, the other node recognizes that the requesting node is on an outdated version and provides them with the stripped transaction. Legacy nodes can relay the stripped transaction among each other as well. To cover the signatures, segwit transactions additionally have a witness transaction id (wtxid) which covers the full data of the signed transaction. Segwit blocks also need to commit to the signed transactions, though! To that end, a second Merkle tree is built from the wtxids. The Merkle root of the wtxid tree is stored as the "witness commitment" in an OP\_RETURN output on the coinbase transaction. This is in addition to the regular Merkle root in the block header that commits to the txids of the transactions and remains readable to legacy nodes.

Legacy nodes arrive at the same UTXO set, because stripped transactions specify which UTXO get spent in the inputs, and which new UTXO get created. Since legacy nodes do not know about the witness data, they cannot check the signatures of segwit transactions. Therefore, legacy nodes are not fully validating nodes (full nodes) that enforce all rules of the Bitcoin protocol independently (specifically, they don't enforce segwit's rules). The segwit transactions appear as valid to the legacy nodes, since the inputs appear to be "anyone can spend" to their dated understanding of the Bitcoin protocol rules.

---

¹On 2022-08-11 block 748,918 achieved a size of 2,765,062 B, exceeding that estimated range for the first time by including a lot of 2-of-3 P2WSH inputs. H/T @bordalix for pointing this out.


---

