public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] MuSig2 BIP
@ 2022-04-05 22:57 Jonas Nick
  2022-04-28  1:47 ` Olaoluwa Osuntokun
                   ` (2 more replies)
  0 siblings, 3 replies; 15+ messages in thread
From: Jonas Nick @ 2022-04-05 22:57 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

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


^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] MuSig2 BIP
@ 2022-04-28 15:33 Brandon Black
  0 siblings, 0 replies; 15+ messages in thread
From: Brandon Black @ 2022-04-28 15:33 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]

Hi Laolu,

> 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?

I believe this was added in response to an email that a co-worker and I
sent to Jonas. The idea originated because one of our signers would have a
difficult time tracking, restoring, and securely deleting secret nonces
across a signing session, so what was important was that the signer not
have to retain state, rather than that they not have to provide their own
randomness. The result is that the signer also doesn't need to provide
randomness though.

The important property of the last signer's nonce is that any variation in
any other party's nonce, or other values that contribute to the challenge,
must uniformly randomize the last signer's nonce. The sentences following
the one you quote describe exactly how achieve this, particularly:

* Optional arguments become required
* extra_in argument must be composed of all other parties' nonces

These modifications ensure that if and only if the partial signature will
be exactly equal will the same nonce be used in a subsequent signing
session.

Best,

--Brandon

[-- Attachment #2: Type: text/html, Size: 2257 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2022-11-03 14:43 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-05 22:57 [bitcoin-dev] MuSig2 BIP Jonas Nick
2022-04-28  1:47 ` Olaoluwa Osuntokun
2022-04-28  3:53   ` Olaoluwa Osuntokun
2022-04-28 19:18     ` Jonas Nick
2022-05-22 22:26 ` AdamISZ
2022-05-23 15:56   ` Jonas Nick
2022-05-23 22:09     ` AdamISZ
2022-05-24 19:06       ` AdamISZ
2022-05-26 15:32         ` Jonas Nick
2022-05-26 17:34           ` AdamISZ
2022-06-12 23:07             ` AdamISZ
2022-10-03 20:41 ` Jonas Nick
2022-10-11 15:34   ` Jonas Nick
2022-11-03 14:43     ` Jonas Nick
2022-04-28 15:33 Brandon Black

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox