7

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?

Murch
  • 75,206
  • 34
  • 186
  • 622

1 Answers1

6

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.

Murch
  • 75,206
  • 34
  • 186
  • 622
  • "but did not allow for an input to be spent with an empty scriptSig ...", do you mean "a non-empty"? – Kalle Rosenbaum Jun 21 '21 at 07:17
  • Why can't the witness fields be used for the one-byte placeholders instead, maybe in combination with an annex? – Kalle Rosenbaum Jun 21 '21 at 07:21
  • @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 Jun 21 '21 at 13:49
  • More discussion here: https://github.com/ElementsProject/cross-input-aggregation#integration-into-the-bitcoin-protocol – Michael Folkson Jul 20 '22 at 12:06