What block space savings (specific numbers in weight units or vbytes) would we achieve for coinjoins (and payjoins) if we had cross input signature aggregation (post a speculative future soft fork that enabled it)?
This question was asked by Mario Gibney on Twitter and has been paraphrased.
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.
Murch answered this on Twitter.
The signatures for P2TR are part of the witness data already, and Schnorr sigs are only 64 bytes. Each aggregated signature but the last would need a one byte placeholder. So, the savings for a n-input tx would be
(n-1)*63WUminus whatever other overhead is added.A P2TR key-path input weighs 230 WU (57.5 vB), the header 42 WU, a P2TR output 172 WU.
Let's assume a CoinJoin (CJ) would use two inputs and have one recipient and one change output per participant, i.e. (
2*p) inputs and (2*p) outputs.If each user performed this transaction separately without CISA, the user would incur a transaction weight of:
42 + 2*230 + 2*172 = 846WUWith CISA:
42 + 2*230 - 63 + 2*172 = 783 WU2 participants per user:
(42 + 4*230 - 3*63 + 4*172) / 2 = 1461 / 2 = 730.5 WU5 participants per user cost:
(42 + 10*230 - 9*63 + 10*172) / 5 = 699 WU10 participants per user cost:
(42 + 20*230 - 19*63 + 20*172) / 10 = 688.5 WUThe savings are limited as the savings asymptotically approach 63 WU per input with increasing input count. Note that the relative savings are greatest if each participant contributes one input—when already contributing a large number of inputs themselves, coinjoining has the least relative savings as the savings are fixed to splitting the transaction header and last sig p ways.
Without CISA: Multiple inputs in a Bitcoin transaction requires multiple signatures
With CISA: Multiple inputs require only one signature
How many inputs are used in different coinjoin implementations?
Joinmarket: More than 3 (Example Tx) Wasabi: More than 10 (Example Tx) Whirlpool: 5 (Example Tx)
Let's assume 5 number of inputs for whirlpool, 50 for Joinmarket and 150 for Wasabi and all using P2TR, savings for each transaction will be (n-1)*63 WU where n is number of inputs.
Whirlpool: 252 WU
Joinmarket: 3087 WU
Wasabi: 9387 WU