--- Log opened Wed Aug 04 00:00:28 2021
01:02 -!- belcher [~belcher@user/belcher] has quit [Remote host closed the connection]
01:06 -!- belcher [~belcher@user/belcher] has joined #secp256k1
01:18 -!- belcher [~belcher@user/belcher] has quit [Read error: Connection reset by peer]
01:20 -!- siv2r09 [~siv2r@103.77.37.165] has quit [Quit: The Lounge - https://thelounge.chat]
01:25 -!- belcher [~belcher@user/belcher] has joined #secp256k1
02:44 -!- jonasschnelli [~jonasschn@2a01:4f9:2a:2510::2] has joined #secp256k1
04:30 -!- roconnor [~roconnor@host-184-164-31-32.dyn.295.ca] has joined #secp256k1
06:57 -!- siv2r09 [~siv2r@103.77.37.165] has joined #secp256k1
09:19 < andytosh1> heads up that this week's optech has quite a bit about musig2 in practice https://bitcoinops.org/en/newsletters/2021/08/04/
09:48 < andytosh1> notably it says "The wallet also generates a set of nonces that are also shared with the other participants. The wallet can generate these nonces using BIP32 hardened derivation. Nonces are 32 bytes and you need two of them per signature. For infrequently used wallets, all the nonces needed for the entire wallet lifetime can be shared up front."
09:48 < andytosh1> which sounds cool but honestly terrifies me
09:49 < andytosh1> i don't think this can really be done safely in practice without risking nonce reuse
09:50 < sipa> agreed
09:51 < gmaxwell> One could make it safer by having more nonces and interpolating each parties nonce based on the message hash. If you do that, you need N reuses, where N is the number of nonces each party has.
09:52 < gmaxwell> An attacker that can get you to reuse once can probably make you repeat it, but it would at least reduce the risk of a totally fluke non-attacker induced reuse.
09:52 < sipa> gmaxwell: MuSig2 does that
09:53 < gmaxwell> sipa: it does that for the players combined, but I'm saying it can be done within each player.
09:53 < gmaxwell> oh it already does it within each player.
09:53 < gmaxwell> well you can add more to make it harder against reuse. :P
09:57 < sipa> andytosh1: i think there will be places where precomputed nonces will be used, but only in restricted ssettings that are part of some higher level protocol (i think lightning may use it, for example), but not something that should be suggested/encouraged as a general purpose technique 
10:38 < andytosh1> do you know who best to contact at optech about this? if anyone (i imagine at this early stage people won't be writing code against optech newsletters)
10:39 < sipa> harding, probably
10:41 < gmaxwell> probably calling it 'musig2' means that people will think it replaces musig.
10:41 < sipa> i think it's an improvement over it in every way?
10:45 -!- siv2r09 [~siv2r@103.77.37.165] has quit [Quit: The Lounge - https://thelounge.chat]
10:46 < sipa> ah, signing is more expensive of course
10:48 -!- siv2r09 [~siv2r@103.77.37.165] has joined #secp256k1
10:49 -!- siv2r09 [~siv2r@103.77.37.165] has quit [Client Quit]
11:05 < andytosh1> i think it is true that, if you don't have specialized knowledge, you should use musig2 instead of musig1 always
11:19 -!- siv2r09 [~siv2r@103.77.37.165] has joined #secp256k1
12:08 -!- siv2r09 [~siv2r@103.77.37.165] has quit [Quit: The Lounge - https://thelounge.chat]
12:20 -!- siv2r09 [~siv2r@103.77.37.165] has joined #secp256k1
13:25 < nickler_> agree that it's a bit misleading by optech to not mention that this would require a _lot_ of care (but not impossible if you have an uncorruptable counter for example)
13:29 < nickler_> the current MuSig2 implementation continues to not have a function to serialize the session state which is at least some deterrent against writing it to a persistent medium
13:35 < gmaxwell> It's really hard to get an uncorruptable counter. Only if you control the whole hardware/software stack could you be really confident in one.
13:37 -!- siv2r09 [~siv2r@103.77.37.165] has quit [Quit: The Lounge - https://thelounge.chat]
14:29 -!- roconnor [~roconnor@host-184-164-31-32.dyn.295.ca] has quit [Ping timeout: 250 seconds]
17:17 < ariard> yeah we'll likely need precomputed nonces on the lightning side to still update chans in 1.5 round-trip
17:18 < ariard> otherwise we might to re-architecture the state machines which are one of the buggiest part of the stack
17:28 < gmaxwell> Sure though lightning already has utterly critical anti-replay requirements.
17:55 -!- harding [quassel@newmail.dtrt.org] has joined #secp256k1
17:55 < harding> Hi.
17:56 < harding> I heard there was discussion of optech's descirption of musig this week.  Did I screw something up?
17:58 < gmaxwell> The optec description describes preshared nonces. Thats a thing you can do, indeed. But you have to be absoltely positively sure that you will never reuse a nonce, even with an attacker trying to make you reuse a nonce, or else you leak your key.
18:00 < harding> I think that's mentioned in the post.
18:00 < gmaxwell> So probably no one should use preshared nonces unless they both have a really strong need for the round trip reduction and a way of preventing the reuse.   The secp256k1-zkp implementation right now doesn't even give you an interface to serialize the state to save it to make it hard to reuse.
18:01 < gmaxwell> Probably nothing except lightning should ever use it that way, and I fully expect to see private key losses for essentially everything that does.
18:01 < gmaxwell> (lightning already has pretty gnarly replay sensitivity in the protocol)
18:01 < harding> Isn't preshared nonces the main appeal of musig2?
18:02 < gmaxwell> I think the concern andytoshi was raising was that the description sounded casually like presharing nonces is just a thing you can do,  rather than being an unrecommended dangerous special case.
18:02 < gmaxwell> No.
18:02 < gmaxwell> Having a reduced round trip count is.
18:02 < sipa> musig2 has two modes; one is 2 rounds (which is better than anything that existed before in similar settings)
18:02 < sipa> the other is 1 round with preshared nonces
18:04 < gmaxwell> It practice it's really hard to avoid replay, thats why RFC6979 exists--- lots of actual pratical systems have been exploited because they managed to reuse randomness on accident (or when triggered by an attacker). .. and musig2 1round is even worse: at least randomness you would be expected to generate on demand, while 1round requires not reusing stored data.
18:05 < harding> Not to deflect blame for my own failure to get the optech musig stuff more review, but I do kinda wish this concern was mentioned in https://medium.com/blockstream/musig2-simple-two-round-schnorr-multisignatures-bf9582e99295
18:06 < gmaxwell> pft. well blame isn't a concern in any case, this is a bleeding-edge area, bleeding is expected.
18:06 < gmaxwell> also wtf why is andytosh1 and not andytoshi? has he always been andytosh1 ???????
18:06 < harding> Anyway, I'll work up an edit for the current published newsletter and I'll probably add a Corrections section or something to next week's newsletter for all the people who already saw it.  Thanks.
18:07 < gmaxwell> harding: unrelated to the concern raised here, one thing that wasn't clear to me (maybe I was sloppy in my reading) in your writeup:  You're aware that the classic bitcoin checkmultisig is 0.5 round, right?
18:07 < gmaxwell> so even the 1 round musig2 is still, sadly, slightly more burdensome than using multiple signatures.
18:09 < harding> It's only 0.5 rounds if everyone already knows what they're going to sign in advance, right?  In normal use, it's still the case that Alice has to send Bob and Carol a PSBT before they can sign, so that feels to me like 1.0 rounds.
18:11 < gmaxwell> ah ignore me, I'm incorrect, the flow in the same as multiple signatures if the nonces are preshared, indeed.
19:12 -!- andytosh1 is now known as andytoshi
19:12 < andytoshi> gmaxwell: lol, oops, i don't know when my nick changed
19:13 < andytoshi> harding: definitely not assigning blame! your description is correct and sensible, but i think after several attempts to try it in practice i've concluded that it's impossible to do safely
19:14 < andytoshi> and also i'll re-read that medium post, it would not surprise me if we were incautiously advocating this in the past
19:14 < andytoshi> before we'd thought more practically about it
19:15 < andytoshi> oh! reading this convo i think i see where the confusion may be
19:15 < harding> https://github.com/bitcoinops/bitcoinops.github.io/pull/622
19:15 < andytoshi> in musig2 you can exchange nonces **before agreeing on the message**
19:15 < andytoshi> and this is indeed a big benefit of musig2 because it lets you pipeline multiple signatures
19:15 < andytoshi> but you still need to generate uniformly random nonces and you can't (safely) share them before the signing session has even started
19:16 < gmaxwell> Well you *can*, but at your own peril because if an attacker can restart you and cause you to reuse a prior stored nonce you are doomed.
19:16 < gmaxwell> That distinction is important though-- pipeline is a lot safer than storing.
19:17 < andytoshi> yeah. i think in the past we've been sloppy about that distinction
19:18 < andytoshi> harding: thanks for the correction - i probably won't be able to review it before tomorrow morning
19:18 < andytoshi> and btw, thanks so much for writing these things. it's really incredible what you do in this newsletter, i don't know how you keep track of so many things. sometimes you catch stuff in rust-bitcoin that i even missed
19:18 < sipa> indeed!
19:19 < harding> It's my pleasure!  Thank you all for working on things that are interesting to write about!
19:20 < sipa> right, and this distinction is sething that alao makes sense in the lightning swtting, i think; ariard says 1.5 roundtrips, which sounds like there arr 3 steps anyway - if the first step sends a nonce **before the message is known**, that sounds still reasonable as it's within the same.session
19:22 < sipa> as long as failure means the whole thing (incl. the nonce receiving) is repeated
19:25 -!- belcher_ [~belcher@user/belcher] has joined #secp256k1
19:28 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 240 seconds]
20:52 -!- siv2r09 [~siv2r@103.77.37.165] has joined #secp256k1
23:29 -!- siv2r09 [~siv2r@103.77.37.165] has quit [Quit: The Lounge - https://thelounge.chat]
--- Log closed Thu Aug 05 00:00:29 2021