# How has the Bitcoin average block size recently risen above 3 MB?

I was aware that the block size could rise above the 1 MB cap due to SegWit. However, my understanding was that the block size would still be limited under SegWit.

My understanding of SegWit is that it partitions the signature part of the block from the transaction part. I also believe I read that the signature part can account for 65% of the block size. If this is true, I would be under the impression that the maximum block size with SegWit would be 1 MB * (1/.35) making the theoretical maximum 2.85 MB.

Is there a way to calculate the theoretical maximum allowed in Bitcoin blocks and where is my understanding above flawed?

I also believe I read that the signature part can account for 65% of the block size.

This is not entirely correct. The typical size of a block depends on the make-up of transactions in that block. The size of signatures to overall block size will depend on the number of inputs in a transaction. More the number of inputs in a transaction, higher the signature components and higher the ratio of signature size to block size. Also, higher the number of multi-sig inputs, more the signature components per input. Also, one has to note that both the signature and the redeemScript form the part of the witness, and not just the signature.

Is there a way to calculate the theoretical maximum allowed in Bitcoin blocks and where is my understanding above flawed?

Yes, the theoretical maximum limit of block size is 4,000,000 WU. To calculate size in bytes, it will be very very close to 4,000,000 bytes. Consider a block made up of only one transaction, with only one OP_TRUE anyonecanspend output in that transaction and only one input. Assume the `redeemScript` and `signature` are so big that they take up the maximum allowed space in the block (Bitcoin supports custom scripting, so I can theoretically create a script in that way). Now, the standard components of the a block are:

``````size = 4 bytes / 16 WU
block header = 80 bytes / 320 WU
transaction counter = 1-9 bytes (1 byte in our case as we use 1 tx) = 4 WU
Transactions = variable

So this leaves 4,000,000 - (16 + 320 + 4) = 3,999,660 WU for our transaction.
``````

Standard components of the transaction are:

``````nVersion = 4 bytes / 16 WU
number of inputs = 1 byte / 4 WU
previous transaction txid = 32 bytes / 128 WU
previous transaction output index = 4 byte / 16 WU
script length = 1 byte / 4 WU
script = 0 byte
nSequence = 4 bytes / 16 WU
output count = 1 byte / 4 WU
amount size = 4 bytes / 16 WU
script length = 1 byte / 4 WU
script (OP_TRUE) = 1 byte / 4 WU
nLocktime = 4 bytes /16 WU

so witness size is: 3,999,660 WU - 228 WU = 3,999,432 WU
``````

Now, to convert this to traditional bytes that would be relayed on the wire:

``````340/4 + 228/4 + 3,999,432 = 3,999,574 bytes
``````

Note: Standard transaction weight is 400,000 WU, which means full nodes won't relay transactions higher than this cap. However, consensus rules allows transaction to be as high as the block size, which means nothing stops a miner from including this transaction in a block and then mine the block with it.