<p>Murch answered this on <a href="https://twitter.com/murchandamus/status/1391358558441193480?s=20" rel="nofollow noreferrer">Twitter</a>.</p>
<blockquote>
<p>The signatures for P2TR are part of the witness data already, and Schnorr sigs are only 64 bytes. Each aggregated signature but the last would need a one byte placeholder. So, the savings for a n-input tx would be <code>(n-1)*63WU</code> minus whatever other overhead is added.</p>
<p>A P2TR key-path input weighs 230 WU (57.5 vB), the header 42 WU, a P2TR output 172 WU.</p>
<p>Let's assume a CoinJoin (CJ) would use two inputs and have one recipient and one change output per participant, i.e. (<code>2*p</code>) inputs and (<code>2*p</code>) outputs.</p>
<p>If each user performed this transaction separately without CISA, the user would incur a transaction weight of: <code>42 + 2*230 + 2*172 = 846WU</code></p>
<p>With CISA: <code>42 + 2*230 - 63 + 2*172 = 783 WU</code></p>
<p>2 participants per user:
<code>(42 + 4*230 - 3*63 + 4*172) / 2 = 1461 / 2 = 730.5 WU</code></p>
<p>5 participants per user cost:
<code>(42 + 10*230 - 9*63 + 10*172) / 5 = 699 WU</code></p>
<p>10 participants per user cost:
<code>(42 + 20*230 - 19*63 + 20*172) / 10 = 688.5 WU</code></p>
<p>The savings are limited as the savings asymptotically approach 63 WU per input with increasing input count. Note that the relative savings are greatest if each participant contributes one input—when already contributing a large number of inputs themselves, coinjoining has the least relative savings as the savings are fixed to splitting the transaction header and last sig p ways.</p>
</blockquote>

CC BY-SA 4.0
2021-05-12T11:21:23.770Z
2021-05-12T11:21:23.770Z
Michael Folkson
<p><em>Cross-input signature aggregation (CISA)</em> refers to an idea to produce one shared signature that covers multiple inputs in one transaction. The aggregation is made possible by the linearity of the Schnorr signature algorithm. Note that CISA seems to be mostly interesting for key path spending and this answer will not look at script path spending at all. Further, CISA is a feature in the idea/draft stage and a potential implementation could significantly differ from my current understanding.</p>
<p>Assuming that Taproot activates as it currently is proposed, signature aggregation (for key path spends) would likely <a href="https://bitcoin.stackexchange.com/q/106240/5406">require a new output type</a>. Let's assume that Taproot activates as currently proposed (Note: It did.) and the new output type that supports signature aggregation is otherwise equivalent to Pay to Taproot (P2TR) in all regards.</p>
<p>In P2TR, signatures are part of the witness section of the transaction, and thus they are subject to the witness discount. As proposed by BIP340/BIP341, Schnorr signatures are 65 bytes (32 bytes for the <code>r</code> value, 32 bytes for the <code>s</code> values, 1 byte for the sighash value). BIP341 introduces a new sighash flag <code>SIGHASH_DEFAULT</code> which is semantically identical to <code>SIGHASH_ALL</code> and can be expressed by omitting the sigash flag. So we can generally assume that signatures are only 64 bytes. Presumably, each input covered by the aggregated signature would see its signature replaced by a one byte placeholder, except for the last input whose witness would contain the aggregated signature. Given a transaction with <code>n</code> aggregated inputs, the savings would be <code>(n-1)×64 WU (weightunit)</code> assuming no additional overhead is necessary for the cross-input signature.</p>
<p>In a P2TR transaction, a key path input weighs <code>230 WU (57.5 vB)</code>, the transaction header weighs <code>42 WU (10.5 vB)</code>, and a P2TR output is <code>172 WU (43 vB)</code>.</p>
<p>Let's assume that a coinjoin transaction is created by multiple participants where each participant contributes two inputs, one recipient output, and one change output. If each user performed this transaction separately without CISA, each user would incur a transaction weight of:<br />
<code>42 WU + 2×230 WU + 2×172 WU = 846 WU</code>.</p>
<p>With CISA, the cost for a single participant just aggregating the signatures of their two inputs, this cost would reduce to:<br />
<code>42 WU + 2×230 WU - 64 WU + 2×172 WU = 782 WU</code>.</p>
<p>When two participants throw in together, the cost per participant would go down to:<br />
<code>(42 WU + 4×230 WU - 3×64 WU + 4×172 WU) / 2 = 1458 WU / 2 = 729 WU</code>.</p>
<p>For five participants the cost per user would become:<br />
<code>(42 WU + 10×230 WU - 9×64 WU + 10×172 WU) / 5 = 3486 WU / 5 = 697.2 WU</code></p>
<p>For ten participants, the cost per user is:<br />
<code>(42 WU + 20×230 WU - 19×64 WU + 20×172 WU) / 10 = 6866 WU / 10 = 686.6 WU</code></p>
<p>As you can see, the cost per user decreases with the number of inputs/participants, and thus there is an economic incentive for multiple users to create a transaction together. However, the savings are limited in that they asymptotically approach 64 WU per input as the input count increases. The greatest savings are achieved by the first two inputs getting joined up, with each additional input bringing diminishing returns. If a user already has a lot of inputs by themselves, coinjoining provides them only with marginal savings since the savings by joining with others are fixed to splitting the header and last remaining signature by the number of participants.</p>
<p>Put differently, the first CISA input would cost 230 WU, and every additional CISA input would cost 166 WU, therefore the average input weight converges asymptotically to 166 WU as more inputs get added.</p>
<p>However, from the perspective of a user pondering whether to create a transaction by themselves or to join a multi-user transaction, the cost savings are almost flat: <code>(n-1)×106 WU</code>; 42 WU for the transaction header and 64 WU from the first signature, shared over <code>n</code> inputs. And all users benefit from a greater set of inputs breaking the <a href="https://en.bitcoin.it/wiki/Common-input-ownership_heuristic" rel="nofollow noreferrer">common-input ownership heuristic</a>.</p>

CC BY-SA 4.0
2021-05-26T20:08:48.167Z
2022-04-13T16:07:34.303Z
2022-04-13T16:07:34.303Z
Murch
<p>What block space savings (specific numbers in weight units or vbytes) would we achieve for coinjoins (and payjoins) if we had cross input signature aggregation (post a speculative future soft fork that enabled it)?</p>
<p>This question was asked by Mario Gibney on <a href="https://twitter.com/Mario_Gibney/status/1391330776080261121?s=20" rel="noreferrer">Twitter</a> and has been paraphrased.</p>

<coinjoin><cross-input-signature-aggregation>
What block space savings would we get for coinjoins (and payjoins) if we had cross input signature aggregation?
Michael Folkson
# What block space savings would we get for coinjoins (and payjoins) if we had cross input signature aggregation?

(Asked by: username_0 on 2021-05-11)

What block space savings (specific numbers in weight units or vbytes) would we achieve for coinjoins (and payjoins) if we had cross input signature aggregation (post a speculative future soft fork that enabled it)?

This question was asked by Mario Gibney on [Twitter](https://twitter.com/Mario_Gibney/status/1391330776080261121?s=20) and has been paraphrased.

**Tags:** coinjoin, cross-input-signature-aggregation


---

## 2 answers

### Answer by username_1 on 2021-05-26. Score: 8 | Accepted answer

*Cross-input signature aggregation (CISA)* refers to an idea to produce one shared signature that covers multiple inputs in one transaction. The aggregation is made possible by the linearity of the Schnorr signature algorithm. Note that CISA seems to be mostly interesting for key path spending and this answer will not look at script path spending at all. Further, CISA is a feature in the idea/draft stage and a potential implementation could significantly differ from my current understanding.

Assuming that Taproot activates as it currently is proposed, signature aggregation (for key path spends) would likely [require a new output type](https://bitcoin.stackexchange.com/q/106240/5406). Let's assume that Taproot activates as currently proposed (Note: It did.) and the new output type that supports signature aggregation is otherwise equivalent to Pay to Taproot (P2TR) in all regards.

In P2TR, signatures are part of the witness section of the transaction, and thus they are subject to the witness discount. As proposed by BIP340/BIP341, Schnorr signatures are 65 bytes (32 bytes for the `r` value, 32 bytes for the `s` values, 1 byte for the sighash value). BIP341 introduces a new sighash flag `SIGHASH_DEFAULT` which is semantically identical to `SIGHASH_ALL` and can be expressed by omitting the sigash flag. So we can generally assume that signatures are only 64 bytes. Presumably, each input covered by the aggregated signature would see its signature replaced by a one byte placeholder, except for the last input whose witness would contain the aggregated signature. Given a transaction with `n` aggregated inputs, the savings would be `(n-1)×64 WU (weightunit)` assuming no additional overhead is necessary for the cross-input signature.

In a P2TR transaction, a key path input weighs `230 WU (57.5 vB)`, the transaction header weighs `42 WU (10.5 vB)`, and a P2TR output is `172 WU (43 vB)`.

Let's assume that a coinjoin transaction is created by multiple participants where each participant contributes two inputs, one recipient output, and one change output. If each user performed this transaction separately without CISA, each user would incur a transaction weight of:  
`42 WU + 2×230 WU + 2×172 WU = 846 WU`.

With CISA, the cost for a single participant just aggregating the signatures of their two inputs, this cost would reduce to:  
`42 WU + 2×230 WU - 64 WU + 2×172 WU = 782 WU`.

When two participants throw in together, the cost per participant would go down to:  
`(42 WU + 4×230 WU - 3×64 WU + 4×172 WU) / 2 = 1458 WU / 2 = 729 WU`.

For five participants the cost per user would become:  
`(42 WU + 10×230 WU - 9×64 WU + 10×172 WU) / 5 = 3486 WU / 5 = 697.2 WU`

For ten participants, the cost per user is:  
`(42 WU + 20×230 WU - 19×64 WU + 20×172 WU) / 10 = 6866 WU / 10 = 686.6 WU`

As you can see, the cost per user decreases with the number of inputs/participants, and thus there is an economic incentive for multiple users to create a transaction together. However, the savings are limited in that they asymptotically approach 64 WU per input as the input count increases. The greatest savings are achieved by the first two inputs getting joined up, with each additional input bringing diminishing returns. If a user already has a lot of inputs by themselves, coinjoining provides them only with marginal savings since the savings by joining with others are fixed to splitting the header and last remaining signature by the number of participants.

Put differently, the first CISA input would cost 230 WU, and every additional CISA input would cost 166 WU, therefore the average input weight converges asymptotically to 166 WU as more inputs get added.

However, from the perspective of a user pondering whether to create a transaction by themselves or to join a multi-user transaction, the cost savings are almost flat: `(n-1)×106 WU`; 42 WU for the transaction header and 64 WU from the first signature, shared over `n` inputs. And all users benefit from a greater set of inputs breaking the [common-input ownership heuristic](https://en.bitcoin.it/wiki/Common-input-ownership_heuristic).


---

### Answer by username_0 on 2021-05-12. Score: 2

username_1 answered this on [Twitter](https://twitter.com/murchandamus/status/1391358558441193480?s=20).

> The signatures for P2TR are part of the witness data already, and Schnorr sigs are only 64 bytes. Each aggregated signature but the last would need a one byte placeholder. So, the savings for a n-input tx would be `(n-1)*63WU` minus whatever other overhead is added.
>
> A P2TR key-path input weighs 230 WU (57.5 vB), the header 42 WU, a P2TR output 172 WU.
>
> Let's assume a CoinJoin (CJ) would use two inputs and have one recipient and one change output per participant, i.e. (`2*p`) inputs and (`2*p`) outputs.
>
> If each user performed this transaction separately without CISA, the user would incur a transaction weight of: `42 + 2*230 + 2*172 = 846WU`
>
> With CISA: `42 + 2*230 - 63 + 2*172 = 783 WU`
>
> 2 participants per user:
> `(42 + 4*230 - 3*63 + 4*172) / 2 = 1461 / 2 = 730.5 WU`
>
> 5 participants per user cost:
> `(42 + 10*230 - 9*63 + 10*172) / 5 = 699 WU`
>
> 10 participants per user cost:
> `(42 + 20*230 - 19*63 + 20*172) / 10 = 688.5 WU`
>
> The savings are limited as the savings asymptotically approach 63 WU per input with increasing input count. Note that the relative savings are greatest if each participant contributes one input—when already contributing a large number of inputs themselves, coinjoining has the least relative savings as the savings are fixed to splitting the transaction header and last sig p ways.


---

