<p>There is a large gap between the theoretical maximum value of tx per second vs. what is actually feasible.</p>
<p><em>Edit. Note that these calculations are arbitrary, as the comment from Murch pointed out the smallest possible tx without a real purpose could be even smaller. These transactions will not transfer any BTC over the network, but for the sake of theoretical maximum speeds they can be calculated.</em></p>
<p>The theoretical minimum-sized transaction is an <a href="https://en.bitcoin.it/wiki/OP_CHECKSIG" rel="nofollow noreferrer">OP_CHECKSIG</a> transaction with the minimum size of 166 bytes for the whole tx. The tx looks like this (the total size of 166 bytes is the two scripts + reference to previous tx + headers):</p>
<p><code>scriptPubKey: &lt;33 byte compressed pubKey&gt; OP_CHECKSIG scriptSig: &lt;72 byte signature&gt;</code></p>
<p>Given a 1 MB block, we get <code>1,000,000 bytes / 166 bytes</code> per block which is about 6024 tx per block. On an average, a block is mined every ten minutes. This means <code>6024/(60*10)</code> or around 10 tx per second. A conservative estimate of a transaction having two inputs and two outputs equates to a rough tx size of 320 bytes which will halve our estimation to 5 tx per second.</p>
<p><em>Edit. Fix segwit calculations, as pointed out by Murch in the comments</em></p>
<p>For a 100 % segwit block there is a great calculation in <a href="https://bitcoin.stackexchange.com/a/59501/147910">this answer by cdeker</a>. Basically a full segwit block could hold up to 12195 transactions per block (calculated by having the non-segwit part as a limiting factor, which is 82 bytes in the optimal case). This will result in about 20,3 tx/s.</p>
<p>You can calculate the theoretical maximum speed by dividing your tx count in a block by 600 seconds. How many tx will fit into a block can be calculated in many different ways but the theoretical possibilities are far from actual usage. For the current situation in real world, you can see that <a href="https://www.blockchain.com/explorer/charts/n-transactions-per-block" rel="nofollow noreferrer">the avg number of tx in a block</a> hovers around 3000 tx per block.</p>

CC BY-SA 4.0
2024-02-21T13:23:12.530Z
This answer has a few issues. If you allow non-standard transactions, the theoretical minimum-sized transaction would be to spend an OP_TRUE output with an empty input script, and create a new OP_TRUE output. Such a transaction has 60 bytes. If you only look at standard transactions, a tx with a single P2TR input and a P2WPKH output has 99 vbytes. A block can fit just shy of 10,000 of those. It’s not clear to me why you think that segwit doesn’t matter for your calculation, segwit transactions are way more blockspace efficient, see e.g. https://bitcoin.stackexchange.com/q/84004/5406
Murch
CC BY-SA 4.0
2024-02-21T13:46:18.527Z
Thanks, your points are valid. I did include an input script as part of the calculation to at least somewhat make assumptions about what a smallest feasible tx would have. But I feel like the actual value is not so important, the point is that a more realistic tx will always be much larger. I will edit to make it more clear that the first part is arbitrary. I will also edit to add a segwit calculation.
Juha Siivikko
CC BY-SA 4.0
2024-02-21T08:39:31.587Z
2024-02-21T13:54:34.537Z
2024-02-21T13:54:34.537Z
Juha Siivikko
<p>If you want to maximize the (useful) transactions per block, you should try to minimize the transaction weight. The smallest payment transaction using <em>standard</em> output types would be a transaction with a single P2TR keypath input and a P2WPKH output. This transaction would weigh:</p>
<p>42 WU (Header) + 230 WU (P2TR input) + 124 WU (P2WPKH output) = <strong>396 WU (= 99 vbytes)</strong></p>
<p>You would be able to fit about 10,100 such transactions into a block, which would amount to about 16.833 transactions per second.</p>
<p>If you wanted to maximize the creation of UTXOs, your goal would not be to maximize the <em>transactions per second</em> (which in itself is a meaningless metric, if one considers that transactions can perform multiple payments and range in 60 to 100,000 vB), but rather the <em>payments per second</em>. To that end, we would create transactions with a single P2TR input and as many outputs as possible. In that case, we would be able to fit 10 transactions into a block that each create 3222 P2WPKH outputs.</p>
<p>This would allow us to create about 32,200 additional UTXOs in each block, i.e. approximately <em><strong>53.667 payments per second</strong></em>.</p>

CC BY-SA 4.0
2024-02-21T14:16:40.913Z
2024-02-21T14:22:40.583Z
2024-02-21T14:22:40.583Z
Murch
<p>What's max possible tx/second right now, if we use all the latest Bitcoin tech multi-sig,  MAST + Taproot, without increasing block size? Let's say our goal is simple tx finality and 10b utxo.</p>
<p>How do I calculate this max utxo possible right now per block, or per second?</p>

CC BY-SA 4.0
2024-02-21T13:50:12.423Z
Does https://bitcoin.stackexchange.com/q/111234/5406 answer your question?
Murch
<utxo><transaction-capacity>
What's max possible tx/second right now?
vi.su.
# What's max possible tx/second right now?

(Asked by: username_0 on 2024-02-21)

What's max possible tx/second right now, if we use all the latest Bitcoin tech multi-sig, MAST + Taproot, without increasing block size? Let's say our goal is simple tx finality and 10b utxo.

How do I calculate this max utxo possible right now per block, or per second?

**Tags:** utxo, transaction-capacity

> **Comments:**
> **username_1**: Does https://bitcoin.stackexchange.com/q/111234/5406 answer your question?  

---

## 2 answers

### Answer by username_2 on 2024-02-21. Score: 2

There is a large gap between the theoretical maximum value of tx per second vs. what is actually feasible.

*Edit. Note that these calculations are arbitrary, as the comment from username_1 pointed out the smallest possible tx without a real purpose could be even smaller. These transactions will not transfer any BTC over the network, but for the sake of theoretical maximum speeds they can be calculated.*

The theoretical minimum-sized transaction is an [OP\_CHECKSIG](https://en.bitcoin.it/wiki/OP_CHECKSIG) transaction with the minimum size of 166 bytes for the whole tx. The tx looks like this (the total size of 166 bytes is the two scripts + reference to previous tx + headers):

`scriptPubKey: <33 byte compressed pubKey> OP_CHECKSIG scriptSig: <72 byte signature>`

Given a 1 MB block, we get `1,000,000 bytes / 166 bytes` per block which is about 6024 tx per block. On an average, a block is mined every ten minutes. This means `6024/(60*10)` or around 10 tx per second. A conservative estimate of a transaction having two inputs and two outputs equates to a rough tx size of 320 bytes which will halve our estimation to 5 tx per second.

*Edit. Fix segwit calculations, as pointed out by username_1 in the comments*

For a 100 % segwit block there is a great calculation in [this answer by cdeker](https://bitcoin.stackexchange.com/a/59501/147910). Basically a full segwit block could hold up to 12195 transactions per block (calculated by having the non-segwit part as a limiting factor, which is 82 bytes in the optimal case). This will result in about 20,3 tx/s.

You can calculate the theoretical maximum speed by dividing your tx count in a block by 600 seconds. How many tx will fit into a block can be calculated in many different ways but the theoretical possibilities are far from actual usage. For the current situation in real world, you can see that [the avg number of tx in a block](https://www.blockchain.com/explorer/charts/n-transactions-per-block) hovers around 3000 tx per block.

> **Comments:**
> **username_1**: This answer has a few issues. If you allow non-standard transactions, the theoretical minimum-sized transaction would be to spend an OP_TRUE output with an empty input script, and create a new OP_TRUE output. Such a transaction has 60 bytes. If you only look at standard transactions, a tx with a single P2TR input and a P2WPKH output has 99 vbytes. A block can fit just shy of 10,000 of those. It’s not clear to me why you think that segwit doesn’t matter for your calculation, segwit transactions are way more blockspace efficient, see e.g. https://bitcoin.stackexchange.com/q/84004/5406  
> **username_2**: Thanks, your points are valid. I did include an input script as part of the calculation to at least somewhat make assumptions about what a smallest feasible tx would have. But I feel like the actual value is not so important, the point is that a more realistic tx will always be much larger. I will edit to make it more clear that the first part is arbitrary. I will also edit to add a segwit calculation.  

---

### Answer by username_1 on 2024-02-21. Score: 2

If you want to maximize the (useful) transactions per block, you should try to minimize the transaction weight. The smallest payment transaction using *standard* output types would be a transaction with a single P2TR keypath input and a P2WPKH output. This transaction would weigh:

42 WU (Header) + 230 WU (P2TR input) + 124 WU (P2WPKH output) = **396 WU (= 99 vbytes)**

You would be able to fit about 10,100 such transactions into a block, which would amount to about 16.833 transactions per second.

If you wanted to maximize the creation of UTXOs, your goal would not be to maximize the *transactions per second* (which in itself is a meaningless metric, if one considers that transactions can perform multiple payments and range in 60 to 100,000 vB), but rather the *payments per second*. To that end, we would create transactions with a single P2TR input and as many outputs as possible. In that case, we would be able to fit 10 transactions into a block that each create 3222 P2WPKH outputs.

This would allow us to create about 32,200 additional UTXOs in each block, i.e. approximately ***53.667 payments per second***.


---

