diff --git a/_posts/2019-04-15-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-04-15.md b/_posts/2019-04-15-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-04-15.md new file mode 100644 index 00000000..c0a8ebf9 --- /dev/null +++ b/_posts/2019-04-15-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-04-15.md @@ -0,0 +1,93 @@ +--- +layout: post +title: Logs for the Monero Research Lab Meeting Held on 2019-04-15 +summary: Surae work, Sarang work, and miscellaneous +tags: [community, crypto, research] +author: el00ruobuob / sarang +--- + +# Logs + +**\** Let's begin our meeting! +**\** 1. GREETINGS +**\** Hi +**\<[-mugatu-]>** o/ +**\** Quiet day today... +**\** But I suppose we can still move to 2. ROUNDTABLE +**\** suraeNoether: care to go first today? +**\** sure, my cat is missing and i want to go look for her, so i'm going to make this quick +**\** :( +**\** Understood +**\** CLSAG signatures are fast and small, they are so fast and small that my naive colored-coin approach could support two assets and still be faster and smaller than our present MLSAG scheme +**\** i'm not recommending coloring monero, but commenting on overall speed, it's nuts +**\** however, as sarang mentioned, there is a key image problem i'm looking into +**\** it's possible rectifying them will cost us some of those gains +**\** Yeah, I don't think a straightforward LSAG reduction works here +**\** in the meantime, i'm handing CLSAG off to sarang for at least 7 days so i can focus on MRL11 +**\** But I wonder if a redefinition of the security requirements to accommodate the new linking will be sufficient +**\** since we're rounding the corner on that, it's my top priority, and i want to get CLSAG out of sight for a few days +**\** righto +**\** okay, i'll be back later today, hopefully with suraecat +**\** Thanks, and best of luck with your search +**\** I completed the building blocks for a simple Lelantus transaction flow (insecure example code in agenda) +**\** and am in contact with the paper's author to discuss some privacy aspects of the construction +**\** the CLSAG example code has been updated to reflect some changes +**\** and, as suraeNoether said, still working on proper formalization, which is trickier than expected +**\** The output selection algorithm discussed here still has an open PR from moneromooo that needs eyeballs +**\** PR 5389 +**\** Hi +**\** yo +**\** Will lurk mostly. +**\** Does anyone else have research to share? +**\** Just announcing presence +**\** Otherwise we can keep waxing poetic about CLSAG definitions +**\** here now +**\** :/ +**\** Hi suraeNoether +**\** sgp\_: +**\** bah, silly autocomplete +**\** I have these multi user txes going in the background, and I am wondering whether the 'a' values can be reuesd for multiple outputs. +**\** Remind me what these values are/ +**\** What's the status on M-of-N multisig? +**\** The idea is to make 16 actual outs for the "same" logical output, so they get shuffled as new outputs are added. +**\** (our notation is often inconsistent) +**\** And I don't know whether it's safe to keep those. I assume sharing them with other usesr of the same tx is not good. +**\** \ however, as sarang mentioned, there is a key image problem i'm looking into \<= This is referring to CSLAG right? +**\** dEBRUYNE: yes +**\** there are no such issues with MLSAG +**\** All right, thanks for clarifying +**\** The problem refers to the fact that trying to reduce CLSAG to LSAG with an aggregated key yields the wrong key image +**\** a is the random secret keys generated at proive time to create the pseudoOuts. +**\** Hmm ok +**\** You asked me to review this earlier, and it completely slipped my mind +**\** I'll look for the code snippet you sent in PM +**\** to ensure I don't get wrong the terms you're referring to +**\** ty +**\** sgp\_: did you have something you wished to discuss too? +**\** I don't believe so +**\** Well, this meeting is turning out to be quite short :D +**\** moneromooo: anything specific, aside from the reuse question you posed? +**\** (to discuss here, I mean) +**\** Not at the moment I think. +**\** OK, I suppose we can move right along then +**\** to 3. QUESTIONS and 4. ACTION ITEMS +**\** While suraeNoether continues working on matching/churn via MRL-0011, I have several things for the week +**\** Now that CLSAG reduction to LSAG is proving so problematic, I want to see if definition modifications for the LSAG proofs will suffice for our use case +**\** I'll be checking on moneromooo's question shortly (apologies for letting that slip by) +**\** as well as more work on Lelantus transaction flows +**\** sarang: Have you consulted RandomRun regarding this problem btw? +**\** suraeNoether and I have been in contact with him throughout the development process +**\** I don't believe this problem has practical effects on CLSAG's security, only in the complexity of the formalization +**\** Any other questions or action items on people's minds? +**\** I see, so it does not render the scheme infeasible? +**\** Heh, depends +**\** If we end up not being able to prove secure under proper definitions, that's a bit of a quandry +**\** but in the worst case, we decide not to adopt the scheme, and are right back to where we are now +**\** True, better safe than sorry I guess :p +**\** However, the space and time savings are so compelling that it's worth the effort +**\** ~25% space savings and 15% time savings for a 2-2 transaction +**\** (in the signature portion) +**\** Not bad +**\** OK, any last questions before we formally adjourn? +**\** Righto, in that case, we are adjourned. Discussion can of course continue +**\** Logs will be posted shortly to the GitHub agenda issue