<p>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. </p>

<p>Let's take an example transaction with a single input and output: <a href="https://blockchain.info/tx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653" rel="nofollow noreferrer">https://blockchain.info/tx/82d62d5f4e69ae8338c39b7ae2e1d33db59bdf62c869ded7344adc936bab8653</a></p>

<p>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.</p>

<blockquote>
  <p>Really weight is a new concept, previously it was measured in bytes.</p>
</blockquote>

<p>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)</p>

CC BY-SA 3.0
2017-08-20T20:29:38.053Z
2017-08-20T20:29:38.053Z
meshcollider
<p>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.</p>

<p>My understanding is:</p>

<p>1) The “weight” calc changes from:</p>

<pre><code>weight = transaction size
to:
weight = non_sig_siz * 4 + sig_size
</code></pre>

<p>where total max "weight" per block goes from <code>1024^2 to 4*(1024^2)</code>.</p>

<p>Really weight is a new concept, previously it was measured in bytes.</p>

<p>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:</p>

<p><a href="https://tradeblock.com/bitcoin/historical/1h-f-tsize_per_avg-01101" rel="nofollow noreferrer">https://tradeblock.com/bitcoin/historical/1h-f-tsize_per_avg-01101</a></p>

<p>3)</p>

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

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

<p>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.</p>

<p>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.</p>

<p>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?</p>

CC BY-SA 3.0
2018-01-31T12:30:51.657Z
There is a related answer that may also be of value: https://bitcoin.stackexchange.com/a/69678/75001
Willtech
<segregated-witness><blocksize><block-weight><witness-data>
How much will Segwit *actually* increase bitcoin capacity for realistic transactions?
Brian
# How much will Segwit *actually* increase bitcoin capacity for realistic transactions?

(Asked by: username_0 on 2017-08-20)

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
to:
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:

<https://tradeblock.com/bitcoin/historical/1h-f-tsize_per_avg-01101>

3)

```
((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?

**Tags:** segregated-witness, blocksize, block-weight, witness-data

> **Comments:**
> **username_1**: There is a related answer that may also be of value: https://bitcoin.stackexchange.com/a/69678/75001  

---

## 1 answers

### Answer by username_2 on 2017-08-20. Score: 2 | Accepted answer

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)


---

