--- Log opened Tue Jan 16 00:00:31 2024
00:07 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #bitcoin-wizards
00:16 -!- dongcarl [~dongcarl@066-065-169-019.res.spectrum.com] has quit [Read error: Connection reset by peer]
00:18 -!- dongcarl [~dongcarl@066-065-169-019.res.spectrum.com] has joined #bitcoin-wizards
00:38 -!- CryptoDavid [uid14990@id-14990.uxbridge.irccloud.com] has joined #bitcoin-wizards
01:14 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-wizards
01:53 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Quit: Leaving...]
06:32 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #bitcoin-wizards
07:33 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
07:44 -!- Ademan [~ademan@47.185.95.178] has joined #bitcoin-wizards
07:56 -!- brunoerg_ [~brunoerg@187.183.43.117] has quit [Remote host closed the connection]
07:57 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-wizards
08:20 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Remote host closed the connection]
08:21 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-wizards
08:38 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #bitcoin-wizards
08:43 -!- salvatoshi [~salvatosh@genymobile-2-6-86.fib.nerim.net] has quit [Ping timeout: 246 seconds]
09:08 -!- zato [~zato@user/zato] has joined #bitcoin-wizards
09:48 -!- cotsuka [~cotsuka@user/cotsuka] has quit [Remote host closed the connection]
09:50 -!- cotsuka [~cotsuka@user/cotsuka] has joined #bitcoin-wizards
10:07 -!- CryptoDavid [uid14990@id-14990.uxbridge.irccloud.com] has quit [Quit: Connection closed for inactivity]
10:47 < stevenroose> about musig, if everyone is supposed to generate secure and new private nonces, can't all the public nonces be combined to securely calculate the session id?
10:48 < stevenroose> I'm trying to do 2-party musig and the rust api emphasises the session id must be unique. So I'm thinking to just have either party provide 32-bytes of randomness and hash them together. But then I thought that kinds looks like the nonce protocol..
10:49 < stevenroose> Ah I see, in the API, the session ID already has to be known at the time of nonce generation
10:51 < stevenroose> Ah wait, it seems that the session ID does not have to be shared between the parties.. The docs have this sentence that's actually not correct english, so i'm not sure what that should be
10:51 < stevenroose> > If you cannot provide a sec_key, session_id UNIFORMLY RANDOM AND KEPT SECRET (even from other signers).
11:08 -!- cotsuka [~cotsuka@user/cotsuka] has quit [Remote host closed the connection]
11:09 -!- cotsuka [~cotsuka@user/cotsuka] has joined #bitcoin-wizards
11:27 < Ademan> stevenroose: fwiw I've implemented it here https://github.com/ademan/rust-musig-psbt and use it in a 2 party context (key path only) and it works for that. Not saying it's good but I want more review heh
11:27 < Ademan> in fact quite the opposite, what I've got is probably bad lol
11:28 < Ademan> I'm probably going to merge a non-typestate API as well, since I've found that's actually more useful to me, but I'll also leave the existing typestate API
11:31 < stevenroose> Ademan: oh cool psbt work :) but no tapscriptspends tho
11:32 < stevenroose> I'm not doing psbt atm, everything manual
11:34 < reardencode> stevenroose: Yeah, session id is local - it can be a simple counter that is never reused for the same secret key.
11:35 < reardencode> In 2p MuSig2 you can also have one of the parties generate their nonces deterministically following the DeterministicSign procedure from the BIP
11:35 < stevenroose> reardencode: does that work in untrusted setting?
11:37 < stevenroose> sanket1729: is that flow planned to be added to rust-secp256k1-zkp?
11:37 < reardencode> yes. one party (the last to generate nonces) can make those nonces deterministically in any MuSig2 scenario.
11:39 < stevenroose> cool
11:42 < stevenroose> reardencode: so IIRC the other party does need to create a random sessionid when it makes its partial signature, right? but their nonce can already be precalculated by other
11:42 < stevenroose> the others*
11:45 < reardencode> Not sure I'm following. No party can ever calculate any other party's nonce (I wish!). They must receive the nonces from all other parties (or the aggregate nonce) before they can generate a partial signature.
11:45 < Ademan> stevenroose: Well, I guess it's more an issue with knowing which outputs to sign for, you can create a context and use it with CoreContext::new_script_spend() but I have no support for discovering them, and I haven't actually exercised that code...
11:47 < Ademan> achow101: spitballing here, but maybe PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS should also be qualified with an optional tap leaf like the other keys? This would enable signers to find script path spends. On the other hand, is there any problem with a signer signing for a script path it doesn't understand?
11:51 < Ademan> OTOH there's no analogue PSBT key for this when signing for script path spends with "normal" schnorr signatures, how do such applications decide what to sign for? or maybe it's all application specific?
11:51 < achow101> Ademan: The thinking is that there will be a PSBT_IN_TAP_BIP32_DERIVATION for the aggregate key too, and since that has tap leaf hashes, we don't need to have it for PARTICIPANT_PUBKEYS
11:51 < Ademan> ah
11:51 < achow101> the BIP32_DERIVATION fields are kind of the generic "there's a pubkey here" field since a key without derivation can be specified
11:52 < Ademan> well I may as well add support for that this week. that deficiency was bothering me anyway
13:29 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
13:39 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
13:42 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #bitcoin-wizards
14:49 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
14:54 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #bitcoin-wizards
15:04 -!- Ademan [~ademan@47.185.95.178] has quit [Quit: leaving]
15:08 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
15:26 -!- Ademan [~ademan@47.185.95.178] has joined #bitcoin-wizards
15:37 < stevenroose> reardencode: you said above that the last party can calculate their nonce "deterministically" this means that others can also do the same, right?
15:39 < stevenroose> reardencode: oh it seems the DeterministicSign still uses the sk in the nonce generation, so it's not publicly deterministic
15:41 -!- vysn [~vysn@user/vysn] has quit [Remote host closed the connection]
15:48 -!- CryptoDavid [uid14990@id-14990.uxbridge.irccloud.com] has joined #bitcoin-wizards
15:55 < _aj_> stevenroose: you can create a nonce deterministically if you make it dependent on everyone else's (public) nonce, so only the last party to choose a nonce can actually do this
15:56 < _aj_> stevenroose: the private part of the nonce has to be private, or you give away your secret key when you do your signature
15:57 < stevenroose> _aj_, yeah I got that wrong, so it's deterministic only for yourself, cuz it still depends on your secret key 
15:57 < stevenroose> but that's still helpful though, thanks!
15:58 < stevenroose> Would need sanket1729's comments on how to do that. It seems that maybe if I use his new_musig_nonce_pair function and keep the `extra_random` argument None, it might do that
16:02 < stevenroose> Hmm, on second thought, I don't see how that actually makes things better. I thought it would make is so that the last signer would not have to keep any state for the signature, it could give the other party it's deterministic public nonce and then forget anything happened and when receiving the other party's partial signature, create it's secnonce again deterministically and then sign,
16:02 < stevenroose> but it still needs to maintain a unique session ID between these two events.
16:02 < stevenroose> Or am I missing something?
16:03 < jeremyrubin> https://github.com/judica-org/judica-vm/blob/master/common/attest-messages/src/nonce.rs#L46 << in case you were looking for the code snippet
16:04 < stevenroose> I don't really grasp the session ID, the API for it is also weird in sanket1729's PR. It seems to me you need to keep it between nonce gen and signing time, but in his API the nonce gen takes ownership of the SessionId and it doesn't have Clone or Copy, so it's impossible to store it until sign time without weirdly copying its internals
16:04 < _aj_> A->B: pubnonce ; B->A pubnonce, partial signature ; A: partial signature, adds B's partial signature, final signature
16:05 < stevenroose> jeremyrubin: that doesn't look like Musig?
16:05 < _aj_> in that scenario, A never generates a partial signature until she's received B's partial signature, so has much lower risk of doing two signatures with the same nonce but on different messages, which would leak her key
16:05 < _aj_> conversely, B only generates a determistic nonce, so if A feeds him different nonces he'll generate a unique nonce, so also avoids that risk
16:06 < _aj_> that's my understanding of the benefit, anyway; hard to keep it in your head though
16:07 < stevenroose> _aj_: this helps. ah yeah I see what you mean, the nonce gen and signature are at the same time, so it doens't have to keep the session id state
16:08 < stevenroose> Ok that actually helped!
16:09 < _aj_> A has to keep state -- if B sends two different nonces/partial signatures, and gets A to do two different final signatures with the same pubnonce, that's a problem
16:10 < jeremyrubin> i thought you were also looking for a code snippet of forcing a particular nonce to be signed with
18:10 -!- cotsuka [~cotsuka@user/cotsuka] has quit [Remote host closed the connection]
18:11 -!- cotsuka [~cotsuka@user/cotsuka] has joined #bitcoin-wizards
18:28 -!- Ademan [~ademan@47.185.95.178] has quit [Ping timeout: 252 seconds]
18:30 -!- Ademan [~ademan@47.185.95.178] has joined #bitcoin-wizards
19:22 -!- zato [~zato@user/zato] has quit [Quit: Om mani padme hum]
19:40 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-wizards
21:55 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #bitcoin-wizards
22:05 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
22:26 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #bitcoin-wizards
23:21 -!- tusko [~xoxoxo@user/tusko] has quit [Ping timeout: 240 seconds]
23:22 -!- tusko [~xoxoxo@user/tusko] has joined #bitcoin-wizards
23:30 -!- tusko [~xoxoxo@user/tusko] has quit [Remote host closed the connection]
23:31 -!- tusko [~xoxoxo@user/tusko] has joined #bitcoin-wizards
23:42 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
--- Log closed Wed Jan 17 00:00:32 2024