Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5FEA4C002D for ; 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 ; 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 ; 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 ; Thu, 28 Apr 2022 01:47:46 +0000 (UTC) Received: by mail-wr1-x42b.google.com with SMTP id x18so4819216wrc.0 for ; 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 Date: Wed, 27 Apr 2022 18:47:33 -0700 Message-ID: To: Jonas Nick , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Hi Jonas,

Great work on this BIP! Props to you and= the other co-authors for putting
together such an excellent technical s= pecification. 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 othe= r implementations to integrate the existing vectors and
more easily upda= te implementations to account for any updates to the
vectors.

I&#= 39;ve been following the BIP for a few months now, and have been updating m= y
implementation for `btcsuite/btcd` (mostly) in lock step. Admittedly, = I miss
the earlier iterations of the BIP that were a bit simpler, but al= so commend
y'all's approach re specifying more performant (remov= al 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 w= ell 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. T= here may, or may
not be a few musig2 spends in the main chain today crea= ted using our PR ;).
We hope to cut a release next month (lnd v0.15.0) t= hat includes an
experimental API intended to give developers safe access= to musig2 signing
and key aggregation. I've also concurrently start= ed 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 applica= ble.

While exercising all the different signing combinations on regt= est, we
realized that in order to support signing for a key that uses BI= P 86
derivation (so commit to an empty root, and only the serialized int= ernal) or
an external key that commits to a tapscript root, an implement= ation must
make the _pre tweaked_ combined key available to the caller. = Without this
key a valid control block proof (in the script path spend c= ase) can't be
constructed. Similarly, for the BIP 86 case, the pre-t= weak 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 an= y
implementation will need to account for if they wish to support the tw= o
signing modes I mentioned above. In practice, what we do now is comput= e the
aggregated key, stash that away, _then_ compute the tweaked key, m= aking both
available to the caller [3]. We also add a special case for B= IP 86 [5],
since in that case no real tweak needs to be specified, inste= ad 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<= br>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 o= n 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
> la= st, 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 th= e responder to an LN funding attempt or a server for
a non-custodial ser= vice like Loop), then they don't actually need to
generate real rand= omness, and can just fully specify all the new optional
arguments? If so= then this may end up really simplifying the implementation
of certain p= rotocols since that last party doesn't (?) need to worry about
their= nonces as long as all the other (?) parties are using strong
randomness= ?


On Tue, Apr 5, 2022 = at 4:04 PM Jonas Nick via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote= :
Tim Ruffing, E= lliott 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 BIP3= 40
public keys and signatures. It supports tweaking, which allows deriving BIP= 32
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 implementat= ion
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. Ple= ase
be aware that this is only a draft and that it may still be necessary to ma= ke
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/mail= man/listinfo/bitcoin-dev
--000000000000b9676505ddad1c9e--