public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Salvatore Ingala <salvatore.ingala@gmail.com>
To: Andrew Chow <lists@achow101.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposed BIP for MuSig2 Descriptors
Date: Tue, 7 Nov 2023 11:34:46 +0000	[thread overview]
Message-ID: <CAMhCMoHLfRDZPeVcuDnDy4mXbsyOQbgbqWPK51VBxCW=a1wD-A@mail.gmail.com> (raw)
In-Reply-To: <71971e91-c065-478e-8489-44cc4cdacca4@achow101.com>

[-- 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 --]

      reply	other threads:[~2023-11-07 11:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-10 22:30 [bitcoin-dev] Proposed BIP for MuSig2 Descriptors Andrew Chow
2023-11-07 11:34 ` Salvatore Ingala [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMhCMoHLfRDZPeVcuDnDy4mXbsyOQbgbqWPK51VBxCW=a1wD-A@mail.gmail.com' \
    --to=salvatore.ingala@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=lists@achow101.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox