I often see claims that Segwit increases transactions per block by 1.7x to 2x. I'm not sure if this is true, but if I do the math myself, I don't get this number.

My understanding is:

1) The “weight” calc changes from:

weight = transaction size
weight = non_sig_siz * 4 + sig_size

where total max "weight" per block goes from 1024^2 to 4*(1024^2).

Really weight is a new concept, previously it was measured in bytes.

2) That typical transactions are around 500b, and that signatures are 65b of that. They vary, but you can check here for average historical transaction sizes:



((500.0 – 65.0)*4+65)/4.0 = 451.25
1-(451.25/500) = 9.7% 

Suggesting we’d only get about 10% not 70-100% more transactions with segwit.

I'm not sure if there a mistake in my math, or my understanding of segwit weights, or typical tx sizes, or something else. I've seen 1.7 to 2x in posts from people more knowledgeable than me, so I would be interested to see how this works.

Of course if transactions were not typical, and had almost nothing but signature data in them, you could fit far far more transactions in a block. E.g. if you could find a way to create a transaction that was only signature data, you could fit about 8x as many transactions per block, though those transactions would be useless.

For typical realistic use cases, is my 10% figure in the right order of magnitude, or is there something I'm missing that would allow 2x as many realistic useful transactions?


1 Answer 1


Note that the scriptSig field is not just the ECDSA signature itself (65 bytes) but also the public key in the case of a P2PKH input, or the redeem script for a P2SH input, and a couple more bytes for sizes. Also, there is a scriptSig for every input, not just one per transaction. You are looking at the average transaction size, most of which contain multiple inputs, but then assuming only one signature of 65 bytes.

Let's take an example transaction with a single input and output: https://blockchain.info/tx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653

This transaction is 226 bytes, 108 bytes of which is the scriptSig (including the length byte), which is nearly half the size of the transaction. Because the average transaction has more than just one input, the multiple scriptSigs make up a higher percentage of the total transaction size in those transactions - on average around 60% of the transaction. Taking that into account gives you the estimated increase on average, which was based on simulations run with the new rules according to current usage I believe.

Really weight is a new concept, previously it was measured in bytes.

Indeed, it's misleading to say weight was the transaction size in bytes before this new weight was defined, you should compare the old size to the new virtual transaction size (which basically is what you did anyway by dividing by 4)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.