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?
1 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.
-
"but did not allow for an input to be spent with an empty scriptSig ...", do you mean "a non-empty"? Jun 21, 2021 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, 2021 at 7:21
-
@KalleRosenbaum: You're right, it's misleading to use
scriptSig
here, I've replaced it withwitness
. 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, 2021 at 13:49 -