<p>The idea behind CISA is to only provide a single signature per Bitcoin transaction even when there are multiple inputs.</p>
<p>A key advantage of the Schnorr signature algorithm over ECDSA is its linearity. As <a href="https://bitcoin.stackexchange.com/a/106453/5406">Sachin's answer</a> described already, this permits multiple signers to construct a single signature which proves a message's authorization by several keys.</p>
<p>In Bitcoin, traditionally each input requires a signature committing to a digest of the complete transaction, the <code>sighash</code>. For non-segwit inputs, each input's <code>sighash</code> was distinct (which was also causing the quadratic hashing problem), but the <code>sighash</code> is uniform for all segwit inputs in one transaction. Since all segwit inputs in one transaction commit to the same digest, a single signature can be used to satisfy multiple inputs.</p>
<p>The current sketch for CISA proposes to replace all but one of the corresponding witnesses with a one-byte placeholder and then to provide only a single signature for all the encompassed inputs in the last input's witness. For a transaction with <code>n</code> inputs, this would reduce the transaction data by <code>n-1</code> signatures adding <code>n-1</code> one-byte placeholders in their stead.</p>

CC BY-SA 4.0
2021-11-28T08:49:13.663Z
The MuSig paper says this also requires a change to outputs: “_Doing so requires a fundamental change in validation semantics, as the validity of separate inputs is no longer independent. As a result, the outputs can no longer be modeled as predicates. Instead, we model them as functions that return a boolean plus a set of zero or more public keys. Overall validity requires all returned booleans to be True and a multi-signature of the transaction with L the union of all returned keys._”. Can you expand on this?
runeks
CC BY-SA 4.0
2021-06-16T20:56:30.957Z
2021-06-16T20:56:30.957Z
Murch
<p>Schnorr Signatures and public keys can be aggregated (added together) such that</p>
<p>S1 + S2 = S3 and P1 + P2 = P3 where (S3, P3) is a valid signature-pubkey pair IFF (S1, P1) and (S2,P2) were valid signature-pubkey pairs.</p>
<p>Because of this, if a transaction has <em>n</em> inputs, the signatures of those inputs can be aggregated, so the transaction only needs one signature and public key even with any number of inputs, whereas a regular transaction would need <em>n</em> signatures and public keys.</p>
<p>The main benefit being block space (fee) savings.</p>

CC BY-SA 4.0
2021-05-19T23:48:55.253Z
The last second half of this post covers it in greater detail: https://www.reddit.com/r/Bitcoin/comments/ibcnsv/taproot_coinjoins_and_crossinput_signature/
Sachin Meier
CC BY-SA 4.0
2021-05-20T01:41:30.727Z
Note that this is an oversimplification, and actually doing this would be completely insecure. But the principle applies indeed: keys can be combined in such a way that signing for the combination is easy.
Pieter Wuille
CC BY-SA 4.0
2021-05-19T23:47:14.163Z
2021-05-19T23:47:14.163Z
Sachin Meier
<p>I'm seeing lots of mentions of cross-input signature aggregation (CISA) lately. It appears to be something that one can do with Schnorr signatures. What is the main idea of CISA? What would a transaction look like that makes use of CISA?</p>

<cross-input-signature-aggregation>
What is cross-input signature aggregation and how would it work?
Murch
# What is cross-input signature aggregation and how would it work?

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

I'm seeing lots of mentions of cross-input signature aggregation (CISA) lately. It appears to be something that one can do with Schnorr signatures. What is the main idea of CISA? What would a transaction look like that makes use of CISA?

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


---

## 2 answers

### Answer by username_0 on 2021-06-16. Score: 5

The idea behind CISA is to only provide a single signature per Bitcoin transaction even when there are multiple inputs.

A key advantage of the Schnorr signature algorithm over ECDSA is its linearity. As [Sachin's answer](https://bitcoin.stackexchange.com/a/106453/5406) described already, this permits multiple signers to construct a single signature which proves a message's authorization by several keys.

In Bitcoin, traditionally each input requires a signature committing to a digest of the complete transaction, the `sighash`. For non-segwit inputs, each input's `sighash` was distinct (which was also causing the quadratic hashing problem), but the `sighash` is uniform for all segwit inputs in one transaction. Since all segwit inputs in one transaction commit to the same digest, a single signature can be used to satisfy multiple inputs.

The current sketch for CISA proposes to replace all but one of the corresponding witnesses with a one-byte placeholder and then to provide only a single signature for all the encompassed inputs in the last input's witness. For a transaction with `n` inputs, this would reduce the transaction data by `n-1` signatures adding `n-1` one-byte placeholders in their stead.

> **Comments:**
> **username_1**: The MuSig paper says this also requires a change to outputs: “_Doing so requires a fundamental change in validation semantics, as the validity of separate inputs is no longer independent. As a result, the outputs can no longer be modeled as predicates. Instead, we model them as functions that return a boolean plus a set of zero or more public keys. Overall validity requires all returned booleans to be True and a multi-signature of the transaction with L the union of all returned keys._”. Can you expand on this?  

---

### Answer by username_2 on 2021-05-19. Score: 1

Schnorr Signatures and public keys can be aggregated (added together) such that

S1 + S2 = S3 and P1 + P2 = P3 where (S3, P3) is a valid signature-pubkey pair IFF (S1, P1) and (S2,P2) were valid signature-pubkey pairs.

Because of this, if a transaction has *n* inputs, the signatures of those inputs can be aggregated, so the transaction only needs one signature and public key even with any number of inputs, whereas a regular transaction would need *n* signatures and public keys.

The main benefit being block space (fee) savings.

> **Comments:**
> **username_2**: The last second half of this post covers it in greater detail: https://www.reddit.com/r/Bitcoin/comments/ibcnsv/taproot_coinjoins_and_crossinput_signature/  
> **username_3**: Note that this is an oversimplification, and actually doing this would be completely insecure. But the principle applies indeed: keys can be combined in such a way that signing for the combination is easy.  

---

