Taproot transactions aren't always cheaper onchain compared to their segwit native counterparts. How does the current MuSig spec fare compared to multisig onchain? Is one always cheaper than the other with regard to the number of participants? Is there a point where the number of participants impacts the comparative price onchain?
Add a comment
|
2 Answers
I assume that you are asking about MuSig being used to aggregate the participants' public keys and an input that spends directly using the aggregate pubkey in a keypath spend. In that case, the on-chain footprint is the same as any other P2TR keypath spend.
A P2TR keypath spend is cheaper than any (sensible¹) P2WSH multisig input, since even a 1-of-1 P2WSH input is more expensive. If the MuSig-aggregated key is used in a scriptpath spend, it depends on the depth of the leaf in the taptree, but for 2-of-2 the depths 0, 1, and 2 would still be cheaper. The scriptleaf would only be more expensive starting at a depth 3.
P2TR and P2WSH outputs both weigh 172 WU (43 vB). A P2TR keypath input weighs 230 WU (57.5 vB). A 2-of-2 P2WSH input weighs 384 WU (96 vB), from the top of my head, a 1-of-1 P2WSH input should weigh 277 WU (69.25 vB).
The only output type that has a smaller on-chain weight across the whole lifecycle is P2WPKH. A P2WPKH input weighs 272 WU (68 vB), a P2WPKH output weighs 124 WU (31 vB) for a total weight of 396 WU (99 vB). P2TR (keypath) has a total weight of 402 WU (101.5 vB).
You may also find my blog post 2-of-3 inputs using P2TR interesting, in which I detail a few alternative constructions and compare their weights.
¹ 0-of-0 and 0-of-1 P2WSH inputs would be cheaper but anyone-can-spend.
The MuSig(2) protocol produces one aggregate signature that goes onchain. Multisig requires multiple signatures to go onchain. So if you are just talking transaction size MuSig(2) will always be smaller and cheaper. There are some setup and complexity costs to MuSig(2) but they don't impact the onchain transaction fee.
answered Jan 17 at 16:53
