00:00:19 i guess it's possible that since the H for pedersen commitments is way more important to never have its private key wrt G exposed, i'd imagine that they may have thought it lower risk to generate H directly from the hash in case a vulnerability was ever found in their special Hp() concoction 00:00:31 it feels more NUMS-y to generate H that way 00:01:37 i think that special Hp() function is unique to cryptonote 00:02:39 so didn't have wider scrutiny 00:04:15 the citation for that function is here https://arxiv.org/abs/0706.1448 00:11:24 it seems so strange the original cryptonote team's project bytecoin was a scam; they really were very intelligent 00:11:40 and competent 00:15:00 Interestingly, someone noted a while back that an iterated direct-point-test hash may be faster on average 00:15:26 i.e. you keep testing `H(data,i)` for iterated values `i` until you land on the curve 00:16:21 faster than Hp? 00:17:52 Possibly faster than the SWU method, possibly. But it'd be pretty small potatoes (and you'd need to build plenty of spaghetti code for the change), so we never investigated 00:19:17 FWIW the next-gen sublinear constructions don't use hash-to-curve operations for linking tags anyway 00:19:39 Only hash-to-scalar operations, which are very fast 00:19:53 oh nice 00:20:16 Yeah, linking tags for signing key `x` are of the form `(1/x)*U` for a fixed group generator `U` 00:20:42 Speeds up verification quite a bit 00:21:17 (that was the reason why multisig is more annoying... you lose the linearity) 00:22:46 You still need a set of NUMS generators, which you'd presumably construct via hash-to-point ops 00:22:57 did you find a solution for multisig? 00:22:58 But these are done once and can be cached 00:23:30 Oh a solution for the inversion thing? Yes, a variation of Gennaro and Goldfeder 00:24:21 The other steps are all nicely linear and can be done with simple commit-and-reveal sums 00:26:06 UkoeHB_ | the citation for that function is here < interesting, thanks - i didn't know that was something they'd taken from elsewhere. i wonder though if it had been used elsewhere, how much scrutiny the method had received, and how confident they were that they didn't screw up their implementation of the theory 00:26:38 It's a pretty well-accepted method AFAIK 00:27:04 I should test whether iterated direct hashing ends up being faster on average 00:27:35 There would be values that require many iterations, but statistically the chain terminates quickly 00:28:18 wouldnt you just need to check that the x coordinate is smaller than the group order? or do not all field elements produce group points? 00:28:28 correct 00:28:33 to the second part 00:28:57 and I assume you mean the underlying curve field 00:29:07 which does not have the same order as the curve group 00:29:31 On average, about 50% of field elements correspond to curve points 00:29:54 But anyway, switching hash methods would be unnecessarily complex and not useful for the next-gen stuff anyway 00:30:00 Only mentioned it as a fun note 00:30:57 why would there be field elements that dont produce curve points? 00:32:11 if the equation is ax^2+y^2=1+dx^2y^2, are there some x that make y = sqrt(negative number)? 00:34:10 no that doesnt make sense since all field elements are positive 00:52:46 i dont understand what i'm talking about, but i can see in the source code that the test for an invalid curve point is whether BOTH vx^2-u and vx^2 are non-zero 00:53:35 where u = y^2 -1 and v = d * y^2 + 1 and x = sqrt(u / v) 00:54:38 and where y is the field element represented by the byte sequence being interpreted as a curve point 00:56:33 makes sense, I wonder how often that would actually happen though 00:56:43 oh i've tested that for sure 00:56:55 it always comes out at pretty much exactly 50% of byte sequences work 00:57:34 wonder why that would be 00:58:09 sorry for the spam, this is the explanation of how points are recovered: 00:58:16 * x is recovered in the following way (p = field size): 00:58:18 *
00:58:20 * x = sign(x) * sqrt((y^2 - 1) / (d * y^2 + 1)) = sign(x) * sqrt(u / v) with u = y^2 - 1 and v = d * y^2 + 1. 00:58:22 * Setting β = (u * v^3) * (u * v^7)^((p - 5) / 8) one has β^2 = +-(u / v). 00:58:24 * If v * β = -u multiply β with i=sqrt(-1). 00:58:26 * Set x := β. 00:58:28 * If sign(x) != bit 255 of s then negate x. 00:59:03 point decompression 00:59:41 yeah 01:01:35 i don't even really understand how you can have a field element representing sqrt(-1) 01:01:58 which is what is done to x to get the EC point x coord 01:02:02 there are no negative numbers, so it's really -1 mod q 01:02:37 i can't get my head around why mod q provides a sqrt 01:03:00 sqrt([-1 mod q]) = sqrt(positive number) 01:03:22 or actually sqrt([-1 mod q]) = sqrt(q - 1) 01:04:16 ohh i see, thanks 16:00:28 Reminder: research meeting today at 18:00 UTC (about two hours from now) 16:45:36 suraeNoether: I found a small omission in the original Triptych preprint's prover routine description that I'll be updating today (letting you know since you're a coauthor) 16:45:58 Doesn't affect security or anything. Merely forgot to transcribe a particular variable definition from my notes 17:03:00 Updated: https://eprint.iacr.org/2020/018 17:03:07 Literally a one-line update 17:05:38 Reminder: research meeting in about an hour (18:00 UTC) 17:51:18 real quick, I need two more citations to hit twice the amount of first edition, any takers? 17:52:37 Cite a few of the proposed next-gen transaction protocols? 17:52:45 Omniring, RingCT 3.0, Lelantus, Triptych 17:54:06 ah good idea 17:55:05 Omniring was accepted to a conference 17:55:13 so that has a non-preprint citation now 17:58:08 OK, we'll start our meeting shortly 17:58:18 omniring doesn't need an audit to implement, got it /s 17:58:26 The usual agenda: https://github.com/monero-project/meta/issues/444 17:59:31 Logs will be posted there after the meeting ends 18:00:15 Let's start the meeting! 18:00:20 First, GREETINGS 18:00:21 hello 18:00:28 hi 18:00:47 * sarang will wait a couple of minutes 18:02:08 [meta] I added the MRL meetings with reminders to the Google Calendar I have if you are ok using Google: https://calendar.google.com/calendar/embed?src=itmaraubkfoe4aq2oquoaogsuk%40group.calendar.google.com&ctz=UTC 18:02:47 Does using that link leak any information to you? (presumably it leaks IP information to Google) 18:02:59 not to me, just Google 18:03:23 roger 18:03:27 OK, continuing on 18:03:31 Next up is the ROUNDTABLE 18:03:48 hi 18:03:50 I've been getting the multi-input version of Triptych updated for posting to the IACR preprint archive 18:04:01 as well as minor edits to the original preprint as I come across them 18:04:34 Posting to IACR (with suitable caveats about non-standard cryptographic hardness assumptions) can increase the visibility of the idea, and hopefully encourage feedback 18:05:07 It's pretty slow going, but progressing well 18:05:15 Any particular questions on that before I pass the baton? 18:08:06 OK, next up! 18:08:17 Does anyone else have research of interest to share and discuss? 18:09:39 * sarang will wait a bit; there's plenty of time 18:10:04 Yo 18:10:21 Hello Isthmus 18:10:29 Did you wish to share anything, or just observing? 18:10:33 I’ve been pretty busy in meatspace, sadly no time for data spelunking 18:10:41 OK, no problem! Simply checking 18:10:48 It's a fairly quiet day today anyway 18:11:18 UkoeHB_? 18:11:21 suraeNoether? 18:11:22 Others? 18:11:22 Oh yes, actually 18:11:25 ah ok 18:11:28 carry on Isthmus 18:11:51 Wait there’s too much traffic for voiced text, let me look back pewter in four minutes 18:12:00 roger 18:12:05 Someone else, then? 18:12:10 need about 10mins 18:13:04 OK, in that case, let's pause the meeting for 10 minutes or so; I show the time is 18:12, so let's reconvene at 18:22 or so 18:13:11 * sarang pauses the meeting 18:17:21 sarang: want to talk about Triptych naming at some point? 18:17:38 That seems like a suitably off-topic idea during this break =p 18:17:52 Right now, the multi-input Triptych preprint uses the name "Triptych-2" 18:17:59 this is boring and not descriptive 18:18:05 I am open to better naming ideas 18:18:20 Note that I can revise the older paper if that's helpful (this has been done to add features and fix errors) 18:19:14 what part of the original "triptych" is triple? 18:19:17 The benefits of Triptych-2 are using a single proof for all spends (instead of separate proofs with commitment offsets), and handling balance assertions directly within the proof 18:19:19 I originally recommended Triptyzk as a half joke, but part of me thinks it's a good idea 18:19:33 Polyptych 18:19:34 The idea was that the three parts to Triptych are signing keys, commitment keys, and linking tags 18:19:47 Heh, a polyptic sounds like something a surgeon would remove :/ 18:19:54 lmao 18:20:20 FWIW there's basically no change to the SHVZK property or proof between the two versions 18:20:29 They're almost identical 18:20:58 that's partially why adding "zk" now makes no sense. It's more about proactively naming for the Twitter trolls/idiots 18:21:47 B-Triptych and E-Triptych for basic and extended 🤔 18:21:57 Triptych Classic and New Triptych 18:22:26 Triptych and Antikythera :P 18:23:05 Just what we need; something equally hard to pronounce =p 18:23:19 * sarang resumes the meeting 18:23:19 Technology so old nobody remembers how it works. 18:23:28 yes... and indecipherable, and considered too advanced for its time 18:23:38 i havent been paying that close attention but have we "shelved" CLSAG? 18:23:57 suraeNoether just told me he's now happy with the revised security model for CLSAG 18:24:29 Nothing has changed with the algorithms themselves, apart from a small change to hash function inputs 18:25:08 it sounded like suraeNoether was considering advocating to skip CLSAG and go directly to next-gen in a year or two 18:25:17 I disagree 18:25:40 CLSAG is a straightforward change that's well understood 18:26:25 * moneromooo moves mouse over merge button 18:26:32 😂 18:26:54 Anyway, he made very recent updates that I'll review (more on this during ACTION ITEMS) for IACR posting 18:26:55 Anyway 18:27:04 UkoeHB_ and Isthmus both wanted to share some work 18:27:18 Will CSLAG require a paid review? 18:27:29 Nothing "requires" paid review 18:27:36 for you to be comfortable with it 18:27:38 But it's probably a good idea :) 18:27:51 I'm very comfortable with the math 18:28:09 Hm, upon more consideration, discussing it today might be the wrong order of operations 18:28:17 Nothing pressing or dangerous 18:28:18 The total estimate for math+code review by Teserakt was ~$15000 USD, which is quite reasonable IMO 18:28:28 Isthmus: how so? 18:28:36 Now you have everyone intrigued 18:29:08 happy to announce a final proofreading draft of ZtM2 is ready. Note that I decided not to go into Bulletproofs since it's frankly way too much detailed math to be worth it. Anyone who wants to learn bulletproofs should just read the original paper. https://www.pdf-archive.com/2020/03/04/zerotomoneromaster-v1-1-0/zerotomoneromaster-v1-1-0.pdf 18:29:10 A poorly-framed thought experiment is worse than no thought experiment at all 😅 18:29:21 UkoeHB_: great! 18:29:36 Will this be renamed to 2.0 after review? 18:29:59 Or will the title be incremented to "One to Monero" :D:D:D 18:30:17 Ill make a reddit post asking for proofreaders, and if anyone knows someone who wants to proofread go ahead and pass it around. Not much is likely to change between now and publication in ~1.5-2months. The proofreading period is 3 weeks. 18:30:34 I think Ill just remove the version number 18:30:36 maybe 18:31:14 UkoeHB_: fair play 18:31:15 Name them based on the most recent Monero version name? 18:32:21 Anyway, great to hear the update is nearing completion 18:32:28 Zero to Monero, Hero Edition 18:32:50 yes I want to meet the hero who reads the whole thing :) 18:32:53 the more -ero suffixes in the title, the better :P 18:33:24 Does anyone else wish to share research of interest? 18:35:59 OK, we can move on to ACTION ITEMS, then 18:36:21 I am completing the Triptych-2/NewTriptych/E-Triptych/etc. preprint for IACR posting 18:36:42 and reviewing the (hopefully final) changes to CLSAG that I received from suraeNoether 18:36:53 Anyone else? 18:37:58 proofreading, and listening to proofreader feedback if and when it appears; starting now will probably spend a lot less time with Monero as this project wraps up 18:38:29 I think a reddit post is a great idea to encourage readers to take a look 18:39:02 ZtM is such a valuable resource 18:40:50 Short meeting today! But that's fine 18:41:00 Any other questions, comments, etc. as we wrap up? 18:42:51 All right! Let's adjourn 18:42:56 Thanks to everyone for attending 18:43:01 Logs will be posted shortly to the GitHub issue 18:45:36 posted 18:49:20 sarang: do you think we need an audit in addition to the math+code review by Teserakt? 18:50:49 so triptych is like a bulletproof but all these things have been packed in the bulletproof. So its a quiverproof. magazineproof. why was it called bullet proof? the paper doesn't really say why it was named that 18:50:52 I personally don't think another code audit would provide much benefit for the cost, given the limited scope of changes and the fact that Teserakt would also be reviewing the math 18:51:26 gingeropolous: bulletproof because of standard assumptions, and bullet because fast to verify (IIRC from the paper) 18:51:45 Triptych is not like bulletproofs! 18:51:53 Different proving system, different goals, etc. 18:51:54 sorry sorry 18:53:09 The idea behind Triptych (broadly) is to use a single hidden index representation to prove things about signing keys, commitment keys, linking tags, and commitment balance 18:53:33 or rather, single hidden representation per spent input, extending this to multiple indices in one proof 18:53:43 (the original version removed the balance stuff but handled single indices, of course) 18:54:29 when you say single index representation, is this like the index shorthand currently used to reference outputs? 18:54:45 !tip $15000 MRL 18:54:52 o_0 18:55:00 for Audut 18:55:07 or an audit 18:55:38 so should the name describe how it does it, or what it can do. because it can be used for many fast many rings. 18:55:58 Who knows! I'm not good at naming things 18:56:21 As long as the name isn't misleading 18:56:26 All Your Rings Are Belong To Us (AYRABTU)... no that won't do. 18:56:32 and preferably sounds cool, because why not 18:57:16 I don't want to make this simply an update to the existing paper, because it's different in the cryptographic assumptions and is a pretty substantial improvement 18:57:30 but it's still based on the same underlying proving system 19:00:55 https://www.reddit.com/r/Monero/comments/fdhtqh/request_for_proofreading_zero_to_monero_second/ 19:01:57 :) 19:02:15 Neoskizzle. Peachflame. Pentwist. Pruvia. random word creators are fun. 20:09:14 Anybody heard from suraeNoether today? 20:10:02 tweeted 4h ago 20:19:40 Hmm perhaps he forgot about the meeting? 20:19:46 Or had a conflict