11:06:25 <binaryFate> ok interesting
13:45:00 <bmo-noire> ~~
15:20:27 <sarang> Hello all
15:20:37 <sarang> Reminder that the usual weekly meeting will take place here at 17:00 UTC
15:20:51 <sarang> (it's currently 15:20 UTC)
15:21:28 <sarang> .time
15:21:35 <sarang> Rats, that bot does not live here
15:56:09 <timebot> Hello sarang, the time is 1556 h UTC
16:01:39 <derpy_bridge> [keybase] <seddd>: :) more bot friends
16:46:40 <Isthmus> Hiya
16:46:49 <Isthmus> I wanna join for the meeting, but I'm soooo sleepy
16:46:57 * Isthmus pulls on lab coat, then takes a nap
16:59:24 <sarang> OK, let's get started with the meeting
16:59:26 <sarang> GREETINGS
16:59:27 <sarang> hi
16:59:59 <derpy_bridge> [keybase] <seddd>: o/
17:00:37 <UkoeHB_> hi
17:00:50 * sarang waits a few moments for others to arrive
17:01:00 <SerHack> hi
17:02:44 <sarang> Moving on, then, to ROUNDTABLE
17:02:50 <sarang> Who wishes to share research of interest?
17:03:42 <ArticMine> Hi
17:04:06 <sarang> I can share a few things
17:04:23 <sarang> I've completed some formal peer review for the IEEE S&B proceedings
17:04:41 <sarang> and worked on analysis for a linkable ring signature construction in IACR 2020/333
17:04:54 <sarang> it claimed to be more efficient than CLSAG
17:05:27 <sarang> However, the numbers assumed an insecure key image construction
17:05:52 <sarang> The authors have already posted a revision, but it doesn't include numbers or new security proofs for the modified construction
17:06:07 <sarang> Besides this, here's an update on some other projects...
17:06:34 <sarang> For CLSAG, I am still waiting on the final go-ahead from suraeNoether, who is a coauthor on the paper
17:07:00 <sarang> I finished code optimization and made a PR to moneromooo's branch, which has some nice verification speedups
17:07:17 <sarang> For Triptych-1, its preprint has been updated at IACR 2020/018
17:07:38 <sarang> An MPC construction for key images is completed, and multisig/join analysis is still underway
17:07:50 <sarang> For Triptych-2, its preprint has been posted at IACR 2020/312
17:07:57 <sarang> Multisig/join analysis is still underway
17:08:10 <sarang> That's all for me
17:08:17 <sarang> Any particular questions or comments?
17:08:44 <nioc> how much verification speeedup for CLSAG?
17:08:52 <derpy_bridge> [keybase] <seddd>: Do you need any more eyes on the CLSAG PR?
17:08:55 <sarang> It's around 4-5%
17:09:01 <nioc> nice
17:09:19 <sarang> seddd: That would be welcome, once moneromooo integrates the new changes into the branch
17:09:43 <derpy_bridge> [keybase] <seddd>: Ok, let me know, and I'll review
17:09:49 <sarang> that'd be great
17:09:59 <moneromooo> I did, I can push.
17:10:03 <sarang> Oh excellent
17:10:20 <ArticMine> 4-5% reduction in size? Verification time?
17:10:25 <sarang> The only real changes from the paper's description is a modification to the public parameters that go into the challenge hashes, which allows for the speedup to happen
17:10:29 <sarang> ArticMine: verification time
17:10:41 <sarang> I didn't bother with generation stuff, since that's less important
17:10:45 <sarang> Size is identical
17:11:22 <sarang> The PR includes new performance tests with better direct comparison to MLSAG, if that's useful to anyone
17:11:32 <derpy_bridge> [keybase] <seddd>: moneromooo: link?
17:12:08 <ArticMine> So is this the version that is going for audit?
17:12:21 <moneromooo> Not yet.
17:12:21 <sarang> Presumably, but that's up to the audit workgroup
17:12:40 <moneromooo> I'm rebasing it to master now, then will run tests, then push, then post a link.
17:12:56 <sarang> moneromooo: excellent, then the CI workflow will operate properly
17:13:09 <derpy_bridge> [keybase] <seddd>: awesome, many thanks 🤗
17:13:22 <sarang> Any other questions for me?
17:13:31 <sarang> Or does anyone else wish to share research topics?
17:14:38 <derpy_bridge> [keybase] <seddd>: Mb but it involves pow of another coin, not sure appropriate
17:14:49 <sarang> Perhaps suited for after the meeting
17:14:58 <derpy_bridge> [keybase] <seddd>: Definitely
17:15:18 <selsta> who is the audit workgroup? sgp?
17:15:36 <sarang> sgp_ has been working to coordinate
17:16:29 <sarang> As far as the CLSAG paper goes, if I don't hear from suraeNoether, eventually I suppose we'll just have to release the revised version without him
17:16:39 <sarang> But I would prefer not to do that, since he's a coauthor
17:17:14 <derpy_bridge> [keybase] <seddd>: Is suraeNoether not around rn?
17:17:18 <sarang> He hasn't enabled public viewing on the overleaf version, and I don't have access rights to do that unfortunately
17:17:40 <sarang> No, he is not around right now AFAIK
17:19:48 <derpy_bridge> [keybase] <seddd>: k
17:21:13 <sarang> Well, to respect everyone's time, I suppose we can move to ACTION ITEMS
17:21:16 <UkoeHB_> update from me: proofreading is extended to this weekend as comments are trickling in at the last moment :p; I have received several good feedbacks so far
17:21:22 <sarang> Ah ok, go ahead UkoeHB_
17:21:34 <UkoeHB_> current proofreading version is here https://www.pdf-archive.com/2020/03/22/zerotomoneromaster-v1-1-2/zerotomoneromaster-v1-1-2.pdf
17:21:36 <UkoeHB_> that's all
17:21:41 <sarang> Great, thanks
17:21:59 <sarang> My action items are to complete my proofreading of Zero to Monero (it's been delayed; my apologies)
17:22:10 <sarang> and to work on some Triptych-2 MPC math
17:22:23 <sarang> Anyone else?
17:22:40 <hyc> "research only, not for production use" inb4 sumo releases it and claims to be first
17:22:59 <UkoeHB_> oh right, I made a small update to Janus mitigation
17:23:03 <sarang> hyc: ?
17:23:10 <sgp_> UkoeHB_: cool,, what?
17:23:14 <derpy_bridge> [keybase] <seddd>: lul hyc
17:23:16 <hyc> sorry, catching up from a couple days ago
17:23:27 <UkoeHB_> https://github.com/monero-project/research-lab/issues/62#issuecomment-603079784
17:24:12 <derpy_bridge> [keybase] <seddd>: imagines sumo as yt commenter: "FIRST"
17:24:15 <sgp_> UkoeHB_: none of that is implemented correct?
17:24:20 <sarang> Off topic, folks!
17:24:21 <UkoeHB_> correct
17:24:32 <derpy_bridge> [keybase] <seddd>: srry
17:26:45 <sarang> IIRC, the last time Janus mitigations were discussed in a dev meeting, there seemed to be mixed support
17:26:47 <UkoeHB_> my action item is to go through all proofreading comments, and then this weekend finalize a for-publication version
17:27:44 <UkoeHB_> sarang part of that seemed to be related to exactly how many pub keys and janus base keys it would require
17:28:37 <UkoeHB_> full Janus mitigation would require: 1 Janus base key per transaction, #pub keys = #outputs for ALL transactions (not just tx with subaddresses as is the case now)
17:28:52 <sarang> yep
17:30:22 <derpy_bridge> [keybase] <seddd>: sounds like a lot of overhead, is that one of the main objections?
17:30:32 <UkoeHB_> there is partial Janus mitigation, where normal addresses and subaddresses are split up; in other words, don't mitigate linking of normal addresses with subaddresses; that way only tx with subaddresses would need the janus base key
17:31:36 <UkoeHB_> however, even with partial mitigation a lot more subaddress tx would be revealed as subaddress, as there are currently some optimizations that hide subaddress tx among normal tx
17:32:08 <UkoeHB_> while with full migitation, normal address tx and subaddress tx would be universally indistinguishable
17:32:26 <UkoeHB_> which iirc sarang was in favor of even outside of Janus
17:32:46 <derpy_bridge> [keybase] <seddd>: +1 for the latter
17:32:58 <sarang> Yeah, encouraging/enforcing indistinguishability is useful
17:32:59 <UkoeHB_> the main objective is solving the Janus attack
17:33:16 <UkoeHB_> which is currently undetectable
17:33:22 <sarang> yes
17:33:56 <derpy_bridge> [keybase] <seddd>: so what are the opposing arguments?
17:34:19 <sarang> Transaction size is increased
17:34:28 <sarang> that's a big counterargument
17:34:32 <sarang> (literally)
17:34:43 <derpy_bridge> [keybase] <seddd>: :)
17:35:14 <sarang> So as happens always, there's a tradeoff on complexity (in this case, size and protocol changes) and indistinguishability
17:35:19 <sarang> s/always/often
17:36:16 <sarang> Worth noting that with CLSAG, standard tx size already drops from ~2.5 kB to ~1.9 kB
17:36:23 <sarang> so there's some wiggle room
17:36:58 <derpy_bridge> [keybase] <seddd>: are there potentially more compact full Janis mitigations?
17:37:03 <sarang> Each added scalar/group element adds 32 bytes
17:37:09 <derpy_bridge> [keybase] <seddd>: Janus*
17:38:07 <UkoeHB_> this is the smallest known mitigation
17:38:41 <ArticMine> Tx size is increased by how much?
17:39:12 <UkoeHB_> on average, about 2.2*32 bytes per transaction
17:39:21 <UkoeHB_> assuming 2.2 is the average output count
17:39:55 <UkoeHB_> wait no, 32 + 1.2*32
17:40:01 <UkoeHB_> same thing lol
17:40:59 <derpy_bridge> [keybase] <seddd>: What about encoding the extra basepoint in smth like a lookup table, where base points are indexed by the first 8? bytes
17:41:04 <UkoeHB_> actually a tiny bit less than that, taking into account current subaddress tx
17:41:11 <ArticMine> So 64 bytes for a typical tx
17:41:20 <UkoeHB_> yeah basically
17:41:52 <ArticMine> So if the security issue is verified I do not see an issue here
17:41:53 <UkoeHB_> seddd, the base key must be generated by transaction authors
17:42:08 <UkoeHB_> under the current construction, not sure if there are any other ways to do it
17:42:14 <sarang> ArticMine: the math checks out on the fix
17:42:30 <derpy_bridge> [keybase] <seddd>: Ok so unknowable ahead, gotcha
17:43:57 <derpy_bridge> [keybase] <seddd>: will read more in the issue you linked
17:44:09 <sarang> Probably time to bring it up in dev meeting again
17:44:30 <UkoeHB_> seddd there might be something to that (using a fixed janus base key of some kind), Ill ponder it a bit
17:44:47 <sarang> Any other action items to bring up?
17:45:18 <derpy_bridge> [keybase] <seddd>: UkoeHB_ that's kind of what I was thinking, or a fixed set of usable bases
17:45:53 <derpy_bridge> [keybase] <seddd>: Happy to collaborate, this is an interesting problem
17:47:01 <sarang> for sure
17:47:17 <sarang> OK, let's go ahead and wrap things up for this meeting; discussions can of course continue after we adjourn
17:47:27 <sarang> Any last topics of general interest for the meeting?
17:48:40 <sarang> Righto! Meeting adjourned
17:48:46 <sarang> thanks to everyone for attending
17:49:02 <derpy_bridge> [keybase] <seddd>: ty for the meeting 😊
17:49:07 <sarang> Logs will be posted to the github issue shortly
17:49:13 <sarang> Feel free to continue discussions!
17:49:58 <derpy_bridge> [keybase] <seddd>: hyc: if you're still around, and have time, I'd like to talk some randomx stuffs
17:50:46 <moneromooo> I pushed sarang's new CLSAG stuff to https://github.com/moneromooo-monero/tree/clsag but tests haven't been run yet, still building.
17:51:12 <derpy_bridge> [keybase] <seddd>: woot, will pull down and run locally
17:56:04 <sarang> Thanks moneromooo !
17:58:34 <selsta> moneromooo: there are some Windows / macOS compile issues https://github.com/moneromooo-monero/bitmonero/actions/runs/63185312
17:59:43 <selsta> or wait, Windows is just Github being dumb :) macOS does seem to have a problem though
18:00:18 <moneromooo> Any error message ?
18:00:48 <moneromooo> (apart from "We are currently unable to download the log. Please try again later")
18:01:21 <selsta> https://paste.debian.net/hidden/d6a6188e/
18:02:14 <selsta> also Windows CI fails because it seems like you have too many branches lol
18:04:14 <moneromooo> Does adding a u suffix to 1 help ?
18:04:29 <moneromooo> Or does that get auto run if I push to the branch
18:04:39 <selsta> yes it runs again once you push
18:04:46 <moneromooo> I'll try that then.
18:05:58 <moneromooo> Same for the rpc tests then, that's where you got that error ?
18:06:52 <selsta> yep, your rpc patch did not solve the iise
18:06:58 <selsta> issue*
18:09:47 <moneromooo> Guess it uses some really weird system to load logs. I've got javascript enabled on that browser but it can't load any log...
18:11:12 <selsta> hmm afaik it does not javascript
18:13:43 <selsta> does clicking on … and then View raw logs work?
18:14:09 <moneromooo> Oh nice, it does , thanks.
19:23:11 <moneromooo> selsta: AFAICT this change fixed it, so I'll squash and push again.
19:24:45 <sarang> what was the problem?
19:26:32 <moneromooo> signed/unsigned thingie.
20:19:02 <sarang> moneromooo: are you testing locally still? Last commit that I see on your `bitmonero/clsag` branch shows CI failure
20:22:51 <moneromooo> No. I see it's built on mac. Still going on ubuntu, but it succeeded ealrier.
20:23:00 <sarang> Ah I see, ok
20:23:16 <sarang> Best to wait on any mac build fixes before reviewing?
20:23:18 <moneromooo> And window is being windows apparently.
20:23:30 <moneromooo> Since Mac builds, no.
20:24:56 <sarang> Hmm, wonder what the windows issue is
20:25:13 <sarang> My earlier rebased versions of clsag (without your full implementation stuff) built fine on all platforms
20:25:14 <moneromooo> selsta said too many branches. Could be out of fds.
20:25:19 <sarang> but those were only signature stuff and tests
20:25:22 <sarang> ah ok
20:25:35 <moneromooo> The error was in seralization.
20:26:11 <sarang> ty
20:26:36 <sarang> Is the plan to do a PR to `monero/master` with review there?
20:26:56 <moneromooo> Yes.
20:28:15 <sarang> roger
20:28:24 <sarang> Hope my optimization changes weren't too annoying :/
20:29:13 <moneromooo> They were not, despite stuff moving around.
20:31:47 <sarang> gotta keep you on your toes
20:32:07 <sarang> Looking forward to reviewing the PR :D
20:32:32 <moneromooo> Well I was waiting for a review first. All this time...
20:33:14 <sarang> I see
20:33:29 <sarang> I had expected to review again after any final rebase etc.
20:33:44 <sarang> to ensure that all the changes I expected were present
20:34:00 <sarang> since there's been back-and-forth on the optimizations
20:34:34 <moneromooo> There might be a misunderstanding. What's in the clsag tree *is* the latest including your recent changes.
20:34:35 <sarang> IIRC you had requested that I not rebase for my changes, to make your integrations simpler
20:34:38 * moneromooo ask for a bit
20:35:22 <sarang> At any rate, apologies for any confusion
20:41:23 <derpy_bridge> [keybase] <seddd>: moneromooo: running tests on clsag tree now. Is there anything useful you would like me to do manually?
20:54:10 <sarang> ditto, also testing
21:06:51 <derpy_bridge> [keybase] <seddd>: also NVM about the set of bases thing for janus mitigation. Just read thru the gh issue again and realized only one extra element need to be sent since fixed base used
21:30:09 <moneromooo> Well, I can PR it before review if that's what most people want.
21:31:44 <moneromooo> seddd: depending on your skills and time... code review of various bits. sarang's commits if you're a crypto person, my commits if you're more of a generalist coder.
21:31:56 <moneromooo> Nothing particular otherwise.
22:07:57 <derpy_bridge> [keybase] <seddd>: For sure, will dig through the code. I saw fuzz tests when I built, do you welcome contributions there for this PR?
22:08:45 <derpy_bridge> [keybase] <seddd>: All tests passed btw 🚀
22:09:04 <derpy_bridge> [keybase] <seddd>: _hurray I iz CI_
23:35:09 <moneromooo> Feel free to add fuzz tests for anything, though I fear nobody runs them atm.
23:35:24 <moneromooo> So that makes them not super useful unfortunately.