Proposed BIP for MuSig2 PSBT Fields

The context starts by mentioning that BIP 327 does not include adaptor signatures, and the decision was made due to the complexity of the BIP and the higher demand for single-signer adaptor signatures at the time. However, adaptor signatures were added to the libsecp256k1-zkp MuSig2 module for experimentation purposes.

The email also mentions alternative designs to the implementation in the libsecp256k1-zkp module, such as the current libsecp256k1-zkp PR for (single-signer) Schnorr adaptor signatures.

Another topic discussed is anti-exfil and libwally's protocol for that, specifically for ecdsa signatures. The email provides links to the description of the protocol and the relevant code in the secp256k1-zkp repository.

The email suggests that if musig capable signers were also capable of handling s2c/anti-exfil and tweaks/adaptor-sigs immediately, it would be beneficial. It explains 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. The email proposes that specifying this feature would be an easy win but should not be considered a blocker.

Additionally, the email mentions another idea for formatting the tables in the specification and provides a link for reference.

In response to the email, another participant expresses surprise at the absence of adaptor signature support in BIP 327 but notes that it has been implemented in libsecp256k1-zkp. They suggest adding additional fields to specify the adaptor and adaptor secret in the PSBT, and provide details on how they envision these fields working. They highlight the importance of specifying this as soon as possible to ensure support from all signers.

Finally, another participant shares a draft of a BIP for MuSig2 PSBT fields, which can be viewed on GitHub. They mention some differences from a previous gist and explain that participant pubkeys are compressed rather than xonly.

The email conversation covers various aspects related to BIP 327 and adaptor signatures, including the rationale behind the omission of adaptor signatures in the BIP, alternative designs, anti-exfil protocols, and suggestions for improving the specification.