What does the BIP86 tweak guarantee in a MuSig2 Lightning channel, beyond address format?

External question — Bitcoin Stack Exchange Author: Aaron Zhang Original post: https://bitcoin.stackexchange.com/questions/130652 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. In a single-signer Taproot address, the BIP86 tweak has a clear meaning: the output commits to no script tree, only a key path. But in a two-party MuSig2 channel, I think it does something extra. Without the tweak, Alice could in principle embed a hidden script path into the funding output — one that lets her spend unilaterally. If both sides independently apply the BIP86 tweak and verify the resulting output key matches, it is effectively a mutual confirmation: "nothing is hidden in this output." So my question: in a MuSig2 channel context, is this the intended security guarantee of BIP86 — preventing the counterparty from embedding a hidden script path? Or does the channel protocol have separate mechanisms that already cover this?

External answer — Bitcoin Stack Exchange Author: Ava Chow Original post: https://bitcoin.stackexchange.com/a/130659 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. If the key used in signature verification has a tweak applied to the MuSig2 pubkey, then all participants in the MuSig2 must apply the same tweak. Otherwise, the signature itself cannot be aggregated to produce a valid signature for the final key. This means that if MuSig2 is used as an internal key in a keypath spend only case, all signers are applying the tweak computed by hashing the internal key (i.e. hashing the MuSig2 aggregate pubkey). Anyone who is applying a different tweak will not have a valid partial signature. If the MuSig2 is used as an internal key in a taproot output that also has script paths, all signers must apply the tweak computed from the merkle root in order to produce valid partial signatures. Lastly, if the MuSig2 is used as a pubkey in a script, no tweak is applied, but the partial signature commits to that particular leaf script so the partial signatures cannot be used in other spends. Since all participants in a MuSig2 must be signing the same thing and applying the same tweaks, it's not possible for Alice to embed a hidden script path. She would be applying a tweak that no one else is applying, or applying a tweak different to what everyone else is applying. The resulting aggregate signature would not be valid.