--- layout: post title: Logs for the MRL Meeting Held on 2020-02-12 tags: [dev diaries, crypto, research] author: asymptotically / Sarang --- # Logs **\** Greetings! **\** Hi **\** Hiya **\** Hello **\** Thanks selsta I'll look **\** I suppose we can move to roundtable discussion **\** Who wishes to share interesting research? **\** hello **\** Something quick from NRL **\** We've been looking at some results regarding the extra field in transactions. We have one thing to share today **\** Here is an analysis of Payment id usage since v10 when unencrypted payment ids were deprecated: **\** https://usercontent.irccloud-cdn.com/file/Xf1uZRsZ/image.png **\** (Sorry there is an uncorrected typo: "Unencrypted Included x Encrypted Absent" should be 232980 (not 232972) and "Unencrypted Absent x Encrypted Included" should be 1904765) **\** ^ moneromooo etc. **\** It's actually not 'mandatory', just part of the core wallet's behavior **\** As jtgrassie liked to insist :p **\** Nothing stops a wallet from simply including a fixed default value either **\** (can't enforce "uniformly random" in that way) **\** Once again touches on the idea of extra parsing/enforcement **\** Are there other indications of what non-standard software it might be? **\** 17% is a good amount that didn't update properly **\** do they save slightly on fees? **\** That's a good question, we didn't look into the transactions but there may be other things going on that make more of a fingerprint **\** Thanks n3ptune **\** Thanks! Just sharing these numbers today **\** if the fees are lower, I can see someone setting it up this way if they process many transactions **\** Looking at long payment id usage since 1.7e6 is a bit pointless. What is it from 1.98e6 ? **\** I can check **\** n3ptune: the core wallet only creates encrypted payment IDs for all 2-output tx, would you mind looking into the distinction (proportion encrypted IDs with 2-output and \>2 output)\> **\** moneromooo: was the dummy encrypted payment ID also since 1.98e6? **\** Another good question **\** I think before. **\** It was merged late january 2019. **\** Yes, it was included in the release for that height. **\** I don't think we looked at long PID **\** Sorry, here is the updated figure **\** https://usercontent.irccloud-cdn.com/file/t5ozuruh/image.png **\** ? Long PID = Unencrypted PID, yes **\** Yes. **\** Oh, I was thinking integrated **\** Sorry, on 4 hours of sleep, no coffee, and in presentations at a crypto compliance company all morning **\** But they're cool with me being half in MRL, obviously they've been pretty supportive of my research over the past year :- ) **\** How ominous **\** it might just mean more significant implementations exist than just core, which might be good news also **\** Well, not if the result is fingerprinting **\** n3ptune: also, afaik coinbase transactions do not use payment IDs (a round 200k tx over that period) **\** The numbers should be for non-coinbase only **\** Well, in the interest of time, shall we continue? Hopefully we can get more detailed data, which can help any future decisions about parsing **\** Thanks for the data Isthmus and n3ptune **\** Thx, I'll check out those questions **\** Other research to discuss or share? **\** UkoeHB \_ ? **\** suraeNoether ? **\** OK, I can discuss a few short items **\** ok, I sketched out a light node proposal https://github.com/monero-project/research-lab/issues/69 pls leave your thoughts there if interested **\** Ah ok, nvm **\** go ahead UkoeHB\_ **\** ZtM2 I got through multisig and the draft of that chapter is done, started working on escrowed marketplace chapter which will be done by next meeting https://www.pdf-archive.com/2020/02/12/zerotomoneromaster-v1-0-25/zerotomoneromaster-v1-0-25.pdf **\** thats all from me **\** @UkoeHB\_ just scoped that proposal last night, looks like great stuff **\** Looks to be similar to SPV structure? **\** possibly, idk anything about SPV **\** I worked out data storage inside RCT3 proofs (both single- and multi-input) as well as storage in multi-input Triptych **\** Finished code and tests for new transaction proofs **\** did some Dandelion++ review **\** yay triptych! **\** Wrote some code to demo spend/non-spend status proofs that have been discussed previously **\** and overhauled the Omniring/RCT3/Triptych key image multisig construction protocol **\** Any size indications for triptych? **\** Individual transactions? Sure, that's been available for some time **\** https://github.com/SarangNoether/skunkworks/blob/sublinear/triptych.md **\** Now that I have I/O structure data from n3ptune, I can run some chain-wide estimates based on that **\** since different tx protocols imply different tradeoffs as I/O structure changes **\** It seems to me a move in the reference tx size from 3000 bytes to 4000 bytes would be needed **\** Which is very reasonable given the mixin privacy gains **\** why increase? **\** It depends on what protocol (if any) is chosen, what parameters used, etc. **\** ah i see, for 1024 ring size **\** I am saying with N = 512 or 1024 **\** what are the hurdles for tryptich? besides me wanting to spell it wrong all the time **\** If this goes through, by the time it makes it to the main chain the drop in block reward would easily cover the fee increase **\** If we increase the penalty free block weight to 400000 bytes **\** gingeropolous: no peer review yet **\** I also need to know the practical drawbacks to the more complex multisig operations **\** especially on lower-powered devices **\** They'd need to support Paillier encryption/decryption for multisig with any of the sublinear protocols **\** We must also keep in mind this is less than a year of Nielsen's Law of Internet Bandwidth **\** ugh. what, for those silly hardware wallets? **\** Well, anything that would need to participate in multisig **\** The process involves doing peer-to-peer Paillier operations, some Schnorr and commitment stuff, etc. **\** would multi-tryptich work with any kind of join protocol? **\** Unclear. It's still in the early stages **\** before this meeting gets wrapped up, I am curious about the state of discussion around Monero's difficulty algorithm; zawy12 seems to have done a lot of research on the topic of difficulty algos https://github.com/zawy12/difficulty-algorithms/issues/50 **\** and suraeNoether was at one point doing research on that area **\** apparently Monero's algorithm is quite bad, relatively speaking **\** Interesting; I had seen some of their earlier work, but not this summary **\** The conclusion seems to be that the potential oscillations would be of much greater importance for uses with large mining variance **\** (which isn't really part of the design choice) **\** Worth a read, now that we have the link **\** UkoeHB\_: did you want to discuss extra sorting, given its relationship to the information from n3ptune and Isthmus? **\** I feel Ive made my case for it, although Isthmus says they are working on a big comprehensive report so at that time I may recapitulate **\** Fair enough. Trying to enforce better uniformity and order is a good idea, so I agree **\** It may come down to questions of efficiency and "someone needs to write it", but who knows **\** enforcing it should be less than 100 lines of code IMO **\** Sounds like someone is volunteering :D **\** Anyway, there is a Konferenco meeting starting presently, so any final comments or thoughts before adjourning? **\** Righto; thanks for attending, everyone