--- layout: post title: Logs for the MRL Meeting Held on 2020-02-19 tags: [dev diaries, crypto, research] author: asymptotically / Sarang --- # Logs **\** OK, let's get started with the meeting **\** GREETINGS **\** hello :) **\** Hello **\** I caught the meeting! **\** I would like to note that the meetings are not listed in the calendar **\** idk if thats intentional **\** Which calendar? **\** Hi **\** And how are meetings applied to it? **\** Hi **\** Meeting times/agendas are always listed as meta repo github issues **\** Anyway, does anyone wish to begin the ROUNDTABLE with research topics of interest? **\** Yes **\** Take it away UkoeHB\_ **\** I finished designing an escrowed marketplace 'protocol' which hopefully solves issues encountered by rbrunner in his openbazaar integration analysis. Also, multisig and txtangle have been finalized. **\** https://www.pdf-archive.com/2020/02/19/zerotomoneromaster-v1-0-28/zerotomoneromaster-v1-0-28.pdf **\** Neat **\** Finally, I had an idea for reducing minimum fee variability, and likewise for putting antispam directly in the protocol instead of relying on minimum fee **\** Are you seeking analysis on those? **\** Which is issue #70 **\** They are open for comments any time anywhere **\** Ah and sarang provided a draft for a tx knowledge proof chapter **\** aye **\** (not really my research :p) **\** Heh, it's more of a summary of what's in the codebase (and some changes) **\** I look forward to reading the update draft you linked **\** A number of topics here are lonely and want attention btw https://github.com/monero-project/research-lab/issues **\** \end **\** Thanks UkoeHB\_ **\** Any questions or comments on those topics from anyone? **\** Yes **\** Please go ahead! **\** I have taken a look at issue 70 **\** It actually has serious implications **\** When the LT medium increases substantially **\** I do have an idea for a solution **\** Very preliminary at this stage **\** As for an interim fix **\** The est is to pay the high or at least normal fee for escrows that are expected to last past the next hard fork **\** I will have comments on the issue in the next two weeks **\** end **\** Thanks ArticMine **\** Any other questions/comments from the topics presented by UkoeHB\_? **\** Righto **\** I'll share a few things **\** First, the Stanford Blockchain Conference is happening right now (and the next couple of days), and has streaming available: https://cbr.stanford.edu/sbc20/ **\** Second, I did some math/code related to multiparty stuff for next-gen protocols **\** Third, I worked on code and write-ups for transaction proofs, both for an updated PR and for inclusion in Zero to Monero for better documentation **\** Fourth, I used chain data from n3ptune and friends to do better estimates of the cumulative effects of next-gen protocols **\** both in chain growth and verification time **\** Major caveat: these assume the same input/output distribution as the current chain, and are \_estimates\_only\_ **\** and apply to post-bulletproof chain data only **\** https://usercontent.irccloud-cdn.com/file/ijaEAI7m/size.png **\** ^ this link shows the total chain growth estimates for various protocols with varying ring size **\** namely, from 16 to 1024 in powers of 2 (lines for visual aid only) **\** Sarang would you mind adding an indicator for MLSAG and CLSAG at the 11 ring size 'point'? For reference **\** Sure, let me grab that data from my spreadsheet **\** hold please **\** Or the super steep slope from 11 to 20 lol that goes off that chart **\** Heh, I had that data but didn't include it since it's crazy linear **\** I'm running the N=11 code for MLSAG/CLSAG, which I don't have handy **\** Anyway, I'll pull up the time data while we wait **\** https://usercontent.irccloud-cdn.com/file/T7uWoFEp/time.png **\** ^ verification time estimate for \_group\_operations\_only\_ at varying ring sizes **\** I think it's interesting that all these protocols/signature schemes are similar size on the small end **\** All the verification times are linear (up to a logarithmic term due to multiexp) **\** Where is tryptich multi hiding? **\** It's underneath Triptych-single **\** They're essentially indistinguishable **\** Does Triptych single have advantages over multi? **\** RCT3-multi suffers due to input padding requirements that still have a linear verification effect **\** selsta: a complete soundness proof :) **\** Update on MLSAG/CLSAG size estimates... **\** Could you make a smaller graph from 0 to 128 ring size? Since those large ones seem pretty unreasonable **\** At N=11, MLSAG for that chain range is 7.84 GB, while CLSAG is 5.84 GB **\** (the actual size of that chain range is 7.9 GB) **\** https://usercontent.irccloud-cdn.com/file/DFhClmEe/time-small.png **\** ^ same time data, zoomed in **\** Perfect thanks :) are time estimates for CLSAG/MLSAG available? **\** Heh, just writing that out **\** I have very early estimates on that, which are tricky since multiexp doesn't apply, and hashing is nontrivial **\** MLSAG N=11 estimate is 29.9 hours for that chain range (but I have \_not\_ double-checked it) **\** What hardware was used for the verification time calculations? **\** It's a single core on a 2.1 GHz Opteron machine, with a bonkers amount of RAM **\** I would rely on the timing data only for comparisons, not absolute values **\** age of CPU? **\** I am still in the process of getting CLSAG data, which requires additional test code **\** It's a gen-3 Opteron, if that's what you mean **\** Is there a way others could run the same tests? **\** Again, only estimates using performance test code **\** For next-gen protocols, it's quite easy **\** Yes great it does give an idea thanks **\** Well, somewhat easy **\** You need to get multiexp performance timing data and use a linear interpolation that you plug into the simulator **\** For MSLAG/CLSAG you need to run more operation performance data **\** This is the simulator, which is still WIP: https://github.com/SarangNoether/skunkworks/blob/sublinear/estimate.py **\** https://usercontent.irccloud-cdn.com/file/HuPcfLdT/image.png **\** But again, it's tricky to do comparisons between MLSAG/CLSAG and the next-gens **\** (drive by data) **\** Wow, that's quite low **\** Oh yeah, the numbers are one thing. But moreso, we should all be more alarmed that analyzing something like this is possible for an outside observer **\** ;-) **\** Yep, and has certainly been a topic of interest! **\** It's a privacy risk to use subaddresses right now... **\** Anyways, I gotta bounce, sorry to spam n run **\** OK thanks for sharing the data Isthmus **\** Another good reminder that I/O structure reveals some information about subaddress use **\** Since Isthmus had to leave, were there other questions/comments on the data that I shared above? **\** UkoeHB\_: if you want to run tests as well, let me know after the meeting and I can let you know how to get the numbers you'll need **\** My computer is quite weak, was just asking for viewers :) **\** sarang: can you remind us on the plans to fix this subaddress thing? **\** ah ok **\** Requiring separate tx keys per output is a good idea, but IIRC didn't have a huge amount of support when last brought up **\** FWIW the size data that I presented for next-gens assumes a separate tx key per output **\** Is that necessary for the protocols? **\** For the proving systems, you mean? No, not at all **\** They don't care how you get signing keys **\** Can you estimate the amount of additional pub key data? Num outs \* 32 and num tx \* 32? **\** sarang: why did it not get support now? complexity? size? verification time? **\** My numbers for MLSAG/CLSAG include separate tx keys too! **\** Also: n3ptune's dataset includes the pubkey counts **\** So I could run that separately for a more direct count **\** With only 3% subaddress adoption, the difference is likely on the order of 100MB **\** Or 2% of total size I think **\** that's probably a good order-of-magnitude estimate **\** But IIRC scanning requires checking all pubkeys **\** So either there needs to be a specified correlation, or there's added complexity in scanning **\** I think it costs ~1GB for 30mill pub keys btw **\** I think moneromooo had a better idea of the impacts, when it was brought up earlier **\** FWIW I think it's a good idea unless it's very compelling not to due to complexity **\** OK, we're running up to the one-hour mark... **\** obviously without this change, the impacts are quite negative for network privacy........ **\** It's differentiated data, but it doesn't leak \_which\_ outputs are subaddress-destined **\** (not that I'm saying that's a good reason to keep the current approach) **\** It's quite a lot of unused data, I'm a bit skeptical **\** just reveals "one of this outputs goes to a subaddres?" **\** UkoeHB\_:? **\** A lot of dummy data **\** sgp\_: it reveals the number of subaddress outputs **\** sarang all it reveals is at least one of the outputs must be to a subaddress **\** Doesn't it reveal the total number of sub outs? **\** No **\** orly **\** How would it? **\** Number of additional pub keys always equals number of outs **\** Even if nonsubaddress **\** How is the CLSAG paper going? **\** Hmm, for some reason I thought otherwise; noted **\** I'm still waiting for suraeNoether **\** He wanted to continue working on his ideas for the security model **\** So unfortunately I am not the one to ask **\** OK, is there anything else of interest to share? **\** (Would be a good idea to continue discussing this after meeting, or on an issue, to keep it alive) **\** definitely need an issue for it **\** All righty then; thanks to everyone for attending today **\** We are adjourned!