Proposed BIP for MuSig2 Descriptors

Proposed BIP for MuSig2 Descriptors
2023-11-07 11:34 ` Salvatore Ingala
  
From: Andrew Chow @ 2023-10-10 22:30 UTC ( / )
  To: Bitcoin Protocol Discussion

Hi All,

I've written up a BIP draft for MuSig2 descriptors. It can be viewed at 
https://github.com/achow101/bips/blob/musig2-descriptors/bip-musig2-descriptors.mediawiki.

Andrew
2023-10-10 22:30 [bitcoin-dev] Proposed BIP for MuSig2 Descriptors Andrew Chow

  
From: Salvatore Ingala @ 2023-11-07 11:34 UTC (permalink / raw)
  To: Andrew Chow, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]

Hi Andrew,

Thank you for putting this together; these standards will be of great
help for implementations.

The only concern I have is about the utility of supporting KEY
expressions inside musig to contain ranged derivations with `/*`.

Consider a wallet described as follows:

  musig(key1/<0;1>/*, key2/<0;1>/*, ..., keyN/<0;1>/*)

With such a setup, for each input being spent, each signer is required
to derive the child xpub for each key, and then execute the KeyAgg
algorithm [1] (which includes N scalar multiplications).

Instead, a policy like:

  musig(key1, key2, ..., keyN)/<0;1>/*

is more succinct, and KeyAgg is executed only once for all the inputs.
I think the performance impact is substantial for signing devices.

Therefore, unless there are known use cases, I would suggest keeping
the standard minimal and supporting only the second form, avoiding
both the performance overhead and the additional complexity when
writing descriptor parsers.

If, on the contrary, there are legitimate use cases, a discussion
about them (and the above mentioned tradeoffs) might be worth adding
to the BIP proposal.

Best,
Salvatore


[1] - BIP-327 MuSig2: https://github.com/bitcoin/bips/blob/master/bip-0327

[-- Attachment #2: Type: text/html, Size: 1439 bytes --]

 permalink raw reply	[|nested]