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
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
