<h2>Status Quo</h2>
<p>The CoinJoin transaction only has a minimally reduced blockspace requirement in comparison to the unaggregated transactions:</p>
<p>Transaction sizes (example is P2PKH) can be calculated by the following formula:</p>
<pre><code> size = #inputs * 148 bytes + #outputs * 34 bytes + 10 bytes
</code></pre>
<p>By combining multiple transactions only the 10 bytes of the transaction overhead will be saved, the inputs and outputs will require the same amount of space as in the separate transactions before.</p>
<p>The transaction size is limited by the blocksize, however <a href="https://bitcoin.stackexchange.com/a/35882/5406">transactions bigger than 100kB are non-standard</a>.</p>
<h2>Outlook Schnorr Signatures</h2>
<p>The latter will change with the planned introduction of Schnorr signatures and the subsequent possibility of signature aggregation. Schnorr signatures have the nice feature that multiple signatures can be combined into one.</p>
<p>Hence, more inputs on one transaction would reduce the blockspace requirement in the following fashion. Assuming the signature is about half of the input size (it's <a href="https://bitcoin.stackexchange.com/q/48279/5406">72 bytes of 148 for P2PKH</a>) you would get:</p>
<pre><code>inputSizeTotal(n inputs) = 1 * inputSize + (n - 1) * ¹/₂ * inputSize
</code></pre>
<p>With the number of inputs going up (i.e. <code>n → ∞</code>) you'd about halve the inputSizeTotal. ;)</p>
<hr />
<p>Update 2023: Note that Cross-input signature aggregation was not shipped with the Taproot softfork, and if/when it will get shipped, it will require a new output type since it is incompatible with the rules for P2TR. You can find more information about the approximate savings in <a href="https://bitcoin.stackexchange.com/q/106224/5406">What block space savings would we get for coinjoins (and payjoins) if we had cross input signature aggregation?</a> and more general information by perusing topics tagged with <a href="/questions/tagged/cisa" class="post-tag" title="show questions tagged &#39;cisa&#39;" aria-label="show questions tagged &#39;cisa&#39;" rel="tag" aria-labelledby="tag-cisa-tooltip-container">cisa</a>.</p>

CC BY-SA 4.0
2017-06-08T21:53:27.920Z
2023-09-12T17:38:28.167Z
2023-09-12T17:38:28.167Z
Murch
<p>As I understand it, CoinJoin is a method to aggregate multiple transactions into a single transaction, mostly for privacy purposes.</p>

<ul>
<li>How does this aggregation affect the total size of the transactions? I believe it contains the same number of inputs and outputs, but I wonder if the total size decreases due to reducing some overhead.</li>
<li>How many transactions can be aggregated? I believe there is a cap on the transaction size, which will limit the total number of inputs and outputs.</li>
<li>For the maximal number of inputs/outputs, what will be the total size with and without CoinJoin?</li>
<li>Are there additional factors which might affect the CoinJoin transaction size?</li>
</ul>

<transactions><multi-signature><transaction-verification><coinjoin>
How does CoinJoin affect the total transaction size?
UriCS
# How does CoinJoin affect the total transaction size?

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

As I understand it, CoinJoin is a method to aggregate multiple transactions into a single transaction, mostly for privacy purposes.

* How does this aggregation affect the total size of the transactions? I believe it contains the same number of inputs and outputs, but I wonder if the total size decreases due to reducing some overhead.
* How many transactions can be aggregated? I believe there is a cap on the transaction size, which will limit the total number of inputs and outputs.
* For the maximal number of inputs/outputs, what will be the total size with and without CoinJoin?
* Are there additional factors which might affect the CoinJoin transaction size?

**Tags:** transactions, multi-signature, transaction-verification, coinjoin


---

## 1 answers

### Answer by username_1 on 2017-06-08. Score: 3 | Accepted answer

## Status Quo

The CoinJoin transaction only has a minimally reduced blockspace requirement in comparison to the unaggregated transactions:

Transaction sizes (example is P2PKH) can be calculated by the following formula:

```
 size = #inputs * 148 bytes + #outputs * 34 bytes + 10 bytes

```

By combining multiple transactions only the 10 bytes of the transaction overhead will be saved, the inputs and outputs will require the same amount of space as in the separate transactions before.

The transaction size is limited by the blocksize, however [transactions bigger than 100kB are non-standard](https://bitcoin.stackexchange.com/a/35882/5406).

## Outlook Schnorr Signatures

The latter will change with the planned introduction of Schnorr signatures and the subsequent possibility of signature aggregation. Schnorr signatures have the nice feature that multiple signatures can be combined into one.

Hence, more inputs on one transaction would reduce the blockspace requirement in the following fashion. Assuming the signature is about half of the input size (it's [72 bytes of 148 for P2PKH](https://bitcoin.stackexchange.com/q/48279/5406)) you would get:

```
inputSizeTotal(n inputs) = 1 * inputSize + (n - 1) * ¹/₂ * inputSize

```

With the number of inputs going up (i.e. `n → ∞`) you'd about halve the inputSizeTotal. ;)

---

Update 2023: Note that Cross-input signature aggregation was not shipped with the Taproot softfork, and if/when it will get shipped, it will require a new output type since it is incompatible with the rules for P2TR. You can find more information about the approximate savings in [What block space savings would we get for coinjoins (and payjoins) if we had cross input signature aggregation?](https://bitcoin.stackexchange.com/q/106224/5406) and more general information by perusing topics tagged with [cisa](/questions/tagged/cisa "show questions tagged 'cisa'").


---

