The whole fourty-five missing MRL meeting logs

+ corrections after testing
parent 0f25ac80
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2017-10-09
summary: Announcements, Round table discussion of projects, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<surae>** Okay, everyone, welcome to our first MRL Research meeting!
**\<endogenic>** yay!
**\<surae>** Agenda, I guess, will be 1) Greetings, 2) Announcements, 3) Round table discussion of projects, 4) anything else that anyone else can think of
**\<surae>** So, greetings!
**\<hyc>** hello
**\<surae>** As far as announcements go, I'll start with the usual: Next week at this time, we'll have office hours, where people can come in and just ask whatever questions they like. Monday 17:00 UTC. Then we'll be alternating Mondays
**\<surae>** between research meetings and "office hours"
**\<surae>** i can't think of any other announcements...
**\<surae>** sarang? anything?
**\<surae>** Okay, moving along I guess
**\<surae>** For project discussion...
**\<surae>** Personally, I've been working on multisig. Sarang and I had some basic security definitions nailed down when he came out to visit. Unfortunately, a paper that mustn't be ignored came out by Boneh and co-authors...
**\<surae>** https://eprint.iacr.org/2017/956.pdf
**\<surae>** That paper presents a new scheme that is not directly relevant to us (although it may be in the future) but importantly it defines several security models
**\<endogenic>** How lucky it came out at the same time...?
**\<endogenic>** ;)
**\<surae>** one of the security definitions Sarang and I came up with is actually a stronger definition than the one in that paper
**\<endogenic>** Of course
**\<surae>** so, it seems as if we are on the right track, if someone like Boneh is thinking about similar problems
**\<surae>** There are some implementation issues in my description also; the current draft is here: https://www.sharelatex.com/project/5980a44556789660b0600edb
**\<hyc>** sounds like their paper is applicable both to multisig and the ever-popular trusted setup
**\<sarang>** Sorry here
**\<surae>** hyc tbh i haven't gotten deep into their homomorphic-specific stuff, so i have very little idea. i'm very interested in their security definitions, though
**\<surae>** welcome~
**\<endogenic>** Should we mention ppl like mooo at the beginning of mtgs?
**\<surae>** oh good idea
**\<endogenic>** Per multisig
**\<surae>** moneromooo knaccc luigi1111 fluffypony anonimal dEBRUYNE
**\<sarang>** So yes multisig is coming along well
**\<sarang>** Subaddress paper is done
**\<sarang>** That was posted as a final draft to the channel for comment
**\<sarang>** And is ready to go to Reddit etc
**\<surae>** yes, Subaddress paper will now be MRL-0006, will be pushed to my github in a bit here and then i'll issue a pull request to the monero-project
**\<surae>** send us a link real quick sarang
**\<surae>** i'd be happy to have folks read over it one more time
**\<surae>** is anyone else doing anything research-y? learn something new? anyone working on a project?
**\<sarang>** https://github.com/b-g-goodell/research-lab/blob/master/publications/bulletins/in-prog/MRL-9999-subaddy/MRL-9999-subaddresses.pdf
**\<sarang>** I am updating myself on some aggregator constructions
**\<sarang>** And based on the Green tweet, I'd like us to do an analysis of our use of PRNGs
**\<hyc>** I have nothing crypto-related to offer. been benchmarking DB engines lately. (LMDB still fastest.)
**\<surae>** i'd be very interested in hearing from xpto also, since he's working on some LN stuff, and anonimal, since he's dealing with RSA I guess for kovri? knaccc is probably catching up in his RL from spending weeks programming RuffCT/StringCT/RTRS RIngCT
**\<surae>** hyc can you link me a primer for LMDB? i know precisely zero
**\<hyc>** https://symas.com/lmdb/technical/#pubs
**\<surae>** nice thanks
**\<endogenic>** i've been curious if there's a simpler implementation of i2p possible
**\<endogenic>** and i'm just wondering (blindly) about revocable view keys
**\<surae>** i am excited to start thinking about those more deeply. multisig is...
**\<hyc>** ah, the notion of time-limited/expiring view keys sounds like a good idea
**\<moneromooo>** Sorry, I was out.
**\<surae>** yes
**\<surae>** no problem mooo, i didn't ping anyone before we started (my bad, first time here yuk yuk)
**\<endogenic>** hyc: i've heard some downsides to proposals of time-expiring view keys
**\<surae>** multisig is more delicate than i thought. thing is, i'm pretty sure that our current implementation is safe enough to roll with (pending sarang's agreement, maybe). problems abound, though
**\<endogenic>** nm90 had some concrete ideas on it
**\<endogenic>** problems?
**\<surae>** the problems aren't huge. it's like "well, if an adversary uses a side channel attack and listens in on this computation here, the adversary may be able to determine whether a certain key is a shared key or not, so these here should be communicated with encryption" and so on and so forth. since the security of keys in that way is far less important than being unable to go backwards and determine the
**\<surae>** participating private keys, stuff like this isn't a huge deal
**\<surae>** little... details. that keep building up.
**\<surae>** so, i'm going to take a day or two off of it and work on other things, to reset my brain. it's been a few days of just multisig. Pending sarang's agreement on the multisig code being "safe enough," multisig can be put to work before the MRL-0007 paper is put out, though. Two reasons for this
**\<sarang>** A lot of it is about assuming things about communication of coalition members
**\<surae>** First, even if multisig satisfies weaker security definitions than i would like, we can always push changes to it later. Second, I'm already proposing a slightly different implementation in the paper than we are currently going to see in the code. I'm considering writing an appendix to this paper that compares the current code by moneromooo with my suggested implementation, and attempts to close the gap
**\<surae>** between them.
**\<surae>** so, anyway, i'll probably take two days off and think about blockchains or specter or difficulty or something
**\<sarang>** Now what about this PRNG bizniss?
**\<moneromooo>** Monero's PRNG is not homebrew, AFAIK it's the canonical construction from the Keccak authors.
**\<surae>** ?
**\<surae>** Our PRNG should follow whatever the best practice is. I'm not convinced NIST or ISO are the ones who describe the best practices. maybe we should have our own standard for that
**\<sarang>** I'd like to understand it a bit better
**\<sarang>** Especially since the issue was raised last year and kinda died away
**\<surae>** either way, identifying where the PRNG as-is currently influences stuff that actually hits the blockchain seems to be a no-brainer sort of thing to do anyway
**\<hyc>** https://www.deepdyve.com/lp/institute-of-electrical-and-electronics-engineers/software-only-extremely-compact-keccak-based-secure-prng-on-arm-cortex-QsZRJs71MZ
**\<surae>** I also want to vet this spectre paper. I'm suspicious of outlandish claims.
**\<surae>** Thanks hyc
**\<hyc>** also https://keccak.team/files/SpongePRNG.pdf
**\<hyc>** afaics it's already heavily studied
**\<surae>** that's interesting. i'd be very interested to have a conversation with Green
**\<surae>** maybe i'll shoot him an e-mail
**\<surae>** i also want to meet an economist
**\<endogenic>** ArticMine might be able to help you there surae
**\<surae>** for ASIC and POW discussions. i need to learn about the game theoretic dynamics behind commoditizing hardware, decentralization, renting, etc
**\<surae>** nice
**\<surae>** Okay, so in the next two weeks: progress on multisig expected, i want to vet the spectre paper, sarang is learning about accumulators lacking a trusted set-up, hyc will presumably continue playing with DB engines
**\<hyc>** ;)
**\<endogenic>** surae will take a short vacation
**\<surae>** Oh
**\<endogenic>** ... right??
**\<sarang>** Aye
**\<surae>** actually, yes, i need sleep and it just snowed for the first time
**\<surae>** i need a weekend
**\<surae>** hard to separate work and life
**\<sarang>** Other issues of interest?
**\<surae>** oh, and since we are having this public discussion right now
**\<surae>** RTRS RingCT: we've concluded that pretty much any improvement in signature verification time will lead to exponentially bigger rings for the same blockchain size.
**\<surae>** on the flip side: any increase in verification time will lead to exponentially smaller rings
**\<surae>** this is a property of any logarithmically sized ring sig scheme
**\<hyc>** "lead to bigger" -> "enables using bigger" ?
**\<surae>** yeah, for the same blockchain size
**\<hyc>** ok
**\<surae>** since RTRS RIngCT is log-sized and has comparable verification time compared to MLSAG, it's not feasible to implement them unless we can make them faster to verify than MLSAG. If they are as fast or slower, they aren't worth switching to
**\<surae>** and i believe vtnerd benchmarked sandy2x and it was freaking fast
**\<hyc>** faster than MLSAG?
**\<surae>** well, sandy2x is just an EC arithmetic implementation
**\<surae>** so boht MSLAG and RTRS RingCT would be faster
**\<hyc>** ok
**\<surae>** i believe he got around a 15% improvement in EC arithmetic time, which would lead to around 15% faster verifciation time
**\<surae>** which would allow us to have a fixed min ring size of 10!
**\<surae>** not 10 factorial
**\<surae>** but 10
**\<surae>** we could possibly even get away with a ring size closer to 32 or something like that
**\<hyc>** so RTRS RingCT is still viable, not dead. good to know
**\<surae>** now, knaccc had me contact some folks who did some GPU otpimization for EC
**\<surae>** and their code also speeds up CPUs because it's so optimized
**\<surae>** for Curve25519
**\<surae>** they are eager to help us try to impement it, though, their emails show a lot of enthusiasm, and I didn't even ask for assistance or anything
**\<surae>** so, i'm going to pursue that further in the next two weeks also
**\<hyc>** excellent
**\<surae>** i kind of wanted all that "on the record" so to speak
**\<surae>** I can't think of anything else for now.
**\<surae>** sarang, anything?
**\<sarang>** Negatory
**\<surae>** allrighty, well
**\<sarang>** Keep up the good fight?
**\<surae>** yep
**\<sarang>** We can talk PRNG after
**\<surae>** and if anyone reads any papers on forward-secure key exchange that may be helpful for revocable view keys, send them along!
**\<surae>** yep, we can call this meeting \*over \*
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2017-12-18
summary: MRL work, MRL 2018 forecast, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<suraeNoether>** okay, everyone, I suppose we can start this research meeting
**\<suraeNoether>** 1) Greetings, 2) What has everyone been doing? 3) What should 2018 look like for MRL, in your opinion?
**\<andytoshi>** btw if i got a reviewer to look at the bp stuff (hypothetically) who wolud i ping about security issues
**\<suraeNoether>** andytoshi: I think sarang
**\<moneromooo>** And luigi1111w.
**\<suraeNoether>** luigi1111w and moneromooo would also be good contacts
**\<suraeNoether>** \*nod\*
**\<suraeNoether>** So, hi everyone. sarang anonimal ArticMine dEBRUYNE endogenic gingeropolous JollyMort[m] pigeons othe silur stoffu unknownids vtnerd waxwing
**\<suraeNoether>** I know sarang is moving so he may or may not be active this morning
**\<suraeNoether>** Sarang and I are finishing up the multisig paper and then we'll be shopping it around to get thoughts from community members
**\<sarang>** Hello
**\<suraeNoether>** howdy~
**\<sarang>** andytoshi: yeah any reviews could contact me
**\<suraeNoether>** We have also been reading about the new untrusted-set-up zk-snark paper. I'm particularly interested to see if BPs can be dropped into that scheme.
**\<sarang>** [email protected] is a good way to contact more privately
**\<silur>** or darkwire.io for realtime
**\<sarang>** suraeNoether: yes, there is a particular inner-product argument they use
**\<silur>** surae you talking about hyrax?
**\<sarang>** yes
**\<suraeNoether>** silur yes
**\<silur>** I will most likely be responsible for ZoKRates implementation
**\<suraeNoether>** oh, at ethereum?
**\<silur>** chris and vitalik seem to be too concerned about scalability
**\<silur>** yea
**\<silur>** but IMO hyrax witness size etc totally worth for kicking trusted setups
**\<sarang>** It's certainly worth our looking into
**\<sarang>** And I've found the paper to be quite good
**\<sarang>** very solid lit review too
**\<silur>** it's amazing
**\<suraeNoether>** I don't care so much about sizes, I care more about validation times under the conditions we've been considering recently
**\<sarang>** They explicitly consider validation complexity
**\<suraeNoether>** yep
**\<sarang>** which is a welcome addition
**\<silur>** well hyrax is highly parallel
**\<sarang>** mhmm
**\<silur>** should be many times faster on first sight then simple Groth
**\<sarang>** Very dependent on circuit parallelization
**\<silur>** but haven't actually made any tests on that
**\<silur>** I also got my attention on this
**\<silur>** http://arxiv.org/abs/1712.04417v2
**\<silur>** quite relevant on sharding, decentralized storage etc
**\<sarang>** oh interesting
**\<suraeNoether>** In addition to the authentication end of things, Sarang and I have also been working on an implementation of SPECTRE, the blockchain concencus algorithm here: https://eprint.iacr.org/2016/1159.pdf
**\<sarang>** Yeah, constant time implementation of SPECTRE is quite interesting
**\<silur>** wow
**\<sarang>** Hinted at by the authors but not explicitly considered in the paper
**\<suraeNoether>** My current constant-time implementation is on my github here https://github.com/b-g-goodell/research-lab/tree/in-prep/source-code/Spectre <--- it does not match the current SPECTRE algorithm so that it can operate in constant-time, but there are also some design choices I'm tinkering with in the original SPECTRE algorithm...
**\<suraeNoether>** and, it doesn't pass unit tests yet (with or without the aforementioned tinkering)
**\<suraeNoether>** but this appears to be the first implementation of spectre anywhere
**\<sarang>** The unit tests are tricky with this
**\<sarang>** Because the voting gets so complex very quickly
**\<sarang>** and suraeNoether you found it doesn't always match intuition
**\<suraeNoether>** Spectre uses insanely high block arrival rates, so I've been doing computations to maximize privacy (ring size) and transaction processing rate subject to a constraint of getting some minimum gain in new node sync time.
**\<suraeNoether>** i plan on using values from RTRS ringCT (or RuffCT), MLSAG signatures, borromean range proofs, and bulletproofs to determine what sort of rates we could rationally use in spectre while maintaining network security. I wouldn't mind throwing the new zk-snarks in there also
**\<suraeNoether>** I've also attained some recent proofs into why some ideas I was previously researching just fundamentally aren't going to work
**\<suraeNoether>** for example, in terms of Proof-of-Space, I am giving up the ghost for a few months or more, because one critical property of block validation is that it can't have \*progress\* like a progress bar. otherwise, the fastest/strongest always wins the next block.
**\<suraeNoether>** and i think that PoS will tend toward a progress-bar-like block validation mechanism
**\<suraeNoether>** a few other ideas I had can't work like that
**\<suraeNoether>** i'm literally thinking of writing a blog post entitled "Apparently clever but inarbuably bad ideas for cryptocurrencies."
**\<suraeNoether>** silur keep us informed on how Zokrates comes along
**\<suraeNoether>** anyone else doing anything interesting?
**\<sarang>** I'm enjoying zkSNARKs and SPECTRE and tweaks to BP efficiency and review
**\<sarang>** and helping out w/ multisig review, which has gone well
**\<sarang>** I'm moving this week and trying to balance that as well
**\<suraeNoether>** Allrighty for 3) a few things. Firstly, i think we are going to follow the cue of #monero-dev meetings and postpone our next meeting. I'm going to say Monday Jan 8 (perhaps Mon the 1st is cruel). Secondly, for research meetings each week, perhaps sarang or I can present a paper we had read the previous week and try to describe how it works to the community.
**\<sarang>** Ha just like a real lab group meting
**\<suraeNoether>** ikr
**\<suraeNoether>** but moreover
**\<suraeNoether>** I want to know how everyone feels about the direction MRL should head in 2018
**\<sarang>** As long as it doesn't turn into a Buzz Killington event: https://www.memecreator.org/static/images/memes/4440318.jpg
**\<suraeNoether>** eh, this conversation could wait until our next meeting, I think.
**\<unknownids>** ooo lab group https://i.imgur.com/ehgxi9o.png
**\<suraeNoether>** oh man it's meme time, meeting adjourned ~ hehe
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-02-26
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<suraeNoether>** Okay, well let's get this research meeting started, I guess.
**\<suraeNoether>** Greetings everyone who is here. :P I'll make this easy and quick: I'm working on multisig furiously, working my way into migraines so I can get it done, so i haven't thought much about much else except churning and the EABE (or more precisely the EAE) attack. I thought I would be done this morning, but I was put out of commission yesterday afternoon. so maybe this afternoon.
**\<suraeNoether>** sarang: what have you spent the last week on?
**\<suraeNoether>** diego[m], sgp\_[m], chachasmooth\_, silur, I believe have all been doing some work over the past few weeks but I could be misrecalling names
**\<suraeNoether>** mercury^: is your project an attempt at estimating the age distribution of outputs the moment they are spent?
**\<mercury^>** suraeNoether: yes.
**\<suraeNoether>** cool, we should talk about it after this meeting
**\<mercury^>** I have not done much work so far. I just read the monerolink paper, then tried to think a little bit about what the actual distribution should be.
**\<suraeNoether>** so, the monerolink paper... the parts that aren't obliterated by obscured amounts in RCT...
**\<suraeNoether>** there is a slightly incorrect interpretation of our system, which is: the authors, Miller et al, they claimed that the youngest output in a ring is most likely to be the true spender. in fact, it's that \*the first time an output is put into a ring\* is most likely occurrence of the true spending
**\<suraeNoether>** which is subtly different
**\<sarang>** I'm making more progress on SoWs
**\<sarang>** And prepped a privacy talk
**\<mercury^>** suraeNoether: well, both of those could be true. Is their claim false? (Is now a good time to talk about it, or should be wait until the research meeting is over?)
**\<suraeNoether>** eh, this research meeting is a dud. their claim is also true, but leads to an estimate with much higher variance. one benefit of their approach is that it really should never result in a \*tie\* between two outputs unless they occurred in the same block. one criticism of their approach is that there is not a super clear way to estimate false positive and false negative rates
**\<suraeNoether>** of course the criticism also holds true for my statement
**\<suraeNoether>** testing the sensitivity and specificity of a de-anon technique is... well, nontrivial at least
**\<gingeropolous>** its unfortunate they didn't create a fake network where they could have had ground truth
**\<scoobybejesus>** their block explorer uses their own index instead of pub keys, so it's annoying to cross-reference
**\<hyc>** fake network based on what? ideally you model the real network but the inputs to the real network are all unknowns
**\<suraeNoether>** gingeropolous: the thought of the details of that gives me a headache :P
**\<gingeropolous>** i dunno. just create a network with n "users" making transactions randomly
**\<mercury^>** gingeropolous: but they have to act like the users of Monero.
**\<gingeropolous>** yeah, ideally. but a fake network of random operators would be better than their current analysis, which IMO still boils down to "maybe"
**\<suraeNoether>** mercury^: the thing about my heuristic of "find the first ring signature referencing output X, that's the true spender of output X" is true with high probability except in a scenario where an output was sitting around long enough to be included in several ring signatures, or unless several ring signatures already reference it. Hence, I think rather than concentrating on distribution of ages, I think
**\<suraeNoether>** we should concentrate on including as many outputs that have never been used before as possible, or some sort of joint technique that takes both "number of referential ring signatures" and "block height" into account
**\<suraeNoether>** gingeropolous: they can test their modeling technique against a null hypothesis like exponential or weibull inter-spending time. or even whole families of distributions, and see how well it does.
**\<mercury^>** gingeropolous: Assuming that the probability of a transaction being unmasked by their method depends only on ring size, their data set would be reasonable I think.
**\<suraeNoether>** if it is robust against many choices of distribution, then they can be rather confident in their approach in the "unknown distro" case
**\<suraeNoether>** actually that's a hell of a good idea
**\<mercury^>** suraeNoether: then the pool of never-unconsumed outputs is contentet and might get too small?
**\<mercury^>** never-consumed\*
**\<suraeNoether>** ahhhh shit i'm going to write that as a paper: rather than test the sensitivity vs. specificity directly, do it monte-carlo style. Pick a random distribution of inter-spending times from a parameterized family of distributions. Simulate an economy with monero or zcash. Try to unmask. Repeat 2^N times for each parameter, and with M parameters, you end up exploring a parameter space of size 2^(NM).
**\<suraeNoether>** estimate false pos and false neg rate of your de-anon technique for each point in this big parameter space. Estimate the "sensitivity" of these rates to parameter perturbation. Try to find a de-anon technique that is most insensitive to choice of distribution.
**\<suraeNoether>** suraeNoether: yeah, just weight it so you can still pick 2x or 3x outputs, just less likely to do so somehow
**\<suraeNoether>** oh man so that'll be the paper I write after multisig is done
**\<mercury^>** suraeNoether: I think with your approach the most likely real output consumed will just be the one that was spent the most often.
**\<suraeNoether>** no, it's the one that has been spent least often
**\<suraeNoether>** if an output has not yet been referenced, say X
**\<suraeNoether>** and you make a new \*random\* transaction
**\<suraeNoether>** the probability that X is included in that signature is, say, 1/B where B is the blockchain size
**\<suraeNoether>** actually that probability is the same even if the output has been referenced
**\<suraeNoether>** however, if X occurs at block height h
**\<suraeNoether>** the only transactions that could possibly reference X occur at height h+1 or bigger
**\<suraeNoether>** so if the blockchain is height H, and X is at height h, then at most h/H transactions on the blockchain (roughly) could possibly reference X
**\<suraeNoether>** each of these is like rolling a B-sided die and looking for a natural 1, and we do it h/H times
**\<suraeNoether>** that's a baseline "random" appearance of X that occurs completely innocently
**\<mercury^>** Do you mean H−h instead of h/H? (I am new to all this…)
**\<suraeNoether>** actually \*i do\* good catch
**\<suraeNoether>** otoh, if we see some X at height h, and it is referenced at block h+10, and H=like a really large number compared to 10, and B=like a really large number compared to 1, the probability of this occurring \*completely innocently and at random\* is super duper small
**\<suraeNoether>** in other words: the first time an output is referenced is the most likely time it was truly referenced
**\<gingeropolous>** i wonder if fake out selection should be biased to those outputs that don't have any reference yet
**\<mercury^>** suraeNoether: I can believe that this is currently true; what I said is that I cannot believe that it will stay true if one were to implement your proposed method of choosing fake outputs to consume by preferring those that have rarely been consumed.
**\<gingeropolous>** hah
**\<gingeropolous>** ok ill shuddup
**\<sarang>** So
**\<ArticMine>** Is there a temporal aspect to the idea that the first time an output is referenced it is the real output
**\<sarang>** To test?
**\<ArticMine>** For example is it different for recent and old outputs
**\<mercury^>** ArticMine: I believe so.
**\<suraeNoether>** ArticMine: yes, my argument is based on the idea that the probability an output has been spent is monotonically decreasing over time
**\<mercury^>** ArticMine: an old output that is really being spent is more likely to have been spent before.
**\<suraeNoether>** er.. has \*not\* been spent
**\<ArticMine>** That is also my thought
**\<suraeNoether>** mercury^: oh yeah i agree, i was walking you through the "derivation" of my argument.
**\<ArticMine>** Since this is velocity of money dependent
**\<suraeNoether>** ah, so that's the thing: miller et al made it velocity dependent by saying "youngest output in the ring."
**\<suraeNoether>** you can make it velocity independent by saying "first time an output is referenced"
**\<mercury^>** suraeNoether: you assume that outputs are selected uniformly among all that are available. As far as I know that is not even currently true? But the argument probably still holds with the current selection method.
**\<sarang>** I believe that's the wallet code?
**\<ArticMine>** I was thinking in changes in the velocity of money for Monero over time
**\<suraeNoether>** mercury^: actually since we use two triangular distributions... i would have to think about that mercury^
**\<ArticMine>** It was different in say 2014 that today and will also be different in the future
**\<suraeNoether>** ArticMine: yeah, this is another reason distributional arguments for wallets squick me out, other than allowing an attacker insight into chain reaction saturation attacks (for lack of a better term)
**\<ArticMine>** My thought was to have multiple ring sets that are close in time to the real output and also randomly chose ring leader outputs
**\<mercury^>** ArticMine: the properties of the fake outputs should not depend on properties of the real output.
**\<mercury^>** They should be chosen independently.
**\<ArticMine>** So we start with ah output pick say 2 other outputs randomly and then build rings around the real output and the two fake ones
**\<suraeNoether>** you know, it's funny, i usually laugh at people like IOTA for throwing around terms like neural nets etc, but... this is a great situation for a genetic algorithm. parameterize a wallet selection method as a genetic code, and parameterize an output-reveal-oracle method as another genetic code, then have the two species compete. One tries to make ring signatures that are anonymous, the other tries to
**\<suraeNoether>** reveal ring signatures, and neither of them breed or eat until they win
**\<ArticMine>** With the rings close in time to the real output and each of the fake one and the rings all the same size
**\<suraeNoether>** but that'd be a senior math-bio-finance major's capstone project
**\<suraeNoether>** or maybe a masters thesis
**\<suraeNoether>** for an open minded advisor
**\<gingeropolous>** just start a college already
**\<hyc>** for bonus points, toss in a spectre/meltdown attacker trying to steal the wallet secrets
**\<hyc>** this is just a very fancy version of CoreWars...
**\<mercury^>** Weren't CoreWars programs written by hand?
**\<hyc>** yes. redcode.
**\<hyc>** but it would be easy to automate generation of CoreWars programs.
**\<hyc>** pretty sure it was done, multiple times
**\<hyc>** but it points to an interesting approach - we should have multiple distribution algorithms, and randomly select when creating each transaction
**\<hyc>** otherwise an attacker will always know "they're using triangular/whatever" ...
**\<mercury^>** hyc: I think one could guess the selection algorithm by inspecting the transaction.
**\<gingeropolous>** is there a theoretical ringsize where distribution of fakeout selection becomes moot?
**\<gingeropolous>** prolly depends on size of blockchain (i.e., number of available outputs)
**\<mercury^>** gingeropolous: I would say that it affects the security that the ring size provides multiplicatively.
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-03-05
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<suraeNoether>** howdy everyone~
**\<endogenic>** hello
**\<suraeNoether>** Agenda is, as usual: I describe what I've done for the past week or so, and field questions, and Sarang does the same. If anyone else is working on projects, we want to hear about other people's contributions, too!
**\<suraeNoether>** at any time, feel free to jump in and ask questions
**\<sgp\_[m]>** hey
**\<suraeNoether>** if it gets too chaotic, we'll try to rein it in
**\<suraeNoether>** oh fluffypony forgot him
**\<sarang>** Shall we begin?
**\<suraeNoether>** Yep. How about you go first, brother noether
**\<sarang>** Sure
**\<sarang>** The BP audit fundraising FFS is ready and in Open Tasks, waiting for an admin to move to Funding Required
**\<sarang>** We're setting a stretch goal of 3 auditors, and will fund as many as we raise funds for
**\<sarang>** Kudelski is pushing back on payment in XMR, but I'm trying to get them to work with OSTIF
**\<sarang>** If they do, we can pay OSTIF in XMR and they'll convert to USD and pay the auditor
**\<fluffypony>** FFS has been moved
**\<sarang>** Thanks fluffypony
**\<sarang>** Otherwise we have to ensure that we can legally do the exchange to USD and pay them ourselves
**\<sarang>** As soon as we have enough XMR for Bunz, we'll hire him
**\<sarang>** then QuarksLab, then Kudelski
**\<sarang>** If we can't reach an arrangement with Kudelski, we can replace them with X41, which will work with OSTIF for payment
**\<sarang>** Other than that, working on some Pippenger stuff for fast multiexponentiation, reviewed a few papers regarding RingCT
**\<sarang>** Posted my monthly report on r/Monero
**\<sarang>** Those are the big things!
**\<suraeNoether>** nice. Does anyone have any questions?
**\<rehrar>** hiya
**\<rehrar>** We're now in Funding Required btw
**\<sarang>** yup yup
**\<rehrar>** oh, didn't see fp's comment there
**\<sarang>** https://giphy.com/gifs/excited-ron-paul-its-happening-rl0FOxdz7CcxO
**\<sarang>** I'll be working with each auditor throughout the process, so this will occupy an known amount of my time for the next couple of months
**\<suraeNoether>** I have a question, sarang, which is: what are you excited to work on now that the bulletproof range proof audit stuff is going to be spread around a bit?
**\<sarang>** ah yes
**\<sarang>** I'm looking forward to doing a more thorough analysis of operation optimization in our current stuff and in proposals like RingCT replacements
**\<sarang>** and interested in RingCT futures in general
**\<sarang>** Now that the blockchain will be smaller and verifications faster, anonymity has been moving to the forefront
**\<suraeNoether>** neat. that leads me to questions about multi-exp optimization in our current scheme
**\<suraeNoether>** like, in general, it seems like all our EC operations could be made much more speedy
**\<suraeNoether>** across the board
**\<sarang>** Depends on what types of operations you mean
**\<sarang>** Multiexp? Sure
**\<sarang>** The precise way depends on the size of the operations and curvepoints involved
**\<sarang>** There's no single silver bullet that's always better
**\<suraeNoether>** ah i see
**\<sarang>** Using a combo of Bos-Coster and Straus handles a lot of cases
**\<sarang>** Pippenger is next up, based on results from andytoshi et al. on their curve
**\<suraeNoether>** I'd be very curious to see how much faster MLSAGs can get with more efficient operations
**\<sarang>** The nice thing is that multiexp is probably biggest opportunity for savings, since the current scaling is so bad
**\<sarang>** I'm pretty much done if someone else wishes to speak now
**\<sarang>** I just like listening to the sound of my own keyboard
**\<suraeNoether>** Well, this past week I got the multisig paper to the point where I am seeking feedback/corrections from community members. You can read the current version (main.tex) here. https://www.sharelatex.com/read/bfjfkdgnhgvh
**\<suraeNoether>** I am confident that the bones of the thing are correct, but details need to be fleshed out
**\<suraeNoether>** the C++ code appendix must still be reviewed
**\<suraeNoether>** so i'm not seeking feedback on the appendix yet: i know it's wrong, and I have a list of ways its wrong
**\<sarang>** There were a few rumblings on whether or not we'd like to take this audit momentum and keep applying it elsewhere, like to multisig
**\<sarang>** Thoughts?
**\<rehrar>** \*cough\*RingCT?\*cough\*
**\<sarang>** I believe it'd be good for security and also excellent PR
**\<sarang>** Ha yes rehrar that was also brought up for sure
**\<suraeNoether>** I didn't know there were rumblings on that. i think a weak point of my presentation is the C++ code review, for sure
**\<sarang>** informal rumblings
**\<suraeNoether>** i actually think I have a pretty clever proof structure that I'm attempting this afternoon that may make things even smaller
**\<rehrar>** rumblings sans top hats
**\<andytoshi>** re BPs. in libsecp we use strauss then pippinger. we changed our prover from doing the recursive scheme to one that directly computes L and R with a big multiexp at each iteration, and got an almost 2x speedup
**\<suraeNoether>** but, again, that's the \*theoretical\* end of the review
**\<suraeNoether>** andytoshi dayumn brother
**\<sarang>** andytoshi: nice!
**\<andytoshi>** i think i can get a bit more by combining generators at some levels
**\<sarang>** We did basically zero optimizations to the prover, since that's done once
**\<sarang>** suraeNoether: auditing the implementation would be key
**\<suraeNoether>** if we have money left over from the BP audit, I would be happy sitting on the leftover XMR for a month to see if we can get an audit of multi-ringCT out of a single funding round
**\<sarang>** I very much doubt we'd have enough to fund another complete audit
**\<sarang>** Might depend on price movement
**\<suraeNoether>** eh, who knows where the market will be in a month
**\<suraeNoether>** rihgt
**\<suraeNoether>** that's all i'm saying
**\<sarang>** But we could combine leftovers with a new FFS and ride the wave of support for audits
**\<suraeNoether>** after reading through the C++ code, the only real complaint I had was to increase the # of rounds of chacha encryption
**\<suraeNoether>** on another note, I'm writing up a brief technical note on sublinear ring signatures.
**\<suraeNoether>** and why we haven't implemented them yet
**\<suraeNoether>** or, to be more specific
**\<suraeNoether>** The idea is this: (i) small anonymity sets are worse than large anonymity sets, (ii) authentication still requires touching all keys in the anonymity set at least once, leading to linear verification times, and (iii) improving the space-efficiency of a blockchain therefore interacts with this linear verification time in a way that produces a space-time trade-off, leading to (iv) a trade-off between
**\<suraeNoether>** traceability and the space-time efficiency of the blockchain... and I want to discuss (v) several ways that several different currencies have handled this trade-off, and (vi) implications from cost of running an untraceable cryptocurrency network at scale on this time-space trade-off.
**\<suraeNoether>** Other than working with sarang to get the multisig paper up to peer review shape, soliciting comments from the community on that, and working on this trade-off technical note, I've also been reading papers like Sarang.
**\<sgp\_[m]>** What other currenices of notehave handled this tradeoff with ring signatures?
**\<suraeNoether>** none, but other currencies have hadnled it without ring signatures, i.e. zcash
**\<sarang>** The tradeoff I see is a replacement with proof structures requiring trusted setup
**\<sarang>** yeah ^
**\<sarang>** There was a paper out with suggestions for Monero, but they too involved a trusted-setup accumulator
**\<sarang>** (and this fact was buried within the paper....)
**\<andytoshi>** yeah, trusted setups are often really hard to find in papers
**\<andytoshi>** academics seem to think it's not an important thing
**\<andytoshi>** some academics\*
**\<sarang>** I was surprised since the paper was specifically about Monero
**\<sarang>** And our views on trust are pretty clear
**\<andytoshi>** yeah that's weird
**\<sarang>** I expect that's \_why\_ they buried it
**\<andytoshi>** :|
**\<sarang>** anyhoo
**\<sarang>** suraeNoether: carry on...
**\<suraeNoether>** So, papers: 1) Matthew Green shared his "squeezing crowds" paper, which is a constant-space way of describing the complete set of ring members in a transaction. Link here: https://isi.jhu.edu/~mgreen/mixing.pdf This is a non-trivial result that will help Monero scale eventually... but it solves a problem that isn't yet a problem and may not be for a long while
**\<rehrar>** that new paper by Green?
**\<suraeNoether>** great minds brother
**\<sarang>** I know moneromooo had some concerns about transaction height in general
**\<sarang>** but I can't speak for him
**\<rehrar>** Does it have drawbacks if it was theoretically implemented tomorrow (i.e. not large ringsizes yet)?
**\<moneromooo>** Oh that wasn't about the paper itself, just general about when I thought about this.
**\<sarang>** right
**\<sarang>** I'm working through the Green paper as well
**\<suraeNoether>** rehrar literally all it does is \*describe the public keys for use in the signature.\* you still need to pull the public keys out of the blockchain and plug them into the verification equation.
**\<moneromooo>** But in retrospect, if you include the height at which you make the sampling, it all goes away.
**\<suraeNoether>** so this own't help us get larger rings.
**\<moneromooo>** Given fake out list size is not our bottleneck, no. Maybe later.
**\<sgp\_[m]>** Can you elaborate a little more on what the paper says?
**\<suraeNoether>** sure, so they define a Recoverable Sampling Scheme
**\<sarang>** It says you can use a keyed hash function to succinctly describe the ring members to be used in a transaction
**\<suraeNoether>** so, say you want to construct a ring {A, B, C}
**\<suraeNoether>** rather than sending keys A, B, and C along with the transaction, you send information for constructing a hash function
**\<suraeNoether>** if you compute a quick hash of the blockchain using that information, out pops the keys you want to use in the ring signature
**\<luigi1111>** Sender grinds or what
**\<sgp\_[m]>** All right, with you so far. Why does this have relatively small impact?
**\<suraeNoether>** and their approach scales with the number of outputs, not the number of inputs. So \*describing\* a transaction with 1000 ring members and five outputs is 99% more efficient with an RSS than with our current scheme
**\<suraeNoether>** but you still need the signature
**\<suraeNoether>** and yous till need to verify it
**\<suraeNoether>** and verifying the signature takes O(N) time. in this case, with 1000 ring members, it's implausible
**\<suraeNoether>** well except for weirdos
**\<moneromooo>** Should not need to grind, make a random + offset should be enough.
**\<suraeNoether>** in general, you need ring sizes around 10-15 before the RSS scheme actually saves space
**\<suraeNoether>** one may consider it a database trick for accessing keys efficiently, perhaps, rather than a privacy-enhancing thing
**\<suraeNoether>** unless i've wholly misunderstood their paper
**\<luigi1111>** Hmm moneromooo but that doesn't sound like a hash function
**\<luigi1111>** Anyway doesn't matter
**\<sgp\_[m]>** ok, thanks for the info
**\<suraeNoether>** yeah
**\<suraeNoether>** SO
**\<sarang>** Yes suraeNoether it's just about descriptors for bandwidth savings over large sample sets
**\<sarang>** and the use of a hash function means they get proofs of security out of it
**\<sarang>** not privacy
**\<suraeNoether>** in addition to that, I've been reading about arithmetic circuits, idly tinkering with my cryptocurrency network simulation tool, thinking about large anonymity sets
**\<suraeNoether>** but Sarang and I kind of have an announcement, I guess. We are starting an educational non-profit called Multidisciplinary Academic Grants in Cryptocurrency. Our primary goal will be to provide scholarships to students, research grants to researchers, and infrastructure grants to schools.
**\<rehrar>** whoa. And this is a 'separate from MRL' type thing?
**\<sarang>** Legally separate, yah
**\<suraeNoether>** yep. The original idea was to start a pipeline between the research world and the cryptocurrency world
**\<binaryFate>** Nice! Do you see possible ties to the Monero FFS for scholarships and grants?
**\<sarang>** We'll get the benefits of being a U.S. registered nonprofit
**\<sarang>** binaryFate: abso-freaking-lutely
**\<suraeNoether>** See, after attending several schools that seemed so resistant to cryptocurrencies, I think it's a shame that a lot of students won't be getting a decent education in cryptocurrencies, especially when we're talking about the future world economy
**\<suraeNoether>** and after speakign with fluffypony and a partner in South Africa, I realized... like... for the cost of a year of college here in the US, that's... an entire schoolteacher's salary in South Africa
**\<suraeNoether>** Chile has a similar situation going on
**\<binaryFate>** cool idea
**\<suraeNoether>** and if we can manage to encourage education in financial privacy, improve cryptocurrency literacy, etc etc, these are all good things for the economy as a whole...
**\<sarang>** It also has the side benefit of helping Monero's image
**\<sarang>** and letting community members give back in a different way
**\<suraeNoether>** and not to mention: Monero's image as a contributor to education would be an extremely valuable thing for the future of Monero, in terms of development, interest, research, etc. HOW COOL will it be when the first principal investigator who received a MAGIC grant gets tenure or gets an award for a paper they wrote while being funded by us?
**\<suraeNoether>** ha
**\<suraeNoether>** again, great minds
**\<sarang>** jinx
**\<binaryFate>** Missed "MAGIC". Just do it already! :)
**\<sarang>** The idea is that it's legally not tied to Monero (to keep things simple) but can be heavily funded anonymously by Monero community members
**\<sarang>** and the 501(c)(3) structure will help integrate with institutions and schools better than some random group
**\<sarang>** kudos to suraeNoether for doing all the legwork on this
**\<sarang>** I'm just along for the ride
**\<sarang>** binaryFate: yeah, MAGIC internet money...
**\<sarang>** Worth noting for the scrupulous among us that donations may be tax-deductible if you're in the U.S.
**\<suraeNoether>** Thing is, if you go visit a college campus, you'll notice something: the really sweet campuses, the beautiful ones, the country-club campuses... those are the ones that get funding from alumni. you would think that schools that are dumps, the president house is on fire and the dorms are rioting, these are the schools that should get funding. not how it usually goes. i would love it if MAGIC started
**\<suraeNoether>** funding folks to go to community college and some of those folks ended up building world-changing stuff out of Monero.
**\<suraeNoether>** and I would love it if the Monero community was responsible for building a library for some disadvantaged kids in south africa. :P
**\<suraeNoether>** Not to mention, this gives us a legal vehicle to fund academic conferences for Monero
**\<sarang>** ^^ yesss
**\<suraeNoether>** So, that's the educational outreach "secrets in the works" that I've been keeping under my hat for a few weeks
**\<sarang>** It definitely felt like accepting anonymous crypto to fund a nonprofit would rile up the government, but apparently not if you do it correctly
**\<rehrar>** accept XVG?
**\<sarang>** -\_\_\_\_\_-
**\<sarang>** sure
**\<suraeNoether>** Currently we have a partner in ZA and a partner at Clemson University who are interested in being board members, for the two very different ends of the spectrum
**\<suraeNoether>** I am filing the paperwork to incorporate today
**\<sarang>** MAGIC doesn't need to GAF about crypto politics
**\<sarang>** If someone wants to donate to help students, awesome
**\<sarang>** too bad zcash just announced their grant program too
**\<sarang>** we want the spotlight =p
**\<rehrar>** well that's all super cool. Glad that you guys are doing awesome things.
**\<suraeNoether>** Oh, and one last thing: this paper was just put out only a few days ago. Has anyone read it yet? https://eprint.iacr.org/2018/241
**\<rehrar>** easy sarang. Just make your grant program more grant-ier
**\<rehrar>** and have free pizza. Spotlight all yours.
**\<sarang>** suraeNoether: I have not yet
**\<sarang>** Naturally suraeNoether will also be on the board?
**\<andytoshi>** oof neha asked me to read that quite a while ago (before publication) and i forgot
**\<suraeNoether>** ok, well is anyone else working on anything interesting they want to share? andytoshi i know you aren't a direct MRL contributor, but I'm certainly curious about what yall have been up to
**\<andytoshi>** BP optimizations mainly
**\<sarang>** I think he puts blocks into a stream or something
**\<andytoshi>** lol
**\<sarang>** but in very efficient ways
**\<andytoshi>** i implemented an optimization from benedikt where we do one less recursion (so we expose two more scalars but save one L/R pair so it's a wash)
**\<andytoshi>** this gives us a ~8% speedup in batch verification of single-range rangeproofs
**\<sarang>** andytoshi: that's the one you discussed with me earlier?
**\<andytoshi>** yeah i think so
**\<rehrar>** So, I obviously have zero idea about this, but how long does an audit take to do?
**\<sarang>** We're looking at up to a month each
**\<sarang>** but the times overlap
**\<rehrar>** Right.
**\<sarang>** maybe a little more, maybe a little less
**\<rehrar>** I ask this for two reasons, 1. for BP audits
**\<rehrar>** but 2. what would it look like to devote a bit of MRL time to help audit codebases of other security-focused projects in the privacy space
**\<rehrar>** i.e. Veracrypt, KeepassXC, etc.
**\<rehrar>** it may not be at all feasible, obviously. But just thought I'd ask
**\<sarang>** That's a huge undertaking
**\<rehrar>** That's what I figured.
**\<sarang>** and I think it's outside the scope of our intent
**\<sarang>** Plus we're hardly an independent group
**\<sarang>** so our results might be viewed as inherently biased
**\<sarang>** That's really what groups like OSTIF are for
**\<sarang>** Organizing audits of important tech
**\<sarang>** (and it's why we're working with them now)
**\<rehrar>** ok :)
**\<sarang>** We're approaching the end time, and suraeNoether had to leave a bit early
**\<sarang>** Any other topics of interest to bring up?
**\<sarang>** OK!
**\<sarang>** Thanks to everyone for joining in
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-03-12
summary: BP audit, Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<suraeNoether>** So, greetings everyone!
**\<MoroccanMalinois>** Hi
**\<iDunk>** Hi
**\<sarang>** yo
**\<suraeNoether>** Agenda today is 1) hello, 2) BP audit update 3) other stuff Sarang has been reading/working on, 4) stuff I've been working on, 5) obligatory update on MAGIC, 6) anything anyone else wanna talk about?
**\<suraeNoether>** oh, I also want to talk about: how to educate our users about proper key usage and proper privacy practices
**\<ArticMine>** hi
**\<endogenic>** o/
**\<suraeNoether>** so, sarang: BP audit update? you gave us a brief one earlier
**\<suraeNoether>** but let's recap for folks who weren't here
**\<sarang>** sure thing
**\<sarang>** We have raised funds for 3 audits: Benedikt Bunz, QuarksLab, Kudelski
**\<sarang>** I'm finalizing contracts with them
**\<sarang>** We will likely need to do supplemental funding later due to market tomfoolery
**\<sarang>** I will be working with the groups during their audits, which will take place between this months and June
**\<sarang>** That's the brief version
**\<endogenic>** may i ask a question regarding our auditing efforts in general?
**\<sarang>** plz
**\<endogenic>** or should i wait til end?
**\<sarang>** fire away
**\<endogenic>** so i'm also wondering about vulnerabilities in the code in general - i know we have the bounty system for that but it's not got quite the same incentive system
**\<endogenic>** just wondering if it makes sense to apply this model to other parts of the code
**\<sarang>** Hiring auditors, you mean?
**\<endogenic>** yeah
**\<sarang>** I'm seeing more and more support for it, yes
**\<endogenic>** or an FFS for an auditor
**\<suraeNoether>** endogenic: so there is this clever idea
**\<sarang>** At least for components of the code, like multisig or BPs that have a defined scope
**\<suraeNoether>** that greg maxwell and blockstream are using for their libsecp256k1 library
**\<suraeNoether>** which has a badass test suite
**\<endogenic>** sarang: right i suppose i'm thinking more from the security and cracking standpoint .. like, can we confirm what % of data input fuzzing we've done and where / if / how the code fails
**\<endogenic>** etc
**\<suraeNoether>** where they aren't providing bug bounties for the actual library, but for the unit test suite: if you can upload a new unit test that the current system fails, and yet still passes all current unit tests, you get the bounty
**\<sarang>** That's more of a question for moneromooo I think
**\<endogenic>** that sounds interesting surae
**\<suraeNoether>** it incentivizes things very nicely
**\<suraeNoether>** but it requires a really great test suite
**\<sarang>** yes indeed
**\<moneromooo>** I don't think we can easily determine a percentage of inputs for fuzzing.
**\<endogenic>** well that was just one example
**\<endogenic>** i cant take responsibility to define all the jobs an expert cracker would do :P
**\<suraeNoether>** if we are going to start putting money into auditors, then we should consider putting a proportion of that toward beefing up our test suites. perhaps require that auditors propose new unit tests, or something along those lines, in addition to a thumbs up/down and a list of recommended changes
**\<endogenic>** yeah
**\<endogenic>** i mean we want to record the work which was done
**\<endogenic>** and tests can be nice way to do that
**\<sarang>** yes
**\<suraeNoether>** and that way, perhaps after a year or two, we will have a test suite sufficiently beefy to incentivize properly
**\<suraeNoether>** i know its' kind of a long-term plan
**\<sarang>** Too bad it's sexier to run an FFS for an auditor than for writing test suites :(
**\<suraeNoet