What's the blocksize limit after segwit and how do legacy nodes deal with segwit transactions?

Question

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

Answer 1

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.}

Answer 2

1. Segregated witness therefore takes advantage of this opportunity to raise the block size limit to nearly 4 MB, and adds a new cost limit to ensure blocks remain balanced in their resource use (this effectively results in an effective limit closer to 1.6 to 2 MB).

https://bitcoincore.org/en/2016/01/26/segwit-benefits/#block-capacitysize-increase

2. The maximum block size is 4,000,000 bytes (4 MB). This is because the block weight calculation is base size (in MB) * 3 + total size (in MB) = block weight (see BIP 141). Since the only units are MB, the block weight's only units are also MB, thus the maximum block size is the same as the block weight.

In theory, you can get pretty close to 4M, by having transactions that consist almost entirely of witness data. In practice, that won't happen for normal financial transactions, closer to 2M.

https://bitcoin.stackexchange.com/a/54949/

3. SegWit simply lets you verify non-witness transaction data without downloading (then discarding) the witnesses, which solves the problem of light clients having to download things they don’t care about and can’t verify anyway.

https://blockstream.com/2017/07/31/en-segwit-myths-debunked/

4. When Segwit transactions are sent to Legacy nodes the witness data is stripped. The key is that these “stripped” transactions are still valid transactions on Legacy nodes, which gives us a savings over non-Segwit transactions. Thus, more transactions can fit into the block sent to Legacy nodes without going over the 1,000,000 byte limit.

Segwit nodes get Segwit transactions and blocks that include the witness data using alternate network messages. The new network messages are defined in BIP144 as part of Segwit. The Segwit blocks which include the witness data can be over 1,000,000 bytes. Legacy nodes, as mentioned, receive the same blocks and transactions, but with the witness data stripped. This is a way to make Segwit a soft fork.

The Segwit blocks are restricted by something called Block Weight. Block Weight is a new concept introduced in Segwit, and it’s calculated on a per-transaction basis.

Each transaction has a “weight” which is defined this way:

(tx size with witness data stripped) * 3 + (tx size)

Segwit transactions are transmitted to Legacy nodes without witness data, so this formula will always result in blocks communicated to Legacy Nodes that are less than or equal to 1,000,000 bytes. Again, this is why Segwit is a soft fork.

https://link.medium.com/3lvCPzo5q9

5. Size vs Weight: What is block weight and how is it different from block size?