--- layout: post title: Logs for the Monero Research Lab Meeting Held on 2018-07-30 summary: Sarang work, others work, and miscellaneous tags: [community, crypto, research] author: el00ruobuob / sarang --- # Logs **\** We can start now **\** Greetings **\** This will be a brief meeting to catch up on recent research **\** All bulletproof audits have completed **\** Kudelski's final report is posted. QuarksLab is updating theirs with our responses before releasing their final version. Benedikt Bunz is updating his similarly with our feedback. **\** yaay **\** I continue to work on some new ring signature algos from Ruffing et al. **\** very nice, excited to read the most recent reports **\** lots of fun building blocks with that scheme **\** and suraeNoether has provided a multisig paper for me to review **\** that is also in progress **\** any questions on these things in particular? **\** let's collaborate on that I have an implemaentation on the first paper version **\** C, openssl **\** silur: sure, the initial parts of the prototype are on my repo, rupol branch, in python **\** been working on rtrs for a long time **\** okay, will write you after the meeting **\** anything in particular to share regarding your rtrs silur ? **\** well we just have to update it to the new-new-new construction **\** I only have the unpublished internal version of the first paper **\** righto **\** We shall talk afterward **\** Any other interesting work to be shared? **\** anyone see a problem with running openssl transpiled via emscripten in a browser? **\** I feel extremely not qualified to answer that properly **\** endogenic: openssl, transpiling, emscripten, and browsers are all bad for security **\** yep, no worries, just throwing it out there **\** lol **\** then why does monero use it lol **\** where? **\** monero is writtcen in C++ **\** common/util.cpp (LOL) #include ... ringct/bulletproofs.cc #include ... **\** yea but where do we transpile it with emscripten? **\** just asking **\** I don't really recommend that **\** any specific reason? **\** don't know about emscripten internals but we used to have a thing called openssl code health tuesdays **\** after a month we eliminated 40K dead lines and 8 dead platforms **\** I think that's a reason not to include it in browsers **\** emscripten handles that sort of stuff **\** there are lots of reasons that projects might have an openssl dep (bitcoin had one for a while). it takes time to eliminate it as other options are developed **\** also it has lots of inline ASM stuff how does emscripten handle that? **\** but in all seriousness, if you're doing crypto in a browser, you should stop, because it's snake oil. a browser cannot run code in a secure environment. **\** Did anyone check out the paper I posted last week? **\** https://arxiv.org/abs/1702.07588 **\** http://matasano.com/articles/javascript-cryptography/ **\** andytoshi: people are going to run worse web wallets if we don't **\** run one that is **\** I'm curious if FHE can be used for remote node syncing, to allow us to make queries on encrypted data **\** silur: 1sec **\** needmoney90: you want PIR for that, not FHE. and there are existing PIR primitives that are actually implemented and usable (see percy++) **\** It's possible that due to our static append only data set that we can't actually hide access patterns **\** needmoney90 thanks a lot, it seems super interesting **\** Never heard of PIR, got a paper for me? **\** Maybe I just don't know the acronym **\** private information retrieval **\** lots of stuff on PIR **\** thanks for percy++, i'm working with pir a lot for riffle **\** where do we need that btw? **\** in monero? **\** silur: emscripten might not be able to handle it, depending on exactly what's there. i guess maybe an alternative implementation exists **\** people seem to have been able to do it , in any case **\** 🤞 **\** is boringssl an option for you? **\** oh **\** ./configure --no-asm **\** of course **\** oneiric\_: not to ignore you - i'll investigate if it becomes necessary **\** Anyone else wish to share something intriguing on their minds? **\** Also welcome andytoshi **\** Oh, I can give a #noncense-research-lab summary **\** please **\** Lots of action in the Monero Archival Project this week. @n3ptune released a new version of our custom archival daemon, and @serhack has been working wonders, configuring and maintaining our network of global VPS-based nodes. **\** I have been playing around with temporal analysis of the blockchain. Miner-reported timestamps were shown to be very unreliable, since 2% of blocks include a timestamp that is \*before\* the timestamp of the block prior. **\** These time-traveling Merlin blocks showed up while scoping out the distribution of wait times. https://usercontent.irccloud-cdn.com/file/tLUEZ9aU/ttblocks.png // Looking at the wait times for the block above and below the Merlin blocks themselves, we see that it is skewed toward a longer interval afterward, suggesting that they are actually being retroactively timestamped. **\** Our new daemon (upgraded last night) records the node-receipt timestamp(s) in addition to the miner-reported timestamp, so expect some way more detailed analysis of that soon. **\** I'm a little exploratory study of how fast the blockchain syncs at each height. It's mostly a cute novelty, but if there are interesting features (e.g. discontinuities around introduction of new tech), or notable conclusions about empirical scaling, I'll share back here. **\** (/end) **\** Whoops, here's the second link, showing the skew in wait times before and after Merlin blocks: https://usercontent.irccloud-cdn.com/file/f46p6Ddd/merlin\_parent\_child **\** this is very interesting work **\** sarang: we've made a lot of progress on musig recently; you can see https://github.com/apoelstra/secp256k1/blob/2018-04-taproot/src/modules/musig/musig.md for our current API. may have insights valuable to monero in future when you guys support arbitrary multisigs **\** oh excellent, thanks **\** Shoot, I gave the wrong channel above. #noncesense-research-lab **\** andytoshi: what are the overall plans for musig? **\** sarang: well, musig signatures verify identically to schnorr.. **\** so the goal is for bitcoin to support schnorr as part of taproot **\** and then wallets would implement musig if they're doing multisig stuff **\** since the resulting multisigs would be smaller/more private than ones using CHECKMULTISIG **\** Great, so laying the groundwork for future wallet code **\** cool **\** It seems fairly quiet here otherwise today, so any other material to share? **\** not really, i've mostly been doing rust-bitcoin ecosystem work **\** yknow people have been transpiling rust to JS too :P **\** and wasm :D **\** well that's what i mean :P **\** wasm openssl is not a bad idea tho **\** looks like I have a new sideproject **\** oh that's just what i'm talking about... **\** whoever beats the other to it i guess **\** it's easy enough **\** i have instructions.. :P **\** i have boost transpiled already.. **\** Well, I think we can safely call the meeting then, everyone can continue performing admirably