Cross-input signature aggregation (CISA) refers to an idea to produce one shared signature that covers multiple inputs in one transaction. The aggregation is made possible by the linearity of the Schnorr signature algorithm. Note that CISA seems to be mostly interesting for key path spending and this answer will not look at script path spending at all. Further, CISA is a feature in the idea/draft stage and a potential implementation could significantly differ from my current understanding.
Assuming that Taproot activates as it currently is proposed, signature aggregation (for key path spends) would likely require a new output type. Let's assume that Taproot activates as currently proposed (Note: It did.) and the new output type that supports signature aggregation is otherwise equivalent to Pay to Taproot (P2TR) in all regards.
In P2TR, signatures are part of the witness section of the transaction, and thus they are subject to the witness discount. As proposed by BIP340/BIP341, Schnorr signatures are 65 bytes (32 bytes for the
r value, 32 bytes for the
s values, 1 byte for the sighash value). BIP341 introduces a new sighash flag
SIGHASH_DEFAULT which is semantically identical to
SIGHASH_ALL and can be expressed by omitting the sigash flag. So we can generally assume that signatures are only 64 bytes. Presumably, each input covered by the aggregated signature would see its signature replaced by a one byte placeholder, except for the last input whose witness would contain the aggregated signature. Given a transaction with
n aggregated inputs, the savings would be
(n-1)×64 WU (weightunit) assuming no additional overhead is necessary for the cross-input signature.
In a P2TR transaction, a key path input weighs
230 WU (57.5 vB), the transaction header weighs
42 WU (10.5 vB), and a P2TR output is
172 WU (43 vB).
Let's assume that a coinjoin transaction is created by multiple participants where each participant contributes two inputs, one recipient output, and one change output. If each user performed this transaction separately without CISA, each user would incur a transaction weight of:
42 WU + 2×230 WU + 2×172 WU = 846 WU.
With CISA, the cost for a single participant just aggregating the signatures of their two inputs, this cost would reduce to:
42 WU + 2×230 WU - 64 WU + 2×172 WU = 782 WU.
When two participants throw in together, the cost per participant would go down to:
(42 WU + 4×230 WU - 3×64 WU + 4×172 WU) / 2 = 1458 WU / 2 = 729 WU.
For five participants the cost per user would become:
(42 WU + 10×230 WU - 9×64 WU + 10×172 WU) / 5 = 3486 WU / 5 = 697.2 WU
For ten participants, the cost per user is:
(42 WU + 20×230 WU - 19×64 WU + 20×172 WU) / 10 = 6866 WU / 10 = 686.6 WU
As you can see, the cost per user decreases with the number of inputs/participants, and thus there is an economic incentive for multiple users to create a transaction together. However, the savings are limited in that they asymptotically approach 64 WU per input as the input count increases. The greatest savings are achieved by the first two inputs getting joined up, with each additional input bringing diminishing returns. If a user already has a lot of inputs by themselves, coinjoining provides them only with marginal savings since the savings by joining with others are fixed to splitting the header and last remaining signature by the number of participants.
Put differently, the first CISA input would cost 230 WU, and every additional CISA input would cost 166 WU, therefore the average input weight converges asymptotically to 166 WU as more inputs get added.
However, from the perspective of a user pondering whether to create a transaction by themselves or to join a multi-user transaction, the cost savings are almost flat:
(n-1)×106 WU; 42 WU for the transaction header and 64 WU from the first signature, shared over
n inputs. And all users benefit from a greater set of inputs breaking the common-input ownership heuristic.