On Mon, Jan 15, 2024 at 4:28 PM Ava Chow via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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