1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
Return-Path: <salvatore.ingala@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 781F9C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 7 Nov 2023 11:35:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 4CD2E613E6
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 7 Nov 2023 11:35:00 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 4CD2E613E6
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20230601 header.b=VpfSnS0S
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.698
X-Spam-Level:
X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5
tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id RkVsyoJkmvrc
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 7 Nov 2023 11:34:58 +0000 (UTC)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com
[IPv6:2607:f8b0:4864:20::12c])
by smtp3.osuosl.org (Postfix) with ESMTPS id 45BB1613E4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 7 Nov 2023 11:34:58 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 45BB1613E4
Received: by mail-il1-x12c.google.com with SMTP id
e9e14a558f8ab-357ccaf982eso21186705ab.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 07 Nov 2023 03:34:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1699356897; x=1699961697;
darn=lists.linuxfoundation.org;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:from:to:cc:subject:date:message-id:reply-to;
bh=rQWdtfQJGnbZ20Ef62uCS/WqYmmnuXmu+ZKId/yyjbI=;
b=VpfSnS0S9Zh8xqR85g/4EGuSRIM8/dZENJ6Vlq0SijH7wbN49Wv9Qxd9YIXKMaMmPY
ukLfd9xt0Zb73JSmRAKpAtDqLGdlN0y+vPa/SAHV0pNfHiLcFDzekaPk8SESYxkruqo/
+QUqdqt+NV/GBuqKQb/1IA9E3OuZD5fH9fs8HuCdwzIGNMhRDUEAhllUY0k/82sCQ/nG
I0szKILUjgwhO91+74GdjZCqPi6IS2H9Y79DKE5Da6LLPTaRpOmsYqzIHIip9Y0g8HXw
PUdOoZaO1GyIKYZ4+o6SoQD/tO+StPlbuckolZxY8fy5ZZFGZJKSOPipa32cbj4JM1hj
7t2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1699356897; x=1699961697;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=rQWdtfQJGnbZ20Ef62uCS/WqYmmnuXmu+ZKId/yyjbI=;
b=Rh7goF7DkIAAwflJur13KE6s+1yEL7X5Euv2EN9dKt//WTWQZXAEzZ3/8dAN39mSvi
drP/LabPtSAhnUTXTiAPIf/k4Mh7CQJuMTqq6m6PAXJEQ16qADCOOynSgQ7fAc/7X25Z
uoKk9TmZi0drqatmNglSzgeW4SAU191A7vIIXUJ48ivMHvi+9aW6iWdCKavZxa18jgc/
Jpl0zoGk0Pa6En1cFcwr13dIU9xIFYE6vGlcQRisI8g1udOt78DenCzgR9cRkBpCuQV/
y+JGDWy1Agt3FTYVK/5omhMkN0prIdgCWm5W8evHPnWWf12/JLJnU6ljP09MJxf7w8LB
2jyw==
X-Gm-Message-State: AOJu0YwGyAWIt/KDiHVb6SlvSgqT0PQxkVEG0CIXzRj67RBiPm5WQ/oA
ZLKOxmlo+nQBKdFbMP8TaJu0daYtTBRa+t+rgCTUb7NDyPq4wg==
X-Google-Smtp-Source: AGHT+IFVbPWfwPnSOtr6rfKdcrMEHCFRDQH3iGNZNPMb9sH3Rep0lnkjY1NvOA44yec1jFdMEvAOQ1j3oTgeE3bMnLE=
X-Received: by 2002:a05:6e02:b46:b0:357:4a63:2ad2 with SMTP id
f6-20020a056e020b4600b003574a632ad2mr2732128ilu.21.1699356897292; Tue, 07 Nov
2023 03:34:57 -0800 (PST)
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"
X-Mailman-Approved-At: Tue, 07 Nov 2023 11:42:54 +0000
Subject: Re: [bitcoin-dev] Proposed BIP for MuSig2 Descriptors
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Nov 2023 11:35:00 -0000
--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/<0;1>/*, key2/<0;1>=
;/*, ..., keyN/<0;1>/*)<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)/<0;1>/*<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--
|
