Proposed BIP for MuSig2 PSBT Fields

The author mentions that the BIP is already long and complicated enough without including adaptor signatures. However, it is possible to propose a separate adaptor signature BIP on top of MuSig2 in a modular fashion. The author also notes that there is no security proof for adaptor signatures except for a sketch that was written a few years ago. At the time, there seemed to be a higher demand for single-signer adaptor signatures.Despite the missing specification, some version of adaptor signatures has been added to the libsecp256k1-zkp MuSig2 module to allow experimentation. However, it is worth mentioning that alternative designs to the implementation in the libsecp256k1-zkp module exist. There is a current libsecp256k1-zkp PR for single-signer Schnorr adaptor signatures with the adaptor signature, where the point is extracted from an adaptor signature. This simplifies the API and reduces communication but makes batch verification of multiple adaptor signatures impossible.The email also touches upon the topic of anti-exfil and provides a link to libwally's protocol for anti-exfil with ecdsa signatures. The author suggests that adding support for anti-exfil and tweaks/adaptor signatures to musig capable signers would be beneficial. They mention that for signers who don't care about these features, the only difference is adding the tweak to the musig nonces before hashing/signing, which is straightforward. However, the author believes that specifying these features as part of the BIP would be an easy win, although it shouldn't be a blocker.In another email, a participant expresses disappointment at the absence of adaptor signature support in BIP 327. They mention that libsecp256k1-zkp has implemented it and provide links to the relevant code. The participant suggests adding additional fields to specify the adaptor and adaptor secret, along with changes to the PartialSigAgg. They note that signers who don't know the adaptor secret would need to ensure the validity of partial signatures provided by signers who do/might know the secret, but this depends on the protocol and cannot be automated at the PSBT level.Finally, the email includes a message from the author who shares a BIP draft for MuSig2 PSBT fields. They provide a link to the draft and mention some notable differences compared to a previous gist. The participant pubkeys field is keyed by only the aggregate xonly key, and the participant pubkeys themselves are compressed rather than xonly.