02:21:24 "> <@coinstudent2048:matrix.org..." <- Monero doesn't use this curve. Please use `dumb25519.py`. 02:26:06 Here's my dumb25519: https://github.com/coinstudent2048/verklebp/blob/main/dumb25519.py. I am interested with your `hash_to_ec` though. Is the hash consistent with Monero wallet's? 03:29:53 Another note: dumb25519 has `hash_to_point`, but this is ad hoc and will be different from `hash_to_ec`. The reason is that the code is used to implement cryptography math, and not necessary reflecting Monero code. 04:06:06 023. 06:51:46 hello :) 06:54:30 i am a little bit how should i say... 06:55:53 assume i always spend 1000 piconeros. And i only ever do one input -> one output transactions. 06:57:11 and i always want to know the blinding factor when my "wannahave" amount is 100xmr... 06:58:27 being a "outpk" from a previous tx now the only input i have, then : 06:58:55 C1 = aG + cH 06:59:21 being C1 = outpk. 06:59:54 C2 = bG + dH 07:00:24 being C2 my new commitment i want to find... 07:00:48 if 07:00:59 C1 = C2 07:01:29 aG + cH = bG + dH 07:02:03 aG + cH - dH = bG 07:03:12 aG + (1000 picos)H - (100xmr)H = bG 07:03:34 and i know a ... 07:03:40 then : 07:04:35 b = log (G) [ aG + (1000 picos)H - (100xmr)H ] 07:06:47 what i'm trying to express is that for me it does not sit well, that not only is there a public secret called gamma... 07:08:59 every commitment in every tx, has a discrete log problem that only depends on the blinding factors being choosen randomly... 07:10:08 ? 07:30:33 What is gamma? Also, yes, given `C` and `y` in `C=xG+yH`, the only thing that prevents you from recovering `x` is the discrete log problem except for negligible probability (i.e. extremely extremely lucky). If this reliance to discrete logarithm is what concerns you, well it works so far, **until** that day secret-breakers solve the problem efficiently (by quantum computers, or some future math). 15:34:08 >@Elija "I came across https://github.com/dalek-cryptography/bulletproofs#comparative-performance when looking at some projects. Is this bulletproofs a possible way to optimize Monero, or does Monero's implementation prevent such types of optimizations, ignoring the porting constraints. " 15:34:08 >UkoeHB "It seems odd to me that daleks' bp would be 7x faster. Maybe they have a faster multiexp algorithm... (seems unlikely) is there someone out there up to investigating the reason?" 15:40:02 I see 4.63x, and about 4x once you disregard the asm specific one. I *think* I heard before that dalek could not be used for monero due to using a slightly different curve. 15:41:10 If a whole lot of stuff gets changed anyway with seraphis, that might be a more plausible option (I saw without knowing what I'm talking about). 15:42:09 I can't recall how much of the verificatoin time BP takes though. I htink it's fairly significant. 15:43:18 Oh, I see the 7x in the comment, it's not in the table. 15:43:58 But just on a handpicked machine, presumanly handpicked to be the one with the highest speedup. Not helpful. 15:44:23 proofing is 7.3x and verification is 4.63x in the table 15:44:34 s/proofing/proving/ 15:44:57 Intel Skylake-X i7-7800X 15:45:39 Maybe a curve switch would also speed up other parts of tx verification (ie, rings). 15:58:23 oh whoops the proof is 7x, verification is 4x 18:12:42 I ran the bp benchmarks on my machine (rough results): 18:12:42 ``` 18:12:42 verification 18:12:42 [num aggregated: zkcrypto bp, monero bp, monero bp+] 18:12:42 1: 3.23ms, 5.90ms, 5.80ms 18:12:42 2: 5.29ms, 9.64ms, 9.24ms 18:12:42 4: 8.85ms, 15.72ms, 17.56ms 18:12:43 8: 16.24ms, 27.95ms, 27.28ms 18:12:43 16: 28.05ms, 49.46ms, 49.16ms 18:12:44 32: 54.38ms, 91.33ms, 92.80ms 18:12:44 ``` 18:14:20 (I am not using a avx2 backend)