<p>Very interesting question, let's see what the smallest transaction we can build is. For it to be minimal it has to be a single input and a single output. The non-segwit part would look something like this:</p>

<ul>
<li>4 bytes version</li>
<li>1 byte input count</li>
<li>Input

<ul>
<li>36 bytes outpoint</li>
<li>1 byte scriptSigLen (<code>0x00</code>)</li>
<li>0 bytes scriptSig</li>
<li>4 bytes sequence</li>
</ul></li>
<li>1 byte output count

<ul>
<li>8 bytes value</li>
<li>1 byte scriptPubKeyLen</li>
<li>22 bytes scriptPubKey (<code>0x0014{20-byte keyhash}</code>)</li>
</ul></li>
<li>4 bytes locktime</li>
</ul>

<p>This sums up to a total of 82 bytes for the non-witness part. So with a total non-witness blocksize of 1 million bytes we get a maximum of 12195 transactions. Assuming that all spent outputs were P2WPKH the witness part for each transaction consists of two pushes: one for the signature and one for the pubkey. These are around 72 bytes and 33 bytes long, and each need a length prefix of 1 byte. Additionally there is 1 byte witness version. So the total witness size is 108 bytes. With 3 MB of space in the witness block left, this brings us to about 27777 witnesses per block. So the limiting factor is the space in the non-witness part of the block, so that's the final number that we should consider.</p>

<p>Notice that I used the non-segwit serialization for the non-segwit part since that is what non-upgraded nodes will enfore. Notice also that this is an extreme example, since most transactions are not single-input-single-output. A corresponding non-segwit transaction would have a size of 192 bytes, which, together with the 1MB size limit brings us to 5208 transactions per block, compared to 12195 max segwit transaction per block.</p>

<p>The second part of your question regarding maximum UTXO in a block is rather easy. We'd like to amortize the overhead from the transaction structure, and maximize inputs + outputs. Since inputs are larger than outputs we will simple use a single input and compute the maximum number of outputs that fits in a block which is 32256. Since the outputs are non-segwit data, it also changes minimally from before the segwit activation (only the signature from the one input is moved to the segwit part). Therefore the maximum UTXO churn is 1 UTXO gets removed, 32256 get added. For comparison, without segwit the maximum number added was 32252. Notice that there may be other limits that I haven't considered, but this definitely are the upper limits, and these limits are unlikely to have changed during the activation of segwit.</p>

CC BY-SA 3.0
2017-09-13T13:28:14.303Z
Just to make sure we're comparing apples to apples: In both cases, we're talking about signed inputs and outputs that are not anyone-can-spend, right?
Nick ODell
CC BY-SA 3.0
2017-09-13T14:25:08.513Z
Right, in both cases we're talking `SIGHASH_ALL`, which is the most common use. Since we have just a single input and a single output, this also matches `SIGHASH_SINGLE`.
cdecker
CC BY-SA 3.0
2017-09-14T11:14:17.940Z
@cdecker if 1 tx = 1 utxo update / creation, then 12195 is the max utxo change in a block? Or, more than 12195 utxo can be updated (created) in a block?
vi.su.
CC BY-SA 3.0
2017-09-14T18:03:00.297Z
Probably not, but this is the smallest reasonable use I could come up with. If you were to create outputs with just OP_TRUE in it, you could get away with slightly smaller transactions, but you couldn't make sure that only the owner can spend them. Specifically you can get rid of 21 of the 22 bytes scriptPubKey, making the non-witness part only 61 bytes, bringing you to 16393 transactions, but again those wouldn't be secure at all.
cdecker
CC BY-SA 3.0
2017-09-23T02:57:18.667Z
@cdecker can you please answer 2 part of the question, so that I can mark it as answered.
vi.su.
CC BY-SA 3.0
2017-09-23T13:41:03.963Z
Well we are in the same order of magnitude for the updated UTXO entries. Remove 12195 and add 12195 new ones, though it might be possible to squeeze in some more inputs/outputs and further amortizing the transaction overhead.
cdecker
CC BY-SA 3.0
2017-09-23T13:56:54.380Z
Ok, looks like the maximum UTXO churn is a bit different, I'll amend my response :-)
cdecker
CC BY-SA 3.0
2017-09-13T12:42:34.837Z
2017-09-23T14:36:34.900Z
2017-09-23T14:36:34.900Z
cdecker
<p>With 100% segwit transactions, what would be the max number of transaction confirmation possible on a block?</p>

<p>And, how many utxo can be updated by a block full of segwit transactions?</p>

CC BY-SA 3.0
2017-09-23T05:08:46.707Z
what does it mean for an "utxo to be updated". UTXOs get consumed, and new ones are produced in each transaction. Can you elaborate what you actually mean?
rny
CC BY-SA 3.0
2017-09-23T07:33:45.610Z
Maximum, how many utxo are updated (created or consumed or updated) by a block full of segwit transactions (~12k)? Is it the same as pre-segwit?  I mean, max how many bitcoin addresses get updated by a block full of segwit transactions?
vi.su.
CC BY-SA 3.0
2017-09-23T09:20:12.320Z
i think cdecker made it really clear, if they are all transactions with 1 input and 1 output, then 12k will be the maximum number of UTXOs consumed and produced. Also, 12k transaction implies a maximum of 12k unique addresses getting produced.
rny
<transactions><confirmations><segregated-witness><utxo><blocksize>
With 100% segwit transactions, what would be the max number of transaction confirmation possible on a block?
vi.su.
# With 100% segwit transactions, what would be the max number of transaction confirmation possible on a block?

(Asked by: username_0 on 2017-09-11)

With 100% segwit transactions, what would be the max number of transaction confirmation possible on a block?

And, how many utxo can be updated by a block full of segwit transactions?

**Tags:** transactions, confirmations, segregated-witness, utxo, blocksize

> **Comments:**
> **username_1**: what does it mean for an "utxo to be updated". UTXOs get consumed, and new ones are produced in each transaction. Can you elaborate what you actually mean?  
> **username_0**: Maximum, how many utxo are updated (created or consumed or updated) by a block full of segwit transactions (~12k)? Is it the same as pre-segwit?  I mean, max how many bitcoin addresses get updated by a block full of segwit transactions?  
> **username_1**: i think username_2 made it really clear, if they are all transactions with 1 input and 1 output, then 12k will be the maximum number of UTXOs consumed and produced. Also, 12k transaction implies a maximum of 12k unique addresses getting produced.  

---

## 1 answers

### Answer by username_2 on 2017-09-13. Score: 15 | Accepted answer

Very interesting question, let's see what the smallest transaction we can build is. For it to be minimal it has to be a single input and a single output. The non-segwit part would look something like this:

* 4 bytes version
* 1 byte input count
* Input
  + 36 bytes outpoint
  + 1 byte scriptSigLen (`0x00`)
  + 0 bytes scriptSig
  + 4 bytes sequence
* 1 byte output count
  + 8 bytes value
  + 1 byte scriptPubKeyLen
  + 22 bytes scriptPubKey (`0x0014{20-byte keyhash}`)
* 4 bytes locktime

This sums up to a total of 82 bytes for the non-witness part. So with a total non-witness blocksize of 1 million bytes we get a maximum of 12195 transactions. Assuming that all spent outputs were P2WPKH the witness part for each transaction consists of two pushes: one for the signature and one for the pubkey. These are around 72 bytes and 33 bytes long, and each need a length prefix of 1 byte. Additionally there is 1 byte witness version. So the total witness size is 108 bytes. With 3 MB of space in the witness block left, this brings us to about 27777 witnesses per block. So the limiting factor is the space in the non-witness part of the block, so that's the final number that we should consider.

Notice that I used the non-segwit serialization for the non-segwit part since that is what non-upgraded nodes will enfore. Notice also that this is an extreme example, since most transactions are not single-input-single-output. A corresponding non-segwit transaction would have a size of 192 bytes, which, together with the 1MB size limit brings us to 5208 transactions per block, compared to 12195 max segwit transaction per block.

The second part of your question regarding maximum UTXO in a block is rather easy. We'd like to amortize the overhead from the transaction structure, and maximize inputs + outputs. Since inputs are larger than outputs we will simple use a single input and compute the maximum number of outputs that fits in a block which is 32256. Since the outputs are non-segwit data, it also changes minimally from before the segwit activation (only the signature from the one input is moved to the segwit part). Therefore the maximum UTXO churn is 1 UTXO gets removed, 32256 get added. For comparison, without segwit the maximum number added was 32252. Notice that there may be other limits that I haven't considered, but this definitely are the upper limits, and these limits are unlikely to have changed during the activation of segwit.

> **Comments:**
> **username_3**: Just to make sure we're comparing apples to apples: In both cases, we're talking about signed inputs and outputs that are not anyone-can-spend, right?  
> **username_2**: Right, in both cases we're talking `SIGHASH_ALL`, which is the most common use. Since we have just a single input and a single output, this also matches `SIGHASH_SINGLE`.  
> **username_0**: @username_2 if 1 tx = 1 utxo update / creation, then 12195 is the max utxo change in a block? Or, more than 12195 utxo can be updated (created) in a block?  
> **username_2**: Probably not, but this is the smallest reasonable use I could come up with. If you were to create outputs with just OP_TRUE in it, you could get away with slightly smaller transactions, but you couldn't make sure that only the owner can spend them. Specifically you can get rid of 21 of the 22 bytes scriptPubKey, making the non-witness part only 61 bytes, bringing you to 16393 transactions, but again those wouldn't be secure at all.  
> **username_0**: @username_2 can you please answer 2 part of the question, so that I can mark it as answered.  
> **username_2**: Well we are in the same order of magnitude for the updated UTXO entries. Remove 12195 and add 12195 new ones, though it might be possible to squeeze in some more inputs/outputs and further amortizing the transaction overhead.  
> **username_2**: Ok, looks like the maximum UTXO churn is a bit different, I'll amend my response :-)  

---

