ok interesting

~~

Hello all

Reminder that the usual weekly meeting will take place here at 17:00 UTC

(it's currently 15:20 UTC)

.time

Rats, that bot does not live here

Hello sarang, the time is 1556 h UTC

[keybase] <seddd>: :) more bot friends

Hiya

I wanna join for the meeting, but I'm soooo sleepy

OK, let's get started with the meeting

GREETINGS

hi

[keybase] <seddd>: o/

hi

hi

Moving on, then, to ROUNDTABLE

Who wishes to share research of interest?

Hi

I can share a few things

I've completed some formal peer review for the IEEE S&B proceedings

and worked on analysis for a linkable ring signature construction in IACR 2020/333

it claimed to be more efficient than CLSAG

However, the numbers assumed an insecure key image construction

The authors have already posted a revision, but it doesn't include numbers or new security proofs for the modified construction

Besides this, here's an update on some other projects...

For CLSAG, I am still waiting on the final go-ahead from suraeNoether, who is a coauthor on the paper

I finished code optimization and made a PR to moneromooo's branch, which has some nice verification speedups

For Triptych-1, its preprint has been updated at IACR 2020/018

An MPC construction for key images is completed, and multisig/join analysis is still underway

For Triptych-2, its preprint has been posted at IACR 2020/312

Multisig/join analysis is still underway

That's all for me

Any particular questions or comments?

how much verification speeedup for CLSAG?

[keybase] <seddd>: Do you need any more eyes on the CLSAG PR?

It's around 4-5%

nice

seddd: That would be welcome, once moneromooo integrates the new changes into the branch

[keybase] <seddd>: Ok, let me know, and I'll review

that'd be great

I did, I can push.

Oh excellent

4-5% reduction in size? Verification time?

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

ArticMine: verification time

I didn't bother with generation stuff, since that's less important

Size is identical

The PR includes new performance tests with better direct comparison to MLSAG, if that's useful to anyone

[keybase] <seddd>: moneromooo: link?

So is this the version that is going for audit?

Not yet.

Presumably, but that's up to the audit workgroup

I'm rebasing it to master now, then will run tests, then push, then post a link.

moneromooo: excellent, then the CI workflow will operate properly

[keybase] <seddd>: awesome, many thanks 🤗

Any other questions for me?

Or does anyone else wish to share research topics?

[keybase] <seddd>: Mb but it involves pow of another coin, not sure appropriate

Perhaps suited for after the meeting

[keybase] <seddd>: Definitely

who is the audit workgroup? sgp?

sgp_ has been working to coordinate

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

But I would prefer not to do that, since he's a coauthor

[keybase] <seddd>: Is suraeNoether not around rn?

He hasn't enabled public viewing on the overleaf version, and I don't have access rights to do that unfortunately

No, he is not around right now AFAIK

[keybase] <seddd>: k

Well, to respect everyone's time, I suppose we can move to ACTION ITEMS

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

Ah ok, go ahead UkoeHB_

current proofreading version is here pdf-archive.com/2020/03/22/zerotomo…1-1-2/zerotomoneromaster-v1-1-2.pdf

that's all

Great, thanks

My action items are to complete my proofreading of Zero to Monero (it's been delayed; my apologies)

and to work on some Triptych-2 MPC math

Anyone else?

"research only, not for production use" inb4 sumo releases it and claims to be first

oh right, I made a small update to Janus mitigation

hyc: ?

UkoeHB_: cool,, what?

[keybase] <seddd>: lul hyc

sorry, catching up from a couple days ago

[keybase] <seddd>: imagines sumo as yt commenter: "FIRST"

UkoeHB_: none of that is implemented correct?

Off topic, folks!

correct

[keybase] <seddd>: srry

IIRC, the last time Janus mitigations were discussed in a dev meeting, there seemed to be mixed support

my action item is to go through all proofreading comments, and then this weekend finalize a for-publication version

sarang part of that seemed to be related to exactly how many pub keys and janus base keys it would require

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)

yep

[keybase] <seddd>: sounds like a lot of overhead, is that one of the main objections?

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

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

while with full migitation, normal address tx and subaddress tx would be universally indistinguishable

which iirc sarang was in favor of even outside of Janus

[keybase] <seddd>: +1 for the latter

Yeah, encouraging/enforcing indistinguishability is useful

the main objective is solving the Janus attack

which is currently undetectable

yes

[keybase] <seddd>: so what are the opposing arguments?

Transaction size is increased

that's a big counterargument

(literally)

[keybase] <seddd>: :)

So as happens always, there's a tradeoff on complexity (in this case, size and protocol changes) and indistinguishability

s/always/often

Worth noting that with CLSAG, standard tx size already drops from ~2.5 kB to ~1.9 kB

so there's some wiggle room

[keybase] <seddd>: are there potentially more compact full Janis mitigations?

Each added scalar/group element adds 32 bytes

[keybase] <seddd>: Janus*

this is the smallest known mitigation

Tx size is increased by how much?

on average, about 2.2*32 bytes per transaction

assuming 2.2 is the average output count

wait no, 32 + 1.2*32

same thing lol

[keybase] <seddd>: What about encoding the extra basepoint in smth like a lookup table, where base points are indexed by the first 8? bytes

actually a tiny bit less than that, taking into account current subaddress tx

So 64 bytes for a typical tx

yeah basically

So if the security issue is verified I do not see an issue here

seddd, the base key must be generated by transaction authors

under the current construction, not sure if there are any other ways to do it

ArticMine: the math checks out on the fix

[keybase] <seddd>: Ok so unknowable ahead, gotcha

[keybase] <seddd>: will read more in the issue you linked

Probably time to bring it up in dev meeting again

seddd there might be something to that (using a fixed janus base key of some kind), Ill ponder it a bit

Any other action items to bring up?

[keybase] <seddd>: UkoeHB_ that's kind of what I was thinking, or a fixed set of usable bases

[keybase] <seddd>: Happy to collaborate, this is an interesting problem

for sure

OK, let's go ahead and wrap things up for this meeting; discussions can of course continue after we adjourn

Any last topics of general interest for the meeting?

Righto! Meeting adjourned

thanks to everyone for attending

[keybase] <seddd>: ty for the meeting 😊

Logs will be posted to the github issue shortly

Feel free to continue discussions!

[keybase] <seddd>: hyc: if you're still around, and have time, I'd like to talk some randomx stuffs

I pushed sarang's new CLSAG stuff to github.com/moneromooo-monero/tree/clsag but tests haven't been run yet, still building.

[keybase] <seddd>: woot, will pull down and run locally

Thanks moneromooo !

moneromooo: there are some Windows / macOS compile issues github.com/moneromooo-monero/bitmonero/actions/runs/63185312

or wait, Windows is just Github being dumb :) macOS does seem to have a problem though

Any error message ?

(apart from "We are currently unable to download the log. Please try again later")

also Windows CI fails because it seems like you have too many branches lol

Does adding a u suffix to 1 help ?

Or does that get auto run if I push to the branch

yes it runs again once you push

I'll try that then.

Same for the rpc tests then, that's where you got that error ?

yep, your rpc patch did not solve the iise

issue*

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...

hmm afaik it does not javascript

does clicking on … and then View raw logs work?

Oh nice, it does , thanks.

selsta: AFAICT this change fixed it, so I'll squash and push again.

what was the problem?

signed/unsigned thingie.

moneromooo: are you testing locally still? Last commit that I see on your `bitmonero/clsag` branch shows CI failure

No. I see it's built on mac. Still going on ubuntu, but it succeeded ealrier.

Ah I see, ok

Best to wait on any mac build fixes before reviewing?

And window is being windows apparently.

Since Mac builds, no.

Hmm, wonder what the windows issue is

My earlier rebased versions of clsag (without your full implementation stuff) built fine on all platforms

selsta said too many branches. Could be out of fds.

but those were only signature stuff and tests

ah ok

The error was in seralization.

ty

Is the plan to do a PR to `monero/master` with review there?

Yes.

roger

Hope my optimization changes weren't too annoying :/

They were not, despite stuff moving around.

gotta keep you on your toes

Looking forward to reviewing the PR :D

Well I was waiting for a review first. All this time...

I see

I had expected to review again after any final rebase etc.

to ensure that all the changes I expected were present

since there's been back-and-forth on the optimizations

There might be a misunderstanding. What's in the clsag tree *is* the latest including your recent changes.

IIRC you had requested that I not rebase for my changes, to make your integrations simpler

At any rate, apologies for any confusion

[keybase] <seddd>: moneromooo: running tests on clsag tree now. Is there anything useful you would like me to do manually?

ditto, also testing

[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

Well, I can PR it before review if that's what most people want.

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.

Nothing particular otherwise.

[keybase] <seddd>: For sure, will dig through the code. I saw fuzz tests when I built, do you welcome contributions there for this PR?

[keybase] <seddd>: All tests passed btw 🚀

[keybase] <seddd>: _hurray I iz CI_

Feel free to add fuzz tests for anything, though I fear nobody runs them atm.

So that makes them not super useful unfortunately.