sarang: eprint.iacr.org/2020/152.pdf

o_O

plug and play? I haven't heard about that since 2007

lul

"drop-in replacement" has become more popular

hey everyone, good morning, I wanted to give the community a brief update on me and what's happening

I don't want to get into a personal discussion about my health on a public channel, but the short story is that my doctors found some suspicious test results that indicated absolute doom and gloom. It turns out that instead of doom and gloom, these results were due to a confluence of other health issues. I thought I was dying extremely soon, but I'm okay and I'm not dying. I do, however, need an

absolute horrendous amount of surgery this year, and I'll try to keep people up to date on that as it happens

regarding work: the majority of my work in the past two weeks has been for CLSAG results and matching code, which i'm wrapping up

if this wasn't february, i'd say i'd probably be done by the end of the month, but I'm guessing I'll have an update for our next research meeting

in addition to clsag and matching, I've been taking a second look at triptych and longer-term migration plans for Monero over the next 5 years or so

due to our development process, it's hard to look at something like triptych or CLSAG and guess the shelf life before we upgrade to Something Else (tm)

but it's important because migration time has to be taken into account; i've been thinking heavily about whether we should skip CLSAG altogether and go straight for triptych. unfortunately, i have not kept up with conversation in here over the past two weeks.

i understand several folks in the community have been frustrated with how CLSAG has proceeded with auditing, and I secretly wish on some level that triptych had come around 6 months later than it had, it would have made thinking about the pros and cons dead simple

the primary issue that's nagging at me is that triptych and ringct3 seem to be approaching a sort of optimality with proving statements using discrete log approaches, and triptych is sufficiently efficient (heh) that i would love for its shelf life to be more than 3-4 years

using clsag so soon would involve keeping a lot of code around for later verification, it would involve the implementation risk associated with any migration, and it's shelf life would be like, a year

maybe two if it takes a long time to switch to triptych

last thing i want to mention about what i've been doing is largely keeping up with literature as best I can

i've recently been looking into linkable ring signatures in settings outside of the discrete logarithm setting for longer-term migration, for example. at least two "post-quantum" Monero-style proposals have recently come out of chinese universities. they are both awkwardly slow and huge, as one may expect from PQ protocols, but they are just the start of quantum-secure private e-cash, which is exciting

to follow along with

during the past few weeks, I also spoke at the Fields Institute on Triptych

you can see the video here, where I both planned for only 15 slides and blew through my slides faster than intended, ending up facing a full 10 minutes of questions afterwards (so it's good i went quick) fields.utoronto.ca/video-archive/st…/2020/02/2892-22075/mergedvideo.ogv

sarang is going to cringe because I made many slip-ups during that talk... I got my doctor's results just like... two days before that and I didn't practice at all :(

hopped up on caffeine, jetlagged, y'all know the drill

anyway, if anyone has any questions for me, my main goal today is to get that matching report written up

I left some notes on CLSAG's new overleaf document, suraeNoether

I guess horrendous surgery is far better than quick death. But dang man, that still sucks. May you live long and prosper!

I'll be using most of today to get caught up on literature review

I have a long list of papers that's been piling up :/

sarang thanks

Inge-: also thanks

Glad you're back suraeNoether :)

danke

suraeNoether: a quick note that my new CLSAG optimization branch requires a small tweak to the hash inputs to include both amount commitments and aux commitments, not just the commitments to zero

This lets us reduce a bunch of byte conversions to save time

So instead of being handed `{P_i}` and `{C_i}` (where `P_l` and `C_l` are commits to zero), the verifier is handed `{P_i}` and `{D_i}` and `C'` (where `{D_i}` are the actual output amount commitments, and `C'` is the commitment offset) and uses `{D_i - C'}` in the verification

So now the hash functions must include `H({P_i},{D_i},C,...)` instead of `H({P_i},{C_i},...)`

This shouldn't affect security at all

makes sense

The overall time savings is about 5%, which absolutely seems worth it

also sarang, i'm not sure if you saw this: fc20.ifca.ai/preproceedings/54.pdf

i'm not endorsing any ideas in that paper

just pointing out that it's come across my desk, so to speak

Ah yes, I saw that but haven't had a chance to review yet

isthmus will like the final sentence of this abstract, too: ieeexplore.ieee.org/abstract/document/8993834

So this mainly applies known cluster-type techniques to transparent Zcash (which is basically Bitcoin)?

Aha, there's no paywall for the article... nvm

Unrelated note... a recent preprint (eprint.iacr.org/2020/094) looked at a range of difficulty adjustment algos with respect to selfish mining, and found Monero's to be reasonably robust

[keybase] <surae>: Nice

[keybase] <surae>: Medians are powerful

suraeNoether: can I upload that talk to the Community Workgroup YouTube channel?

yes please

suraeNoether: youtube.com/watch?v=uHKq-n2c0PE

It will be interesting to hear your thoughts on what eprint.iacr.org/2020/152.pdf being to the table.. more log scaling?

[keybase] <surae>: Don't know yet TBH and I don't want to speculate yet. But it's a very interesting paper

My university is tasking me with a 12 week full-time internship at a company and project of my choosing over the summer. Do you happen to know of something that I could work on in Monero that I can finish within 3 months? Maybe I can help with something that MRL or Insight are currently doing? <- sarang Isthmus

Can you remind us any particular areas of math and/or CS for which you consider yourself well-versed, TheCharlatan?

And what kind of thing it has to be. Because without more detailed specs, I'm thinking about this "maintain a DHT on bittorrent to find monero peers to bootstrap from" thing gingeropolous and yanmaani were talking about earlier.

Which might or might not be doable in practice, given you need to squawk bittorrent.

TheCharlatan gave us reproducible builds IIRC

scoobybejesus: yep, just trying to get a sense of projects that might be applicable here

indeed

it can be literally anything, only frame is it needs to be done within 3 months and focus on a single project with a clear description. My math is not that strong, but I can find my way around the code and I can read and understand the mrl publications. if you want me to name a particular field, I'm more interested in wallets and transactions than the p2p layer.

In that case, maybe adding an encrypted field in extra and taking out things like tx keys out of extra.

UkoeHB_: had some interesting ideas about more general tx proofs for audit purposes

^ TheCharlatan

I have preliminary code for the former. Nowhere near three months though, but maybe we can pad it a bit :D

Was the extra tx pubkey bug taken care of moneromooo?

3 months seems like a lot of time

idk if even multisig updates are 3 months

I don't know. What is the extra tx pubkey bug ?

UkoeHB_: prove me wrong :D

An unfinished project is, by definition, not finished

who am I to say though lol

moneromooo: was it not observed that subaddress-destined txs included an extra pubkey?

not a programer <-

there is the normal pub key, and 'additional pub keys', but with subaddresses that normal pub key isn't used

Oh, that. It's not a bug AFAIK. I've always left it alone till stoffu changes it because I'm scared to touch that part of the code ^_^

ah ok

Seems like a good candidate to be fixed as a side effect of ing tx keys

Seems like a good candidate to be fixed as a side effect of moving tx keys out of extra.

aye

Though smooth had a fair point that tx keys are really not protocol, one might well imagine a world where no tx has tx keys, and they're communicated via different channels.

So forcing them out of extra means they always have to be in the tx.

TheCharlatan: from my point of view there are two fairly big projects. Making a structured audit system (includes adding new proofs to what we have), and various updates to multisig (security updates from paper, and then increasing the code versatility so more applications are possible).

They're basically protocol though

and probably should be

Multisig is probably way harder

anyway, latest ztm2 draft already explains more or less what should happen for both; pdf-archive.com/2020/02/26/zerotomo…0-30/zerotomoneromaster-v1-0-30.pdf tx proofs is ch. 9, and multisig is ch. 10 and 11. I made notes about what isn't implemented, and what is. You could say our current systems are 'incomplete' versions of what I lay out. That's my pitch :p