01:21:21 Can someone explain to me what the purpose of these few lines in bulletproofs are? https://github.com/monero-project/monero/blob/master/src/ringct/bulletproofs.cc#L116 01:22:07 It sets a variable to false then immediately checks if it is true or not.....why? 01:36:50 It is intended to run the rest of function once and no more. 01:39:39 is that an object oriented programming thing? 01:40:50 No. There are objects in there, like the lock above. 01:42:43 huh. i get what QQ is getting at, but im no programmer. but it reads like init_done is never gonna be true, cause its always set as false in the preceding line. but this is why im not the programmer. i'll go back to whatever it is i was doing 01:43:47 It's static. It means its value stays unchanged over calls. 01:44:23 It's set at the end of the function. 01:44:31 The way I see it, if init_exponents() was called before, it will return. If not, it will run and set init_done at the end. 01:45:07 And the lock protects the init code from running in two threads at the same time, 01:47:09 i feel bad cluttering my lack of c++ understanding here... but ... 116 is setting it to false. And then 117 is checking if its true. if its false, it will run, and 141 will set it to true. if its called again, 116 will set it to false. etc. 01:48:13 < moneromooo> It's static. It means its value stays unchanged over calls. 01:48:31 Imagine it's global. 01:48:35 It kinda is. 01:52:43 Well, I certainly appreciate the attempt to explain it. I will chew on it some more and see if I can pick up what you are laying down. 01:53:32 It does not get reset when called again. 01:53:42 Its value does not change across calls. 01:56:16 Does the line on 116 set it to false if the function gets called a second time? 01:56:28 ah, so the initialization call in 116 sets it to false, but when the code wants to initialize it again, it goes "nah buddy, im alrady initialized" 01:57:49 No QQ, yes ginger. 01:58:18 cause its pointing to a location in memory. and pointing to, changing, and creating a memory address are all unique things.... hrmm.. thats cool 01:58:34 It's global really as I said. Except lexically. 01:59:44 Thanks moneromooo, I appreciate your patience. 14:58:13 I was pointed to an interesting paper about multiparty ECDSA today: https://eprint.iacr.org/2019/114 14:58:38 Might be useful in building MPCs for new proposals that require inversion 15:08:23 ^_^ 15:19:17 Will read today and think about applications 18:00:30 A variation of the method discussed in section 4.2 of that paper may be suitable for inverse computation... and presumably the rest of the linearly-dependent private key stuff could be handled as usual 18:01:09 The question becomes how many rounds, versus the security guarantees 18:01:34 Things like precommitments add computational complexity, but prevent tomfoolery 18:54:32 hey everyone 18:55:08 please excuse my absence yesterday, i was sick and i was coding offline while drinking lots of tea. i'm trying to get matching off my plate while i take a break from security proofs 18:55:30 i'm giving myself until end of day tomorrow before i switch contexts back to proof writing and checking 18:57:52 suraeNoether: I tidied up some Triptych definitions and finished the LA proof in CLSAG 18:57:56 i've made a small change to my Matching code because playerchallenger was getting really messy and was unnecessarily object oriented. i've replaced that script with tracing.py, which has the general structure of the space i'm trying to explore (for each ring size, for each churn length, etc, run a simulation and add the result to a csv file) but is still sufficiently buggy to require more massaging 18:58:12 I'd like your opinion at some point on applying the Triptych linkability and non-frameability defs to CLSAG 18:58:17 i saw you had made some changes *right after* i printed the older version of the paper, and this is one of the (minor) reasons i switched gears briefly. :P hehe 18:58:23 No problem 18:58:28 That's my fault :/ 18:58:39 nah, it's copyediting 18:58:40 I wasn't happy with how linkability was being presented 18:58:43 it's how it goes 18:58:50 I've come around on the Backes linkability definition 18:59:00 does triptych support dual output with hidden trigger heights btw? 18:59:01 It's basically a set-theory test 18:59:20 Ummmmmm not that I can immediately see 19:00:05 The linking tag structure (and its use in verification) is much different 19:00:09 how about threshold multisig? 19:00:26 using a commit-and-open approach 19:00:38 Well, if the MPC inversion approach works, in theory Triptych and RCT3 could benefit from it for multisig 19:00:43 but this is a hypothesis 19:00:58 is there a point in my logs that you've discussed that recently? 19:01:20 Earlier today I posted a relevant paper on ECDSA MPC that was brought to my attention 19:01:48 It uses a clever approach to computing the inverse of a secret field element 19:02:21 was this a *this morning* sort of realization? or is this one of many papers you've been reading about the topic lately? 19:02:30 This morning 19:02:40 I've been working up some initial math on paper today 19:02:57 ok :D thanks for the clarifications 19:03:09 The issue is that the secret key is used in different ways in each sublinear protocol 19:03:20 So we must tread lightly on how to go about MPC 19:03:32 Each requires an inverse, which was the tricky part 19:03:44 and also an affine computation, which we understand much better 19:04:25 This is the paper I'm looking at: https://eprint.iacr.org/2019/114 19:04:47 thanks 19:04:54 Namely, adapting the method presented in section 4.2, which uses the protocol in section 3 19:04:54 who brought it to your attention if you don't mind me asking 19:05:27 It was in PM, so I'll respect their privacy unless they wish otherwise 19:14:21 it was satoshi, wasn't it 19:14:27 or craig wright 19:15:01 -___- 19:26:03 craig wright has, admittedly, given me my best shower thoughts, but i'll also admit they have nothing to do with computer science or math. 20:13:25 In practice, what t-of-n values are most useful for multisig? 20:14:37 I ask because the method I'm looking at requires pairwise interactions between players 20:14:55 I think 2/3 and 3/5. Also possibly 2/2. 20:15:49 suraeNoether: did you ever get those graphs you talked about on Monday? 20:18:31 It would also require a one-time setup phase where each player has its own keypair used just for transmitting multisig data 20:43:28 Hmm, looking at that, the paper suggests the use of Paillier as this internal additively homomorphic cryptosystem 20:44:23 This means computationally-constrained devices would need support for the more generic computations (arbitrary modular reduction, etc.) that this would imply, rather than only curve operations 20:45:23 ElGamal is homomorphic, but requires a mapping of the message onto the curve group homomorphically... and in this case the messages are scalar field elements 20:46:12 So really what we want is an additively homomorphic encryption scheme that's light enough to implement and plays nicely with scalar messages 20:46:42 ^ suraeNoether 20:48:36 Sgp: the code for that is in my tracing.py file which is currently being debugged. That script generates a csv file importable into Excel. Or it will once I figure out a few problems with it 20:51:31 Sarang you mean an analytic/computable function? If such a map were a homomorphism then discrete log would not be hard. And for a simple map you can just keep a hash table with secret key public key pairs. So I'm guessing you want something computable that isn't a homomorphism and that doesn't require a hash table (because the table may as well be used as a discrete logarithm oracle)? 20:51:49 So why not Hs(X) 20:52:14 Because that's a hash table 20:52:25 So I'm not sure exactly what you are looking for 20:55:24 Nah, you're right... that would imply an advantage on discrete logs 20:55:26 Paillier it is! 20:55:43 A hash map unfortunately would not work for this