--- Log opened Thu Aug 05 00:00:29 2021
01:05 -!- belcher_ is now known as belcher
01:54 < nickler_> "but I do kinda wish this concern was mentioned in [...]" Not to deflect blame :D but there are two paragraphs on that issue in the post (see "demonstrate the risk with MuSig2")
01:54 < nickler_> Thanks for updating the description harding. This shows that you can not reiterate this pitfall enough.
01:56 < nickler_> Fwiw, the current MuSig2 (and the old MuSig1 implementation) supports both modes: msg known before and msg known after nonce generation time. The former is recommended and adds the message into the nonce generation process for defense in depth.
02:23 -!- meshcollider [meshcollid@user/meshcollider] has quit [Ping timeout: 272 seconds]
02:45 -!- meshcollider [meshcollid@meshcollider.jujube.ircnow.org] has joined #secp256k1
02:53 -!- siv2r09 [~siv2r@103.77.37.165] has joined #secp256k1
03:28 -!- siv2r09 [~siv2r@103.77.37.165] has quit [Ping timeout: 258 seconds]
03:59 -!- siv2r09 [~siv2r@103.77.37.165] has joined #secp256k1
04:08 -!- siv2r09 [~siv2r@103.77.37.165] has quit [Quit: The Lounge - https://thelounge.chat]
04:09 -!- siv2r09 [~siv2r@103.77.37.165] has joined #secp256k1
05:52 < harding> nickler_: I think what confused me about that part of yours and real_or_random's post was "if open signing sessions need to be stored on a persistent medium, the statelessness property of MuSig-DN is beneficial."  and "1. Start a MuSig2 signing session."  What I think of as a signing session starts when a message is created; (e.g. Alice creates a PSBT).  But it sounds to me like what ya'll are calling a signing session begins when the nonces are 
05:52 < harding> shared.
05:57 < andytoshi> oh, cool, that's a really useful distinction to make
05:58 < andytoshi> in our model a "signing session" does start with nonces being shared, and if something goes wrong you may need to restart the signing session (regenerate/share nonces) even if the message doesn't change
05:58 < andytoshi> and in musig2, you can actually choose the message after nonces have been shared (so after the "signing session" has started)
05:58 < andytoshi> but i see how to a user, "signing session" seems to be when you start to sign something
06:46 < nickler_> harding: Ok, I see. I like the session term because that's how multisignatures are defined (in the papers). Parallel sessions = nonces may be shared for multiple session before signing a message.
06:46 < nickler_> But Nicolas Dorier also suggested dropping the term in the MuSig2 PR.
07:06 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
07:13 -!- siv2r09 [~siv2r@103.77.37.165] has quit [Quit: The Lounge - https://thelounge.chat]
07:14 -!- siv2r09 [~siv2r@103.77.37.165] has joined #secp256k1
08:49 -!- roconnor [~roconnor@host-45-78-236-232.dyn.295.ca] has joined #secp256k1
08:50 < roconnor> sipa: Does your utACK on https://github.com/bitcoin-core/secp256k1/pull/956 mean that you think we should be going forward with it despite your window measurements?
08:53 < sipa> yes
08:54 < sipa> i don't think we can justify including larger windows as pre-generated in-repo files
08:54 < sipa> and if someone really needs bigger, they can generate them themselves
08:54 < roconnor> Right, but we could just drop the PR and increase the window size.
08:57 < sipa> I like the direction it takes where all the big tables become compile-time generated.
10:02 -!- siv2r09 [~siv2r@103.77.37.165] has quit [Quit: The Lounge - https://thelounge.chat]
13:01 -!- jonatack [~jonatack@user/jonatack] has quit [Quit: Client closed]
13:16 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
13:31 < gmaxwell> besides larger windows are going to be less of a win in the conext of a real program that is doing something other than verifying signatures in a tight loop-- though thats hard to measure
13:33 -!- belcher [~belcher@user/belcher] has quit [Read error: Connection reset by peer]
13:45 -!- belcher [~belcher@user/belcher] has joined #secp256k1
13:59 -!- jonatack [~jonatack@user/jonatack] has quit [Quit: Client closed]
14:59 < andytoshi> harding: your update at https://github.com/bitcoinops/bitcoinops.github.io/pull/622/ looks great!
15:00 < andytoshi> i might try to do a personal blog post or something about pipelining signatures (and why/how this is new in musig2), also pipelining vs pre-sharing nonces and what a "signing session" means, this all seems like good terminology to try and clear up
15:33 < harding> andytoshi: that'd be awesome. I had the same thought for next week's newsletter, although I'll probably focusing a bit more on "use this for that application; use this other thing for that other application".
17:27 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
20:14 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 265 seconds]
20:18 -!- luke-jr [~luke-jr@user/luke-jr] has joined #secp256k1
20:38 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 258 seconds]
20:40 -!- luke-jr [~luke-jr@user/luke-jr] has joined #secp256k1
20:42 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Read error: Connection reset by peer]
20:47 -!- luke-jr [~luke-jr@user/luke-jr] has joined #secp256k1
--- Log closed Fri Aug 06 00:00:30 2021