path: root/00/dbe09cf721186168aae60dcd48a814fac1a463

Return-Path: <laolu32@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 5FEA4C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 01:47:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 3EE7260EF9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 01:47:48 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, 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
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 Gm5X8A0WLafY
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 01:47:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com
 [IPv6:2a00:1450:4864:20::42b])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 9DA4360A75
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 28 Apr 2022 01:47:46 +0000 (UTC)
Received: by mail-wr1-x42b.google.com with SMTP id x18so4819216wrc.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 Apr 2022 18:47:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=h0zK9UepGwiYZ0N3GJgysIhGoPqTnKyiQDXPCp0N/go=;
 b=m5dUE0X1u4v4oaLfB9PG5cr92iWT2aggH5Z4W4+eblcpkb8DigySKeVvdAOyXZSd44
 9/detFC9GeXFEHuksSOeplevtSn73y4fOwk/Z1+dibnuqygHTSivWZ5cp8xVtVbEJDkB
 1OOjHNsUzxjz3wUp4YBH8KuVbdc8VJVmZ8HlxLZYT4k+M+xRv47cm7mfQlRv5nv9Q3hf
 inu4HSZEBVcO6Dk1llkSjDK7sN6wy4Rwn1h8wMKOXCje2jI1Kws1rWe8rdpiK6CUeoSy
 PSVpk70fa9JmijWaL4Szqoct1cBUK8ZJF0MfmwlhIxbVJyRYehK0RWHB1Ovpw8IGc/4k
 6Lqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=h0zK9UepGwiYZ0N3GJgysIhGoPqTnKyiQDXPCp0N/go=;
 b=iA+kEtvXxSb8tbRSVnc1+mQXHHNdN62/KyV/wwf3e67qokXup+5kbkC5dffjMCkF+v
 HpMzc9g8JdhfJs+oGn8TXJUojtO/1zp7VcfN7KgyorbuabXEu1TLSce8UJznjfFhwSPV
 EyQg+pQz+rcuOIQvBZIySyoceYhrpXTXbj/ezooXShJWHeWUWMG2TCEKnz8rfHFpLcKA
 6G4z+SD6kgAdFRwQ/LgRQhF/+wMfRqNkug/SugZBVgYxWhV8XMZoUsucIHazbqGnm1fT
 Wqpl5tUs8dc5Irxdz4tEYGevwpXlUd4z/v6nqTw6UMoiKNAQ9v7nfNIUogMLGopNp853
 otsQ==
X-Gm-Message-State: AOAM532h8fjWKhpu2PKGM6it3cDhVoZkh63vK7wGQbjDFUnAfJYlQHjc
 H30Wn+87Of0VsX1JkS77Jb6U/mf5NU1zdQVfmEr8TkJNgNEeEQ==
X-Google-Smtp-Source: ABdhPJxcfoErULOByY2U11reA1BQRtpi2J6IUDyxGcprAQMl8u/rcnbOGbXszRP3CRyetg0RyE0/ZcmguFdgB6vCJlk=
X-Received: by 2002:a5d:64eb:0:b0:20a:ea5d:4066 with SMTP id
 g11-20020a5d64eb000000b0020aea5d4066mr6859734wri.677.1651110464545; Wed, 27
 Apr 2022 18:47:44 -0700 (PDT)
MIME-Version: 1.0
References: <46175970-d2ab-a58e-7010-f29820849604@gmail.com>
In-Reply-To: <46175970-d2ab-a58e-7010-f29820849604@gmail.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Wed, 27 Apr 2022 18:47:33 -0700
Message-ID: <CAO3Pvs9t0H_TpqihPLeknHX30dmtzUgoA+-7uV4UOnrmacsAtQ@mail.gmail.com>
To: Jonas Nick <jonasdnick@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000b9676505ddad1c9e"
Subject: Re: [bitcoin-dev] MuSig2 BIP
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: Thu, 28 Apr 2022 01:47:48 -0000

--000000000000b9676505ddad1c9e
Content-Type: text/plain; charset="UTF-8"

Hi Jonas,

Great work on this BIP! Props to you and the other co-authors for putting
together such an excellent technical specification. I'm sure I'm not the
only developer stoked to see the much anticipated musig2 BIP published!

I made a PR earlier today to add some JSON test vectors [1], which'll make
it easier for other implementations to integrate the existing vectors and
more easily update implementations to account for any updates to the
vectors.

I've been following the BIP for a few months now, and have been updating my
implementation for `btcsuite/btcd` (mostly) in lock step. Admittedly, I miss
the earlier iterations of the BIP that were a bit simpler, but also commend
y'all's approach re specifying more performant (removal of that O(n^2)
loop), safe (the added aux input to nonce generation), and generalized
(support for both normal and x-only tweaks) algorithms.

We've also been integrating my implementation into lnd [2] as well in order
to get more familiar with my proposed API, as well as hands-on experience
crafting real transactions that use musig2 in the wild. There may, or may
not be a few musig2 spends in the main chain today created using our PR ;).
We hope to cut a release next month (lnd v0.15.0) that includes an
experimental API intended to give developers safe access to musig2 signing
and key aggregation. I've also concurrently started working on a proposal
for a new taproot native (taprooty level 1, so step 1 here [6]) LN channel
type that natively uses musig2 where applicable.

While exercising all the different signing combinations on regtest, we
realized that in order to support signing for a key that uses BIP 86
derivation (so commit to an empty root, and only the serialized internal) or
an external key that commits to a tapscript root, an implementation must
make the _pre tweaked_ combined key available to the caller. Without this
key a valid control block proof (in the script path spend case) can't be
constructed. Similarly, for the BIP 86 case, the pre-tweak combined key
needs to be used to apply the top-level taproot tweak.

As is the BIP doesn't touch on this case, which is something any
implementation will need to account for if they wish to support the two
signing modes I mentioned above. In practice, what we do now is compute the
aggregated key, stash that away, _then_ compute the tweaked key, making both
available to the caller [3]. We also add a special case for BIP 86 [5],
since in that case no real tweak needs to be specified, instead an
implementation should compute the BIP 340 tagged hash (tap tweak) of the
pre-tweaked aggregated key and use that as the main tweak.

In both of these cases, we use a special taproot specific options to make
the operations explicit [4] from the caller's PoV. This _does_ mean that an
implementation needs to know how to compute the BIP 341 taproot tweak fwiw.
So ideally any changes to the BIP in this direction can just link out to BIP
341 in place.

Finally, can you elaborate a bit on this fragment of the BIP that describes
a "short cut" when a specific signers is meant to send their nonces last:

> Second, if there is a unique signer who is supposed to send the pubnonce
> last, it is possible to modify nonce generation for this single signer to
> not require high-quality randomness

My reading here is that if there's a signer that will always send their
nonce last (possibly the responder to an LN funding attempt or a server for
a non-custodial service like Loop), then they don't actually need to
generate real randomness, and can just fully specify all the new optional
arguments? If so then this may end up really simplifying the implementation
of certain protocols since that last party doesn't (?) need to worry about
their nonces as long as all the other (?) parties are using strong
randomness?

 -- Laolu

[1]: https://github.com/jonasnick/bips/pull/10
[2]: https://github.com/lightningnetwork/lnd/pull/6361
[3]:
https://github.com/Roasbeef/btcd/blob/afbf14a3a061b961c7fe0d21dcbbc6c941a33027/btcec/schnorr/musig2/keys.go#L320-L331
[4]:
https://github.com/Roasbeef/btcd/blob/afbf14a3a061b961c7fe0d21dcbbc6c941a33027/btcec/schnorr/musig2/keys.go#L211-L248
[5]:
https://github.com/Roasbeef/btcd/blob/afbf14a3a061b961c7fe0d21dcbbc6c941a33027/btcec/schnorr/musig2/keys.go#L406-L414
[6]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-November/003336.html

On Tue, Apr 5, 2022 at 4:04 PM Jonas Nick via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Tim Ruffing, Elliott Jin, and I are working on a MuSig2 BIP that we would
> like
> to propose to the community for discussion. The BIP is compatible with
> BIP340
> public keys and signatures. It supports tweaking, which allows deriving
> BIP32
> child keys from aggregate keys and creating BIP341 Taproot outputs with
> key and
> script paths. You can find the BIP draft at:
> https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawiki
>
> The draft is in a state where it should be possible to write an
> implementation
> based on the BIP that passes the basic test vectors (as, e.g.,
> demonstrated by
> [0]). The draft BIP also contains a reference implementation in python.
> Please
> be aware that this is only a draft and that it may still be necessary to
> make
> small tweaks to the algorithms and test vectors.
>
> [0] https://github.com/btcsuite/btcd/pull/1820
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Hi Jonas, <br><br>Great work on this BIP! Props to you and=
 the other co-authors for putting<br>together such an excellent technical s=
pecification. I&#39;m sure I&#39;m not the<br>only developer stoked to see =
the much anticipated musig2 BIP published!<br><br>I made a PR earlier today=
 to add some JSON test vectors [1], which&#39;ll make<br>it easier for othe=
r implementations to integrate the existing vectors and<br>more easily upda=
te implementations to account for any updates to the<br>vectors.<br><br>I&#=
39;ve been following the BIP for a few months now, and have been updating m=
y<br>implementation for `btcsuite/btcd` (mostly) in lock step. Admittedly, =
I miss<br>the earlier iterations of the BIP that were a bit simpler, but al=
so commend<br>y&#39;all&#39;s approach re specifying more performant (remov=
al of that O(n^2)<br>loop), safe (the added aux input to nonce generation),=
 and generalized<br>(support for both normal and x-only tweaks) algorithms.=
<br><br>We&#39;ve also been integrating my implementation into lnd [2] as w=
ell in order<br>to get more familiar with my proposed API, as well as hands=
-on experience<br>crafting real transactions that use musig2 in the wild. T=
here may, or may<br>not be a few musig2 spends in the main chain today crea=
ted using our PR ;).<br>We hope to cut a release next month (lnd v0.15.0) t=
hat includes an<br>experimental API intended to give developers safe access=
 to musig2 signing<br>and key aggregation. I&#39;ve also concurrently start=
ed working on a proposal<br>for a new taproot native (taprooty level 1, so =
step 1 here [6]) LN channel<br>type that natively uses musig2 where applica=
ble.<br><br>While exercising all the different signing combinations on regt=
est, we<br>realized that in order to support signing for a key that uses BI=
P 86<br>derivation (so commit to an empty root, and only the serialized int=
ernal) or<br>an external key that commits to a tapscript root, an implement=
ation must<br>make the _pre tweaked_ combined key available to the caller. =
Without this<br>key a valid control block proof (in the script path spend c=
ase) can&#39;t be<br>constructed. Similarly, for the BIP 86 case, the pre-t=
weak combined key<br>needs to be used to apply the top-level taproot tweak.=
<br><br>As is the BIP doesn&#39;t touch on this case, which is something an=
y<br>implementation will need to account for if they wish to support the tw=
o<br>signing modes I mentioned above. In practice, what we do now is comput=
e the<br>aggregated key, stash that away, _then_ compute the tweaked key, m=
aking both<br>available to the caller [3]. We also add a special case for B=
IP 86 [5],<br>since in that case no real tweak needs to be specified, inste=
ad an<br>implementation should compute the BIP 340 tagged hash (tap tweak) =
of the<br>pre-tweaked aggregated key and use that as the main tweak.<br><br=
>In both of these cases, we use a special taproot specific options to make<=
br>the operations explicit [4] from the caller&#39;s PoV. This _does_ mean =
that an<br>implementation needs to know how to compute the BIP 341 taproot =
tweak fwiw.<br>So ideally any changes to the BIP in this direction can just=
 link out to BIP<br>341 in place.<br><br>Finally, can you elaborate a bit o=
n this fragment of the BIP that describes<br>a &quot;short cut&quot; when a=
 specific signers is meant to send their nonces last: <br><br>&gt; Second, =
if there is a unique signer who is supposed to send the pubnonce<br>&gt; la=
st, it is possible to modify nonce generation for this single signer to<br>=
&gt; not require high-quality randomness<br><br>My reading here is that if =
there&#39;s a signer that will always send their<br>nonce last (possibly th=
e responder to an LN funding attempt or a server for<br>a non-custodial ser=
vice like Loop), then they don&#39;t actually need to<br>generate real rand=
omness, and can just fully specify all the new optional<br>arguments? If so=
 then this may end up really simplifying the implementation<br>of certain p=
rotocols since that last party doesn&#39;t (?) need to worry about<br>their=
 nonces as long as all the other (?) parties are using strong<br>randomness=
?<div><br></div><div>=C2=A0-- Laolu<br><br>[1]: <a href=3D"https://github.c=
om/jonasnick/bips/pull/10">https://github.com/jonasnick/bips/pull/10</a> <b=
r>[2]: <a href=3D"https://github.com/lightningnetwork/lnd/pull/6361">https:=
//github.com/lightningnetwork/lnd/pull/6361</a><br>[3]: <a href=3D"https://=
github.com/Roasbeef/btcd/blob/afbf14a3a061b961c7fe0d21dcbbc6c941a33027/btce=
c/schnorr/musig2/keys.go#L320-L331">https://github.com/Roasbeef/btcd/blob/a=
fbf14a3a061b961c7fe0d21dcbbc6c941a33027/btcec/schnorr/musig2/keys.go#L320-L=
331</a><br>[4]: <a href=3D"https://github.com/Roasbeef/btcd/blob/afbf14a3a0=
61b961c7fe0d21dcbbc6c941a33027/btcec/schnorr/musig2/keys.go#L211-L248">http=
s://github.com/Roasbeef/btcd/blob/afbf14a3a061b961c7fe0d21dcbbc6c941a33027/=
btcec/schnorr/musig2/keys.go#L211-L248</a><br>[5]: <a href=3D"https://githu=
b.com/Roasbeef/btcd/blob/afbf14a3a061b961c7fe0d21dcbbc6c941a33027/btcec/sch=
norr/musig2/keys.go#L406-L414">https://github.com/Roasbeef/btcd/blob/afbf14=
a3a061b961c7fe0d21dcbbc6c941a33027/btcec/schnorr/musig2/keys.go#L406-L414</=
a><br>[6]: <a href=3D"https://lists.linuxfoundation.org/pipermail/lightning=
-dev/2021-November/003336.html">https://lists.linuxfoundation.org/pipermail=
/lightning-dev/2021-November/003336.html</a><br></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr 5, 2022 =
at 4:04 PM Jonas Nick via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote=
:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Tim Ruffing, E=
lliott Jin, and I are working on a MuSig2 BIP that we would like<br>
to propose to the community for discussion. The BIP is compatible with BIP3=
40<br>
public keys and signatures. It supports tweaking, which allows deriving BIP=
32<br>
child keys from aggregate keys and creating BIP341 Taproot outputs with key=
 and<br>
script paths. You can find the BIP draft at:<br>
<a href=3D"https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawi=
ki" rel=3D"noreferrer" target=3D"_blank">https://github.com/jonasnick/bips/=
blob/musig2/bip-musig2.mediawiki</a><br>
<br>
The draft is in a state where it should be possible to write an implementat=
ion<br>
based on the BIP that passes the basic test vectors (as, e.g., demonstrated=
 by<br>
[0]). The draft BIP also contains a reference implementation in python. Ple=
ase<br>
be aware that this is only a draft and that it may still be necessary to ma=
ke<br>
small tweaks to the algorithms and test vectors.<br>
<br>
[0] <a href=3D"https://github.com/btcsuite/btcd/pull/1820" rel=3D"noreferre=
r" target=3D"_blank">https://github.com/btcsuite/btcd/pull/1820</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000b9676505ddad1c9e--