BIPs for MuSig2 derivation, descriptors, and PSBT fields

[achow101]

This PR contains 3 proposed BIPs, the main contents of which were sent to the bitcoin-dev mailing list in October. There have been a few changes, notably the addition of a new BIP for the derivation methodology which was split from the descriptors BIP.

I've also changed the PSBT BIP to use 33 byte plain aggregate pubkeys rather than xonly.

[benma]

I've also changed the PSBT BIP to use 33 byte plain aggregate pubkeys rather than xonly.

It would be helpful to document the reasoning in the commit msg or here in the PR to have a record of design decisions.

[achow101]

I've also changed the PSBT BIP to use 33 byte plain aggregate pubkeys rather than xonly.

It would be helpful to document the reasoning in the commit msg or here in the PR to have a record of design decisions.

I've added a rationale section which addresses this.

[Sjors]

An additional benefit is that such wallets can be watched by a musig2-unaware wallet, or a tapleaf co-signer who does not need to know about the individual keys, by casting the tr(musig()) descriptor to tr(). Similarly it's compatible with the privacy-preserving rawtr descriptor (needs a BIP).

[achow101]

I've made a minor change with the descriptors regarding sorting. Keys in a musig() can be specified in any order, but will be sorted prior to aggregation, similar to sortedmulti(). However for PSBTs, keys must be supplied in the expected order for aggregation (this is unchanged), which means sorting them if they weren't already.

[bigspider]

I've made a minor change with the descriptors regarding sorting. Keys in a musig() can be specified in any order, but will be sorted prior to aggregation, similar to sortedmulti(). However for PSBTs, keys must be supplied in the expected order for aggregation (this is unchanged), which means sorting them if they weren't already.

What is the rationale for this change? It seems to me that this complicates parsing/processing the descriptor unnecessarily. The only practical advantage I know of sortedmulti versus multi is that with multi an external observer can possibly fingerprint who signed different UTXOs even without knowing the descriptor; but that's not the case anyway for musig.

[achow101]

What is the rationale for this change?

I had a discussion involving @jonasnick and @sipa about this. Since BIP 327 suggests to do sorting, we decided it made sense to do in descriptors as well.

[bigspider]

I had a discussion involving @jonasnick and @sipa about this. Since BIP 327 suggests to do sorting, we decided it made sense to do in descriptors as well.

BIP 327 discusses the possibility of sorting and describes a canonical sorting, but I didn't read it as 'suggesting' one way or another.

In general, I'd prefer maximum simplicity and less chances of malleability in descriptors, and this imho goes against both (albeit slightly, not a huge deal).

Note that this removes functionality, as one of $n! - 1$ of the $n!$ possible combinations become inexpressible with descriptors.

[bigspider]

The functionality that I would suggest to consider for removal is derivation before aggregation: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/022132.html

Unless there are use cases for it that I'm not aware of?

[rot13maxi]

have you thought about putting [] or something around the final hash here to make it clear that it will be omitted if the aggregate key is either the taproot output key or the taproot internal key

[rot13maxi]

the specification for the descriptor says that keys must be sorted with KeySort. If unsorted keys are allowed here, then its possible to have a psbt for a musig aggregate key that's not expressible in a descriptor. Maybe that's ok, just flagging it.

[achow101]

Yes, that is allowed. PSBTs is intentionally less restrictive than descriptors.

[Ademan]

What's wrong with taking the ordering from the descriptor directly? That seems simpler and more flexible (Not that I can imagine a specific reason why a user would want a particular order).

[rot13maxi]

Yes, that is allowed. PSBTs is intentionally less restrictive than descriptors.

makes sense, you want PSBTs to be a super-set of what you can express in a descriptor

[achow101]

What's wrong with taking the ordering from the descriptor directly? That seems simpler and more flexible (Not that I can imagine a specific reason why a user would want a particular order).

There's no descriptor in psbts.

[Ademan]

Right I was commenting on KeySort-ing the participant keys in the descriptor. Seemed on-topic for this thread but I'll put the comment where it belongs.

[Ademan]

Why KeySort when we already have a explicit ordering from the descriptor? It seems like an unnecessary complication.

[achow101]

As I mentioned in #1540 (comment), there was a discussion about this and that was the conclusion. But I'm also having a hard time remembering the exact reason, maybe @jonasnick and/or @sipa can help me out here.

[murchandamus]

The formatting seems to be in order on these documents. What is the status of the discussion on these proposals?

[murchandamus]

In #1434 it was mentioned that this proposal may conflict with the way PSBT is used by an existing implementation. Has there been any communication to reconcile that?

[bigspider]

It might be worth mentioning explicitly that musig() nesting is forbidden (while musig() inside Script-based multisignatures/thresholds is fine).

[achow101]

I thought it was sufficiently implied by the above paragraph which states "The musig(KEY, KEY, ..., KEY) expression can only be used inside of a tr() expression as a key expression."

[bigspider]

Since you can put musig() inside any fragment inside tr(), I think it's very easy to miss the fact that musig() itself is not a fragment, despite using a visually identical syntax. Especially since nesting musig() inside musig() is a natural thing that some people will surely want to do.