I've also made a change to the PSBT fields BIP where the aggregate
pubkey is included as a plain pubkey rather than as xonly. I think this
change is necessary for to make discovering derived keys easier. The
derivation paths for derived keys contain the fingerprint of the parent
(i.e. the aggregate pubkey) and the fingerprint requires the evenness
bit to be serialized. So the aggregate pubkey in the PSBT fields need to
contain that evenness information in order for something looking at only
the PSBT to be able to determine whether a key is derived from an
aggregate pubkey also specified in the PSBT.
The topic of some challenges in using x-only pubkeys with FROST recently came up in a conversation that I didn't completely understand. It sounds like it may be related to this issue with MuSig2.
What are the gotcha's in x-only keys with these multisig protocols? Can you explain a little more? Any other particular things do we need to be careful about with x-only pubkeys? I had mistakenly assumed the technique was just a useful trick, not that it might cause some problems in higher level protocols.
Thanks!
-- Christopher Allen