<p>Cross-Input Signature Aggregation (CISA) is an idea for allowing multiple inputs to be covered by a single signature. One of the main motivations is that it would allow multiple users to combine transactions they're about to send in a single transaction and reduce the overall cost. To that end, CISA is chiefly interesting for key path spends.</p>
<p>The current sketch for CISA would be to replace all but one of the corresponding <code>witnesses</code> with a one-byte placeholder and then to provide the signature for all the encompassed inputs in the last input's <code>witness</code>.</p>
<p>Since BIP341 defines the spending rules for P2TR key path spends, but did not allow for an input to be spent with an empty <code>witness</code>, it would not be possible to introduce CISA with a softfork for P2TR key path spends after activation of Taproot as proposed.</p>
<p>Therefore, a new output type would be needed that explicitly permits the placeholders employed by CISA.</p>
<hr />
<p><sup><em>As there is no formal proposal for CISA, yet, the above observations are potentially subject to change.</em></sup></p>

CC BY-SA 4.0
2021-06-21T07:17:36.590Z
"but did not allow for an input to be spent with an empty scriptSig ...", do you mean "a non-empty"?
Kalle Rosenbaum
CC BY-SA 4.0
2021-06-21T07:21:43.560Z
Why can't the witness fields be used for the one-byte placeholders instead, maybe in combination with an annex?
Kalle Rosenbaum
CC BY-SA 4.0
2021-06-21T13:49:34.397Z
@KalleRosenbaum: You're right, it's misleading to use `scriptSig` here, I've replaced it with `witness`. The actual design is still open with the whole concept being in the idea stage, I'm not sure whether an annex would be helpful.
Murch
CC BY-SA 4.0
2022-07-20T12:06:55.697Z
More discussion here: https://github.com/ElementsProject/cross-input-aggregation#integration-into-the-bitcoin-protocol
Michael Folkson
CC BY-SA 4.0
2021-05-22T23:03:29.880Z
2021-06-21T13:39:33.613Z
2021-06-21T13:39:33.613Z
Murch
<p>If cross-input signature aggregation were to get implemented in a subsequent soft fork after Taproot's activation, would its use require a new output type?</p>

<segregated-witness><output><cross-input-signature-aggregation>
Will cross-input signature aggregation need a new output type?
Murch
# Will cross-input signature aggregation need a new output type?

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

If cross-input signature aggregation were to get implemented in a subsequent soft fork after Taproot's activation, would its use require a new output type?

**Tags:** segregated-witness, output, cross-input-signature-aggregation


---

## 1 answers

### Answer by username_0 on 2021-05-22. Score: 6 | Accepted answer

Cross-Input Signature Aggregation (CISA) is an idea for allowing multiple inputs to be covered by a single signature. One of the main motivations is that it would allow multiple users to combine transactions they're about to send in a single transaction and reduce the overall cost. To that end, CISA is chiefly interesting for key path spends.

The current sketch for CISA would be to replace all but one of the corresponding `witnesses` with a one-byte placeholder and then to provide the signature for all the encompassed inputs in the last input's `witness`.

Since BIP341 defines the spending rules for P2TR key path spends, but did not allow for an input to be spent with an empty `witness`, it would not be possible to introduce CISA with a softfork for P2TR key path spends after activation of Taproot as proposed.

Therefore, a new output type would be needed that explicitly permits the placeholders employed by CISA.

---

*As there is no formal proposal for CISA, yet, the above observations are potentially subject to change.*

> **Comments:**
> **username_1**: "but did not allow for an input to be spent with an empty scriptSig ...", do you mean "a non-empty"?  
> **username_1**: Why can't the witness fields be used for the one-byte placeholders instead, maybe in combination with an annex?  
> **username_0**: @username_1: You're right, it's misleading to use `scriptSig` here, I've replaced it with `witness`. The actual design is still open with the whole concept being in the idea stage, I'm not sure whether an annex would be helpful.  
> **username_2**: More discussion here: https://github.com/ElementsProject/cross-input-aggregation#integration-into-the-bitcoin-protocol  

---

