Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 781F9C0032 for ; 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 ; 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 ; 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 ; 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 ; 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 Date: Tue, 7 Nov 2023 11:34:46 +0000 Message-ID: To: Andrew Chow , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Hi Andrew,

Thank you for putting this together; the= se 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 de= scribed as follows:

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

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

Instead, a policy like:

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

is more succinct, and KeyAgg is executed o= nly once for all the inputs.
I think the performance impact is substanti= al for signing devices.

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

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

Best,=
Salvatore


[1] - BIP-327 MuSig2: https://github.com/bitcoin/bips/blob/m= aster/bip-0327
--00000000000035bb5b06098e5c45--