4

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?

4

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.

3
  • "but did not allow for an input to be spent with an empty scriptSig ...", do you mean "a non-empty"? Jun 21 at 7:17
  • Why can't the witness fields be used for the one-byte placeholders instead, maybe in combination with an annex? Jun 21 at 7: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 at 13:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.