public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] Proposed BIP for MuSig2 Descriptors
@ 2023-10-10 22:30 Andrew Chow
  2023-11-07 11:34 ` Salvatore Ingala
  0 siblings, 1 reply; 2+ messages in thread
From: Andrew Chow @ 2023-10-10 22:30 UTC (permalink / raw)
  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



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [bitcoin-dev] Proposed BIP for MuSig2 Descriptors
  2023-10-10 22:30 [bitcoin-dev] Proposed BIP for MuSig2 Descriptors Andrew Chow
@ 2023-11-07 11:34 ` Salvatore Ingala
  0 siblings, 0 replies; 2+ messages in thread
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	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2023-11-07 11:35 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-10 22:30 [bitcoin-dev] Proposed BIP for MuSig2 Descriptors Andrew Chow
2023-11-07 11:34 ` Salvatore Ingala

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox