* [bitcoin-dev] MuSig2 derivation, descriptor, and PSBT field BIPs
@ 2024-01-15 23:29 Ava Chow
2024-01-16 8:18 ` Christopher Allen
0 siblings, 1 reply; 3+ messages in thread
From: Ava Chow @ 2024-01-15 23:29 UTC (permalink / raw)
To: Bitcoin Protocol Discussion, bitcoindev
Hi All,
In October I sent the MuSig2 descriptor and PSBT field BIPs to the list.
Since then, I've made a few changes to the BIPs and am looking for
feedback on these.
The most significant change is the addition of third BIP which describes
how the synthetic xpubs are constructed and derived. This is split from
the descriptors BIP as I felt that the PSBT fields BIP needed to
reference this process too, and referencing the descriptors BIP for that
seemed a bit odd.
Otherwise, the descriptors BIP is unchanged, although I am open to
Salvatore's suggestion of dropping the ranged derivation within the
expression and only allow ranged derivation of the aggregate pubkey itself.
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 full text of the BIPs can be found at the following:
* Derivation:
https://github.com/achow101/bips/blob/musig2/bip-musig2-derivation.mediawiki
* Descriptors:
https://github.com/achow101/bips/blob/musig2/bip-musig2-descriptors.mediawiki
* PSBT:
https://github.com/achow101/bips/blob/musig2/bip-musig2-psbt.mediawiki
Thanks,
Ava Chow
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] MuSig2 derivation, descriptor, and PSBT field BIPs
2024-01-15 23:29 [bitcoin-dev] MuSig2 derivation, descriptor, and PSBT field BIPs Ava Chow
@ 2024-01-16 8:18 ` Christopher Allen
2024-01-23 12:12 ` Michael Folkson
0 siblings, 1 reply; 3+ messages in thread
From: Christopher Allen @ 2024-01-16 8:18 UTC (permalink / raw)
To: Ava Chow, Bitcoin Protocol Discussion; +Cc: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 1751 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] MuSig2 derivation, descriptor, and PSBT field BIPs
2024-01-16 8:18 ` Christopher Allen
@ 2024-01-23 12:12 ` Michael Folkson
0 siblings, 0 replies; 3+ messages in thread
From: Michael Folkson @ 2024-01-23 12:12 UTC (permalink / raw)
To: Christopher Allen; +Cc: Bitcoin Protocol Discussion, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 2837 bytes --]
Hi Christopher
In the absence of a response from someone who is working on MuSig2/FROST etc I did ask Tim Ruffing about the problems with using x-only pubkeys for MuSig2 etc in an (online) London Bitcoin Devs meetup [0] in 2022.
His response was:
"If you want to do more complex things, for example MuSig or more complex crypto then this bit is always a little pain in the ass. We can always get around this but whenever we do advanced stuff like tweaking keys, a lot of schemes involve tweaking keys, even Taproot itself involves tweaking, MuSig2 has key aggregation and so on. You always have to implicitly remember that bit because it is not explicitly there. You have to implicitly remember it sometimes. This makes specifications annoying. I don’t think it is a problem for security but for engineering it is certainly annoying. In hindsight it is not clear if we would make that decision again. I still think it is good because we save a byte but you can also say the increased engineering complexity is not worth it. At this point I can understand both points of view."
Hope this helps.
Thanks
Michael
[0]: https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/#a-retrospective-look-at-bip340
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
On Tuesday, 16 January 2024 at 08:18, Christopher Allen via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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
[-- Attachment #2: Type: text/html, Size: 10921 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-01-23 12:13 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-15 23:29 [bitcoin-dev] MuSig2 derivation, descriptor, and PSBT field BIPs Ava Chow
2024-01-16 8:18 ` Christopher Allen
2024-01-23 12:12 ` Michael Folkson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox