14:06:08 sarang: https://eprint.iacr.org/2020/152.pdf 14:07:38 o_O 14:14:43 plug and play? I haven't heard about that since 2007 14:15:01 lul 14:15:09 "drop-in replacement" has become more popular 14:23:23 hey everyone, good morning, I wanted to give the community a brief update on me and what's happening 14:26:22 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 14:26:22 absolute horrendous amount of surgery this year, and I'll try to keep people up to date on that as it happens 14:27:22 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 14:27:44 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 14:28:18 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 14:28:41 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) 14:30:26 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. 14:31:19 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 14:33:16 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 14:33:55 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 14:34:04 maybe two if it takes a long time to switch to triptych 14:34:37 last thing i want to mention about what i've been doing is largely keeping up with literature as best I can 14:36:39 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 14:36:39 to follow along with 14:37:37 during the past few weeks, I also spoke at the Fields Institute on Triptych 14:38:22 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) http://www.fields.utoronto.ca/video-archive/static/2020/02/2892-22075/mergedvideo.ogv 14:39:15 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 :( 14:39:32 hopped up on caffeine, jetlagged, y'all know the drill 14:39:51 anyway, if anyone has any questions for me, my main goal today is to get that matching report written up 14:44:04 I left some notes on CLSAG's new overleaf document, suraeNoether 14:49:16 I guess horrendous surgery is far better than quick death. But dang man, that still sucks. May you live long and prosper! 14:50:49 I'll be using most of today to get caught up on literature review 14:50:58 I have a long list of papers that's been piling up :/ 15:27:30 sarang thanks 15:27:34 Inge-: also thanks 15:28:13 Glad you're back suraeNoether :) 15:42:28 danke 15:45:15 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 15:45:27 This lets us reduce a bunch of byte conversions to save time 15:47:54 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 15:48:31 So now the hash functions must include `H({P_i},{D_i},C,...)` instead of `H({P_i},{C_i},...)` 15:48:55 This shouldn't affect security at all 15:49:30 makes sense 15:51:31 The overall time savings is about 5%, which absolutely seems worth it 15:53:14 also sarang, i'm not sure if you saw this: http://fc20.ifca.ai/preproceedings/54.pdf 15:53:22 i'm not endorsing any ideas in that paper 15:53:34 just pointing out that it's come across my desk, so to speak 15:54:26 Ah yes, I saw that but haven't had a chance to review yet 15:54:40 isthmus will like the final sentence of this abstract, too: https://ieeexplore.ieee.org/abstract/document/8993834 15:58:49 So this mainly applies known cluster-type techniques to transparent Zcash (which is basically Bitcoin)? 15:59:20 Aha, there's no paywall for the article... nvm 16:00:19 Unrelated note... a recent preprint (https://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 16:17:05 [keybase] : Nice 16:17:10 [keybase] : Medians are powerful 16:17:56 suraeNoether: can I upload that talk to the Community Workgroup YouTube channel? 16:19:35 yes please 16:50:04 suraeNoether: https://www.youtube.com/watch?v=uHKq-n2c0PE 17:33:49 It will be interesting to hear your thoughts on what https://eprint.iacr.org/2020/152.pdf being to the table.. more log scaling? 17:37:28 [keybase] : Don't know yet TBH and I don't want to speculate yet. But it's a very interesting paper 20:08:59 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 20:10:10 Can you remind us any particular areas of math and/or CS for which you consider yourself well-versed, TheCharlatan? 20:28:15 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. 20:28:46 Which might or might not be doable in practice, given you need to squawk bittorrent. 20:31:32 TheCharlatan gave us reproducible builds IIRC 20:32:08 scoobybejesus: yep, just trying to get a sense of projects that might be applicable here 20:32:26 indeed 20:47:24 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. 20:48:46 In that case, maybe adding an encrypted field in extra and taking out things like tx keys out of extra. 20:48:56 UkoeHB_: had some interesting ideas about more general tx proofs for audit purposes 20:49:09 ^ TheCharlatan 20:49:13 I have preliminary code for the former. Nowhere near three months though, but maybe we can pad it a bit :D 20:49:38 Was the extra tx pubkey bug taken care of moneromooo? 20:49:40 3 months seems like a lot of time 20:49:57 idk if even multisig updates are 3 months 20:50:01 I don't know. What is the extra tx pubkey bug ? 20:50:11 UkoeHB_: prove me wrong :D 20:50:22 An unfinished project is, by definition, not finished 20:50:49 who am I to say though lol 20:50:55 moneromooo: was it not observed that subaddress-destined txs included an extra pubkey? 20:50:58 not a programer <- 20:51:32 there is the normal pub key, and 'additional pub keys', but with subaddresses that normal pub key isn't used 20:51:36 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 ^_^ 20:51:45 ah ok 20:52:18 Seems like a good candidate to be fixed as a side effect of ing tx keys 20:52:25 Seems like a good candidate to be fixed as a side effect of moving tx keys out of extra. 20:52:50 aye 20:53:19 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. 20:53:41 So forcing them out of extra means they always have to be in the tx. 20:54:42 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). 20:54:52 They're basically protocol though 20:54:57 and probably should be 20:55:05 Multisig is probably way harder 21:05:09 anyway, latest ztm2 draft already explains more or less what should happen for both; https://www.pdf-archive.com/2020/02/26/zerotomoneromaster-v1-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