--- layout: post title: Logs for the MRL Meeting Held on 2020-04-08 tags: [dev diaries, crypto, research] author: asymptotically / Sarang --- # Logs **\** OK, time for the weekly research meeting **\** Let's get started **\** GREETINGS **\** hi **\** hi **\** hi **\** ahoy **\** On to ROUNDTABLE, I suppose **\** I've been working on papers for PoPETs submission, which has been a blast **\** hello! **\** As well as some review for a paper on hierarchical one-of-many proofs **\** Finally, plenty of code relating to Triptych **\** Not too much exciting stuff to report overall **\** Any particular questions? **\** hierarchical one-of-many-proofs sounds interesting. can you link the paper? **\** It's not on the IACR yet (and I am not the author) **\** Otherwise, anyone else who wishes to share research topics is welcome to do so **\** what are hierarchical one-of-many-proofs? **\** An extension of the Groth proofs used in Triptych and Lelantus that trade size for prover complexity **\** They use a clever layering technique **\** smaller size for increased prover complexity? **\** Other way around :) **\** ok :) **\** The author thought there could be verification savings in certain cases, but I don't think that's the case if you do batching in the usual way **\** Does anyone else have research topics they'd like to share or discuss here? **\** I can give an update on the scaling and fees issue #70 **\** Sure! **\** I have a solution for the scaling side and minimum relay fee. I am still finalizing the fee ratios **\** Basically we can use the long term medium to deal with this **\** Can you summarize? **\** Sure **\** 1) Put a cap on the rate of fall of the long term medium so that it falls at the same rate it rises **\** 2) Make the penalty free zone dynamic as the greater of 300000 bytes and 25% of the log term medium **\** Will that 300K value change with CLSAG? **\** No the reference transaction size will to 2100 **\** yes **\** But there are no plans to change the fixed-value penalty-free size? **\** The minimum relay fee will very close to the old normal fee **\** So for the current minimum penalty one the minimum fee will actually go up ~2.5x **\** ArticMine what issue/risk is this solution tackling? **\** A sudden drop in use followed by a recovery **\** In many ways similar to COVID-19 **\** What would be the shortcomings of the current implementation in that situation? **\** https://github.com/monero-project/research-lab/issues/70 **\** This create the scenario **\** Ah, couldn't find issue. Thank you **\** The basic problem is a sharp rise in fee that can take months or year to come back to normal **\** Also a very sudden drop in the long term medium that also could take months or years to recover **\** Issue #70 does not mention COVID-19 but COVID-19 is a very good scenario **\** Will you have specific code or pseudocode soon to allow for simulations prior to any recommended deployment? **\** Also there are scenarios where COVID-19 cold lead to a significant demand on the Monero network in terms of transactions **\** Yes **\** I have all the formulas now except for the fee ratios **\** OK, thanks **\** Still working on that **\** I assume you'll post them to the issue you linked? **\** Yes that is where I will post this **\** Got it **\** Anything else of note that folks wish to discuss? **\** I know UkoeHB\_ recently posted his new version of Zero to Monero **\** not sure if he's around right now **\** Yes that is excellent **\** but that's on the getmonero library page, along with a link to the TeX source repo **\** and there was also a suggestion from UkoeHB\_ for updating how MLSAG secret data is wiped, which was a great catch (PR now available) **\** Anyone else? **\** Otherwise, we can move on to ACTION ITEMS for the week **\** I will be continuing work on a C++ implementation of Triptych for timing efficiency tests **\** as well as some new material for the multi-signer Triptych variant's security model, prior to the PoPETs submission deadline **\** Oops, just got back. Nice work Artic! **\** Isthmus: do you have any research or topics you'd like the group to discuss? **\** Ah, I've been neck deep in Zcash all week. **\** https://twitter.com/Mitchellpkt0/status/1245769462172745728 **\** [ Mitchell P. Krawiec-Thayer on Twitter: "Several unique phenomena in the #Zcash transaction lock\_time field. Most make sense: 0, block heights, unix timestamps, delayed broadcast. Still trying to under ] - twitter.com **\** We did find that funny transaction over in NRL **\** Probably more of a novelty than anything else **\** Lemme grab the link **\** Anything relating to the Zcash lock times that's been observed in the Monero network too? **\** https://gist.github.com/noncesense-research-lab/a90b8bc5f57ffa9fff1a22d1323e5c2c **\** Or any lessons to learn from the Zcash work? **\** Monero's lock times look very similar **\** Actually there's also 4 bands **\** Like this: **\** 0 **\** {1,3,8,10,12} **\** {block heights ~ 1xxxxxx} **\** and then UTC timestamps **\** It's all over the place, and I don't think any of it is enforced, so the lock\_time field is really just an arbitrary memo xD **\** In Zcash too? **\** Did you analyze the distribution of the UTC timestamps as well? **\** Lemme try to find that notebook **\** Shoot, I don't have it on this computer **\** No worries **\** Any other action items for the week? **\** So what's up with duplicate subaddresses? **\** Isthmus: were those the only two such examples? **\** You suggested "novelty", heh **\** No, there were several, But all very similar, that one is representative **\** hmm **\** Along those lines, it was suggested (last week, IIRC) to move some of the more standardized tx fields out of extra **\** Which wouldn't eliminate strange behavior, of course **\** but could help with distinguishing factors like ordering etc. **\** Any further thoughts on that? **\** I'm working on it a bit, but need to move ideas from my head into diagrams. Will share here in a week or two. **\** Might have a new approach, but tbd **\** New approach to what exactly? **\** Transaction structure? **\** Nah, mental models that more accurately describe information leaks **\** But it doesn't all fit together yet. **\** My action item is making it into something comprehensible by next week xD **\** ah ok **\** Neat! **\** We're coming up on the end of the hour **\** Any last questions, topics, action items, etc.? **\** Just curious what's your perception of relevant research over the next 6 months. Everything staled? Business almost as usual? **\** Conferences and events are mostly canceled or moved to remote? **\** Oh you mean in the broader research community? **\** Seems that some conferences planned for later in the year are playing it by ear for now **\** Yeah, anything relevant to MRL and Monero, how do you see things going? **\** The cancellation of the Konferenco was unfortunate, but necessary **\** Otherwise, calls for papers seem to be mostly continuing as normal, which is great to see **\** ok good to know thank you **\** Perhaps bored academics stuck at home will be more eager to read and review new research too **\** and go straight for journals :) **\** Oh interesting question @binaryFate **\** That reminds me, when do we want to research quantum-resistant PoW and/or quantum-resistant cryptography? **\** Note that pqPoW isn't super important in the short term **\** "before it's too late" **\** However it is unfortunate that the Monero transaction I make tomorrow will most likely be decrypted by a quantum computer during my life time. **\** I know that suraeNoether had taken a particular interest recently in post-quantum signature constructions, but I don't know of any relevant efficient results at this point **\** It might be nice to have somebody put together a survey of (1) Exactly which pieces of Monero will be broken by quantum computers (2) Potentially Monero-compatible solutions **\** The reliance on discrete log hardness is the kicker **\** Yep, it's gonna be tricky. **\** But, I believe we can do it! If not, Monero has a very limited shelf-life :- P **\** I feel like the bipartite graph matching project that suraeNoether is verifying will be one of the most vulnerable **\** Graph matching is already parallelizable without a quantum computer **\** It's just a very large search space in general **\** On that happy note, let's go ahead and adjourn! **\** Thanks to everyone for participating **\** Logs will be posted shortly to the agenda GitHub issue