MIME-Version: 1.0
References: <71971e91-c065-478e-8489-44cc4cdacca4@achow101.com>
In-Reply-To: <71971e91-c065-478e-8489-44cc4cdacca4@achow101.com>
From: Salvatore Ingala <salvatore.ingala@gmail.com>
Date: Tue, 7 Nov 2023 11:34:46 +0000
Message-ID: <CAMhCMoHLfRDZPeVcuDnDy4mXbsyOQbgbqWPK51VBxCW=a1wD-A@mail.gmail.com>
To: Andrew Chow <lists@achow101.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000035bb5b06098e5c45"
Subject: Re: [bitcoin-dev] Proposed BIP for MuSig2 Descriptors
Precedence: list

--00000000000035bb5b06098e5c45
Content-Type: text/plain; charset="UTF-8"

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

--00000000000035bb5b06098e5c45
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Andrew,<br><br>Thank you for putting this together; the=
se standards will be of great<br>help for implementations.<br><br>The only =
concern I have is about the utility of supporting KEY<br>expressions inside=
 musig to contain ranged derivations with `/*`.<br><br>Consider a wallet de=
scribed as follows:<br><br>=C2=A0 musig(key1/&lt;0;1&gt;/*, key2/&lt;0;1&gt=
;/*, ..., keyN/&lt;0;1&gt;/*)<br><br>With such a setup, for each input bein=
g spent, each signer is required<br>to derive the child xpub for each key, =
and then execute the KeyAgg<br>algorithm [1] (which includes N scalar multi=
plications).<br><br>Instead, a policy like:<br><br>=C2=A0 musig(key1, key2,=
 ..., keyN)/&lt;0;1&gt;/*<br><br>is more succinct, and KeyAgg is executed o=
nly once for all the inputs.<br>I think the performance impact is substanti=
al for signing devices.<br><br>Therefore, unless there are known use cases,=
 I would suggest keeping<br>the standard minimal and supporting only the se=
cond form, avoiding<br>both the performance overhead and the additional com=
plexity when<br>writing descriptor parsers.<br><br>If, on the contrary, the=
re are legitimate use cases, a discussion<br>about them (and the above ment=
ioned tradeoffs) might be worth adding<br>to the BIP proposal.<br><br>Best,=
<br>Salvatore<br><br><br>[1] - BIP-327 MuSig2: <a href=3D"https://github.co=
m/bitcoin/bips/blob/master/bip-0327">https://github.com/bitcoin/bips/blob/m=
aster/bip-0327</a></div>

--00000000000035bb5b06098e5c45--