--- Log opened Thu Mar 31 00:00:42 2022
00:21 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
00:22 -!- shesek__ [~shesek@user/shesek] has joined ##miniscript
00:24 < jeremyrubin> sanket1729: it's not an issue IMO because you can store in the PSBT an encyrpted field for yourself
00:24 < jeremyrubin> you would encrypt and sign of course in a way that is binding to the instance
01:04 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
01:04 -!- shesek__ [~shesek@user/shesek] has joined ##miniscript
02:59 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
03:00 -!- shesek__ [~shesek@user/shesek] has joined ##miniscript
03:50 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
03:51 -!- shesek__ [~shesek@user/shesek] has joined ##miniscript
04:07 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
04:07 -!- shesek__ [~shesek@user/shesek] has joined ##miniscript
05:48 <@sipa> jeremyrubin: That's not sufficient. You need a way to invalidate it after signing with it.
05:49 <@sipa> So you need some form of permanent incorruptible storage within control of the signer that remembers which nonces have been produced but haven't been used for signing.
07:20 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
07:21 -!- shesek__ [~shesek@user/shesek] has joined ##miniscript
08:25 -!- mplsgrant [~mplsgrant@68-168-187-155.fttp.usinternet.com] has quit [Ping timeout: 250 seconds]
08:29 -!- salvatoshi_ [~salvatosh@genymobile-2-6-86.fib.nerim.net] has quit [Ping timeout: 260 seconds]
08:29 < jeremyrubin> You cant bind it to the specific transaction / inputs you're signing on?
08:29 <@sipa> Not without MuSig-DN.
08:31 <@sipa> You either need fresh randomness for every signing attempt, or at least an incorruptible counter (which could be used to construct a non-rewindable RNG... e.g. H(privkey || counter++)).
08:32 <@sipa> And you need to remember which randomness/counter values you've haven't constructed a (partial) signature for already.
08:38 <@sipa> With MuSig-DN you can avoid having signer state entirely, but it comes at an enormous cost (1000x CPU...).
09:50 -!- salvatoshi_ [~salvatosh@lfbn-idf3-1-717-163.w86-252.abo.wanadoo.fr] has joined ##miniscript
10:16 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
10:17 -!- shesek__ [~shesek@user/shesek] has joined ##miniscript
10:45 -!- salvatoshi_ [~salvatosh@lfbn-idf3-1-717-163.w86-252.abo.wanadoo.fr] has quit [Ping timeout: 246 seconds]
11:09 < jeremyrubin> it seems OK for a node signer (e.g. core) to generate fresh entropy for signing attempts v.s. requiring a log of all active and past sessions
11:09 <@sipa> you always need the log
11:10 <@sipa> unless you use MuSig-DN
11:10 <@sipa> it doesn't need all previous sessions though; just the current ones
11:11 <@sipa> and it could just be kept in memory - if restarted, you just lose all ongoing sessions then
11:11 < jeremyrubin> why can't I store the sessions as encrypted blobs in the PSBTs
11:11 <@sipa> because the other parties can replay those
11:11 <@sipa> if you don't have memory
11:12 < jeremyrubin> so if the sessions are replayed, and i use fresh entropy, i might double sign?
11:12 < jeremyrubin> and then lead to key leak?
11:12 <@sipa> you generate the entropy during the first round; you use it during the second
11:12 <@sipa> if you perform two second rounds with the same entropy, you leak your private key
11:12 < jeremyrubin> gotcha
11:13 < jeremyrubin> i think it might be helpful to talk about it not as entropy but a bound Nonce
11:13 < jeremyrubin> since just 'entropy' can be stretched uniquely per-round
11:13 < jeremyrubin> e.g. H(seed || H(all the info at this round))
11:13 <@sipa> that's fair; entropy isn't really the right term here either, as we only need computational unpredictability, not information-theoretical one
11:14 <@sipa> like you can generate it with a CSPRNG, which doesn't increase entropy
11:14 < jeremyrubin> yeah, so when you say entropy is selected in the first round, you mean that a nonce is comitted to to be used in the 2nd
11:15 < jeremyrubin> and we can't re-randomize at that point based on all the data we see in the 2nd round
11:15 <@sipa> right
11:15 < jeremyrubin> so we need some sort of session state.
11:15 < darosior> Arg i'm confused again. We state on the website 'The fact that non-"d" expressions cannot be dissatisfied in valid witnesses rules out the usage of the non-canonical and_v dissatisfaction'. But and_v *can* be dissatisfied in a valid witness?
11:16 < jeremyrubin> i guess we're very OT for miniscript :p 
11:16 <@sipa> Maybe "cannot" is too strong. We cannot *rely* on non-d expressions ever being dissatisfied, because such dissatisfaction may not be available to any subset of signers.
11:17 <@sipa> And as a result, no output from the miniscript satisfaction algorithm will ever dissatisfy a non-d expression.
11:17 <@sipa> But that doesn't mean that there exist no circumstances under which it may be possible to construct a dissatisfaction at all.
11:17 < darosior> Right, it's only for the static analysis. Thanks!
11:19 < jeremyrubin> sipa: one nice thing we could do would be to have the session state stored as just a hash and keep it in the PSBT still, if we're just worried about e.g. HSMs having to non volatile store some data. but as they stay, if you can non volatily store one bit, you can store them all
11:19 < jeremyrubin> (clarification: store the blob in the psbt encrypted, just keep a commitment to it in the HSM)
11:20 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
11:20 <@sipa> Yeah, I think we considered approaches like that at some point, but I think in many cases the state that needs to be stored is actually smaller than a hash :)
11:20 <@sipa> (it can just be a counter)
11:20 -!- shesek__ [~shesek@user/shesek] has joined ##miniscript
11:21 <@sipa> e.g. if you only ever allow one parallel session, you need (a) a non-decrementable counter and (b) a boolean whether the last current counter value has been signed for already
11:23 < jeremyrubin> sipa: advantages of a hash tho are that if e.g. your counter gets corrupted you *definitely* end up reusing entropy 
11:23 < jeremyrubin> whereas w/ a hash you only reuse if someone actually tries to attack by replaying a session
11:23 <@sipa> i'm not sure i like that argument :)
11:24 <@sipa> philosophically
11:24 < jeremyrubin> so maybe a CSRNG where you feed in all past sessions for uniqueness
11:24 <@sipa> if something is so broken that it is trivially expoitable, i'd rather have it fail is a very obvious way
11:25 < jeremyrubin> sipa: 'oh no, these bits of my nv memory got fried by cosmic rays and now always start at 0'
11:25 < jeremyrubin> :)
13:16 -!- salvatoshi_ [~salvatosh@lfbn-idf3-1-717-163.w86-252.abo.wanadoo.fr] has joined ##miniscript
14:00 -!- salvatoshi_ [~salvatosh@lfbn-idf3-1-717-163.w86-252.abo.wanadoo.fr] has quit [Ping timeout: 246 seconds]
14:31 -!- proofofkeags [~proofofke@96-81-42-77-static.hfc.comcastbusiness.net] has joined ##miniscript
14:31 -!- proofofkeags_ [~proofofke@96-81-42-77-static.hfc.comcastbusiness.net] has joined ##miniscript
14:32 -!- proofofkeags_ [~proofofke@96-81-42-77-static.hfc.comcastbusiness.net] has quit [Client Quit]
15:00 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
15:00 -!- shesek__ [~shesek@user/shesek] has joined ##miniscript
15:19 -!- salvatoshi_ [~salvatosh@lfbn-idf3-1-717-163.w86-252.abo.wanadoo.fr] has joined ##miniscript
15:51 -!- salvatoshi_ [~salvatosh@lfbn-idf3-1-717-163.w86-252.abo.wanadoo.fr] has quit [Ping timeout: 260 seconds]
16:32 -!- shesek_ [~shesek@user/shesek] has joined ##miniscript
16:34 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
17:05 -!- proofofkeags [~proofofke@96-81-42-77-static.hfc.comcastbusiness.net] has quit [Ping timeout: 256 seconds]
17:11 -!- shesek_ [~shesek@user/shesek] has quit [Remote host closed the connection]
17:12 -!- shesek_ [~shesek@user/shesek] has joined ##miniscript
17:39 -!- shesek__ [~shesek@user/shesek] has joined ##miniscript
17:40 -!- shesek_ [~shesek@user/shesek] has quit [Remote host closed the connection]
18:00 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
18:00 -!- shesek__ [~shesek@user/shesek] has joined ##miniscript
18:32 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
18:33 -!- shesek__ [~shesek@user/shesek] has joined ##miniscript
18:42 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
18:43 -!- shesek__ [~shesek@user/shesek] has joined ##miniscript
19:14 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
19:14 -!- shesek__ [~shesek@user/shesek] has joined ##miniscript
20:20 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
20:20 -!- shesek__ [~shesek@user/shesek] has joined ##miniscript
21:00 -!- achow101 [~achow101@user/achow101] has quit [Quit: Bye]
21:00 -!- achow101 [~achow101@user/achow101] has joined ##miniscript
21:11 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
21:11 -!- shesek__ [~shesek@user/shesek] has joined ##miniscript
21:41 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
21:42 -!- shesek__ [~shesek@user/shesek] has joined ##miniscript
22:04 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
22:04 -!- shesek__ [~shesek@user/shesek] has joined ##miniscript
22:25 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
22:26 -!- shesek__ [~shesek@user/shesek] has joined ##miniscript
22:43 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
22:43 -!- shesek__ [~shesek@user/shesek] has joined ##miniscript
23:46 -!- salvatoshi_ [~salvatosh@genymobile-2-6-86.fib.nerim.net] has joined ##miniscript
--- Log closed Fri Apr 01 00:00:44 2022