Understanding Segwit Block Size

After I wrote my last article, I was surprised by the protest about the 2MB part of the title (the title has since been changed). The protest stems from the fact that Segwit2x would allow block sizes that are larger than 2MB (it’s possible to get very close to 8MB). This is often a point of confusion and also a point of very contentious debate.

In this article, I’m going to describe the difference between how Segwit determines block transaction capacity vs. how it is determined currently. If you’ve ever heard something like “Segwit is a block size increase” and didn’t understand what that meant, this article is written with you in mind. I’ll also describe how this affects Segwit2x and the block transaction capacity that we can expect to see before and after the 2x hard fork.

Block Size and Soft Fork

As part of the consensus rules, every node on the Bitcoin network currently checks that a block is less than 1,000,000 bytes. That is, a block that’s greater than 1,000,000 bytes will be rejected by these nodes as a consensus rule.

Because legacy nodes (that is, nodes that don’t upgrade) will reject a block that’s greater than 1,000,000 bytes, any soft fork must keep this rule. But how can you increase block size and still keep this rule? Are larger blocks via a soft fork even possible?

Enter Segregated Witness

BIP143 defines new transaction outputs that do exactly this. p2wpkh and p2wsh are very similar to p2pkh and p2sh respectively, but move scriptSig data to the end of the transaction.

Non-Segwit transactions (defined as txs only spending non-Segwit output like p2pk, p2pkh and p2sh) put the scriptSig in the middle of the transaction. Segwit transactions (defined as txs spending at least one p2wpkh or p2wsh output) put the scriptSig at the end. The scriptSig part of Segwit transactions is called the “witness data”. 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.

Restricting Segwit Blocks

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)

Non-Segwit transactions have zero witness data, so the weight for a non-Segwit transaction is exactly 4 times the size. Segwit transactions have some witness data so the weight is going to be less than 4 times the size. Note 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.

Block Weight

Thus, we can say the Block Transaction Capacity of non-Segwit transactions is the same as before Segwit. That is, you cannot fill Segwit blocks with non-Segwit transactions and be over 1,000,000 bytes. This is because non-Segwit transaction weight is directly proportional to size. 1000-byte non-Segwit transactions will always have a weight of 4000 no matter what the transaction is composed of.

This is not the case for Segwit transactions. 1000-byte Segwit transactions can have many different weights depending on how much of the transaction is taken up by Witness data. Consider two different transactions:

  • A 1000 byte Segwit transaction with 500 bytes of witness data
  • A 1000 byte Segwit transaction with 300 bytes of witness data

The first would have a weight of 500*3+1000=2500 whereas the second would have a weight of 700*3+1000=3100. From a miner’s perspective, if both transactions had the same fee, they would make more money including the former transaction as it takes up less weight in a block despite the same size.

Similarly, transactions of different sizes can have the same weight. Consider 3 different transactions:

  • An 800-byte Segwit transaction with 400 bytes of Witness data
  • An 1100-byte Segwit transaction with 800 bytes of Witness data
  • A 500-byte Non-Segwit transaction

All of these transactions have the same exact weight of 2000. When serialized to a Legacy node, they will be 400 bytes, 300 bytes and 500 bytes respectively (tx size without witness data). When serialized to a Segwit node, they will be 800 bytes, 1100 bytes and 500 bytes respectively.

At this point, you may be wondering how much Witness Data will be in a typical Segwit transaction. This depends on the number of p2wpkh or p2wsh inputs, but roughly speaking, Segwit Transactions are about 2/3 Witness Data.

So How Big Can Segwit Blocks Get?

It turns out that if you made a pathologically large Segwit transaction, you can make a block with just the coinbase transaction and a pathologically large Segwit transaction that’s very close to 4MB. Essentially, this pathologically large Segwit transaction would be mostly Witness Data with the block weight just under 4,000,000. That block would be very close to 4MB, but way under 1,000,000 bytes when stripped of witness data. This is an extraordinary case and wouldn’t be very profitable for a miner unless that transaction also had an extraordinarily high fee.

The normal case without pathologically large/giant fee Segwit transactions results in a block size of around 2MB, which is what the creators of Segwit designed for. When you hear someone say “Segwit is a block size increase”, this is what they’re referring to. The average Segwit block size will be roughly 2MB, though Legacy nodes will still receive blocks that are 1,000,000 bytes or lower due to stripped witness data.

Segwit2x

But my protesters have a point. The Segwit Block size (the only block size really left after a hard fork as there are no Legacy nodes) has a maximum of close to 8MB after the planned hard fork in Segwit2x. The normal case is actually more like 4MB.

Conclusion

For this reason, miners are not incentivized to make a block the maximum possible block size. This is because after a certain point (2mb without segwit2x hard fork, 4mb with), miners have to remove transactions in order to make the block size go up as they’re likely already up against the block weight limit. That, of course, reduces fees and makes mining a larger block add cost for a miner.

In other words, you can expect miners to mine around 2MB blocks with Segwit only and 4MB blocks with Segwit and 2x hard fork. What you can be sure of, however, is that miners will maximize the weight of each block as miner profit strictly increases with block weight. Blocks, then will have close to 4,000,000 weight with Segwit only and 8,000,000 weight with Segwit and 2x hard fork.

Segwit makes block size a less relevant concept. Block Weight is the more accurate and useful metric to judge blocks by, though it certainly has a relationship to size.

Want to get curated Technical Bitcoin News? Sign up for the Bitcoin Tech Talk newsletter!

Bitcoin Educator, Developer and Entrepreneur. Book: https://amzn.to/2RSlnTb PGP Fingerprint: C1D7 97BE 7D10 5291 228C D70C FAA6 17E3 2679 E455

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store