monero-project/monero-site
monero-project/monero-site
1
0
Fork 0
mirror of https://github.com/monero-project/monero-site.git synced 2024-09-28 21:41:11 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

The whole fourty-five missing MRL meeting logs

Browse source 
+ corrections after testing
This commit is contained in:
el00ruobuob 2019-02-14 14:00:11 +01:00
parent 0f25ac80a1
commit d185db671f
No known key found for this signature in database
GPG key ID: 8794A50E11FE51A0
45 changed files with 9364 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

136
_posts/2017-10-09-logs-for-the-Monero-Research-Lab-meeting-held-on-2017-10-09.md Normal file
View file

@ -0,0 +1,136 @@
---
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 \*

83
_posts/2017-12-18-logs-for-the-Monero-Research-Lab-meeting-held-on-2017-12-18.md Normal file
View file

@ -0,0 +1,83 @@
---
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>** sarang.noether@protonmail.com 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

107
_posts/2018-02-26-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-02-26.md Normal file
View file

@ -0,0 +1,107 @@
---
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.

227
_posts/2018-03-05-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-03-05.md Normal file
View file

@ -0,0 +1,227 @@
---
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

277
_posts/2018-03-12-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-03-12.md Normal file
View file

@ -0,0 +1,277 @@
---
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 :(
**\<suraeNoether>** short of paying some smart people to audit our whole lie-berry and come up with test suites across the board
**\<suraeNoether>** yeah, no kidding
**\<endogenic>** sarang it can be pitched in the same way
**\<endogenic>** they audit by the very activity
**\<rehrar>** do unit tests require coding? (sorry if this is a stupid question)
**\<endogenic>** yep
**\<sarang>** yes
**\<rehrar>** blerg
**\<endogenic>** it's not that bad tho rehrar
**\<endogenic>** it's more about understanding what you are testing for
**\<sarang>** The goal is to have complete scope
**\<rehrar>** it is when my coding is 1/10 :D
**\<sarang>** Any questions on the current audit that anyone has?
**\<sarang>** Kudelski will be the first to go
**\<moneromooo>** When does the C++ based one start ?
**\<sarang>** They're available this month
**\<moneromooo>** More precisely ?
**\<sarang>** TBD once we sign with them, but I can check on more specific dates if you need them
**\<sarang>** Anything in particular?
**\<suraeNoether>** ok, well
**\<ArticMine>** are all the audits going through ostif?
**\<sarang>** Two of them are
**\<sarang>** Benedikt will be paid directly in XMR
**\<suraeNoether>** ArticMine: I believe Buenz is independent
**\<suraeNoether>** ^
**\<sarang>** OSTIF's role is just to handle the payment
**\<sarang>** They'd appreciate being thanked in our materials for helping to organize the groups and handle the exchange
**\<suraeNoether>** okay, if there are no more questions on BPs
**\<sarang>** So this will be an ongoing process over the next few months
**\<sarang>** expect little news until someone finishes
**\<suraeNoether>** Sarang: what else have you been reading/doing?
**\<sarang>** I've been reviewing the latest multisig draft from suraeNoether
**\<suraeNoether>** ok in that case we will stop bringing it up every meeting for 3 weeks or so :P
**\<sarang>** prepping a submission for defcon china
**\<suraeNoether>** that's cool
**\<sarang>** prepping a talk in portland on monero security
**\<sarang>** reading up on some papers involving mixing and ring representations
**\<sarang>** hoping to get back to some math shortly for pippenger's algorithm
**\<sarang>** for speedier multiexp
**\<sarang>** more administrative work lately, unfortunately
**\<sarang>** I submitted a monthly report recently that details other efforts
**\<sarang>** linky linky https://forum.getmonero.org/9/work-in-progress/89005/funding-for-sarang-at-mrl-for-q1-2018?page=&noscroll=1#post-94324
**\<suraeNoether>** any other questions for sarang?
**\<suraeNoether>** I'd like to remind the crowd that sarang's FFS funding round I believe has been posted, although I'm not sure if it's moved to Funding Required yet
**\<rehrar>** There's quite a few things that need to be moved to funding required
**\<rehrar>** we should all poke fluffypony and luigi1111
**\<sarang>** Mine is still in Open and not in Funding yet
**\<sarang>** There hasn't been much activity regarding it anyway
**\<sarang>** Not a huge rush. I write them in advance to allow for discussion if needed
**\<sarang>** How about suraeNoether? Your turn
**\<suraeNoether>** 4) Stuff I've been working on. Multisig paper, formal documentation work for monero, and a formal description of EABE attacks.
**\<suraeNoether>** For the multisig paper, I just received notes from sarang and I'll be composing a draft for review by someone outside of MRL.
**\<sarang>** suraeNoether: I'll have remaining notes added to your doc this afternoon
**\<suraeNoether>** right now I need to copy-paste some intro/notation stuff from a previous version of the paper, fix some references, stuff like that, and then take sarang's changes into account
**\<suraeNoether>** great thanks
**\<suraeNoether>** Once the document is a little less ugly, i'll link to it again
**\<sarang>** Now on to MAGIC per the agenda?
**\<suraeNoether>** I've been attempting to write up a formal description of the statement being proven in a given monero ringCT authentication, for two reasons. For one thing, I think that our approach for threshold multisig could be generalizable in a way that may make it fun to publish. But I'm not sure if this description has appeared before in the literature, so I'm looking around and contacting some folks
**\<suraeNoether>** For another reason, because I haven't seen it written out explicitly before.
**\<suraeNoether>** And the EABE attack is concerning enough to me to be writing up some statistical arguments about churn (sgp\_[m] ping)
**\<suraeNoether>** i'll be linking all these documents in the next week
**\<suraeNoether>** so far it looks like 3 sketches of possible papers for publication, even if not as peer reviews, as whitepapers
**\<suraeNoether>** after multisig is running
**\<suraeNoether>** anyway, onto MAGIC
**\<suraeNoether>** i feel like folks have a lot of questions about MAGIC, so I'll ask if anyone has any questions
**\<sarang>** Question I've seen is: what types of things will it fund, and how will they be determined?
**\<luigi1111w>** sarang moved
**\<luigi1111w>** moneromooo ready for funding
**\<rehrar>** thanks luigi
**\<sarang>** ty luigi1111w
**\<suraeNoether>** Good question. The overall scope will be: 1) scholarships to undergraduates in the US 2) grants to graduate students in the US, 3) grants to researchers in the US, 4) grants to schools globally with an emphasis on secondary and tertiary education
**\<suraeNoether>** how much of that we can actually do depends on our funding
**\<suraeNoether>** oh 5) sponsoring tehcnical conferences in cryptocurrencies is also on that list
**\<sarang>** suraeNoether: why restrict scholarships and grad grants to US?
**\<suraeNoether>** so our first year, my goal is to provide a few scholarships, sponsor the first monero conference, and fix up a school in south africa
**\<rehrar>** what other ways of funding are you searching for besides FFS stuff?
**\<endogenic>** do you have any criteria to decide what is good research that gets funded?
**\<suraeNoether>** sarang: because i feel like we already are going to have lots of applications
**\<endogenic>** will decision making ever get delegated?
**\<sarang>** The org will need established principles for determining its choices
**\<sarang>** to stay transparent and accountable to its donors
**\<suraeNoether>** rehrar: we'll be soliciting funding and grants from as many places as possible. one delightful property of non-profits in america: anything they spend that isn't on overhead must go to charitable purposes or other non-profits. so non-profits like the bill & melinda gates foundation give lots of money to other non-profits.
**\<sarang>** rehrar: I mentioned the kernel of this idea to some fund managers, who said their groups were interested in supporting nonprofits; this may lead to new funding avenues
**\<rehrar>** that's pretty awesome
**\<suraeNoether>** endogenic: I haven't started thinking about the research end of MAGIC yet because i'm assumign the first year we won't necessarily get enough money to manage to give out substantial research grants
**\<endogenic>** sorry replace research with project
**\<endogenic>** i misspoke
**\<sarang>** Sounds like there would be a clear delineation between scholarships and grants
**\<suraeNoether>** ah yeah well in general, like sarang says, we need established principles for determing our choices, and this is something that needs to be discussed at our board meetings. we want to be very public, and i want to make our board meetings available as youtube videos or whatever... pending agreement by the other board members (some of whom have not yet been picked)
**\<suraeNoether>** sarang yes
**\<sarang>** Grants would have the expectation of deliverables
**\<sarang>** Scholarships are to increase the talent pool and help perhaps underrepresented student groups become involved in the space
**\<suraeNoether>** scholarships for undergrads, it is my intention, to mainly be aimed at folks in law or economics or computer science or math. Not exactly the traditional STEM mix. however, i don't want an undergrad to worry about losing their money if they decide to study graph theory instead of bitcoin
**\<suraeNoether>** sarang ^ yep
**\<suraeNoether>** i kind of want the schoalrships nearly strings-free
**\<sarang>** However, the devil's in the details
**\<suraeNoether>** as far as funding goes, though, i'm matching up to 5% of donations up to 50 XMR for this venture. If we manage to get 1000 XMR, I donate 50 XMR to the cause and we'll have 1050 XMR for the first year
**\<sgp\_[m]>** suraeNoether a little late to chime in, but I would love to help you with the EAE paper if there's any way I can
**\<suraeNoether>** sgp\_[m]: PM me
**\<suraeNoether>** and if we can manage that much XMR the first year, we can pay for like 5 scholarships for undergrads, 2 grad student grants, fix up a school or two in ZA, and host the first monero conference (with no entry fee)
**\<sarang>** This is an interesting pilot project that could take many different directions
**\<suraeNoether>** and still have some XMR leftover for the next year
**\<sarang>** I think it'll important to keep the scope balanced between too narrow and too broad
**\<suraeNoether>** my primary concern right now is determining criteria for handing out scholarships
**\<sarang>** An established mission is gonna be essential to establishing and maintaining this direction
**\<suraeNoether>** personally i think the best students are the ones who sucked the first year or three and then completely turn around, but that's just rewarding students with a past similar to myself
**\<rehrar>** how many board members and who is under consideration?
**\<rehrar>** will you guys need a website?
**\<suraeNoether>** yes
**\<sarang>** You'll need to use the application process to determine who is excited about the crypto space and not just eager to hop on a money train
**\<rehrar>** msvb-lab will get mad at me if I talk about other people's websites before I finish Kastelo
**\<sarang>** I wouldn't expect the model student to know everything about this space, but I want to ensure that the recipients are those with a strong desire to succeed in it for good reasons
**\<msvb-lab>** rehrar: Yes, very mad. It's our nature.
**\<suraeNoether>** me, sarang, the operations manager from Globee, my advisor at Clemson university (Jim Coykendall), my wife are going to be the first board members.
**\<sarang>** rehrar: we'll advertise with hip videos on FaceSpace and SnapTime and InstantGram where students like to hang
**\<suraeNoether>** if anyone has an issue with my wife on the board, MAGIC was partly her idea, she has 7 years experience teaching in higher education, and she isnt' being paid
**\<sarang>** Should there be broader representation?
**\<suraeNoether>** I'd be happy including more board members
**\<sarang>** Or is this sufficient?
**\<rehrar>** I'm a Mexican if we need diversity :P
**\<sarang>** I'm not leaning one way or another, just wondering if it is
**\<suraeNoether>** rehrar: you are also in NM yeah?
**\<rehrar>** I am
**\<suraeNoether>** and NM has liiiike some serious education problems
**\<suraeNoether>** iirc
**\<rehrar>** Come down and we'll have a party trip to Juarez
**\<rehrar>** yes
**\<rehrar>** we really do
**\<suraeNoether>** WELCOME ABOARD REHRAR
**\<rehrar>** I'm working on this myself actually in my free time
**\<rehrar>** We're like the second worst in the nation
**\<suraeNoether>** cool email me at surae@getmonero.org so I can get you on a list
**\<suraeNoether>** okay, lastly
**\<rehrar>** I'm on a lot of NSA lists already, but sure.
**\<endogenic>** yes NM does
**\<endogenic>** rehrar is the only beacon
**\<rehrar>** endogenic came here and saw the people sobbing in the streets
**\<suraeNoether>** okay, lastly: I wanted to talk about how to educate the community about key safety with MoneroV and best practices (currently, I'm not convinced churn is non-negligibly helpful under a very specific threat model)
**\<rehrar>** What about a short one minute video?
**\<suraeNoether>** would be very convenient to link to
**\<rehrar>** We can put it on our soon-to-come media.getmonero.org as well as youtube and stuff
**\<suraeNoether>** i've been thinking about starting whiteboard youtube videos explaining how cryptocurrencies work. this could be the first one.
**\<rehrar>** suraeNoether, talk with me later about Privacademy.
**\<nioc>** something that would allow an idiot like me to know exactly what to do
**\<sarang>** Just paste your private keys here. We'll print them out and put them in a safe for you
**\<Osiris1>** ;)))
**\<sarang>** OR DON'T
**\<Osiris1>** nice
**\<nioc>** thx
**\<ArticMine>** My concern with this is that we do not end up protecting MoneroV from the claws of the bear
**\<suraeNoether>** nioc, looks to me like you're a pretty smart fella, if the past few years have shown us anything about anticipating change. :P ok. Does nayone have any questions, concerns, comments? I'll be posting my next funding request this afternoon. I have a hard time gauging the mood of an IRC chat room
**\<suraeNoether>** ArticMine: care to elaborate?
**\<endogenic>** i heard nioc is a cabbage
**\<endogenic>** literally
**\<sarang>** I don't have a good sense for how many users will fall for V
**\<ArticMine>** Basically i see MoneroV as an economic attack. If nobody claims their MoneroV then it price will be significantly inflated
**\<ArticMine>** So we need a process for people to claim, their MoneroV safely and without impacting their own and other's privacy and to be blunt at the appropriate time dump the MoneroV on the market
**\<ArticMine>** That is where the claws of the bear come in
**\<sarang>** What do you mean ArticMine? Spending an existing output on the V chain with random ring is immediately deanon
**\<sarang>** and contributes to the eventual deanon of your ringmates
**\<rehrar>** I see what he's saying though. If not a lot of people claim theirs, then it's a lot of immediate 'holders' which might artificalily inflate the price
**\<ArticMine>** The only way I can see this working is a spend on both chains with a significant number of overlapping rings
**\<rehrar>** which in turn, might make it seem like MoneroV was somewhat successful
**\<rehrar>** which also in turn might make other people try to do something similar with Monero
**\<ArticMine>** If the price of MoneroV crashes then this becomes a powerful deterrent for the future
**\<suraeNoether>** ArticMine: i disagree. airdrops are designed to crash like that
**\<sarang>** Tough part is that a given user might not care about their transaction being deanon. But it's convincing them that it contributes to others that's trickyy
**\<suraeNoether>** they aren't designed for egalitarian long-term pegs
**\<Olufunmilayo>** sarang, I thought (mind you I am late to the party), that spending a output on both chains with the same ring was theoretically "safe-ish" to some extent
**\<suraeNoether>** Olufunmilayo: only if all your ringmates do the same, and all their ringmates, etc
**\<sarang>** And their code needs to support it
**\<ArticMine>** It is but trike to do
**\<sarang>** they've shown they don't GAF
**\<ArticMine>** Then we will have to release a patched Monerov
**\<ArticMine>** It does not have to be "official"
**\<sarang>** One idea I like is making it easier to fork the Monero codebase and blockchain safely
**\<rehrar>** \*shrug\* I may be thinking a bit casually here, but since this is the first time something like this is happening, and we're already going to be getting our upped ringsize before the fork, I think we can somewhat safely wait this one out and see how it plays
**\<sarang>** So for future attempts, they'd have to actively break that safety
**\<sarang>** and then we can give them bad publicity for actively hurting users
**\<suraeNoether>** i wonder if they doubly-hash their key images. so you check if pHp(P) is in the key image set or if pHp(pHp(P))
**\<suraeNoether>** or if they could rather
**\<ArticMine>** By the way the network effect is less because of spent RingCT ouputs that will not be compromised
**\<rehrar>** Alright, I gotta split. Thanks for the meeting. Catch you guys later
**\<Olufunmilayo>** ArticMine, what good would a patched monerov be if the core team is not behind monerov? Also, suraeNoether, time would also be a factor yes? both have to be done simultaneously
**\<ArticMine>** The trouble is that the same keys are used on both chains
**\<ArticMine>** It will allow those who wish to claim and sell their MoneroV to do so safely.
**\<suraeNoether>** oh no the double hash doesn't work unless all previous ring sigs do it that way. bah.
**\<ArticMine>** Not all but enough to provide a good mix
**\<ArticMine>** and that means pre fork mixins will only work
**\<Olufunmilayo>** ArticMine, you will then have two competing versions of monerov competing against each other. I do see the benefit but \*shrug\*
**\<suraeNoether>** okay, well, unless folks have more questions or suggestions, i think our best bet is simply to put out a video that says "don't claim your MoneroV, here is why."
**\<ArticMine>** No the patch can be compatible with the MoneroV consensus
**\<suraeNoether>** because the math to patch monerov or to protect monero isn't obvious to me right now
**\<ArticMine>** I am not sure if there is a solution
**\<iDunk>** It's mooo's code to make it use the ringdb, AFAIUI.
**\<Olufunmilayo>** suraeNoether, only other thing would be to I guess track monerov tx's to see just how bad it is haha
**\<sarang>** We will
**\<suraeNoether>** Okay, well
**\<suraeNoether>** good meeting everyone
**\<suraeNoether>** 1h10 minutes, not too bad
**\<suraeNoether>** OH OH
**\<sarang>** oh
**\<hyc>** oh?
**\<suraeNoether>** anyone want to volunteer to make PRs to my github with meeting logs? I'm literally never going to do it
**\<suraeNoether>** i intend to every week, but i think i need to practically accept that it's not going to happen. :P
**\<sarang>** https://www.youtube.com/watch?v=ZXsQAXx\_ao0
**\<suraeNoether>** ok
**\<suraeNoether>** fine
**\<suraeNoether>** lol
**\<suraeNoether>** \\meeting
**\<sarang> \</meeting>**
**\<suraeNoether>** https://github.com/b-g-goodell/research-lab/tree/master/meta/research-meeting-logs
**\<suraeNoether>** just started a folder called meta rather than cloning the meta repo for The Monero Project.
**\<suraeNoether>** i suppose i should clone it and make pushes appropriately
**\<suraeNoether>** but i'll dot hat later
**\<suraeNoether>** ack its not complete
**\<suraeNoether>** ok there we go: https://github.com/b-g-goodell/research-lab/blob/master/meta/research-meeting-logs/ResMeetLogs-12-Mar-2018.txt
**\<suraeNoether>** bbl yall~

134
_posts/2018-03-19-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-03-19.md Normal file
View file

@ -0,0 +1,134 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-03-19
summary: MRL work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<suraeNoether>** So research meeting, I guess, 1) Hello. 2) Sarang's stuff (he appears to not be on)... 3) my stuff. 4) anyone anything else is interested in, and 5) questions
**\<suraeNoether>** looks like participation this week is a litlte weak. maybe it has something to do with the st patty's weekend or something
**\<suraeNoether>** So, skipping directly to what i've been working on: I finished the multisig "submission" draft (here https://github.com/b-g-goodell/research-lab/blob/in-prep/publications/bulletins/MRL-0007-multisig/draft/MRL-0007-multisig.pdf )
**\<suraeNoether>** i've gotten one email from someone about key cancellation, which I was able to explain
**\<suraeNoether>** but i'm seeking all sorts of feedback, in particular about the veracity of my proofs
**\<rehrar>** here
**\<suraeNoether>** andytoshi if you wouldn't mind giving it a sanity check read-through and some brutally honest critiques before I push it out the door, I value your opinion. luigi1111 and moneromooo the implementation in the paper doesn't exactly match the code, i'm splitting the code review into a second document
**\<suraeNoether>** other than that, i've just been thinking about how to send an output to a \*subring\* of user keys instead of a single user key. and then any ring signature with a key image from the destination subring has authorization to sign a new signature
**\<suraeNoether>** if i can figure out how to force the square peg/round hole, this is a way to have refund transactions
**\<suraeNoether>** but it's not atrivial problem
**\<suraeNoether>** i'm also thinking about how one could send to a "special" monero adress (special according to some TBD definition) that allows a sort of off-network ledger system to track asset issuance and transfer. sort of monero lightning, but not exactly
**\<suraeNoether>** and the refund addresses are required for that to work out, so... yeah
**\<suraeNoether>** basically, all theoretical week from me for a few days
**\<suraeNoether>** ahrem
**\<suraeNoether>** so, if anyone has any questions
**\<suraeNoether>** we can call this a Q&A or something I guess. :P
**\<suraeNoether>** or if anyone thinks we need to start looking into some specific stuff, we can chat about it
**\<gingeropolous>** are u guys looking into PoW mods / changes / evolution?
**\<suraeNoether>** there is a core team discussion that involves MRL that is kind of ongoing about PoW
**\<gingeropolous>** gotcha. i just didn't know if you've formally looked into some things like ... ah some password hash that hyc brought up, or the thing merkle tree proof thing, etc
**\<suraeNoether>** i haven't looked into any specific stuff recently... but i'm starting to be inclined toward abandoning the idea of asic resistance. in one sense, at least, it's a matter of willfully engaging in an arms race that, 7 years from now, will be (unless something changes) all but unwinnable
**\<suraeNoether>** ah, that password hash document bothers me
**\<suraeNoether>** i need to talk to sarang about it actually
**\<suraeNoether>** it seems like a nice idea because you are 1) hashing 2) an RSA signature
**\<suraeNoether>** there are some issues with trying to boost a low-entropy space like the space of passwords to a high-entropy space
**\<rehrar>** smooth's point that the centralization required to hard fork away from ASIC resistance isn't something that's what Monero stands for long term
**\<moneromooo>** That sounds a lot like "abandoning the idea of freedom".
**\<gingeropolous>** ^^
**\<suraeNoether>** hahahha
**\<suraeNoether>** ok well
**\<suraeNoether>** think of it this way
**\<gingeropolous>** yeah i was gonna say, if your pro asic, then as lord troll dev I banish u
**\<suraeNoether>** lol no no i'm not pro-asic... or rather, i'm not pro-centralization
**\<rehrar>** my opinion: https://www.reddit.com/r/Monero/comments/84vqkt/why\_is\_everyone\_so\_happy\_about\_making\_monero\_asic/dvsy5us/
**\<suraeNoether>** i'm just not convinced that anti-asic = pro-decentralization in the long-run
**\<rehrar>** centralization happens with asic resistance or asic friendliness, just in different ways
**\<suraeNoether>** andytoshi made a very very good argument at one point that the most decentralized a PoW mining scheme \*can be\* is if it's been ASIC'd down to the thermodynamic equilibrium
**\<suraeNoether>** right
**\<gingeropolous>** well, i guess my point was to ask if you've investigated some of the wilder thoughts that have cropped up, like compiling as a PoW
**\<moneromooo>** The long run is different from the near future. You can make different decisions for both, but you can't made decisions for the long term now without knowing how things develop.
**\<suraeNoether>** what i'm primarily concerned about is preserving monero's censorship resistance, antifragility, etc all the buzzwords cryptotwitter loves
**\<suraeNoether>** gingeropolous: i'm always looking into new schemes, if you find one send me a link! i haven't seen anything like compiling as PoW before
**\<gingeropolous>** well no one has
**\<rehrar>** Right moneromooo, which is why I support ASIC resistance in the short term, and probably sometime much further down the road when things have developed quite a bit, ASIC friendliness
**\<suraeNoether>** moneromooo: correct. and in the short-run we have been rather dedicated to foiling ASIC rollouts and this I FULLY support
**\<gingeropolous>** its fresh off the mindspring of the collective
**\<gingeropolous>** so there's no link
**\<rehrar>** if there ever comes a point where ASIC creation and distribution is much more decentralized than today (as determined by...?), then I would be in favor of switching to an ASIC-friendly algo
**\<suraeNoether>** so let me be very clear
**\<gingeropolous>** thats the general idea. I like the metric that fluffypony proposed - when ASICS are handed out as schwag at corporate events
**\<madLyfe>** i can ask PoW and BP question?
**\<suraeNoether>** I'm 100% behind the community's unspoken social contract that the path to centralization (whihc is inevitable) needs to sort of be \*linear\* in the amount of burnt resources.
**\<suraeNoether>** yep madLyfe shoot
**\<suraeNoether>** i feel like that was one of the more fun takeaways from the cryptonote initial design
**\<rehrar>** I think this distinction is important though gingeropolous because otherwise people think ASIC resistance is the be-all-end-all of Monero security. And if they don't realize that it's a means to an end (decentralization and censorship resistance) then if/when we do come to a point that ASIC-friendliness is the better option, there will be hell to pay as people don't understand.
**\<madLyfe>** is it in the cards to move towards CPU only PoW mining for the next HF? and for BPs, is it possible to apply in reverse? or prune? or make the chain size smaller?
**\<moneromooo>** Define "in reverse".
**\<luigi1111w>** not possible
**\<luigi1111w>** possible to prune, absolutely
**\<madLyfe>** well maybe not via BPs but to make the entire chain size smaller.
**\<suraeNoether>** madLyfe: our recent work on the PoW algorithm is intended to foil ASICs that have already been taped out at the factory. the goal is to make monero as close to "all CPU mining" as possible (for the time being).
**\<luigi1111w>** by pruning and certain trust models, yes
**\<suraeNoether>** madLyfe: you mean like compressing the current blockchain? i echo what luigi1111w said
**\<luigi1111w>** well different types of pruning for different trust models, heh
**\<madLyfe>** is there an idea of what % of the chain could be shed?
**\<suraeNoether>** although i'm fairly certain that gmaxwell's original proposal for masking amounts with confidential transactions, where he says that range proofs etc can eventually be discarded... this was a comment intended for a bitcoin-style rollout not a monero style rollout, so i'm not sure how much we'll be able to save on pruning
**\<madLyfe>** ah
**\<suraeNoether>** madLyfe rather than looking at % shaved off the current blockchain, we tend to focus on the marginal improvements like "how much faster or smaller can we make it going forward"
**\<moneromooo>** With 100% pruning I can give you an idea, for a lower bound.
**\<rehrar>** luigi1111w, as I don't have a lot of experience in this, what you're saying is that if a person is willing to trust certain things implicitly, then they are able to prune different parts of the blockchain depending on what things they trust, correct?
**\<suraeNoether>** moneromooo: +1
**\<suraeNoether>** rehrar: that is what luigi1111w is saying yeah
**\<luigi1111w>** rehrar prune at different times
**\<suraeNoether>** well i shouldn't speak for him
**\<rehrar>** that'd be interesting
**\<luigi1111w>** you can prune after verifying
**\<luigi1111w>** or you could "sync pruned"
**\<suraeNoether>** if you are willing to trust the past 3 months of blockchain info, and willing to trust that range profos aren't cheatable, you can get away with checking nothing but signatures for 90 dyas, for example
**\<rehrar>** leave it up to the user to define what they are comfortable trusting and not, with some users choosing max convenience (basically 96%) and some users choosing to verify and store it all
**\<rehrar>** moneromooo, could you give that number? I'd be interested to know.
**\<luigi1111w>** note that basically all users already trust hashes for historical syncing
**\<luigi1111w>** well basically all, I don't have numbers
**\<moneromooo>** Hmm. Looks like 50 GB in prunable stuff. Looks a bit much.
**\<rehrar>** perfect! Let's tell the community.
**\<luigi1111w>** the chain isn't even 50 GB?
**\<luigi1111w>** lol
**\<suraeNoether>** rehrar: while that seems like an interesting idea on the surface, keep in mind we don't necessarily let users select everything based on their trust model. for example, they can't pick a curve with smaller group order because they are so trustworthy.
**\<moneromooo>** It's 58 GB on my disk.
**\<rehrar>** luigi1111w it adds more space to your hard drive
**\<suraeNoether>** although it'd be \*very\* interesting to see a cryptocurrency where each transaction specifies \*everything\* including curves. :P heh
**\<luigi1111w>** .hmm
**\<luigi1111w>** 44.2GB on mine
**\<moneromooo>** Yeah, that sounds a bit wrong.
**\<rehrar>** suraeNoether but is this enforced at a protocol level?
**\<moneromooo>** Ah, but I have a db where I split prunable/unprunable, and I have a prunable hashes table too.
**\<rehrar>** or in our reference client implementations (sorry I am nub)
**\<luigi1111w>** we only have one curve
**\<luigi1111w>** and one group, really
**\<luigi1111w>** so, yes (enforced)
**\<rehrar>** k, if I'm too stupid just pat me on the head and move on :D
**\<luigi1111w>** though one could certainly choose a lower scalar entropy if they desire
**\<luigi1111w>** (ie, they are incredibly stupid)
**\<luigi1111w>** ((yet somehow smart enough to set it up))
**\<anonimal>** X)
**\<suraeNoether>** rehrar: well, think about it like ring size
**\<suraeNoether>** except instead of signer ambiguity, you're looking at transaction validity
**\<suraeNoether>** if you allow users to trust less for greater convenience, you get american airports, TSA, border securiyt, and no more 4th amendment ... ahem what was I saying?
**\<luigi1111w>** that does not sound like greater convenience -\_-
**\<suraeNoether>** ikr?
**\<suraeNoether>** so, i thought zkledger was silly until i realized it could be layered on top of or integrated into most Pedersen-commitment-based cryptocurrencies really nicely
**\<luigi1111w>** moneromooo sorry just saw your comment
**\<luigi1111w>** how can that be that much space
**\<andytoshi>** suraeNoether: sorry, i stepped away. sure i can read over the multisig thing
**\<moneromooo>** I think mdb\_stat is including free space in its pages count. I asked hyc,
**\<luigi1111w>** prunable hashes should be like a few hundred MB
**\<madLyfe>** thanks guys!
**\<suraeNoether>** it allows a user to act like a "depositor" and specify a finite number of "banks" and execute transfers between these banks and prove it is all correct without revealing any information about that. at first i was like "ehhhh seems like a very fixed set-up that requires a trusted third party, etc etc." then i realized this allows a user to (1) declare and issue an asset, (2) declare a finite set of accounts
**\<suraeNoether>** through which this asset will be be transferred, and (3) issue assets and transfer them around between these accounts with zkledger. use case: a large store wishes to issue gift cards. they act like a depositor, depositing XMR into a gift card zkledger, declaring a finite set of banks/accounts, say one for each brick and mortar store, and updates the zkledger offchain with gift card transactions. later, they
**\<suraeNoether>** can close the transaction by auditing the ledger and proving no XMR was created or destroyed.
**\<madLyfe>** moneromooo: so you are saying the chain could be pruned to 17%ish of its current size?
**\<moneromooo>** I am saying mdb\_stat is getting me weird results.
**\<suraeNoether>** madLyfe: the take-away is that we have some pruning available if we had some folks carefully thinking about how to do it. :P
**\<suraeNoether>** we all wear multiple hats here
**\<suraeNoether>** oh ... uh... i guess we can say that concludes the meeting? :P oy, today was quite informal. \</meeting>

101
_posts/2018-03-26-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-03-26.md Normal file
View file

@ -0,0 +1,101 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-03-26
summary: MRL work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<suraeNoether>** Sarang is apparently en route from an airport and is not expected to make it for the meeting. So today i'll just babble a bit
**\<suraeNoether>** and answer questions
**\<rehrar>** Remind me, was he presenting at that Blockchain conference?
**\<suraeNoether>** yes, that's why he's en route from the airport
**\<suraeNoether>** he took it upon himself to disabuse some folks of some certain notions about hashgraph
**\<suraeNoether>** which I think is neat
**\<suraeNoether>** specifically, he's been reading a lot about graph-based currencies, and someone gave a rather misleading presentation, but Sarang's presentation (I believe) preceded it and it was an educational moment
**\<suraeNoether>** but I shouldn't speak for him, I wasn't there. the conference organizers flew him out to give a presentation on behalf of MRL and I have confidence he did a great job representing us
**\<rehrar>** Will it be posted online?
**\<suraeNoether>** he can answer that later today. I don't know.
**\<rehrar>** ok, thanks
**\<suraeNoether>** So, before we proceed, does anyone have any other general questions for MRL?
**\<sgp\_[m]>** Sorry I'm here but mostly distracted by class. Looking forward to hopefully viewing the presentation online
**\<suraeNoether>** ok, neato burrito. So, basically this week I've 1) been putting some copy-editing changes into the multisig paper like spelling and references 2) working on models of the spend-time distributions vs. ring mixin selection distributions, and 3) while driving between albuquerque and denver, I think I came up with a novel ECC signature scheme from one-way functions (staring into the desert sun), but I'm not
**\<suraeNoether>** putting a lot of effort into that until I have more of a handle on spend-time distributions
**\<suraeNoether>** I've also 4) been building the MRL Research Roadmap for 2018. I need to discuss with sarang, but I think we'll be putting that out mid-May, because we want to have a complete look at what's going on
**\<suraeNoether>** uhm, also I've spent an enormous amount of time this week on a certain project for MRL related to churning and the EAE scenario. details to come later on
**\<hyc>** sounds cool
**\<rehrar>** if hyc thinks it's cool, then it's cool
**\<suraeNoether>** hyc and I have been chatting about an asic-unfriendly POW expansion, also
**\<sgp\_[m]>** I'm highly looking forward to seeing your work with EAE
**\<hyc>** yes and I'm now digging back into the bulletproofs paper to try to get more solid understanding
**\<suraeNoether>** namely, if instead of a POW game like: find nonce x such that H(block || x) \* difficulty < target.... we can run a POW game like: find a nonce x such that, for a random bit of javascript J(x) that is loop-free, H(block || J(x))\*difficulty < target
**\<suraeNoether>** this was the idea hyc originally brought to my attention, but verification requires executing the code, so I was thinking instead it could be a random arithmetic circuit instead. then you can present bulletproofs that you know the nonce x such that H(block || AC(x))\*difficulty < target efficiently
**\<rehrar>** oh yeah, I remember you guys discussing something like that. Just to clarify for me cuz it was a bit confusing at the time. The idea is that CPUs and GPUs compile code better than ASICs would, correct?
**\<hyc>** compile and execute
**\<suraeNoether>** the idea is that if the code is random, then an asic will presumably not even be able to compile the code, let alone execute it, but a cpu is built to deal with arbitrary code
**\<suraeNoether>** maybe this is a bad analogy, but I think of an ASIC as a big manufacturing factory, fully automated. it makes lemon cakes. the random code you just spit out asked for a rotisserie chicken
**\<rehrar>** making it so that an ASIC would have to be built with a CPU, which defeats the purpose because might as well have a computer at that point, right?
**\<hyc>** that's the general idea yes
**\<rehrar>** great, I understand now. Thank you for explaining. :)
**\<suraeNoether>** yeah, it shifts the bottleneck away from the highly asic'able hash to finding the nonce for the hash, kinda
**\<suraeNoether>** which is quite clever
**\<endogenic>** hack the planet!
**\<rehrar>** if this idea pans out, we can even do some looking into seeing if the random stuff can do something useful as well?
**\<hyc>** useful?
**\<rehrar>** never mind, this is something I know too little about. Sorry. Plz continue.
**\<hyc>** the code must be highly random and unpredictable
**\<hyc>** if it does something useful, that can be ASIC'd
**\<endogenic>** rehrar: use the heat to warm your chickens
**\<hyc>** there ya go
**\<rehrar>** can the chickens consume the arbitrary code?
**\<ArticMine>** The random code can provide space heating and in many parts of the world that is useful
**\<suraeNoether>** does anyone have any other questions? i can sketch out my new signature scheme if folks are curious, but it'd be more of an algebra discussion. :D
**\<ArticMine>** Sure
**\<suraeNoether>** Cool. So, definition: a cartesian square of groups is a set of four groups and four group homomorphisms arranged in a square satisfying \*one weird property\*
**\<suraeNoether>** https://www.irccloud.com/pastebin/XXZjHHp0/
**\<suraeNoether>** So the square looks like this
**\<suraeNoether>** and the property is this: if group elements from B and C end up \*at the same element\* in D, then they must have \*come from\* the same element in A
**\<endogenic>** scientists hate it!
**\<suraeNoether>** denoting the top map f, the left map g, the rihgt map h, the bottom map j, this means: if there exist some b in B and c in C such that j(c) = h(b), then there exists some a in A such that b = f(a) and c = g(a)
**\<suraeNoether>** so I'm going to set A to be my private key group Zq, and D to be my public key group G
**\<suraeNoether>** and i'll just assume the middle groups B and C are also equal to my public key group
**\<suraeNoether>** then a message M can give me a signature this way: from M, build a one-way map from Zq (private keys) to G (signatures) called SIGN and a one-way map from G (signatures) to G (public keys) called VER
**\<suraeNoether>** to sign the message, I evaluate my private key SIGN(x) and get a group element, my signature. To validate this game from me, I evaluate VER at my signature and check that the result is my public key, VER(SIGN(x)) = X
**\<suraeNoether>** so my signature is SIGN(x) and the function VER
**\<suraeNoether>** each message M has a different pair of one-way functions SIGN and VER
**\<suraeNoether>** to forge this, I need to find a group element S such that VER(S) = VER(SIGN(x)) for someone's honestly computed SIGN(x), but that requires breaking the one-way-ness of all the arrows in my square
**\<suraeNoether>** \*this is all great in theory, but i have no implementation yet. :P\*
**\<suraeNoether>** oh, i missed a word: in the definition of the cartesian square, the diagram has to be commutative. so if I traverse from A to D along one path (through B), I get the same result as if I had traversed the other path (through C)
**\<suraeNoether>** and that is \*critical\*
**\<suraeNoether>** so, to construct an implementation, I need a way to map from message space to the space of one-way group homomorphisms to get SIGN and VER, and then I need to mod out by the ideal generated by all the functions that don't satisfy the cartesian property
**\<suraeNoether>** more recently cartesian squares (mid-late 20th century terminology) have been called "pullback diagrams," and I haven't found any descritpions in the literature of EC-based digital signatures based on them
**\<suraeNoether>** that doesn't mean that this is a novel signature scheme, only that I haven't found any old references to them. I'm emailing around asking folks, and if anyone comes across anything, please let me know
**\<suraeNoether>** to forge this... <--- also, i need to find a message M such that VER is the one-way function derived from M to compute a forgery
**\<suraeNoether>** okay, abstract algebra/category theory lecture done. :P hehe
**\<hyc>** whew ;)
**\<suraeNoether>** ikr what a blowhard
**\<suraeNoether>** also s/game/came
**\<hyc>** I think I missed a part, can you explain again the bit after "now listen carefully" ?
**\<suraeNoether>** "i think a few pages back, you missed a negative and the error propagates. I would have said something, but you were so excited about proving P=NP"
**\<hyc>** lol
**\<suraeNoether>** does anyone have any questions for MRL? I believe sarang is going to be posting another FFS to fund the third audit later today or something?
**\<rehrar>** how much extra is going to be needed?
**\<rehrar>** and did we sign off on anyone getting started already?
**\<suraeNoether>** rehrar I don't know, and I don't know. i believe nioc was encouraging us to not worry about getting it funded and to just post it so we can get the process moving, but I don't want to speak for him.
**\<rehrar>** got it
**\<suraeNoether>** and sarang will be back later today to talk about that
**\<suraeNoether>** days like today, i want to hire a suresh noether
**\<suraeNoether>** okay, next meeting, I want to talk about planning the first monero conference, and planning travel for sarang and i to other conferences between now and then
**\<suraeNoether>** i'm actually attending a bitcoin/blockchain event on april 25 in denver at one of the venues i'm looking at for the monero conference
**\<suraeNoether>** and I have a few meetings next week about it too
**\<suraeNoether>** other than that, I got nothing left to chat about
**\<nioc>** rehrar: I believe Bunz and QuarksLab have already been signed
**\<suraeNoether>** i also want to chat next week about how is everyone satisfied with MRL. I want to gauge the community on direction, depth, breadth, leadership, funding models/goals etc.
**\<rehrar>** cool, thanks nioc
**\<suraeNoether>** so, with that, i want folks to think about what you would say to me if you had me face-to-face. :D
**\<rehrar>** oy, I need to talk with the two of you fairly soon. It's already Revuo time again.
**\<suraeNoether>** rehrar i believe i'm dragging sarang out to denver for that blockchain event. make it up here around that time and maybe we can make it a MAGIC board member meeting + revuo intervuo.
**\<suraeNoether>** we'll drag mike from the moneromonitor by. :P it'll be historic~
**\<suraeNoether>** \</meeting>

235
_posts/2018-04-02-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-04-02.md Normal file
View file

@ -0,0 +1,235 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-04-02
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<suraeNoether>** meeting time!
**\<antw081>** i think he is attributing research to his imaginary R&D research group
**\<sarang>** If he's claiming they're doing the "improved" CT then I am not concerned at all
**\<sarang>** because that's junk
**\<antw081>** FFS he is known to basically hate Monero
**\<suraeNoether>** allrighty, 1) Greetings everyone, 2) what MRL has been up to, 3) what we plan on getting up to. i know it's a really loose agenda, but hey
**\<antw081>** FFS = FYI
**\<sarang>** monero loves him too
**\<suraeNoether>** so, hi!
**\<suraeNoether>** who's all here?
**\<rehrar>** Cat of the week, sarang?
**\<ArticMine>** hi
**\<rehrar>** also, I'm here.
**\<sarang>** He's hiding out in the clothes dryer now
**\<sarang>** and I'd have to get a photo and scrub the metadata first
**\<oneiric\_>** hiyo :)
**\<koe>** hi :)
**\<hyc>** 12 monekys more like
**\<hyc>** 12 monkeys was a pretty good film tho
**\<suraeNoether>** allrighty: sarang, what have you been up to?
**\<suraeNoether>** https://imgur.com/a/gpv13
**\<sarang>** A lot of paper reading to stay up to date and learn, released my monthly report on r/Monero and FFS, checking up on moneromooo's recent addition of batch verification to his BP code and tests
**\<sarang>** Trying to stay afloat with Son of Monerolink
**\<sarang>** Seems to be a lot of putting out small fires that idiots start
**\<hyc>** Matthew Green all proud of himself about that
**\<sarang>** My gods the press coverage has been abysmal
**\<sarang>** and much of it by people who should absolutely know better
**\<sarang>** Schneier basically said HEY LOOK A THING I SAW ONLINE
**\<koe>** negativity sells on a bust
**\<ArticMine>** but only for a while
**\<suraeNoether>** This past week I've been working on reviews to the multisig paper. andytoshi has provided me some comments and I'm making some changes consequently
**\<koe>** what is your timeline for release?
**\<sarang>** What sorts of changes? I'm curious
**\<suraeNoether>** the paper in its current form is already on github koe, changes will be uploaded by the end of the week I think
**\<suraeNoether>** the main large-scale complaint is that I specify stuff that could be chalked up to secure side-channels, and there is some back-and-forth discussion about using fresh multisig keys versus salting and hashing your current user keys
**\<koe>** oh I dont see it in MRL, is there another spot?
**\<sarang>** True, there were plenty of discussions during the development about the nature of secure communication between coalition members
**\<sarang>** I'll be curious to see what updates you make from it
**\<suraeNoether>** sechttps://github.com/b-g-goodell/research-lab/tree/in-prep/publications/bulletins/MRL-0007-multisig
**\<suraeNoether>** whoops
**\<suraeNoether>** https://github.com/b-g-goodell/research-lab/tree/in-prep/publications/bulletins/MRL-0007-multisig
**\<koe>** cool thanks :)
**\<sarang>** Tell us about fresh keys vs salting
**\<suraeNoether>** if the hash function is good, no one could tell the difference between using fresh keys or using hashed ol keys, and the reason to not re-use old addresses is to prevent exclusion attacks where two coalitions collude to remove control of some common coalition members... but if the old keys have been hashed with new salts, that isn't a danger with a good hash function. so ...
**\<sarang>** right...
**\<suraeNoether>** for convenience to users, i think it's okay to re-use keys this way, but to describe the scheme for the paper and make it more clear, readable, compact, etc, I think i agree with andytoshi that the salted-then-hashed keys can be at least moved to the end
**\<suraeNoether>** as a "if users really want to do it this way, they can do it" sort of thing as opposed to built into the scheme
**\<suraeNoether>** it will make it easier to prove secure too
**\<suraeNoether>** andytoshi had a variety of other very helpful comments. i'm most concerned about my unforgeability proof at this point, and revisions are still happening.
**\<sarang>** roger
**\<suraeNoether>** in addition to all that, i invented what i think is a novel signature scheme in the elliptic curve setting. depending on construction, the security can fall onto the existence of one-way 2nd pre-image resistant group isomorphisms, instead of the discrete log hardness assumption
**\<hyc>** going for QC-resistance?
**\<suraeNoether>** current draft descritpion is here; an implementation requires, i think, a really freaking large group, though
**\<suraeNoether>** hyc no, just had a dream one night. :P
**\<suraeNoether>** https://www.sharelatex.com/project/5ab98a71234cc910159f828b
**\<sarang>** Did you make updates to it since you first showed me?
**\<suraeNoether>** it's been undergoing pretty much constant revision, i don't recommend anyone read it yet. you have the basic idea from the first read-through and until stuff is more formal, it's just me messing around
**\<suraeNoether>** it'd be nice to be able to pick some folks brains \*in person\* at a whiteboard, though
**\<sarang>** always is
**\<rehrar>** suraeNoether: will you bill for your sleeping time since you seem to work then also?
**\<suraeNoether>** i know andytoshi isn't a formal contributor to MRL, but we enjoy his assistance an awful lot around here...
**\<suraeNoether>** and since this is a research meeting, andytoshi, would you feel comfortable going over your BP work again for those who missed it earlier?
**\<suraeNoether>** rehrar: i don't bill by the hour, which is why i can't put work down ever
**\<hyc>** any chance andytoshi will co-author any papers with you?
**\<suraeNoether>** hyc maybe if i write something worth publishing. :P oh! my last paper from grad school has been thrown up on arxiv and is seeking publication. not technically an MRL accomplishment, but my co-author let me know he put it on arxiv and submitted it
**\<suraeNoether>** nuts, i wanted to chat with hyc about random-code POW
**\<sarang>** Any other updates?
**\<suraeNoether>** Not from me, not about MRL or research. If anyone has any other research projects they have been working on/would like to discuss, fire away...
**\<suraeNoether>** or any questions, etc
**\<sarang>** suraeNoether had mentioned an upcoming conference very relevant to our interests
**\<antw081>** do you actually get informed if someone references your work in white paper?
**\<sarang>** Depends on how they're released
**\<antw081>** ok
**\<sarang>** Google Scholar can pull citations from a lot of formats, for exampl
**\<suraeNoether>** antw081 google scholar tracks citations of whitepapers and you can set up alerts.
**\<sarang>** but for informal non-cached stuff, not necessarily
**\<suraeNoether>** Ah, yeah, so there's this conference in London in 2 weeks. I would normally just buy tickets and go and then start an FFS for reimbursement (if possible) but tickets are A LOT more than they were when I did the same thing for Switzerland.
**\<suraeNoether>** and I don't want to just impulsively go to conferences last minute
**\<sarang>** you should send meeeee
**\<sarang>** It is a lot though for a one-day
**\<sarang>** suraeNoether: link?
**\<sarang>** looks like good talks relevant to cryptocurrency privacy
**\<suraeNoether>** yes, and the first MAGIC board meeting is in a day or two after that conference
**\<sarang>** and that's kind of our specialty and junk
**\<suraeNoether>** http://ieee-sb2018.cs.ucl.ac.uk/#schedule
**\<sarang>** I was totally unaware of this event until earlier today
**\<suraeNoether>** so i'm okay with not going to it, but \*i'm totally willing to hop on a plane and jet lag myself later this month\* if that is what this community wants from me. i'm your humble servant, as it were. :P
**\<suraeNoether>** \*on that note\* I would like to start an MRL calendar or something like that, where we throw up big research conferences in bitcoin, blockchain, cryptocurrencies, and infosec, and our travel plans
**\<suraeNoether>** any time \*anyone\* sees a conference or an event i htink it'd be cool if folks started to just passively populate this calendar
**\<sarang>** Just use Github issues?
**\<antw081>** FFS it, it will get funded
**\<sarang>** I think it'd be excellent to go
**\<suraeNoether>** antw081 and if it doesn't, we just simply won't go. :P
**\<sarang>** I haven't done an international conference for MRL =p
**\<suraeNoether>** sarang: start an FFS for both of us, whydon'tya
**\<sarang>** Wish it were a longer event though, we could talk about this stuff forever
**\<sarang>** sure thing
**\<antw081>** FP, FFS a speaking tour, it was funded in no time.
**\<sarang>** I find it funny to see Monero talks and not know about the contents in advance 0\_0
**\<suraeNoether>** besides, i would like to be able to chat with some of the organizers in person, since i want to organize a conference for next year
**\<sarang>** suraeNoether: we can chat after meeting about the FFS detais
**\<sarang>** see what the community thinks
**\<suraeNoether>** okay, let's see here... we've covered research, travel, a bit of MAGIC...
**\<suraeNoether>** later today i'm writing up my FFS end-of-month summary...
**\<sgp\_[m]>** What's the approx expense?
**\<rehrar>** sgp\_[m]: will sponsor you
**\<suraeNoether>** sgp\_[m]: tickets alone for me are 2400USD. doesn't include loding
**\<sarang>** Airfare for me would be ~1500-1700 USD
**\<suraeNoether>** lodging\*
**\<sarang>** This one is not cheap, that's for sure
**\<suraeNoether>** Okay, the last thing I wanted to chat about
**\<suraeNoether>** is \*next year of MRL\*
**\<suraeNoether>** for those of you who recall correctly, I began in June of last year,
**\<suraeNoether>** aaaand
**\<suraeNoether>** well, I want to know how folks like the direction we are going, see if anyone thinks we should be taking different directions, perhaps see how community members feel about our resources
**\<rehrar>** oh shoot, it's time for another Revuo already.
**\<ArticMine>** My take is that MRL is on the right track
**\<rehrar>** I think MRL is doing good stuff. Happy with you guys.
**\<suraeNoether>** I wouldn't mind hiring an additional researcher or two. but I don't want to overly burden the community, though, and
**\<suraeNoether>** it reminds me of a story, I have no idea who told it to me
**\<suraeNoether>** but you tell two guys to go dig a ditch and everything is fine. you later hire a third guy to help and tell him he's in charge of the first two and all work totally stops
**\<suraeNoether>** or send a third guy over and have one of the first two guys be in charge, same thing happens
**\<suraeNoether>** I'm not sure how sarang feels bout hiring additional folks, if he feels like we could use a person for specific things or not, etc
**\<antw081>** we can do grants maybe? to do research on Monero related topics
**\<sarang>** When I started shortly after suraeNoether, our goals seemed pretty broad: figure out what we're doing right, correct what we're doing wrong, and figure out what comes next. The way we're funded always makes me feel guilty about providing good deliverables, but I think the community realizes that's not necessarily the point
**\<rehrar>** that's an interesting idea antw081. More on a contract basis for specific stuff.
**\<ArticMine>** but this begs the question do we want to dig a second ditch
**\<suraeNoether>** antw081: that's sort of hard to fund on a per-project basis.
**\<suraeNoether>** ArticMine: +1 heh
**\<suraeNoether>** so, the thing is
**\<antw081>** it can be general fund
**\<antw081>** like HackerOne
**\<rehrar>** question, would a third researcher have unique things to do, or just be another set of eyes on the current stuff?
**\<antw081>** or Bug Bounty FFS
**\<sarang>** That also begs the question: what would that mean for my role? Or suraeNoether ?
**\<sgp\_[m]>** I think grants make the most sense for additional research. Get some people to focus more formally on specific research
**\<sarang>** Should we move to a per-project funding too/
**\<rehrar>** I don't think so sarang
**\<antw081>** ok i gut to ask
**\<rehrar>** I think having two general researchers that do what they feel needs to be done is beneficial
**\<antw081>** is there like a group of cryptographers called the: Is there an organisation called Chainmasons?
**\<sarang>** ?
**\<koe>** lol
**\<antw081>** sorry: Chainmasons
**\<antw081>** what is that
**\<sarang>** rehrar: I ask because I want to ensure suraeNoether and I are providing value to the community
**\<oneiric\_>** sarang + suraeNoether = 33rd degree Chainmasons
**\<antw081>** his guy claims to have formed a group of researchers - referred to as Chainmasons
**\<rehrar>** In my personal opinion, you the four full time hired people, you two, mooo, and anonimal are good four cornerstones for teh community
**\<antw081>** his = this
**\<koe>** it seems like if the MRL didn't exist, Monero would feel a lot more precarious and purposeless
**\<antw081>** https://bitcointalk.org/index.php?topic=3118418.msg32233166#msg32233166
**\<sarang>** I view part (certainly not all) of my value as staying afloat of new developments that we don't necessarily have specific projects for
**\<rehrar>** yes, this is important
**\<koe>** like, shouldn't there obviously be research into privacy for a privacy focused crypto?
**\<rehrar>** Monero does not necessarily equal ring sigs, ringct, and stealth addresses
**\<sarang>** koe: A lot of good research happens academically too
**\<sarang>** not affiliated with anyone
**\<sarang>** We often use that work (e.g. BPs)
**\<sgp\_[m]>** I think at the moment you all are more responding to other research, changes, and looking into thoughts people have. There's definitely value there, but there's also value in allowing people to be focused on certain projects.
**\<koe>** yeah, but the MRL cares about making that stuff apply to Monero
**\<rehrar>** I may not speak for the community though, since I'm a privacy idealist, and this stuff you guys do gets me excited :D
**\<sarang>** sgp\_[m]: definitely
**\<suraeNoether>** so, the reason i bring all this up is this
**\<rehrar>** if I had one comment though it would be this:
**\<sarang>** When I came on, there were some specific projects in that realm, like sublinear ring sigs, but more kept getting added to our plates
**\<sgp\_[m]>** sarang is the intent for MAGIC to provide research grants? Eg: support one group taking a deep dive into the effectiveness of churning
**\<rehrar>** I think time should be split fairly evenly between new research, and improving the privacy and security of the stuff we already have implemented. As an example, and as I have stated before, I think designated research into optimal ring sizes, fixed ring size vs non, and other stuff of that nature should be a higher priority than it currently is.
**\<sarang>** MAGIC is definitely intended to provide research grants as part of its mission
**\<sarang>** rehrar: agreed, but it sucks that these things are often not so neatly delineated
**\<rehrar>** I understand.
**\<suraeNoether>** if i was hired at a university and got a big grant, or if i was hired at a big company and had resources, i would write a budget, hire folks, get a proper lab going where representatives from the lab regularly travel to represent the lab and disseminate results, etc etc. very very different approach from getting hired at a small start-up
**\<suraeNoether>** and i feel like sarnag and I have spent the first year treating MRL sort of like the start-up approach
**\<suraeNoether>** but maybe there is a middle way
**\<sarang>** that's a good analogy
**\<sarang>** The specific goals were much smaller back then
**\<suraeNoether>** rehrar: MAGIC can give research grants, but not to open-source software projects (non-profits in america cannot touch OSS)
**\<sarang>** Now we have more irons in the fire
**\<ArticMine>** One thing to keep in mined is that this is a very fluid situation
**\<sarang>** ArticMine: how so
**\<ArticMine>** A significant change in XMR/USD
**\<suraeNoether>** yeah, if the market bottoms out further over the next six months, buttholes will get progressively tighter
**\<sarang>** true
**\<suraeNoether>** or vice versa, we'll go full goatse at 12,000 USD/XMR
**\<antw081>** true
**\<ArticMine>** ... and there is also the flipside
**\<sgp\_[m]>** As an non-researcher, I think the "best" way forward is to balance both. I think the project will demand that it becomes more formalized
**\<rehrar>** this is an important thing to consider. The FFS, while working so far, has shown some signs of beginning to sit down to catch its breath
**\<suraeNoether>** rehrar Yeah, pockets aren't infinitely deep
**\<sarang>** So we'd have to consider the carrying capacity of the funding network
**\<rehrar>** this applies to all sorts of people who want to put out more 'FFS propoasls'
**\<rehrar>** I think as a community we need to gauge what proposals are really worth funding
**\<suraeNoether>** at the very least, we have 2 months to sort of figure out \*whether\* or \*how much\* our directions shall shift for the second half of 2018. not a super urgent conversation, and 2 months is an eternity in cryptocurrencies
**\<sgp\_[m]>** There should be a need for people to do what you both do right now
**\<sarang>** I constantly worry that my FFS will be the last to get fully funded :/
**\<sgp\_[m]>** But I expect future grant-based research to be more specific
**\<rehrar>** ye, no job security is indeed one of the downsides of changing the world :P
**\<suraeNoether>** sarang: same, i'm actually regularly worried fluffypony is going to text me a big unhappy horse pic
**\<suraeNoether>** so we'll table this discussion for now
**\<nyeaa>** If I may offer the perspective of an outsider: It is often quite hard to even grasp where to start research, maybe having a list of problems that need to be solved could give more people the opportunity to contribute. We could then just reward people when they solve a problem, based on how hard the problem is. this way anyone can give it a shot without entering a paid commitment, but with the certainty that they will be
**\<nyeaa>** paid for their work if they are successful
**\<suraeNoether>** oh, hi heh
**\<sarang>** This line of reasoning isn't new at all. There are camps that value more "open-ended" research because it often contributes in novel ways, and camps that really want to push specific projects that may or may not have return due to their specificity
**\<suraeNoether>** nyeaa merely formalizing our problems and characterizing whatever constitutes a solution is a monumental task in itself. :\\
**\<rehrar>** m2049r[m] is facing a similar issue with his FFS proposal
**\<sarang>** suraeNoether: many of our open questions on things like churn, optimal ring size, fixed vs variable, are partly due to a lack of formalization of attack vectors IMHO
**\<sarang>** our attack surface is much different than other projects
**\<sarang>** thanks to ring sigs and key images
**\<rehrar>** can't just fall back on all the work done on bitcoin...again
**\<sarang>** Maybe this also speaks to the need for suraeNoether and I to devote less time to new broad ideas and more to existing fiddly problems
**\<rehrar>** with a fraction of the third party interest
**\<suraeNoether>** fwiw i am willing to throw some xmr at m2049r[m] but that's aside the point.
**\<rehrar>** he really is quite amazing, isn't he? Did alone what nobody did.
**\<rehrar>** popped out of nowhere :D
**\<Inge->** I feel a lot mor comfortable using XMR with monerujo than I do using bitcoin.
**\<rehrar>** clock is ticking, our time is limited boiz
**\<suraeNoether>** allrighty, let's conclude with this
**\<rehrar>** (in regards to FFS)
**\<suraeNoether>** Anyone who is willing to take out Issues on the MRL github for upcoming conferences will be rewarded with admiration
**\<suraeNoether>** end of the week we should have another iteration of the multisig paper to read
**\<rehrar>** admiration. A new coin...or...?
**\<endogenic>** nobody
**\<suraeNoether>** i got a document camera for making whiteboard videos, too, forgot to mention that
**\<endogenic>** monero: nobodycoin
**\<suraeNoether>** okay \</meeting>

145
_posts/2018-04-09-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-04-09.md Normal file
View file

@ -0,0 +1,145 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-04-09
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<sarang>** Let's start our abbreviated meeting presently
**\<suraeNoether>** hey everyone
**\<suraeNoether>** i'm surae
**\<suraeNoether>** this is sarang
**\<sarang>** attention all aircraft, research meeting now
**\<suraeNoether>** we do maths sometimes, and math other times
**\<keatonofthedrake>** :D
**\<sarang>** When you travel to Europe, you have to surrender the "s" at immigration
**\<rehrar>** yay
**\<sarang>** before leaving
**\<suraeNoether>** Okay, I've been working on a churn model, as I mentioned before, and the idea is reducing to this: if there is a proportion $p$ of poison outputs and everyone uses ring size $R$ then the probability that the first poison output appears at height H in the transaction tree is easily computable: for P(H=1) = 1-(1-p)^R and for h > 1, we have P(H=h) = (1-p)^(f(h))\*(1-(1-p)^(R^h)) where f(h) = R^(h-1) + R^(h-2) +
**\<suraeNoether>** ... + R... reduces to f(h) = ((1-R^h)/(1-R)) - 1. So we want to pick a probability alpha describing type I error and we want to churn for some height H so that P(H=1)+...+P(H=h) > 1-alpha
**\<suraeNoether>** this ensures that at least 100\*(1-alpha)% of the time, some poison output appears before your churned output
**\<sarang>** Now, does height delay work into this model?
**\<suraeNoether>** not used at all
**\<sarang>** In case I want to delay or space my churns
**\<sarang>** Is this because you assume uniform fraction of poisoned outputs over time?
**\<suraeNoether>** that will probably help protect against temporal association, but the model of transaction i'm using doesn't take age of ring signatures into account at all
**\<suraeNoether>** right
**\<suraeNoether>** but essentially, if you can churn deeply enough so that other poison outputs are more likely to be implicated than the one you are really spending, i suppose that's the best you can really hope for lacking a more rigorous analysis
**\<scoobybejesus>** not sure i've seen you folks define "poison outputs," though i suspect one could make a pretty approximate guess as to the definition
**\<sarang>** Outputs controlled by Eve, who can identify them as such
**\<smooth>** stating it adversarilly is probably more useful than uniform. assume there might be some poison outputs in whatever time period you as the target are concerned with (since you don't know there aren't)
**\<scoobybejesus>** ty
**\<suraeNoether>** so, to give an idea, even with a ring size of 5, you can churn 8 or 9 times and an attacker with between 1-in-a-million and 1-in-a-thousand poison outputs and the attacker will see a fake poison output before the real one
**\<smooth>** seeing fake one before real one say 50% of the time is probably good enough
**\<suraeNoether>** at least it provides us an actionable suggestion
**\<sarang>** right
**\<suraeNoether>** the good news is that churn doesn't appear useless except against extremely powerful attackers
**\<sarang>** defined as?
**\<suraeNoether>** high proportion of poison outputs
**\<sarang>** defined as?
**\<smooth>** all except yours :)
**\<sarang>** lol
**\<smooth>** even works against zcash
**\<smooth>** those powerful attackers are a real pita
**\<suraeNoether>** if an attacker has poisoned 1-in-a-thousand outputs in a large subset of the blockchain, i would call that attacker powerful
**\<smooth>** really? that's only like 2 per day right?
**\<smooth>** well now at least, with low usage
**\<suraeNoether>** maybe the word powerful is misleading people. let's say "determined."
**\<sgp\_[m]>** Yeah, 1 in 1000 is relatively easy to get...
**\<suraeNoether>** yeah, but 75% isn't hard to get either, for short periods of time
**\<smooth>** 2 per day could be more like 'what the hell, ill give it a try and see what i figure out'
**\<sarang>** I'll be really interested to read the writeup with the deets!
**\<sarang>** Other comments, in the interest of staying abbreviated today?
**\<suraeNoether>** write-up by the end of the week
**\<sarang>** sexcellent
**\<suraeNoether>** oh, also, the first board meeting of MAGIC is being held at the end of this month, April 27 in denver. the board members (minus one) are all going to be there: me, sarang, my wife, rehrar, and sgp. if anyone happens to be in the area, feel free to lmk and we can all go out to lunch or whatever
**\<sarang>** looking forward to it
**\<koe>** btw, I finished rewriting that monero report. would anyone mind reviewing it? https://github.com/UkoeHB/Monero-RCT-report
**\<rehrar>** creepy
**\<suraeNoether>** koe great, i will try to read through it this week
**\<koe>** cool thanks suraeNoether :)
**\<rehrar>** multisig paper?
**\<sarang>** koe: many changes?
**\<koe>** yes
**\<sarang>** OK, will run a diff to see
**\<rehrar>** (status, I mean)
**\<suraeNoether>** rehrar: making edits and waiting on comments from two folks. "in progress"
**\<rehrar>** kthx
**\<koe>** there were some theoretical errors, i reworked the notation scheme, added subaddresses and a summary chapter, and generally revamped everything to communicate better
**\<sarang>** nice!
**\<koe>** er summary section not chapter
**\<sarang>** Funding is open for IEEE workshop later this month: https://forum.getmonero.org/8/funding-required/90165/noether-brothers-ieee-workshop
**\<rehrar>** sarang were you planning on funding for Defcon?
**\<koe>** and about 30-40 footnotes trying to explain eveyrthing to laymen
**\<sarang>** rehrar: I wasn't sure what the overall funding plan for DEF CON was
**\<sarang>** it seemed a bit up-in-the-air
**\<rehrar>** should be discussed sooner rather than later
**\<sarang>** agreed, but in the context of everyone
**\<rehrar>** ye
**\<sarang>** Plan is (ideally) for me to give a talk at the village on our crypto/math
**\<sarang>** and touch on new developments and ideas
**\<rehrar>** suraeNoether: coming?
**\<sgp\_[m]>** koe this looks great
**\<koe>** also, I should have a plan ready for the FMEA meeting that I mentioned last week, within a day or two (fingers crossed)
**\<sarang>** cool
**\<sarang>** koe: I'm curious, what's your background?
**\<koe>** thanks sgp\_[m] :) if you have any comments let me know, I want it to be as perfect as possible
**\<suraeNoether>** rehrar yeah, i'm opening a window to get tickets so i don't forget
**\<rehrar>** noice!
**\<koe>** mechanical engineering
**\<sarang>** a solid discipline
**\<sarang>** Any other items to discuss? We touched on churn, koe's updates to the kurtmagnus paper
**\<rehrar>** wathoo been doing?
**\<rehrar>** \*watchoo
**\<sarang>** a lot of reading on zero-knowledge schemes and arithmetic circuits to familiarize myself with recent progress
**\<rehrar>** sarang, I mean :P
**\<rehrar>** thank you, no more questions, your honor
**\<sarang>** getting back into some tests for multiexp optimizations
**\<sarang>** in prep for the BP finalization
**\<sarang>** it would be nice to have those operations optimized for the next network upgrade when we deploy BPs
**\<sarang>** suraeNoether: if you want another set of eyes on churn (or other help with it) let me know
**\<nioc>** more than nice
**\<sarang>** nioc: but it's worth noting that those aren't consensus related
**\<nioc>** yes
**\<sarang>** and even with the two optimizations I worked with mooo on, we're much faster than we used to be
**\<nioc>** still most people only upgrade wen they have to :)
**\<sarang>** we now use either bos-coster or straus
**\<sarang>** these operations are also really only relevant if you bring a new node up and need to process the whole chain going forward
**\<sarang>** the nice part is they're general and not BP specific
**\<moneromooo>** Aggregated verification is relevant for keeping up with new blocks too.
**\<sarang>** moneromooo: true, but less of a bottleneck
**\<sarang>** also thanks to moneromooo for doing the codebase integrations for the optimizations so far
**\<suraeNoether>** sarang for sure i will real soon
**\<suraeNoether>** so this is really interesting
**\<suraeNoether>** so, the PMF for these distributions is highly unimodal and very ... spikey. low variance, heavy tails. it's like there's a step function at a critical depth in a tree. before the step, poison outputs are rare, and after the step, poison outputs are super common. very very helpful property
**\<sarang>** absolutely
**\<sarang>** gradual changes make it difficult to establish cutoffs
**\<suraeNoether>** ok so here's some sample numbers
**\<sarang>** yes plz
**\<suraeNoether>** ring size 15, attacker proportion 10%, it is all but certain a poison output appears either in the first ring signature or in the layer of second ring signatures; in this scenario, churning twice or three times is all that's necessary for the attacker to see some decoy poison output first before the true spender
**\<sarang>** UkoeHB: usual terminology is "cyclic group", not "cyclical"
**\<gingeropolous>** what fixed ringsize do u think we can pull off once BP is in?
**\<suraeNoether>** ring size 5 and poison proportion 0.0001, it is all but certain an attacker will see a poison output before layer 6, so churning 6 or 7 times is all that's necessary
**\<sarang>** Do you mean, in order to maintain the same tx size as right now?
**\<gingeropolous>** i mean, will be optimal. optimal verification speed, size, privacy
**\<sarang>** Well, there's a subgroup of users for whom "optimal" means "tiny in size"
**\<suraeNoether>** right
**\<suraeNoether>** so, gingeropolous
**\<UkoeHB>** are you referring to a level of churn that puts a churner at max 'anonymity set'? ie the whole pool of txo
**\<gingeropolous>** i mean, cause we're kicking the tires on a fixed ringsize right?
**\<suraeNoether>** if blockstream mathemagics their way into BP sublinear ring signatures like the RTRS sigs, or some sort of hash tree or something ... then we can get pretty big rings for the same current size, verification speed, etc
**\<suraeNoether>** UkoeHB: the maximum anonymity set is trivial: keep churning forever and don't stop
**\<suraeNoether>** who knows if that'll happen any time soon, though
**\<gingeropolous>** ok, so in the absence of mathemagic , is there a proposal for a fixed ringsize for v8 fork?
**\<suraeNoether>** there are more clever statistical tricks that could be used to link monero transactions, though, this is simply an eyeball metric
**\<UkoeHB>** maybe: 'makes a churner indistinguishable from most unrelated people'?
**\<suraeNoether>** gingeropolous: to fix ring size? i always advocate it. a formal proposal? not really, not yet
**\<suraeNoether>** UkoeHB: well, i don't necessarily think that's a good description either. i said what I meant: if you churn this amount, the attacker is more likely to see a decoy poison output appear in the transaction history before the true spender. whether that translates into indistinguishability from an innocent spender is a very different animal...
**\<suraeNoether>** and not only that, the statistical test i came up with the other day didn't take into account \*how many\* of some outputs even had poison outputs in their history.. this influences the test quite a bit
**\<suraeNoether>** but coming up with a really powerful statistical test would require strong assumptions on properties of transaction history trees, and i'm not sure that any assumptions are time-invariant (economic conditions influence a lot about how money moves)
**\<UkoeHB>** hmm ok, so preliminary work before discussing implications
**\<suraeNoether>** so "for now" this is "good enough" and these "air quotes" are somewhere between irony and not really believing what i say. :P i know of a handful of folks who are working on de-anonymization techniques for anonymity sets up to sizes like 50-100, so whatever sort of unlinkability we are buying here is strongly provisional on the analytic capability of the attacker
**\<suraeNoether>** yeah

109
_posts/2018-04-16-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-04-16.md Normal file
View file

@ -0,0 +1,109 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-04-16
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<suraeNoether>** allrighty
**\<suraeNoether>** well hello everyone
**\<suraeNoether>** oh man how could i forget hyc
**\<sarang>** grettings
**\<suraeNoether>** Sarang, you want to kick us off? What have you been working on?
**\<sarang>** Sure
**\<sarang>** I've been working on the churn analysis paper suraeNoether began, looking at definitions and models etc.
**\<sarang>** The paper on FruitChains was also brought to my attention again
**\<suraeNoether>** this is my first time seeing it
**\<sarang>** It's an interesting scheme intended to reduce the effectiveness of pooled mining
**\<sarang>** there's an overhead in block data, unfortunately
**\<suraeNoether>** interesting
**\<sarang>** but it ensures more fair mining and reduces the effectiveness of selfish mining attacks
**\<sarang>** What isn't as clear is the way reward incentives are done, since it's a sort of distributed reward system
**\<sarang>** We did a review of our JS PRNG
**\<sarang>** after a posting on some shitty ones (we're fine)
**\<suraeNoether>** yes! such drama haha
**\<sarang>** Looked at zerocoin attacks
**\<sarang>** and more of the usual audit administrivia
**\<sarang> \</update>**
**\<suraeNoether>** how is the audit going?
**\<suraeNoether>** what stage of the process are we at for each auditor?
**\<sarang>** As planned; we're in the queue for each reviewer
**\<sarang>** I have a kickoff meeting w/ Kudelski tomorrow morning
**\<suraeNoether>** i think this might be the first time we'll actually end up getting this discussion into the meeting notes on github
**\<sarang>** I will say that the FruitChains idea is intriguing if only because of the disincentive to pooled mining
**\<sarang>** especially after our ASIC shenanigans
**\<sarang>** the paper says "orange is the new block"
**\<hyc>** I see the resistance to selfish mining as pretty important too
**\<sarang>** Oh yes, that property is also nice for sure
**\<suraeNoether>** hyc i agree, especially after seeing a huge ecology of selfish mining and block withholding attacks at BPASE
**\<hyc>** also, BTC is unlikely to ever pursue it. "Too complicated to code"
**\<suraeNoether>** cool beans, cool beans. i've spent the past month basically reading crypto papers, writing code, and writing papers. i'm now back knee-deep in multisig, and i think i'm going to make some recommendations for changes instead of trying to merely describe our current system, since the c++ review was going to be in a second paper anyway...
**\<suraeNoether>** but in the past few weeks, i invented a signature scheme. i lack an implementation, but i am still going to seek publication (because maybe someone else can come upw ith an implementation)
**\<sarang>** In the grand scheme of things, the addition of fruits isn't a \_huge\_ overhead in space, but it'd need to be considered
**\<sarang>** What's the coding you're up to suraeNoether ?
**\<suraeNoether>** anyone curious about that can see it here: https://www.sharelatex.com/read/sbjpykftgxkn ...
**\<suraeNoether>** still doing the Poisson graph simulation thing in the evenings
**\<sarang>** sounds like an excellent work-life balance =p
**\<suraeNoether>** in addition to that, I started writing up some notes on using a Kolmogorov-smirnov test as a basis for difficulty adjustment... and then i realized it'd be nice and fun to write a "difficulty adjustment as a statistical inference problem" paper
**\<suraeNoether>** and with those sims, i'll be able to test various hypotheses about UMVUEs and such
**\<suraeNoether>** but that's sort of my side thing the past few weeks. i've been putting a lot of energy into churn and multisig
**\<koe\_>** surae is there an updated multisig pdf I can look at?
**\<koe\_>** the one from a month ago has some issues but if you fixed them then all good
**\<suraeNoether>** koe\_ wednesday. and yeah, there have been some drastic changes since then
**\<hyc>** difficulty? have you been talking to @zawy12 ? https://github.com/monero-project/monero/pull/2887
**\<suraeNoether>** hyc i've read through a lot of that, and zawy12 will be heavily cited in my work
**\<hyc>** cool
**\<suraeNoether>** let's see here...
**\<suraeNoether>** I've also spent time organizing the first board meeting for MAGIC, April 27 in Denver. sgp and rehrar and myself and sarang and my wife will all be there, and we'll be doing it at one of the possible monero conference locations so we can kinda scope it out
**\<suraeNoether>** maybe we'll all go out and look at several locations and take pictures and rate the places by ratio of distance-to-taco-place by distance-to-hotels
**\<sarang>** yessir
**\<suraeNoether>** oh, and effing taxes
**\<sarang>** Aren't those fun?
**\<sarang>** Any updates from others?
**\<hyc>** last weekend I cobbled together my PoW PoC
**\<hyc>** literally slapped together while reading a tutorial on JS syntax
**\<suraeNoether>** gonna fork monero? do an airdrop?
**\<rehrar>** I wanted to launch hyccoin from it, but he wasn't ecstatic about it
**\<koe\_>** it would be nice to publish my report on transactions soon, if surae can get a chance to look through it this week
**\<suraeNoether>** give me a link right quick
**\<suraeNoether>** i'll add it to my high priority before Wednesday thing
**\<koe\_>** https://github.com/UkoeHB/Monero-RCT-report
**\<hyc>** in the next couple weeks I plan to rewrite it into something closer to production quality. the current version produces wildly inconsistent random programs (very small to very large) and we want something a bit more uniform in length/runtime
**\<sarang>** koe\_: it's a nice update
**\<suraeNoether>** oh koe wait are you kurt magnus also? or are you two just collaborating?
**\<koe\_>** ill add some edits ive made over the last week soon, so its all up to date
**\<koe\_>** I took over the report ffrom him
**\<koe\_>** haven't heard from him in weeks idk
**\<suraeNoether>** huh.
**\<suraeNoether>** Okay, so, basically my whole life right now is dedicated to 1) multisig, 2) reading koe's thing by wednesday, and 3) getting ready for LONDON NEXT WEEK
**\<suraeNoether>** oh my GOD you community members who donated ROCK and kick ASS
**\<sarang>** ^
**\<sarang>** I'll put on my Fancy Jacket so I can represent us well
**\<suraeNoether>** If anyone is going to find themselves in london on Monday next week
**\<rehrar>** hyc, when you do that, can we launc the test coin? :D
**\<suraeNoether>** let's get some fish and chips and wear bowler hats together
**\<sarang>** suraeNoether: do I have to start carrying my phone in my left pocket instead of my right?
**\<hyc>** rehrar absolutely, I will launch my own testnet. pre-ICO announcement right here right now.
**\<suraeNoether>** Okay, anyone have any other discussion points?
**\<jwinterm>** instead of directly storing the records m inside the blockchain, the records are put inside “fruits” denoted f
**\<suraeNoether>** sarang i recommend not bringing your phone to police states, but that's none of my business
**\<sarang>** jwinterm: yes
**\<sarang>** fruits and blocks are mined at the same time
**\<jwinterm>** I'm just going over the paper quickly now
**\<sarang>** but reference different things in the chain
**\<sarang>** and mining rewards are distributed over a segment
**\<rehrar>** please inform me hyc, I want to be among the first to hold these coins
**\<hyc>** lol okeydoke
**\<unknownids>** how many wowneros for a hycoin
**\<suraeNoether> \</meeting>**
**\<suraeNoether>** lol
**\<suraeNoether>** OH! No meeting next Monday
**\<suraeNoether>** Sarang and I will be bowler-hatting
**\<suraeNoether>** in old london-town
**\<hyc>** funfun
**\<sarang>** I assume it'll go much like The Prisoner
**\<sarang>** and we'll end up on some island
**\<sarang>** until we spill the beans on Monero

188
_posts/2018-04-30-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-04-30.md Normal file
View file

@ -0,0 +1,188 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-04-30
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<sarang>** dingdingding
**\<sarang>** it's time
**\<rehrar>** h'lo
**\<suraeNoether>** Hi everyone~
**\<suraeNoether>** Welcome to our research meeting
**\<UkoeHB>** g day
**\<suraeNoether>** One week ago today, Sarang and I were in London
**\<midipoet>** hello
**\<suraeNoether>** thanks to this generous community
**\<sarang>** It seems as if it were only a week ago
**\<suraeNoether>** heh
**\<sarang>** It was highly productive
**\<sgp\_[m]>** Hello
**\<sarang>** We got to meet some London meetup organizers before the event, which was great
**\<suraeNoether>** yes, this is where we spoke with Pedro Moren-Sanchez, who together with his student (who goes by donut in here) invented refund adresses for Monero
**\<sarang>** I'm analyzing some preliminary material from them
**\<sarang>** There's some question about the applicability of hiding block heights
**\<sarang>** and whether this provides sufficiently better information obscurity to make it worthwhile
**\<sgp\_[m]>** Great sarang! Glad you could make that work
**\<suraeNoether>** Since then, other than recovering from jetlag, I've been working non-stop on the multisig paper, which has come a long way... but I've run into a roadblock on the proof of unforgeability, involving the key image, the signing oracle, and access to a discrete logarithm oracle
**\<sarang>** it involves a change to the ring signatures and key images
**\<suraeNoether>** in addition to that, I brought rehrar, sgp\_[m], and sarang out to Denver to meet with me and my wife about MAGIC, Multidisciplinary Academic Grants in Cryptocurrencies
**\<midipoet>** whats MAGIC?
**\<midipoet>** or rather, can you elaborate..
**\<suraeNoether>** MAGIC is (or will be) a 501(c)3 non-profit based in Colorado, USA
**\<sarang>** a Colorado nonprofit organization dedicated to empowering the next generation of people in this space
**\<midipoet>** nice
**\<suraeNoether>** our goal is to promote education and scientific research, as well as community and educational outreach, in privacy infrastructure for the public good
**\<midipoet>** that is actually pretty awesome
**\<suraeNoether>** the basic idea will be to take some of the capital flowing into cryptocurrencies and close the loop back toward education. provide scholarships, provide research grants to researchers and infrastructure grants to schools, and to host conferences on privacy enhancing technologies
**\<sarang>** It will help boost education (which is great for many reasons) and also can help to promote privacy in the eyes of the public
**\<sarang>** I'm not one for focusing solely on PR, but it could help
**\<suraeNoether>** \*nod\*
**\<sarang>** Kudos to suraeNoether for all the planning on this
**\<sarang>** it's a ton of work
**\<suraeNoether>** well, so is math, and this is a way for me to procrastinate on one by being productive in another, and vice versa. :P
**\<midipoet>** i think if you can redirect some of the capital flows alone towards solid scientific research you are doing a great service already
**\<midipoet>** there is a lof of greed in crypto
**\<suraeNoether>** thanks midipoet
**\<sarang>** Our goal is focus first on education, and then on research
**\<sarang>** The research side overlaps a bit with some other groups (which is totally fine and beneficial)
**\<rehrar>** MAGIC focuses on ecological conservation and saving the whales
**\<midipoet>** lol
**\<sarang>** hehe
**\<rehrar>** oh wait, I think I dreamed that (no joke) after our meeting
**\<suraeNoether>** our first year we don't expect to get enough money to provide a substantial amount towards research, which is pretty expensive. the first year we are going to focus on scholarships, hosting a conference, and hopefully building a computer lab or a library for some impoverished primary schools
**\<sarang>** Hopefully the 501(c)(3) process goes smoothly. It's very... federal
**\<suraeNoether>** I'll have more info on that later this week
**\<suraeNoether>** tomorrow, it's lawyer meetin' time
**\<sarang>** excellent
**\<midipoet>** nice
**\<sarang>** It's worth noting that donors are free to remain anonymous, in the spirit of Monero
**\<sarang>** but the 501 status will allow donations to be tax-deductible in the U.S. if donors reveal themselves
**\<midipoet>** creating goodwill around crypto is needed. a lot of people have a very strange view of it, especially since the whole ICO thing
**\<sarang>** midipoet: definitely
**\<sarang>** The only other group I know of trying a similar-ish thing is the Zcash Foundation
**\<sarang>** We'll certainly apply for one of their grants if possible
**\<sarang>** This work transcends silly interproject politics
**\<midipoet>** i could tell you a sad story about what computer science kids thought crypto is about in nigeria
**\<madLyfe>** yay!
**\<sarang>** crypto = ca$hmoney
**\<madLyfe>** https://i.imgur.com/J2Vyl27.png
**\<midipoet>** pretty much sarang
**\<suraeNoether>** So, from sarang's research we've been looking at refund addresses. from mine, I'm struggling with signing oracles, key images, and discrete logarithms in our unforgeability proofs of multisig (ahem). from educational outreach, we have several folks from the monero research lab and the monero community participating. We even got dinner with Zooko to get ideas on including more independent folks, and I'm
**\<suraeNoether>** reaching out to two possible additional board members later today
**\<hyc>** ... silly politics is based on technological assessment tho
**\<madLyfe>** wrong channel. sorry.
**\<sarang>** hyc: I totally see that side of it
**\<sarang>** But for the purposes of this organization it's all silly
**\<sarang>** I should have clarified
**\<sarang>** We'll take donations where we can find them if it means helping more students and communities
**\<suraeNoether>** on another note, a representative from the ZCash foundation asked if we know of anyone in the Monero community who would be willing to serve on the ZCash Foundation board of directors. Because ZCash Foundation, despite the name, is independent of ZCashCo, is a non-profit focused on internet payment and privacy infrastructure also, even if one disagrees with the zcash design philosophy (which is totally fair)
**\<suraeNoether>** you could still contribute to the privacy community as a whole
**\<suraeNoether>** hyc maybe you should do it :D
**\<suraeNoether>** of course, no one from Monero \*needs\* to go and attempt that, but I think it's nice that they reached out
**\<midipoet>** would you not lose some street cred sitting on that board?
**\<rehrar>** I second hyc
**\<rehrar>** he has the good looks and charisma necessary
**\<suraeNoether>** midipoet: almost certainly.
**\<suraeNoether>** rehrar: and the fiddlin' talent
**\<sarang>** midipoet: maybe, but that's up to the individual
**\<rehrar>** midipoet: street cred is for shmuks
**\<suraeNoether>** rehrar: ^ +1
**\<midipoet>** schmuks in Zcash suits
**\<sarang>** It's worth noting their organization documents include language specifically mentioning supporting the Zcash network
**\<sarang>** FWIW
**\<rehrar>** I don't agree with many things of the Zcash implementation, but they're pushing the privacy scene forward
**\<rehrar>** in a similar way that we are as well with our work
**\<sarang>** I choose to believe that better research and public perception of privacy will help us all
**\<rehrar>** right, even if this whole cryptocurrency experiment fails, the world can learn
**\<midipoet>** yeah, i agree as well. just sceptical
**\<sarang>** and they're literally making free money available for research and other helpful projects
**\<suraeNoether>** personally, i think that in 20 years or so, we'll look at the different currency teams in the same way we look at IBM vs. microsoft. it's not weird for IBM guys to get lunch with microsoft guys, or for them to do business together, and probably any market forces that improve one will lead to improving the other.
**\<suraeNoether>** i mean
**\<suraeNoether>** there's a positive covariance in market performance across most of the big cryptocurrencies, so high tides lift all the boats, so to speak
**\<sarang>** It's like commercial airlines... the management types see each other as the devil, but the pilots all help each other out since they're out to get people there safely
**\<sarang>** maybe
**\<suraeNoether>** lol maybe
**\<rehrar>** that said: https://www.youtube.com/watch?v=A51Bl3jkF0c
**\<sneurlax>** to continue that analogy, it's like Google using Java for Android, which was made (or maybe its IP is just now owned) by Oracle
**\<rehrar>** ^ continues to be one of my favorite videos (10 seconds long)
**\<suraeNoether>** sneurlax: sure lol
**\<sarang>** anyway
**\<midipoet>** aha
**\<suraeNoether>** ok, so that covers the basic research from the last week, and our educational outreach, and the various political-ish connections MRL has made with other projects
**\<sarang>** My monthly report details a few other things we've been doing: https://www.reddit.com/r/Monero/comments/8fzfzx/april\_monthly\_report\_from\_sarang\_noether/
**\<suraeNoether>** has anyone done anything else they want to chat about? interesting simulations? I know silur has expressed some interest in getting more involved at MRL, but he is suffering under the delusion that one of us is in charge
**\<sarang>** The audit has begun for the two larger groups
**\<suraeNoether>** oh! audit! yeah!
**\<sarang>** Nothing to report there, just reviewers getting their hands dirty
**\<sarang>** but it's good news
**\<suraeNoether>** good, good, it's before May so that's pretty good
**\<sneurlax>** uh, yeah, what's your favorite programming language with which to verify claims/reports? Python?
**\<midipoet>** i want to signpost the research i am doing. some of you will have heard it a million times, but formal requests for interviews with devs/cryptographers will be coming very soon. so warning!
**\<sarang>** sneurlax: I dig Python for tools
**\<sarang>** We also need to have fee structure discussions sooner rather than later
**\<sarang>** and decide precisely how that will change with the BP deployment
**\<rehrar>** oh shoot, that's a big conversation that we don't want to leave for the last minute
**\<sarang>** yes
**\<sarang>** We keep almost having the conversation
**\<sarang>** Fees are probably the most publicly-visible part of the BP thing
**\<rehrar>** as well, would there be work for an undergrad mathematician (well versed in statistics)? I know of one that would probably want to get involved over the summer. Would be at the disposal of our MRL PhDs
**\<sarang>** One thing I would like is a clean Python library giving data structure access to transaction trees
**\<suraeNoether>** sarang let's talk about fees later today or tomorrow?
**\<suraeNoether>** rehrar: what sarang said: visualization of transaction histories
**\<sarang>** i.e. this transaction has these inputs in its ring, and those trace back to other rings, etc.
**\<sarang>** not even visualizations
**\<sarang>** just a library giving clean data structures
**\<sarang>** we can do all sorts of things with that
**\<sneurlax>** sarang: suraeNoether: that is the basis of my tool
**\<suraeNoether>** yeah, fair enough, i'm more interested in various statistical properties of those things
**\<sarang>** Yeah I wanted to ask about details with that
**\<suraeNoether>** sneurlax: want to talk about it, since it came up?
**\<sneurlax>** I can port that to Python. the more information/specs you can proivide, the less questions I'll have later
**\<sarang>** Sure, let's chat after the meeting sneurlax
**\<sneurlax>** perfect
**\<sarang>** Even if it's not Python, having something easy to implement will be great
**\<suraeNoether>** yeah, i mean from my point of view
**\<nioc>** always check with ArticMine when it comes to fees
**\<suraeNoether>** i'm interested in things like the distribution of sizes of transaction trees, how often outputs are re-used within the same, tree, stuff like that
**\<sarang>** Yes, it's a discussion for many people
**\<suraeNoether>** nioc: yeah, he has something written up already
**\<sarang>** but one that needs to be had
**\<suraeNoether>** iirc
**\<sarang>** Any other interesting work lately?
**\<sarang>** (BTW we should arrange some time in -dev meeting for fee talks)
**\<nioc>** should be a dev meeting this coming Sun
**\<nioc>** rehrar: ^^^ ??
**\<rehrar>** yes nioc
**\<sgp\_[m]>** Was this discussed? https://github.com/moneroexamples/key\_images\_comparison
**\<suraeNoether>** it has not been
**\<suraeNoether>** wow!
**\<suraeNoether>** much smaller numbers than I was expecting
**\<suraeNoether>** you know, endogenic earlier asked about the plausibility of long-term blackballing
**\<suraeNoether>** and I responded with a silly analogy, comparing the monero blockchain to a pile of radioactive material: outputs have half-lives of their anonymity as bad actors perform more and more blockchain forensics, they expose more and more old outputs...
**\<sgp\_[m]>** Thoughts on the proportion used, and the proportion that used the tool? I actually felt that 10% of reused key images using a special tool to pair outputs was unusually high
**\<hyc>** lol pretty sure Zcash team has me blacklisted
**\<suraeNoether>** i meant the % that have at least one re-used key
**\<suraeNoether>** hyc it's what you get for being such a lovely violinist
**\<hyc>** harhar
**\<sneurlax>** @sgp\_:matrix.org would you mind linking your previous work on key image reuse impacts at ... what was it, % reuse?
**\<suraeNoether>** if we make it clear which outputs are provably spent, then what we are doing is relying on economic activity frontloading this radioactive decay process, hoping that a big mass of anonymous outputs stand between us and the back end, as blockchain forensics unravel the blockchain from the genesis block moving forward. so the only way this sort of thing is sustainable is if we have economic activity outpacing
**\<suraeNoether>** forensics efforts
**\<midipoet>** thats quite interesting
**\<sneurlax>** I just ask because I liked the work, sqp
**\<suraeNoether>** it highlights that ring sigs, or at least "small anon set" methods, need to be replaced
**\<sneurlax>** that big mass probably has a lot of dead ends that'll confound that unravelling. who knows how many keys have been lost.
**\<sgp\_[m]>** sneurlax here's the Google Sheet (logout of Google): https://docs.google.com/spreadsheets/d/1iLa\_yklutjHqn\_DrOlO\_eTb00l4YDAezijX2J5r6P14/edit?usp=sharing
**\<midipoet>** or there is some critical mass of privacy enaction that provides protection...
**\<sneurlax>** there are definitely outputs which will never be reused because their owners forgot about them, lost their keys, etc.
**\<sneurlax>** thank you!
**\<suraeNoether>** okay, does anyone else have any questions, concerns? i need to bother andytoshi about key images and this discrete log problem I'm having before I'm more comfortable with where our multisig scheme is at
**\<hyc>** so those outputs will always be ambiguous, never proven spent
**\<UkoeHB>** they could be proven unspent
**\<suraeNoether>** hyc unless all outputs that refer to it can be proven to be linked to another output
**\<suraeNoether>** right
**\<hyc>** ok
**\<sarang>** OK, meeting is officially adjourned, but feel free to stick around for further discussion

236
_posts/2018-05-07-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-05-07.md Normal file
View file

@ -0,0 +1,236 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-05-07
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<sarang>** OK, it's time to begin
**\<sarang>** Welcome to everyone; hello
**\<sgp\_[m]>** Hi!
**\<sarang>** Calling others: hyc suraeNoether anonimal endogenic binaryFate fluffypony luigi1111 luigi1113 rehrar[m] monerigo[m] gingeropolous dEBRUYNE
**\<sarang>** and many others no doubt
**\<sarang>** s/monerigo[m]/moneromooo
**\<binaryFate>** présent
**\<sarang>** I suppose we can discuss recent updates and such
**\<sarang>** I have been focusing on noninteractive refund transactions
**\<sarang>** it's surprisingly tricky to get right
**\<sarang>** The idea of whether or not to hide block heights has big implications on size and complexity
**\<sarang>** and also will affect the use of old outputs
**\<theRealSurae>** Hey everyone, sorry I'm late (and not using my registered nick)
**\<sarang>** A good higher-level question is whether we insist that having refund transactions is enough of a priority
**\<sarang>** Hello fake suraeNoether
**\<theRealSurae>** heh
**\<sarang>** \*enough of a priority to devote big plumbing-level changes
**\<sarang>** these questions have consumed me as the Whale consumed Ahab
**\<sarang>** and, like Ahab, I spend much time in the company of Starbuck(s)
**\<theRealSurae>** gross
**\<sarang>** theRealSurae: what has consumed you lately?
**\<UkoeHB>** it feels like there should be an easier way to hide amounts. Maybe worth mulling for some time
**\<sarang>** UkoeHB: other than commitments?
**\<rehrar[m]>** Hi
**\<UkoeHB>** Yeah. Maybe a shift in perspective. Baseless intuition
**\<silur>** what
**\<sarang>** Well, the current Best Way is homomorphic commitments + range proofs to ensure balance
**\<theRealSurae>** I've been thinking about koe's reduced mlsag and how we might be able to batch-verify ring signatures with bulletproofs. and i've been speaking with a professor at clemson university about the possibility of starting a paid project for a grad student to invent a new elliptic curve with 2^255-19 points on it, or to come up with a similar sort of variant to secp256k1
**\<theRealSurae>** yeah, I think we are going to experience reduced returns in terms of hammering bulletproofs for improving our amount strucutres
**\<sarang>** theRealSurae: BPs to batch verify our current MLSAG scheme?
**\<silur>** oh yea the curve order question you asked
**\<theRealSurae>** so, i think it'd be really really helpful for both bitcoin and monero to have alternate curves
**\<theRealSurae>** ohgod
**\<theRealSurae>** other than that and the multisig dump I made the night before yesterday, this week has been consumed by editing papers for other folks. Koe and my old advisor and another document. lots of reading this week
**\<sarang>** What are your thoughts on refunds?
**\<UkoeHB>** and thank you for that :) incredibly helpful
**\<sarang>** UkoeHB: any big changes to your excellent paper?
**\<UkoeHB>** Well we found out monero doesn't even use borromean sigs
**\<UkoeHB>** genBorromean should be genSAGs
**\<UkoeHB>** Or something
**\<sarang>** SAG?
**\<theRealSurae>** I've been thinking a lot about the refund structure with timelocks, and I'm trying to figure out exactly whether we have a novel "invention" in these refund transactions or whether tit is equivalent to a timelock+multisig situation
**\<UkoeHB>** spontaneous anonymous group sig. Like LSAG but no key images
**\<sarang>** for range?
**\<UkoeHB>** Yeah
**\<UkoeHB>** Check ringCT.cpp genBorromean
**\<sarang>** Yeah I'm familiar with that code
**\<UkoeHB>** It's 33% larger range proofs than a real borromean setup
**\<theRealSurae>** ... i need more details about that, koe, if you don't mind...
**\<sarang>** heh
**\<sarang>** theRealSurae: big thing is non-interactivity
**\<sarang>** I don't need the recipient's cooperation
**\<UkoeHB>** I'll see what I can do
**\<theRealSurae>** thanks koe, i'm not in a rush on that though...
**\<theRealSurae>** I want to remind everyone that I'll be mostly away from the internet from tomorrow until the 19th, with some intermittent access.
**\<moneromooo>** luigi1111: is this (genBorromean doesn't actually generate Borromean sigs) correct ?
**\<UkoeHB>** yup have fun :). Vacation right?
**\<theRealSurae>** i'm not the sort who can really put work down, but i'm trying, briefly. i managed to write up a skeleton of the unforgeability proof for multisig and hand it off to sarang to familiarize himself with the musig approach
**\<binaryFate>** Zcash is also coming up with their own curve so as to speed up the particular things they need to. I find it worrying if the trend is that every project cooks up their curve to suit their particular needs.
**\<theRealSurae>** and, like I said, I'm communicating with some folks at Clemson
**\<sarang>** Yeah I've been revisiting the original musig paper
**\<luigi1111>** Not that I know of
**\<theRealSurae>** binaryFate: why would this be worrying?
**\<luigi1111>** theRealSurae: 2^255-19 isn't the number of points
**\<theRealSurae>** you are right, it's the group order
**\<binaryFate>** against the "don't invent your own crypto", and light years away from typical review process for curves
**\<theRealSurae>** right? i misspoke
**\<vtnerd>** no, 2^255-19 is the prime field
**\<sarang>** I hear it's a kind of cake
**\<sarang>** Or that feeling when your leg falls asleep and you stand up
**\<luigi1111>** Group order is l
**\<luigi1111>** 2^252+blah
**\<sarang>** aaaanyway
**\<theRealSurae>** i confess I tend to think of our group as a scrambled mirror image of Z\_q, despite addition of points not even landing on the subgroup.
**\<sarang>** So theRealSurae is working on unforgeability
**\<sarang>** I am figuring out if noninteractive new-output-style refunds are worth it
**\<sarang>** Other fun times?
**\<theRealSurae>** binaryFate: yeah, I see that
**\<sarang>** binaryFate: do you have any information on the Zcash efforts? I wasn't aware of their work
**\<theRealSurae>** binaryFate: eventually that curve, even if proven to satisfy our desired properties, will have to be implemented, and the dangers or crappy implementation are huge... but I don't think that should discourage research into new curves and new proof methods using isomorphic curves
**\<theRealSurae>** yeah, I wasn't either. I thought it was just Blockstream looking for a variant of secp256k1 so far
**\<UkoeHB>** oh i messed up - they are borromean ugh
**\<theRealSurae>** that's a relief koe!
**\<sarang>** UkoeHB: what led to believe otherwise?
**\<luigi1111>** ^
**\<UkoeHB>** misreading code like a fool
**\<UkoeHB>** thought this hash\_to\_scalar(L[1]) meant an array of hashes for each L[1], instead of a hash of the entire array
**\<sarang>** Good thing hashes aren't important to borromean sigs /s
**\<sarang>** If there aren't any other big topics to discuss, we could certainly return to refunds or previous topics
**\<sarang>** There were suggestions from luigi1111 that the refunds needed for payment channels would be possible purely w/ timelocks + multisig
**\<binaryFate>** will look for some link on the zcash curve thing. It's part of their roadmap to reduce overhead to generate z-transactions iirc
**\<sarang>** I do not see how that would be possible without interaction from both parties, or a third-party arbiter
**\<sgp\_[m]>** I just want to mention that I'm working on preserving the integrity of outputs held by mining pools
**\<sarang>** But I'd love to be convinced otherwise
**\<rehrar[m]>** MRL corporate cheer!
**\<sarang>** sgp\_[m]: in response to the linking work?
**\<luigi1111>** It does require interaction at the start
**\<sarang>** right
**\<sarang>** it'd have to
**\<sarang>** So the recipient pre-signs for the refund?
**\<rehrar[m]>** I have a bit of other ZCash news.
**\<sgp\_[m]>** sarang kinda, yeah. I don't have too much to mention now though
**\<sarang>** How does the network verify the spend of the originally-intended output?
**\<sarang>** sgp\_[m]: ok, keep us updated
**\<sneurlax>** I've contacted ehanoc re: the "transaction tree" python toolkit and we will collaborate to deliver that after I finish the scraping tool which moneromooo asked for. mooo, I'll be sending you results this week
**\<sneurlax>** sorry to interject
**\<sarang>** sneurlax: excellent! That'll provide good data
**\<theRealSurae>** rehrar[m]: tell us?
**\<theRealSurae>** sneurlax: that's fantastic news
**\<rehrar[m]>** ZCash wants to open a grant proposal jointly with a Monero community member (that'd be me atm) to donate a considerable sum of money to some FFS proposals.
**\<sarang>** What types of FFS do they want to fund?
**\<theRealSurae>** how would that work? would you have discretion over donating the funds?
**\<rehrar[m]>** https://twitter.com/socrates1024/status/993252058923925506?s=19
**\<theRealSurae>** i'll almost always take free money if it's no-strings
**\<sarang>** Aw shucks, they like us!
**\<theRealSurae>** that's... fantastic
**\<rehrar[m]>** Dunno. When next round of bp auditing funds?
**\<rehrar[m]>** We can out it up, raise the amount, and take out right away. Superior Coin also wants to help if you recall.
**\<rehrar[m]>** Perhaps we can also get subaddresses audited?
**\<theRealSurae>** hmm
**\<sarang>** Yeah, was thinking of waiting until closer to the finalization, but I suppose there's little advantage if we can coordinate w/ OSTIF quickly
**\<theRealSurae>** it seems like a lot of projects want to funnel their research funding through the Monero FFS
**\<binaryFate>** the harder we criticize them the more they like us... 10k$ is not that much compared to amounts raised typically anyway
**\<sarang>** It's a nice gesture of community spirit though
**\<sgp\_[m]>** I think the best ones are the hardware wallet (which should work with Zcash iirc) and code audits
**\<rehrar[m]>** They're masochists binaryfate. If we criticize harder they'll give more.
**\<sarang>** A subaddress audit depends highly on the scope
**\<sarang>** The BP scope was narrow-ish
**\<theRealSurae>** binaryFate: yeah, it seems like a largely symbolic thing, but also: they've been really encouraging me and sarang to encourage you guys to ask for grant money.
**\<theRealSurae>** rehrar[m]: i should just take zooko out to a bdsm club in denver, see if they offer us six or seven figures. :P
**\<rehrar[m]>** In return , we can send them Monero stickers to put on their laptops.
**\<sarang>** something something meat market
**\<theRealSurae>** meat meat something market
**\<binaryFate> \<rehrar[m]>** In return , we can send them Monero stickers to put on their laptops. <-- they have one at least, we've put one on zooko's back at CCC without him noticing
**\<sarang>** I'll be interested to see how the 10K is disbursed
**\<theRealSurae>** sarang: Is the implication that it would totally be up to our discretion? that's sort of what i'm getting...
**\<rehrar[m]>** Zooko is a dude.
**\<rehrar[m]>** I chilled with him in Colorado.
**\<rehrar[m]>** Can neither confirm nor deny Verge dev there too.
**\<theRealSurae>** What if we take the 10k, pay for a semester of a grad student working with some cryptographers to invent three new curves, a variant for secp256k1, a variant for x25519, and a variant for zcash's thing
**\<sarang>** tall order
**\<theRealSurae>** maybe
**\<endogenic>** sorry rehar
**\<theRealSurae>** it'd guarantee that student would spend the rest of his time in grad school working on that sort of thing
**\<theRealSurae>** which I think would be a valuable thing: seed the mind-virus among as many researchers as possible
**\<binaryFate>** They're not even asking for doing joint work with zcash stuff at this stage apparently. Would just channel to Monero topics entirely if possible.
**\<pwrcycle>** Hi all.
**\<binaryFate>** Anyway grad student is a great idea
**\<theRealSurae>** binaryFate: yeah, that's the inference I made
**\<rehrar[m]>** I'll talk with Miller.
**\<rehrar[m]>** See how he wants to do the grant proposal.
**\<theRealSurae>** binaryFate: the problem then is picking the student/school
**\<pwrcycle>** Funding grant money for school research seems cool. Pinning all the hopes on one grad student seems like a bad idea.
**\<theRealSurae>** rehrar[m]: please do, maybe CC me... I can hook him up with at least two cryptographers at Clemson who may be interested
**\<theRealSurae>** pwrcycle: yeah, you'd pick by advisor more than student
**\<rehrar[m]>** Maybe we can get some people to make a FFS that should have made one a while back in exchange for ZCash paper
**\<rehrar[m]>** Like dEBRYUNE
**\<rehrar[m]>** Then again, what use have gods for our petty currencies.
**\<binaryFate>** Btw having some sort of pulic call for the paid internship circulating in academic circles is as important as the thing actually happening, in terms of mind-virus spreading
**\<rehrar[m]>** Nothing more from me.
**\<theRealSurae>** rehrar[m]: you are the greatest orator of our time
**\<theRealSurae>** binaryFate: TRUE point
**\<theRealSurae>** very true
**\<theRealSurae>** sarang
**\<sarang>** yo
**\<theRealSurae>** when I get back I'm going to look into putting job postings on mathjobs.org
**\<theRealSurae>** i was about to ask you to do it while i'm gone, but it's not urgent and there's no need to delegate. :P if you're curious, though :D
**\<sarang>** I think using mathjobs is a really good idea for pure math applicants
**\<theRealSurae>** there are lots and lots of applied jobs on there too
**\<theRealSurae>** you should check it some time, but
**\<theRealSurae>** creation of a curve is at the intersection of applied algebraic geometry and pure cryptography
**\<sarang>** right, that wasn't what I meant
**\<theRealSurae>** so it's sort of both pure and applied
**\<theRealSurae>** oh ok
**\<sarang>** I mean to get solid reach to academics
**\<sarang>** that's the obvious choice
**\<theRealSurae>** yep
**\<sarang>** They can send us a list of all the points on their new curve, for us to check
**\<binaryFate>** good old emails circulating between labs and advisors ("if you have a really good students, consider asking them to apply. And please forward blabla") is also worth it. Reaches more senior people than a job posting probably read primarily by students directly.
**\<sarang>** Oh, so I've been seeing random reddit postings about deep reorgs
**\<sarang>** But I haven't looked into it at all
**\<sarang>** Anyone know anything?
**\<selsta>** also articles are starting to come out https://www.trustnodes.com/2018/05/07/monero-allegedly-attack-claims-double-spends-orphaned-chains-21-block-deep
**\<moneromooo>** I think it's fixed now (no PR yet).
**\<sarang>** Do you know the cause?
**\<theRealSurae>** is it known what the issue was?
**\<sarang>** jinx
**\<binaryFate>** The +20-blocks fork mentioned in the post is not an actual fork, you only see that when syncing. But somebody is fiddling with decent HR
**\<sarang>** buy me a DietMonero
**\<theRealSurae>** i thought the first few reports were possibly the OP for some reason
**\<binaryFate>** moneromooo link or summary?
**\<moneromooo>** Some init wasn't done in some cases when adding a tx.
**\<sarang>** Yeah, I want to be able to give correct information
**\<moneromooo>** So that was causing the tx to be rejected though it is valid.
**\<theRealSurae>** hrmm
**\<sarang>** OK, so that explains the "double spend" FUD
**\<sarang>** The long-chain reorgs are just related to initial sync?
**\<sarang>** It was noted that there wasn't any big spike in hashrate
**\<sarang>** so it's not outsiders coming online and futzing
**\<moneromooo>** If a pool doesn't accept a valid tx, it will continue mining on its own chain till it stops doing so.
**\<sarang>** OK, so it's a single cause with these two effects?
**\<moneromooo>** What two effects ?
**\<sarang>** Well the reports I've seen have complained about apparent double spends (rejected tx) and long-chain reorgs
**\<theRealSurae>** i feel like if a selfish miner was going to release a chain in an attack, the hashrate wouldn't necessarily look different to an observer, especially if the attacker had 33%+ attack power and was clever with their timestamp choice...
**\<moneromooo>** I don't know anything about double spends.
**\<moneromooo>** Though if a merchant is only connected to that pool, you could swindle it.
**\<moneromooo>** The merchant would have to be only connected to that pool though, but that's not a new attack.
**\<sarang>** Yeah that's just being cavalier
**\<theRealSurae>** https://www.trustnodes.com/2018/05/07/monero-allegedly-attack-claims-double-spends-orphaned-chains-21-block-deep
**\<theRealSurae>** i don't like that article for a variety of reasons, but
**\<sarang>** Yeah that's the article I keep getting linked to
**\<sarang>** it's based on some r/monero complaint posts
**\<sarang>** so naturally it will be accepted as gospel and spread widely
**\<theRealSurae>** it would be helpful to get more information from the specific users making this complaint
**\<sarang>** A random user says one thing and the devs who know things say another thing! So there's no way to know!
**\<binaryFate> \<sarang>** It was noted that there wasn't any big spike in hashrate <-- if someone is purposefully mining on alternative blocks rather than winning chain, we would not "see" the HR spike as it does not make blocks coming faster
**\<moneromooo>** You'd see a hashrate spike downwards.
**\<binaryFate>** only if that miner was mining before no?
**\<moneromooo>** Yes.
**\<theRealSurae>** not necessarily; an attacker with exactly 50% hash rate and honest timestamps will appear to be invisible. an attacker with lower hash rate could mess with timestamps slightly and appear invisible. an attacker with too low of a hash rate couldn't manipulate his timestamps enough to hide his activity
**\<theRealSurae>** (not necessarily re: downward spike)
**\<binaryFate>** Can we check how long it took them to mine a particular altchain of N blocks by checking logs on other nodes on when the last block in their chain got known to peers?
**\<theRealSurae>** we can put a bound on it, for sure, and we can use that to estimate the hash rate power they have
**\<theRealSurae>** ok y'all I gotta go
**\<theRealSurae>** have a good week and a half!
**\<binaryFate>** same!

162
_posts/2018-05-14-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-05-14.md Normal file
View file

@ -0,0 +1,162 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-05-14
summary: MRL work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / sarang
---
# Logs
**\<sarang>** andytoshi anonimal binaryFate ArticMine dEBRUYNE endogenic gingeropolous moneromooo sgp\_[m] smooth stoffu UkoeHB etc
**\<ArticMine>** Hi
**\<dEBRUYNE>** Kind of present :P
**\<sarang>** close enough!
**\<sarang>** an informal meeting today, probably fairly short
**\<endogenic>** not present
**\<sarang>** 1. Greetings
**\<sarang>** yo
**\<sarang>** 2. Updates all around
**\<sarang>** Our pal suraeNoether is on holiday
**\<sarang>** that lucky bastard
**\<sarang>** I've been continuing to work with the Purdue researchers on noninteractive refunds
**\<sarang>** which would be much more of a hassle than an interactive refund
**\<sarang>** But it brings up some really interesting new ideas that we're formalizing to publish
**\<sarang>** Aside from that, there was some good Zcash anonymity research in the spirit of the monerolink stuff
**\<sarang>** It has good lessons about the importance of mandatory privacy
**\<sarang>** Another paper pointed out some flaws in the MuSig paper that suraeNoether had been working with
**\<sarang>** not in terms of attacks, but in terms of security proofs unfortunately
**\<sarang>** The second BP round went through, and we'll be getting that funding to OSTIF as soon as I can talk with a Core Team member about funding release (send them my way if you find them today!)
**\<sarang>** Anything else from the peanut gallery?
**\<binaryFate>** will get in touch with OSTIF again tomorrow
**\<sarang>** binaryFate! Perfect, thanks
**\<sarang>** Please release it all to lock in the exchange rate; your help is appreciated as always
**\<sarang>** Any unused amount will be return to us by OSTIF
**\<binaryFate>** Yes I understand there is some freaking out about exchange rate around :) Will do
**\<sarang>** It seems to be a quiet day today, not sure if anyone else has anything to share
**\<sarang>** Or something they've run across lately
**\<dEBRUYNE> \<sarang>** not in terms of attacks, but in terms of security proofs unfortunately <= What does this entail?
**\<sarang>** They had done away with a precommitment phase of their key preparation
**\<sarang>** and this led to a flaw in the proof that would be fixed by adding this step (more communication)
**\<sarang>** it would also make it secure up to discrete log, as opposed to one-more discrete log as it is now
**\<sarang>** I had a brief chat w/ andytoshi about it earlier
**\<dEBRUYNE>** So it's not a showstopper, but would preferably be implemented right?
**\<sarang>** Right. I don't know of any big projects that were immediately applying MuSig directly, but suraeNoether was curious about using some of the ideas to reduce communication
**\<dEBRUYNE>** All right
**\<sarang>** The "upgrade" to DL security is good too IMHO
**\<sarang>** Consensus is live streaming, as mentioned earlier... so that's a source of infotainment for anyone interested
**\<sarang>** They're having Zooko interview Whit Diffie about privacy
**\<sarang>** that'll be a good watch
**\<sarang>** For this week, I plan to incorporate some suggestions from the Purdue folks into the writeup of noninteractive refunds and get that out
**\<sarang>** and look more precisely at interactive refunds and what's needed
**\<sarang>** Whelp, it looks like slim pickings today for updates, so
**\<sarang>** 3. Tearful goodbyes
**\<sarang>** Keep up the good work, and be well
**\<sarang>** We'll never forget the good times and memories
**\<sgp\_[m]>** Did anyone have a chance to look at my research on mining pool outputs?
**\<sarang>** Yes! Can we talk about that openly in here?
**\<sarang>** I don't recall if you had publicly released it
**\<sgp\_[m]>** Just the mitigation strategies
**\<sgp\_[m]>** This is what I worked on: https://1drv.ms/b/s!AjOt8D-0YjBHgco6O7TRnzm91YACUw
**\<sarang>** My only lingering question was regarding the suggestions for churn
**\<sarang>** since that work is still ongoing to determine the optimal behavior
**\<sgp\_[m]>** I think we should discourage churning as much as possible since it harms the network, but it can be used effectively to preserve the integrity of outputs. Even if it only adds plausible deniability
**\<sarang>** What's your view on it harming the network specifically?
**\<ArticMine>** Yes there is also the issue of pool transparency
**\<sgp\_[m]>** Just blockchain bloat. Imagine if we recommended every mining pool churn after each payout lol
**\<ArticMine>** Any proprietary in mining is a potential danger
**\<sgp\_[m]>** Note that I've only looked at publicly-available information. Many mining pools also publish the transaction amount, which could allow a recipient to remove certain decoys that are known to be under the sent value. I haven't thoroughly looked into this yet
**\<ArticMine>** Maybe we need to find a way to blackball these outputs for future rings and leave the churning to the recipient
**\<sarang>** The recipient is also likely the one with greater incentive to do so, no?
**\<sgp\_[m]>** ArticMine one option is for mining pools to be extremely transparent about all outputs they have controlled, and clients blackball these. I think there's a high risk of clients not doing this though
**\<ArticMine>** but can the blackballing not be done by the pool
**\<sarang>** We also have a broader issue of the blacklist being slow to implement
**\<sgp\_[m]>** I recommend my "third best" solution for pools that still want to make everything transparent, which involves a different selection algorithm
**\<sgp\_[m]>** It doesn't really matter that pools would use a different algorithm, since they publish a list of transactions anyway
**\<sgp\_[m]>** And they could adapt their algorithm to include payout outputs in a single ring signature
**\<sarang>** That relies entirely on pools voluntarily complying, right?
**\<sgp\_[m]>** I have diagrams in slides 11-15 of the deck I shared
**\<ArticMine>** My take is that we should be actively discouraging pools from being anything but totally transparent
**\<sgp\_[m]>** sarang yes, it relies on pools complying. Pools have the potential to cause a lot of harm to outputs in the status quo
**\<ArticMine>** It is a related but different issue that is impacted here. Namely overall transparency in mining.
**\<sarang>** yeah
**\<sarang>** One of the reasons I was intrigued by the FruitChains paper was the idea of reducing the incentives to pool at all
**\<ArticMine>** A voluntary way for pools to flag these outputs as to not be used in mixins may be the best way
**\<sgp\_[m]>** If a user thinks pools are malicious, they should absolutely churn individually to the extent research shows. However, I'm talking more about the pools removing the entropy of these outptus in this transparency. We can have transparent pools while still preserving the integrity of these outputs
**\<sgp\_[m]>** If people feel comfortable mining to a pool that doesn't even publish coinbase history, that would be the best for the network. However, that is unrealistic
**\<ArticMine>** It is best for the network from the point of view of privacy but no from the point of view of mining integrity
**\<sarang>** ArticMine: in what way
**\<ArticMine>** For starters how does one determine the size of the pool?
**\<ArticMine>** Independently?
**\<ArticMine>** Or how much of a take the pool is getting
**\<ArticMine>** It is a special situation one step above coinbase outputs
**\<ArticMine>** Pools are in a unique position of power which is why transparency must at least be encourages and ideally enforced
**\<sarang>** But my understanding is that pools can simply not give all this information
**\<sarang>** so it'll all still based on voluntary goodwill
**\<sarang>** as in, information from self-selecting entities
**\<ArticMine>** This is true but there is a market pressure to give out this information
**\<ArticMine>** and this is very healthy
**\<sgp\_[m]>** Well, even if they don't povide an easy blackball list, someone can realtively trivially put one tegether from the complete transaction history
**\<moneromooo>** sneurlax made one such tool (or may still be making one).
**\<ArticMine>** That is actually a backup answer
**\<ArticMine>** But ideally we should encourage the pools to give a blackball list
**\<sarang>** What do you think the general thoughts are about the blackball list being checkpointed and supplied non-locally?
**\<sgp\_[m]>** I recommend we instead encourage them to use a different selection process so a blackball list is unnecessary
**\<sarang>** Because the local generation seems pretty intense
**\<ArticMine>** sgp\_[m] So if I understand correctly these pool outputs could then be easily identified and not included in mixins
**\<ArticMine>** That of course would work very well
**\<sgp\_[m]>** I believe you are explaining the blackball process ArticMine
**\<ArticMine>** Yes
**\<ArticMine>** So I am not clear how a different selction process would work
**\<rehrar>** oy, missed the meeting?
**\<sarang>** Most folks were away, but we're still chatting
**\<sarang>** whats the good word
**\<sgp\_[m]>** I recommend that pools instead take the outputs in a published transaction and use all these outputs in a single ring signature. Then, outsiders don't know which outputs are paid to miners and which are change returned to the pool
**\<sarang>** Yeah I liked this approach
**\<sarang>** I didn't see any immediate downsides
**\<sarang>** It makes sense since the pools are known entities
**\<ArticMine>** but normally almost all of these outputs are paid to miners
**\<moneromooo>** It still needs someone to volunteer to maintain a blackball list, and so far nobody has so this code is left unused :)
**\<sgp\_[m]>** The goal is to make the outputs returned to the pool look the same in a random transaction decoy as how they look when miners make transactions with their payouts
**\<rehrar>** can we replace ring sigs already? that is all
**\<sarang>** That'll be our big MoneroCon unveil
**\<sgp\_[m]>** This is difficult to explain, so I'm sorry I'm not doing it very well
**\<rehrar>** oh, also that article on PoW (which I'm sure had to have been discussed at this meeting). Something else.
**\<sarang>** "MoneroCon: Monero is a con!"
**\<ArticMine>** So one is obfuscating the change output among the payouts
**\<sarang>** sgp\_[m]: I think I get the point you're making
**\<ArticMine>** That I understand
**\<sgp\_[m]>** ArticMine yes that's the goal, so that the outputs controlled by the pools (these change outputs) no longer need to be blacklisted
**\<sgp\_[m]>** \*blackballed
**\<sgp\_[m]>** even if the transaction history is published
**\<ArticMine>** Yes that would work.
**\<sgp\_[m]>** hmm actually on second thought, pools should need to still churn the coinbase outputs (not just the very first one), or they need to be blackballed. My slide 14 is incorrect
**\<sarang>** sgp\_[m]: Suppose you get some fraction of pools to comply, but some don't... you'd still need to monitor for the blacklist, no?
**\<serhack>** hi :)
**\<sarang>** hullo
**\<sgp\_[m]>** Yes, an end user should still blacklist as much as possible
**\<sgp\_[m]>** I want to limit this as much as possible though, in case users don't go through this process
**\<sarang>** Unless we more broadly support a non-local blacklist integration
**\<sarang>** but that has its own issues
**\<ArticMine>** There may be a different approach. What if we were to limit the number of ring members comprising of these troublesome outputs to say 2 fakes
**\<ArticMine>** that would include coinbase and tx outputs a certain number of steps above coinbase
**\<sarang>** What's the advantage to this?
**\<rehrar>** what if we blacklisted all of the outputs in existence
**\<ArticMine>** Ensure the ring has a minimum unexposed number of fakes
**\<sgp\_[m]>** I would have to see the math before saying it would be effective. Coinbase outptus are already the minority, and they could still be revealed as decoys anyway. Would potentially limit impact to extend of all decoys compromised but hard to say
**\<ArticMine>** In my I idea I would include the real output if it was one of the gray outputs so actually two members of the ring as opposed to two fakes
**\<ArticMine>** I believe the way to deal with exposed outputs is to limit their number in a ring to two or possibly three rather than exclude them altogether
**\<sgp\_[m]>** Why not exclude them? They are known to be fake
**\<ArticMine>** If they are known spent yes, but if they are known unspent then no
**\<ArticMine>** that is the key difference
**\<ArticMine>** A coinbase tx for example is a known unspent output
**\<ArticMine>** Once it is included in a ring it can become unclear if it is unspent or not
**\<sgp\_[m]>** Not if a pool lists it on the site though
**\<ArticMine>** They make it a known unspent
**\<ArticMine>** by listing it
**\<ArticMine>** If they make the coinbase a known spent then it should be ideally blackballed; however if this cannot be easily automatically determined then simply including it in the limit I suggested becomes an option
**\<ArticMine>** Centralized blackball lists can also becomes an issue
**\<sarang>** ArticMine: yes, and that's why I wonder what they'll look like broadly
**\<ArticMine>** Which is why creating entropy around the exclusion of "blackballed" outputs may have some merit
**\<ArticMine>** Then it would also be impossible to as rehrar said blacklist "all of the outputs in existence"
**\<ArticMine>** It is an interesting attack by a centralized blackball list

241
_posts/2018-05-21-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-05-21.md Normal file
View file

@ -0,0 +1,241 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-05-21
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<sarang>** Let's begin the meetin
**\<suraeNoether>** sure
**\<rehrar>** ye
**\<suraeNoether>** i have a list of stuff i want to bring up
**\<suraeNoether>** but let's start with the simple stuff
**\<suraeNoether>** sarang: updates on BP audits?
**\<sneurlax[m]1>** hi all, I had a death in the family on the 14th so I have been travelling this week and have not made any progress on anything, really :(
**\<sneurlax[m]1>** I will remind you that I've reached out to ehanoc and will be working with them on python code but yeah, delays delays delays
**\<sarang>** Sure, so the audits are underway, will be checking in tomorrow with the groups for updates
**\<sarang>** Noting to report yet
**\<sarang>** sneurlax[m]1: sorry to hear that :(
**\<suraeNoether>** sneurlax I am sorry to hear about that. :(
**\<ArticMine>** What are the expected time lines for each group/
**\<sarang>** Looking at mid-July all around
**\<suraeNoether>** not bad
**\<sarang>** Yeah given that they work on a lot of projects
**\<suraeNoether>** sarang: what have you been working on for the past 2 weeks?
**\<sarang>** Otherwise, I've written up a noninteractive refund scheme in collaboration w/ Purdue folks
**\<sarang>** will be doing a formal journal paper for submission too
**\<suraeNoether>** ah yeah, that's on my lsit of stuff to read today
**\<suraeNoether>** nice
**\<sarang>** Have been keeping up with some Zcash flaws and plenty of other papers that came through the pipe
**\<sarang>** and advanced course prep for the upcoming crypto course
**\<suraeNoether>** i've started keeping a monthly "works cited/read" list
**\<suraeNoether>** any other updates?
**\<sarang>** Nice, I also include my reading list in updates
**\<sarang>** Also some good talk in here about BPs and fees
**\<sarang>** which needs to be settled soon
**\<sarang>** Can't deploy without consensus on the new fee structure
**\<rehrar>** this fees thing is not something we can keep saying 'we need to talk about this soon'
**\<rehrar>** it needs to get talked about ASAP
**\<suraeNoether>** Allright, so when Sarang and I were in london, we started hashing out (heh) a list of things for MRL to tackle in the upcoming year. we've been late on the research road map because... well, because there are lots of possible forks in the road, so to speak, and it's not clear which are dead ends, and which the community would like us to pursue. and near the top of the list is BP fee structure
**\<suraeNoether>** let's talk about it immediately after the meeting
**\<sarang>** rehrar: yes, we need concrete proposals with actual values
**\<ArticMine>** Once we have final figures on size and verification efficiency we can finalize on fees / blocksize
**\<suraeNoether>** before i get to my big list: has anyone else been working on anything interesting? I don't want to downplay the contributions of other folks
**\<endogenic>** well vtnerd has, a little
**\<suraeNoether>** oh?
**\<endogenic>** he was looking into xmr <> btc swaps
**\<sarang>** UkoeHB worked up a great draft of his tech explanation of transactions
**\<endogenic>** he came up with a funny method by which you'd have to burn your btc priv key :P
**\<sarang>** endogenic: there were all sorts of curve issues tho
**\<endogenic>** called it the sony method
**\<endogenic>** yeah
**\<UkoeHB>** I did?
**\<endogenic>** oh yeah didn't koe have something to gift surae? : P
**\<sarang>** UkoeHB: yeah, your extension of the magnus stuff, not sure if the latest work was before or after surae's departure
**\<UkoeHB>** Ah yes give me abt 10mins
**\<endogenic>** oh, one thing from my recent trip was noting a strong interest in ring sig alternatives research
**\<endogenic>** fwiw
**\<suraeNoether>** kurt magnus contacted me asking me for my comments before I left, and I was confused because I thought UkoeHB \*took over\* that paper from kurt, but kurt appears to think it's two separate projects now? maybe y'all should chat about that together...
**\<suraeNoether>** endogenic: seems like very few folks in the community oppose the idea of replacing ring signatures with something else
**\<endogenic>** suraeNoether: no i just meant people are excited about specific alternatives like starks
**\<UkoeHB>** Don't know surae kurt is rather curt
**\<endogenic>** rather than saying 'oh this is a problem'
**\<suraeNoether>** oh he spelled it with a k when he first got on irc \*shrug\*
**\<suraeNoether>** okay, so here's the list of stuff on my general MRL "todo" list:
**\<suraeNoether>** 1. BP fee models.
**\<suraeNoether>** 2. Transaction graph python library (see sneurlax[m]1 comment above)
**\<suraeNoether>** 3. Sarang and I would both like a full technical report on "what happens if PRNG is terrible in Monero? Failure model and effects analysis sort of deal.
**\<suraeNoether>** 4. Codifying Monero's best practices guidelines into a nice infographic. I believe sgp and rehrar have put some effort into this so far.
**\<suraeNoether>** 5. Monero Standards in general. We have lots of source material to start gathering these together, and I would like to get MOST of this done before next month; describing the current state of monero before BPs go live is probably going to be valuable later on.
**\<sarang>** 6. Payment channel infrastructure and prereqs
**\<endogenic>** ^
**\<moneromooo>** Ooooh yes please :)
**\<sarang>** We have some good work on 6 so far, but no definite path forward atm
**\<suraeNoether>** 7. network simulation library for testing things like consensus algorithms and difficulty metrics. (I am off-and-on working with a friend at University of New Mexico on using population-ecology models to look at mining incentives, etc)
**\<sarang>** There's more work on the actual channel implementation that's being worked on w/ Purdue folks, but those drafts aren't released yet
**\<suraeNoether>** 8. Ric's zk-s(t,n)ark zidechain proposal
**\<sarang>** at their request
**\<suraeNoether>** 9. I would like to write a paper on using heuristic analyses for constructing "ground truth" transaction graphs in private cryptocurrencies, and the common pitfalls that crop up from statistical points of view
**\<suraeNoether>** (for example, my common sensitivity vs. specificity complaint)
**\<suraeNoether>** 10. Churn analysis (ties with 9)
**\<sarang>** (and with 2)
**\<sarang>** Having the library will give really useful data into the churn models
**\<suraeNoether>** 11. I have written here "curve optimizations," but I feel like the ones we intend to use should be included in the monero standards... but it could be helpful for other projects for us to make a technical note about them
**\<suraeNoether>** in particular, seeing where we can cram them in elsewhere seems like a good idea
**\<sarang>** good ideas all around
**\<suraeNoether>** 12. General literature reviews (this is an ongoing thing, but since Sarang and I are constantly reading, we may as well start compiling our thoughts into common documents!). This ranges from zero knowledge proofs, to hash-based signatures, to reviews on pairings-based approaches
**\<rehrar>** I may have missed it, but was the multisig paper sent off for review?
**\<sarang>** There was a recent flaw in MuSig that IIRC will affect one of suraeNoether's proof strategies
**\<suraeNoether>** no: the flaws in the musig paper apply to my security proof too, so we are now... reading... a lot.
**\<sarang>** this happened during his absence
**\<suraeNoether>** this isn't to say that they were proven insecure
**\<sarang>** The MuSig fix is to add another communication round
**\<sarang>** it hardens the proofs substantially
**\<suraeNoether>** but merely that it's been proven that a proof of the security \*cannot exist\* under standard assumptions
**\<suraeNoether>** subtle point, but important
**\<sarang>** Yeah, and it snuck past a lot of people
**\<endogenic>** phew big list in any case
**\<suraeNoether>** a lot of very smart people
**\<suraeNoether>** 13. New elliptic curves. \*if we think it is valuable,\* and I think it is, I think we should reach out to folks for developing a family of suitable ECs that are compatible with 25519
**\<sarang>** Before I leave to do my crypto course, I'll continue the payment work w/ Purdue primarily, as well as get a bunch of educational material onto GitHub
**\<rehrar>** you'll be gone for one month sarang?
**\<sarang>** 3 weeks
**\<suraeNoether>** this is the sort of thing that could be a whole masters thesis, so that alone would be a sufficient project to require funding, I think... and there are dangers in rolling our own crypto, making our own libraries... so this is a bit controversial
**\<rehrar>** alright, great
**\<sarang>** one week is dumbass training that'll be "multitasking" =p
**\<sarang>** I'll also continue the audit coordination work during that time
**\<suraeNoether>** great
**\<sarang>** Otherwise it's full time teaching (not getting FFS during the month) so I'll have limited availability
**\<rehrar>** are they paying you in Dash?
**\<sarang>** but it's good outreach and PR
**\<sarang>** lol
**\<sarang>** fiat, those fools
**\<sarang>** I'll assign groups to each of our MRL goals secretly =p
**\<suraeNoether>** this huge list, is varying in urgency depending on items. i think BP fees, churn analysis + txn graph modeling, and the monero standards are the most important in my mind. almost everything else on the list would be great to tick off the list before another year is up
**\<suraeNoether>** but these are \*broad MRL goals.\*
**\<rehrar>** \*applause\*
**\<suraeNoether>** not a checklist of things I personally feel responsible for and need to get done (which is why multisig wasn't included on this list.) it's a roadmap list
**\<suraeNoether>** so, my question is
**\<sarang>** It's my personal desire to see a path set toward payment channels within the next couple of network upgrades
**\<suraeNoether>** ah yeah, i think that's super important too
**\<sarang>** depending on quality of proposals
**\<UkoeHB>** speaking of that
**\<UkoeHB>** tadah new chapter
**\<sarang>** go on...
**\<UkoeHB>** https://www.pdf-archive.com/2018/05/21/zero-to-monero-first-edition-v0-14/zero-to-monero-first-edition-v0-14.pdf
**\<suraeNoether>** good! i will read that today too
**\<sarang>** multisig!
**\<sarang>** excellent UkoeHB
**\<sarang>** I will also review
**\<suraeNoether>** SO! Does anyone want to add anything to the MRL broad goals for the 2018/2019 year?
**\<rehrar>** wow, that looks comprehensive.
**\<sarang>** Any new proposals contained in that UkoeHB, or just descriptions?
**\<endogenic>** suraeNoether: is that list ordered by priority or just generally?
**\<UkoeHB>** m-of-n and details on how to nest multisigs inside each other
**\<sarang>** great
**\<UkoeHB>** some conventions
**\<suraeNoether>** endogenic: it's very loosely ordered by the order that sarang and I thought of them after meeting philkode at green man in london. :D
**\<rehrar>** I think we're excited about BPs as an on-chain optimization, and we're looking for off-chain optimizations, but I think keeping a casual look at other opportunities for on-chain optimization is quite important. Not the least reason for doing so is to help quell the BTC/BCH debate from within our halls.
**\<UkoeHB>** and a walkthrough of all implications for monero transactions
**\<endogenic>** suraeNoether: kk
**\<sarang>** rehrar: totally, but optimizations to the level people \_really\_ want are not immediately forthcoming
**\<suraeNoether>** rehrar: one of the items on my list is "sublinear ring signatures," but because of this: we need to write a technical note to the community on why we don't intend on pursuing \*that route\* of on-chain optimizations.
**\<suraeNoether>** so add that as 14
**\<suraeNoether>** "14. explain why we don't have logarithmic ring signatures, and investigate other on-chain optimizations."
**\<sarang>** 14 is pretty straightforward to do
**\<rehrar>** If people see that we are pursuing both on and off chain optimizations it will hopefully keep the braindead squealing to a minimum
**\<suraeNoether>** well half of it is easy. :D
**\<suraeNoether>** thanks for that addition, rehrar, I agree
**\<suraeNoether>** anyone else have any suggestions for the MRL roadmap for the next year?
**\<rehrar>** sorry, I obviously don't have high opinions of people who adamantly hold to one side or the other of the BTC/BCH debate :P
**\<rehrar>** 15. Stupid contracts
**\<suraeNoether>** ha
**\<sarang>** Well having payment channel infrastructure available and understood will be a Good Thing even without a definite intent to move to large off-chain operations
**\<suraeNoether>** maybe the slogan of MRL should be something like "Don't be intellectually dishonest." In line with google's now-defunct code of conduct
**\<UkoeHB>** oh and a one-key lstag for generating shared key images with zero-trust
**\<rehrar>** you'd think so wouldn't you sarang?
**\<sarang>** I would
**\<rehrar>** if you'd kept up with the debates, you'd see that even good ideas, if proposed by 'the other side', become evil ideas
**\<sarang>** MRL: ruining everything since 20xx
**\<rehrar>** "a social/technical/something else attack"
**\<rehrar>** that's going on the t shrit
**\<suraeNoether>** UkoeHB: what page should i read that on, and are you comfortable with us using a lot of your document for the monero standards? (i've asked before but I want to verify)
**\<rehrar>** suraeNoether and/or sarang can these MRL roadmap goals be sent to me ASAP. I'd like to make a little simple graphic to share with the community.
**\<sarang>** Sure we'll work them up into something more formal on GitHub
**\<rehrar>** as well, anything that has been completed in the past year should go on the roadmap section of the website
**\<sarang>** agreed
**\<rehrar>** which desperately needs updating :P
**\<rehrar>** https://getmonero.org/resources/roadmap/
**\<sarang>** I'll need to run in about 5-10 min, btw
**\<rehrar>** we still in 2017
**\<sarang>** suraeNoether: can we talk formal roadmap in about an hour?
**\<suraeNoether>** okay, so now that the roadmap discussion is out of the way: I plan on reading about BIP47 today for endogenic, reading sarang's dual output paper with the purdue guys, and reading zero to monero again... and then after I've done those three finite tasks, I'll start reading the criticisms of the musig proof and continuing with multisig. and hten I'm going to write up my FFS for June-July-August because, like
**\<suraeNoether>** an idiot, i'm off the usual fiscal year again :(
**\<suraeNoether>** suraeNoether:
**\<suraeNoether>** yes
**\<suraeNoether>** sarang\* yes
**\<suraeNoether>** when you get back we'll talk about fees + roadmap
**\<sarang>** suraeNoether: sarang
**\<sarang>** sarang: suraeNoether
**\<suraeNoether>** heh
**\<sarang>** anything else before I head out? (parking metre is dumb)
**\<suraeNoether>** go fix your meter bruh
**\<rehrar>** serious request here
**\<suraeNoether>** also move to a place where you don't have meters
**\<rehrar>** can I get profile shots of both suraeNoether and sarang
**\<sarang>** ikr
**\<rehrar>** top of head to upper chest
**\<ArticMine>** One fees I do have a preliminary proposal ideas
**\<suraeNoether>** rehrar: are you making us those fake passports you promised? :D
**\<rehrar>** I'll talk with both of you about it later
**\<ArticMine>** When is later?
**\<suraeNoether>** ArticMine: do you have them written up, by chance, or is it going to be a platonic dialogue to talk about them?
**\<ArticMine>** I have not written it up yet but it is coming
**\<suraeNoether>** ArticMine: he meant about the pictures. we can talk about fees as soon as sarang gets back
**\<suraeNoether>** i want him to be able to ask questions
**\<suraeNoether>** like, live
**\<rehrar>** ArticMine: by later I mean the profile shots
**\<ArticMine>** but one question that came up is verification times
**\<ArticMine>** This was a very valid point raised by smooth
**\<moneromooo>** performance\_tests show you verification times for various cases. The only thing that I know will change it is Pippenger, if it gets coded.
**\<suraeNoether>** ArticMine: yeah, i wanted to do fees proportional to both expected ver time and space, but i feel like someone shot me down when i suggested ms-kB metric
**\<suraeNoether>** but i don't recall
**\<ArticMine>** It more an understanding on what verification times will be with current tech
**\<UkoeHB>** surae the table of contents should have everything. i don't recall you asking, but sure do whatever you want with it :)
**\<suraeNoether>** ah, yeah, we'll have to estimate, and it's hardware dependent but the info-theoretic lower bound on the number of operations isn't, and we can use that instead
**\<ArticMine>** and this will require the optimizations
**\<suraeNoether>** UkoeHB: if you seek peer review publication, we'll have to probably make sure that rights are reserved or blah blah so the monero project doesn't get sued by the publication company for copy-pasting a document you helped write while volunteering at MRL. :P
**\<ArticMine>** That is where copy left comes in
**\<suraeNoether>** ArticMine: well, the lower bound will be impelmentation-independent. like, "we know we have to check \*at least\* this many group elements, and therefore... " sort of argument
**\<UkoeHB>** is there any benefit to getting it peer reviewed?
**\<suraeNoether>** Last thing I wanted to mention as part of the meeting is MAGIC, the non-profit that sarang, myself, rehrar, sgp\_[m], and my wife are starting. we are currently waiting on communications from our lawyer and CPA re: filing our 1023. my wife is on the phone with him this morning taking notes, and we'll probably make a more formal update later today or at least before the end of the week. the main trouble has
**\<suraeNoether>** been finding CPAs and attorneys with the sufficient interest to learn about cryptocurrency law, etc
**\<ArticMine>** Yes but is that a valid basis for pricing vs size, or can ti be handled instead with a clawback / weight idea
**\<suraeNoether>** UkoeHB: eh, i merely thought that was your intention for the docuemnt.
**\<rehrar>** interesting indeed
**\<endogenic>** get scooby on your board man
**\<suraeNoether>** why scooby? is he a laywer?
**\<suraeNoether>** paging scoobybejesus
**\<endogenic>** well you said CPA
**\<rehrar>** I miss sarang already
**\<endogenic>** not to doxx him..
**\<scoobybejesus>** :D
**\<endogenic>** lol scooby you dont mind me volunteering your life do you? :P
**\<endogenic>** but anyway surae he may be able to point you in some direction
**\<suraeNoether>** that would be helpful
**\<suraeNoether>** right now it's our attorney calling all his CPA friends and getting shot down it looks like. :P but we will see
**\<UkoeHB>** It's to be educational more than anything
**\<scoobybejesus>** i snoop around the lounge, so i'll at least be sure to put in my two cents when appropriate
**\<UkoeHB>** Learning crypto and monero is haphazard and frustrating with no formal approach
**\<rehrar>** UkoeHB: people can only teach you about "hodling" nowadays
**\<suraeNoether>** cool thanks scoobybejesus
**\<suraeNoether>** UkoeHB: agreed, and you and me and sarang should chat about textbooks.
**\<scoobybejesus>** i hesitate to provide to much firm advice in this crypto wild west we're in, but i can sure help with understanding context and the like
**\<suraeNoether>** sool
**\<suraeNoether>** cool\*
**\<suraeNoether>** Allright, anything else anyone want to bring up for MRL? especially anyone who feels they have helped fund MRL and they have something they want to say?
**\<rehrar>** Nah.
**\<suraeNoether>** okay, well, \</meeting>

188
_posts/2018-05-28-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-05-28.md Normal file
View file

@ -0,0 +1,188 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-05-28
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<suraeNoether>** sure~
**\<suraeNoether>** Greetings everyone
**\<suraeNoether>** welcome to the MRL Research meeting for the week
**\<rbrunner>** Hi. Lurking for one here :)
**\<sarang>** yo
**\<suraeNoether>** mostly an informal discussion of what we've all been getting up to for the past week
**\<ArticMine>** hi
**\<jwinterm>** o/
**\<sarang>** Happy Memorial Day to those who celebrate it today!
**\<suraeNoether>** i know sarang has been discussing fees with myself and ArticMine, and we both have been talking about multisig with each other... does anyone want to put an item on the agenda?
**\<suraeNoether>** otherwise, sarang and I can just describe what we've done this past week and get on to it, but i know some folks have been working on a lot of stuff
**\<suraeNoether>** oh, man i forgot to ping UkoeHB
**\<endogenic>** ya if i may, you should ping ppl at the start of the mtg
**\<sarang>** Yes there is plenty to discuss for BPs, fees, and optimizations
**\<suraeNoether>** endogenic: I pinged people about 20 minutes ago
**\<suraeNoether>** but point taken
**\<suraeNoether>** Sarang, how about you go first
**\<sarang>** I worked with moneromooo to speed up BPs
**\<suraeNoether>** we can let people jump in with questions
**\<sarang>** Here is timing data for the expensive multiexp operations they use, to illustrate: https://imgur.com/a/rZB0vin
**\<sarang>** The green bar, Pippenger, is the new one
**\<sarang>** BPs start at 256 points, on the x-axis
**\<suraeNoether>** cool!
**\<endogenic>** suraeNoether: think both can be helpful
**\<sarang>** Once we finish up some testing, BPs will use a combination of algorithms. The speedup on the operations has been clocked at 40% of the original
**\<sarang>** The audits continue
**\<sarang>** What really remains is determining fees, as was discussed last week
**\<suraeNoether>** fluffypony knaccc luigi1111 anonimal andytoshi ArticMine binaryFate chachasmooth dEBRUYNE endogenic gingeropolous hyc iDunk IsthmusCrypto john\_alan JollyMort[m] jwinterm kenshi84 medusa\_ moneromooo MoroccanMalinois needmoney90 nioc nioc\_ othe philkode rehrar rrol[m] sgp\_[m] smooth sneurlax[m]1 stoffu TheCharlatan unknownids vtnerd waxwing
**\<suraeNoether>** okay, so let's talk about fees really quick
**\<sarang>** yes
**\<suraeNoether>** since verification times are roughly constant across powers of 2 (in terms of number of outputs) and the space is proportional to the number of outputs, we can get a good simple fee model going
**\<sarang>** This chart shows timings \_before\_ the new Pippenger optimizations: https://docs.google.com/spreadsheets/d/1HPk2a0atBqLqUlxQqBLiQXEJi-e1egIMYu3tS1NGHUo/edit#gid=0
**\<sarang>** It's the same chart as I presented last week, but gives an idea of timings
**\<suraeNoether>** say N = # outputs, and 2^(m-1) < N <= 2^m. then space is approximately N and verification time is approximately m = round(lg2(N)).
**\<sarang>** The timings also do \_not\_ account for batch verification, since that depends on what size proofs a client has
**\<sarang>** suraeNoether: space does not scale linearly with the # of outputs
**\<ArticMine>** It essentially forces verification time as the major pricing element when comparing a 2 output proof with 2^N output proof
**\<sarang>** Yes. Compared to Borromean, space is basically constant
**\<sarang>** at least across the ranges we deal with
**\<ArticMine>** 64 bytes for each additional factor of 2
**\<ArticMine>** From the table
**\<sarang>** yes, it's a very small increase
**\<sarang>** but among all costs to consider, it's the smallest
**\<suraeNoether>** wait, sarang, verificaiton time is O(N) and space is lg(N), right? according to that table we glanced at earlier
**\<sarang>** For single verification, yes, but it scales with the next power of 2 from N
**\<suraeNoether>** right
**\<sarang>** We don't have the more general BPs that can handle any number of outputs cleanly
**\<sarang>** (and we'd never get that change audited since it's tricky and not published)
**\<suraeNoether>** so, my point is: if we consider space to be wasted download time, then everything is about time, not space-and-time
**\<suraeNoether>** and so for fees
**\<sarang>** more or less
**\<suraeNoether>** we can either do space+time, and pick some constants a, b and charge fees a\*lg(N) + b\*N
**\<suraeNoether>** or we can do space\*time and pick some constant a and charge fees a\*N\*lg(N)
**\<ArticMine>** Yes we can convert between space and time. The question becomes the conversion factor
**\<suraeNoether>** so, for a 2-in-2-out transaction
**\<suraeNoether>** lg(N) = 1, N=2, so we charge a base fee of 2\*a
**\<suraeNoether>** whatever we think is fair for that, say a = 1 piconero
**\<ArticMine>** We have to modify the penalty formula this is critical
**\<ArticMine>** To reflect the time component
**\<ArticMine>** So converting time back to space is the simplest way
**\<rehrar>** ok here
**\<suraeNoether>** ArticMine: the time component is linear in number of outputs, and I think the penalty formula is already linear in the number of outputs?
**\<ArticMine>** We can use the 2 output proof ans the starting point. Then add a space weight linear to the number of outputs to account for the time
**\<suraeNoether>** wait, i'm getting myself confused here
**\<sarang>** Are we accounting for the fact that a 9-proof and a 15-proof take the same verification time, roughly?
**\<suraeNoether>** that's a hugely important observation
**\<ArticMine>** The penalty formula is size based and includes all the transaction inputs
**\<suraeNoether>** ArticMine: okay, so check this out
**\<ArticMine>** We have to price 9 and 16 the same
**\<suraeNoether>** ArticMine: the time to verify is approximately linear in size
**\<suraeNoether>** ArticMine: in number of outputs i mean
**\<ArticMine>** Time to verify is linear in outputs for each 2^N
**\<ArticMine>** so 9 and 16 is the same
**\<sarang>** It's linear in the number of outputs used, but we pad to ensure there are always 2^m
**\<sarang>** We'd need the unpublished BP modifications to get rid of that requirement
**\<ArticMine>** because of padding
**\<suraeNoether>** assuming everything is being rounded up to the nearest power of 2, time = O(N outs). space = O(log(N outs)), essentially. so fees can be a\*N + b\*log(N). agreed or disagreed? if measured in atomic units of monero, we can write this as N + c\*log(N) if we like and if we want to pick c carefully.
**\<sarang>** We do get much smoother time changes if we use separate proofs
**\<sarang>** but at the cost of greater size
**\<sarang>** This discussion is all assuming we require a single proof
**\<suraeNoether>** i am not assuming that at all
**\<suraeNoether>** i'm going proof-by-proof
**\<sarang>** Well
**\<sarang>** If we split proofs, each proof is an optimal size from a verification perspective
**\<suraeNoether>** if every proof pays fees in proportion to both space and time, then there's an economic incentive for wallet software to find the best solutions for output management
**\<sarang>** If we round, some are more optimal than others
**\<suraeNoether>** if someone wants to make a sloppy BP, then \*fine\* let them pay for it by simply charging in proportion to number of outputs. is what i'm saying
**\<ArticMine>** suraeNoether Yes size which determines penalty which in turn sets fees would follow a\*N + b\*log2(N)
**\<suraeNoether>** ok so next question: how many fees should a 2-in, 2-out transaction incur? what about a 2-in, 4-out transaction?
**\<ArticMine>** Though given the data I suspect that a\*N will be dominant
**\<suraeNoether>** ArticMine: it will be
**\<suraeNoether>** but since most txns are 2-in, 2-out, we're really over-optimizing the crap out of this
**\<jwinterm>** is it only the number of outputs that affects the verification time for BPs?
**\<suraeNoether>** all we need is a quick metric that asymptotically matches the cost in space and time. that's all we need. :P
**\<ArticMine>** For 2 in 2 out there is not change from the current formula
**\<sarang>** jwinterm: yes
**\<ArticMine>** Since this will be used as the base tx size
**\<suraeNoether>** okay, so call that fee F
**\<suraeNoether>** and we set F = a\*2 + b\*1
**\<sarang>** ArticMine: but I assume the prefactor will be smaller than currently
**\<sarang>** Since we're dropping both verification time and space from the current txns
**\<suraeNoether>** now for a 2-in 4-out transaction
**\<suraeNoether>** oh, we don't want to do that one
**\<suraeNoether>** we need linearly independent choices
**\<suraeNoether>** so what about a 1-in, 2-out transaction?
**\<suraeNoether>** ah, the fees will be the same
**\<suraeNoether>** heh
**\<suraeNoether>** okay, so what about a 3-output transaction?
**\<suraeNoether>** for a 4-output transaction, they'll pay double, so we may as well make a 3-output transaction 50% more
**\<ArticMine>** 3 out same as 4 out
**\<suraeNoether>** oh ok
**\<suraeNoether>** that works too
**\<ArticMine>** The will pay double on the proof
**\<ArticMine>** very likely but not on the rest of the tx
**\<moneromooo> \<@suraeNoether>** but since most txns are 2-in, 2-out, we're really over-optimizing the crap out of this
**\<moneromooo>** No, because this is a defense against attacks.
**\<moneromooo>** So you have to consider the worst case here.
**\<UkoeHB>** jumping in: yay new chapter
**\<UkoeHB>** https://www.pdf-archive.com/2018/05/28/zero-to-monero-first-edition-v0-17/zero-to-monero-first-edition-v0-17.pdf
**\<ArticMine>** Which is why we have to add a space penalty term for the spoace gains in say 2 out to 4 out 8 out etc
**\<suraeNoether>** thanks UkoeHB
**\<suraeNoether>** okay, so ArticMine and sarang, let's talk about fees after the meeting
**\<ArticMine>** Sure
**\<suraeNoether>** i don't want to waste a bunch of folks' time, but I think I have a formula
**\<suraeNoether>** sarang, my understanding is you are taking June off to teach, correct? and that during that time you'll be volunteering your time at MRL to complete, for example, the bulletproof audit
**\<sarang>** Yes, I'll be teaching a crypto course for Duke
**\<sarang>** w/o FFS pay
**\<sarang>** I'll be volunteering time to manage the BP udit
**\<sarang>** \*audit
**\<sarang>** If it ends up being more time than expected, I can adjust the next FFS accordingly
**\<sarang>** The first week of June is BS training, so I'll be partially available
**\<suraeNoether>** cool. UkoeHB care to share/describe your newest chapter in zero-to-monero?
**\<UkoeHB>** blockchain
**\<sarang>** lol
**\<suraeNoether>** "blockchain" he said, with stars in his eyes
**\<sarang>** short and sweet
**\<UkoeHB>** and two new appendices: block content, genesis block
**\<sarang>** If I were a VC, that statement alone would get you funding
**\<UkoeHB>** lol
**\<suraeNoether>** sarang i should have asked: do you have anything else you want to talk about before we move on?
**\<sarang>** Did a little timing on the noninteractive refund stuff, turns out they're a little faster than typical signatures
**\<sarang>** finished up the tech note, hoping for internal review before we release
**\<suraeNoether>** oh yeah, i wanted to ask: think there's a way we could compute \*all\* our key image basepoints in a way that can exploit the speed-up you discovered?
**\<suraeNoether>** sarang, can you also give us a link to your dual output tech note?
**\<sarang>** https://www.sharelatex.com/read/vcyxgpntfsgz
**\<sarang>** I don't know a great way to do it safely with just the single pubkey value
**\<suraeNoether>** k
**\<sarang>** If anything I'd rather find a way to reconstruct MLSAG to use other speedups
**\<sarang>** but I've given almost zero thought to that
**\<suraeNoether>** so, in the past week I've read this paper in detail (https://scholar.google.com/scholar?cluster=15619301617669058049&hl=en&as\_sdt=0,6) and this paper in detail (https://arxiv.org/abs/1503.08768) and this paper in detail (https://scholar.google.com/scholar?hl=en&as\_sdt=0%2C6&q=okamoto+beats+schnorr&btnG=) and this paper in detail (https://eprint.iacr.org/2018/068) to get to the bottom of this multisig
**\<suraeNoether>** unforgeability proof
**\<suraeNoether>** the long story short: I believe that by adding the commit-and-reveal phase of the musig appraoch to our ring signatures will result in a provably unforgeable scheme
**\<sarang>** too bad they couldn't fix it without that phase
**\<suraeNoether>** it's fine, i like that phase in general
**\<sarang>** but it also improves the security assumptions
**\<suraeNoether>** commitment isnt' scary, sarang
**\<suraeNoether>** yes, it does
**\<suraeNoether>** unfortunately, we fork all over the place
**\<suraeNoether>** and depending on the constructions, things can get out of hand rather quickly
**\<suraeNoether>** on the plus side, the paper is, once again... smaller than it was. :D
**\<suraeNoether>** unfortunately i'm debugging some latex code so it's not viewable right now
**\<suraeNoether>** that has basically been my whole life this past week, although I spent some time looking into what it would take for a zk-ledger-based sidechain to work merge-mined with monero
**\<suraeNoether>** i believe a very private "banking system" with off-chain transaction processing through semi-trusted third parties could be a second layer on top of monero
**\<suraeNoether>** but that's not where my mind has really been at, which has been on multisignature unforgeability proofs
**\<suraeNoether>** sarang, I believe, will be posting his monthly report, as will I...
**\<suraeNoether>** and later today, I'm helping advise zcash foundation on how to spend a quarter million of their dollars on grants
**\<suraeNoether>** anyone have any questions?
**\<sarang>** Yep, my report will go up later today, once I again remind myself how markdown works on various platforms
**\<sarang>** I love how it's different EVERYWHERE
**\<suraeNoether>** oh, and we have formalized our research roadmap from our meeting last week! i can't believe I forgot to metnion that
**\<sarang>** aye
**\<suraeNoether>** https://github.com/monero-project/research-lab/issues/29
**\<suraeNoether>** if anyone has questions or concerns or comments, that's a good place to throw them
**\<UkoeHB>** oh you can update z-to-m link with new draft :)
**\<suraeNoether>** yay
**\<IsthmusCrypto>** Nice roadmap. I'll definitely want to be in the loop for item 4, the "research infrastructure" - and I'll try to contribute myself.
**\<suraeNoether>** good to hear :D
**\<suraeNoether>** allright, well, let's finish this \</meeting> and talk about fees

226
_posts/2018-06-04-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-06-04.md Normal file
View file

@ -0,0 +1,226 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-06-04
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<sarang>** I can stay ~15 min today
**\<sarang>** poor cat
**\<unknownids>** :)
**\<sarang>** Coco hates car rides, needles, and strange places. This'll go great
**\<philkode>** Hey guys
**\<sarang>** yo
**\<suraeNoether>** so we'll go with 1. greetings, 2. give sarang a brief platform to talk with us about what he'll be up to before he has to dip out, 3. i'll give the community an update on the unforgeability of LSTAGs, 3. we'll bring up churning and best practices infographics, 4. any other projects anyone wants to talk about
**\<philkode>** Will be keeping one eye on the Apple WWDC keynote and one eye here
**\<suraeNoether>** philkode: i'll post transcript after the meeting so no worries there
**\<suraeNoether>** so, howdy everyone
**\<sarang>** heyo
**\<suraeNoether>** sarang, take it away~
**\<sarang>** As has been discussed elsewhere, BP reviews are humming along
**\<sarang>** moneromooo and I worked up the last big optimization we had hoped to get done for them
**\<sarang>** increasing verification speed
**\<sarang>** While I'm away I'll continue managing the review process as needed
**\<sarang>** Everything is coming up Milhouse for the next upgrade
**\<suraeNoether>** what's our "overall" verification speed improvement looking like, and do your changes only apply to the BP code for now?
**\<suraeNoether>** i recall around 50% improvement in total? or am i misremembering?
**\<sarang>** We're looking at up to >90% size benefits and >85% speed benefits for transactions
**\<sarang>** depending on batching, size, etc.
**\<suraeNoether>** freaking fantastic
**\<suraeNoether>** you win the internet
**\<sarang>** We'll get some "official" stats for public-facing publicity stuff
**\<sarang>** And yes, this only applies to BPs for now
**\<sarang>** but in theory any multiexp operation (besides aX+bY simple terms) could probably benefit from this
**\<sarang>** But BPs are the big use case right now
**\<suraeNoether>** this makes me want us to write our own 25519 library with pippinger and blackjack
**\<sarang>** nopenopenope
**\<suraeNoether>** i know, never roll your own crypto
**\<suraeNoether>** it may be worth incentivizing the creation of test suites, though
**\<sarang>** This was a case of good algorithm deployment, nothing more
**\<suraeNoether>** not libraries themselves, but test suites for libraries
**\<sarang>** but one that was on the back burner for a while
**\<suraeNoether>** but that's another discussion
**\<sarang>** Anyway, that's my Big News for today
**\<suraeNoether>** gratzo
**\<sarang>** Tests are available on mooo's branch
**\<suraeNoether>** anyone have any questions for sarang?
**\<sarang>** for anyone wanting to play with them
**\<sarang>** https://github.com/moneromooo-monero/bitmonero/tree/bp-multi-aggregation-pippenger
**\<sarang>** thanks to mooo for fast coding of my shit Python prototypes
**\<sarang>** =p
**\<suraeNoether>** mooo is actually seven dudes in singapore
**\<sarang>** I often agree with this hypothesis
**\<suraeNoether>** okay, if no one has any questions, i'll bring up a discovery i've made
**\<iDunk>** That would explain memory lapses.
**\<suraeNoether>** in terms of LSTAGs and unforgeability
**\<philkode>** Those are amazing size and speed up figures, really well done guys
**\<sarang>** ty philkode
**\<suraeNoether>** yes, sarang and moneromooo are MVPs of the ... year so far
**\<suraeNoether>** so, unforgeability: the Musig paper uses a double fork to accomplish their proof of unforgeability. while working through a ring-signature version of the same approach, i realized something
**\<sarang>** suraeNoether: wasn't it three forks?
**\<sarang>** or was that changed with the fixes
**\<suraeNoether>** it was 2 before and after the changes, whereas i initially thought we would need 3 for the ring signatures
**\<sarang>** oh ok, must be thinking of something else, nvm
**\<suraeNoether>** but, i was not just trying to do a ring signature version of the proof, but also a recursive-aggregation version, where keys have trees of family members, and as long as everyone is participating, they can cooperate to construct a signature simultaneously, in a big recursive signing party
**\<suraeNoether>** now, one fact about unforgeability proofs is that they often use rewinding-on-success or forking to prove their unforgeability, and every time you do this, the security bound gets looser and looser
**\<suraeNoether>** what i realized is that forking ring signatures the way i've been trying to do it, with trees of family histories of keys... the bound gets so freaking loose that you lose non-negligibility \*if the size of the family histories is a security parameter\*
**\<suraeNoether>** in other words: the forking approach to proving unforgeability, afaik one of the only real ways to prove equivalence wiht the DL hardness problem, \*seems to not be sufficient to allow an attacker to get the DL\*
**\<suraeNoether>** this \*suggests\* that violating the unforgeability of ring signatures is much harder than regular signatures
**\<suraeNoether>** it's not a proof on the relation between hardness, but it means that classic proof techniques \*may fail\* to prove unforgeability for arbitrary recursive key aggregation
**\<suraeNoether>** so, in other words: we have to fork once for each use of the honest key in the family history, which could be a big tree of re-uses of the same key, and in this case, the attacker can't present a forgery...
**\<suraeNoether>** so, long story short: i'm looking into merely restricting things to the non-recursive case, proving it secure in that case and remarking on the crappiness of the bound (instead of forking twice as in musig, we have to fork 2+ringSize times in this case, so you have a really really loose security bound, but you still hav ea non-negligible advantage
**\<suraeNoether>** and that's what i've been working on
**\<suraeNoether>** I wanted to be explicit about this particular fact, because it may end up being useful later: rewind/forking lemmas applied recursively cause adversaries to lose non-negligible advantages very quickly
**\<suraeNoether>** any questions in that regard before we start talking about churning and infographics and microsoft and github?
**\<UkoeHB>** jw about your eta for the paper
**\<sgp\_[m]>** That all went way over my head, but hopefully I can understand your work with churning!
**\<UkoeHB>** Sounds like you have some interesting stuff to work with
**\<suraeNoether>** UkoeHB: if i restrict the scope of this thing appropriately, i'll be posting a version of it later today that is a sketch of my intentions and then a more correct version of it later this week. I don't want this thing to take more time than the remainder of June.
**\<UkoeHB>** Cool :)
**\<suraeNoether>** and i've really pared this thing down, it's a lot smaller and more clear at this point
**\<suraeNoether>** now churn
**\<suraeNoether>** the biggest concern is that you receive some money from or send some money to an adversary (or first one then the other). if someone is "watching you," so to speak, then even if your transactions appear to look like background noise to the average observer and match the statistical pattern of the monero economy (somehow), the "watcher" can still sort of tell you are churning. they can look at an AML/KYC
**\<suraeNoether>** exchange's records with a warrant, for example, and see that an abnormal \*number\* of your transactions reference one of their poison outputs, even if the depths and distribution of those references appear to look like background noise
**\<suraeNoether>** to avoid this, even innocent parties have to reference these poison outputs \*quite often\*
**\<suraeNoether>** one solution is that \*everyone always does a lot of churning.\*
**\<suraeNoether>** not just people who care about securtiy
**\<suraeNoether>** sort of like ring size minimums
**\<suraeNoether>** i don't know how one could enforce that, thoguh
**\<sgp\_>** I think the only way would be a large minimum (likely impractical) ringsize, yeah
**\<sgp\_>** Difficult to force people to send transactions
**\<suraeNoether>** not just a minimum ring size that is large, but some sort of structure that requires "you can send this to (A,B), but only if you send it through (X,Y) and (W,Z) first"
**\<suraeNoether>** but if we do that
**\<suraeNoether>** we're talking about a massive blockchain blowup
**\<sgp\_>** hmm
**\<sgp\_>** The input selection algorithm can't help with this?
**\<erciccione\_[m]>** maybe a timed pop-up on the GUI-CLI saying: churning help your privacy, do you want to churn now? every week or so (i don't know how stupid this can sound)
**\<suraeNoether>** input selection could be tweaked so that inputs are chosen with a probability that is inversely proportional to the number of references that have been made (so that no output goes long without being referenced a few times)
**\<sgp\_>** I think that's more reasonable
**\<suraeNoether>** erciccione\_[m]: we have to weigh the benefits of security against the increased weight of our blockchain in the long term, if we are going to go down that route
**\<suraeNoether>** so, i'm going to write up a proposal on input selection algorithms
**\<sgp\_>** Do you have an idea how many times you want each output referenced? Obviously the more the better all else being equal
**\<suraeNoether>** simply the more the better
**\<UkoeHB>** Outputs can't be referenced more than ringsize number of times on average
**\<erciccione\_[m]>** shouldn't the ringsize become larger anyway after BP get implemented?
**\<sgp\_>** It sounds like you're hoping for a ringsize increase too then
**\<suraeNoether>** UkoeHB: \*can't\* be, or under mild assumptions, will asymptotically tend toward the ring size?
**\<sgp\_>** Well, the average number of references depends on the average number of inputs and outputs in transactions
**\<sgp\_>** There are likely more outputs than inputs on average, meaning that the references should be less than the ringsize over a long term
**\<suraeNoether>** each output can be referenced at most R\*number of transactions ahead of it in the blockchain. so the total number of references would be R\*N + R\*N-1 + ... + R\*2 + R, so the maximum average would be R\*(N-1)/2 references (although the true average would be much smaller in general)
**\<UkoeHB>** How could the average output be referenced more or less than ringsize, if total number of references is ringsize\*numouts?
**\<sgp\_>** Of course there could be periods of mass consolidation where it could be the opposite
**\<suraeNoether>** anyway, this is all a bit accessory to the point, which is that the probability that an output is selected should be jointly proportional to (1) 1/# of references that already exist and (2) the gamma distribution from bitcoin's age data (although combining data from litecoin would be helpful)
**\<suraeNoether>** and probably only from the non-blackballed list
**\<m2049r[m]>** dynamic ringsize is not an option based on which inputs are actually used?
**\<UkoeHB>** It makes sense. Reduce reference spread
**\<suraeNoether>** m2049r[m]: eh, I usually think about ring size only in terms of the minimum, because people really shouldn't be advertising their behavior by selecting out-of-the-ordinary ring sizes
**\<sgp\_>** those two sound good suraeNoether
**\<suraeNoether>** the question earlier about larger ring sizes
**\<sgp\_>** and hope that people do the third
**\<UkoeHB>** Could you poison outputs? Simply reference one a bunch of times so it becomes extremely improbable. Then, when you spend it, it's probably real
**\<dEBRUYNE>** because people really shouldn't be advertising their behavior by selecting out-of-the-ordinary ring sizes <= A good argument to enforce static ring sizes after the next HF
**\<suraeNoether>** UkoeHB: yes, you could, actually! nuts. that's the consequence of using things like temporal heuristics and selection frequency to try to mask erratic human behavior :(
**\<dEBRUYNE> \<UkoeHB>** Could you poison outputs? Simply reference one a bunch of times so it becomes extremely improbable. Then, when you spend it, it's probably real <= You could still reference it after spending it?
**\<UkoeHB>** dEBRUYNE: if selection probability is 1/(prev references), someone can reference an output many times
**\<UkoeHB>** reduces likelihood future references ARENT real
**\<suraeNoether>** dEBRUYNE: NSA wants to know if an output has been spent. So they manufacture 1000 ring signatures referencing it. almost no one except the true spender will include it in any future ring signatures because it is 1000 times less likely to be selected at random. so after the nsa do this experiment, the first time the output in question appears on the blockchain is very likely a true spend
**\<sgp\_>** "I send money to you, knowing which output I give you. Then I make 100 transactions with this output as a decoy, meaning the only likely other transaction that will include it is the real one"
**\<suraeNoether>** it's real bad
**\<suraeNoether>** it's a \*real bad idea.\*
**\<UkoeHB>** maybe we just triple ring size after BP
**\<dEBRUYNE>** sgp\_: But an observer doesn't know when it is used as decoy and when it is actually spent
**\<suraeNoether>** it reverses the "guess newest" rule from monerolink and turns it into a "guess the last possible spender"
**\<sgp\_>** dEBRUYNE right, but if the input selection algorithm is tweaked to prefer lesser-used outputs, then it may not be used outside of the actual transaction
**\<suraeNoether>** dEBRUYNE: no, but an observer can be pretty sure that the output has been spent. besides, if 1000 transactions referencing an output P occur in a single block, and then a week later a single transaction with P occurs, that is strong circumstantial evidence that this attack occurred and the single lonely P from later in the week is likely the true spender
**\<needmoney90>** Why not choose probabalistically between different selection algos
**\<UkoeHB>** Or define a 'ring sig ambiguity tree' factor, analyze as function of ring size, and select a new ring size w/ justification. Instead of arbitrarily increasing
**\<needmoney90>** One which prioritizes unused outputs, one which chooses uniformly
**\<hyc>** why wouldn't attacker spread txs across many blocks?
**\<needmoney90>** For example
**\<dEBRUYNE>** suraeNoether: Why wouldn't he spend it in one of those 1000 transactions and reference it as decoy a week later?
**\<sgp\_>** Some may be stronger than others. A uniform one falls under the shortfall where the newest is typically the real one, and this phenomemon will get worse over time
**\<dEBRUYNE>** You have to account for the alternative scenario here as well
**\<suraeNoether>** hyc \*shrug\* they may be impatient, or they may want to expose the true spender to the whole community maliciously instead of keeping the information to themselves. there are other attack models
**\<UkoeHB>** I mean, new ring size that synergizes with a churn strat
**\<needmoney90>** Sgp\_ the point was to have multiple selection strategies, where one is randomly chosen, and some of them have a chance to use a ring member previously used 100x
**\<suraeNoether>** dEBRUYNE: the point is merely that this could be exploited to make it easier for an attacker to tell if a given output they don't control has been spent. that's all. the specific threat models aren't as important as the observation that it can be exploited \*somehow.\*
**\<suraeNoether>** in other words: since output reference frequency can be adversarially controlled, we can't use it as part of our input selection method
**\<needmoney90>** So someone using a ring member you poisoned by including it in a ring a lot doesn't mean they're the real spender
**\<needmoney90>** They could have just used a selection algo that chose it
**\<sgp\_>** I still think it is good to adapt the selection algorithm with this criteria in mind, perhaps only to a small extent though. Maybe a 10-20% preference
**\<suraeNoether>** it does if all wallet software selects outputs \*in inverse proportion\* to frequency of spending
**\<suraeNoether>** which is what we are talking about needmoney90
**\<needmoney90>** Yes surae, I'm saying we can add multiple selection algos, where one of them doesn't choose with inverse proportion
**\<needmoney90>** Even if a given tx only has a 10% chance of using it
**\<UkoeHB>** sgp\_: even in that case, it gives block chain analysts more power to reduce effective ring sizes
**\<needmoney90>** It adds plausible deniability
**\<suraeNoether>** needmoney90: yes, okay, but to give you an idea of the challenges we face here, let's reduce it to a simple case where we have two algorithms, A1 and A2
**\<suraeNoether>** and we pick one with probability p and the other with probabiltiy 1-p
**\<UkoeHB>** Any programmatic deviation from natural distribution can be analyzed
**\<sgp\_>** Yeah, but only by ~1 or 2 UkoeHB. May be less than the reduced risk of some outputs being referenced few times
**\<needmoney90>** It will be apparent which was used
**\<needmoney90>** For sure
**\<needmoney90>** Hm
**\<suraeNoether>** now an attacker who has success with algorihtm A1 just needs to make the attack 1/p times
**\<suraeNoether>** instead of only once
**\<suraeNoether>** so, this brings us back towards plausible deniability, which is good
**\<suraeNoether>** but it still isn't protection against the attack
**\<needmoney90>** We can continue in lounge after the meeting, sorry to derail
**\<suraeNoether>** if you have many algorithms, this increases the sample size the attacker needs to attack any one of them
**\<UkoeHB>** sgp\_: it might ok if we increase ring size dramatically
**\<suraeNoether>** which is that plausible deniability, which is good, but still gamable
**\<suraeNoether>** UkoeHB: any deviation from "natural" is identifiable, you are right, and the problem is we have small anonymity subsets chosen from a (still unfortunately rather small) anonymity superset
**\<suraeNoether>** there merely isn't a good statistical mask for behavior here, the fix has to be to replace ring sizes
**\<ArticMine>** You mean increase ring size
**\<UkoeHB>** Any good prospects for escaping ring sigs?
**\<suraeNoether>** erg.... replace ring signatures\*
**\<ArticMine>** with ...
**\<sgp\_>** Is there anything else that works without trust?
**\<suraeNoether>** whatever comes next :)
**\<suraeNoether>** there are untrusted stark set-ups that are slow
**\<suraeNoether>** or use weird pairings
**\<suraeNoether>** i'm looking into options
**\<suraeNoether>** but the fact of the matter is, small anon sets will need to go for this problem to really be solved
**\<suraeNoether>** in the meantime, churning isn't going to help you if all the transactions you deposit on your AML/KYC exchange originated somehow from a malicious watcher like the DEA or NSA or something
**\<suraeNoether>** and churning more than 3-4 times is probably overkill if all you are worried about is helping flesh out our anonymity sets
**\<gingeropolous>** so ... what should we put on getmonero.org regarding churning... ? :)
**\<suraeNoether>** gingeropolous: give us a few days to write up a formal thing
**\<gingeropolous>** cool
**\<suraeNoether>** gingeropolous: because i want some specific numbers on how much you are really exposing yourself
**\<sgp\_>** Can you give us a hint on the relationship between churning and ringsize? How significant is it?
**\<UkoeHB>** exponential?
**\<suraeNoether>** well, the naively computed anonymity set of a monero transaction tree of depth H with ring size R is approxiamtely O(R^H)
**\<suraeNoether>** so
**\<suraeNoether>** the question is "how many times are you going to pull a poison jelly bean out of this jar with R^H jelly beans in it, only one of which is poison?"
**\<suraeNoether>** oh, "while grabbing R jelly beans at a handful?"
**\<suraeNoether>** and these answers require some statistics involving the hypergeometric distribution, or binomial approximations...
**\<UkoeHB>** I'm having flashbacks
**\<suraeNoether>** hahah
**\<suraeNoether>** let me summarize: churning 80 times wiht ring size 10 gives you more possibilities than the number of fundamental particles in teh universe
**\<UkoeHB>** Ok we are at end of meeting so I'll jump in
**\<suraeNoether>** churning 7 or 8 times with ring size 10 gives you more possibilities than the monero blockchain
**\<suraeNoether>** but a lot of these are collisions
**\<UkoeHB>** Final draft: open for edits and feedback. Plan to publish in 2 weeks
**\<UkoeHB>** https://www.pdf-archive.com/2018/06/04/zero-to-monero-first-edition-v0-20/zero-to-monero-first-edition-v0-20.pdf
**\<suraeNoether>** by "collisions" i mean 'the true anonymity set is much smaller.'
**\<UkoeHB>** sarang will be happy to see pg 50 (57 of pdf)
**\<suraeNoether>** if everyone on the network churned 2-3 times, we'd all be better off. anyone who lives in a sensitive land of security nightmares should churn maybe 8 times, but definitely shouldn't be using AML/KYC exchanges, and if they do, the vast majority of their deposits at those exchanges should \*not\* be sensitive.
**\<sgp\_>** makes sense suraeNoether, given the selection algorithm
**\<suraeNoether>** UkoeHB: good job, i'll try to read it before the end of the week
**\<UkoeHB>** awesome thanks :)
**\<suraeNoether>** i wanted to ask if folks were worried about github and microsoft and alternatives we may want to look into, but i think that can wait till later
**\<suraeNoether>** anyone have any last questions before we finish up?
**\<needmoney90>** Any official status updates on atomic swaps?
**\<suraeNoether>** needmoney90: dual output ring signatures for refund transactions should enable atomic swaps, but there are some security concerns involved with those that will make it easier to determine spent outputs
**\<suraeNoether>** so, there has been progress made, sarang wrote a technical note on the dual output sigs... but we are examining "what it means" for us to have two outputs with a differentiating/trigger block height.
**\<suraeNoether>** it is too easy to see if one or the other has been spent based on block height, and introduces some temporal stuff: if a transaction happens right after a trigger block height for a ring member, that ring member is likely to be the true spender in a refund
**\<ArticMine>** UkoeHB Great job. I was looking at the block size scaling part
**\<suraeNoether>** if the block height is encrypted, there are different problems that show up
**\<ArticMine>** This is on my reading list for this week
**\<suraeNoether>** oooh, i like reading lists
**\<suraeNoether>** okay, any other questions?
**\<UkoeHB>** oops mistake in range proof verification. 63 is for A+B
**\<suraeNoether>** okay, \</meeting> :D

64
_posts/2018-06-11-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-06-11.md Normal file
View file

@ -0,0 +1,64 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-06-11
summary: MRL work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<suraeNoether>** Greetings everyone!
**\<endogenic>** ??
**\<suraeNoether>** I'm Surae, and I'll be accompanying you on this mathematical journey today
**\<suraeNoether>** Our agenda today is simple. 1. Greetings. 2. I'll give a brief update on the multisig paper, giving a brief update on MAGIC, and a brief talk about the recent paper on constant-sized ring sigs that made its rounds on twitter this morning.
**\<suraeNoether>** 3. I'll open it up for any updates or projects anyone else is officially or unofficially working on
**\<suraeNoether>** 4. Q&A
**\<suraeNoether>** So, 1. Greetings everyone! say hello if you are sitting in on this one or lurking
**\<suraeNoether>** okaaaaaaaaaay 2. Multisig paper will be done later this week, I'm just putting finishing touches on it before i send it out for review by some smarter parties than myself. it's a lot more clear and correct and compact now, and it actually makes some sense re: simulations and signing oracles. some details are still lacking, but that's what the rest of this week is for. https://v2.overleaf.com/read/bfjfkdgnhgvh
**\<oneiric\_>** oh hi
**\<suraeNoether>** MAGIC and MRL are going to have a presence at defcon this year, and I was hoping sgp\_[m] could say something about that, but it looks like I'm alone today, and that's okay. Hopefully we can sell some MAGIC t-shirts and start accepting donations.
**\<suraeNoether>** We had some speedbumps to overcome in terms of getting MAGIC off the ground. CPAs and lawyers who didn't really have time for new clients who thought they could waste our time, etc.
**\<binaryFate>** bonsoir
**\<suraeNoether>** howdy oneiric\_ and binaryFate
**\<suraeNoether>** I mentioned earlier about a constant-sized ring signature scheme in the random oracle model. it's actually a really neat scheme, but it uses bilinear pairings and takes a lot more verification time than our current set-up, so it isn't really suitable as a replacement. i did a little tweetstorm on it this morning you can see here. https://twitter.com/BGGoodell/status/1006203923827343361
**\<UkoeHB>** Is there a white paper for it?
**\<suraeNoether>** https://link.springer.com/article/10.1007/s11390-018-1838-z
**\<suraeNoether>** not white
**\<endogenic>** i linked it earlier
**\<suraeNoether>** Let's see here, in addition to that, I have a script for a white-board video on cryptocurrencies that i am fleshing out. rehrar mentioned he would be willing to help when he gets back, and that could be fun and cool.
**\<binaryFate>** I was quite offline last 3 days, didn't see the twitter storm. It's constant-size in space, right? How does it scale for verification time?
**\<suraeNoether>** in the meantime, i'm interested in doing a plausibility analysis of a RLWE-based version of Monero instead of a discrete logarithm-based version, but that's a longer-term thing. I've been taking notes on all the multisig papers i've been reading for a comprehensive literature review that i plan on publishing later this summer, too, and that's coming along nicely (although no links available yet)
**\<suraeNoether>** binaryFate: it's a lot slower
**\<suraeNoether>** same nubmer of exponentiations, but also a linear number of pairings operations
**\<binaryFate>** Ok. First time someone comes up with a constant-size scheme without any sort of setup no? Neat even if not usable for us
**\<suraeNoether>** yep!
**\<suraeNoether>** Other than that, sarang and I posted the roadmap on github a few weeks ago, and we are still hoping for discussion and/or comments about additions or expansions to the topics listed. https://github.com/monero-project/research-lab/issues/29
**\<binaryFate>** Sorry if I'm behind the curve, what's RLWE?
**\<suraeNoether>** Ring-Learning-With-Errors, it is a hardness assumption that is thought to be resistant to quantum computers, and a lot of "lattice-based" crypto schemes rely on it
**\<suraeNoether>** a lot of "lattice-based" ring signature schemes are available, too
**\<binaryFate>** So that would be to use ring sigs resistant to quantum computers?
**\<oneiric\_>** That's awesome surae, find anything interesting/potentially usable there?
**\<suraeNoether>** oh, i don't know yet, i just know that most of the frameworks are available to be assembled together carefully
**\<suraeNoether>** it's an interesting route of inquiry, but htat's all at this point
**\<binaryFate>** How does that relate to plausible deniability (if a ring remains a ring, just using different underlying math)
**\<suraeNoether>** binaryFate: the hope is merely to replicate all of monero's current capabilities in a setting where an adversary with a quantum computer is trying to peek in on amounts, or to cheat the system to mint money, or to try to forge signatures.
**\<suraeNoether>** the signatures would still be ring signatures with plausible deniability as we currently have, just built with a scheme with a different hardness assumption
**\<suraeNoether>** there's almost no point in having ring signatures in that setting though, even if they are QC-resistant to forgery, becuase a QC computer can enumerate the spending tree and find true spenders very efficiently; a QC-resistant privacy-focused currency, I think, really has to be built on large-anon set technology
**\<suraeNoether>** otherwise you could use far less exotic QC-resistant signatures to accomplish the same deal
**\<suraeNoether>** anyway, since we are probably going to have to switch to pairings or starks or something weird eventually anyway in order to get our large anon sets, i started thinking a little more broadly
**\<suraeNoether>** UkoeHB: do you want to update us on ZTM?
**\<suraeNoether>** maybe later today :D
**\<suraeNoether>** Does anyone have any questions for me or MRL in general?
**\<UkoeHB>** mostly proofreading and edits
**\<suraeNoether>** Okay, well, if anyone has any questions or concerns for me, I'll be here for most of the rest of the day and you an always e-mail me at suraeNoether@protonmail.com
**\<suraeNoether>** \</\\meeting
**\<suraeNoether>** \<.,>d;fhadlf
**\<oneiric\_>** lol, thanks for the information suraeNoether
**\<UkoeHB>** here is latest draft https://www.pdf-archive.com/2018/06/11/zero-to-monero-first-edition-v0-20-3/zero-to-monero-first-edition-v0-20-3.pdf
**\<suraeNoether>** thanks UkoeHB
**\<suraeNoether>** and thanks to endogenic for throwing that link in earlier
**\<UkoeHB>** aiming to close proofreading sunday night, then PR getmonero, for publish ~1 week later
**\<UkoeHB>** unless proofreaders more time, then ill push it out
**\<oneiric\_>** really tremendous work coming out of the research lab, as always. much excite for 2018-2019!
**\<binaryFate>** thanks suraeNoether for the updates!

139
_posts/2018-06-18-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-06-18.md Normal file
View file

@ -0,0 +1,139 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-06-18
summary: MRL work, DefCon plans, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<suraeNoether>** fluffypony knaccc luigi1111 anonimal binaryFate chachasmooth dEBRUYNE endogenic erciccione\_[m] gingeropolous hyc iDunk isthmuscrypto john\_alan JollyMort[m] jwinterm kenshi84 kerber m2049r[m] moneromooo MoroccanMalinois needmoney90 nioc othe philkode pigeons rehrar rrol[m] sarang sgp\_[m] stoffu unknownids vtnerd waxwing, research meeting in three minutes~
**\<suraeNoether>** and of course UkoeHB who is already here and aware :D
**\<silur>** it's time \\o/
**\<ArticMine>** Hi
**\<rehrar>** hi
**\<suraeNoether>** 1. Greetings! 2. Work from this past week. I was hoping to chat about BP fees and where they are currently at, i wanted to update folks on the multisignature paper and literature review, I wanted to share a few links to papers I'm reading... and open up the floor to anyone else doing anything fun and math and crypto related. 3. Plans for this upcoming week and defcon?
**\<suraeNoether>** So, hi everyone :D
**\<suraeNoether>** does anyone want to add anything to our little makeshift agenda before we get goin?
**\<suraeNoether>** okay, cool
**\<suraeNoether>** as far as bulletproofs go, apparently Quarkslab will be done by the end of the week and Benedikt has begun work (I think). Quarkslab has apparently found a few small optimizations, but no bugs so far (but that could be outdated info)
**\<suraeNoether>** ArticMine: do you want to bring the community up to speed on where we are currently sitting in terms of bulletproofs fees? you've led the charge for a lot of that discussion
**\<rehrar>** yay ArticMine
**\<ArticMine>** I have the basic concept down
**\<ArticMine>** Replacement of the blcoksize with block weight
**\<ArticMine>** That is linear with an increase in verification time
**\<suraeNoether>** i believe the last time we talked about this, taking space and time together into account led to a formula that was like n + log(n) in number of outputs. by picking fees based on n only, this means we are slightly under-compensating miners for large bulletproofs and slightly overcompensating them for smaller ones, leading to a weak batching incentivization without distorting our ideas of cost paid by the
**\<suraeNoether>** miner in both space and time. since the space paid is logarithmic, its impact is rather small, even for large bulletproofs.
**\<ArticMine>** This will replace the blocksize in the determination of the penalty. Fees then follow from the penalty based weight calculation using the current formula
**\<suraeNoether>** \*nod\* are we not modifying the current formula to make overall fees lower?
**\<ArticMine>** We are not modifying the formula however the weight will be a lot lower than our current blocksize
**\<ArticMine>** So we still have to change the minimum fee
**\<ArticMine>** For a 2 output transaction the block weight will equal the block size
**\<suraeNoether>** ah i see
**\<suraeNoether>** we should get a formal description of our proposed bulletproof fee structure out to the community so they can start discussing it soon
**\<suraeNoether>** so I'll try to put 2-3 hours into that this week
**\<ArticMine>** What really matters is that as the number of outputs the weight scales linearly with number of outputs
**\<ArticMine>** I expect to have a formal description out by the middle to the end of next week
**\<suraeNoether>** cool, let us know if you need more hands
**\<ArticMine>** After the weekend I expect to have 2-3 days I can dedicate to this
**\<ArticMine>** There are a lot of details
**\<suraeNoether>** we have some folks who are interested in contributing to MRL but don't necessarily have a project, so there are lots of eyes we can put on it as well
**\<suraeNoether>** Allright, moving on
**\<suraeNoether>** I've been discussing our multisig scheme with UkoeHB and a few other folks. I have contacted one of the musig authors about an issue UkoeHB brought up. It's... causing me sufficient pause to reach out. Essentially, my first (and second and third) reading of the scheme seems to allow for a replay attack
**\<silur>** our multisig scheme ?= RTRS multisig?
**\<moneromooo>** no, threshold sigs.
**\<suraeNoether>** the musig scheme + our scheme. it \*seems\* to allow an honest adversary to be cloned or rewound in a way that may be dangerous. of course, in the musig paper there is a whole section on derandomization and not re-using signature data... this is a \*known issue\* but I'm not sure if their security model is sufficient.
**\<suraeNoether>** our threshold scheme, not RTRS
**\<suraeNoether>** so, due to this, i've gone back to some older papers on multisignatures and simulation theory to look into it
**\<suraeNoether>** right now i'm reading a primer on simulation theory by Lindell, who is a good author and has written a rather comprehensive document on the matter (pdf link https://eprint.iacr.org/2016/046.pdf)
**\<suraeNoether>** and i've gone back to some of the original certificate authority and/or KOSK assumption papers because their security models are highly relevant
**\<suraeNoether>** https://hovav.net/ucsd/dist/agg-sig.pdf
**\<suraeNoether>** during all this, by the way, I'm taking copious notes on multisignature schemes and old papers for a future literature review
**\<dEBRUYNE>** ArticMine: Great to hear (about the fee stuff). I, however, hope we're not making it unnecessarily complex
**\<ArticMine>** The concepts are very simple and elegant if we work at the protocol level and change the penalty from block size to block weight
**\<suraeNoether>** dEBRUYNE: eh, essentially we are merely changing the fee structure to count the outputs in a block instead of absolute size in bits, or bytes, or kb, or what have you, that's the core idea of the change
**\<ArticMine>** Strictly speaking we are changing the penalty formula to take into account ^
**\<suraeNoether>** other than that (deep diving into the simulation theory and the dark corners of the multisig world), I wanted to see what other folks are working on (silur?), and maybe chat about defcon first, a monero conference second, and a MAGIC conference in privacy technologies third. things seem so quiet around here without sarang
**\<ArticMine>** The fees then follow with essentially no change other than the minimum fee to account fro the much lower overall weight
**\<rehrar>** sarang was the heart and soul of MRL
**\<ArticMine>** A very important distinction is that the penalty formula is consensus while the fees are not
**\<rehrar>** read: was
**\<ArticMine>** was?
**\<silur>** I'm continuing my RTRS implementation
**\<rehrar>** was talking to suraeNoether, ArticMine
**\<silur>** HCPP invited me to make a demo there
**\<suraeNoether>** silur are you implementing that on github? have a link?
**\<silur>** RTRS still needs heavy testing, i kinda tend to do 'if it compiles it's ready'
**\<silur>** sure
**\<silur>** https://github.com/Silur/libstringct
**\<suraeNoether>** tim ruffing contacted me, their scheme has been modified and they are coming out with a newer version of it. as a sample, their signatures are about 1.12 kb for a ring size of 64
**\<suraeNoether>** thanks silur
**\<rehrar>** how long is verification for that ring size?
**\<silur>** great to hear, although the current docs are already outdated
**\<silur>** would be nice to have that paper out :D
**\<silur>** are there any sketches on the mods?
**\<suraeNoether>** he has been loose with details silur, but he contacted me about it tuesday last week and he said he'd get me the paper this week. maybe, maybe not. :P it's how research goes, even at universities like saarlang
**\<suraeNoether>** rehrar: no idea, i don't wnat to speculate
**\<suraeNoether>** rehrar but my knee jerk instinct is "about as much time as an LSAG with 128 ring members"
**\<ArticMine>** Also are there any non linear with size verification times
**\<suraeNoether>** or "no less than" instead of "about as much time as"
**\<suraeNoether>** ArticMine: not with a usual ring signature model. technically you could count zk-snarks as sublinear verification time ring signatures that require a trusted set-up, but htere is nothing in the chasm/gulf between our untrusted set-up hash-based ring signatures and the zk-snark world
**\<suraeNoether>** everything with RTRS has to take around double the amount of time for each group operation, since keys are double in length... and our hash-based set-up is pretty much as close to an information-theoretic minimum allowable in terms of "number of group operations" in order to compute a ring signature, we are very optimal in that regard, very few wasted computations... so "best case" RTRS will be double the
**\<suraeNoether>** verification time of an LSAG
**\<suraeNoether>** so, uh... what's up with defcon
**\<ArticMine>** The bottom line we do not have to deal with a situation similar with bulletproof verification times
**\<suraeNoether>** who all is going to be at defcon?
**\<ArticMine>** I am
**\<ArticMine>** I am alos giving a talk related to the fee question
**\<ArticMine>** also
**\<suraeNoether>** nice
**\<suraeNoether>** i heard something about a booth
**\<suraeNoether>** i believe that sarang and I both declined actually having an MRL booth, but I'm happy to sit around at the monero booth for awhile, presuming... we have a booth (and now the word booth is meaningless, it's been said too much. like the word kiosk)
**\<rehrar>** hmmm....then there was a misunderstanding
**\<rehrar>** I thought it was "we'd man the booth if there was one, but not for the whole time cuz we want to enjoy the conference"
**\<rehrar>** I'll communicate and change that right away if I was incorrect.
**\<suraeNoether>** oh, no, i think i'm mis-remembering
**\<suraeNoether>** we can totally do a booth
**\<suraeNoether>** i need to make a t-shirt or something
**\<rehrar>** it'd probably be split with Kovri temporally
**\<suraeNoether>** turf warrrrr
**\<rehrar>** I don't think MRL needs to prepare anything special unless you guys want to
**\<rehrar>** just sitting at the table and fielding questions would be sufficient
**\<suraeNoether>** but i want a t shirt ;(
**\<suraeNoether>** wait that's winking
**\<suraeNoether>** i meant :\*(
**\<suraeNoether>** semicolons are so hard to use correctly
**\<rehrar>** we'll get you a tshirt, but it may not be what you expect
**\<rehrar>** ;P
**\<rehrar>** anyways, nothing else regarding defcon as far as I know
**\<suraeNoether>** okay, so, in terms of other conferences, we originally had this idea to have the first Monero conference in Denver next spring, perhaps funded or hosted by the MAGIC non-profit (me, rehrar, sgp, and sarang and some non-monero-related people)
**\<suraeNoether>** but we are trying to keep MAGIC more or less separate from Monero, (we are looking for some non-monero members to be on the board) becuase it's an educational organization, not a project-oriented one
**\<suraeNoether>** so we are going to host the MAGIC conference as a general privacy enhancing technology conference instead
**\<suraeNoether>** and all funding for that will be through MAGIC, we won't be starting an FFS for that
**\<suraeNoether>** totally independent
**\<suraeNoether>** BUT
**\<suraeNoether>** the monero community deserves a freaking technical conference!
**\<suraeNoether>** so i wanted to get the community's thoughts on starting a Monero conference-specific FFS. If I took charge of this, I would hire an event organizer to take care of a lot of it and spend time trying to get speakers for the conference.
**\<silur>** FFS?
**\<suraeNoether>** forum funding system
**\<silur>** oooh
**\<endogenic>** cool, go for it
**\<silur>** great
**\<silur>** really sorry I gotta run
**\<silur>** best to y'all
**\<suraeNoether>** ta silur
**\<suraeNoether>** okay, the way i figure it, the monero conference is a good use of MRL resources and time, so I'll post it under ideas with the current estimated price tag and we'll see what happens from there. i think anything over-funded should go to the general fund
**\<suraeNoether>** well, we're rounding up on the hour here
**\<suraeNoether>** does anyone have any questions?
**\<suraeNoether>** maybe about the proceedings at MRL, what's going on recently and what's going to be going on over the next few weeks, any other general questions?
**\<suraeNoether>** (my favorite color is blue and i'm probably a taurus and i like long walks on the beach)
**\<rehrar>** hmmm...
**\<rehrar>** I think I'm a gemini, would we work well together?
**\<rehrar>** Or am I a something else?
**\<dEBRUYNE>** ArticMine: Sounds interesting. Looking forward to the details of your fee proposal
**\<nioc\_>** a question earlier from the lounge >> \<lenovuh> some while ago, was there a discussion about letting new nodes bootstrap the blockchain quickly, that required new crypto techniques, afaik? i might have this completely wrong, but think i read about it in the research-lab channel
**\<m2049r[m]>** if the meeting is over i would like to get back to the topic of exposing the index of a subaddress - from what i understood there are mixed statements about this. it may be a problem and it may not be. ??!?
**\<suraeNoether>** nioc\_: not sure about htat
**\<suraeNoether>** yeah, we can call this meeting over :D
**\<suraeNoether>** thanks everyone \</meeting>

135
_posts/2018-06-25-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-06-25.md Normal file
View file

@ -0,0 +1,135 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-06-25
summary: MRL work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<suraeNoether>** let's get this partay starteeeeed
**\<suraeNoether>** Agenda today: 1. Greetings. 2. Brief MRL update. 3. Show and tell! 4. Who's going to defcon?
**\<suraeNoether>** hi everyone
**\<oneiric\_>** hullo
**\<suraeNoether>** Okay, 2. I have finally posted all our meetings logs here: https://github.com/b-g-goodell/research-lab/tree/master/meta/research-meeting-logs
**\<suraeNoether>** I didn't want to fork the whole meta repo just to keep track of our research meeting logs, so I just started a folder
**\<isthmuscrypto>** Greetings!
**\<suraeNoether>** if anyone objects or wants to make PRs to monero-project's meta repo to track our logs, I'm fine with that, too, but this is easiest for me to deal with.
**\<needmoney90>** Morning all
**\<sgp\_[m]>** Hello
**\<suraeNoether>** morning isthmuscrypto and needmoney90
**\<suraeNoether>** Another update, Sarang will be back next week I believe
**\<suraeNoether>** Other than that, Sarang and I will be at defcon, and we are excited to meet up with folks
**\<sgp\_[m]>** They're more accessible if they are posted as a blog post on getmonero. Probably some value there
**\<suraeNoether>** sgp\_[m]: would I make a PR to the monero-site repo then?
**\<binaryFate>** hello
**\<sgp\_[m]>** There are some open PRs now for the community meetings. Best to use those as a template
**\<suraeNoether>** so the answer is yes, and to use those as a template? I haven't done any blog posts through the repo before, so I'm not sure exactly what the procedure is. :P
**\<selsta>** they require markdown change
**\<suraeNoether>** I'll look around and take care of it later today
**\<sgp\_[m]>** Basically yes. It's not very difficult
**\<suraeNoether>** cool, then easy thing to check off my list later
**\<suraeNoether>** So, 3. Show and tell. Silur is here, isthmuscrypto is here, and both of them are working on rather interesting projects I'd like to hear about.
**\<silur>** I'm struggling with testing my RTRS lib, and now got into VDFs, verifiable delay functions and trying to generalize them for lattices
**\<suraeNoether>** i didn't catch isthmuscrypto's original description of his generalized adversarial networks, when he mentioned it for the first time a few weeks ago
**\<silur>** and of course as usual lattices are more interesting than testing but I need to have RTRS done for HCPP :/
**\<suraeNoether>** oooh VDFs are super super interesting to me
**\<isthmuscrypto>** Hi @suraeNoether https://github.com/Mitchellpkt/BlockchainAnalysisGAN
**\<silur>** I have a general VRF construction for DH and EC, PoC ready (I can share the notebook) and a blockchain is already adapting it, working on the lattice VRF now
**\<isthmuscrypto>** I'm tied up in a meeting for the next 50 minutes and sneaking the MRL meeting on the side, so I'll be intermittent in responding.
**\<suraeNoether>** ah silur, that's a conference I would have loved to attend if I had heard of it a few months earlier.
**\<silur>** so my next step is to make the same for VDFs
**\<suraeNoether>** that's awesome, silur!
**\<silur>** I'm sure we can figure something out
**\<silur>** about HCPP
**\<suraeNoether>** oh, no, i literally can't attend, but maybe next year.
**\<suraeNoether>** oh that brings up something: I was thinking maybe we could start taking issues out on the monero-project/research-lab repo for conferences that the community might want us to attend
**\<suraeNoether>** a lot of them I'm willing to go to out of pocket because they are great experiences, but keeping track of the wide world of conference calendars can be challenging
**\<isthmuscrypto>** " track of the wide world of conference calendars can be challenging" < sounds like we need a decentralized solution xD
**\<silur>** MARKET GAP! :D
**\<suraeNoether>** tokenize it!
**\<silur>** ICO it
**\<oneiric\_>** lol
**\<rehrar>** hi
**\<suraeNoether>** is it unreasonable to ask: if folks hear about a technical conference, literally anywhere in the world, at which MRL should have a presence, open up an issue about it on the monero-project/research-lab repo?
**\<suraeNoether>** hi rehrar
**\<silur>** so brings me back to a interesting bottleneck I can't overcome for weeks for all my current work
**\<silur>** VDF, IVC, VRF, Bulletproofs....
**\<silur>** ACs
**\<silur>** I don't have any experience for arithmetization of boolean circuits
**\<silur>** anyone willing to help out on that?
**\<silur>** maybe not a meeting subject, let's go on with the agenda and get back on it later :D
**\<suraeNoether>** well funny thing about that silur
**\<suraeNoether>** boolean circuits are arithmetic circuits already, just not contrariwise
**\<suraeNoether>** which is one of my favorite -wise suffixed words
**\<silur>** well in Gf(2)
**\<silur>** but most protocols need a galois field with a large prime base so I thought bulletproofs won't work ever on Gf(2)
**\<suraeNoether>** ah that's what you meant
**\<silur>** anyway I'm stuck now with QSP-s and a little less-efficient snark stuff to experiment with BPs
**\<suraeNoether>** well, we'll chat about it later
**\<silur>** yea sorry for holdin' the meeting :D
**\<suraeNoether>** does anyone else have any interesting work they want to talk about? My work this past week has been into zero knowledge proofs and extractability requirements and schnorr signatures. primary reference of the week is this one (pdf link https://link.springer.com/content/pdf/10.1007/3-540-48071-4\_28.pdf)
**\<suraeNoether>** primarily, I'm thinking it's possible we don't need to worry about the KOSK setting with only minor adjustments to our current scheme, and if that's the case, all the musig key computation and all the commit-and-reveal nonsense just goes away
**\<suraeNoether>** in which case the whole paper will \*AGAIN\* collapse to something smaller
**\<suraeNoether>** but I need some sanity checks from folks with more knowledge in the field of complexity theory
**\<suraeNoether>** Other than that, I recently finished advising the ZCash Foundation in giving out 250kUSD in grants, I'm working on encrypted memo fields in Monero transactions, and I've been writing up my backlog statements of work. I've already broken 160 hours this month, but I like this job a whole lot so I'm not really taking weekends until I start feeling burnt out.
**\<silur>** usual cryptographer's calendar :D
**\<suraeNoether>** oh, earlier this week I made some commits to my PoissonGraph simulations (see here https://github.com/b-g-goodell/research-lab/tree/simple/source-code/Poisson-Graphs/new) which are \*inches\* away from successfully producing human-readable transcripts describing cryptocurrency network simulations.
**\<suraeNoether>** The sim suite is for testing difficulty algorithms, consensus algorithms, and dynamical properties of the network.
**\<suraeNoether>** a friend who just got a job at the university of Exeter (inspiration for Hogwarts) is interested in writing a population ecology-inspired paper demonstrating how ethereum can effectively prey upon bitcoin's hashrate by rewarding bitcoin block-withholding attacks using ethereum smart contracts.
**\<silur>** wow this is awesome
**\<isthmuscrypto>** o\_0
**\<suraeNoether>** https://arxiv.org/abs/1805.08832
**\<suraeNoether>** this paper is sort of the foundation of that idea
**\<suraeNoether>** well
**\<suraeNoether>** one part of the foundation
**\<oneiric\_>** +1000 on the sim network research suraeNoether!
**\<silur>** oh yea I saw a paper based on this .... "vulnerability"?
**\<silur>** https://eprint.iacr.org/2018/581
**\<suraeNoether>** yes, exactly
**\<suraeNoether>** that's another part of the foundation, but i haven't been able to find the reference recently, thank you
**\<suraeNoether>** i forgot that was mccrory
**\<suraeNoether>** also a nice guy
**\<suraeNoether>** hmm, published june 6
**\<suraeNoether>** i must have seen him talk about this
**\<suraeNoether>** Allright, next meeting agenda point: who's going to defcon?
**\<rehrar>** I am
**\<rehrar>** and all of you should also
**\<suraeNoether>** yay, i think most of the board of directors of MAGIC will be there, if not all of us
**\<suraeNoether>** we should all go out for a dinner
**\<silur>** but... it's in the... USA :'(
**\<suraeNoether>** ugh, no kidding
**\<rehrar>** 'murica
**\<suraeNoether>** who wants to start a sea-cooled, solar-powered mining farm with me on the pacific coast of Costa Rica?
**\<oneiric\_>** yes please
**\<oneiric\_>** :)
**\<suraeNoether>** who wants to fund it?
**\<oneiric\_>** Elon Musk
**\<suraeNoether>** good ole' elon
**\<suraeNoether>** okay
**\<silur>** i'm still thinking about defcon, also I have another blockchain security conf in vegas in october that I'm invited as a speaker but still couldn't get my head over getting into US
**\<silur>** last year I think 2 ppl got arrested at defcon?
**\<silur>** the wannacry and the election machine guy
**\<sgp\_[m]>** ooh what conference?
**\<rehrar>** just surround them so po po can't get to them
**\<rehrar>** civil disobedience of whatever
**\<suraeNoether>** if you are invited as a speaker, the conference should be able to write you a letter requesting a temporary visa for your visit, but i'm not sure if hungary is on the list of countries that need temporary visas even for a conference visit. i would assume so, because we have shut our borders to friggin canada
**\<silur>** it's more complicated than that, I'm stateless
**\<suraeNoether>** !
**\<suraeNoether>** good freaking luck
**\<silur>** https://www.hoshocon.com/
**\<rehrar>** does being stateless suck?
**\<rehrar>** it sucks that you wouldn't be able to get into USA :/
**\<suraeNoether>** being stateless is a desirable state for a hash-based signature scheme.
**\<rehrar>** they should see about holding Defcon in Canada
**\<sgp\_[m]>** Ugh Tues-Thurs
**\<suraeNoether>** should we hold the monero conference in another country?
**\<silur>** HCPP last year had a "secret" monero meeting, I met a dev guy there
**\<silur>** he was giving away SO MANY stickers
**\<silur>** so I guess HCPP is ideal :P
**\<suraeNoether>** Okay, so anyway
**\<suraeNoether>** :D
**\<oneiric\_>** hold monero conf in Liberland: http://www.liberland.org/
**\<suraeNoether>** Let's call this meeting what it is: done
**\<suraeNoether>** \</meeting>

201
_posts/2018-07-02-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-07-02.md Normal file
View file

@ -0,0 +1,201 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-07-02
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / sarang
---
# Logs
**\<sarang>** First, greetings
**\<needmoney90>** Yawns\*
**\<sarang>** well, greetings
**\<needmoney90>** Hopefully a little more people than the Dev meeting, but prolly not, because of the holidays
**\<sarang>** For my sake at least, I'm very interested in the current state of folks' projects or undertakings
**\<needmoney90>** Does Merkato count?
**\<serhack>** Hi :)
**\<serhack>** Does Mastering Monero count?
**\<sarang>** fo sho
**\<needmoney90>** Currently one of the next steps for Merkato is calculating the optimal spread, which is some fun math that scares me
**\<sarang>** elaborate?
**\<sneurlax>** Hi all, small update and that's it, I quit my job so I'm resuming work on my small project related to scraping mining pools. I apologize it took so long, but my job got incredibly demanding incredibly quickly... So I quit!
**\<luigi1111w>** that's what I do when the going gets tough
**\<needmoney90>** https://arxiv.org/pdf/1606.07381.pdf
**\<needmoney90>** Starts on describing the optimal spread Calc
**\<needmoney90>** I need to dive into it
**\<sarang>** interesting!
**\<sarang>** I finished up my teaching and also worked with the auditors more
**\<sarang>** QL and Kudelski are finishing up reports
**\<sarang>** There was, of course, also the twitteresearcher
**\<hyc>** all hail twitter
**\<sarang>** His notes about subgroup checking were also identified by our audit
**\<sarang>** and will be incorporated into some easy checks on the code
**\<silur>** as far for me on RTRS-StringCT I didn't have any advance on testing for the last 2 weeks :(
**\<silur>** neither on Lattice-based bulletproofs
**\<sarang>** suraeNoether sent me more details on sublinear ring sigs but that was just yesterday
**\<sarang>** I'm sure he will have more to say on this
**\<serhack>** I just need a technical feedback because I am not sure I wrote anything correctly in Mastering Monero. You can read by viewing this pdf https://masteringmonero.com/book/preview.pdf . Thanks! :) Feel free to message me for any inputs!
**\<silur>** yea that's why RTRS is on hold now, the scheme changed a lot since I started implementing
**\<sarang>** yes indeedy
**\<suraeNoether>** eek, time got away from me. sorry about that everyone! i'm here, i swear, i'm writing a document on blockdags and got excited :(
**\<sarang>** The incorporation of an internal range proof is intriguing
**\<sarang>** suraeNoether: what about blockdags?
**\<sarang>** go on
**\<suraeNoether>** oh, i think i have a "fast" version of a blockdag based approach to transactions sort of similar to spectre
**\<suraeNoether>** i'm looking at convergence rates and such
**\<sarang>** Ah, new work?
**\<suraeNoether>** yeah. going into details, the problem with blockdag schemes is ordering blocks that aren't linked to each other (so-called "antichains")
**\<sarang>** correct
**\<sarang>** that's the hangup in computation
**\<suraeNoether>** and i think I realized a structure built into the blockdag approach that allows for a rather fast linear ordering of otherwise unordered blocks
**\<sarang>** that would be hugely useful!
**\<suraeNoether>** in the end, if all these different metrics end up being equal, you end up hashing block headers either way, so the probability of two blocks having the same place in the line is negligible either way, and it should be quick
**\<sarang>** What other projects have kept you busy during my absence suraeNoether ?
**\<suraeNoether>** oh gosh, i made commits to my PoissonGraphs project, which allegedly spits out a human-readable cryptocurrency network simulation's transcript... and i've been communicating with tim ruffing about his new sublinear ring signature scheme...and I've been trying to get a handle on the multisig KOSK setting and UkoeHB's rewind/replay problem.
**\<sarang>** excellent
**\<sarang>** Anyone else with news or updates? I have a month of "lack of knowledge" to account for!
**\<silur>** @suraeNoether pls relay any info on RTRS from ruffiing if available!
**\<suraeNoether>** i believe we've spoken about the twitterstorm "problems with bulletproofs and ed25519" thing?
**\<sarang>** yes
**\<sarang>** Here's the lowdown
**\<sarang>** I thought we were performing key checks at a lower level already, but I was mistaken
**\<sarang>** After speaking with the auditors (who also noticed this), they recommended adding some checks
**\<sarang>** for subgroup membership and point-at-infinity
**\<sarang>** as well as checking for null scalars
**\<sarang>** However
**\<sarang>** They, like us, were unable to identify any way that the absence of such checks could be exploited
**\<sarang>** But this is precisely why we audit
**\<suraeNoether>** long story short: the bulletproof method uses a group of prime order. we use a group of composite order, and while we restrict all our keys to the prime order subgroup, we didn't have checks to guarantee that someone wasn't feeding non-subgroup elements into the bulletproof as inputs
**\<sarang>** So, once we deploy bulletproofs, we can get to RTRS and make bulletproofs obsolete =p
**\<sarang>** basically, yes
**\<sarang>** it's an easy and fairly cheap thing to check
**\<suraeNoether>** this leaves open the logical possibility that someone coudl produce a bulletproof that passes the verification algorithm correctly, but does not present a valid proof of the range of the argument. as sarang said, \*there is no way we have yet identified to do this.\* but \*it's a logical possibility\* and we deal in the realm of provable security in this here lab
**\<sarang>** On a more irritating note, Benedikt indicated on twitter that he had not yet begun his review, which was not indicated in his communications to me, and I've been unable to reach him for details
**\<suraeNoether>** sarang: the new RTRS scheme with bulletproofs is faster than the scheme with their "included" range proofs
**\<suraeNoether>** ...
**\<sarang>** suraeNoether: ok, haven't looked into newRTRS at all
**\<silur>** which new? :D
**\<moneromooo>** By RTRS, you mean the new paper by Ruffing et al ?
**\<silur>** there's like new-new-new-RTRS :D
**\<sarang>** lol, the internal paper suraeNoether showed me
**\<suraeNoether>** let's say RTRS2
**\<suraeNoether>** it's actually... one sec
**\<sarang>** the paper was marked to be for internal review only
**\<suraeNoether>** LRRSTW signatures now. :D
**\<sarang>** omg no more
**\<suraeNoether>** different authors than RTRS
**\<ArticMine>** What are the implications if any for verification cost vs 1) number of outputs, 2) number of rings?
**\<suraeNoether>** ArticMine: number of rings = ring members?
**\<sarang>** TBD
**\<silur>** LRRSTW is even new for me
**\<sarang>** they have some data
**\<ArticMine>** yes
**\<suraeNoether>** ArticMine: eyeballing their results, it looks like we can have 2.4kb, ring-sized 64 signatures that take as much time to verify as (approximately) one of our current ring signatures with ring size 16...
**\<suraeNoether>** BUT
**\<suraeNoether>** it's POSSIBLE that the verification time there needs to double
**\<suraeNoether>** in which case we could go for 2.0kb, ring sized 32 signatures that take as much time to verify as one of our MLSAGs at ring size 8-10
**\<sarang>** My view is that once we prototype it, we'll get a better sense of the op counts
**\<suraeNoether>** note: these are actually really huge signatures
**\<sarang>** and that will tell us verification times
**\<sarang>** suraeNoether: agree?
**\<suraeNoether>** sarang: sure, although there is a table of op counts in the back
**\<ArticMine>** Is there a scaling issue when compared to tx size with increasing the number of ring members?
**\<suraeNoether>** we can literally compute whether it's worth it to even prototype it
**\<suraeNoether>** (and i'm doing that calculation this afternoon)
**\<suraeNoether>** ArticMine: yes, these signatures are sublinear, are almost as fast as our current signatures... but their size constants are bigger than ours, and the sublinearity doesn't become worth it in terms of size until 10-12 ring members
**\<ArticMine>** Subliner with tx size?
**\<suraeNoether>** oh i thought you meant by ring member, excuse me
**\<suraeNoether>** i'm not sure what you mean, then. signature size is related to both the number of inputs and outputs.
**\<sarang>** Whats the level of incompatibility with what we're doing now?
**\<iDunk>** 1 sig for all inputs (and outputs), IIRC from yesterday.
**\<suraeNoether>** unsure yet, i'm optimistic that it doesn't requrie, for example, more group elements in the public key or antyhing like that
**\<ArticMine>** My question relates to a possible attack by increasing the number of ring members where we are only measuring tx size
**\<suraeNoether>** oh, if we made a decision like moving to these signatures, i would strongly recommend a fixed ring size, if that helps your thought process on the matter
**\<sarang>** What would it take to allow \_either\_ signature type, depending on size, if the size were not fixed?
**\<suraeNoether>** considering this as an option boils down to considering whether or not we are willing to commit to having large, slowish, but rather efficient (with respect to privacy) sigs
**\<sarang>** just as a thought experiment
**\<suraeNoether>** no idea
**\<sarang>** OK
**\<ArticMine>** Yes that would simplify the issue; however we could also add a weight parameter to increasing the number of ring members
**\<sarang>** I'll be interested to actually look into this
**\<sarang>** Moving forward for this month, what's everyone's priorities?
**\<suraeNoether>** (i think in general keeping around multiple signature schemes is bad business)
**\<sarang>** Mine are to finalize BPs and then move on to RTRS, while finishing up a few other writeups
**\<silur>** @sarang it shouldn't take much effort in my opinion
**\<sarang>** suraeNoether: sure, just a thought experiment
**\<silur>** to support both
**\<suraeNoether>** every time i need something to do for an afternoon, i look at the MRL roadmap
**\<sarang>** I mean a bit longer-term
**\<sarang>** to help long-range planning
**\<sarang>** and help us complete things
**\<silur>** as long as the implementation keeps it's orthogonal design it can be an opt-in
**\<sarang>** it's easy to get sidetracked with fun new projects
**\<silur>** temptation of math!
**\<suraeNoether>** other than my weird blockdag approach, which i'll be sharing with sarang eventually, and my poissongraphs simulations, and multisig + kosk setting stuff... actually, i'm pretty full up. :P
**\<sarang>** Nice!
**\<suraeNoether>** and i'll talk about the blockdag stuff after the meeting in some more detail
**\<sarang>** Yeah I'm interested
**\<sarang>** dags are at the top of my "I wish I had more time to do this" list
**\<suraeNoether>** it's not clever, which is my strongest argument in its favor
**\<sarang>** being not clever often means "easier to prove"
**\<suraeNoether>** yep, and more secure, and lots of other things
**\<sarang>** suraeNoether: what do you intend to do with RTRS2 this month?
**\<sarang>** If the op counts they provide make sense, I'd be interested in prototyping to help my understanding better
**\<suraeNoether>** step 1: understand how it works
**\<sarang>** ^
**\<suraeNoether>** step 2: if it's like RTRS1, step 2 is "abandon the project."
**\<silur>** T\_T
**\<silur>** RIP silur :D
**\<sarang>** lolol
**\<suraeNoether>** i regret to inform yall but i'm guessing 1) this scheme is as good as it gets without pairings based crypto or a weird RLWE scheme or something, and 2) i still think it's too slow for a mandatory every-transaction sort of deployment and 3) i don't think it's worth deploying without the always-on protection of 64-member rings. maybe. i don't know.
**\<silur>** we talked about an RLWE-generalization months ago
**\<silur>** so more likely ruffing found that too
**\<sarang>** Well, we can use this month to find out
**\<suraeNoether>** i think the variability in ring sizes is... well, it's not the biggest vulnerability, right, but it's a vulnerability and it's super low-hanging fruit: we should be mandating ring sizes to avoid inter-signature linking
**\<suraeNoether>** i love my cat, and you should love my cat too. i got nothing else to contribute to this meeting except CAT LOVE.
**\<sarang>** My cat is sitting on my lap with his paw on the keyboard
**\<sarang>** ready to jump in should he become necessary here
**\<sarang>** hyc: any developments on asic resistance?
**\<sarang>** I have not been following that stuff this past month
**\<sarang>** (or anyone else involved in this)
**\<sarang>** (please chime in)
**\<silur>** my last info on that is that cuckoo-cycle doesn't work for some reason
**\<silur>** last time I got into that, it was the best known stuff
**\<silur>** \*sad\*
**\<suraeNoether>** silur hyc has been working on a proof of random code project
**\<silur>** VRF? \*-\*
**\<hyc>** sorry was on another call
**\<suraeNoether>** i suppose one could imagine it as a VRF. some random code is generated from a nonce, excecuted, the final state is hashed, and that's the nonce for the proof of work game. puts the burden not on hashing the final output for PoW, but in executing random code
**\<hyc>** silur you can catch up here https://www.reddit.com/r/Monero/comments/8bshrx/what\_we\_need\_to\_know\_about\_proof\_of\_work\_pow/
**\<suraeNoether>** hyc its ok we still love you
**\<hyc>** my prototype is here github.com/hyc/randprog but already superseded by tevador's
**\<hyc>** https://github.com/tevador/RandomJS
**\<silur>** thanx hyc
**\<hyc>** cuckoo-cycle breaks down because of some memory/time tradeoff
**\<suraeNoether>** hyc when did tevador start working on that? haha
**\<hyc>** e.g. double memory gives superlinear time acceleration
**\<silur>** oh
**\<hyc>** suraeNoether: shortly after I published PoC ;)
**\<silur>** what about a VRF or rather VDF-based approach?
**\<hyc>** VDF ? what are these acronyms
**\<silur>** verifiable random/delay function
**\<hyc>** I don't know of any good examples.
**\<silur>** I have a DH and EC demo on VRF in a jupyter notebook I can upload it into the lab
**\<silur>** repo
**\<hyc>** cool
**\<hyc>** Also, Wolf's colleagues have another variation on my idea, but tuned to GPUs
**\<silur>** but it kind of sidetracks a lot from "asic-resistant pows" since it's not a pow
**\<hyc>** https://github.com/ifdefelse/ProgPOW
**\<hyc>** we had a good couple days' worth of email conversations leading into that one
**\<hyc>** I'm disinclined to adopt it because I think it leaves CPUs out, and ignores the prevalence of smartphones in the userbase these days
**\<sarang>** In the interest of time, are there any other updates before we officially close and continue discussion of these topics?
**\<sarang>** I'll be giving a presentation in Portland in a couple of weeks on the importance of fungibility, so hopefully some good PR from that
**\<hyc>** nice
**\<sarang>** The usual disclosure that my travel/hotel are covered, so I'm not requesting any community funding for this
**\<sarang>** I'll be glad to share the presentation here for comments
**\<sarang>** OK, looks like the official topics list is exhausted, so I suppose we can officially adjourn and continue talking here
**\<sarang>** keep up the good fight
**\<suraeNoether>** <3 cool
**\<sarang>** I'd be glad to hear more from hyc or suraeNoether about PoW and/or fun DAG stuff
**\<suraeNoether>** \</meeting>

145
_posts/2018-07-09-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-07-09.md Normal file
View file

@ -0,0 +1,145 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-07-09
summary: MRL work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / sarang
---
# Logs
**\<knaccc>** hey
**\<sarang>** Our pal suraeNoether is unavailable today, so this inmate will be running the asylum today
**\<sarang>** Let's go around the room and mention any present or ongoing work of interest to the group
**\<sarang>** In the spirit of fairness, I'll go first
**\<rrol[m]>** hi
**\<sarang>** Waiting on reports from our reviewers, all of which are finalizing with a few delays due to last-minute checks
**\<sarang>** (on BPs, that is)
**\<sarang>** There was a delightful twitteresearcher who pointed out lack of small-subgroup checking
**\<sarang>** Reviewers also noted this, but were unable to identify an exploit
**\<ArticMine>** hi
**\<sarang>** Regardless, this is now included in the code
**\<hyc>** reviewers clearly lack imagination of twitterati
**\<sarang>** As always, we welcome external research but appreciate responsible disclosure (the lack of which makes a researcher ineligible for hackerone moneyz)
**\<sarang>** Relating to the audit, there was some work on other aspects of the BP code, like generator specifications, fixes to multiexp, etc
**\<sarang>** I posted some code and other materials to my research-lab repo, including notes from my summer course
**\<sarang>** I'll be giving a talk in Portland on fungible digital assets, and another at defcon
**\<sarang>** I got a recent email from someone with an idea for including a transaction-specific subaddress within transactions, which could be used for (among other things) refunds
**\<sarang>** or returns for misdirected funds to exchanges
**\<sarang>** Finally, I've been working through additional sublinear ring sig material and some math on non-power-of-2 bulletproofs (a future thing)
**\<hyc>** why NPO2?
**\<sgp\_[m]>** Hello everyone. Sorry I'm late
**\<knaccc>** does that subaddress email come with the condition of restricted circulation?
**\<sarang>** hyc: NPO2 gives better verification efficiency, which is relevant for any later work involving larger circuits
**\<hyc>** ah cool
**\<sarang>** knaccc: I can share the info if desired
**\<sarang>** just need to check if the researcher wants their name released
**\<knaccc>** yes a fedorapaste or something, with name redacted, would be interesting for discussion
**\<sarang>** Yeah, he's been emailing me just before the meeting. When I hear back I'll make a paste of the info
**\<sarang>** Anyway, that's my work this week
**\<sarang>** Move on to others, or questions on my stuff?
**\<hyc>** sounds good
**\<sarang>** I know suraeNoether has been working on nonprofit stuff and also recently on some churn analysis. We really need information on output depth, which a few folks said they were interested in coding
**\<moneromooo>** What is output depth ?
**\<sarang>** Oh, link to my repo with that material: https://github.com/SarangNoether/research-lab
**\<sarang>** The distribution of coinbase outputs tracked back through the spend tree of a transaction
**\<sarang>** It's useful as parameters for churn analysis
**\<moneromooo>** Is this something that's been pending for a while ?
**\<moneromooo>** Kinda rings a bell...
**\<sarang>** yup
**\<moneromooo>** If it's a few folks that siad they would, then flaked out, I can do it. If it's a few folk that recently said so and are doing it, I won't.
**\<sarang>** Not sure if flaked, or busy, or what
**\<sarang>** I have little experience in lmdb, or I'd jump on it
**\<sarang>** clearly moneromooo sits around all day doing... very little =p
**\<moneromooo>** Well, remind me whenever you feel like you waited enough :)
**\<sarang>** lol ok
**\<sarang>** I can give more details after meeting
**\<sarang>** ty
**\<hyc>** if you want to poke and prod at the blockchain before writing actual code, I suggest the CLI in py-lmdb
**\<sarang>** hyc: I thought our implementation was non compatible?
**\<hyc>** eh? you point the python module at out liblmdb, no problem
**\<hyc>** at our
**\<sarang>** Ah ok, I had tried a while back to no avail, and had read that we were using too new a version or something
**\<hyc>** py-lmdb itself works great
**\<hyc>** with any recent version of liblmdb
**\<sarang>** great
**\<sarang>** I'll revisit it then
**\<sarang>** Who else wishes to share anything of group interest?
**\<hyc>** on the subject of LMDB, I've been doing a bunch of benchmarking on $secret $systems lately
**\<sarang>** orly
**\<hyc>** point of interest - common filesystems today are all journaling filesystems - they log FS ops before they perform them
**\<hyc>** to give them crash resilience. With LMDB such logging is superfluous. turns out you can creatae Linux ext4 filesystems without journals
**\<hyc>** which gives a nice performance boost
**\<hyc>** also, I've got a patch that lets LMDB use a raw device directly, without any filesystem at all
**\<hyc>** on a bulk load test (loading records sequentially, as fast as possible) this is 2x faster than ext4 with no journal
**\<sarang>** oh wow
**\<hyc>** it turns out you spend a lot of time just growing the file, on a filesystem
**\<hyc>** that's what I can share at the moment. actual results/numbers are under NDA
**\<ArticMine>** So LMDB on a dedicated GNU / Linux partition
**\<hyc>** yes
**\<spaced0ut\_>** very cool
**\<knaccc>** is there a way to ask an commonly used filesystems to just allow raw access to some regions?
**\<ArticMine>** With way faster sync for Monero
**\<knaccc>** any\*
**\<sarang>** Throwback time... here's the email regarding subaddys: https://paste.fedoraproject.org/paste/KTgF84V-pHPL-dO8V8mAjw
**\<hyc>** knaccc: unfortunately not
**\<knaccc>** doh
**\<hyc>** you create a filesystem, it owns all that space
**\<sarang>** Researcher asked to be identified as "that Russian dude"
**\<hyc>** won't give it to you :P
**\<knaccc>** haha
**\<moneromooo>** BTW, iDunk reported much faster sync on HDD with some particular options.
**\<scoobybejesus>** i think it was sneurlax who was writing up spend tree code in python
**\<moneromooo>** Just needs... a lot of data points. To fix a new default.
**\<rrol[m]>** re: churn, i have been planning to put together a 'best practices' infographic that collects some of surae's findings, as well as other usage guidelines, but work keeps eating my headspace. if ppl want to help maybe reach out and we can coordinate together
**\<sarang>** scoobybejesus: righto, didn't see any final product, unless there is and I don't know about it
**\<sarang>** rrol[m]: that'll be great; just waiting on some final numbers
**\<oneiric\_>** is there a way to setup a partition without root? then on make install, partition sets up automatically?
**\<hyc>** oneiric\_: I think it always requires root access
**\<sneurlax>** soon™ -- do you want the mining pool traceability analysis first or the generalized spend tree code first?
**\<oneiric\_>** damn, very cool work hyc
**\<moneromooo>** Kinda loses the point of a fs, which is to allow files to live in parallel. So you have to preallocate loads of space to your raw partition.
**\<hyc>** thanks. I guess mostly theoretical for now, impractical for most people to deploy
**\<sgp\_[m]>** rrol sarang: I also want to see what's known about churning for my Defcon talk
**\<sarang>** sneurlax: getting the distribution of output depths (back to coinbase) for a given txn sample will be the most relevant right now
**\<sarang>** sgp\_[m]: righto
**\<hyc>** oh, and like sarang, I'll be giving a talk at defcon. unlike sarang's.
**\<ArticMine>** I am not so sure this is impractical to deploy
**\<spaced0ut\_>** i think thats really exciting you're giving a talk about fungibility at defcon. from what i've seen, people change their mind on that topic fairly easily once presented with some evidence
**\<spaced0ut\_>** "people" == people that think btc is fungible
**\<sarang>** Yeah, I think it'll be really relevant at the Portland event too, which is attended by a very nontechnical audience
**\<sarang>** I'm shifting my language from private to fungible more and more
**\<hyc>** ^good
**\<oneiric\_>** less overtones/baggage?
**\<sarang>** Telling people how much it would suck if your salary wasn't exchangeable because of some ransomware crap you had nothing to do with
**\<sarang>** oneiric\_: easier to explain why people should care
**\<ArticMine>** My favorite paying for a meal with two $20 bills
**\<ArticMine>** In the US
**\<knaccc>** fungibility requires a weaker form of untraceability than privacy though
**\<sarang>** sure
**\<spaced0ut\_>** knaccc, in cryptocurrency though?
**\<sarang>** and I still talk about privacy too
**\<knaccc>** so as long as it's not an admission of defeat :)
**\<hyc>** knaccc: weaker, how so?
**\<sarang>** I assume knaccc means breaking links between outputs
**\<sarang>** not necessarily identities of use
**\<hyc>** I use physical coinsas my example, since they have no serial numbers (as opposed to paper bills)
**\<knaccc>** privacy can be exposed after the fact
**\<spaced0ut\_>** weaker is fine for something like cash imo. there are serial numbers so it may only be 99.9999% fungible. with cryptocurrency its either private or extremely public
**\<knaccc>** fungibility counts in the moment more
**\<spaced0ut\_>** very good point
**\<ArticMine>** In many countries fiat is fungible by law
**\<sarang>** A fun topic, but to keep us on track...
**\<sarang>** Are there other research topics on anyone's plate?
**\<sarang>** (I'd love to continue talking fungibility afterward)
**\<unknownids>** ArticMine, as in no serial numbers on bills?
**\<knaccc>** I was interested to know if anyone thought that a 38% reduction in wallet output scanning time was significant enough to justify altering the one-time output public key construction. UkoeHB and vtnerd had some interesting comments which I've incorporated into this: https://paste.fedoraproject.org/paste/h069cKbPYUC3ixgVJIPVYw/raw This is very low priority of course
**\<sarang>** I need to think more about changes to any security properties by removing the hash and replacing with a sum in this way
**\<knaccc>** yes, I'm sure it would need a thorough security analysis. That's why I was wondering specifically if people thought 38% was enough to bother looking into it
**\<moneromooo>** To decide whether it's worth it, you'd need to give actual speedup, not speedup for a particular step.
**\<smooth>** /win/win1
**\<knaccc>** moneromooo true, I'm sure there are other factors that I'm not taking into account
**\<sarang>** Seems the topics are winding down a bit, but interesting on all counts
**\<sarang>** Well, thanks to all for attending today, and let's continue the discussions now that the meeting is formally concluded!
**\<knaccc>** ^^
**\<oneiric\_>** thanks everybody :)

205
_posts/2018-07-16-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-07-16.md Normal file
View file

@ -0,0 +1,205 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-07-16
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / sarang
---
# Logs
**\<sarang>** Welcome to everyone; greetings
**\<suraeNoether>** hi
**\<sarang>** Let us go with brief updates
**\<sarang>** The initial draft report from Kudelski has arrived, with generally positive results
**\<sarang>** A few small things to address
**\<sarang>** I am working on some prototyping code for a sublinear RingCT proposal that's progressing very nicely
**\<sarang>** I delivered a talk on fungibility in Portland (in the airport right now about to depart)
**\<sarang>** Other reports?
**\<suraeNoether>** I wrote a thing... it was sort of a whim
**\<suraeNoether>** endogenic and I started talking about comparing addresses when sending a transaction
**\<suraeNoether>** humans tend to only check the first five or sex and last five or six characters in an address
**\<suraeNoether>** there are graphical representations of random data so people can visually compare them
**\<suraeNoether>** one way to do this is using seashells, since they are easily parameterizable
**\<sarang>** (e.g. randomart)
**\<suraeNoether>** https://github.com/b-g-goodell/research-lab/tree/master/source-code/iseeseashells
**\<sarang>** nice
**\<suraeNoether>** so i wrote a thing that takes an address, hashes it, breaks the hash into 4-byte pieces
**\<suraeNoether>** uses each of those pieces to define a parameter of a seashell
**\<suraeNoether>** and then plot it
**\<suraeNoether>** so if we could get something going client-side with each transaction, with a javascript renderer, it would work like this
**\<suraeNoether>** i want to send xmr to a bitcoin address using xmr.to
**\<suraeNoether>** i fire up my xmr wallet and copy-paste my xmr.to address into it, and a seashell appears. i compare it to the seashell on the xmr.to website. they look the same, and the characters seem to mostly match, so i send the transaction
**\<suraeNoether>** (same thing for firing up my bitcoin wallet to verify i'm sending to myself appropriately)
**\<sarang>** So you effectively treat the shell as a fingerprint
**\<suraeNoether>** yeah, pretty much
**\<suraeNoether>** there are collision issues
**\<sarang>** its use being similar to key fingerprints in other places
**\<suraeNoether>** but i think if we do it appropriately, it's less likely than for other approaches
**\<sarang>** Right, so it's not a primary check
**\<knaccc>** very cool, can you paste an example seashell ascii art please?
**\<suraeNoether>** in addition to that, i wrote a thing on churn that is 3+ pages long. it's statistics-heavy, still internal, will be shared later this week. it'll help inform us on our ring size choices, etc, for the next fork
**\<suraeNoether>** not ascii :D
**\<suraeNoether>** but one sec
**\<knaccc>** oh it's not ascii art? so won't work in the CLI?
**\<suraeNoether>** correct, it is a 3d rendering
**\<knaccc>** oh cool
**\<moneromooo>** You can have cli shells there.
**\<suraeNoether>** so it'd have to be a javascript client side rendering sort of deal
**\<knaccc>** hehe
**\<suraeNoether>** let me find where i saved some of the cool ones last night
**\<sarang>** will it work in bash, or just in csh =p
**\<endogenic>** you could render it easily enough
**\<moneromooo>** :)
**\<endogenic>** and could also scan a render
**\<endogenic>** rotated of course
**\<sarang>** FYI will have to leave meeting early in 20 min to catch plane
**\<knaccc>** 3d renderings sound much more useful than the kind of ssh-keygen fingerprint ascii art
**\<suraeNoether>** https://usercontent.irccloud-cdn.com/file/vM0sXAXB/Figure\_1.png
**\<suraeNoether>** https://usercontent.irccloud-cdn.com/file/RKtCkotV/Figure\_1-1.png
**\<suraeNoether>** so, 1) i'm using matplotlib in python, so it's ugly
**\<knaccc>** oooh that's lovely! much better than this:
**\<knaccc>** +---[RSA 2048]----+
**\<knaccc>** | .++ |
**\<knaccc>** | .+.. .|
**\<suraeNoether>** ikr
**\<knaccc>** | . . . . ..|
**\<knaccc>** | . . .E.. |
**\<moneromooo>** ...
**\<knaccc>** | ...S . |
**\<knaccc>** | o+. |
**\<knaccc>** | +..o |
**\<knaccc>** | o B .o. |
**\<knaccc>** | . + +.. |
**\<knaccc>** +------[MD5]------+
**\<sarang>** omg stahp
**\<sarang>** the ascii, it hurts
**\<knaccc>** haha
**\<suraeNoether>** so, all the formulaes and everything need to be tweaked to make them prettier and more shell-like... and a good javascript person could use the marching cubes algorithm to render these really easily. someone could mess with textures and colors using the hashes, too
**\<moneromooo>** Or we could generate rogue rooms...
**\<suraeNoether>** but i'm essentially \*not\* going to put more effort into it: my goal was to construct parameterizations of these surfaces, the math heavy end of things, so someone else can take it and run with it
**\<sarang>** To jump in quickly due to time... any questions lingering about the audit results? The initial stuff has been picked up by a few sites, generally reported badly
**\<sarang>** We'll respond to the findings and they'll issue a final report, and then get the rest of their payment from OSTIF
**\<sarang>** The initial draft doesn't mention OSTIF, which is an oversight on Kudelski's part
**\<suraeNoether>** sarang I was going to ask about how money was transferred to OSTIF without tax exposure to the monero project or whatever
**\<suraeNoether>** i was thinking about \*how to pay for the monero conference\*
**\<suraeNoether>** like, will we need to start an LLC for each conference? maybe
**\<endogenic>** didn't seem like anyone found the keyspace validation issue.. is that correct
**\<endogenic>** ?
**\<suraeNoether>** endogenic: you mean the multiply-by-8 stuff?
**\<endogenic>** mm
**\<sarang>** endogenic: kudelski did not mention the subgroup checks
**\<endogenic>** oh wiat one did
**\<sarang>** quarkslab did note it in an email to me
**\<endogenic>** i think
**\<endogenic>** k \*zips it\*
**\<sarang>** suraeNoether: what about taxes?
**\<endogenic>** scoobybejesus ^
**\<suraeNoether>** sarang: well, some entity has to pay another entity
**\<suraeNoether>** example: to pay for a venue
**\<sarang>** I mean for the audits
**\<sarang>** The payment for the audit was from OSTIF, a nonprofit, to Kudelski, a private company
**\<suraeNoether>** ah, so we paid OSTIF in monero, and OSTIF is dealing with it
**\<nioc>** when is QuarksLab expected to be finished?
**\<suraeNoether>** and since they are non-profit, tax reports must be made but they aren't exposed to the taxes. i get it. but now i'm thinking about how to funnel money from the monero project towards something like a venue expenditure
**\<sarang>** Correct; OSTIF does the transfer to Kudelski's preferred fiat
**\<suraeNoether>** which is a different question
**\<sarang>** the phrase "funnel money" sounds like a Very Bad Thing
**\<sarang>** nioc: I had expected it this past week
**\<charuto>** Probably a bad idea to make the audits public one at a time
**\<sarang>** charuto: I've been posting public audit information as I receive it, in the interest of open disclosure
**\<suraeNoether>** i can see the argument that it foils some of the independence of the teams
**\<sarang>** and IMHO we should fix issues openly as we find them
**\<moneromooo>** Well, if they'd found something bad, we'd have wanted to wait till a release anyway.
**\<moneromooo>** (without piping up)
**\<sarang>** true, good point
**\<sarang>** Their issues were only minor
**\<charuto>** the last team to release their results could have done nothing and waited to see the other team's results to copy them
**\<sarang>** I suppose
**\<suraeNoether>** charuto while that's technically possible, it's more likely that hte second report will merely be \*bigger\* than the first, including everything the first does, plus more.
**\<charuto>** Imagine like a student assignment where students make their work public before the assignment is due
**\<suraeNoether>** yeah, except these firms make their living off repeat business and word of mouth
**\<sarang>** Except that I trust these groups to operate in good faith
**\<suraeNoether>** it's not a great incentive to screw over one small software project for a relatively small amount of money, when all of them are on twitter all the time trolling zooko
**\<suraeNoether>** yeah, the incentive structure for them to not do their jobs isn't really there the way it is in high school or college
**\<silur>** hey guys sorry for being late :(
**\<sarang>** hullo
**\<sarang>** Anyway, other questions on the audits?
**\<sarang>** We shall make changes as necessary and continue the plan toward a release
**\<suraeNoether>** i have one last quick question on that
**\<sarang>** go
**\<suraeNoether>** i know we signed contracts wtih K and QL
**\<suraeNoether>** or did we just accept their SOW?
**\<sarang>** We signed the statements of work regarding scope and payment
**\<sarang>** y?
**\<suraeNoether>** either way, i'm curious about what we have for Buenz. in terms of "what happens if he just gets busy and phones it in? do we still owe him 10k if he does that?"
**\<sarang>** We have an SoW for Benedikt
**\<sarang>** There is no defined metric for what counts as "phoning it in"
**\<suraeNoether>** k i'll read through it again
**\<sarang>** It is assumed that he will operate in good faith, just as we assume this for the other reviewers
**\<suraeNoether>** yep
**\<sarang>** part of the reason he and the others were chosen was for this reason
**\<suraeNoether>** yep, just curiuos.
**\<nioc>** When is QuarksLab expected to be finished?
**\<moneromooo>** He gave bulletproofs research for free already. No reason why he'd try and screw us here.
**\<sarang>** I emailed a few days ago to QL asking for a status update; no word yet
**\<nioc>** thx
**\<sarang>** I am not pleased with their lack of communication this week
**\<moneromooo>** Well, not "no reason", that is too strong.
**\<suraeNoether>** moneromooo: i'm not assuming malice, but densely packed schedules, the priorities and prerogatives of grad students, etc
**\<sarang>** suraeNoether: he waited for summer term
**\<sarang>** partly because of scheduling
**\<suraeNoether>** yeah i know\\
**\<suraeNoether>** i'm not making any accusations, i was just curious. gosh guys
**\<sarang>** lol
**\<suraeNoether>** i'm going to re-iterate my request that future audits have a "suggested unit testing" section to their reports, though. if we're going to be forking over lots of cash for someone to audit our code, and they are going to spend time saying "gee, this HERE would have been an easy test to write" then... may as well
**\<suraeNoether>** anyway, that's all i have: seashells, churn paper (and small delay on multisig for churn analysis last week, but I've been communicating with Yannick of musig regarding our multisig paper, so that's still moving too)
**\<suraeNoether>** oh, if anyone is curious on the churn paper, and they are tolerant of \*incorrect statistics\* (NEVER BE TOLERANT OF THIS) then you can read my crapdraft here: https://v2.overleaf.com/read/rznczkmdmchy
**\<endogenic>** lol
**\<endogenic>** all statistics are incorrect
**\<endogenic>** got 'em
**\<sarang>** OK, I need to board my plane now
**\<sarang>** I'll be back online in the air
**\<sarang>** because we're living in the freaking future
**\<endogenic>** man can't believe they make people actually catch the planes these days
**\<sarang>** they don't taxi that fast
**\<endogenic>** maybe if you're riding a pony
**\<silur>** last time border police didn't let me on my flight..... again
**\<silur>** #beingstateless
**\<suraeNoether>** Okay, does anyone have any other things they want to discuss?
**\<silur>** yep, any news from the new-new-new-updated rtrs?
**\<suraeNoether>** silur yes, sarang is getting permission to post it on his github
**\<silur>** shall we merge the implementation too there?
**\<suraeNoether>** he has finished around half the algorihtms required, and has been messing around wtih an ed25519 library in python
**\<silur>** oh it's AN implementation
**\<silur>** thought only text
**\<suraeNoether>** no, no, friend
**\<suraeNoether>** sarang has been ON THIS
**\<suraeNoether>** okay, any other questions before we call it?
**\<sarang>** Yeah code is making good progress, waiting on permission to include on my repo
**\<silur>** I kinda don't want to progress with mine if the reference is outdated but glad to hear the py version is goin good
**\<sarang>** I don't have an opinion on it yet
**\<sarang>** The code is basically to help me better understand the setup and efficiency
**\<endogenic>** i'm curious to bring up the question of bindings to C/C++
**\<sarang>** It's also not even remotely optimized
**\<endogenic>** but i know it's work
**\<endogenic>** the mem mgmt could be made v simple
**\<endogenic>** guess it can be a future goal
**\<silur>** @endogenic my implementation is pure C with openssl dependency
**\<suraeNoether>** endogenic: yeah, all we are doing right now is trying to prototype it to get a \*sense\* of asymptotic properties of verification time, etc beyond the statistics described in the paper
**\<endogenic>** i mean for various util libs so the usage of a specific language for r&d isn't indicated by the existence of those shared libs
**\<endogenic>** r&d as in prototyping, sims, etc
**\<suraeNoether>** alllrighty, well, it appears as if we have run out of stuff to talk about. Any final questions?
**\<suraeNoether>** I love you all
**\<endogenic>** no i mean that's unsolved
**\<suraeNoether>** ?
**\<endogenic>** sarang chose a specific language to work in because there were libs in that language already
**\<endogenic>** even if it wasn't the preferred language
**\<endogenic>** just saying there are alternatives and asking how recently they've been investigated
**\<suraeNoether>** oh, gosh
**\<suraeNoether>** i don't know!
**\<suraeNoether>** last time i checked... which was last year when knaccc and i were working on ruffct
**\<suraeNoether>** i believe there weren't better options available at the time
**\<suraeNoether>** but since it's just prototyping, i'm not sure it matters too much
**\<endogenic>** yeah, just a matter of language preference for him..
**\<suraeNoether>** okay, \</meeting>

278
_posts/2018-07-23-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-07-23.md Normal file
View file

@ -0,0 +1,278 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-07-23
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<suraeNoether>** Allright everyone, let's get going on this. Today we are having a research meeting, whose purpose in general is to keep the community up to date on what MRL is doing. That includes all contributors, too, not just sarang and myself. We share papers we've been reading or writing, we disseminate our results... but also we get ideas from you guys, give you a chance to provide feedback to us. Today's agenda is:
**\<sarang>** let us begin, eh
**\<suraeNoether>** 1) Greetings. 2) Sarang has an update on bulletproofs for us. 3) I have an update on multisig for us. 4) ArticMine has an update on bulletproof fees but I'm not sure if available... let's see... 5) soliciting questions, etc?
**\<sarang>** hello
**\<suraeNoether>** Hi
**\<oneiric\_>** hi
**\<iDunk>** hi
**\<suraeNoether>** Sarang, want to start us off?
**\<sarang>** Kudelski has completed their final report, with input from us. This reduces the number of identified flaws to 3, along with some observations
**\<sarang>** All flaws have been patched by moneromooo already
**\<ArticMine>** hi
**\<suraeNoether>** sweet
**\<hyc>** if a flaw sits in a codebase, and no one is there to release it, is it a bug?
**\<sarang>** The report is staged for release, but there was an issue with how OSTIF was credit in the report. That's been fixed and we're waiting for their sign-off as a courtesy for concurrent release and blag posting
**\<suraeNoether>** care to describe the flaws and their severities?
**\<sarang>** However, the final report is just the draft report (https://github.com/SarangNoether/research-lab/tree/master/audits/bulletproofs) with one issue removed, typos fixed, and our brief responses inserted
**\<sarang>** There was a possible overflow (low priority), unsafe use of env variables (low), lack of certain scalar range verification (low)
**\<rehrar>** hi
**\<sarang>** and a couple of identified patches elsewhere in the codebase to harden it up a bit
**\<dEBRUYNE>** sarang: To be clear, 3 flaws found, which already have been fixed by mooo right?
**\<sarang>** yes
**\<sarang>** QL expects first draft today, but they have been delightfully poor at communicating promptly, so we shall see
**\<sarang>** Bunz has not responded to my emails in several workdays
**\<endogenic>** "hyc> if a flaw sits in a codebase, and no one is there to release it, is it a bug?" you changed it
**\<suraeNoether>** well that already makes the audit financially worth it, in my mind: imagine someone purposely desigining a bulletproof with the overflow issue
**\<sarang>** None of the flaws had identified exploits
**\<moneromooo>** Wouldn't matter, since that function will not be used :)
**\<sgp\_[m]>** <3
**\<suraeNoether>** hence the low priority
**\<suraeNoether>** but i imagine someone could do something nefariously annoying with it
**\<suraeNoether>** even if it wasn't a full on exploit
**\<suraeNoether>** perhaps
**\<suraeNoether>** anyway
**\<moneromooo>** We didn't know at the time it wouldn't be used. We know only since ArticMine's fee proposal limits to one proof per tx.
**\<suraeNoether>** aha i see! so it's even lower priority, since it's not a functional component
**\<suraeNoether>** that's neat
**\<suraeNoether>** "we found a flaw in your design: the appendix."
**\<suraeNoether>** "i mean what is that really"
**\<sarang>** Aside from BPs, I have been working with Ruffing's colleague on ring sig stuff. I now have enough information to jump a big hurdle in the prototyping code
**\<suraeNoether>** oh yeah you saw that email he sent with the polynomial info?
**\<sarang>** This code has been cleared for release to GitHub, so I can push to a test branch on my repo
**\<sarang>** suraeNoether: yes
**\<suraeNoether>** awesome
**\<sarang>** I think he has it a little backwards tho
**\<sarang>** (transpose of his matrix, IIRC)
**\<sarang>** I'll check with him to confirm
**\<suraeNoether>** these are sublinear batch-verification ring confidential transactions, for those of you in the crowd keeping track
**\<sarang>** We haven't been cleared to release their draft paper unfortunately, just the code, with the understanding that it's very, very early
**\<sarang>** and we have no definite plans to do anything with it yet
**\<hyc>** needs "quantum" in the name somewhere
**\<suraeNoether>** sarang one last thing on BPs: want to write a blog post on "the current state of our art" with bulletproofs + audit results? we can hold off on releasing it until after all the audits are in, or we could do it piecemeal, but I want a link I can point to that summarizes all the optimizations etc, and maybe summarizes the net improvements we'll be seeing
**\<sarang>** However, it includes a built-in range proof (SORRY BULLETPROOFS) and can take advantage of our cool multiexp stuff
**\<sarang>** suraeNoether: I'd wait
**\<sarang>** We'll publish the Kudelski final report first, in the interest of transparency
**\<suraeNoether>** "quantum transactions: you can either be sure the money was authorized to be sent and not a double spend, or be sure where it's supposed to go, but you can't be certain..."
**\<hyc>** ;)
**\<suraeNoether>** neato burrito. Does anyone have any questions for sarang on the bulletproof updates, or the sublinear ring signature scheme (the paper we have not been given permission to share, btw)
**\<sarang>** kk
**\<hyc>** surprised you're allowed yo publish the prototype code, since that obviously gives away the algorithm from the paper
**\<sarang>** They wanted it clearly identified as code only representing a draft paper
**\<sarang>** and the code has no security proofs, obviously
**\<oneiric\_>** will the sublinear ring signatures work alongside bulletproofs to reduce signature size/ verification?
**\<suraeNoether>** hyc they don't want to embarass themselves by pushing out incorrect proofs, or typo-laden stuff, etc, and they want the code to be labeled as sarang just described
**\<sarang>** oneiric\_: they can either use BPs or a built-in range proof option
**\<suraeNoether>** question: can the ruffct proofs be bulletproofed?
**\<oneiric\_>** very cool, thanks sarang
**\<sarang>** They essentially take all the statements in a RingCT proof and batch them all together in a big polynomial matrix
**\<sarang>** the range proof is one row of this matrix
**\<sarang>** then they compress them down logarithmically
**\<suraeNoether>** that sounds to me like the bulletproof method could be applied to it. interesting.
**\<sarang>** it's very clever
**\<sarang>** not really
**\<sarang>** they use a method by Bootle on polynomial zero-knowledge systems
**\<sarang>** I can link the Bootle paper later
**\<sarang>** that's been out for a bit already
**\<sarang>** I don't know why you'd want to bulletproof this system
**\<sarang>** it already is logarithmic
**\<suraeNoether>** let me put it another way: i'm curious about whether bringing the polynomial commitments into bulletproofs would bring anything, not the other way around. but nevermind, we can move on. :P
**\<sarang>** and allows for a fair bit of flexibility in the statements you can include all at once
**\<sarang>** oh, I haven't considered that. My gut says "not easily"
**\<suraeNoether>** nothing worth doin is easy. :P
**\<suraeNoether>** speakign of which, moving onto multisig
**\<suraeNoether>** https://v2.overleaf.com/read/bfjfkdgnhgvh
**\<suraeNoether>** i'm moving through to verify equations, but proof structure is all finished, and we have some other updates to make like copy editing, etc
**\<suraeNoether>** the hard parts are all completed
**\<suraeNoether>** for \*this\* paper
**\<sarang>** congrats!
**\<suraeNoether>** it technically is not proving anything about MLSTAG-style ring confidential transactions, or our view key structures
**\<sarang>** instead...
**\<suraeNoether>** well, it's like a plain public key model, you use one key X, I use one key Y, we compute one shared key Z, and we compute a ring signature with some fake Z's
**\<suraeNoether>** instead of: I have a pair of keys (A,B), you do too, we merge the B's, etc
**\<suraeNoether>** but it's the underlying threshold ring signature scheme upon which our extensions are based
**\<suraeNoether>** and it's secure!
**\<suraeNoether>** now, the ruffing paper with sublinear ring confidential transactions defines RCT as a primitive, and proves a variety of security properties specific to that primitive
**\<suraeNoether>** they are helping lay the foundation of the path towards proving our entire current set-up secure... but if we are considering switching to ruffing's approach eventually...
**\<sarang>** considering is a very strong word
**\<sarang>** intrigued is a better word
**\<suraeNoether>** heh, well you and I and everyone else immediately say "what" about ring signatures?
**\<suraeNoether>** "ugh, ring signatures need to be replaced eventually"
**\<sarang>** yes please
**\<sarang>** but until that day, bigger is often better
**\<sarang>** ring size, not proof size
**\<suraeNoether>** a full and complete rigorous description of our current ring signature set-up like in this multisig paper if ring signatures days are numbered? not sold on the utility of that
**\<rehrar>** and other things ;)
**\<suraeNoether>** motion of the ocean, rehrar, motion of the ocean
**\<rehrar>** lies
**\<moneromooo>** I'm lost now.
**\<ArticMine>** Do we have possible alternatives to ring signatures in the pipeline
**\<sarang>** Not particularly. Nobody has a way that's untrusted and smaller and faster yet
**\<suraeNoether>** ArticMine: other than ruffing's ring confidential transactions, which are the only good candidates we know of for ring sizes 32-64, short of using a zk-stark set-up... not yet
**\<sarang>** Ruffing is still essentially a ring signature
**\<sarang>** in that we rely on key images and known decoy sets
**\<sarang>** It just uses a more general language to prove the underlying statements
**\<suraeNoether>** fair enough
**\<sarang>** I look forward to the shitty newzsites: MONERO TO GET RID OF BULLETPROOFS
**\<sarang>** Anyway, I plan to continue working with the Ruffing scheme
**\<suraeNoether>** heh
**\<sarang>** ArticMine had much to say about fees
**\<hyc>** I have a proposal for better than ZKPs: negative knowledge proofs. the longer you analyze them, the dumber you get.
**\<suraeNoether>** allrighty, other than a bit of work on churn, i've spent like 12+ hours per day on multisig for a week so i'm taking a few days off. :P heh... and i'm done.
**\<suraeNoether>** hyc i love it
**\<suraeNoether>** hyc we should make tshirts
**\<suraeNoether>** yes, ArticMine please enlighten us on bulletproof fees
**\<sarang>** suraeNoether: definitely carry on with churn going forward
**\<ArticMine>** I posted the proposal in dev https://docs.google.com/document/d/1Y3IsjH7ywJOvFeZd1qT1fRfz2lw8APp8ptcyDXzYrxk/
**\<suraeNoether>** wheee! yay
**\<ArticMine>** Basically we replace size with weight to account for the Log2 scaling of BP verification
**\<sarang>** (BTW don't view link if you have an active Google session, or your information will be listed as a viewer)
**\<ArticMine>** View it without a Google log in
**\<sarang>** correct
**\<sarang>** anyway, carry on
**\<sarang>** Your second FOR loop applies to the (total number of outputs) - 2?
**\<ArticMine>** The key is that size has to be replace with weight in the determination of the block size now block weight penalty
**\<ArticMine>** The weight only applies when there is more than 2 outputs and we limit the maximum number of outputs to 16
**\<suraeNoether>** so fees are flat\_fee + (# outs - 2)\*fee-per-out?
**\<ArticMine>** Yes
**\<suraeNoether>** sweet!
**\<suraeNoether>** does anyone have any questions for ArticMine ?
**\<oneiric\_>** could a reduction happen with only one output?
**\<sarang>** Why would there be one output?
**\<oneiric\_>** someone gaming the weighting algo
**\<ArticMine>** if an output is spent with no change
**\<tnsepta>** if you sweep a wallet won't there only be 1 output?
**\<suraeNoether>** or if you want no change
**\<suraeNoether>** yeah
**\<sarang>** I thought wallet always generated a zero-amount second out
**\<iDunk>** It does.
**\<sarang>** Is that consensus level?
**\<moneromooo>** No.
**\<sarang>** ty
**\<tnsepta>** didn't know that, what's the purpose of it?
**\<tnsepta>** is it for anonymisation?
**\<ArticMine>** Still since it is possible it need to be accounted for
**\<suraeNoether>** tnsepta: since most txns are 2-in-2-out, it helps keep most transactions distinguishable
**\<ArticMine>** Actually there can be many txs that are 1 in 2 out
**\<suraeNoether>** wait?fair, i should just restrict my statement to number of outs
**\<iDunk>** x-in-2-out
**\<suraeNoether>** but anyway
**\<ArticMine>** and they are significantly smaller in size now because the ring signature part is more significant
**\<tnsepta>** yup that makes sense then from an anonymisation standpoint
**\<suraeNoether>** Is anyone else doing anything interesting with monero they want to chat about?
**\<ArticMine>** One other point here is increasing the ring size to 11 or using a fixed ring size of 11
**\<ArticMine>** This actually helps mitigate the verification issue
**\<sarang>** This is where I'd hoped we would have better data on churn/diffusion and its relationship to ring size
**\<sgp\_[m]>** Why 11?
**\<suraeNoether>** oh, gosh, moneromoo o built me a utility that i can use to figure out whether there is a numerical solution to that!
**\<suraeNoether>** i forgot! i've been so busy finishing multisig
**\<sarang>** yup yup
**\<sgp\_[m]>** Likewise
**\<suraeNoether>** moneromooo built a utility that computes the # of unique transaction outputs in the history of any given transaction
**\<ArticMine>** I piked 11 as the largest ring that would still allow for an 80% fee reduction
**\<suraeNoether>** oh, that's a good metric :D
**\<sarang>** We should have concrete data to show the benefit
**\<sarang>** Otherwise we're just saying "surely bigger is better"
**\<ArticMine>** So all the fee calculations are based upon a ring size of 11 and a 2 in 2 out tx
**\<sarang>** and then there's a counterargument about keeping ring size and taking smaller txn size
**\<rehrar>** at the very least we wanted to moved to a fixed ringsize this upcoming hard fork, yes?
**\<rehrar>** regardless of bigger or not
**\<sarang>** I believe that is best
**\<suraeNoether>** i think that would be beneficial, yes
**\<suraeNoether>** we are at 7 now?
**\<suraeNoether>** is that rihgt?
**\<ArticMine>** In my proposal my recommendation is fixed 11
**\<rehrar>** yes
**\<sgp\_[m]>** Yes
**\<sarang>** that is rihgt
**\<sgp\_[m]>** Yes 7
**\<sarang>** We can at least make fun Spinal Tap references to convince people it's a good thing
**\<suraeNoether>** i'd support a fixed number between 7 and 11. i have no skin in this game, so to sepak
**\<sarang>** I'd support learning the effects
**\<suraeNoether>** sarang: oh yeah we can brand this the spinal tap update, with bulletproofs and ring size all the way to 11
**\<sarang>** and making a decision based on that
**\<unknownids>** 11 rings when you need 1 more ring than 10
**\<oneiric\_>** lol
**\<unknownids>** why not just make 10 bigger? cause ours go to 11
**\<moneromooo>** I see you got the idea rihgt.
**\<ArticMine>** The case for a fixed 11 are 1) User simplicity 2) No ring profiles 3) There may also be a regulatory advantage in taking away control from the user here
**\<sarang>** I still think we need to start naming our changes (PoW, network upgrades, etc.) to make them seem less contentious
**\<suraeNoether>** i'll run moneromoo's utility, it'll take a day or three of boiling my ram, then i'll have an answer about "what ring size is so large that improvements become negligible?
**\<sarang>** ty suraeNoether
**\<sarang>** keep me in the loop
**\<rehrar>** post results here, I wanna know too
**\<ArticMine>** Any questions?
**\<suraeNoether>** rehrar: of course
**\<rehrar>** Will we be ready for the "freeze"?
**\<dEBRUYNE>** Moving to a static ring size is more important than bumping it imo
**\<rehrar>** has the freeze been discussed yet?
**\<sarang>** When is our desired freeze date
**\<sgp\_[m]>** I need to update the verification time and size increase to account for bulletproofs before making any analysis. The % will be higher since outputs are a smaller consideration
**\<moneromooo>** Yes, one: have you considered allowing compound proofs for the case of 2^n+1 ?
**\<ArticMine>** Is there support for static 11 ring size?
**\<moneromooo>** Yes.
**\<scoobybejesus>** any interest in a consensus rule that # of outputs must be >= 2?
**\<rehrar>** I would say Yes, unless suraeNoether's research shows something surprising
**\<suraeNoether>** ArticMine: i support a static ring size. i will hold off on a number for a day or three
**\<oneiric\_>** Are there any arguments/reasons against using a static ring size?
**\<sgp\_[m]>** ArticMine I need to compile more info before agreeing, but I think the number is generally reasonable
**\<sgp\_[m]>** I definitely support static
**\<sarang>** Some users will argue they want "greater privacy"
**\<suraeNoether>** i think 11 in general is fine, actually
**\<sarang>** I think those users are wrong
**\<suraeNoether>** i may support a slightly higher number
**\<scoobybejesus>** i tentatively support static 11
**\<moneromooo>** No, they're not. Everyone should want greater privacy.
**\<moneromooo>** They get to send to themselves once, and wait for a day or so.
**\<sgp\_[m]>** People who REALLY know what they're doing lose flexibility
**\<sarang>** I think they're wrong about the big ring size moneromooo, not wanting privacy
**\<tnsepta>** isn't there a balance between privacy and prices?
**\<ArticMine>** Yes
**\<suraeNoether>** tnsepta: there is, the question is whether the balance will be on the side of privacy or prices. :P
**\<isthmuscrypto>** @xmrhaelan et al over in Monero Outreach could do some preemptive education about "ringsize > default ---> LESS privacy, not more"
**\<dEBRUYNE>** tnsepta: Price as in fee price or?
**\<hyc>** but it's misguided to believe "I want greater privacy than the average monero user so whatever ringsize they use, I'm going to use a bigger one"
**\<ArticMine>** A increase over 11 will require a modification of the fees.
**\<ArticMine>** Basically what matters is the ratio of the reference transaction weight to the effective minimum block weight
**\<suraeNoether>** okay, let's move on for now; seems like a static ring size is supported regardless of whether we increase it or not or by how much
**\<ArticMine>** That alternative is to increase the minimum effective median block weight above 300000 bytes
**\<moneromooo>** have you considered allowing compound proofs for the case of 2^n+1 ?
**\<suraeNoether>** moneromooo: can you elaborate on your question?
**\<sarang>** The case where the # of outputs is 3, 5, 9
**\<moneromooo>** Sure. If you have 9 outs, have you considered allowing two proofs of 8 and 1, insetad of one of 16 ?
**\<sarang>** and we round up
**\<moneromooo>** Since that' the case that hurts most in verification time.
**\<ArticMine>** Yes the tradeoff is size
**\<moneromooo>** So you considered it, and deemed it better even in that case ?
**\<ArticMine>** Yes
**\<moneromooo>** OK, thanks.
**\<ArticMine>** In fact the 9 case is the tricky one
**\<sarang>** When is our ideal freeze date?
**\<ArticMine>** Also the pricing treats 9 the same as 16
**\<suraeNoether>** sarang: good question
**\<suraeNoether>** we should have asked that in dev at the last meeting
**\<suraeNoether>** ok does anyone else have anything they want to chat about?
**\<isthmuscrypto>** Monero Archival Project is chugging along nicely. Transitioning to VPS infrastructure, spun up nodes on 3 continents now. Having multiple geographically-distributed archival nodes will helpful for understanding the representativeness of our data, and enables study of network topology/latency.
**\<isthmuscrypto>** NeptuneResearch is working on updating our archival daemon to be compatible with 0.12.3.0 and expects to be done soon.
**\<suraeNoether>** that's such a cool project isthmuscrypto
**\<suraeNoether>** do you guys have an irc channel or a website or something
**\<suraeNoether>** ?
**\<isthmuscrypto>** #noncesense-research-lab
**\<suraeNoether>** heh
**\<isthmuscrypto>** Anybody is welcome to join, we just keep the data science-y stuff over there to avoid flooding the MRL channel
**\<suraeNoether>** cool
**\<suraeNoether>** i think it's interesting, though, so you're welcome to talk about it here too :D
**\<isthmuscrypto>** Have some preliminary results analyzing the spring data. Going to do some double checking, and documentation, but will run the results by you in the next month or so.
**\<isthmuscrypto>** Thanks! It's helpful to get input from MRL
**\<sarang>** Our timing today is perfect; exactly one hour
**\<sarang>** I'll finish up some polynomial stuff and continue lighting small fires under reviewers' asses =p
**\<suraeNoether>** yep! have a good day everyone

113
_posts/2018-07-30-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-07-30.md Normal file
View file

@ -0,0 +1,113 @@
---
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
**\<sarang>** We can start now
**\<sarang>** Greetings
**\<sarang>** This will be a brief meeting to catch up on recent research
**\<sarang>** All bulletproof audits have completed
**\<sarang>** 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.
**\<silur>** yaay
**\<sarang>** I continue to work on some new ring signature algos from Ruffing et al.
**\<oneiric\_>** very nice, excited to read the most recent reports
**\<sarang>** lots of fun building blocks with that scheme
**\<sarang>** and suraeNoether has provided a multisig paper for me to review
**\<sarang>** that is also in progress
**\<sarang>** any questions on these things in particular?
**\<silur>** let's collaborate on that I have an implemaentation on the first paper version
**\<silur>** C, openssl
**\<sarang>** silur: sure, the initial parts of the prototype are on my repo, rupol branch, in python
**\<silur>** been working on rtrs for a long time
**\<silur>** okay, will write you after the meeting
**\<sarang>** anything in particular to share regarding your rtrs silur ?
**\<silur>** well we just have to update it to the new-new-new construction
**\<silur>** I only have the unpublished internal version of the first paper
**\<sarang>** righto
**\<sarang>** We shall talk afterward
**\<sarang>** Any other interesting work to be shared?
**\<endogenic>** anyone see a problem with running openssl transpiled via emscripten in a browser?
**\<sarang>** I feel extremely not qualified to answer that properly
**\<andytoshi>** endogenic: openssl, transpiling, emscripten, and browsers are all bad for security
**\<endogenic>** yep, no worries, just throwing it out there
**\<sarang>** lol
**\<endogenic>** then why does monero use it lol
**\<silur>** where?
**\<andytoshi>** monero is writtcen in C++
**\<endogenic>** common/util.cpp (LOL) #include <openssl/sha.h>... ringct/bulletproofs.cc #include <openssl/ssl.h> ...
**\<silur>** yea but where do we transpile it with emscripten?
**\<endogenic>** just asking
**\<silur>** I don't really recommend that
**\<endogenic>** any specific reason?
**\<silur>** don't know about emscripten internals but we used to have a thing called openssl code health tuesdays
**\<silur>** after a month we eliminated 40K dead lines and 8 dead platforms
**\<silur>** I think that's a reason not to include it in browsers
**\<endogenic>** emscripten handles that sort of stuff
**\<andytoshi>** 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
**\<silur>** also it has lots of inline ASM stuff how does emscripten handle that?
**\<andytoshi>** 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.
**\<needmoney90>** Did anyone check out the paper I posted last week?
**\<needmoney90>** https://arxiv.org/abs/1702.07588
**\<andytoshi>** http://matasano.com/articles/javascript-cryptography/
**\<endogenic>** andytoshi: people are going to run worse web wallets if we don't
**\<endogenic>** run one that is
**\<needmoney90>** I'm curious if FHE can be used for remote node syncing, to allow us to make queries on encrypted data
**\<endogenic>** silur: 1sec
**\<andytoshi>** needmoney90: you want PIR for that, not FHE. and there are existing PIR primitives that are actually implemented and usable (see percy++)
**\<needmoney90>** It's possible that due to our static append only data set that we can't actually hide access patterns
**\<silur>** needmoney90 thanks a lot, it seems super interesting
**\<needmoney90>** Never heard of PIR, got a paper for me?
**\<needmoney90>** Maybe I just don't know the acronym
**\<sarang>** private information retrieval
**\<silur>** lots of stuff on PIR
**\<silur>** thanks for percy++, i'm working with pir a lot for riffle
**\<silur>** where do we need that btw?
**\<silur>** in monero?
**\<endogenic>** silur: emscripten might not be able to handle it, depending on exactly what's there. i guess maybe an alternative implementation exists
**\<endogenic>** people seem to have been able to do it , in any case
**\<endogenic>** 🤞
**\<oneiric\_>** is boringssl an option for you?
**\<endogenic>** oh
**\<endogenic>** ./configure --no-asm
**\<endogenic>** of course
**\<endogenic>** oneiric\_: not to ignore you - i'll investigate if it becomes necessary
**\<sarang>** Anyone else wish to share something intriguing on their minds?
**\<sarang>** Also welcome andytoshi
**\<isthmuscrypto>** Oh, I can give a #noncense-research-lab summary
**\<sarang>** please
**\<isthmuscrypto>** 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.
**\<isthmuscrypto>** 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.
**\<isthmuscrypto>** 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.
**\<isthmuscrypto>** 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.
**\<isthmuscrypto>** 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.
**\<isthmuscrypto>** (/end)
**\<isthmuscrypto>** 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
**\<sarang>** this is very interesting work
**\<andytoshi>** 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
**\<sarang>** oh excellent, thanks
**\<isthmuscrypto>** Shoot, I gave the wrong channel above. #noncesense-research-lab
**\<sarang>** andytoshi: what are the overall plans for musig?
**\<andytoshi>** sarang: well, musig signatures verify identically to schnorr..
**\<andytoshi>** so the goal is for bitcoin to support schnorr as part of taproot
**\<andytoshi>** and then wallets would implement musig if they're doing multisig stuff
**\<andytoshi>** since the resulting multisigs would be smaller/more private than ones using CHECKMULTISIG
**\<sarang>** Great, so laying the groundwork for future wallet code
**\<sarang>** cool
**\<sarang>** It seems fairly quiet here otherwise today, so any other material to share?
**\<andytoshi>** not really, i've mostly been doing rust-bitcoin ecosystem work
**\<endogenic>** yknow people have been transpiling rust to JS too :P
**\<silur>** and wasm :D
**\<endogenic>** well that's what i mean :P
**\<silur>** wasm openssl is not a bad idea tho
**\<silur>** looks like I have a new sideproject
**\<endogenic>** oh that's just what i'm talking about...
**\<endogenic>** whoever beats the other to it i guess
**\<endogenic>** it's easy enough
**\<endogenic>** i have instructions.. :P
**\<endogenic>** i have boost transpiled already..
**\<sarang>** Well, I think we can safely call the meeting then, everyone can continue performing admirably

180
_posts/2018-08-20-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-08-20.md Normal file
View file

@ -0,0 +1,180 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-08-20
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<sarang>** lets begin
**\<suraeNoether>** fluffypony: knaccc luigi1111 sarang ajs[m] andytoshi anonimal ArticMine binaryFate chachasmooth dEBRUYNE endogenic gingeropolous hyc iDunk isthmuscrypto john\_alan jwinterm knaccc kerber m2049r[m] moneromooo MoroccanMalinois needmoney90 nioc philkode pigeons rehrar[m] rrol[m] scoobybejesus sgp\_1 sgp\_[m] smooth sneurlax stout stoffu UkoeHB unknownids vtnerd waxwing
**\<suraeNoether>** let's hang out for 2 minutes and we'll start
**\<sarang>** careful, mass mentions can get you autobanned
**\<sgp\_1>** hello
**\<iDunk>** hi
**\<suraeNoether>** sarang i've been doing it for a year. \*shrug\* you mean from freenode? or from this channel?
**\<sarang>** freenode IIRC
**\<sarang>** due to all the recent spam
**\<scoobybejesus>** hi
**\<suraeNoether>** hi everyone
**\<sneurlax>** Hey, I have the code to provide mining-pool-reused outputs in the format moneromooo requested up at github.com/sneurlax/xmreuse. I don't know if or how there's a way to add to the blackball database from GET/HTTP calls but that's what I was asked for. I need to update the outputs, I think, and add more pools over the next few days, but it's pretty straightforward...
**\<sneurlax>** The repo is private at the moment if I recall correctly. Drop github names to invite or I'll make it public whenever y'all say to
**\<MoroccanMalinois>** hi
**\<suraeNoether>** Welcome to the first post-defcon MRL research meeting. Agenda today is simple. 1) Greetings (done!) 2) Does anyone have any items they want to add to the agenda? 3) Let's catch up on what everyone is doing.
**\<sneurlax>** Sorry to dump and I have to have an afk meeting now but I'll catch up on what I missed after.
**\<suraeNoether>** sneurlax: great, thanks!
**\<sgp\_1>** sneurlax I would like to be invited if possible. I'm added to xmreuse-firebase but not xmreuse
**\<suraeNoether>** okay, as far as stuff \*i\* am doing/want to do: depending on contact from one person, we'll be putting multisig up on IACR. in the meantime we can publish it as MRL-7 or whatever we like as a technical note, or as an author version or something like that...
**\<suraeNoether>** but that depends on whether the journal we decide upon is greedy and has a concurrent publication policy
**\<sneurlax>** Absolutely. Anyone that wants to can be, or just let me know to flip it public. Later tho
**\<endogenic>** weww
**\<suraeNoether>** my first priority is to publish the multisig paper as a peer reviewed document. send, as an MRL bulletin. why? MRL (from my point of view) isnt' interested in drifting toward the publiccation world yet. :P and getting more peer reviewed articles published under the MRL \*name\* is more important than publishing our own articles without review
**\<suraeNoether>** my second priority this week is sarang's DLSAG paper and some research on side channel stuff
**\<sarang>** I'll look forward to the DLSAG review; we can push it as an MRL once internally reviewed
**\<suraeNoether>** my tertiary priorities this week are: discussions about an MRL research assistantship program, and work on the MAGIC non-profit stuff.
**\<suraeNoether>** i already read it once and i saw no troubles with it, but this time i'm looking at it more closely
**\<sarang>** What side channel stuff are you researching?
**\<sarang>** that's a broad area
**\<sgp\_1>** ooh, let me know if I can help with the assistant research program
**\<suraeNoether>** the whole \*waves hand\* broad side of the area on \*waves hands more\* this side of the area
**\<stout>** that assistant research program sounds intriguing by name
**\<suraeNoether>** so, the MRL research assistantship program... \*sigh\* so like, look
**\<suraeNoether>** we, as a crowd-sourced open source project, have a fundamental problem with funding things in crypto
**\<suraeNoether>** and that is: if anyone wants to do anything organizational in nature, they eat the taxes
**\<suraeNoether>** if i want to host a job search for MRL, for example, well.. we aren't a company, someone needs to hold the cash, and spend it, for making websites and putting up job postings, etc
**\<suraeNoether>** if it's an individual, it's all individual income, capital gains and losses... it's insane to try to do it that way legally
**\<sarang>** Not really, just annoying
**\<sarang>** that's how we operate
**\<suraeNoether>** well, the hiring example isn't a good example, but hosting a conference \*is\* a good example
**\<sarang>** yes
**\<suraeNoether>** that's tens of thousands of dollars worth of liability, possibly hundreds depending on size
**\<suraeNoether>** in general, though, there are lots and lots of little things that all add up to "SOMEONE SHOULD START A FREAKING COMPANY HERE JUST TO DIRECT FUNDING THROUGH." and that ... is... i'm a math phd, i'm not a business dude. it's not appealing to me
**\<suraeNoether>** so something like a research assistantship program is an idea that i've been kicking around with sarang and fluffypony
**\<suraeNoether>** and some others
**\<suraeNoether>** where we invite graduate students from across the country to apply. the core team and MRL go through applications and short list us down to 3-5 candidates. then each of those candidates starts their own FFS
**\<suraeNoether>** and either the FFS sends funding directly to the students, or sends it directly to their university, leaving all the liability on the student and/or the school
**\<stout>** doesn't sound like a solution for the conference problem, but I like the step nonetheless
**\<suraeNoether>** this way, grad students who were in the same position sarang and i were in when we first srtarted at MRL can apply, get some funding, and become monero fanatics who will volunteer their time and blood forever. :P
**\<suraeNoether>** no, not a solution to the conference problem
**\<sarang>** For the conference, outside groups have come forward and expressed interest in managing/funding
**\<suraeNoether>** yeah, i think fluffypony is attempting some solutions to that in a roundabout way
**\<suraeNoether>** but, again, we're kicking ideas around
**\<sarang>** yep
**\<stout>** Any way we can help, specifically in the research assistant thing?
**\<sarang>** I also have it on good authority that a research assistant FFS would have no trouble being funded
**\<suraeNoether>** well, one thing we could use is a secure survey/application system.
**\<sarang>** stout: I think good resources for job postings would be helpful too
**\<suraeNoether>** google forms is criticized as being ... google, obviously
**\<sarang>** Cast a wide net for quality applicants
**\<suraeNoether>** surveymonky allegedly leaks IP addresses, etc
**\<suraeNoether>** my understanding is that thunderosa on reddit has made secure survey software for monero before, so that'd be interseting to look into
**\<endogenic>** use blockchain
**\<sgp\_1>** When using Google you give the info to Google, but only form info is shared with the owner
**\<suraeNoether>** as far as advertising and finding sources for job postings, that part is easy. we can literally just send out an advertising email to every single computer science and math department in the US and europe. no problem. that's not hard, and there are lists for things like that.
**\<sarang>** "to every single department" o\_0
**\<suraeNoether>** why not?
**\<sarang>** it sounds tough
**\<suraeNoether>** there are list-servs for it
**\<sarang>** hmm
**\<suraeNoether>** clemson got spammed constantly by such advertisements
**\<suraeNoether>** except it wasn't really spam
**\<suraeNoether>** it was legit grant and scholarship application stuff
**\<suraeNoether>** besides: i don't want to spend time narrowing down which schools to advertise to, for a bunch of reasons
**\<sarang>** https://www.youtube.com/watch?v=yDbvVFffWV4
**\<sarang>** righto
**\<suraeNoether>** yeah, that's ... surprisingly how clemson was. so many students were like "GOSH DUDE I NEED LIKE 3 MORE SEMESTERS TO GRADUATE, LEAVE ME ALONE!"
**\<suraeNoether>** but it was all industry jobs. :P
**\<suraeNoether>** anyway
**\<suraeNoether>** the thing is about google forms
**\<suraeNoether>** 90% of grad students already have to use google and their products
**\<sgp\_1>** Yeah, I think Google Forms is totally fine
**\<suraeNoether>** i don't want to discourage people who are very privacy-centric from applying by using google forms, but i also know that most of our applicants really won't care too much
**\<sarang>** I use it for anonymous student feedback all the time
**\<stout>** Not a fan.
**\<sarang>** OK, they can email the info to us as an alternative
**\<sarang>** ?
**\<sgp\_1>** good
**\<suraeNoether>** they can always drop an encrypted blob into the google form, tbh, but then we have to decrypt it in a virtual box or something, things get annoying fast. :P
**\<sarang>** let's not complicate things too much
**\<sarang>** if we can help it
**\<stout>** Yeah, I feel google forms or not is just a minor point right now.
**\<stout>** Might be wrong, of course.
**\<sarang>** anyway, any other big info along these lines to share?
**\<suraeNoether>** wait, just to be clear: does that mean we have a weak consensus for this first round of applicants that google forms should be good enough, but if folks want to apply in a more private way they should try to arrange to do so with our protonmails or something like that? is everyone chill with that, even if you aren't a google fan?
**\<sarang>** It really comes down to how you end up storing data, IMHO. If you put the PM data into a Google sheet, the applicants gain nothing
**\<suraeNoether>** true. that.
**\<suraeNoether>** the most vocal statement so far about this is stout saying "not a fan" so i'm guessing everyone's pretty chill with this approach in general for now
**\<suraeNoether>** we'll leave the discussion open about this for a week or so, then we'll start designing the application i guess
**\<suraeNoether>** i got nothing else on the MRL RAP
**\<sarang>** roger
**\<stout>** Offering an alternative to google always finds my vote, and protonmail is great. I don't object.
**\<sarang>** I was asked to be on the OSTIF advisory council, so that's a bit of news
**\<sarang>** gave a local talk on privacy
**\<sarang>** some lit review
**\<sarang>** BP follow-up
**\<suraeNoether>** wow
**\<sarang>** polynomial stuffs
**\<suraeNoether>** def do the advisory council
**\<sarang>** Yeah we had a video meeting last night
**\<sarang>** It helps them prioritize and set their goals openly
**\<sarang>** they're doing good work
**\<suraeNoether>** is OSTIF a non-profit?
**\<suraeNoether>** IT IS
**\<suraeNoether>** dude
**\<sarang>** yes
**\<suraeNoether>** as a board member of MAGIC i strongly encourage you to network :D
**\<sarang>** One of the duckduckgo leads is on the board, among others
**\<sarang>** a good group
**\<stout>** Are you going to take the offer?
**\<stout>** And congrats, of course :)
**\<sarang>** It's an informal group, but yeah
**\<suraeNoether>** cool. anyone have any other topics to talk about?
**\<sarang>** It's good to get our name out there as positive contributors to the bigger community
**\<suraeNoether>** yes
**\<sarang>** One topic that came up
**\<sarang>** over def con
**\<sarang>** was the idea of "outgoing view key" functionality
**\<suraeNoether>** ohhh yeah, still thinking about that, but my last attempt did not work the way i wanted it to. did you have ideas?
**\<sarang>** I am still thinking about ways to do it with the new language afforded by the RuPol scheme
**\<sarang>** I don't have any solid answers yet
**\<sarang>** I think it's important to consider this and other topics that may become more relevant as Monero increases in adoption
**\<sarang>** things like exchange blacklisting, outgoing view, etc.
**\<sarang>** I also considered accumulator-based schemes off-chain for the view functionality, but you need to still prove that an output was generated correctly
**\<sarang>** Not that a "me too" attitude matters, but it's clear that Zcash is introducing this to encourage exchange adoption
**\<sarang>** I need to read up on their Sapling circuit to better understand their approach (I admit to knowing zero about it)
**\<sarang>** That's all the news I have atm
**\<sarang>** any thoughts on this would be appreciated
**\<stout>** I remember some voices on reddit saying that all private keys should be kept private at all times, especially including the view key.
**\<stout>** I don't necessarily agree with this, just some input.
**\<sarang>** Yeah and that might be the primary opposition to the idea
**\<sarang>** The broader question about the nature of our optional transparency
**\<sarang>** Of course, higher ring sizes counter the effects of known spends
**\<sarang>** and those are easier now that we're saving space
**\<stout>** And another counterargument is that if you are forced to give up some privacy, at least have it granular.
**\<stout>** Else whoever is trying to get info will just straight up force you to give up all private keys.
**\<sarang>** One original motivation was the idea that an exchange might require account balance information for some clients
**\<sarang>** as a condition of use
**\<sarang>** a la bitlicense
**\<sarang>** I personally am fine with users having the choice of transparency, provided this doesn't harm other users
**\<sarang>** and provided they can do so with understanding of the consequences
**\<stout>** I think it's a discussion worth having in a broader scope.
**\<sarang>** absolutely
**\<sarang>** and it motivates specific discussions based on particular implementation ideas
**\<sarang>** Anyone else care to share their recent work?
**\<sgp\_1>** Not much. I've been working on the blackball tool for the past few days and adding to the fixed ringsize Github issue
**\<sgp\_1>** I just applied to speak at the NDSU conference next month, so hopefully I am selected
**\<sarang>** Nice!
**\<sarang>** Ring sigs?
**\<sgp\_1>** more general privacy tech
**\<sarang>** how so?
**\<sgp\_1>** What privacy technologies are available, what are their use-cases, etc
**\<sarang>** Nice, broad zero-knowledge systems vs. mixers vs. our approach?
**\<sgp\_1>** I don't want to talk too much more about mixers since that's told news, but things like tumblebit, CT, ring sig, zkSNARK, etc
**\<sarang>** Cool, I'd be interested to know what specifically you'll discuss related to snarks
**\<sgp\_1>** zkSNARKs make sense for "private blockchains" (I hear your complaints) since they are already running in a trusted environment
**\<sarang>** are you gonna discuss how they operate specifically? scaling w/ circuit size etc?
**\<sgp\_1>** No, this is a more business-focused audience
**\<sarang>** got it
**\<sarang>** I'd say we can adjourn the meeting, but sgp\_1 what are your views on "private blockchains" as they relate to trusted participation?

200
_posts/2018-08-27-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-08-27.md Normal file
View file

@ -0,0 +1,200 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-08-27
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<sarang>** The meeting starts presently
**\<endogenic>** rbrunner: answer is there no?
**\<sarang>** suraeNoether: care to begin?
**\<suraeNoether>** oh gosh
**\<suraeNoether>** lost track of time
**\<suraeNoether>** Hi, everyone, my agenda today is 1) greetings, 2) description of the noether bros recent work, and 3) open up the lab to discussion. I wouldn't mind hearing from silur and IsthmusCrypto.
**\<suraeNoether>** So, hi everyone
**\<sarang>** hi
**\<silur>** hi :)
**\<rbrunner>** Hello there
**\<suraeNoether>** This week I submitted our multisig paper to IACR, started reading the DLSAG paper by sarang and started writing up notes for thring confidential transactions and their applications to cross-chain atomic swaps
**\<endogenic>** woop woop
**\<suraeNoether>** waiting on a link from IACR
**\<sarang>** So you'll be taking the DLSAG and extending?
**\<suraeNoether>** sarang: if you don't mind. we could do two separate papers but I don't see a good reason for that, unless yours is already over 15 pages?
**\<sarang>** I would also like comments on its current "technical note" form, for internal publication
**\<suraeNoether>** yeah, for sure
**\<sarang>** But yes, I would like to see it publishable elsewhere too
**\<sarang>** Mine is ~7 IIRC
**\<suraeNoether>** i feel like "Spender-ambiguous cross-chain atomic swaps of confidential assets" is a sexy title
**\<sarang>** it is
**\<suraeNoether>** yeah, i'll provide notes on that as a technical note, then i'll copypasta to a new doc for swaps
**\<sarang>** Let's stay in close contact regarding the DLSAG work and extension
**\<suraeNoether>** yes
**\<sarang>** excellent
**\<suraeNoether>** if you want to do more of the writing before handing it off to me, i think with our writing dynamic it may be appropriate to find a third author to "finish it off" so I don't spend months being a perfectionist
**\<sarang>** Let's wait and see how it goes
**\<sarang>** No need to put the cart before the LaTeX manuscript
**\<suraeNoether>** i was basically going to take the appendix from "Enabling Blockchain Innovations with Pegged Sidechains" by Back, et al, describing cross-chain atomic swaps (initial suggestion by Tier Nolan) and write up a highly detailed version of it with thring signatures
**\<suraeNoether>** so if you want to have more of a hand in writing it, i can put that down for a few days and give you a chance to put some words into it
**\<sarang>** aye
**\<suraeNoether>** cool. so, what have \*you\* been up to this week?
**\<silur>** sorry is thring signatures a typo or the new name? :D
**\<sarang>** I've been working with mooo to make BPs even faster
**\<endogenic>** new name
**\<suraeNoether>** Threshold Ring Signatures = thring signatures!
**\<sarang>** I coded up an addition chain for scalar inversion that doesn't need the OpenSSL library
**\<sarang>** and batch inversion that lets us compute a bunch of inverses speedy quick
**\<suraeNoether>** Threshold Ring Confidential Transactions = Thring Confidential Transactions! Woooo!
**\<sarang>** We're now seeing batched BP verification > 40x faster than borromean
**\<suraeNoether>** jfc
**\<silur>** wow
**\<sarang>** So yeah, a bunch of new optimizations
**\<rbrunner>** It something in the stuff that is planned to go online tomorrow on testnet?
**\<sarang>** I'm also doing initial work toward off-chain safe balance computations
**\<sarang>** rbrunner: the PR includes only some of the optimizations
**\<sarang>** not all
**\<suraeNoether>** i vote fixing ring sizes at 36 and keeping them fixed for a year while we look into sublinear optimizations. :P
**\<endogenic>** it would be a good problem to have
**\<sarang>** Unfortunately the prover is still 2x slower than borromean
**\<moneromooo>** Oh, I bumped like 25% off the prover btw.
**\<sarang>** lolwut
**\<sarang>** go on
**\<moneromooo>** Not looking at it anymore for now :)
**\<sarang>** commit #?
**\<moneromooo>** I took out 128 scalarmults IIRC.
**\<suraeNoether>** jfc
**\<sarang>** https://gph.is/1e0T1tY
**\<suraeNoether>** oh, i wanted to add an item to the end of the agenda
**\<endogenic>** lol sarang
**\<moneromooo>** 81a65c30d667eaf5e4a1f0ecd1e64746b09cfdd7
**\<suraeNoether>** 4) the possibility of an FFS for QuarksLabs to just audit our whole codebase.
**\<sarang>** ty
**\<sarang>** Aso
**\<suraeNoether>** or some part of it
**\<sarang>** \*Also
**\<sgp\_>** hello everyone
**\<sarang>** I want to keep working on trustless accumulators for safe balance computation with auditors
**\<endogenic>** ^
**\<endogenic>** sarangpls
**\<sarang>** PIVX claims to be working on a form of this that's bulletproofs-compatible
**\<suraeNoether>** sarang: do you have any links on that? i know we talked about that euclidean-ring based one
**\<sarang>** I've also been chatting with Zcash devs on their knowledge of this field
**\<sarang>** suraeNoether: the issue is efficiency when it comes to committed values
**\<sarang>** BPs let us do this more or less for free
**\<sarang>** You need to have an accumulator that you can prove was computed correctly with all outputs, and then provide proofs of membership of all the outputs you control, and show that the balances compute
**\<sarang>** my goal is an off-chain solution that requires no protocol changes
**\<sarang>** but also doesn't give the auditor direct knowledge of spend outs
**\<sarang>** (modulo knapsack-type attacks)
**\<sarang>** Our goal is \_not\_ to encourage users to reveal their key images, which is bad for privacy
**\<sarang>** it should be to allow a user to safely prove a balance without showing key images
**\<sarang>** hence the benefit of commitment-based trustless accumulators as one possible approach
**\<suraeNoether>** i'm eager for any reading you have available for that, although i don't know when i'd get to it. :P
**\<sarang>** I'll keep a running list
**\<sarang>** Zcash team had good early discussion on this same problem, and I'm following their logs as a start
**\<suraeNoether>** cool, consider it a literature review in prep :P
**\<sarang>** yup
**\<suraeNoether>** i wonder if a zk-ledger sidechain run by all the exchanges would work
**\<sarang>** If PIVX figured this out, hot damn
**\<suraeNoether>** not really trading tokens around but only committed balances
**\<suraeNoether>** and zk-ledger is largely trustless, iirc
**\<sarang>** In the approach in my head, Alice would share an accumulator that she filled with all outputs on the blockchain
**\<suraeNoether>** and i don't see how it wouldn't be BP-able
**\<sarang>** the auditor could verify that it was computed correctly
**\<endogenic>** new type of lightning network? :P
**\<suraeNoether>** strictly for auditing/compliance purposes... uhm.
**\<sarang>** and using this she can construct zk proofs that her outputs either are or are not in the key image list
**\<endogenic>** can i suggest another agenda item? ring sig replacements.. could it make sense to give research into that to another funded postdoc as a main project?
**\<sarang>** depends
**\<sarang>** right now there are no good solutions, and people are looking for them
**\<silur>** khm RTRS
**\<sarang>** the second we get trustless efficient general zk systems, this would be possible
**\<silur>** hyrax?
**\<sarang>** poor size/memory tradeoff IIRC
**\<sarang>** all the trustless approaches I know of have terrible scaling
**\<sarang>** it's that damn snark toxic waste that gives the proof polynomials structure in a zerocash setup
**\<sarang>** and that's what gives you such good scaling
**\<suraeNoether>** okay, so Silur, IsthmusCrypto, y'all have been busy
**\<silur>** yep I'm slowly making tests for my RTRS demo at HCPP and patching up my mistakes
**\<rbrunner>** RTRS being?
**\<suraeNoether>** silur: i know i've asked you about PQ shuffles before, but I don't know much about pseudorandom generating objects on a theoretical level. Do you know of any introductory papers or textbooks you could suggest to us? I'm sure to put a few hours in some time in the next few months for my backburnered "cartesian square sig" project
**\<suraeNoether>** RTRS is a version of sublinear ring confidential transactions based loosely on the Bootle paper "Short Accountable Ring Signatures"
**\<suraeNoether>** or am i thinking about someone else with the PQ shuffle
**\<sarang>** silur: any chance of sharing code, even privately?
**\<silur>** also I had some advance with the RLWE VRF stuff kind of overkilled a whole section with modular and double-rounding reconcillation but maybe it will be helpful for a designated verifier setup
**\<silur>** no I'm also working on PQ shuffles but bulletproofs kind of got ahead of me
**\<silur>** and I still have to understand BP fully
**\<silur>** because originally I went for the simple Neff shuffle model on a generalized Chaum-pedersen proof
**\<sarang>** sharing the RTRS code I mean
**\<silur>** yea it's on my github
**\<silur>** https://github.com/Silur/libstringct
**\<silur>** so because BP's are much more scalable I put the PQ-shuffle on a pause and try again when I understand BP at a level when I can confidently start to "port" them into a PQ setting
**\<sarang>** neat
**\<sarang>** Anything else of interest to share with the class
**\<sarang>** Or IsthmusCrypto?
**\<sgp\_>** sneurlax's tool is now easy to run
**\<sgp\_>** I updated the blackball lists with MoneroV
**\<sarang>** Excellent
**\<sarang>** I hope this sees use and extension by others as well
**\<sgp\_>** Any thoughts on making the pool lists available too? I know sneurlax was worried about releasing the code
**\<sarang>** (for those who don't trust sgp\_ )
**\<sarang>** Give me the arguments
**\<sgp\_>** I can't speak on his behalf. I would release if I was him
**\<sarang>** I'm generally a fan of making information available
**\<sarang>** Might it influence pool behavior in a positive way?
**\<sgp\_>** We will need some way to have this tool check for chain reactions with the regular blackball tool in the future
**\<sgp\_>** sarang I already came up with an initial best practices guide for pools, but I need to refine it
**\<moneromooo>** The pool thing is a guess though.
**\<moneromooo>** Does it output some sane format (like a key per line or so) ?
**\<sgp\_>** It outputs a single output per line in a .txt file
**\<moneromooo>** OK, I can add reading that then.
**\<sgp\_>** great! Ideally the pool tool could be run first, then the list can be added to the blackball tool as a set of bad outputs
**\<sarang>** Is there a regular schedule envisioned for this?
**\<sarang>** for the hosted version
**\<sgp\_>** At the moment I'm just doing it when I have time. It's all manual at the moment
**\<sarang>** seems a prime candidate for automation
**\<sgp\_>** Probably a few times a month unless it's automated, yes
**\<moneromooo>** I had this idea of having diffs made, then advertised in a TXT record like the release updates.
**\<moneromooo>** Then the wallet could automatically download/merge.
**\<sarang>** baller
**\<moneromooo>** It would require the list maintainer to keep to rigid naming conventions for the diffs.
**\<sgp\_>** moneromooo I believe there are two big features that would help with pool outputs: 1) an easily-selectable output selection option, such as "--selection-algo public-pool", 2) a wallet option to avoid selecting coinbase outputs for decoys, enabled by default (--coinbase-decoys false)
**\<sgp\_>** we can streamline the blackball lists significantly if the coinbase outputs are excluded automatically
**\<moneromooo>** I won't do that unless surae or sarang reckons it's a statistically advantageous thing to do.
**\<sgp\_>** all right, but since the vast majority of coinbase outputs are mined by public pools, it's something to consider
**\<sarang>** So you mean perform the statistically correct output selection (fitted gamma) but with avoided decoys
**\<sarang>** including blackball+coinbase
**\<moneromooo>** That means an attacker can know whether a given tx was made by a pool or not. At first glance, it diminishes your anonymity set.
**\<sgp\_>** moneromooo can you expand on this reasoning? If you're referring to coinbase outputs, they know what transaction they are spent in anyway by the pool since the pool makes its transaction lists public
**\<moneromooo>** If your tx has only two outs, then it \*might\* be good, but that's not immediately obvious.
**\<moneromooo>** Oh, I forgot they do now. Dumb.
**\<moneromooo>** Time to kick pools out ^\_^
**\<sgp\_>** yeah, it's a situation where a ton of network info is public
**\<sarang>** Is IsthmusCrypto here?
**\<sgp\_>** So if you can attribute ~90% of coinbase outputs to specific transactions, we should at least consider setting the default wallet behavior to not include these outputs that will be bad ~90% of the time
**\<endogenic>** anyone know if exploremonero.com is open source? i was a bit surprised to see they ask for the sec view key for checking txs
**\<sgp\_>** endogenic I can't find it. Only the localization: https://github.com/GBKS
**\<endogenic>** hmmmmm
**\<endogenic>** btw i -think- i've identified anycoin as one of the wallets sending with ringsize 8
**\<sarang>** damn off-by-one...
**\<sarang>** So we have ten minutes remaining
**\<sarang>** Does anyone else wish to share something of interest they are working on?
**\<sarang>** moneromooo: can you comment on the expected status of BP updates relative to our release schedule?
**\<moneromooo>** Do you mean "are BPs going in" ? If so, yes.
**\<sarang>** I know there was a cutoff for PR review purposes
**\<sarang>** I assume all that is going smoothly?
**\<moneromooo>** The PR is reviewed and ready to go. The CNv2 changes were supposed to go in too, but the author dropped a large change yesterday :/
**\<endogenic>** also interested. would be good to freeze at some point, if only for a good bit of testing lead time
**\<moneromooo>** So that might push the merge a bit.
**\<moneromooo>** If some of you are familiar with low level bit bashing and hashes, feel free to review ^\_^
**\<sarang>** Yeah I've been following the tweak discussion a bit
**\<endogenic>** how worthwhile will it be to have a final review of this code after the final cut ?
**\<sarang>** Updates to BPs will be a point release I suppose?
**\<endogenic>** i mean audit
**\<moneromooo>** If you mean what's not in the current PR, I dunno yet, but it is fairly likely.
**\<moneromooo>** Unless people want the speedups bad :)
**\<sarang>** Eh
**\<sarang>** Well, thanks to everyone for sharing
**\<sarang>** We can adjourn now and keep discussions going as desired
**\<sarang>** \</meeting>

255
_posts/2018-09-17-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-09-17.md Normal file
View file

@ -0,0 +1,255 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-09-17
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<suraeNoether>** welcome to the #monero-research-lab meeting for 17 September 2018
**\<sarang>** Hullo
**\<silur>** hi
**\<suraeNoether>** we didn't meet last week because Sarang and I were meeting in person for some productivity turned up to 11, enabled partly by endogenic
**\<sarang>** When snarks
**\<sarang>** Or at least snark
**\<suraeNoether>** today's agenda is only 1) greetings is 2) a brief update on what folks have been working on and what they see coming up next
**\<suraeNoether>** we got 1) out of the way so efficiently, i'm just blown away, look at you guys, you are rock stars
**\<dog\\>** lol
**\<sarang>** Shine on suraeNoether
**\<silur>** ^
**\<suraeNoether>** sarang has recently been doing some digging into view key solutions for additional functionality like balance-proving or proofs-of-reserve; is there anything you want to bring up publicly about those for now sarang?
**\<suraeNoether>** since you have like 3minutes
**\<sarang>** Just that the nature of our txn model means balance proofs open up knapsack style problems, are not efficient, and therefore I think not something of great priority
**\<suraeNoether>** yeah, and we can elaborate on that for folks who are interested as the week goes on
**\<sarang>** Sure
**\<suraeNoether>** or just later today :D
**\<suraeNoether>** earlier this week, I discussed some stuff regarding finding provably spent subsets of output keys
**\<sarang>** Oh and they're likely always going to be interactive, which is a bad ux
**\<suraeNoether>** sarang and i worked some of this out in person
**\<sarang>** Aye
**\<suraeNoether>** essentially the take-away is this:
**\<suraeNoether>** let's say some entity like the Monero Project wants to keep a blackball list of provably spent outputs
**\<suraeNoether>** to avoid mixing with future ring signatures
**\<suraeNoether>** let's say a user doesn't trust the Monero Project
**\<suraeNoether>** this user wants to verify all the computations used in computing that blackball list, to verify that the list is a complete list of all provably spent outputs
**\<suraeNoether>** the user loses trust in the Monero project if any provably spent set is found that is not on the list, or if any set on the list is not actually provably spent
**\<suraeNoether>** how long does the user need to take to verify a small section of the list? let's say only for transactions created in a single day?
**\<gingeropolous>** tree fitty
**\<suraeNoether>** well, the answer to that is in the binomial coefficient: to completely verify a day's worth of transactions (between 10^3 and 10^4 presently), with a ring size of r=7, requires presently at least 1000-choose-7 checks. this is... around 2e17 things to check. even in constant time, that takes a loooong time to check
**\<suraeNoether>** it's maybe doable, but to verify even a month's of transactions is like 4e27, and there's a certain point where verifiers can no longer check the list for completeness
**\<binaryFate>** I disagree the user loses trust if a provably spent set is not on the list (assuming he uses his own method, not the public sources for determining blackball list). The opposite would be more devastating.
**\<sarang>** I agree
**\<sarang>** We just want the user to trust that nobody is being censored
**\<sarang>** And verifying the list will be easy
**\<suraeNoether>** binaryFate: that's fair, what i mean is if the Monero Project is acting like a curating party for this blackball list, they are acting as a trusted third party, so there is a risk to the user if that third party is acting dishonestly
**\<sarang>** Each item can also have its rings listed
**\<sarang>** So the user checks her own copy of the chain
**\<binaryFate>** I think it's fine as long as it's advertise as a "best effort" and not claiming to be exhaustive.
**\<suraeNoether>** right, checking small pieces of this list for provable spent-ness is easy: verifying that the list is \*complete\* can be made "essentially impossible" by picking larger rings; and using this sort of heuristic, we (sarang and I) determined anything above ring size 45-ish is wasteful in this regard
**\<sarang>** You're all in luck. My plane is delayed
**\<gingeropolous>** is there a way to distribute the computation BOINC style? decentralize all the things and all
**\<sarang>** The initial computation
**\<sarang>** Yes
**\<binaryFate>** I would be way more comfortable to give up completely on the idea to claim we're exhaustive.
**\<sarang>** Then everyone can check their peers work
**\<suraeNoether>** but the key take-away here is that checking our blackball list for ring sizes beyond 3 is impractical for our project. we kicked the idea around of a sidechain that rewards finding provably spent sets on the main chain and proving their spent-ness on the side-chain to earn a PoW reward :D
**\<binaryFate>** There might be more tricks we did not realize yet.
**\<sarang>** We can do a small ring complete subset analysis once
**\<sarang>** And hardcode it
**\<suraeNoether>** yep
**\<sarang>** Optional user verification
**\<binaryFate>** Better to go with "best effort given computational ressources used and state of our understanding; anyone welcome to improve it"
**\<sarang>** Yes
**\<suraeNoether>** binaryFate: for sure, for sure
**\<sarang>** We will have the complete list for those small rings
**\<gingeropolous>** also seems reasonable given our constant releases and forks and checkpoints
**\<sarang>** We don't need to run it further
**\<sarang>** But I'm writing up a quick thing on it
**\<suraeNoether>** right, point is now we have a reasonable expectation of when to stop increasing our curation of the blackball list: ring size 4 is pretty much impractical already, ring size 5 is going to be... a... loooong.... wait...
**\<binaryFate>** that's totally ok
**\<suraeNoether>** on other fronts, I've been looking into zk-snarks and starks as a sidechain on monero, with no transparent pool (the "transparent" pool would be monero's base layer, and this starky side-chain would be the optional "shielded" pool on top of it). i'm looking into trust-free accumulators; i think there's actually a "whole new protocol" sort of thing going on using certain accumulator constructions (see
**\<suraeNoether>** https://link.springer.com/chapter/10.1007/978-3-642-31284-7\_14 for example)
**\<IsthmusCrypto>** Can these calculations be parallelized/cluster-ified?
**\<IsthmusCrypto>** (the blackball)
**\<suraeNoether>** yes they can
**\<gingeropolous>** im curious - is this calculation / processing done on a given state? Or is it done while building the blockchain? i.e., you could imagine a Sync 2.0 where the monero blockchain takes even LONGER because while your synchronizing, your own computer is curating its own blackball
**\<suraeNoether>** very parallelizable
**\<suraeNoether>** but huuuuge search space
**\<sarang>** Worth noting that verification is fast for the user
**\<sarang>** gingeropolous: I don't think we'd need to do a live version during sync
**\<sarang>** Damn. Planes radar altimeter is busted :(
**\<sarang>** No bueno
**\<suraeNoether>** gingeropolous: there are ways to make it faster to blackball in a rolling computation like that, but even for a single day's worth of blocks per batch, you end up having a huge space to search (which is why i selected a day above)
**\<gingeropolous>** and if the blacksync indeed does work, you could just prune them from the blockchain and the network eventually reaches a blackballed consensus because those outputs just don't exist... hrmmmm
**\<gingeropolous>** but it doesn't matter because once we're at ringsize 21 we can all go on vacation
**\<suraeNoether>** yeah, and syncing from scratch doesn't really solve the problem, because even short periods of time end up with huge search spaces
**\<suraeNoether>** if i had a single transaction to the blockchain with a single output, i need to check every known subset to see which share ring members with the new transaction
**\<IsthmusCrypto>** >\_\<
**\<sarang>** But that also means an attacker would have to do that too
**\<suraeNoether>** yes, precisely
**\<sarang>** So it becomes nbd
**\<sarang>** Under a certain threat set
**\<binaryFate>** If ultimately we're facing an NP-complete/NP-hard problem, we could quantify it and demonstrate no attacker can go beyond rings N, no more than we can.
**\<suraeNoether>** for complete lists, that is correct; a ring size of, say, 45-ish gets us close to "you have to brute force more things than particles in the universe" territory
**\<sarang>** Yeah that's the reasonable approach idea
**\<suraeNoether>** but you still have heuristic linkability; all this is merely to discuss proven spent-ness
**\<binaryFate>** This is all theoretical fun anyway, in practice it's assumed all this has no bearings on post-ringct tx anyway
**\<sarang>** Given high ring sizes yes
**\<binaryFate>** suraeNoether Monero always has heuristic linkability anyway... we're only very good at plausible deniablity
**\<suraeNoether>** yeah, the likelihood this happens on accident is vanishingly small, so someone would have to be doing it on purpose for it to really be a problem
**\<suraeNoether>** binaryFate: absolutely correct
**\<sarang>** And this is a fairly easy way to improve safety
**\<sarang>** Therefore worth doing
**\<suraeNoether>** ok, so this week i am finally going to pick a journal for peer review for thring signatures
**\<sarang>** And even doing it on purpose requires collusion anyway
**\<sarang>** And then the attacker can just outputs they control anyway
**\<IsthmusCrypto>** That would be an interesting idea, if a hostile node just returns outputs off the blackball list whenever queried for decoys
**\<suraeNoether>** IsthmusCrypto: yeah but why would it do that instead of using its own outputs? :P
**\<suraeNoether>** sarang and i go back and forth on it
**\<IsthmusCrypto>** Depends if the node is lawful evil or chaotic evil
**\<IsthmusCrypto>** lawful might use own outputs. Chaotic might just ruin it for everybody.
**\<needmoney90>** It would get noticed immediately
**\<needmoney90>** Or fairly quickly
**\<needmoney90>** If they used known black balled outputs
**\<needmoney90>** Exclusively
**\<IsthmusCrypto>** Is somebody watching out for that, or should MAP set it up?
**\<IsthmusCrypto>** Oh
**\<IsthmusCrypto>** because they're all so old
**\<IsthmusCrypto>** yeah, that would be obvious
**\<IsthmusCrypto>** smh
**\<IsthmusCrypto>** sorry, continue
**\<suraeNoether>** anyway, i don't think provably spentness is really the issue
**\<suraeNoether>** i believe that if you take the bipartite graph model and weight edges by output key age at the time of the transaction used it, we would re-attain the monerolink heuristic linkability model; what's funny about that, though, is that even if you were to optimize that guy to look for "probably" not provably spent outputs, you would still have such a large space to search through, you'd never quite be sure if
**\<suraeNoether>** there wasn't a more likely solution right around the corner
**\<suraeNoether>** i want to quantify that
**\<suraeNoether>** because i think heuristic linkability is more a danger issue for monero
**\<suraeNoether>** thank accidentally using provably spent ring members
**\<IsthmusCrypto>** ^^ agree
**\<suraeNoether>** later this week, i'll be reviewing the general M/N multisig thing
**\<suraeNoether>** is there anything else that folks want MRL to work on, bring up, discuss, etc? There will be news about the Denver Monero Conference later this week, I think.
**\<suraeNoether>** IsthmusCrypto and silur you guys have been working on stuff
**\<suraeNoether>** would you care to discuss it?
**\<IsthmusCrypto>** I can give a quick update on some of the #noncesense-research-lab projects
**\<IsthmusCrypto>** 1) Working on ways to automate identification of selfish/stubborn mining, since I have been doing it by visual inspection so far. One example written up so far.
**\<IsthmusCrypto>** 2) Doing a small study of nodes doubled up on IP addresses. Checked peer lists and found duplicates. This is a subtle type of centralization - if 20% of our nodes/miners are showing up over a handful of ProtonVPN addresses, then another DoS on the VPN would have the side effect of knocking a disproportional number of machines off the network.
**\<IsthmusCrypto>** 3)Vanity stealth addresses generation. If all of your personal outgoing transactions have the same prefix, then they will be indistinguishable from each other. This maximizes fungibility and eliminates headaches caused by how difficult it is to link your transactions on the blockchain. When you restore your wallet, use the same vanity code - the initial sync time decreases by orders of magnitude when your
**\<IsthmusCrypto>** wallet only needs to check outputs that obviously belong to it! /s
**\<IsthmusCrypto>** 4) Blockchain analysis to identify all MyMonero.com transactions that used high or paranoid mode. Partial writeup, but porting over to unsupervised ML methods to automatically pick out all the MyMonero txns from the main fungible cluster.
**\<IsthmusCrypto>** 5) A lot of work on MAP infrastructure by @n3ptune - both backend database work and some slick UI/visualization
**\<IsthmusCrypto>** And a misc pet project on timing how long it takes to sync the blockchain on different machines.
**\<IsthmusCrypto>** (end)
**\<suraeNoether>** #4 will be a paper that will be used as FUD; want to collab on an MRL bulletin and use our header and stuff so it's clear it's coming from MRL?
**\<silur>** quantum-vrf is on it's way I had major advances and even figured out that i can do it in a designated verifier setup. also I've sent you my slides on RTRS for HCPP prague, did you have time to review it?
**\<suraeNoether>** no, i have not, did you email it or mention it in chat?
**\<silur>** you = suraeNoether & sarang
**\<silur>** email it for both of you
**\<silur>** on your protonmail addr
**\<needmoney90>** IsthmusCrypto: for number 3, the vanity prefix can be deterministic with the private key as the seed, right?
**\<suraeNoether>** just found it; when is the talk?
**\<needmoney90>** So every new stealth address has a new prefix that can't be determined ahead of time without the private key
**\<silur>** october 3
**\<suraeNoether>** ok i will review it this week
**\<needmoney90>** That's actually super cool
**\<silur>** thanks
**\<suraeNoether>** for #3 that forbids sending to a subaddress
**\<suraeNoether>** since the subaddress recipient has to ask for a specific basepoint on the transaction key
**\<suraeNoether>** which sucks
**\<suraeNoether>** silur i am more interested in your quantum vrf to be honest :D hehe
**\<IsthmusCrypto>** @suraeNoether - yea RE #4 I’ll keep you in the loop. Don’t want to give FUD fodder, so I am really hoping that MyMonero will fix it soon....
**\<silur>** and I'd like your review on that I could send you the draft and we can eliminate my probably countless mistakes :)
**\<IsthmusCrypto>** #3 was just a joke, although it does reflect a real threat model (using a few digits to encode which output is the true spender, or maybe use a few digits to mark part of a hash of the private key to deterministically fingerprint transactions \*from\* the same account.
**\<IsthmusCrypto>** (would be malicious wallet software trying to communicate with no telemetry besides what is on the blockchain)
**\<needmoney90>** I think it could actually be used for fast sync
**\<needmoney90>** Without fungibility concerns
**\<suraeNoether>** endogenic ^ can't really do anything about the older choices, but we can patch that up moving forward
**\<sarang>** Hooray fixed plane. TTYL. Will be on after landing
**\<suraeNoether>** prefixing keys makes them distinguishable by prefix, so i'm not sure what the goal of the idea is :P
**\<needmoney90>** Surae, make the prefix deterministic
**\<needmoney90>** Increment private key by 1 every tx, hash it, truncate, and use that as the prefix
**\<needmoney90>** Without the private key you can't fingerprint the txes
**\<binaryFate>** I think you still get a different prefix for each output no?
**\<needmoney90>** That's a super naive method of course
**\<needmoney90>** You do binaryfate, but when scanning the chain you can look for the next prefix
**\<needmoney90>** Every time you find one, you increment and look for the next
**\<binaryFate>** I mean within the same transaction
**\<binaryFate>** And as you don't know the order, you can miss some
**\<needmoney90>** Ah, yes
**\<needmoney90>** If it's the same tx you can have a lookback
**\<needmoney90>** That's not a huge deal imo
**\<binaryFate>** true
**\<needmoney90>** Sorry for doing research stuff in the meeting, carry on guys. I'll bring this to the lounge.
**\<suraeNoether>** needmoney90: interesting... i need to thinka bout that. :P actually needmoney90 this is what the research meeting is for :D
**\<binaryFate>** I've been finally getting to work on an idea I had since a long time, I think I mentioned it here a couple of times.
**\<suraeNoether>** please go ahead!
**\<silur>** yea I missed that and interested :D
**\<binaryFate>** Broad idea is to study the age distribution of \*actual\* spendings of Monero users, with ultimately maybe proposing a better decoy output selection algorithm
**\<sarang>** Go on
**\<needmoney90>** If it's opt in, wouldn't the set of data we collect be skewed away from those who are super cautious about privacy?
**\<binaryFate>** Maybe best to explain the approach is a simplified example: imagine all rings are of size 2 (one real + one decoy). The "real" distribution is unknown, but the "decoy" one is known from what the wallet software is doing (restricted to certain block ranges where we are confident an overly large percentage of users are using the same version)
**\<binaryFate>** The result is a mixture, or (simplified) a weighted distribution. This is observable in the blockchain.
**\<binaryFate>** By using the observable bit, and the known part of the weighted distribution, I want to estimate the unknown one, aka the real spending habits
**\<binaryFate>** I'm writing an R package to do this, with an emphasis on graphically comparing what we should expect if users were spending "as we think" versus what we actually see from the blockchain
**\<binaryFate>** so whatever results I get be done again in the future with the same procedure
**\<binaryFate>** First results expecting soon (this week hopefully)
**\<binaryFate>** This will also allow to check the Miller et al. gamma distribution fitting btw, which afaik nobody really cross-checked (even though it will make it into the next hard fork)
**\<binaryFate>** (end)
**\<gingeropolous>** so is this asking which inputs are outliers of the distribution the wallet is using?
**\<binaryFate>** no, it's about the distributions, not the level of inputs. It's comparing "the situation we are modelling using [triangular/gamma] distribution" and "what we see in the blockchain"
**\<gingeropolous>** gotcha
**\<binaryFate>** Think of it as cutting through the noise to estimate the real spending habits, but it only gives you the distribution of it, no info on a single input
**\<binaryFate>** We rank highly on plausible deniablity :) I'm trying to improve on the distribution/heuristic thing. There was very little studies to come up with first the triangular one then the gamma one.
**\<binaryFate>** Anyway, I'll probably have a draft report in week or two to circulate.
**\<suraeNoether>** this is a very interesting idea
**\<suraeNoether>** i'm a little confused; where are you getting your data? your own wallet?
**\<IsthmusCrypto>** It doesn't need a ground truth. It's just actual distribution minus decoy selection algorithm expectation, right?
**\<endogenic>** IsthmusCrypto: fix the ability to use different ring sizes? the new apps and new web wallet do not allow you to pick, for that reason. i didn't expect we'd still have the old mymonero.com wallet up til now and totally forgot we have the mixin select there
**\<endogenic>** just let me know next time :)
**\<endogenic>** got so many things going on :
**\<binaryFate>** IsthmusCrypto correct
**\<endogenic>** will start to settle down soon i hope
**\<suraeNoether>** IsthmusCrypto: ahhhhh i see, yeah, if i understand it correctly, that's a wonderful treasure trove of useful data. :P
**\<suraeNoether>** oh man
**\<endogenic>** anyway IsthmusCrypto can you really tell they are -MyMonero- transactions?
**\<suraeNoether>** binaryFate: good freaking idea!
**\<endogenic>** or just that they have a high ring size?
**\<IsthmusCrypto>** The MyMonero fingerprint is based on the ringsize AND the decoy selection algorithm
**\<binaryFate>** suraeNoether simplified example again (ring size 2): wallet is known to use unifom for decoy. Blockchain shows distribution X (and we know it's 0.5 wallet distrib + 0.5 user real spending). We can compare the two and infere a lot about real user spending
**\<IsthmusCrypto>** The first is a good signpost to find candidates, then the second is the actual give-away
**\<binaryFate>** I'm just getting interesting results as we speak, but prefer to clear things a bit before sending to anyone
**\<endogenic>** IsthmusCrypto: just want you to know i've been motivating for the decoy selection algo change for a long time,
**\<endogenic>** i'm discussing it internally again to get it done ...
**\<endogenic>** we hve work on it
**\<endogenic>** need to stabilize and deploy..
**\<IsthmusCrypto>** Cool @edogenic. I haven't worried about it too much or rushed the research because the impending fixed ring size will remove half of the heuristic.
**\<suraeNoether>** binaryFate: more generally: if we use a distribution F to pick ring members, the extent to which ring members on the blockchain vary from F is directly related to the true signers... really great approach
**\<suraeNoether>** anyway
**\<suraeNoether>** okay, anyone else have anything they want to chat about?
**\<suraeNoether>** it's been a few weeks
**\<binaryFate>** yep, and it's directly quantifiable by the ring sizes too
**\<IsthmusCrypto>** Last thought - can we start recording MRL meetings alongside the other dev diaries? It would be good for accessibility and showcasing some of the best people/conversations in our community
**\<IsthmusCrypto>** If somebody can show me where/how, I can take care of uploading them.
**\<selsta>** IsthmusCrypto: they used to get uploaded
**\<selsta>** or did they?
**\<selsta>** anyway I plan on creating a IRC bot that auto uploads the meetings
**\<suraeNoether>** IsthmusCrypto: i usually throw the logs up on my github, but i have been lazy lately; i'll set aside an hour later today to upload all the ones I have
**\<suraeNoether>** if anyone wants to put them anywhere else, feel free, maybe we could throw them up on the getmonero.org page or something like that. i'll look into a few options
**\<IsthmusCrypto>** 👍 I started thinking about this when the person showed up claiming that fixed ring sizes hadn't been publicly discussed
**\<suraeNoether>** if anyone wants to take initiative and upload meeting logs that are missing before i get to them, that'd be a great contribution to MRL
**\<suraeNoether>** only so many hours in a day :D
**\<suraeNoether>** either way, i'll try to organize what i see available later today. my github is a mess
**\<IsthmusCrypto>** Cool, I was thinking I could upload them here? (If that seems alright and somebody shows me how or wants to take initiative and do it themselves)
**\<binaryFate>** go for it
**\<endogenic>** good idea
**\<IsthmusCrypto>** Do I just PR it to here? https://github.com/monero-project/monero-site/tree/master/\_posts
**\<suraeNoether>** i believe that is correct; moneromooo or luigi1111 ?
**\<selsta>** IsthmusCrypto: yes, but you have to convert the logs to markdown
**\<suraeNoether>** ok, I believe we are over an hour here, so we'll wrap this up
**\<suraeNoether>** any last notes/comments/concerns/questions?
**\<suraeNoether>** i'm expecting my cross-chain paper to be done by the end of the month, i think; it's actually a lot simpler than the multisig paper
**\<silur>** the cross-chain atomic swaps?
**\<silur>** not quite, I remember it had a much cooler name
**\<silur>** ring-confidential atomic swaps or something
**\<moneromooo>** No, to https://repo.getmonero.org/
**\<silur>** oh didn't even know about that thx

343
_posts/2018-09-24-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-09-24.md Normal file
View file

@ -0,0 +1,343 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-09-24
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<oneiric\_>** thanks for the ping :)
**\<scoobybejesus>** 👍
**\<binaryFate>** hi
**\<dEBRUYNE>** hi
**\<vtnerd>** hi
**\<MoroccanMalinois>** hi
**\<rehrar>** heyo
**\<suraeNoether>** allrighty
**\<suraeNoether>** Now that greetings are out of the way
**\<suraeNoether>** as usual, we are basically just going over what we've done last week and what we want to go over this week, and to open up the table for questions and suggestions
**\<suraeNoether>** but today i want to reverse the usual order
**\<nioc>** hmmm
**\<suraeNoether>** i want people who have questions or suggestions to be able to speak up at the beginning
**\<suraeNoether>** so they don't have to sit around hearing about groups etc before they are allowed to give us their thoughts
**\<suraeNoether>** nioc i knew i forgot at least one person :D sorry
**\<nioc>** np my comment was about the order
**\<suraeNoether>** so. \*crosses legs\* who has some thoughts for the MRL guys?
**\<sarang>** Anyone? Bueller?
**\<oneiric\_>** are cancellable signatures possible with monero?
**\<nioc>** I see that the BPs were just tweaked, are we all set now?
**\<silur>** you mean (un)denyable signatures?
**\<silur>** \*(un)deniable
**\<oneiric\_>** I mean, one is part of a multisig, but before the multisig is fully signed, can one cancel their part of the multisig?
**\<sarang>** nioc: a verification tweak, for a belt-and-suspenders approach to curve points
**\<suraeNoether>** oneiric\_: i don't think cancellability in the way you describe it is particularly necessary...
**\<suraeNoether>** if you bail on a multisig signing?
**\<suraeNoether>** no information is leaked; there may be a record of your communication between the other signers, though, and that's really the more dangerous part of things, from the point of view of IRL opsec
**\<oneiric\_>** ok, how else would you bail out after initially signing?
**\<suraeNoether>** and there isn't anything in the protocol that prevents you performing the multisig signing ceremony in a "bad" way, if htat makes sense
**\<suraeNoether>** you just stop
**\<suraeNoether>** if you mean "i want to retract a signature that has already been computed," I don't think that... is... practical...
**\<oneiric\_>** adds too many moving parts?
**\<suraeNoether>** uh, well, if it's already computed and can later be revoked
**\<endogenic>** maybe a type of tx which has two stages of confirmation.. during first stage, it could be canceled with another tx by same signer?
**\<suraeNoether>** if it's already computed and later can be revoked, does this mean you need a revocation signature in a later block that refers to the original signature? etc. i'm not sure exaclty how all of it would work
**\<suraeNoether>** and i'm not sure what the use case would be
**\<suraeNoether>** generally we want our transactions to be signed and done, for finality and liveness reasons
**\<suraeNoether>** retracting a transaction that you've already executed... I imagine that's maybe something that \*could\* be done on a lightning like system between honest parties without issue
**\<suraeNoether>** i can't think about how to implement it on the base layer without a lot of problems
**\<oneiric\_>** revocation would happen before tx is fully signed, use-case is for an automatic funding of an FFS wallet
**\<sarang>** there was a similar suggestion for a 2-of-3 with a trusted mediator
**\<suraeNoether>** ah; in that case, if you don't want to make the transaction, just \*don't finish signing it.\*
**\<suraeNoether>** if you already pre-signed it and haven't broadcasted it, then don't broadcast it and delete it
**\<suraeNoether>** if it's already broadcast? don't... don't do that?
**\<oneiric\_>** ok that makes sense. my thinking on this might not be the clearest. was thinking of people signing multisig to show support, but if something changes their mind before the tx is complete, being able to revoke their part of the signature
**\<endogenic>** people could show support by posting proof of funds
**\<suraeNoether>** ah, yeah, that's not necessary; their pre-signatures or partial signatures can't be used to construct a complete signature, so you show your initial support by participating in the first round of interaction, and you revoke your support, so to speak, by not participating in the second round of interaction
**\<oneiric\_>** oooo, that's way smoother, thanks suraeNoether :)
**\<suraeNoether>** i can think of another case, though, that could be helpful, and i'm going to state it so we start percolating on the idea in the back of our heads
**\<silur>** this might actually introduce some problems on blockchains
**\<suraeNoether>** let's say you relay a new transaction that can't be mined for 1440 blocks, and has a locktime of 2880 blocks, so that the soonest it can be mined is tomorrow and the soonest it can be spent is the day after... should someone be able to broadcast a revocation of that transaction in the next 1440 blocks so that miners don't include it? the answer, I think, is yes, this is possible, but I also think that there
**\<suraeNoether>** isn't a good way to \*enforce it.\*
**\<suraeNoether>** so it'd be, at best, asking miners politely to not mine the transaction
**\<suraeNoether>** there could be some workarounds maybe, but we'll think about it and move onto other topics
**\<suraeNoether>** nioc had a question on the BP tweaks, but sarang you didn't mention if we anticipate more tweaks or not
**\<suraeNoether>** you just said what they were
**\<sarang>** I don't anticipate others
**\<suraeNoether>** cool
**\<suraeNoether>** anyone else have any other questions?
**\<endogenic>** does it make sense to do questions also after updates given?
**\<sarang>** sure
**\<suraeNoether>** cool. Last week I worked more on my Fulmo Network (lightning in esperanto) paper, and I anticipate making it available for public perusal later this week or early next week... I read through Sarang's DLSAG paper, which is important to the Fulmo paper, and I'm going through donut and Pedro Moreno-Sanchez' similar paper (in prep, but we got an early copy earlier this year)
**\<suraeNoether>** I'm intending on reading hte M/N multisig thing; I haven't gotten to Silur's slides for HPCC yet
**\<suraeNoether>** (I'm so sorry)
**\<silur>** np, I had help from sarang
**\<suraeNoether>** I also have had some lovely conversations with Dr. Shuhong Gao at Clemson University regarding the possibility of some informal collaborations between MRL and Clemson in the future, which would be fun and great
**\<sarang>** nice
**\<endogenic>** coolio
**\<oneiric\_>** right on
**\<suraeNoether>** I also am waiting on a few more quotes from venues for the Monero Konferenco, named by rehrar (I kind of like Monero in the Mountains, or Ring Signatures on the Rockies, but tbqh, Monero Konferenco has a Mortal Kombat feel to it, and I kinda love it)
**\<suraeNoether>** The remainder of this week? More DLSAG, more fulmo, more research into accumulators... OH OH OH
**\<suraeNoether>** I also have a question for the community, but I'll wait until Sarang has gone and anyone else who wants to contribute
**\<oneiric\_>** dun dun dun dada dun.. Monero Kooooonferenco!!
**\<sarang>** Sure
**\<endogenic>** can we pls work in some lotr references like Council of Elrond?
**\<suraeNoether>** NO
**\<sarang>** Wrote up a draft of a tech note on generalizing our knowledge about provably spent outputs
**\<sarang>** mainly because it covers several other ways we test for this, and shows why it's a hard problem (for us and adversaries)
**\<sarang>** Tweaking the DLSAG stuff based on suraeNoether's comments (and his desire to work the foundations into his work)
**\<sarang>** There was a late tweak to BPs to handle some ways we were doing a scalar conversion that were subtly incorrect
**\<spaced0ut>** oneiric\_, always dressed and ready for Mortal Kombat
**\<sarang>** Also: I was asked to present on attack surfaces and privacy research at a Kyiv hackathon... wondering the group's thoughts on me taking like 5-6 days to do this
**\<sarang>** I like the hackathon approach to getting the word out
**\<oneiric\_>** that sounds like a very cool thing
**\<sarang>** Yeah, it's a big time investment but fortunately I work remotely anyway, amirite?
**\<suraeNoether>** will you be needing financial support for it, or would those organizers be compensating you?
**\<nioc>** https://forum.getmonero.org/7/open-tasks/90857/sarang-re-present-at-kyiv-hackathon
**\<sarang>** They're compensating flight and some hotel. With local transportation, M&IE, and hotel, it'd run about 9 XMR community funding
**\<nioc>** cheap
**\<suraeNoether>** oh hehe
**\<sarang>** Would be nice to reach out to that part of the world, getting technical folks thinking about and hacking on Monero
**\<sarang>** Anyway, open to comments
**\<sarang>** it'd be in a couple of weeks
**\<endogenic>** do you know anyone there?
**\<sarang>** I believe msvb is also speaking there about hardware
**\<sarang>** This group actually approached us at our defcon village
**\<silur>** oh this reminds me, david chaum will be present at HCPP
**\<silur>** \*\*shittin' brix\*\*
**\<oneiric\_>** seriously?! so excite!
**\<suraeNoether>** Sarang and I were curious about whether the community would want to fund us for the Berlin conference, but I'm having a hard time finding the website. i'll bring it up next week
**\<sarang>** I don't think I'll be doing Berlin
**\<sarang>** I'm all traveled out
**\<suraeNoether>** Does anyone else have any projects they want to discuss?
**\<sarang>** and the timing is not great
**\<sarang>** I'm working on some other minor stuff about curvepoint checking
**\<sarang>** small optimization stuff
**\<endogenic>** dang, i wanna go surae
**\<silur>** I got into a spaghetti of proofs on my quantumVRF not much advance there
**\<endogenic>** i'll keep an eye out
**\<suraeNoether>** Another bit of work; sgp and I are contributing to a friend's educational outreach project. the idea is to provide a privacy breakdown of all the different privacy coins out there, at a level that someone with some computer science and/or math experience can understand, but without requiring a Masters or PhD to get
**\<suraeNoether>** I'm not sure exactly how public that is, but I plan on putting a few hours into some writing on that later this week, especially in the Monero sections
**\<endogenic>** nice
**\<sarang>** oh interesting
**\<sarang>** Well I take it there's no big opposition to speaking to Kyiv
**\<vegasbaby>** It would be great to see an honest and even approach to comparing the major privacy currencies
**\<suraeNoether>** oh, sarang, I'm sorry, I didn't mean to switch topics; I got the sense that no one in the room objected
**\<suraeNoether>** but I'll stfu for a moment
**\<sarang>** Heh no, I think people were done commenting
**\<endogenic>** it's a risk..
**\<sarang>** ?
**\<endogenic>** but i dont think anyone objects to the benefits
**\<sarang>** Risk in what way
**\<rehrar>** you could be hit on
**\<sarang>** Oof
**\<sarang>** A risk worth taking I'm sure
**\<endogenic>** well, suppose you traveled with a partner…i think it's reasonable to say you'd be safer
**\<sarang>** That isn't the case tho
**\<suraeNoether>** you can always be \*safer\* by staying home
**\<suraeNoether>** anyway
**\<oneiric\_>** is Kiev that dangerous?
**\<suraeNoether>** my understanding is that kyiv has very low levels of violent crime except when alcohol is involved. :P
**\<binaryFate>** I was there, in general it's ok. But there has been a case of a CEO of a crypto company kidnapped for a ransom
**\<sarang>** Well I'm not overly concerned
**\<sarang>** From what I've heard
**\<sarang>** I'm a lowly mathematologist
**\<rehrar>** sarang you need to let me know about the cards so I can get you necessary files before you go
**\<sarang>** Just a mere scientician
**\<IsthmusCrypto>** \<\< opens FFS page to fund a bodyguard for @sarang in Kiev >>
**\<IsthmusCrypto>** @suraeNoether - that document sounds great, and I'm looking forward to reading it. I love to see cross-project collaborations like these. Building bridges and knowledge sharing makes everybody stronger.
**\<sarang>** Should I request the FFS get opened for that event travel?
**\<suraeNoether>** i belive you should, sarang
**\<sarang>** It's quite new but the event is soon
**\<crCr62U0>** Are there any longterm research tasks that can be done by independent individual except find some vulnerabilities & exploit them?
**\<sarang>** Hark! Requesting eventually FFS migration
**\<sarang>** Yes
**\<endogenic>** what if sarang were held for ffs ransom? :P
**\<rehrar>** sarang: checking with Devin no about migration. He's doing a lot of good work. QR codes will be implemented, an API, and more
**\<endogenic>** i know i would donate
**\<endogenic>** crCr62U0: yes absolutely
**\<vegasbaby>** wait what
**\<vegasbaby>** Donations for FFS rework?!?
**\<vegasbaby>** Plz let me give my money :D
**\<suraeNoether>** okay, last topic I want to discuss is... a little out of the blue, and Sarang and I want some input from the community regarding a Conflicts of Interest Policy for MRL, or some sort of ethics policy....
**\<suraeNoether>** We really bend over backwards to state in our papers that our research is paid for in Monero, for the same reason that doctors funded by pharma companies \*are ethically obligated\* to disclose those conflicts of interest.
**\<suraeNoether>** However, as everyone is aware, there is an epidemic of unethically plausible reporting.
**\<suraeNoether>** We see very often that Coin X is being described in Magazine Y, and they interview researchers P, Q, and R, some of whom are paid in Coin X, and this conflict is not described in the article.
**\<crCr62U0>** I'm asking about longterm in order to have time to learn something; It's difficulty to be successful in shortterm tasks due to lack of experience and mind abilities.
**\<suraeNoether>** we suspect that putting out such a policy, even though it is totally nonbinding, since we are a headless entity with no authorities... we think that putting out such a policy would goad other coins to do something similar, to put out their own ethics policies
**\<crCr62U0>** \*to be competitive(successful) among others
**\<suraeNoether>** crCr62U0: your question about research tasks that the community can contribute to... let's get back to that in a moment. we are overflowing with problems to solve and infrastructure in the coding department that would make our research lives easier
**\<endogenic>** crCr62U0: yes, to contribute you need to know a little about monero first, then you'll find some problems there. one of them is replacing ringsigs with something better than zksnarks
**\<endogenic>** suraeNoether: sounds good to me
**\<suraeNoether>** so if you need something to do, we can definitely point you in a direction none of us currently have time for :D
**\<binaryFate>** suraeNoether it's a great idea. Regardless of what other coins are doing, making the ethic already there in Monero/MRL more visible and clear to the outside world is a net positive.
**\<suraeNoether>** i agree, binaryFate
**\<sarang>** As to research, it's problematic
**\<sarang>** There's a big learning curve to do big bluesky work
**\<sarang>** but there are smaller projects that someone doesn't have to be a broad expert to complete
**\<sarang>** or at least participate in
**\<sarang>** e.g. I'd love to abstract more of our cryptographic functions properly so we can move to more standard and tested libraries
**\<suraeNoether>** can we talk about the never-ending list of to-do in a moment? it's a big list
**\<sarang>** sure
**\<suraeNoether>** okay, so my question to the community is
**\<IsthmusCrypto>** @suraeNoether I hadn't thought about the disclosure before, and I think you have a good point. And while the headless entity cannot enforce it, it does protect the headless entity.
**\<IsthmusCrypto>** In the unlikely case that some Monero dev or researcher presents unethically without full disclosure, we can point to that as a violation of community policy. Meaning that the person was communicating in a sketchy way, and not the community acting in a sketchy way.
**\<sarang>** It also helps guide other projects to the same idea, I hope
**\<sarang>** and is a statement about our intent to do honest work
**\<suraeNoether>** so my question to the community is simple: what do we want to see in our ethics policy?
**\<sarang>** I think the biggest thing is disclosure of funding specifically tailored around research/dev for Monero
**\<sarang>** e.g. "Sarang Noether receives Monero community funding, paid in XMR, to do full-time R&D for the Monero Research Lab, a workgroup of the Monero Project"
**\<suraeNoether>** i think MRL researchers should not go off and start their own coins while working at MRL, even if they do so fairly
**\<sarang>** ehhhhh
**\<sarang>** should it be that broad?
**\<sarang>** What are our ultimate goals for it?
**\<silur>** woopsie
**\<endogenic>** that seems a little over reaching to me
**\<endogenic>** i think at the last it has to require disclosure of material facts
**\<endogenic>** at the least
**\<suraeNoether>** maybe not, but my goal in that regard is: i don't want someone claiming they work for/at MRL while they are shilling/pumping their own project
**\<sarang>** I would care to know if a Monero researcher does have their own coin
**\<suraeNoether>** okay, if we stick with disclosure, i'm cool with that, too
**\<suraeNoether>** maybe
**\<silur>** oh yea that policy was actually active in ethereum foundation too
**\<sarang>** I think it's all about keeping people informed
**\<suraeNoether>** i don't know
**\<sarang>** silur: linky?
**\<endogenic>** if facts are visible then the community can handle things on their own
**\<silur>** to the policy mail? :D
**\<sarang>** I like that people don't need to question our motives for doing this. And I think the policy should continue to reassure people of this
**\<sarang>** silur: yeah, or whatever the policy is
**\<sarang>** I know nothing about it
**\<silur>** I don't know whether ming (that time she was our CEO) published it anywhere
**\<sarang>** Do we know what other projects are doing?
**\<sarang>** Maybe that's a start before drafting our own
**\<silur>** we just received collectively a mail about that
**\<sarang>** See what's out there, if anything
**\<sarang>** Take what we like from it, avoid what we don't
**\<sarang>** I don't want fall into the "not invented here" trap. Let's build on it
**\<IsthmusCrypto>** This is very thought provoking conversation. I don't think a hard ban is quite appropriate - and I don't mind if one of the MRL researchers makes small contributions to other currencies as long as it's not interfering with completion of MRL duties. (see building bridges comment from earlier). But there should be some constraints/transparency.
**\<silur>** I'll look it up sarang
**\<sarang>** Well, and researchers \_do\_ collaborate
**\<sarang>** We don't want to discourage that
**\<sarang>** We should encourage it, with disclosure
**\<IsthmusCrypto>** And I do like the ideas in the brief example statement from @sarang regarding conflict of interest disclosure. I think that "supported by funding from the Monero community" is more important than "paid in Monero"
**\<sarang>** IsthmusCrypto: agreed
**\<sarang>** generally
**\<silur>** totally agreed
**\<suraeNoether>** agreed on that too
**\<sarang>** I don't even care about constraints. If the community doesn't like what the disclosure implies about someone's conflicts, that's up to them to decide
**\<sarang>** But give people open information so they can decide for themselves how to interpret someone's motives or actions, eh?
**\<rehrar>** My recommendation to you both would be to draft a document and present it to the community rather than trying to do something by community design
**\<sarang>** Yeah, based on what we know from elsewhere
**\<rehrar>** And if there are high quality suggestions to be added, they will filter to the top
**\<sarang>** We're surely not the first open-source project to consider this
**\<rehrar>** use your best judgement and include what you think should be there. The community can fill in gaps after it is proposed
**\<sarang>** righto
**\<silur>** basically EF did it in a way that it was okay to do advising and help in other coins under your own name but only that
**\<rehrar>** in the end, MRL is its own workgroup, and is free to set its own internal rules
**\<silur>** so the whitepaper shouldht have \_MRL member\_
**\<silur>** it worked quite well
**\<suraeNoether>** rehrar: I've been working on the draft for a few days, and I wanted to seek input to see if a high signal-to-noise ratio on a specific topic floated during the discussion before the document is really ready to show off to people
**\<endogenic>** "MRL is its own workgroup" <<<
**\<sarang>** Well, that's another question entirely
**\<sarang>** there's no legal status to MRL... anyone can claim to be "part of it"
**\<silur>** sounds quite contradicting from me for I violated that policy ^^"
**\<rehrar>** I had spoken with sarang a bit about formalizing the MRL a little bit, just so random people can't nab the name "MRL Researcher" and use it on stuff when they don't contribute
**\<endogenic>** i don't think so sarang
**\<sarang>** endogenic: they can, it's only based on reputation really
**\<sarang>** and participation
**\<sarang>** and that reputation is basically all internal to the project
**\<endogenic>** i mean no legal status
**\<rehrar>** this arm of Monero is honestly the one that would be under the most scrutiny apart from the coding, so I think it's quite important
**\<IsthmusCrypto>** (that reminds me, I will be uploading meeting notes once I get a break from a current metaphorical tsunami at work)
**\<endogenic>** historically, the community has either hired Noethers directly or the Noethers have published something for monero that the rest of the Noethers agree on .. is that incorrect anywhere?
**\<endogenic>** i would have to speak to an attorney or two about legal status, copyright, etc
**\<suraeNoether>** endogenic: no, I had almost zero interaction with shen regarding ringct. :P MRL is even more headless than your description
**\<sarang>** At the very least, we have no formal guidelines for putting "Monero Research Lab" as a title/tagline
**\<endogenic>** yeah but who published his paper on MRL
**\<suraeNoether>** i dunno, fluffypony?
**\<sarang>** It just really hasn't been tested by anyone
**\<sarang>** (yet)
**\<rehrar>** I would like to make a proposal to do a weak formalization of MRL. Basically acknowledging sarang and suraeNoether as the leaders of the workgroup, whether or not they are paid by the FFS.
**\<sarang>** I assume core team put it up
**\<endogenic>** exactly.. so it's in the first category
**\<fluffypony>** anyone can be part of MRL
**\<fluffypony>** it's self-assembling
**\<suraeNoether>** rehrar: I feel like we're treading into governance territory, and if we are doing that, i would like a title like "Paladin Exemplar" or "Necrophage Elitus"
**\<sarang>** I understand what rehrar is getting at though
**\<sarang>** We're very public-facing
**\<suraeNoether>** yes, for sure
**\<sarang>** I'd like "Man About Town" for my title
**\<sarang>** Right now it's based on your reputation w/in the community. But people outside the community don't track that
**\<suraeNoether>** okay, let's put the ethics document on the side burner, we'll get back to it next week; in the meantime, if anyone doesn't object, i'm going to just go tattoo my pgp keys on my forehead and that'll be MRL's authentication
**\<rehrar>** my proposed formalization doesn't put anything on membership (anyone can join and contribute) but does put a bit of a hierarchy in terms of "these people are putting out random stuff, suraeNoether sarang, is this MRL work?"
**\<sarang>** nor should they
**\<suraeNoether>** rehrar: understood
**\<rehrar>** exactly sarang
**\<fluffypony>** "putting out MRL work" == merged into the research-lab repo
**\<rehrar>** doing something like this is saying the community has vetted and found these two, so you don't have to vet
**\<fluffypony>** and those merges are controlled
**\<fluffypony>** the same way anyone can work on Monero's source code
**\<sarang>** True, but is the concern more about claiming representation from others rehrar?
**\<fluffypony>** doesn't mean we'll merge something that introduces a backdoro
**\<fluffypony>** \*backdoor
**\<rehrar>** fluffypony: or will we...?
**\<binaryFate>** backdoro is esperanto for backdoor
**\<fluffypony>** lol
**\<rehrar>** sarang: unsure yet. Admittedly the concern is vaguely defined, so no action should be taken as of now until the "threats" are better defined
**\<suraeNoether>** we'll start with the ethics policy document
**\<silur>** I'll dig up our EF version and forward to suraeNoether and sarang
**\<sarang>** ty silur
**\<suraeNoether>** one simple method is for Sarang and I to publish an accumulator of PGP keys that we consider "valid" MRL keys; when you ssee a document signed wiht a key, you check if it's in the public accumulator. If it is, great, you know we approved it. If not, you know someone is tryign to push out an MRL paper early (or just lying about their own credentials)
**\<suraeNoether>** but we can think about it more between now and next week
**\<suraeNoether>** i like the idea of a simple ethics/conflict of interest policy
**\<sarang>** We really should sign those
**\<IsthmusCrypto>** I'd be happy to put on my UncagedPotential hat and review any drafts of the policies.
**\<fluffypony>** git already supports GPG signing
**\<sarang>** or at least post to github with signed commits
**\<sarang>** fluffypony: lol, read my mind
**\<fluffypony>** I don't think you need to over complicate it beyond that
**\<sarang>** good point
**\<suraeNoether>** yeah, i agree
**\<binaryFate>** was there any such attempt of claiming MRL relations for unethical or random reasons? Or is this all abstract discussion?
**\<suraeNoether>** binaryFate: when sarang and i met endo in person at the beginning fo this month, we discussed the general phenomena i described regarding too-plausible reporting that doesn't display conflicts of interest. nothing about \*monero\* right now is drifting us in that direction, it was just an idea we had about the overall cryptocurrency space.
**\<sarang>** I think binaryFate means the MRL formalization comments
**\<suraeNoether>** right, all of this is coming from that one discussion; the answer is no, there have not been any attempts to impersonate me or sarang yet, afaik
**\<sarang>** Shall we address the idea of to-do?
**\<sarang>** it was brought up earlier
**\<silur>** yea I was waiting for that :D
**\<sarang>** (we are over time, if anyone needs to go)
**\<suraeNoether>** here is our current "road map" with some things ticked off. It could be slightly out of date. https://github.com/monero-project/research-lab/issues/29
**\<suraeNoether>** in general, I would really really like a transaction tree visualization tool
**\<suraeNoether>** or something that scrapes statistics from teh monero blockchain in genreal
**\<suraeNoether>** From the cryptographic point of view, we are interested in replacing ring signatures with something that has decently large anonymity sets, no trusted set-ups (say ZK-STARKs)...
**\<suraeNoether>** but the replacement must be sufficiently efficient in both space and verification time that total time-to-download-and-verify the blockchain (an up-front cost for new members to join the network) is manageable over the next several years, and preferably should also have greater security claims than computational unforgeability.
**\<sarang>** More pointedly, I have been thinking lately about the state of our current primitives and their implementations
**\<sarang>** IMO we should be offloading to tested libraries far more
**\<suraeNoether>** i agree with that statement, and anywhere that we aren't, should be filled with unit tests.
**\<suraeNoether>** From a stochastic processes point of view, consensus models lack a rigorous description as "adversarial" or game-theoretic, such that participants have some control over the distribution of the outcomes, financial interests, and payoffs, etc. If you are a statistics sort of person, that could be fun.
**\<suraeNoether>** One interesting thing that is almost a computer-science exercise and could land anyone "on the map," so to speak, would be to place the Zerocash Sapling ZK-SNARKs inside the bulletproofs of Bunz, Bootle, Boneh, et al.
**\<suraeNoether>** Anyone who can manage to do that will essentially see money thrown at them to work on these projects forever, and will see their work implemented live on multi-billion dollar currencies within a year.
**\<endogenic>** we should put this in a doc on a repo or somethin
**\<suraeNoether>** From an applied algebra point of view, we are more-and-more interested in RLWE settings and their post-quantum resistance properties, and personally, I've recently been reading about using Euclidean rings to construct untrusted accumulators.
**\<silur>** yaaaay
**\<suraeNoether>** oh, i need to publish the Q4 roadmap by the end of this month, endo, and i'll be including this stuff in there
**\<silur>** I was actually just wondering whether my RLWE fanatism will be extingiused here
**\<silur>** with the roadmap
**\<suraeNoether>** i copy-pasted some of the list above from my communications with Clemson recently. :P
**\<sarang>** These should be open issues on github probably
**\<suraeNoether>** the roadmap is an open issue
**\<suraeNoether>** and it consolidates all this into a list
**\<silur>** suraeNoether: around may we had a brief discussion about how bulletproofs could be even more efficient with RLWE
**\<silur>** we should really see that to the end
**\<suraeNoether>** silur: https://eprint.iacr.org/2018/637 for some RLWE fully homomorphic stuff :P
**\<suraeNoether>** i don't recall that discussion, and i haven't thought \*at all\* about how LWE or RLWE could be used in bulletproofs
**\<silur>** these cipher expansions are supa-dupa small O.o
**\<silur>** thanks for tha paper
**\<suraeNoether>** okay, i think this was a pretty good meeting. Anyone have objections to beginning the closing ceremony of our research meeting?
**\<silur>** also will you have some time to share your leads on this RLWE untrusted accumulator stuff? I don't really see the connection now
**\<IsthmusCrypto>** I have a Q or two about the notes at the GitHub, but that can happen post-meeting
**\<suraeNoether>** no, no, the untrusted accumulator is with euclidean rings (like polynomial rings) https://kodu.ut.ee/~lipmaa/papers/lip12b/cl-accum.pdf
**\<suraeNoether>** the FHE encryption uses RLWE
**\<suraeNoether>** IsthmusCrypto: eh, the closing ceremony is "people gradually losing interest and walking away from their computers" so fire away buddy

197
_posts/2018-10-01-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-10-01.md Normal file
View file

@ -0,0 +1,197 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-10-01
summary: Surae work, Sarang work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / sarang
---
# Logs
**\<sarang>** Hello everyone; greetings abound
**\<hyc>** hola
**\<sarang>** suraeNoether informs me his flight was delayed and he plans to join late if at all
**\<sarang>** Let's briefly go around the (apparently small) table and review anything of interest from this past week
**\<sarang>** I have finalized a few small lingering projects, like a couple of papers: one on dual-key signatures, and another on the set theory of spent outputs
**\<silur>** hope I'm not to late hi all
**\<oneiric\_>** jai
**\<sarang>** and am returning to larger projects like sublinear ring sigs that were delayed due to the network upgrade prep
**\<sarang>** I have some other news regarding external research, but I will save that until others speak about their work
**\<silur>** yaaay sarang on rtrs \\o/
**\<sarang>** On behalf of suraeNoether I'll say that there is a draft of an MRL ethics and conflicts statement; comments requested: https://github.com/monero-project/research-lab/issues/31
**\<sarang>** We want to make sure that our contributors are clear about their conflicts, which is sorely lacking in our field and especially in other projects
**\<sarang>** hyc or silur or oneiric\_ anything of interest?
**\<sarang>** (apologies for my slow responses due to shitty wifi)
**\<hyc>** we had a decent discussion in here about PoW algorithms
**\<sarang>** yes indeed, so good that it was relayed to reddit
**\<hyc>** and the threat of finding shortcuts in e.g. RandomJS
**\<sarang>** hyc what are your conclusions from that discussion?
**\<hyc>** there's 2 considerations - one is that long sequences of source instructions could be automatically recognized/templated
**\<hyc>** and these templates could then be condensed into ASIC blocks
**\<sarang>** That decreases quickly due to randomization, no?
**\<sarang>** ideally
**\<hyc>** the other is that if the generated code has nonuniform difficulty, a miner could detect harder nonces and skip them
**\<hyc>** and presumably choose only easy nonces, and crunch them much faster than a vanilla miner
**\<hyc>** I suppose this is playing with the law of averages; if you only search 1/1000th of the search space, and can do it 1000x faster, you should be able to beat regular miners
**\<hyc>** sarang: yes, ideally the randomization prevents recognizable sequences from recurring
**\<sarang>** (we've been to the moon something like 7 times, but wireless networking is apparently impossible)
**\<sarang>** Does this affect your design principles going forward?
**\<hyc>** these 2 points are actually in opposition: we could guarantee perfectly uniform difficulty
**\<hyc>** but that requires limiting the possible generated output to some strictly defined parameters
**\<hyc>** and that will make the output templatable :P
**\<sarang>** What if we switch to some kind of "hash-function" with a uniform output?
**\<sarang>** lololol
**\<silur>** I dig into multilinear pairing in lattices to form a PQ-HIBBE. Also I'll make sure to follow this guide @sarang at HCPP, originally I didn't even want them to write MRL below my name :D
**\<silur>** but I do have some interest conflicts and make that clear in my interview
**\<sarang>** There are no formal standards to claiming MRL as a byline, but including it should imply that the main MRL peeps are in agreement
**\<silur>** I don't know wheter this actually applies to those not funded by the community?
**\<sarang>** and typically we only publish under MRL when we do releases to the main site
**\<sarang>** If you're publishing on the side, I would personally recommend not including such a byline
**\<sarang>** I'm often careful to say that I "work with MRL", not "for MRL"
**\<sarang>** since nobody works "for MRL"
**\<silur>** publish like research papers or software?
**\<sarang>** anything
**\<sarang>** People may attribute a certain level of researcher consensus to anything bearing The Name
**\<sarang>** Our six papers on lab.getmonero.org are probably the only "official-ish" papers we have out
**\<sarang>** This is all my opinion, btw
**\<sarang>** I don't speak for anyone else
**\<endogenic>** "People may attribute a certain level of researcher consensus to anything bearing The Name" well put
**\<sarang>** e.g. when I speak, I have a whole slide stating that I don't formally represent MRL or Monero in my talks
**\<silur>** this is kinda gödelic :D
**\<endogenic>** hyc: can we find anyone to run those simulations?
**\<silur>** yea I should include that in my HCPP slide too
**\<sarang>** If we were a formal organization I think it would be different, but since we're a loose group that has a certain amount of sway, I want us to be hella careful about representation
**\<sarang>** I don't even include the MRL logo
**\<hyc>** endogenic: nobody has contacted me yet. I'll have some time to set it up myself after next week
**\<oneiric\_>** is this similar to usual "these are my opinions not my employers" disclaimer?
**\<sarang>** except at the end to include a link to it for people to see
**\<sarang>** oneiric\_: basically
**\<sarang>** "All views in this presentation are those of the author, and do not necessarily represent those of the Monero Project, Monero Research Lab, or their associated communities or contributors."
**\<sarang>** Media doesn't know what our loose group actually means
**\<oneiric\_>** :) much formal
**\<sarang>** I don't blame them, but I also don't wanna muddle things
**\<moneromooo>** "Any inference you make are you own problem"
**\<sarang>** lol
**\<sarang>** Anyway, silur you are free to do as you wish, these are solely my views =p
**\<silur>** but I totally agree so I'll include this in my talk and iterview too :)
**\<sarang>** Yes, especially for interviews
**\<sarang>** make sure they know you speak only for yourself
**\<sarang>** the ethics statement draft specifically addresses this
**\<hyc>** "I thought we were an autonomous collective"
**\<sarang>** yeah, but media assumes we're some devious entity
**\<silur>** there was one time when after the interview they published me as a monero developer even though I stated in the recording that im not :/
**\<sarang>** I always keep in mind not to say anything to a journalist that I'm not comfortable having twisted beyond recognition =p
**\<sarang>** lol hyc I totally missed your reference :(
**\<sarang>** So hyc continues his design work toward ASIC-proof random code
**\<sarang>** silur wades the murky waters of cryptofame
**\<sarang>** suraeNoether waits patiently at an aeroport
**\<sarang>** As was discussed yesterday, I received some paper drafts from external researchers
**\<endogenic>** "I'm not comfortable having twisted beyond recognition" i know that feel
**\<sarang>** they basically duplicated all our blackballing and set theory work
**\<sarang>** formalized it quite nicely
**\<sarang>** and plan to publish
**\<sarang>** As a professional courtesy I can't share the papers themselves, but they contain no shocking results
**\<oneiric\_>** did they say if they would cite MRL?
**\<sarang>** I'm drafting a response to them, asking them to acknowledge that we already knew all this
**\<oneiric\_>** nice
**\<sarang>** I assume the cryptomedia will latch onto this, just like the other shitpapers about "output attacks" we already knew about
**\<sarang>** Granted, this paper is really quite good
**\<sarang>** I have a few quibbles about how they present things
**\<sarang>** If anything, I'm peeved that all these academicians work in their silos and don't bother asking "hey, did you folks already do this work?"
**\<sarang>** and then we're left on the defensive, fielding annoying questions
**\<sarang>** My response passive-aggressively says that I wish they would have contacted us, so as not to duplicate other work and waste their own time
**\<sarang>** I hope they agree to collaborate with us, and not claim that their work was unknown
**\<sarang>** I'll share my response before I send it
**\<sarang>** They do have a nice algorithm for identifying more spent outputs; it's one I also came up with but never finished coding
**\<hyc>** perhaps we don't need to press so hard on that point - it's good to have independent reproduction/confirmation of our work
**\<sarang>** I agree on that point; I only ask them to change the wording a bit
**\<sarang>** so as not to unintentionally mislead readers
**\<sarang>** and their results essentially mirror our blackball results
**\<sarang>** so that's good
**\<sarang>** And keep in mind that ideally, scientific reproduction is done with full acknowledgement to other work, with comparisons
**\<sarang>** I get that they only looked into published former work, but not bothering to reach out strikes me as lazy
**\<sarang>** I'd like researchers to stop doing that
**\<sarang>** Any questions/comments regarding this?
**\<hyc>** agreed
**\<hyc>** this is open source, you're supposed to communicate with the community
**\<sarang>** Yeah, it's a weird intersection between the academic community and the OSS community
**\<sarang>** But hey, hopefully these folks continue to work with us; they did great analysis
**\<oneiric\_>** I saw moneromooo jokingly bring up an smt solver. how hard/useful would plugging in a blackball finding algo into an smt solver?
**\<sarang>** unclear
**\<sarang>** We already have algorithms to catch all spent sets up to whatever size our computers can do
**\<sarang>** So for the upcoming week, I'll be working with these researchers, perhaps integrating their/my algorithm into code (unclear if it's actually that useful), and continuing bigger projects
**\<sarang>** I'm sure new things will start on fire that will require attention =p
**\<oneiric\_>** awesome, thanks sarang
**\<sarang>** One thing of future interest: Tari Labs paid travel for suraeNoether and endogenic and I to do an in-person research session in Nashville, and they'll be funding such a thing in November again
**\<endogenic>** Tari Labs didn't pay for my travel
**\<sarang>** Ooh true, thank you
**\<endogenic>** they did take us to a few nice dinners though :)
**\<endogenic>** they being Naveen
**\<sarang>** There was no additional stipend-type funding, and they do not set research directions
**\<sarang>** But are supporters of MRL and Monero
**\<endogenic>** and actually technically I guess I paid for hotel :)
**\<sarang>** I wanted to make this clear for transparency... they have also offered to bring up to 2 others to such a meeting as we see fit
**\<sarang>** In-person research is incredibly effective, and I like the idea
**\<sarang>** suraeNoether says he has a researcher in mind who has interest in zk-stark applications, but has not previously worked with MRL
**\<sarang>** I don't know the person and have no opinion either way about bringing this person to such a meeting
**\<sarang>** Other ideas for people to bring?
**\<endogenic>** let's bring hyc
**\<sarang>** I should add... they agreed to fund travel within the U.S. only, due to cost
**\<sarang>** the unfortunate side to a global project, I suppose, is lack of proximity for in-person events
**\<sarang>** I'm sure suraeNoether will have more to add when he returns
**\<sarang>** but the idea is simply to have space/time to wax poetic about what MRL is working on
**\<endogenic>** there's a whiteboard too
**\<sarang>** the best research tool
**\<endogenic>** minutes are taken
**\<hyc>** ah good, no serious gathering can be without a whiteboard
**\<sarang>** heh
**\<sarang>** I'm also saying all this to ensure that folks are in the know about the nature of the meeting and its funding
**\<sarang>** I appreciate the support of Tari Labs, but they (and everyone else) can pry research independence from my cold, dead hands
**\<sarang>** Anyway... anything else of interest that anyone wishes to share?
**\<endogenic>** it'd be a good idea imo for everyone in the community to know they can put something on MRL's agenda for the meeting
**\<sarang>** Oh absolutely
**\<endogenic>** and this is probably a good place to leave suggestions
**\<sarang>** I'm sure that big topics of interest will be ring signatures, spent output analysis, cross-chain fundamentals, payment channels, and general talk of trustless zero-knowledge applications
**\<sarang>** If there are no other issues to discuss, we can begin to wrap up the formal meeting
**\<sarang>** suraeNoether must still be delayed, but I'm sure he'll be on when his plane lands in Opsec USA
**\<silur>** I'd put trustless IBE on that table and i'll dig somewhat deeper into that
**\<silur>** making key-exchange in crypto payments easier is I think a key adoption step
**\<sarang>** IBE?
**\<sarang>** acronyms are my downfall
**\<silur>** identity based encrytion (for signatures of course)
**\<sarang>** ah yes
**\<sarang>** good call
**\<sarang>** silur: do you have particular interest in attending an in-person research meeting (if based in the U.S.)?
**\<sarang>** you don't have to reveal your location here, obv
**\<silur>** I am interested but you know about my stateless situation :D
**\<silur>** don't know how that works in the US
**\<silur>** I only have 50% success of leaving my country even within the EU
**\<sarang>** it was really only a question of how much the supporters were willing to fund, and I suppose any visa issues that might arise (can't speak to that)
**\<sarang>** perhaps we could arrange some kind of remote participation, this hasn't been worked out yet
**\<sarang>** OK, let's formally adjourn
**\<sarang>** thanks everyone
**\<silur>** thanks
**\<hyc>** ttyl
**\<endogenic>** we just need to get one of these for silur and hyc and maybe moneromooo http://www.doublerobotics.com
**\<endogenic>** and i guess a lackey to write on the whiteboard for them
**\<sarang>** Heh
**\<oneiric\_>** thnx
**\<suraeNoether>** aaaaah six minutes
**\<suraeNoether>** damn
**\<suraeNoether>** hi guys
**\<hyc>** lol
**\<silur>** oh hey
**\<hyc>** surae can buy the post-meeting beers
**\<endogenic>** hyc you have to come to nashville for that
**\<silur>** so I'm kindof outdated with our education lead
**\<silur>** we started to talk about that around may I think
**\<suraeNoether>** sarang i disagree that they contain no shocking results: i was shocked that their global solution is harder than NP (it's #P apparently) but I haven't gotten deeply enough into the paper to see if they've \*proven\* it or just have strong evidence of it
**\<suraeNoether>** so, news from the education front is... twofronted
**\<suraeNoether>** firstly, i got my mentee assigned to me for the she256 mentorship program, and depending on my conversations with her, she'll be joining us in the chat room.
**\<suraeNoether>** secondly, i have gotten more communication from the crypto-brick-string group at clemson
**\<suraeNoether>** he gave me some price ballparks for what it would look like to fund grants/consultation at Clemson, which is less important before the community decides to move forward with funding; i explained how we fund things essentially on a quarterly basis to avoid various problems with volatility, and he stopped describing it as grants and more as consultation...
**\<suraeNoether>** he also said "Regardless of the Monero funding status for Spring 2019, I plan to teach a graduate class for Modern Cryptography, AND teach a research topic course on blockchains and applications (more like a seminar, but meet twice a week, this is related to my NSF grant)."
**\<suraeNoether>** (for the record, NSF grants in the math community are pretty rare, and the fact that he regularly snags them is an indicator of the quality of his work)
**\<suraeNoether>** he also asked a question I want to pass on to the community: "One question for you: In my course announcement, I would like to mention the possible collaboration and funding from Monero Research Lab as an advertisement in order to attract good students from Math and CS to join the team. Is this ok with you? "
**\<suraeNoether>** sarang ^ thoughts?
**\<suraeNoether>** any \*funders\* of the MRL have any thoughts?

446
_posts/2018-10-08-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-10-08.md Normal file
View file

@ -0,0 +1,446 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-10-08
summary: Surae work, Sarang work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / sarang
---
# Logs
**\<sarang>** Let's begin!
**\<suraeNoether>** fluffypony knaccc luigi1111 luigiafk sarang andytoshi anonimal ArticMine binaryFate dEBRUYNE endogenic ErCiccione ferretinjapan gingeropolous gmaxwell hyc iDunk IsthmusCrypto john\_alan jwinterm kenshi84 kerber\_ medusa\_ moneromooo MoroccanMalinois naughtyfox needmoney90 oneiric\_ OhGodAGirl philkode pigeons rehrar rrol[m] sgp\_ smooth sneurlax stoffu unknownids vtnerd waxwing
**\<suraeNoether>** meeting time! woo! i'll get banned from freenode eventually by calling everyone's name
**\<rehrar>** just in time
**\<suraeNoether>** So, greetings everyone
**\<rehrar>** got back from the dentist
**\<suraeNoether>** gross
**\<kovri-slack> \<oneiric>** hallo
**\<suraeNoether>** did you bring snakes and butter
**\<sgp\_>** hello
**\<rehrar>** wat?
**\<laXity>** Im just lurking
**\<suraeNoether>** rehrar: adventure time reference, nothing to see here
**\<suraeNoether>** okay, so today I want sarang and myself to discuss what we're working on presently, and then i want to chat about the topics i mentioned before: 1) research, 2) conferences, 3) collaboration, 4) funding
**\<sarang>** righto
**\<suraeNoether>** 5) privacy/efficiency tradeoffs
**\<suraeNoether>** before we begin, though
**\<suraeNoether>** I like the idea that we employed last time where people can be free to ask questions before we begin
**\<suraeNoether>** (i mean in general, you are free to ask questions)
**\<suraeNoether>** but, before we start: who has questions in general for MRL?
**\<rehrar>** When Monero scale?
**\<gingeropolous>** when GUI?
**\<suraeNoether>** how much does a piconero weigh
**\<sarang>** when 0.13
**\<suraeNoether>** oooh that's a better question
**\<sarang>** But anyway
**\<sarang>** Shall I talk research?
**\<rehrar>** yes
**\<suraeNoether>** yep, fire away sarang
**\<sarang>** Well, suraeNoether and I were sent a couple of draft papers from some researchers regarding spent outputs and blackballing
**\<sarang>** There's some formalization of the set theory that we already developed
**\<sarang>** and some parts of the results that are presented in a way that is FUD-inducing
**\<sarang>** "XX% of outputs are traceable!!!!1!"
**\<suraeNoether>** of course, 99% of those were announced in monerolink. :P
**\<sarang>** So we worked through those, offered to work with the researchers, no word back from them except "we will look into it"
**\<suraeNoether>** or 100\*(1-p) for some reasonably small p, i believe they managed to find an additional, ... I think about a single day's worth of transactions in total, from teh whole blockchain, iirc
**\<sarang>** I'm working to get some updated blackball stats on our own to compare
**\<sarang>** they have an O(N^2) method for identifying more outputs, but this is negligible as always
**\<sarang>** At the very least, we'll have up to date data to refute if they publish their work as-is
**\<sarang>** Aside from that, suraeNoether and I have been continuing work on sublinear ring sigs for feasibility
**\<suraeNoether>** they reinvented several wheels that we've worked on in the past 3 months here at MRL, which is actually a good thing, because it lends credence to our results to have some independent and similar results pop up
**\<rehrar>** like RuffCT type stuff?
**\<sarang>** yiss
**\<sarang>** I have a shitty version of their clustering algo on my repo
**\<suraeNoether>** well, RuPol. RuffCT was the first one we had presented to us (also by Ruffing et al, but with a different "et al")
**\<suraeNoether>** the clustering algorithm has to do with this blackball paper, not sublinear ring sigs
**\<sarang>** yes
**\<sarang>** As sgp\_ has mentioned before, forks and pools will be the BB things to focus on anyway
**\<rehrar>** so is the new sublinear stuff looking more promising than the Ruff Stuff?
**\<sarang>** unfortunately those are not verifiable by the user
**\<sarang>** rehrar: unclear
**\<sarang>** it's clever but very complex
**\<suraeNoether>** that's what we are trying to figure out: it appears to be more efficient, asymptotically, but until we have a working implementation, it's hard to tell
**\<rehrar>** like me
**\<suraeNoether>** yes
**\<sarang>** heh
**\<sarang>** There is a lot of math left out of the paper, so it's a thing we're working on in parallel to other things that come up
**\<rehrar>** cool. Sounds lit.
**\<rehrar>** #litmaths
**\<suraeNoether>** last week I split our MRL research roadmap into a sequence of separate github issues (#30 and higher I believe) https://github.com/monero-project/research-lab/issues
**\<suraeNoether>** nope, #31 and higher
**\<suraeNoether>** and I've spent a bit of time on my lightning-for-monero paper, but not nearly enough, as this RuPol thing is a nasty rabbit hole
**\<rehrar>** is MRL going to transition to gitlab also?
**\<IsthmusCrypto>** I'm at the SF Blockchain Week Epicenter today & tomorrow on behalf of #noncesense-research-lab -- ping me if you're around and want to meet up for coffee/drink/chat. I'll be back with a million new ideas soon.
**\<sarang>** rehrar: I have no big preference
**\<suraeNoether>** rehrar: i have no control over the research-lab git, actually. :P
**\<suraeNoether>** so if all workgroups migrate, we'll presumably migrate too? \*shrug\*
**\<rehrar>** also personal repos, but that can be after the meeting
**\<sgp\_>** yeah sarang and I have been talking about blackball, and it's my opinion that we need the public pool data working with the blackball tool to test for chain reactions before we proceed further
**\<equim[m]>** I have a question. Would the blackball cause such kind of attack? Mallory knows an output belongs to Alice and wants to trace when it is spent. He makes N transactions with each of them exactly N ring members, and each of them contains Alice's target output as decoy. If the blackball get in effects, then the next time the target output apears, it must be Alice's real output.
**\<sarang>** One conclusion sgp\_ and I share is that understanding the statistics can help guide best practices going forward
**\<sgp\_>** if pool transactions are mostly unimportant, then we probably only need to use the blackball tool as an indicator of netowkr health. no one would use it typically
**\<sarang>** equim[m]: the on-chain set theory stuff is for provably spent outs
**\<sarang>** it's not possible to "get caught" with that
**\<sarang>** Mallory couldn't make those signatures anyway
**\<sgp\_>** if pool transactions ARE important, we need to bump ringsize, avoid coinbase decoys by default in wallet clients, or have everyone use a blackball list
**\<sgp\_>** you can see our recommendations hinge on the importance of pool data
**\<sarang>** option 1 is expensive, option 2 is possible (but could fingerprint), and option 3 is not verifiable
**\<sgp\_>** (or at least mine do, I don't mean to speak for sarang)
**\<suraeNoether>** equim[m]: short answer is no, long answer requires more explanation, but primarily: the probability that allice \*happens\* to select all used up ring members is very low unless someone was flooding the network with transactions, and at that point, the attack is costly
**\<sarang>** My opinion is that we need the data for this
**\<sarang>** and moving toward getting that data is the first step
**\<suraeNoether>** i think the blackball thing is a big red herring waste of time, and i've said this beforfe
**\<sarang>** it is for set theory stuff
**\<sarang>** for pools it is unclear until we have data to show one way or another
**\<suraeNoether>** i think i've sketched out my argument about how, even in the next 10 years, it's unlikely to impact even a single ring signature, so i'm still highly skeptical
**\<sarang>** Hence getting pool chain rxn data
**\<sarang>** then we can lay it to rest one way or the other
**\<suraeNoether>** if the back of the napkin is that pessimistic, i think spending even an hour collecting data is wasting time, but i've said that before too
**\<suraeNoether>** i disagree: this shit will never be laid to rest until people just admit that it has no practical impact
**\<nioc>** AIUI mooo thinks it's bad to include pool txs in the BB list
**\<suraeNoether>** the EAE attack and ring sizes in general are far more fearsome
**\<suraeNoether>** and far more worthy places for us to spend our limited time
**\<suraeNoether>** nioc: do you recall moneromooo's justificaiton for that?
**\<sarang>** Not saying we should add them. Saying that we should see what effect they have so we can decide if/how to move forward
**\<suraeNoether>** sgp\_: i heard a rumor that you had started including heuristically linked outputs in the blackball list, or outputs that aren't necessarily \*provably\* spent. is that true?
**\<nioc>** sarang: yes
**\<moneromooo>** I don't really like this. (1) they're not proven spent, (2) it means it strips away non pool miners' ring signaturity when they spend.
**\<suraeNoether>** sarang: would you mind opening an issue up on the research-lab git on this topic so we can have a public discussion about it that is referrable later without combing through meeting logs?
**\<sarang>** I'll defer to sgp\_ since this is really his baby. I'm just an interested party who would like to know the results of the analysis
**\<sgp\_>** moneromooo we can talk about the implications, but the effectiveness of these pool ring signatures is already 0
**\<suraeNoether>** sgp\_ any word on my previous question?
**\<suraeNoether>** re: blackball list and non-provably spent outputs?
**\<sgp\_>** suraeNoether sneurlax's tool looks at coinbase outputs and the sent transactions to see which outptus could have been spent in the transaction
**\<sarang>** the current codebase's bb tool will not do heuristics on its own
**\<sgp\_>** I believe it's a heuristic using data the pool provides, and it takes this data with the assumption it's correct
**\<suraeNoether>** so... \*yes\* the tool blackballs outputs that are not provably spent?
**\<sgp\_>** so if a pool mis-reported, the tool would report different results
**\<sarang>** sgp\_: he's asking if your hosted list contains any non-proven
**\<sgp\_>** the current tool that ships with Monero now does not
**\<suraeNoether>** i strongly recommend against any blackballing for any outputs that are not provably spent
**\<sgp\_>** right now, the site has 3 list categories
**\<equim[m]>** So if everyone is using blackball, then one can easily make others mark a target output as spent (N transactions with N ring size) that is actually not spent?
**\<suraeNoether>** it is critical that the blackball list be independently verifiable
**\<sgp\_>** one for all chain data with chain splits, another with only rct data with chain splits, and a third separate category for pool data
**\<sarang>** equim[m]: you cannot generate signatures that blackball another person's output
**\<equim[m]>** Yes that's my point
**\<suraeNoether>** equim[m] I'm not understanding your question
**\<suraeNoether>** would you mind clarifying?
**\<sgp\_>** a user could verify the first two by running XMR, XMO, XMV nodes locally
**\<equim[m]>** Okay, I think I need to read up more first.
**\<sarang>** equim[m]: if you generate N identical rings of N outputs with valid sigs, it means you controlled all N of them
**\<sgp\_>** fwiw I don't recommend a user should use a blackball list. I think we should use the findings of the blackball list to pursue other options to mitigate the data that would need to potentially be stored there
**\<moneromooo>** equim[m]: you cannot make N rings with N outputs, one of which being not yours.
**\<equim[m]>** Oh I got it, just missed that.
**\<equim[m]>** rings need to be identical
**\<sgp\_>** sneurlax's tool essentially creates a list of outputs that the pool controls at any one given time, then sees if it can attribute these outputs to specific ring signatures
**\<sgp\_>** I still think we need to table this discussion until we can test for possible chain reactions with pool data, which means updating the output format for sneurlax's tool
**\<sarang>** Yes, I think a useful action item is to get this data, run rxns, and compare to our base data to see what the effects might be
**\<sarang>** just like it's useful to have data on previous forks to better understand what, if any, risk is present
**\<sgp\_>** yeah, and if the impact is small, we forget about it. if it's large, we need to discuss options
**\<sarang>** Yep, use the data to inform best practices
**\<sarang>** So
**\<sarang>** suraeNoether: any research to report in addition to what's been discussed?
**\<suraeNoether>** sorry, had to get the door
**\<suraeNoether>** So, other than a modest amount of progress on my lightning paper, and workign with Sarang on this sublinear RuPol scheme, I have done a lot more administrative stuff this week
**\<suraeNoether>** so i want to move onto a bit of that adminstrative crap regarding conferences
**\<suraeNoether>** actually
**\<suraeNoether>** collaboration is a bit more research themed
**\<suraeNoether>** so, there is some good news and bad news on the collaboration/grant front
**\<suraeNoether>** the short summary is this: after speaking with three separate univeristy research foundations on Friday
**\<suraeNoether>** there simply is not a structure in place for universities to accept research funding from a crowdfunded animal like our own
**\<suraeNoether>** this is both good news and bad news
**\<suraeNoether>** the bad news is it'll be six months at least, if not longer, before we can start interacting wtih universities in a way that requires funding
**\<suraeNoether>** the good news is that all three of those universities are extremely eager to start working these things into their foundation's policies
**\<suraeNoether>** so, for example, the researcher Gao at Clemson: even if we wanted to, we couldn't really offer any money (beyond bug bounties, etc) for their collaboration
**\<endogenic>** is it really a good idea for MRL to be in the grant giving business? is there anything the FFS system could not accomplish for such candidates?
**\<rehrar>** endogenic: being actually funded for one
**\<rehrar>** ba dum tsh
**\<suraeNoether>** this relieves a possible burden on the community; in the meantime, CURF (clemosn university research foundation) is going to start working (partly with me at MAGIC) doing research on how to start making this a thing, because everyone at these universities agree this is not going away any time soon
**\<sarang>** I thought the Clemson group might be interested in non-funded collaboration
**\<sarang>** thereby removing the burden from the community
**\<suraeNoether>** and that's the best news, is that they are
**\<sarang>** and the PITA of funding
**\<endogenic>** rehrar: why does everyone keep saying that
**\<suraeNoether>** endogenic: the best jokes require explanation
**\<rehrar>** cuz funding is taking a while for other stuff. It's just cuz people are funded out after funding mooo, sarang, and suraeNoether
**\<suraeNoether>** of course, providing some incentives for that research like travel funding,e tc, these things can be accomplished through the FFS, endogenic... kinda! but not really... because every single university requires a cut of all such funding, and they refuse to accept such funding from a crowdfunded anon crowd style animal
**\<rehrar>** admittedly, those are our greatest assets, but they require good amounts of Momos, so the other ones are struggling a bti atm
**\<rehrar>** \*bit
**\<sarang>** yep
**\<sarang>** I think the correct avenue is non-funded collab
**\<suraeNoether>** so the short answer is that right now, it doesn't matter if it's in MRL's best interest to be a source of funding, because we literally can't do it
**\<sarang>** We already have university groups publishing on Monero
**\<suraeNoether>** yep
**\<rehrar>** I'm going to make it my personal mission to make Momos a thing for Monero in the same way bucks and paper is for dollars
**\<suraeNoether>** all about the momos
**\<endogenic>** i think.. it does matter.. because if it's not in mrl's interest then we don't have to become nonprofit administrators with the ffs funding we have.
**\<suraeNoether>** so, that actually puts a nail in a coffin that i very much wanted to either be nailed shut or aired out in the daylight, i was uncomfortable with whatever was inside banging on a loose lid
**\<suraeNoether>** so to speak
**\<endogenic>** "every single university requires a cut of all such funding, and they refuse to accept such funding from a crowdfunded anon crowd style animal" hmm
**\<endogenic>** how about from individuals?
**\<suraeNoether>** that's a different animal
**\<endogenic>** we just have individuals who are willing to deanonymize themselves say who they are
**\<suraeNoether>** well
**\<endogenic>** you can even feature 'em
**\<suraeNoether>** another option is, for example, OSTIF
**\<suraeNoether>** but for now, adding this layer of grief I think is not worth it, even if there are interested parties who could throw their weight toward our project; MRL has other goals and priorities and we don't want to spread ourselves too thin... and the answers I got from the foundations I spoke with are good enough reasons to abandon the idea for at least a few semesters
**\<sarang>** Keep in mind that whoever is giving the grant is paying a lot extra for administration
**\<suraeNoether>** 50% in fact
**\<sarang>** yes
**\<suraeNoether>** well, between 33% and 50% depending on the university
**\<sarang>** researchers don't see a dime of that
**\<suraeNoether>** yep
**\<suraeNoether>** heh
**\<suraeNoether>** so, that's going on a longer-term back burner
**\<suraeNoether>** another thing I wanted to talk about is the Monero Konferenco
**\<sarang>** So I agree with the sentiment that FFS shouldn't fund university grants, but we should be receptive to helping good researchers apply for funding, and also keep collaborating for free with groups we know are interested
**\<suraeNoether>** especially researchers who have contributed to the project already
**\<endogenic>** sarang: if ffs proposals for grants had more trouble getting funded than those which didnt have admin fees attached then i think that could create a market to lower admin fees
**\<suraeNoether>** endogenic: my experience, to be frank, is that almost any university will climb over their own grandmother, so to speak, for more funding, so you may not be wrong. however, these institutions are oftentimes very... slow... to... make... decisions... regarding new technology especially
**\<suraeNoether>** but anyway, unless folks have questions, let's move along to conference talk
**\<suraeNoether>** re: the Monero Konferenco, I finally have all the quotes for costs that I need to post the funding request, and I want everyone's advice on how to proceed
**\<rehrar>** MoneroKon!
**\<suraeNoether>** long story short I've boiled down our possibilities to at least two, if not three possible locations, all that are roughly within the same range of price and amenities. However, one of those locations is the University of Colorado in Denver, which has some... interesting requirements... for the events held there. And there is a possiblity that they have to turn us down if we are not a "society" like SIAM or
**\<suraeNoether>** AMS (for the same reason that grants can't be accepted)
**\<suraeNoether>** all that needs to happen there is one professor decide to "sponsor" the event, but then there are issues with a public university endorsing our little conference, and whether that is even allowed
**\<rehrar>** so...probably best not to do it there then? Or is that the best of the bunch price-wise?
**\<suraeNoether>** so, depending on my communications with them this week, it may simply not be possible to do it there. I've already gotten proposals from the Colorado Convention Center and the University of Denver, both of which have some sub-optimal properties
**\<suraeNoether>** it's not only the best of the bunch price-wise, I think, but also: you can take the lightrail from the airport to the location, which is embedded in the 16th street mall, which is a bit of a tourist location. lots of restaurants and hotels, etc
**\<suraeNoether>** and there are bike share stations all around, etc
**\<endogenic>** rehrar thinking about your previous mention of people being funded-out .. tbh we have a lot more funding sources than those who are aware of the ffs system but they cant donate monero because they dont have any. we need to open the funding platform to those who visit then drop off
**\<suraeNoether>** this meeting is not about the FFS
**\<suraeNoether>** and I would really like to move on
**\<suraeNoether>** we are coming up on an hour already. :P
**\<suraeNoether>** but i guess the meeting really IS about FFS
**\<endogenic>** it's my fault
**\<rehrar>** so maybe THEY might not be able to market our event
**\<rehrar>** but can WE do it?
**\<rehrar>** is there a cryptocurrency club in that university?
**\<suraeNoether>** oh, marketing is totally aside; the issue is that by sponsoring the event (which they require for the event to be held on their campus) is an implicit endorsement BUT THAT'S A REALLY GOOD QUESTION REHRAR!
**\<sgp\_>** +1 rehrar
**\<suraeNoether>** i know that three professors there are currently chatting with each other about this to decide how to approach the topic
**\<suraeNoether>** they haven't contacted me directly yet, though, and I will email the chair of their department back
**\<suraeNoether>** however, locations aside: we have numbers for funding requests, and I want folks' advice on moving forward for this
**\<rehrar>** My honest opinion is, if this can be hammered out relatively quickly, then let's try for there. If not, then we should find another place. The truth is so much depends on the venue that it's super hard, if not impossible in some areas, to plan further without knowing the venue
**\<suraeNoether>** I feel like having more than one funding round would be wise, where we can cash out as we go. this could prevent something like asking for the single big chunk all at once and then failign to fund the entire thing, even though we could still throw a kcikass event for 80% of funding, or even 60%, as long as we plan around it
**\<suraeNoether>** has that sort of thing been done through the Monero FFS yet?
**\<suraeNoether>** also, if we can get a sponsorship, say from Cake Wallet or Tari or something like that, over-funding could be returned to the community through the general fund or whatever
**\<sarang>** what is the amount of the "big chunk"
**\<rehrar>** I 100% support those terms
**\<rehrar>** The idea that you ask for 100% of what is needed, and then ask for sponsors after.
**\<rehrar>** And specify in the FFS that any extra funding will be kept for next year's conference
**\<rehrar>** there is no guarantee of sponsors
**\<gingeropolous>** this may or may not have been thought of or talked about above, but if MRL can't do university stuff because its a total PITA etc, one resource that could be created is a research facilitator
**\<rehrar>** that's just my opinion though
**\<suraeNoether>** my initial numbers were 54,150 USD to 72,900 USD, but i was assuming wedding-level costs of a venue. with our newest numbers, the cost will be closer to 52k USD to 59k USD
**\<gingeropolous>** i.e., if there's a researcher at a university who wants to do monero research, we can provide grant templates or boilerplate crap or letters of support
**\<rehrar>** I'm not sure how wise several funding rounds is though
**\<gingeropolous>** for the university researchers grant application etc
**\<suraeNoether>** gingeropolous: that's a very interesting idea that we can start looking at over the next few months
**\<rehrar>** depending on how quickly it moves through the system and gets funded each time, it might be too long to get stuff done
**\<sarang>** I still think we need to do a better job of reaching out to groups that have already done Monero research
**\<gingeropolous>** yeah, it shouldn't hit any beaurocratic nightmare hurdles
**\<suraeNoether>** rehrar: that's a fair point
**\<rehrar>** I think make an FFS for 65k
**\<gingeropolous>** bureaucratic
**\<rehrar>** roughly 10% of wiggle room there for price movements
**\<suraeNoether>** okay, and we can make it clear that excess funding will be used for next year's conference
**\<suraeNoether>** now, for transparency reasons
**\<suraeNoether>** I'll be throwing this conference, contacting speakers, hiring the conference coordinator, etc
**\<suraeNoether>** the coordinator will be taking care of most of the grunt work
**\<rehrar>** I'm down to help in whatever capacity (management, coordination, or otherwise) that you need me for
**\<rehrar>** as well as design, obviously
**\<suraeNoether>** in order to avoid liability, I've started an LLC called colorado crypto conferences LLC, so that I can distribute funds to organizers, venues, etc, without it coming out of my personal bank accounts, etc
**\<suraeNoether>** thanks for volunteering for this rehrar!
**\<suraeNoether>** we'll definitely take you up on that. I wouldn't mind having t-shirts or shwag bags
**\<suraeNoether>** so, does anyone object to me opening an FFS for 65kUSD for this? I can post 100% of all bookkeeping information for CCCLLC for transparency
**\<suraeNoether>** and comply with any other wishes the community has for transparency
**\<rehrar>** start there, and get feedback. I think it should be more than fine. :)
**\<kovri-slack> \<oneiric>** sounds like a great idea, +1
**\<suraeNoether>** fantastic
**\<sarang>** How much does the coordinator get paid?
**\<sarang>** (due to the conflict of interest there)
**\<suraeNoether>** 9000 USD. Approximately 100 man-hours of work. Justification: Typical per-hour fees for event organization at a firm are between 125-250 USD per hour. The project organizer is low-balling herself for this cost specifically because she is related to me. Around 10 of these hours she anticipates can be spent seeking out sponsors for the conference to mitigate our costs, as well.
**\<suraeNoether>** she just finished organizing a conference for Johnson and Johnson and she received over 20 for the same amount of time and work she expects for this.
**\<rehrar>** I think all that is needed for this justification is quotes from a couple other people of the same job
**\<endogenic>** ^ that doesnt work
**\<rehrar>** no?
**\<endogenic>** at least not without showing their work will turn out just as well
**\<endogenic>** yup
**\<endogenic>** i say leave it to the community to ask
**\<rehrar>** ok
**\<suraeNoether>** it's not a complete look, but it's fairly standard to find 3-4 quotes from several parties as an investigation into "fair market value" and then select from there
**\<endogenic>** of course
**\<endogenic>** not sure why youre on the hook to justify it though if youve done your research and are doing something for the community
**\<endogenic>** it's an easy thing to find a quote for
**\<sarang>** I'll have a couple of quick unrelated blackball stats when we're finished up here
**\<sarang>** endogenic: I think it's ethically important because he's related to the organizer he currently plans to hire
**\<endogenic>** how does showing quotes ameliorate that? :P
**\<suraeNoether>** endogenic: it's a good faith thing
**\<sarang>** yeah
**\<endogenic>** you're not recommending her rate imo
**\<suraeNoether>** i'm not, she selected her rate
**\<rehrar>** this is true, endogenic.
**\<rehrar>** And if another coordinator wants to come in, prove their past work, and undercut, nothing is stopping them.
**\<rehrar>** but onus on them
**\<suraeNoether>** the fact is: it's a very easy thing to temper any appearance of impropriety, and so we should
**\<sarang>** suraeNoether: what does the total estimate assume about entry fees?
**\<suraeNoether>** I assumed nothing about fees.
**\<suraeNoether>** here is the section I was going to include on that.
**\<sarang>** Cool, so it assumes people show up fo free?
**\<suraeNoether>** \*Registration fees.\* Charging attendees is optional here and we should discuss the benefits (free and open access to Monero conferences is something we value?) and the costs (random crazy people and ICO shillsters will almost certainly walk in off the street!). It's worth pointing out that the event will \*not\* pay for itself unless we charge more than 1000 USD per ticket and we have full attendance.
**\<suraeNoether>** currently looking at 50-70 attendees, so charging, say, 40 bucks for entry would only partially mitigate our total costs
**\<sarang>** Does the LLC's tax burden come into play with any of this?
**\<rehrar>** We can discuss what it would look like to charge a small amount to partially mitigate costs, and give tickets for free to anyone who asks nicely.:D
**\<suraeNoether>** sarang: if the LLC makes any profit, it passes through to me and i pay personal taxes on it; my goal is to save a bit of cash for next year's conference, extract taxes from that part set aside, and then ensure that the remainder is spent on expenses for this year, so that i personally never feel any burden or liability from this.
**\<nioc>** you will get more than 50-70 attendees and there should be some cost for them
**\<sarang>** OK, so charging entry fees doesn't mess with that
**\<suraeNoether>** nioc not if i only sell 70 tickets :)
**\<suraeNoether>** sarang correct
**\<sarang>** got it
**\<suraeNoether>** all my venue costs look at around 600-650 a day, but are based on no more than 150 people
**\<sarang>** how many days?
**\<rehrar>** are we only planning for 50-70 because that's the sizes of the veue
**\<suraeNoether>** 1.5
**\<rehrar>** \*venue
**\<sarang>** Will there be a story about the afterparty on mashable?
**\<suraeNoether>** 50-70 for measuring interest the first year, and to keep the topics and audience in the technical, rather than ICO/business end... also because it's easier to scale a small event up than throw a big event htat no one shows up to... not to mention, fluffypony has discussed with me throwing a monero conference preceding the magical crypto friends conference he is planning in NY, and I \*imagine\* that's going to
**\<suraeNoether>** be a larger scale event.
**\<suraeNoether>** most of these universities have so much room for events like these we can scale up relatively easily without paying \*too much\* more
**\<rehrar>** interesting
**\<rehrar>** if we get flooded with people, we can see about just purchasing a bit more space? :D
**\<rehrar>** anyways, let's do what you've planned. See how it goes.
**\<suraeNoether>** especially at a university, yes
**\<suraeNoether>** but we would need several months lead time on estimates of crowd sizes
**\<suraeNoether>** okay, rehrar's opinion is good enough for me
**\<suraeNoether>** :D
**\<suraeNoether>** okay, any last questions before I pivot to a controversial opinion I'm strongly interested in peddling on everyone here?
**\<sarang>** Sure, but let's speedy things up
**\<sarang>** we're way over
**\<rehrar>** no questions, give opinion
**\<suraeNoether>** okay, the main thing is this: we have a responsibility to our users. they use our currency in some cases to protect their own livelihoods from tyrannical etc etc
**\<sarang>** yes
**\<suraeNoether>** in some cases, monero is a matter of life and death
**\<suraeNoether>** due to this, I believe we need to start shifting our attitude about development at Monero away from efficiency and towards security
**\<suraeNoether>** and due to this, I believe we should move to a fixed but large ring size, like 45.
**\<sarang>** Do we have data to back up such a choice?
**\<sarang>** I believe our job is to provide users the best efficiency for what we see as reasonable and necessary security/privacy
**\<suraeNoether>** if it turns out that, in 6 months time, a more efficient scheme comes along, then we would see a drop in our sizes and verification times, similar to our bulletproof thing, which is a PR win for us, and in the meantime, we would be taking the cautious route.
**\<suraeNoether>** short answer to that sarang is: kinda
**\<sarang>** If users who need us can't join the network reasonably, we've failed them
**\<suraeNoether>** yes, if we go too large, network security is compromised by new nodes choosing other coins
**\<sarang>** "The chain is now 400 GB" is a bad statement to give them
**\<sarang>** I think this hearkens back to the need for a better understanding of threat models
**\<suraeNoether>** so we are stuck between a rock (loose security with efficiency and speed, lots of network security but weaker untraceability claims) vs. a hard place (tight secuirty for a coin that no one uses properly, a la pre-sapling zcash)
**\<sarang>** If ring size is made less relevant by a better understanding of, e.g. churn and controlled spends under certain threat models, that's good data
**\<suraeNoether>** yeah, but what about users who don't churn?
**\<sarang>** That's the need for understanding our threat models better
**\<rehrar>** churning is an active choice to protect yourself
**\<gingeropolous>** i like the idea of shifting focus towards security.... but that seems to go hand-in-hand with efficiency.
**\<rehrar>** every step you make a user take for themselves, you will see significant drop off in people who do it
**\<gingeropolous>** then again, monero (the entity) didn't give two shits about efficiency when it went to RingCT
**\<sarang>** What I mean is that if we can establish that a large ring increase has measurable benefits for users under reasonable threat models, that's a conversation worth having
**\<suraeNoether>** actually gingeropolous that is one of hte best points: we added these huge slow range proofs without hesitation, and then we had a big PR win for making them more efficient.
**\<suraeNoether>** we should just assume the following threat model: anyone we transact with is transacting with an AML/KYC exchange, who can be assumed to have godlike, state-level computational power because a government serving them a warrant leads to that
**\<sarang>** There was a big benefit to CT... can we point to such a benefit with a large increase?
**\<suraeNoether>** now, if you are pinned, EAE style, between two adversaries, ain't no ring size that will help
**\<suraeNoether>** so the only reasonable threat model we can really work with is EBABE where you may not be transacting directly with AML/KYC but people on either side of you are
**\<rehrar>** I think the assumption of EABE for current standard use is not unfounded
**\<suraeNoether>** ^ bingo
**\<rehrar>** and I think a threat model of EABE is probably the one to operate under
**\<rehrar>** BUT
**\<rehrar>** since we cannot see Monero's stuff
**\<rehrar>** we should analyze how people use altcoins
**\<rehrar>** like Litecoin or Dash
**\<rehrar>** see if it tends to go EABE
**\<nioc>** wownero just forked and their static ringsize is now 22. Don't know if they will have any stats that would be of interest to "us"
**\<rehrar>** and extrapolate from that to Monero
**\<kovri-slack> \<oneiric>** what do EAE and EABE stand for?
**\<sarang>** That use could be waaaay different
**\<rehrar>** sarang: we do the same for sending patterns and selecting ring members though
**\<sarang>** Eve-Alice-Eve and Eve-Alice-Bob-Eve
**\<suraeNoether>** oneiric\_: EAE is "eve-alice-eve" where eve is an evil exchange and you are alice. other non-E letters are other users who may or may not be malicious
**\<sarang>** rehrar: we have some Monero data for that too
**\<rehrar>** ok
**\<sarang>** based on deduced spends
**\<kovri-slack> \<oneiric>** ok, thanks sarang and suraeNoether
**\<sarang>** but something like exchange interaction might be way different for a private coin
**\<suraeNoether>** so sarang keeps asking "can we point to a benefit" and the answer is "we can point to a point at which ring size increases are no longer helpful, which is around 45, and we can point to some weak results on, say, how many transaction histories exist." for example, I just found a theorem that proves that there must be twice as many transaction histories as their are output keys, but finding all of them is
**\<suraeNoether>** progressively harder and harder as ring sizes increase
**\<sarang>** OK, let's formalize this, determine how exchange interactions affect it (to the extent that we can), and then go from there
**\<rehrar>** ^
**\<sarang>** The question of formalization and hard numbers always comes up when this gets discussed
**\<rehrar>** see the mathz
**\<sarang>** but it hasn't happened yet
**\<suraeNoether>** okay; i'm not trying to convince people today, i just want our community to start thinking about the formalization components of this and longer-term thinking for the safety of our users
**\<sarang>** This has been on our radar for a long time
**\<sarang>** Until we have the math for it, I think it's a very hard sell
**\<rehrar>** perhaps one of you community paid MRL researchers should get this formalization done ;)
**\<sarang>** ikr
**\<suraeNoether>** that's one of my in-prep papers
**\<sarang>** suraeNoether: it was my understanding that you already had informal versions of this
**\<suraeNoether>** ^
**\<sarang>** I think it should be a priority
**\<suraeNoether>** yeah, that's where my priorities are shifting, but that also includes looking at the sublinear papers
**\<suraeNoether>** because if they are sufficiently efficient (heh) we don't actually even have an argument, y'know?
**\<sarang>** Yeah, they go hand-in-hand
**\<rehrar>** the sublinear papers are for increasing efficiency of larger ringsizes though, correct?
**\<sarang>** But I consider this more important than, say, lightning and cross-chain stuff
**\<sarang>** rehrar: size efficiency, yes
**\<rehrar>** I understand they go together, but I think priority should be on establishing usage patterns to establish a threat model
**\<sarang>** agreed
**\<rehrar>** I believe Monero has been operating for a dangerously long time without a specified threat model
**\<sarang>** Well, and our ring increases have to some extent been based on "bigger is better"
**\<sarang>** we're long past the point of chain reaction style threats
**\<rehrar>** and so, while efficiencies to ring sizes are good, I think the establishment of the threat model is imperative to all future research in this area
**\<sarang>** (exactly 5 post-CT outputs are blackball-worthy from on-chain analysis)
**\<rehrar>** as a community member, I would propose that both sarang and suraeNoether work together on hammering out this formalization before further work proceeds
**\<rehrar>** this will further legitimize Monero in the privacy/security industry.
**\<gingeropolous>** i mean we could just go to 45, and then let optimization take its natural course
**\<rehrar>** At the moment, I can see the criticisms from other people that see the lack of a defined threat model as proof that we are flying by the seat of our pants
**\<gingeropolous>** ala RingCT
**\<suraeNoether>** my primary concern is that repeated analyses of a system that uses small anonymity set sizes (sub-millions) can be very powerful in reducing effective anonymity set sizes, regardless of the threat model
**\<sarang>** We could also require users to use a different burner laptop from a different IP for every transaction, but that doesn't mean it's necessarily helpful
**\<rehrar>** gingeropolous: doesn't solve the problem of threat modeling and formalization. and Monero is better than that
**\<suraeNoether>** and the "sub-millions" thing is essentially a non-starter for obvious reasons
**\<gingeropolous>** "who needs action when you've got words"
**\<suraeNoether>** heh
**\<rehrar>** who needs either when you have math
**\<rehrar>** which guides the action and discussion
**\<sarang>** A good start will be formalizing the ring size informal stuff, hammering out churn wait times as a heuristic killer, and going from there, perhaps?
**\<rehrar>** right now we have not the math
**\<rehrar>** yes ^
**\<rehrar>** for me, as a recommendation from a community member, this is priority number 1
**\<rehrar>** can't speak for others obviously
**\<sarang>** I think it answers "how can we use Monero safely right now" so we can move to "how can we make Monero better for tomorrow"
**\<suraeNoether>** okay, I'm going to formalize a single-hop (EABE) and double-hop (EBABE) pair of threat models, write up my formal definition of fungibility, demonstrate it implies anonymity, show that neither zcash nor monero satisfy my definition of fungibility, demonstrate a churn model that brings us closer to fungibility, and i'll share that document with the community. that will be my top priority this week
**\<rehrar>** thank you suraeNoether
**\<sarang>** baller
**\<rehrar>** from a research perspective
**\<suraeNoether>** also, can we change the term "blackball" to "marked notes?" :P
**\<sarang>** This doesn't even need to be journal-worthy
**\<rehrar>** to me, this is even bigger than BPs
**\<rehrar>** and will be the biggest thign to come out of MRL this year
**\<sarang>** but we need a base for our recommendations
**\<kovri-slack> \<oneiric>** serious win
**\<sarang>** Let's collaborate as much as is useful, suraeNoether
**\<scoobybejesus>** i'm sure the formalization will pretty much write itself... /s
**\<suraeNoether>** allright, before we end the meeting: any final questions, comments, concerns? I need to write my summary of my september work and post it, so I apologize to the community for my delay (again)
**\<sarang>** I ran some new blackball stats to compare to our author friends
**\<rehrar>** nope. Great meeting. Gotta split. Bai.
**\<sarang>** Finding their results are comparable to ours
**\<sarang>** Importantly, our analysis methods show exactly 5 post-CT outputs are bad
**\<sarang>** whereas about 68% of pre-CT outputs are bad
**\<suraeNoether>** good to know :D
**\<sarang>** this accounts only for on-chain stuff (no forks, pools, etc)
**\<sarang>** I'm going to add this to our tech note to shut people up about "OMG OUTPUTS ARE TRACED"
**\<gingeropolous>** yeah 5 of them!
**\<sarang>** modern transactions are not vulnerable to this crap
**\<gingeropolous>** and like all of pre-ct
**\<suraeNoether>** on a totally different note, i'm in a weird funding trap because I was an idiot earlier this year, and I don't have funding for december. sarang and I were going to request funding for Jan-March simultaneously: do you guys think I should ask for Dec-March or should I request december separately, or what? I tried to get back on the quarter system earlier this year and then idiotically got back off it again. :\\
**\<rehrar>** just do four months
**\<rehrar>** now I really gotta split
**\<sarang>** bai
**\<suraeNoether>** ok <3 rehrar

231
_posts/2018-10-15-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-10-15.md Normal file
View file

@ -0,0 +1,231 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-10-15
summary: Surae work, Sarang work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / sarang
---
# Logs
**\<sarang>** LET US BEGIN
**\<suraeNoether>** yes hello
**\<sgp\_>** Hello
**\<kovri-slack> \<oneiric>** hullo
**\<suraeNoether>** today i want to chat about research and the monero konferenco, and... that's my agenda. if folks want to add to the list, shout out~
**\<sarang>** hi
**\<sarang>** Where to begin?
**\<suraeNoether>** well, firstly
**\<suraeNoether>** who wants to come give a 20-40 minute chat at the Monero Konferenco? I'd like each workgroup to have at least one representative
**\<hyc>** when/where is that going to be?
**\<sarang>** I'll do one
**\<suraeNoether>** Good question, hyc! Right now it's looking to be one of the weekends between April 27 and June 15 in Denver, Colorado. invited speakers will be reimbursed for their travel costs
**\<suraeNoether>** assuming the community decides to fund my proposal, that is
**\<hyc>** cool
**\<sarang>** Can reimbursement be in XMR?
**\<suraeNoether>** I'm leaning toward April 27, personally
**\<sarang>** Or are there weird legally things with that
**\<kovri-slack> \<oneiric>** I could do one, or defer to anonimal if he wanted to do one
**\<suraeNoether>** yes, reimbursement can be done in XMR, it just makes accounting moderately more annoying, but no legal issues
**\<sarang>** cool
**\<suraeNoether>** and i'm happy to do that
**\<sarang>** Because fiat reimbursement is always a baffling and lengthy ordeal
**\<suraeNoether>** well oneiric i wanted a session of several talks on networking privacy. i'd love to have both you and anonimal come speak
**\<kovri-slack> \<oneiric>** :)
**\<suraeNoether>** i also want to invite people not directly related to the monero ecosystem
**\<parasew[m]>** i will also try and come there! as i could not make it to defcon sadly
**\<sarang>** suraeNoether: are there plans to arrange for streaming or quality recording?
**\<sgp\_>** Yeah, we need that
**\<suraeNoether>** i really want to give folks who are up and coming a chance to speak at this event; we can invite really big name people to come talk, but i feel like their careers are already pretty well laid out before them, so it'd be nice to get some outside researchers who are more tangential to the crypto celebrity scene
**\<sarang>** May I recommend hiring an outside group to handle that, and \_not\_ venue staff
**\<suraeNoether>** sarang, one option laid out in the budget is a section on audio/visual rental and web streaming and costs; a local place that does webcast-style AV presentations regularly would charge around 5kUSD for such an event.
**\<sarang>** Or at the very least getting someone with professional experience as an audio engineer
**\<sarang>** cool!
**\<suraeNoether>** i posted last week on the forums for the FFS under ideas
**\<suraeNoether>** i haven't gotten comments. :P
**\<sarang>** oops
**\<sarang>** that's my bad
**\<sarang>** I thought I had read something on recording but it's easier to just ask you and be lazy
**\<sarang>** ty
**\<suraeNoether>** not a problem, rehrar was mentioning something about cyphermarket and sponsorship and free toys and t-shirts
**\<suraeNoether>** so i'm thinking we move the idea into "open discussion" and update from there
**\<suraeNoether>** if folks have recommendations for speakers, we are assuming a decent travel cost on average for speakers, so if we can get a handful of relatively small-cost local-ish speakers, we can also have a decent budget for flying people out from further away
**\<parasew[m]>** there are a lot of contacts from the open source hardware association in denver (open source hardware summit was there last year); i could reach out to ppl (audio engineer, etc.)
**\<sgp\_>** Yeah, my RT Frontier flight is only ~$200 :)
**\<suraeNoether>** i'm thinking a formal call for papers may be in order
**\<suraeNoether>** sgp\_: excellente, come give a taaaaalk on blackballin brother
**\<suraeNoether>** let us have a meeting of the minds
**\<suraeNoether>** all the minds
**\<sarang>** sgp\_: but you're flying Frontier, so you'll pay one way or another.... =p
**\<suraeNoether>** sarang zing
**\<suraeNoether>** more like zi... ziring..
**\<suraeNoether>** nah
**\<suraeNoether>** okay, onto research
**\<sarang>** Buy us a Monero jet and I'll fly everyone there
**\<sgp\_>** Lmao
**\<suraeNoether>** last week, sarang and I concluded that, for now, RuPol may be too risky for us to implement, given the layers of development required
**\<suraeNoether>** essentially un-vettable at this stage
**\<suraeNoether>** once things are more clear, we can actually benchmark it
**\<sarang>** The level of complexity required for verification computation is also unclear
**\<sarang>** The authors left many, many implementation details out of their paper
**\<sarang>** It suffices to say that there is a lot of annoying math still to be worked out
**\<suraeNoether>** but for now, it relies on a previously described scheme that has it's own typographical errors, etc, and at this point even workign out a single example by hand requires beautiful-mind-level of whiteboards on the walls
**\<suraeNoether>** so we are falling back on ruffct for now to see how much the multiexp speedups we learned about during bulletproof implementations could help
**\<sarang>** I've returned to our older RuffCT scheme, working to backport what we've learned from BPs about optimizations and batching
**\<sarang>** jinx
**\<suraeNoether>** im finna shutup now
**\<sarang>** heh
**\<sarang>** We can certainly speed up some operations on individual spend proofs, and that's cool
**\<sarang>** But
**\<sarang>** The possibility of batching some parts of verification are quite intriguing
**\<sarang>** especially relating to fixed group points
**\<sarang>** I'm running some code and tests on this presently
**\<suraeNoether>** in addition to all that, i've been working on the churn paper to formalize the threat model we discussed last week
**\<sarang>** Also, I've finished some updated blackball testing
**\<suraeNoether>** that's going... really well, and i hope to have a draft to the community in a few days
**\<sarang>** My hunch is that we'll see those papers published with shitty information
**\<sarang>** and the associated bad press
**\<suraeNoether>** sarang i will want to dip into your blackball info in writing this to illustrate the negligibility of the gains from heuristic methods
**\<suraeNoether>** i disagree, i think the papers weren't sufficiently FUD-dy to really be worried about it, as long as they clarify "newly found" versus "total found"
**\<sgp\_>** Sounds like a good co-op
**\<suraeNoether>** but, you know, matt green says we have "fake privacy" so
**\<suraeNoether>** :P
**\<kovri-slack> \<oneiric>** lol, really?
**\<suraeNoether>** yeah some tweet from awhile ago \*shrug\*
**\<sarang>** The Zcash mentality is that we offer shitty obfuscation
**\<sarang>** I tend to not really pay attention to it
**\<suraeNoether>** we happen to agree that ring signatures suck and they need to be replaced with something with larger anonymity set sizes
**\<gingeropolous>** when ringsize 42
**\<suraeNoether>** which is why sarang and I never really let go of the sublinear
**\<sarang>** Those papers did a terrible job of differentiating things that are time-based or blockheight-based
**\<suraeNoether>** no big deal
**\<sgp\_>** Has anyone seen this new paper? https://eprint.iacr.org/2018/962
**\<suraeNoether>** we saw a draft, not the final thing, i'm withholding judgement
**\<suraeNoether>** sgp\_: i have seen this thing, but i have not yet read that thing
**\<suraeNoether>** i need to learn about aurora and this thing
**\<sgp\_>** Basically Zerocash applied to computations, no?
**\<sarang>** trusted setup
**\<sgp\_>** Just call them "trusted computations" :p
**\<sarang>** lol
**\<hyc>** still quite expensive, <2 minutes generation time
**\<sarang>** the setup is buried deep w/in the paper
**\<sarang>** gmaxwell noted it in p15
**\<hyc>** pls ignore the men behind the curtain
**\<sgp\_>** Sounds like a typical trusted setup response
**\<suraeNoether>** trusted setup reminds me of the phrase "military grade encryption"
**\<kovri-slack> \<oneiric>** lol, shady indeed
**\<sarang>** Nah
**\<sarang>** People brag about military encryption
**\<suraeNoether>** no no
**\<sarang>** They hide the setup deep within a definition
**\<suraeNoether>** the phrase military grade encryption is usually a tongue-in-cheek reference to a plaintext message
**\<sarang>** =p
**\<hyc>** lol
**\<sarang>** rot26
**\<hyc>** smeaphore at least
**\<kinghat>** are we military grade? or moar better?
**\<hyc>** semaphore, or morse
**\<suraeNoether>** sarang that reminds me
**\<sarang>** ?
**\<sgp\_>** We used a Caesar's Cypher, totally secure. Roman military-grade
**\<suraeNoether>** i really really want to create a cryptocurrency like monero but replacing the bernstein group with an absurdly small group, like order 7000-ish or something, and with a tiny-output hash function
**\<suraeNoether>** just let people go wild in forging signatures
**\<suraeNoether>** just see what happens
**\<suraeNoether>** "when forgecoin moon?"
**\<suraeNoether>** etc
**\<sarang>** I'd like to see a version that uses a curve group with cofactor 1
**\<suraeNoether>** ring size 2
**\<suraeNoether>** anyway
**\<sarang>** yeah
**\<hyc>** that can be the next generation of useless ethereum token
**\<suraeNoether>** so, that's my life for this week: ruffct with sarang and the churn paper, and fantasizing about rubiks-cubes-sized groups as a joke cryptocurrency
**\<suraeNoether>** ohhhh man implementing a rubiks cube on top of ethereum would be \*such a waste of resources you guys\*
**\<sarang>** Yup, I'll be finishing up unit tests on optimized ruffct to get a better idea of batching
**\<suraeNoether>** proving you are making each permutation omg
**\<suraeNoether>** put it on the ledger forever man
**\<sarang>** There was a neat paper I linked earlier about some optimized curve operations
**\<sarang>** they found some better EC formulas in certain special cases
**\<sgp\_>** Ethereum Plays Rubik's Cube
**\<hyc>** hm... rubkis cube solvers are pretty fast these days. would be funny to advertise a rubiks cube-based key system
**\<suraeNoether>** oh yes, i am eager to read that. it seems to be strictly related to optimizations obtained from utilizing analytic formula/expressions for multiexp
**\<suraeNoether>** for example, if you have point P = (x, y) and point Q = (z, w) on the ed25519 curve, we define P+Q using the equations of the elliptic curve, the twisted edwards polynomial equations
**\<sarang>** They discuss some neat work on better addition chains
**\<suraeNoether>** so if you want something like 3P + 4Q very often, you can expand that polynomial expression and exploit the structure within those analytic expressions to speed up the computations
**\<sarang>** Goes to show that this is not a totally solved area of research
**\<sarang>** I don't see it being terribly useful here, mind you
**\<sarang>** Anyone else with something fun to share about recent work, questions, ideas?
**\<sarang>** Here's a link to my quick port of ruffct to my python library: https://github.com/SarangNoether/research-lab/tree/pyruff
**\<sarang>** It's more or less a direct port of the java stuff that will be refactored as needed
**\<sarang>** prototyping only; don't use it anywhere that counts
**\<suraeNoether>** oh, I wanted to point out: Vtnerd is asking for a very reasonable amount of USD/hour to construct a tor-based RPC tool for monero (or something like that), and his FFS is under "ideas" right now
**\<suraeNoether>** i wanted to express my support for that proposal
**\<sarang>** Tell me more about this in relation to kovri
**\<sarang>** ELI5
**\<rehrar>** Would RuffCT be pretty drop in as well? Or would it take large amounts of work to get it in?
**\<sarang>** It'd be some work to safely transition old outputs
**\<sarang>** that's part of the prototyping process
**\<suraeNoether>** afaict this is going to be a parallel thing, independent of kovri
**\<suraeNoether>** but also since it's not inventing new protocols, it should proceed with easier-to-anticipate milestones
**\<suraeNoether>** some folks are of the opinion that multiple tools are beneficial; when it comes to tor, i2p, kovri... i tend to think the most beneficial tools will eventually see the most use
**\<sarang>** rehrar: actual practical ruffct is still a bit pie-in-the-sky; but that's part of our job
**\<sarang>** it has implications on things like address size, for example
**\<sarang>** but we're learning what we can from it
**\<sgp\_>** Only point I need to make is that if we want to get anywhere with blackball research, someone needs to update the pool tool and sneurlax is busy
**\<rehrar>** regarding Tor, I think it would be beneficial to Monero to have the option to run over Tor
**\<sarang>** MRL: Putting The Skunk In Skunkworks
**\<sarang>** sgp\_: link to current work?
**\<suraeNoether>** rehrar: ruffct as-is requires an additional user key, which would bring us to either 3 group elements as your public key, or 4, depending on how you interpret the ruffct paper, and so we may end up doubling our key length (which doubles verification time from loading keys!)
**\<suraeNoether>** sgp\_: any ideas? or does anyone want to help sgp\_ out with the pool tool?
**\<gmaxwell>** suraeNoether: you can change the constants in the curve equation and get a tiny group with basically no other changes in the code, there are tests in libsecp256k1 that work that way.
**\<sgp\_>** https://github.com/sneurlax/xmreuse
**\<suraeNoether>** gmaxwell: delightful :)
**\<kovri-slack> \<oneiric>** yeah, having a public node over tor would be nice. even a hybrid of p2p over tor, rpc over i2p would be sweet
**\<sarang>** gmaxwell: you are referring to a cofactor-1 curve?
**\<sarang>** oh nvm, you mean group size
**\<hyc>** we have moneroworld nodes on tor
**\<rehrar>** Of course it's possible to run Monero over Tor with some finagling. But how cool would it be to run over tor with a command or button press?
**\<rehrar>** Qubes-Whonix is a good way right now btw
**\<sarang>** perhaps we first get the moneroworld nodes upgraded at all...
**\<suraeNoether>** okay, for me, final thoughts... please make comments on the Denver Monero Konferenco FFS here, and we will move it up to Open Discussion: https://forum.getmonero.org/6/ideas/90909/surae-noether-first-denver-monero-konferenco-spring-2019 and for this conference, PLEASE please let me know if you know of someone who I absolutely MUST INVITE TO SPEAK. If you have a favorite speaker, let me know by emailing
**\<suraeNoether>** surae.noether@protonmail.com
**\<suraeNoether>** I'll be sending out first-round invitation emails in the next week or so
**\<suraeNoether>** or just email me because i'm lonely
**\<hyc>** lol. I can cook up a talk
**\<hyc>** by next spring we should have a much better idea of whether/how well randomJS will work
**\<sarang>** If there isn't a talk on RandomJS there will be riots
**\<rehrar>** heck, I may start a Riot anyways
**\<hyc>** lol
**\<rehrar>** it's a decent little app on the Matrix protocol
**\<rehrar>** #nerdjokes
**\<suraeNoether>** cool, we can have a session on hardware and proof of work and maybe invite some asic or fpga manufacturers
**\<hyc>** ah a mini-track, yeah
**\<kovri-slack> \<oneiric>** head-to-head debate hyc v. timolson?
**\<sarang>** Other questions or research topics?
**\<hyc>** though if we've done our work right, no asic/fpga guys will want to speak to us ever again
**\<sarang>** heh
**\<kovri-slack> \<oneiric>** was reading up on ML techniques, would LSTM/regression be helpful for blackball analysis?
**\<sarang>** I don't think so
**\<sarang>** Given our ring sizes and the actual risks involved, we understand it decently well
**\<sarang>** Things like forks will always be more of an issue than random selection errors
**\<sarang>** if that's what you mean oneiric
**\<sarang>** Even a deterministic approach to identify spent rings reveals relatively few, and each of these has a negligible effect on other rings
**\<kovri-slack> \<oneiric>** kind of, I meant applying the learning algo to new forks rather than tuning by hand. I might be misunderstanding blackballing though
**\<sarang>** The risk from forks is spending on both forks, which reveals your spend
**\<sarang>** on-chain risks involve things like pool outputs and set-theoretic analysis
**\<sarang>** The goal of blackballing is to identify \_definitely\_ spent outs
**\<sarang>** and that's a hard game to play that gives you progressively lesser benefits over time
**\<sarang>** I suppose we can begin to wrap up the official meeting
**\<kovri-slack> \<oneiric>** ok, thanks sarang
**\<sarang>** Thoughts on anything that people would like to see investigated for this next week?
**\<sarang>** oneiric: I think some people worry that their outputs can get "caught up" in a blackball list, but this isn't the case
**\<sarang>** The methods we use only determine if it's provable that an output is already spent, which does not affect anyone's funds
**\<gmaxwell>** (the name 'blackball' is really kind of unfortunate.)
**\<sarang>** gmaxwell: agreed
**\<sarang>** I've been using the term "spent note" in my paper drafts
**\<sarang>** I'd prefer something like that or "dead output"
**\<gmaxwell>** Spent Note List (SNL) would hae been much better.
**\<sarang>** We could update it each week, in a Weekend Update
**\<kovri-slack> \<oneiric>** Live from New York..
**\<gmaxwell>** Well, sunday is a day of rest so one should do it on saturday, but perhaps as late as possible..
**\<gmaxwell>** :P
**\<sarang>** Well, thanks to everyone for participating in our meeting; we are now adjourned, and informal convos shall continue

202
_posts/2018-10-22-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-10-22.md Normal file
View file

@ -0,0 +1,202 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-10-22
summary: Surae work, Sarang work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / sarang
---
# Logs
**\<sarang>** OK, welcome to our meeting everyone
**\<sarang>** GREETINGS
**\<kovri-slack1> \<oneiric>** hiyo
**\<sarang>** There is much to discuss today, but I'll try to dwell on particular topics too long
**\<sarang>** FIRST, congrats to everyone on the network upgrade
**\<endogenic>** oneiric btw i have a kovri thing to chat about but couldn't PM you
**\<sarang>** BPs, bigger and better rings, and a host of other fixes are a benefit to our community
**\<kovri-slack1> \<oneiric>** yeah, lost access to clearnet irc temporarily
**\<sarang>** Related to this, the final BP audit report is out: https://github.com/SarangNoether/research-lab/blob/master/audits/bulletproofs/Report-QuarksLab.pdf
**\<sarang>** It was delayed to wait for a bugfix at the time of upgrade
**\<kovri-slack1> \<oneiric>** ^ halfway thru first read, great work by QuarksLabs
**\<sarang>** Yeah, they did an outstanding job, catching things outside of BPs too (hence the delay)
**\<sarang>** On to more things now...
**\<sarang>** There was earlier discussion about making it clear to researchers how to contact us and such, to avoid low-quality repetitive research on old shit
**\<sarang>** I propose an addition to the main project readme: http://paste.debian.net/hidden/6d3a8964/
**\<sarang>** Related to that, and to talks and papers given over the past year-ish relating to "OMG old ringz are bad and everyone is ded", I think a blag post is called for, summarizing all the work we've done to mitigate against ring attacks: http://paste.debian.net/hidden/6d3a8964/
**\<sarang>** Correction, this link is to the blag post: http://paste.debian.net/hidden/ea43fad6/
**\<suraeNoether>** back
**\<sarang>** Neither of these is live, but I'd like to post them soon. They take into account several good comments that were received last week about them
**\<sarang>** If there are no comments over the next day or so, I'll PR them / send to the correct peeps to post
**\<sarang>** Related to the upgrade, it was noted that our output selection has a bit of a bias, in that it selects blocks according to time, and then picks fakes equiprobably within them
**\<sarang>** This is skewed a bit, since some blocks are full and other are empty
**\<suraeNoether>** regarding blackballing/dead txn outputs: there is a very efficient algorithm I'm interested in benchmarking to revisit the question of whether it's worth the lab or the core team maintaining a live deadout list
**\<sarang>** I recommend that we introduce a windowing, where transactions in the chosen block \_and\_ a small number on either side are equiprobably chosen
**\<sarang>** suraeNoether: I now agree with your earlier sentiments that this would be a waste of time
**\<sarang>** especially given our ring increase
**\<suraeNoether>** why not use a rule like "pick block height h, go down to the first non-empty block of height h\* <= h and up to the first non-empty blcok of height h' >= h, and pick from the (inclusive) range [h\*, h']?
**\<suraeNoether>** eh, i suppose details are unimportant for the meeting. :P
**\<suraeNoether>** sarang i'll have some specific numbers to \*prove\* it's a waste of time, though. :P
**\<sarang>** excellent
**\<sarang>** But yeah, it's reasonably easy to mitigate against that bias, and we should
**\<suraeNoether>** cool
**\<selsta>** I have a question about that blog post
**\<sarang>** selsta: go
**\<sarang>** s/blog/blag
**\<selsta>** Is it a good idea to write that we know about an upcoming research paper? Maybe other researchers would stop disclosing research that is in progress to us.
**\<netg>** https://eprint.iacr.org/2018/990 < old?
**\<suraeNoether>** selsta: we've communicated with them about that paper, and they didn't ask for any particular confidentiality or anything. in the past, researchers have contacted us with a paper and asked for confidentiality until publication, and we've kept those promises
**\<suraeNoether>** netg i will read this carefully
**\<selsta>** suraeNoether: okay :)
**\<suraeNoether>** ok, i have two things i want to chat about: firstly, the churn analysis, and second, the monero konferenco
**\<sarang>** May I say one thing first?
**\<suraeNoether>** but i don't want to interrupt sarang's
**\<suraeNoether>** yep
**\<sarang>** Then I believe I'm finished
**\<sarang>** ty
**\<suraeNoether>** np didn't even finish typing
**\<sarang>** I have two paper drafts, one on dual-key signatures and one on spent output sets, that are sitting in no-man's land right now. I'd like us to move those to the official MRL publication list
**\<suraeNoether>** i thought we already had for DLSAG
**\<sarang>** We had not
**\<suraeNoether>** i'm fine with that, and we can reformat the thring signature paper and put them out at the same time with sequential numbers
**\<suraeNoether>** or... we should wait till we find out about a journal for thring
**\<sarang>** Cool, we can arrange PRs later for this
**\<sarang>** selsta: about your comment
**\<suraeNoether>** can you make both links available for the folks who are attending?
**\<sarang>** I also didn't provide details on anything that hasn't already been discussed here publicly and known before those peeps contacted us
**\<sarang>** I'll look up links to the compiled PDFs while suraeNoether discusses
**\<suraeNoether>** okay, coolio
**\<suraeNoether>** so, at our research meeting two weeks ago, i guess it was Oct 1
**\<suraeNoether>** rehrar, sgp, sarang, and others asked for a formalization of the EAE + churn problem
**\<suraeNoether>** in the ensuing two weeks, I've come up with some... disappointing results. and some hopeful results. sort of contradictory
**\<suraeNoether>** not a literal contradiction, or i wouldn't be coming to the community about it
**\<suraeNoether>** so, essentially, i have \*nearly\* formalized a game i'm calling the linkability game, and a specific implementation of this game could be called the fungibility game
**\<suraeNoether>** this quantifies the complexity an adversary faces when trying to link monero transactions
**\<suraeNoether>** compare this to the naive anonymity set questions we began with... "if we churn 7 times with ring size 5, does that mean we have an effective anonymity set of 5^7? who knows!"
**\<suraeNoether>** well, now i have a formal, quantifiable way of assessing the time required for an adversary to find a plausible transaction history that is optimal with respect to some model chosen by the adversary: that is to say, if the adversary thinks they have come up with a new heuristic, I can answer the question "how long does it take to find the most plausible transaction history, according to this heuristic?"
**\<sarang>** It sounds like the counter to the adversary's work is "how many other transaction histories are possible along with the true spends?"
**\<suraeNoether>** the answer to that question confirms previous results from linkability studies: it doesn't take long. Even in a world with \*lots and lots\* of plausible transaction histories, it is fairly quick to find the \*optimally plausible ones\* where plausible is defined by the adversary's model
**\<suraeNoether>** ^ good observation, sarang, they are related questions, but here's what's funny
**\<suraeNoether>** if an adversary wants to find an \_approximately\_ optimal transaction history among N keys with ring size R using some model, they can find it in O(R\*N) time
**\<suraeNoether>** if they want to find an \_exactly\_ optimal trnasaction history, they can do it in O(R\*N^1.5) time
**\<suraeNoether>** this is sort of bad news and sort of good news: this is says "it is never worse than O(R\*N^1.5) time to find these histories, and so the time required is proportional to ring size, and gets more annoying as the blockchain gets bigger"
**\<sarang>** What are the takeaways for this group?
**\<suraeNoether>** oh gosh sorry, yeah
**\<suraeNoether>** sorry, getting lost in the weeds
**\<suraeNoether>** so, bad news: it's fast and efficient to find an optimally plausible solution. good news: the total number of solutions can be made \*really really massive\*
**\<suraeNoether>** even if someone can find the optimally plausible solution in a short period of time, \*all the other possible solutions\* are also plausible
**\<suraeNoether>** so, I asked myself "okay, how can we make it so that there are so many plausible transaction histories that it's unreasonable to decide on any one of them?"
**\<wow-discord> \<sgp>** yes
**\<suraeNoether>** even if you have a great heuristic and you can find the optimally plausible one very quickly, you are vulnerable to \*not\* catching someone who uses your heuristics to greedily make their transactions as invisible as possible
**\<suraeNoether>** so, for example, there are at least a billion transaction histories that are \*plausible\* if you deposit 16 outputs with a ring size of 10
**\<suraeNoether>** there are 10^81 plausible trnasaction histories if you deposit 52 outputs at ring size 100
**\<sarang>** So the question becomes "what number is acceptable"?
**\<wow-discord> \<sgp>** how are 10, 81, 52, and 100 related?
**\<sarang>** (not from a theory perspective, from a practical one)
**\<suraeNoether>** so: time complexity to find \*any\* solution is linearly related to ring size, and the total number of possible transaction histories can be computed precisely using this formula: (((R-1)^(R-1))/(R^(R-2)))^k where k = # of outputs deposited
**\<suraeNoether>** sgp\_[m]: merely related according to that formula
**\<wow-discord> \<sgp>** thanks, gives me some context
**\<suraeNoether>** i picked 10 and 100 ring members respectively as examples that are one order of magnitude apart, and i picked a billion (10^9) and big (10^81) essentially just to look at the behavior, at a glance
**\<suraeNoether>** so, this actually demonstrates a few things
**\<suraeNoether>** firstly: someone who is making only a few deposits, say 3, with no churn whatsoever, at a ring size of 11 is like ... dealing with 76 or so possible transaction histories
**\<suraeNoether>** which is unnaceptable for someone whose safety depends on Monero
**\<suraeNoether>** this means people transacting with untrusted 3rd parties should be using at least one churn between transactions
**\<moneromooo>** What do you call "transaction history" ?
**\<suraeNoether>** moneromooo: a plausible transaction history is a matching between key images and one-time output keys. there is only one "true" transaction history, which corresponds to "which key was used to compute this key image?"
**\<suraeNoether>** if some signatures are mutually incompatible, you end up not getting a matching
**\<moneromooo>** Thanks.
**\<suraeNoether>** np
**\<sarang>** (e.g. from the graph representation we talked about a while ago)
**\<suraeNoether>** yep
**\<sarang>** I assume it also goes without saying that churns should follow spend timing patterns
**\<sarang>** but this is a separate issue from the idea of transaction matchings
**\<suraeNoether>** yes
**\<suraeNoether>** so, the second thing this demonstrates is the power of plausible deniability, which really only matters for a court-of-law sort of situation as opposed to a more nefarious type who is trying to literally hunt or track down people using the monero blockchain
**\<suraeNoether>** another thing: this same approach can be used to link commitments and nullifiers in zcash; the goodness of your linking is dependent upon your heuristics (like timing as people leave and enter the shielded pool, or like amount-matching with the transparent-pool trnasactions) just like in monero. the primary difference is that the total number of edges to match is much much higher in zcash, at least whenever
**\<suraeNoether>** the shielded pool is big enough
**\<suraeNoether>** so it takes a lot longer, and there is less information to base heuristics on
**\<sarang>** In the interest of time, what are our next steps?
**\<sarang>** These are excellent results
**\<suraeNoether>** i think a priority of MRL should be to seek out replacements for ring signatures
**\<sarang>** of course
**\<suraeNoether>** i think writing a paper on the topic will 1) do Monero a world of good in the long run but 2) will be FUDbait in the short run
**\<suraeNoether>** sort of like my MRL-0001 paper
**\<sarang>** Our users want to know what churn should look like
**\<sarang>** And before we replace ring sigs, understanding the benefits to increasing ring size is also important
**\<suraeNoether>** well, that's a good question: my results suggest that churning is helpful, but far less important than \*diluting your deposits.\* let me give you an example
**\<sgp\_>** yeah, I agree churning and ringsize should be the high priority since we have them right now
**\<sarang>** IMO we should write up the relevant portions of these results and give some insights into churn behavior and how ring size affects it
**\<sarang>** and then best practices can be built from that
**\<sarang>** formalization and generalization to other projects could come after
**\<sgp\_>** sarang please yes :) it's the material the community can best understand
**\<suraeNoether>** if you are depositing more than 155 outputs at our current ring size, the adversary has more possible transaciotn histories than the number of fundamental particles in the universe.
**\<sarang>** sure
**\<suraeNoether>** and that has no information about churn in it whatsoever
**\<sarang>** ok
**\<suraeNoether>** but we can re-interpret it: instead of 155 outputs, say we have 1 output we churn 154 times. same answer
**\<sarang>** what security level should we strive for?
**\<suraeNoether>** i have no clue, especially since this is a heuristic approach; if we shoot for 10^120, i'm pretty sure we'll be good to go
**\<sarang>** I'm not sure 2^256 is necessary for these kinds of plausible deniability
**\<sarang>** For rings we only have 11 options =p
**\<suraeNoether>** let's say we want to obscure 6 outputs by churning 6 times each. that's 216 keys in total. at ring size 10, there are 10^127 transaction histories
**\<suraeNoether>** oh no that's 36 keys. :P
**\<suraeNoether>** let's say 14 keys 14 times. that gives us 10^114 transaction histories
**\<sarang>** Cool, let's get a table like this into a tech note, along with the relevant results
**\<suraeNoether>** i don't have a good way of saying "here, churn 7 times at ring size 11"
**\<suraeNoether>** ok cool
**\<sarang>** and it'll be a great contribution
**\<sarang>** excellent work suraeNoether on this
**\<moneromooo>** I still hate churning though.
**\<suraeNoether>** moneromooo same same
**\<sarang>** due to bloat?
**\<sarang>** which it certainly does
**\<moneromooo>** Yes. It encourages people to shit on everyone's else resources.
**\<sarang>** suraeNoether and I had discussed that earlier too, that we need to provide answers about reasonable threat models that minimize bloat
**\<sarang>** and obv different user types have different requirements for their privacy/safety
**\<suraeNoether>** long story short: don't use KYC/AML exchanges, and if you do, make sure you churn at least once before your deposits... and more often if you plan on making many deposits that you suspect are "marked..." and dilute your deposits with other outputs as much as possible.
**\<sarang>** it's the "as much as possible" and "at least" that this note should attempt to quantify
**\<sgp\_>** yes, thanks
**\<sarang>** cool
**\<suraeNoether>** except i don't think it's directly quantifiable :( if we say "a cryptographic number of plausible transaction histories, so 10^88 or bigger, or so", this is essentially arbitrarily chosen
**\<suraeNoether>** but we'll chat more about it later
**\<sarang>** Well, whatever we do (or don't do) eventually needs to be distilled to best practices
**\<sarang>** or users will just do whatever they think is helpful
**\<sarang>** and that might just lead to bloat with no benefit
**\<sarang>** Anyway, let's move on for now
**\<sarang>** Any other quick news suraeNoether ?
**\<sarang>** (10 min officially remain)
**\<suraeNoether>** the second thing i wanted to talk to everyone about is the monero konferenco. in order to move forward in the funding process, please leave ANY COMMENT, positive, negative, or neutral, in this thread: https://forum.getmonero.org/6/ideas/90909/surae-noether-first-denver-monero-konferenco-spring-2019
**\<suraeNoether>** Please keep in mind that things like booking the event or inviting speakers... these are unlikely to happen before funding begins, and the longer we wait, the less likely it is we can get all the things we want to get
**\<sarang>** ^
**\<sarang>** There's been informal speaking interest from some top-quality folks
**\<suraeNoether>** yes, several
**\<sarang>** (won't put names out there yet)
**\<suraeNoether>** also, I conferred with fluffypony re: timing for next year
**\<suraeNoether>** due to the lateness of the year, the coincidence with consensus, etc, we decided on the weekend of June 22nd
**\<suraeNoether>** unless booking goes weird, in which case we will shoot for June 15th as a back-up date
**\<sarang>** sweet
**\<suraeNoether>** I know i was mentioning April 27 last week, but that's 1) too close to consensus and graduation, and 2) pushing it back earlier seems unwise.
**\<sarang>** To wrap up, I have some action-item links to list here
**\<suraeNoether>** excellente
**\<sarang>** The dual-key signature paper, which will be pushed to main MRL page unless there are comments: https://v2.overleaf.com/read/vcyxgpntfsgz
**\<sarang>** The spent-output paper, same deal: https://v2.overleaf.com/read/xtbwpvqvtqmm
**\<sarang>** The proposed addition to the readme, that discusses research contacts: http://paste.debian.net/hidden/6d3a8964/
**\<sarang>** The proposed blag post responding to ring attacks: http://paste.debian.net/hidden/ea43fad6/
**\<kovri-slack1> \<rehrar>** Oh shoot! None of my comments have relayed.
**\<kovri-slack1> \<rehrar>** I have been talking this whole time.
**\<sarang>** Action will be taken on all those links if I hear no comments or suggestions
**\<kovri-slack1> \<rehrar>** And thought everyone has been ignoring me cuz they hate me.
**\<sarang>** And of course, suraeNoether's FFS on the conference would like comments: https://forum.getmonero.org/6/ideas/90909/surae-noether-first-denver-monero-konferenco-spring-2019
**\<kovri-slack1> \<rehrar>** I have many many comments on Brandon's work.
**\<sarang>** rehrar[m]: hullo
**\<sarang>** We can chat about all of this once we adjourn!
**\<kovri-slack1> \<rehrar>** Ok.
**\<sarang>** Any other last-minute wrap-up?
**\<suraeNoether>** i'm very eager to see what rehrar[m] had to say
**\<suraeNoether>** :P
**\<sarang>** Yes! OK, lets adjourn and continue discussion
**\<sarang>** Thanks to all
**\<sarang>** hullo rehrar[m] !
**\<binaryFate>** sarang title "Sets of spent notes" is ambiguous wording
**\<kovri-slack1> \<oneiric>** same, thanks for the meeting
**\<binaryFate>** maybe +Notes on "Sets of spent"+

172
_posts/2018-10-29-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-10-29.md Normal file
View file

@ -0,0 +1,172 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-10-29
summary: Surae work, Sarang work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / sarang
---
# Logs
**\<sarang>** Greetings to everyone, and welcome to our meeting, which will likely go pretty quickly
**\<sarang>** Pipe in if you're here!
**\<sarang>** To start with, let's review happenings over the last week or so
**\<sarang>** suraeNoether: care to begin?
**\<hyc>** pipe
**\<sarang>** |
**\<suraeNoether>** Gosh sure
**\<lurkinandlearnin>** I'm tuning in
**\<suraeNoether>** This past week, I've been working on my graph-theoretic security paper
**\<suraeNoether>** calling it a security paper now because i'm pretty sure that my main contribution is formalizing a couple of security games, using graph theory
**\<sarang>** I like the idea of using known graph theory to establish bounds on identifying possible spend histories
**\<hyc>** absolutely. what else is it besides a graph problem
**\<sarang>** those bounds, coupled with a goal for an "acceptable" number of alternate histories, is a neat approach to practical fungibility
**\<sarang>** for sure
**\<suraeNoether>** other than that, I've been chatting with folks about preparing for Monero Konferenco, and having meetings on my non-profit MAGIC (PM me if interested). i also spent some time last week working on a constant sized ring signature scheme, and i'm like, 50/50 on whether or not i found a problem with it. :P
**\<sarang>** To what extent can we extract churn practices from this?
**\<sarang>** I consider that to be an important open question
**\<msvb-lab>** Hello.
**\<suraeNoether>** it's the first step in a long process; all i've confirmed using this message is that at least one churn for paranoid users is probably wise. i'm honestly not sure if there \*is\* a good answer to that question, sarang, and i'm not sure if htere's a good way to formalize \*the lack of an answer\*
**\<suraeNoether>** hello msvb-lab
**\<hyc>** what's the goal? EABE attack establishes that 1 churn minimum is always required
**\<suraeNoether>** s/message/method
**\<sarang>** I would like us to be able to give semi-quantifiable results to avoid unnecessary churn
**\<sarang>** and churn that might harm fungibility if done badly
**\<sarang>** (and would also bloat the chain)
**\<suraeNoether>** hyc well, first and primary goal is to have a document to point at when folks start talking about ring intersection attacks in the future. secondary goal is to lay the groundwork for future security work. third goal is to have a nice publication come out of MRL, imo
**\<hyc>** ^ great
**\<sarang>** It'll be a nice extended complement to our previous tech note on spends
**\<hyc>** btw, I have done a bad churn recently. did a sweep with multiple outputs, then received another exchange withdrawal.
**\<suraeNoether>** if we can get some quantifiable results on churn or ring size, that's great, but my hidden secret opinion is that: any choice we make in that regard is more or less arbitrary and informed by magic numbers being selected for convenience, not necessarily real security, and this is a fundamental problem with ring signatures
**\<hyc>** then did another sweep.
**\<hyc>** but the multiple outputs from the previous sweep are all obviously from the same block...
**\<sarang>** Right, and having something to back up that negative answer will be just as useful
**\<sarang>** So yeah, I look forward to the continuation of this work
**\<sarang>** I'll be reading over the current stuff today or tomorrow suraeNoether
**\<suraeNoether>** it's ... research. jerks and starts, i don't know everything yet or hte paper would already be written :D
**\<sarang>** Questions on this? Going once...
**\<lurkinandlearnin>** Sorry to divert the conversation but quick question: Are ring signatures not constant sized now? What difference would this make?
**\<sarang>** They are not constant
**\<sarang>** They grow linearly with the # of inputs/fakes
**\<sarang>** All existing constant methods suffer huge drawbacks, usually in terms of trust
**\<sarang>** Going twice...
**\<sarang>** OK, suraeNoether, another topic of your interest?
**\<suraeNoether>** lurkinandlearnin: ring sigs are linearly sized now, we are looking at a logarithmic scheme. the smaller our signatures are, making some qualifying assumptions about verificaiton times, the lower the cost for a node to join our network
**\<suraeNoether>** uhm i'm just going ot pass it onto sarang for now and if anyone wants to chat about other topics later today, i'll be here all day
**\<sarang>** OK!
**\<sarang>** We've been examining output selection since our recent switch to a gamma distribution
**\<lurkinandlearnin>** Thanks for the answers. I'll be sure to read up on this.
**\<sarang>** Previously, there was a heuristic about assuming the newest ring member was the spender (but it can't be proven)
**\<sarang>** So we moved to a distribution that mirrors expected spend patterns
**\<sarang>** However, we choose blocks and then txns within those blocks, and the appearance of more empty blocks due to Bulletproofs, and in general the distribution of txns per block, means the selection has bias
**\<sarang>** You can read about this on reddit, or on the many high-quality outlets that report on reddit posts
**\<sarang>** Long term, we need a better strategy for handling coinbase outputs
**\<sarang>** Short term, we're tweaking the algorithm to select from a small group of blocks to mitigate against this
**\<suraeNoether>** "on the many high-quality outlets that report on reddit posts" <--- lulz
**\<sarang>** I predict it will cut the number of coinbase per ring in half from what we see now
**\<sarang>** This is part of the 0.4 release
**\<sarang>** and is not consensus
**\<suraeNoether>** i think there's a strong argument to be made that coinbase-only is used in coinbase transactions, but i'm concerned about provably spent sets amongst coinbase transactions becoming an issue
**\<sarang>** It's subtle
**\<sarang>** and public pools that broadcast mined outputs and payout txns make it trickier
**\<sarang>** There is not a silver bullet to this
**\<sarang>** But we have a mitigating fix in the wings, and are certainly open to more data that can help inform the decision of how best to handle this
**\<lurkinandlearnin>** Is just not selecting from empty blocks not an option?
**\<sarang>** It would be great if pools didn't broadcast payouts like this, and if we also had data on hand for coinbase spend patterns
**\<sarang>** lurkinandlearnin: then you could never spend coinbase
**\<sarang>** they'd be instantly identified
**\<lurkinandlearnin>** aha
**\<sarang>** So while what we have now is not the final answer to this, our current selection algo is arguably a big improvement over previous iterations
**\<sarang>** and is getting better
**\<sarang>** Having bigger rings is also a built-in mitigation
**\<sarang>** Now you are all equipped to handle the flood of posts we'll be getting on this
**\<lurkinandlearnin>** The work Justin did on showing that blackballing is no longer necessary thanks to bigger rings was very cool
**\<sarang>** you mean "spent output analysis" =p
**\<sarang>** blackballing sounds dangerous and non-deterministic, which it isn't
**\<sarang>** the MRL-0007 tech note has a nice table about this
**\<lurkinandlearnin>** I had no idea where the term came from haha
**\<sarang>** motto: modern transactions are fine
**\<sarang>** counterpoint: but about all those papers that were published
**\<sarang>** response: modern transactions are fine
**\<lurkinandlearnin>** They keep quoting the same old papers
**\<sarang>** Moving on from this, work continues on the StringCT optimizations from our Bulletproofs plumbing
**\<IsthmusCrypto>** Ooh wait one last question on that
**\<IsthmusCrypto>** Speaking of "modern transactions are fine" does anybody know about code for generating Plot 5 in Malte Möser?
**\<sarang>** sure
**\<IsthmusCrypto>** https://usercontent.irccloud-cdn.com/file/EH9Lwt8u/Screen%20Shot%202018-10-29%20at%2010.11.42.png
**\<IsthmusCrypto>** It seems like the best antiFUD would be extending this plot to present time
**\<sarang>** They didn't release their code (unfortunately far too common) AFAIK
**\<sarang>** You could get it from a modification to the spent-output tool
**\<sarang>** but the MRL-0007 table basically covers it
**\<IsthmusCrypto>** Cool, it'd be nice anti-FUD to use an extended Moser paper to keep people from stressing about Moser :- )
**\<sarang>** Using single-chain analysis, there are exactly 5 post-ct outputs that are known spent using our methods
**\<sarang>** and those were from a research paper that generated them on purpose for testing
**\<IsthmusCrypto>** Awesome, is MRL-007 in the repo? I'll check it out and let meeting conversation move along 👍
**\<sarang>** It's on my repo, will PR it to the main site once I make a gitlab account and set that up
**\<sarang>** https://github.com/SarangNoether/research-lab/tree/master/publications/bulletins/MRL-0007-spent
**\<sarang>** So yeah, StringCT optimizations show promise and we'll continue looking into them as we get more data on optimal ring sizes
**\<sarang>** Its signature scheme is being updated at suraeNoether's suggestion to harden against key cancellation
**\<sarang>** No definite plans on changing CT schemes yet, mind you, just preliminary stuff in the wings
**\<lurkinandlearnin>** Diversion #2: I'd be interested to know what you guys think about the traceability arising from visible fees. And if it is a threat, what is the best way to mitigate it?
**\<sarang>** Any questions on RingCT schemes, output selection, or spent-output analysis?
**\<notmike>** y
**\<sarang>** lurkinandlearnin: restricting fee amounts
**\<sarang>** it's been suggested
**\<sarang>** as it could be a fingerprinting method in theory
**\<suraeNoether>** sarang: "Using single-chain analysis, there are exactly 5 post-ct outputs that are known spent using our methods" <-- there exists a better method, but we have not deemed it important enough to code up rigorously enough to catch any larger sets, fwiw
**\<sarang>** yes
**\<suraeNoether>** lurkinandlearnin: visible fees are technically a concern, technically
**\<sarang>** statistically it's very unlikely to get set union problems with our large rings
**\<suraeNoether>** we have these dynamic fees, and so if you sign a transaction well before it's broadcast, the fee computed will be linkable back to the height when it was signed
**\<sarang>** notmike: you had a question also?
**\<moneromooo>** The fee is based on weight and the time at which it is made. Harly much of a fingerprinting thing.
**\<moneromooo>** Admittedly, there's also the size of the txpool at the time though.
**\<suraeNoether>** this gives a route for linkability to identify cold signers
**\<moneromooo>** (one bit)
**\<sarang>** moneromooo: yeah, not necessarily very useful, but still one of those things that isn't mandated
**\<sarang>** I'm not particularly concerned about it
**\<moneromooo>** And both weight and time of tx are already essentially public.
**\<suraeNoether>** but overall encrypting fees has a whole bunch of engineering headaches associated with it that are not worth the security risk that the unencrypted fees represent, imo
**\<suraeNoether>** basically the worst thing that can happen is someone identifies that a transaction was signed on an airgapped computer and a significant delay in broadcasting occurred
**\<sarang>** suraeNoether: there's encrypting fees, and then there's mandating set options
**\<suraeNoether>** i shouldn't say worst, because there's always something worse
**\<suraeNoether>** yeah, i personally would prefer 3 fee values, low medium and high
**\<suraeNoether>** but transparent
**\<suraeNoether>** or just low and high
**\<lurkinandlearnin>** Yes set transparent values seems sensible
**\<moneromooo>** With the gamma selection, you can already tell, because there's a fairly hard right wall.
**\<IsthmusCrypto>** "this gives a route for linkability to identify cold signers" < decoy ages does this
**\<IsthmusCrypto>** Oh, yea, exactly @moneromooo
**\<IsthmusCrypto>** Agree with @suraeNoether - fixed & plaintext
**\<lurkinandlearnin>** So the risks of transaparent fees are strictly timing/delay based and not related to what service/wallet was used to make a transaction?
**\<sarang>** Well a wallet can choose whatever it wants
**\<sarang>** if Sarangwallet always chooses a bonkers fee value...
**\<lurkinandlearnin>** I.e are all big services using the same method of dynamic fees?
**\<moneromooo>** I don't think it's selectable now unless you do some surgery on the wallet.
**\<moneromooo>** Not 100% sure though. Do check if you want to know for sure.
**\<hyc>** right, anyone can always tweak their own copy of wallet code and do whatever
**\<IsthmusCrypto>** I think the lowest-hanging privacy detriments will be wallet software and exchanges that use fixed or non-standard fee calculations
**\<lurkinandlearnin>** But for example if a service were compromised and was forced to use some unique fee structure, this would be a subtle way of making users traceable?
**\<IsthmusCrypto>** @lurkinandlearnin Yes. Compromized or just lazy
**\<IsthmusCrypto>** Hah, in addition to KYC we should start talking about MYC (mark your customer)
**\<sarang>** Making it consensus could mitigate
**\<sarang>** as has been discussed before
**\<sarang>** To ensure time is respected, were there questions or comments on other topics discussed so far? We can certainly fee talk afterward
**\<suraeNoether>** IsthmusCrypto: actually... yeah
**\<IsthmusCrypto>** I'll hold other fee thoughts until after the meeting
**\<sarang>** I will be stepping out in about 5 minutes for an unrelated meeting
**\<sarang>** but that's all I have to discuss personally
**\<lurkinandlearnin>** Output selection also is not consensus of course, right?
**\<sarang>** correct
**\<suraeNoether>** does anyone have any topics they want us to chat about today?
**\<lurkinandlearnin>** Maybe another potential for the newly invented MYC threat haha
**\<sarang>** You can't enforce it in any good way
**\<lurkinandlearnin>** Yes it seems clear that would be much harder than doing it for fees
**\<sarang>** But if you don't trust whomever is doing your transactions with your keys, you're hosed in many ways
**\<sarang>** it's all about the threat model
**\<moneromooo>** It (if a service were compromised and was forced to use some unique fee structure) would be stupid, as you don't get more info than getting a view of the service's output txes.
**\<moneromooo>** Unless someone can show something more :)
**\<sarang>** I must unfortunately take off for an hour now
**\<suraeNoether>** ok, let's call this meeting good
**\<suraeNoether>** good job, sarang
**\<suraeNoether>** but we can just continue talking at our leisure. :P </meeting>

126
_posts/2018-11-05-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-11-05.md Normal file
View file

@ -0,0 +1,126 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-11-05
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / sarang
---
# Logs
**\<sarang>** Right right, let's begin our meeting now
**\<sarang>** First, GREETINGS to/from all
**\<sarang>** hello
**\<sgp\_>** hello
**\<sarang>** ping binaryFate dEBRUYNE endogenic hyc IsthmusCrypto gmaxwell gingeropolous moneromooo parasew[m] rehrar rrol[m] stoffu smooth UkoeHB etc
**\<sarang>** small crowd today
**\<parasew[m]>** hi
**\<sarang>** Even so, RESEARCH UPDATE time
**\<sarang>** I've done some rearranging with the Lab's public-facing presentation
**\<sarang>** We'll be routing the old lab.getmonero.org to the new getmonero.org MRL landing page
**\<sgp\_>** nice
**\<rehrar>** I'm here
**\<sarang>** This allows for translations of things like abstracts, and lets us PR new papers
**\<sarang>** Once this gets merged over on monero-site (hint hint nudge nudge), the three newest MRL publications will appear there
**\<sarang>** English translations only for those papers' abstracts, for the moment
**\<sarang>** Anyway, PR is open there: https://repo.getmonero.org/monero-project/monero-site/merge\_requests/950
**\<sarang>** Some format changes too; review if you like
**\<sarang>** I've tossed a basic noninteractive musig implementation over to the sublinear prototyping code for testing purposes
**\<sarang>** The usual lit review
**\<sarang>** And a lot of investigations on output selection since the upgrade
**\<sarang>** Any questions/comments on these items?
**\<sgp\_>** do you think it would be useful to have another bulletproof-type video talking about the recent selection changes and possible options going forward? It could be much shorter, perhaps 20-30 minutes
**\<sarang>** I don't consider there to be consensus on the best way to iterate on that
**\<sarang>** so it's not clear what user benefit there would be, except "it's better than before, and we're working on it"
**\<sarang>** :/
**\<sgp\_>** it could be useful just to get the info out there. depends on user feedback I suppose
**\<sgp\_>** most people probably don't care
**\<sarang>** We certainly could, but I also don't want to cause unnecessary FUD
**\<sarang>** My standard line has become "output selection is one layer we use to keep transactions safe; it's been iterated many times over the project's history, and continues to be"
**\<sgp\_>** all right, we can move on then
**\<sarang>** as with many heuristics, a suboptimal selection algorithm is not a spend proof
**\<sarang>** ring signatures continue to do exactly what it says on the box
**\<sarang>** I'm running a workshop in Chicago later this week, offering hands-on coding with some basic crypto constructions in Python, practicing RPC calls and explorer APIs, and maybe writing some C++ unit tests
**\<sgp\_>** I'm really interested to hear how these technical workshops go
**\<parasew[m]>** very nice, sarang.
**\<sarang>** Folks will get a chance to implement Schnorr sigs and some commitment code
**\<sarang>** Otherwise, I continue to move forward on ring sig code/tests, some graph analysis that moves our spent-output work forward to examine complexity, etc
**\<sarang>** Does anyone else have topics of interest to discuss or ask about? Or doing some work that's of interest to the group?
**\<suraeNoether>** hey everyone, sorry for my delay
**\<sarang>** np
**\<sarang>** I just finished my brief updates
**\<sarang>** This is a good place to jump in
**\<suraeNoether>** well, this weekend I spent time on matching and churn and benchmarking the known traceability attacks on monero, and how to translate similar attacks on zcash into this framework
**\<suraeNoether>** worked on the paper for that a bit
**\<suraeNoether>** chatted with rehrar on the phone regarding the monero konferenco
**\<suraeNoether>** i'm starting to reach out to speakers for formal invitations
**\<suraeNoether>** aaaand yeah, slow weekend, i've been ill :(
**\<suraeNoether>** i'll hopefully be pushing a bipartite graph-theoretic benchmarking tool some time this week
**\<suraeNoether>** hopefully first draft of this benchmark paper will be available by end of november
**\<sarang>** This graph matching work is quite excellent
**\<sarang>** It links the complexity of determining possible spends with computational problems in graph theory
**\<suraeNoether>** yeah, we're getting very good information on the raw computational effort and time an adversary would have to spend to "unravel" monero
**\<sarang>** Can you elaborate on the tool?
**\<suraeNoether>** sur
**\<suraeNoether>** sure\*
**\<suraeNoether>** the tool is essentially going to compute maximal matchings on randomly generated graphs of specified properties (like number of nodes, connectivity, etc) with the intent of estimating, ballpark, the constants associated with big-oh timing
**\<suraeNoether>** for those of you unfamiliar: https://en.wikipedia.org/wiki/Big\_O\_notation
**\<sarang>** Which algorithm(s) in particular?
**\<suraeNoether>** https://en.wikipedia.org/wiki/Hopcroft%E2%80%93Karp\_algorithm
**\<sarang>** great
**\<suraeNoether>** so, essentially, finding an optimal matching under some null model is the same as finding a maximal matching of a related graph, which is the same as finding augmenting paths for existing matching, and all that boils down to...
**\<suraeNoether>** breadth-first searches
**\<rehrar>** you guys are the bees knees
**\<suraeNoether>** so the idea is this
**\<sarang>** Oh, a quick housekeeping note (lest I forget) that suraeNoether and I have an open funding request for an upcoming Stanford academic conference... and there are other open requests in need of support too: https://forum.getmonero.org/8/funding-required
**\<suraeNoether>** if we can estimate a ballpark constant k such that it takes, worst-case, k\*r\*n^1.5 units of time to find a maximal matching on an r-regular bipartite graph with 2n nodes in it, using a dumb computer with a dumb algorithm that isn't parallelized, we can begin estimating what a large-scale perfect matching disclosure attack would do to Monero. (see here:
**\<suraeNoether>** https://link.springer.com/chapter/10.1007/978-3-540-70630-4\_2 )
**\<suraeNoether>** this literally quantifies the urgency with which we need to replace ring signatures
**\<suraeNoether>** i have some expectations of the results, but we'll see how it all unrolls
**\<suraeNoether>** \*and for those who are interested\* that paper above is not one-to-one directly correlatable with Monero. comparing the results from that paper to our system is inappropriate for a handful of reasons
**\<suraeNoether>** if anything, that paper seems more related to "what would happen if we did a fluffypony styled 30-day timed zcash sidechain?"
**\<sarang>** but it's a great first approach
**\<suraeNoether>** yeah, and i'm eager to apply the results therein with the zcash turnstile
**\<fluffypony>** what's the zcash turnstile? I haven't been following recently with the CLI and GUI releases
**\<sarang>** You can't go sprout to sapling
**\<sarang>** you have to sent to transparent, and then to sapling
**\<suraeNoether>** yep: sprout -> transparent -> sapling
**\<sarang>** They plan to release a tool to help users not fuck it up, but I hear it won't be out for a couple months
**\<sarang>** IMO it's a terrible idea to do it this way
**\<sarang>** They call it "turnstile" to make it seem like Fancy Moon Math
**\<suraeNoether>** nah, they called it that for auditing reasons
**\<sarang>** Oh, I know why they want it
**\<suraeNoether>** they want to demonstrate exactly as many zcash exist as intended
**\<sarang>** but it's a terrible idea and the name softens it
**\<suraeNoether>** security be damned, i guess. :P
**\<sarang>** Not offering users help in doing it safely is dumb as rocks
**\<binaryFate>** auditing reasons is an admission you don't trust your math/implementation
**\<gmaxwell>** it's an implicit admission that they could be inflated...
**\<sarang>** I did hear that they're backing off the "eventually make sprout unspendable" bandwagon
**\<sarang>** so that's good
**\<sarang>** (that was also dumb as rocks IMO)
**\<suraeNoether>** agreed
**\<suraeNoether>** anyway
**\<sgp\_>** I offered to help them mitigate turnstile privacy loss. We'll see how good we can get, but it will be a bloodbath no matter what, especially since many people have already transitioned
**\<gmaxwell>** thats a pretty big albatross though... an extra gigabyte of key data wallets need ot have to support it?
**\<sarang>** They should have released the tool and clear instructions to use it
**\<sarang>** gmaxwell: I consider deprecation of spend ability to be a huge violation of the "social contract" of the asset
**\<suraeNoether>** sarang i'm not sure if they've backed off of that. saw zooko brag about backwards incompatibility on twitter. :P
**\<sarang>** Ugh, I had read that they were \_not\_ looking toward deprecation. Boo
**\<binaryFate>** ring signatures for turnstile would help and keep auditing possible :P
**\<suraeNoether>** anyway, this is off-topic for the research meeting BUT point of the matter is that a modified version of the matching game applies to zcash and it's made more interesting by adding the existence of a second shielded pool
**\<suraeNoether>** binaryFate: +1
**\<suraeNoether>** i would invest in zcash and put it all into the sapling shielded pool, but i wouldn't be able to be confident they'll deprecate \*that\* shielded pool and force me through a transparent pool again in the future
**\<suraeNoether>** they can promise that they are abandoning their transparent pool all they like
**\<suraeNoether>** i'll believe it when i see it
**\<sarang>** sure
**\<suraeNoether>** seriously off topic
**\<sarang>** But good to keep in mind our goals relative to what's happening in this space
**\<sarang>** noooo
**\<sarang>** -lounge
**\<sarang>** Anyone else with Fun Things to share?
**\<rehrar>** #monero-too-many-rooms-discussion
**\<sarang>** stahp
**\<suraeNoether>** i tried to get #monero-recipes off the ground, but noooo
**\<suraeNoether>** ok, i guess unless folks have more to talk about
**\<suraeNoether>** we can call this a /meeting

220
_posts/2018-11-12-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-11-12.md Normal file
View file

@ -0,0 +1,220 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-11-12
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<suraeNoether>** howdy everyone!
**\<nioc>** meow
**\<OpenSorceress>** :D
**\<sarang>** hiyo
**\<TheFuzzStone[m]>** Sup!
**\<rehrar>** hiyo
**\<rehrar>** .....to quote sarang
**\<suraeNoether>** so, let's flip the usual order of the meeting to allow for questions at the beginning
**\<suraeNoether>** i like that
**\<suraeNoether>** in fact, i'm going to call THAT the new "usual order"
**\<suraeNoether>** so, the agenda today is 1) questions, 2) sarang's research this week and last, 3) mine, and 4) any other project discussion that's remotely relevant to research
**\<sarang>** roger
**\<suraeNoether>** so, someone give me and sarang your top two questions :D
**\<nioc>** any updates on Konferemco preparations?
**\<rehrar>** I should have a logo and branding guidelines today
**\<rehrar>** in regards to MRL, where are we in the churn and privacy formalizations?
**\<rehrar>** although I assume this will be talked about with your report of the week suraeNoether
**\<suraeNoether>** that is precisely the case
**\<suraeNoether>** i'm in the midst of getting hard numbers for a timing for a practical attack
**\<suraeNoether>** sarang and i have discovered an anonymity metric that could give us a guideline for "how rapidly we need to chagne our ring size with respect to blockchain size to maintain our current levels of anonymity."
**\<suraeNoether>** this is a very useful metric, but it's dangerous to misinterpret it
**\<sarang>** Let us shift that to the later agendum
**\<suraeNoether>** so we're avoiding making formal proclamations about it, but we are going to use it as a rough guideline for future ring size increases
**\<suraeNoether>** agreed
**\<suraeNoether>** nioc our conference organizer has been checking out a few alternative venues, and we have already identified some vendors for things like catering
**\<sarang>** I have a question... how the hell do I build the dalek bulletproof rust implementation for timing testing??!?!?!?!
**\<sarang>** I know jack shiz about rust
**\<suraeNoether>** that's an excellent question that occurred to me yesterday afternoon!
**\<sarang>** they claim to be bonkers fast, even compared to libsecp256k1 (which seems nutso to me)
**\<suraeNoether>** they are claiming some mad speed gainz on top of your already mad speed gainz
**\<sarang>** They don't have batch verification yet tho
**\<sarang>** (it's on their issue list)
**\<suraeNoether>** jfc
**\<sarang>** So I want to run timing tests myself to see
**\<suraeNoether>** if that's the case, then... man that implementation is bonker fast like what-what
**\<sarang>** I don't think they're lying, but I'm also naturally skeptical
**\<sarang>** I don't find it terribly relevant since we're already pretty fast
**\<suraeNoether>** i suspect that bulletproofs are going to benefit from 40 years of optimizations in linear algebra and ECC very very quickly
**\<sarang>** and any changes specific to underlying curve architecture aren't useful for us ATM
**\<rehrar>** sarang: what if it's so fast it can reverse the blackchain continuum?
**\<rehrar>** somethign to look into
**\<sarang>** Ah yes, the chain shrinks over time
**\<sarang>** negachain
**\<suraeNoether>** the blackchain continuum hypothesis, by tom clancy
**\<suraeNoether>** or dan brown
**\<sarang>** Anyway, it won't build for me, but I'll verify timings once I get it figured out
**\<rehrar> \<sarang>** Ah yes, the chain shrinks over time <-- it will give extra space to your computer when it goes negative
**\<sarang>** However, they also have ideas for non-power-of-2 stuff, which was on the back burner for me
**\<sarang>** if it proves useful for them in a way that translates to us, great
**\<suraeNoether>** nioc i believe we already have enough funding availalbe to put a deposit down on a location, and I would like to do that before the end of 2018. email invitations to speakers will be start being setn out this week
**\<sarang>** nice
**\<sarang>** Also our other conference FFS (Stanford) was funded recently, so many thanks on that front
**\<suraeNoether>** in general: thank you to all contributors who make Monero Research Lab a funded thing
**\<sarang>** suraeNoether and I will learn next month if either of us will be speaking there
**\<sarang>** anyway, other questions for us?
**\<rehrar>** ne
**\<sarang>** In the absence of further questions, we can talk recent research
**\<sarang>** This past week, I did two events in Chicago
**\<sarang>** one was a hands-on Monero development workshop
**\<sarang>** the other was a more general talk on privacy tech
**\<sarang>** both videos are on YouTube, linked from the Monero Moon posting
**\<sarang>** thanks to the Chicago Bitcoin and Open Blockchains group for hosting me
**\<suraeNoether>** Did you have a good time? think you'll do something like that again?
**\<sarang>** Yeah, I think it was very valuable
**\<sarang>** They had good turnout and excellent questions
**\<sarang>** I really like the workshop idea especially
**\<sarang>** Aside from that work, I did a good amount of lit review to support suraeNoether's work (discussed shortly) on graph matchings, which was an extension of some earlier analysis we did on spent output analysis
**\<suraeNoether>** what was the demographic of the crowd like?
**\<sarang>** The workshop was smaller (due to scheduling shenanigans for some participants) but had folks interested in math/CS/development
**\<sarang>** The talk had a good mix of technical folks and well-wishers
**\<sarang>** It'd be cool to find a way to host an interactive online workshop
**\<OpenSorceress>** what would that entail?
**\<sarang>** Well, one set of tasks I had them do was use a simple Python ed25519 library to build some constructions
**\<sarang>** like Pedersen commitments and Schnorr sigs
**\<rehrar>** lol, love the name OpenSorceress. That's funny.
**\<sarang>** So being able to do video w/ slides for introductory work would be good
**\<sarang>** as well as interactive stuff to help the participants write code
**\<sarang>** Then we did some basic RPC stuff
**\<OpenSorceress>** like remote pairing?
**\<sarang>** OpenSorceress: some situation where the workshoppers could do in-browser code, perhaps, and then let me assist interactively if needed
**\<sarang>** I don't know if there is such a thing already
**\<sarang>** just spitballing here
**\<suraeNoether>** that is pretty awesome, sarang! i'm glad it's online.
**\<OpenSorceress>** there is
**\<sarang>** orly
**\<OpenSorceress>** yeppers
**\<OpenSorceress>** -> floobits pops to mind
**\<sarang>** Cool, let's discuss after meeting
**\<OpenSorceress>** :) ok
**\<sarang>** I've also been working to integrate stealth addresses into the RTRSRingStringRuffCT optimizations
**\<sarang>** and other minor tasks, etc
**\<suraeNoether>** allrighty
**\<sarang>** How about you suraeNoether? The graph matching, perhaps
**\<suraeNoether>** well, i've been doing the churn and graph theoretic stuff
**\<suraeNoether>** as I mentioned earlier, sarang and I have stumbled upon a class of anonymity metrics for graphs such as ours, and this will give us a quantitative basis for maintaining at least our current levels of anonymity as the blockchain gets larger
**\<sarang>** It's worth noting that this isn't even new analysis
**\<sarang>** But a really clever interpretation of older stuff that suraeNoether came up with
**\<sarang>** which is always great in math
**\<suraeNoether>** correct, in fact several of these were proposed right around the time Bitcoin was proposed, which amuses me
**\<suraeNoether>** 2007, 2008, 2009
**\<rehrar>** so are you saying that as the blockchain gets larger, anonymity decreases?
**\<suraeNoether>** well, consider the following situation
**\<suraeNoether>** let's say something ridiculous like "tomororw Monero goes back to ring size 1"
**\<sarang>** It's important to note that "anonymity" here means "anonymity according to a very specific metric formulation that may or may not correspond to a particular threat model"
**\<suraeNoether>** what happens? a bunch of blocks are added to the monero blockchain, all of which are totally linkable
**\<suraeNoether>** this is an edge case of the following idea:
**\<notmike>** Even I could link them!
**\<suraeNoether>** heh
**\<suraeNoether>** if we take our present system and add a bunch of non-anonymous stuff, we aren't improving our anonymity
**\<suraeNoether>** in fact, we are decreasing our anonymity, by essentially diluting our nice big fat blockchain filled with fat ring sigs with non-anonymous data
**\<sarang>** At their heart, these metrics use numbers of matchings to relate to some idea of anonymity
**\<sarang>** a graph matching is a possible global spend history, of which there will be many
**\<sarang>** Think of it as being a guess about true spends that's at least \_consistent\_, but of course not provable
**\<sarang>** My current view of this type of analysis is that, being only a heuristic that could be combined with things like output age, it provides the same types of plausible deniability that ring sigs have always offered
**\<sarang>** however
**\<sarang>** what suraeNoether was saying about it being useful to examine proposed changes is a good idea
**\<sarang>** So you can say "if we increase ring size to X given usage patterns Y, this metric implies that anonymity gets better"
**\<sarang>** it's not possible to say things like "anonymity gets Z% better" though
**\<suraeNoether>** so, to answer your question rehrar: the Edman anonymity level is \*negatively\* related to overall graph size and \*positively\* related to ring size. so we can say "okay, if our blockchain was \*this\* big, how big of a ring size would we need to have similar EAL to today?"
**\<suraeNoether>** the fact of the matter is, though, it very slowly changes with respect to graph size at these levels
**\<rehrar>** got it
**\<suraeNoether>** to maintain an EAL similar ot what we have today, the blockchain could be 10x larger
**\<suraeNoether>** and we might need a ring size of like 15 at that point, or something like that, to make it equal exactly
**\<sarang>** I have the same types of broad, non-mathematical questions about global anonymity that I do about rings in general
**\<sarang>** If there are 2^64 possible spend histories, is that good enough for our threat models? What if there were only 2^4? I don't know
**\<suraeNoether>** sarang actually we can sort of answer that question quantitatively
**\<sarang>** Well, for some threat models, "good enough" means "enough reasonable doubt to avoid someone getting in trouble for a spend history they weren't actually involved in"
**\<sarang>** and that depends on how your legal system works
**\<sarang>** What types were you considering?
**\<suraeNoether>** the question an attacker needs to answer is "out of all possible spend histories with a likelihood greater than some C of being the true spend history, what % of these is a specific edge traced?" for example, if in 95% of all plausible and likely histories, edge e sending monero from address X to address Y is included in the matching, we conclude that edge e is the true spender.
**\<suraeNoether>** we may be able to quantify our security on an individual level that way, and see how it is sensitive to game parameters
**\<suraeNoether>** anyway, 100% of my MRL attention is on this paper right now
**\<sarang>** A lot of this (not just graph metrics) seems to be chasing after specific heuristics (some unknown) without a real fundamental idea of what guarantees we want to be able to offer
**\<sarang>** Subtly moving from "not provable spending" to "not heuristically-guessable spending" seems like a generally good idea, but it's like swiss cheese
**\<suraeNoether>** all of my work so far is highlighting, essentially, the urgency with which we need to replace ring signatures
**\<sarang>** true
**\<suraeNoether>** and the fundamental problem with using KYC exchanges
**\<sarang>** Well, those aren't going anywhere
**\<sarang>** and if anything, more people will move to them
**\<hyc>** as opposed to DEXs?
**\<sarang>** Do you know of any usable ones?
**\<hyc>** I assume Bisq works
**\<gingeropolous>** bisq .. ?
**\<hyc>** haven't used it
**\<rehrar>** question on replacing ring signatures...is there any sort of tech (eevn un battle tested) that exists at the moment?
**\<sarang>** nor have I
**\<sarang>** rehrar: no
**\<suraeNoether>** i hear bisq is good, but i haven't used it yet
**\<suraeNoether>** rehrar: yes and no
**\<sarang>** not without sacrificing trust
**\<suraeNoether>** or speed/efficiency
**\<sarang>** correct
**\<suraeNoether>** there are some trustless set-ups that are unreasonably slow
**\<hyc>** if we could do cross-chain atomic swaps with BTC that would eliminate a huge chunk of exchange usecases
**\<suraeNoether>** or big
**\<sarang>** IMO the goal of the graph matching analysis should be to at least get an order-of-magnitude estimate on Monero global spend histories
**\<suraeNoether>** hyc that is 100% correct, and we have all the theoretical framework for that except SPV at this point, but the recent nipopow paper and another recent paper may fix that too
**\<sarang>** I'm not convinced this provides an adversary with remarkably more actionable data than existing heuristics
**\<OpenSorceress>** how would you go about sussing that out?
**\<sarang>** And while it should push us toward better non-ring-sig solutions, I also don't want to FUD our users in the same way that all the other Monero tracking papers have
**\<suraeNoether>** it should provide literally the same amount of data, just one is a global approach and one is a txn-by-txn approach
**\<sarang>** OpenSorceress: run the analysis on at least a portion of the chain
**\<sarang>** suraeNoether: implementing nipopow is a huge undertaking
**\<suraeNoether>** yes
**\<sarang>** suraeNoether: what do you see as the goal of the analysis?
**\<suraeNoether>** provide actionable advice for the monero community on how to mitigate the worst known traceability chainalsysis attack. ultimately
**\<sarang>** in terms of ring size specifically?
**\<sarang>** given that the EAL is sensitive to it?
**\<suraeNoether>** not necessarily, although that is presently a facet of the analysis, yeah.
**\<suraeNoether>** i mean, at this point, I think that further increases in ring size without order-of-magnitude increases... i'm not convinced of their efficacy, but i can't say either way at this point
**\<sarang>** What's the takeaway from all of this, for the folks in this meeting?
**\<suraeNoether>** research is ongoing into the matter
**\<suraeNoether>** progress is being made in terms of making actionable recommendations to the community
**\<suraeNoether>** but we aren't announcing them yet, until after more consideration
**\<suraeNoether>** i'm not sure what you mean
**\<rehrar>** good enough for me
**\<sarang>** Do you view this a fundamentally new form of analysis that provides adversaries with a lot of new damaging information?
**\<sarang>** (as opposed to, for example, the closed-set attack, which really gave marginal information)
**\<suraeNoether>** there is no practical way i can answer that question, sarang
**\<sarang>** ok
**\<suraeNoether>** i'm telling you it's the worst-known traceability attack
**\<suraeNoether>** i'm estimating how bad it is
**\<suraeNoether>** that's my job right now
**\<sarang>** ok
**\<sarang>** Anything else of note to share from your side regarding recent stuff?
**\<suraeNoether>** not with respeect to MRL, no
**\<sarang>** kk
**\<suraeNoether>** and i have an appointment i need to get to you guys, so.. peach out
**\<suraeNoether>** imagine whirled peas
**\<suraeNoether>** etc
**\<sarang>** np
**\<suraeNoether>** love you guys \*smooches\*
**\<sarang>** Anyone else wish to bring up something they've been working on?
**\<sarang>** crickets!
**\<hyc>** if you're bothered by blockchain sync speed, get your hands on Optane SSDs
**\<sarang>** yeah?
**\<OpenSorceress>** Optane SSDs?
**\<endogenic>** SSDs?
**\<sarang>** Ds?
**\<endogenic>** ??
**\<OpenSorceress>**
**\<sarang>** I store the chain in RAM
**\<hyc>** yeah http://www.lmdb.tech/bench/optanessd
**\<endogenic>** LOL
**\<sarang>** I build a new ASIC for each block that gets added
**\<hyc>** Real Men store the blockchain in RAM :P
**\<sarang>** Well, I'll officially adjourn today's meeting; thanks to all for attending
**\<sarang>** Next week, same bat-time, same bat-channel
**\<hyc>** ttyl
**\<rehrar>** bai

212
_posts/2018-11-19-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-11-19.md Normal file
View file

@ -0,0 +1,212 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-11-19
summary: Surae work, Sarang work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<sarang>** heyo
**\<sgp\_>** hello
**\<serhack>** Hi surae!
**\<suraeNoether>** good timing :D
**\<vtnerd>** hi
**\<suraeNoether>** i decided to not look at screens this weekend, because i got like 5 migraines last week, and i made it from the hours of 8am saturday to 1pm saturday
**\<suraeNoether>** but i still felt like a totally new person :D
**\<suraeNoether>** anyone have any questions before we begin?
**\<sarang>** Welcome suraeNewther
**\<suraeNoether>** nice
**\<suraeNoether>** \\nick suraEyeOfNewt
**\<suraeNoether>** damn
**\<sarang>** s/\\\\/\\//
**\<sarang>** Shall we begin?
**\<suraeNoether>** omg that should be on a t-shirt with MRL's logo
**\<suraeNoether>** yes
**\<gingeropolous>** how many rings can a ring signature ring if a ring signature can ring rings?
**\<suraeNoether>** let's begin
**\<suraeNoether>** that's actually the subtitle of nick van saberhagen's autobiography
**\<sarang>** Who shall start with updates?
**\<suraeNoether>** Allright, we've gotten greetings out of the way. Sarang: how is that timing code going? still on iteration 18?
**\<sarang>** Nope, 19
**\<suraeNoether>** Sarang is currently running some timing experiments for me on matching bipartite graphs
**\<suraeNoether>** okay, for it to complete 20, i estimate it will be done in mid december, so i say we don't fall prey to the sunk cost fallacy
**\<suraeNoether>** i'm going to re-rig the code and run it over a smaller sample of the parameter space and get some results
**\<sarang>** Want to give your update suraeNoether first?
**\<sarang>** cool
**\<sarang>** Getting some hard numbers with scaling information will be useful
**\<suraeNoether>** Sure: Right now my time is being spent describing this bipartite matching graph problem that traceability problems in monero boil down to
**\<sarang>** very useful
**\<sarang>** having a complete description in terms of graph theory is marvelous to have
**\<suraeNoether>** the idea is simple. if someone were to try to trace the monero blockchain, they would at least have to perform the following matching task. that sort of idea
**\<suraeNoether>** and we have known bounds on the complexity for that matching task
**\<sarang>** Exactly, and now some code to get an idea of scaling
**\<sarang>** at least order of magnitude
**\<suraeNoether>** this is all in the pursuit of a formal model of de-anonymizing a "mixing with an anonymity set" style anonymity system like that of Monero.
**\<suraeNoether>** i've begun writing how we can use this approach + zcash turnstile to place bounds on the difficulty of de-anonymizing zcash as well
**\<suraeNoether>** i should have a draft of the monero portion of this paper done by the end of November
**\<sarang>** sexxy
**\<suraeNoether>** sarang has already seen it and (if i do say so myself) it's a pretty fun paper actually
**\<sarang>** Very much so
**\<suraeNoether>** if it wasn't for the fact that's \*criticizing\* monero just like MRL-0001, i'd be very excited about writing it
**\<sarang>** Have you informed Zcash of the possible applicability to their project, so they can draft a blog post about it? =p
**\<suraeNoether>** i'm confident that this will make monero better, however, by formalizing some of our concerns that were previously only qualitative
**\<suraeNoether>** sarang not formally, i may have brought it up with zooko in person before
**\<sgp\_>** any way I can get a draft copy?
**\<sarang>** We should be good neighbors and let them know
**\<sarang>** sgp\_: it's all super early
**\<suraeNoether>** sgp\_: yes, i actually want your thoughts becauset his is relevant to pools and mining and i want your recommendations, too, sgp
**\<sgp\_>** cool
**\<suraeNoether>** so, that's my MRL update. Sarang, what have you been up to?
**\<sarang>** A few things
**\<sarang>** First, housekeeping for monero-site updates to migrate our papers over, and add the new ones
**\<sarang>** Second, more lit review on graph theory approaches to anonymity
**\<sarang>** Third, reviewing some other papers relating to ring sigs and zk proving
**\<sarang>** Fourth, fixing and writing up a cross-curve discrete log equality proving system
**\<sarang>** there's also working toy code for that, using ed25519 and ed448
**\<sarang>** This allows you to use "discrete log preimages" across curves or groups arbitrarily
**\<sarang>** provided the spaces are big enough (they are)
**\<sarang>** Here's the writeup, for those curious: https://v2.overleaf.com/read/jcyscybzhzmy
**\<sarang>** Note that I did not invent this, but this is the first correct writeup I've seen and I wanted one for completeness
**\<sarang>** That's about it for me
**\<suraeNoether>** sarang has been on fire btw
**\<sarang>** As in, running around with my hair on fire, sure!
**\<suraeNoether>** if you guys haven't noticed, he's implemented several toy implementations of various crypto schemes in the past two months alone
**\<suraeNoether>** you have hair?
**\<sarang>** Not anymore, it burned off
**\<suraeNoether>** nice
**\<sarang>** So going forward, this paper (and others) will be on getmonero.org
**\<sarang>** A few newer papers are in the PR pipeline
**\<sarang>** Questions on any of my stuff?
**\<suraeNoether>** the only other topics on my mind are only half research-related: 1) research: the post-thanksgiving Monero face-to-face being hosted by Tari bringing sarang and endogenic and i together in Nashville again... I heard a rumor someone else important was coming :D 2) not really research: the coin center privacy workshop in December I'm considering attending, 3) research: the Monero Konferenco, and...
**\<suraeNoether>** well, the last bit is related to my nonprofit whihc is a selfish thing to bring up so I'll leave that alone
**\<endogenic>** too l8
**\<endogenic>** bring it up anyway
**\<suraeNoether>** heh
**\<suraeNoether>** okay
**\<suraeNoether>** so, for 1) as folks may know, Tari has paid the expenses required to get sarang, endogenic, and i face to face for a meeting before... and they are doing it again, and it is looking like it may become a quarterly thing
**\<sarang>** I suspect funding may be stalled a bit while belts tighten :/
**\<endogenic>** oh btw i drive in
**\<suraeNoether>** this is largely a research powwow over a few days, at the last meeting this whole bipartite matching thing was initially estimated and it kicked off my current research paper
**\<suraeNoether>** and i should say: it's not just Tari, it's also MyMonero
**\<endogenic>** one of these next ones i'm going to try to get surae to stay at my house ^\_^
**\<suraeNoether>** We aren't burdening the community financially with these meetings, but we also want the community to learn of our financials in this way, to prevent accusations of opacity
**\<suraeNoether>** For 2) I really want to go to this thing on some levels, but i am concerned coin center is going to look to me as a voice of the Monero community. I'm not sure if they want me to come if I'm coming as a private individual not as an individual representing Monero
**\<suraeNoether>** Isthmus was already nice enough to offer a place to stay for me in SFO so the only financial cost would be a plane ticket
**\<suraeNoether>** it seemed to me like folks were lukewarm on the idea of me attending last time I brought it up
**\<suraeNoether>** trying to sense the temperature now that folks have had a week or two to sit on the idea
**\<sarang>** In terms of funding, it seems to have more value for the space as a whole, rather than just for the Monero community
**\<sarang>** I suspect you're right about the "voice of Monero" thing, but I don't know how bad of a thing that is
**\<suraeNoether>** yeah, and I would go on my own dime
**\<sarang>** I remain disappointed that this is a "be in person or don't have a say" thing
**\<sarang>** but that's neither here nor there
**\<suraeNoether>** for 3), the Monero Konferenco: we are sitting almost at 20% funded. https://forum.getmonero.org/8/funding-required/90909/surae-noether-first-denver-monero-konferenco-spring-2019
**\<sarang>** that's impressive
**\<suraeNoether>** i know, right?
**\<suraeNoether>** that'll be enough to put a deposit down on a location
**\<sarang>** I assume you'll wait until funding is closer to guaranteed before deposits?
**\<sarang>** to the extent possible, that is
**\<suraeNoether>** i'm concerned about waiting until it's totally funded for stuff like that, and I can't think of an easy quick solution. maybe rehrar has some thoughts
**\<nioc>** suraeNoether: I see that there are no milestones in the FFS for payout
**\<suraeNoether>** nioc yeah, we should consider how to structure that asap
**\<suraeNoether>** because a milestone like putting a deposit down on a location requires the money before the milestone occurs
**\<sarang>** I think nioc's point is good particularly because of the natural payouts that are needed for this
**\<sarang>** yeah
**\<suraeNoether>** so perhaps we invert the milestones
**\<sarang>** suraeNoether: what's the downside to waiting, besides the risk of losing venue?
**\<suraeNoether>** i could make a milestone post to request funding to complete a milestone
**\<sarang>** I think that's fine
**\<suraeNoether>** sarang: volatility in price over the long term makes the actual funding receive much more variable
**\<sarang>** There's no independent way for donors to verify the milestones happened anyway
**\<sarang>** unless you posted receipts and such
**\<suraeNoether>** we'll be posting contracts signed with venues and receipts, etc, all of which are very easily faked, unfortunately
**\<sarang>** Yeah, that's unavoidable
**\<sarang>** I think people understand this
**\<suraeNoether>** curious parties could always call the literal venues themselves and check, I suppose
**\<sarang>** Goal should be to maximize transparency and accountability within the limits of the unique circumstances
**\<suraeNoether>** so, how shall we go about doing this? Should I edit the funding request post to include all this information? I feel like that's changing the terms of the request after we received donations already, which isn't necessarily fair to the previous donors
**\<sarang>** As long as you're doing the same things with the money, updating for more clear scheduling seems entirely reasonable
**\<nioc>** sarang: I believe it's up to core not the community to verify receipts
**\<nioc>** since they release the funds
**\<sarang>** nioc: I only mean this in the sense that most funding requests have a tangible, publicly-verifiable work output
**\<suraeNoether>** maybe fluffypony luigi1111 binaryFate or ArticMine could weigh in on this.
**\<sarang>** Whereas this is a bit different
**\<nioc>** not that you couldn't make it public
**\<suraeNoether>** thanks for that observation, sarang
**\<suraeNoether>** okay, i'm going to edit the current funding request post to include a handful of milestones and a description of how we are going to invert the milestone process for this event
**\<sarang>** I think a payout with a clear understanding of what happens with it (e.g. venue deposit) and some kind of immediate transparency for a modicum of verification (e.g. invoices and core team verifies somehow) makes sense
**\<sarang>** Donors likely already implicitly assumed something along these lines
**\<sarang>** The "work output" is a conference next year :)
**\<luigi1111>** I would look for community agreement if there seemed to be anything "shady"
**\<sarang>** Plus suraeNoether already has to have evidence of this for corporate tax purposes anyway
**\<sarang>** cool cool
**\<suraeNoether>** one milestone can be a deposit on a venue, AV stuff, caterer and (if appropriate) a deal at a hotel so attendees can get a discount. another milestone can be purchase of flights and hotels for speakers. a final milestone can be for the remainder of the cost of the event to pay for things like media, publicity, printing pamphlets and posters, assembling shwag bags, etc
**\<suraeNoether>** thanks for the input luigi1111 i believe you are 100% correct
**\<parasew[m]>** we will be testing a few things at the 35C3 (Monero at the Chaos Communication Congress 27.-30.dec) which could be valuable for the conferenco: submission management, streaming, etc. will let everyone know when there is something to see!
**\<suraeNoether>** we mentioned having defcon-style badges from the hardware team, but i think we are going to hold off on those until the second year. this will keep our costs down and allow the HW team to focus on the wallet, etc
**\<sarang>** ^ good idea, on both counts
**\<suraeNoether>** parasew[m]: regarding the 35c3 conference, if sarang sgp and myself all want to come (I do!) we need to make our post for travel funds this afternoon
**\<suraeNoether>** i'm holding off on renewing my passport until after it so i don't have to worry about not getting my passport back in time
**\<suraeNoether>** rehrar sarang and sgp\_ are you guys still interested in going to 35c3
**\<suraeNoether>** ?
**\<parasew[m]>** suraeNoether: sure! yes! (my planning got heavily delayed but the stage and everything got confirmed yesterday)
**\<sarang>** I was just checking my schedule yesterday, and it simply will not work for me due to family commitments
**\<sarang>** (the timing of the event is awful)
**\<parasew[m]>** timing indeed is a problem
**\<suraeNoether>** it really is. flights are super expensive on the 26th and 25th in general
**\<sarang>** I had hoped that I could work around the family stuff, but it's not possible
**\<sarang>** Plus my brother, sarangbro, is expecting a kiddo during that week
**\<sarang>** very exciting
**\<luigi1111>** nice name
**\<sarang>** ikr
**\<luigi1111>** we welcome sarangbrokid
**\<sarang>** in olden tymes, they'd have invented a new last name, like sarangson
**\<parasew[m]>** best wishes to sarangbro+sarangbro\_junior! :)
**\<suraeNoether>** yes :D
**\<sarang>** BTW, IACR has been chock full of interesting relevant papers lately
**\<suraeNoether>** yes. yes it ihas.
**\<sarang>** I have a long list for this week
**\<sarang>** I try to hit up lit review weekly but some weeks it gets just bonkers there
**\<suraeNoether>** btw
**\<suraeNoether>** everyone, i really think sarang needs a vacation
**\<suraeNoether>** like five days of no computer screens and some sun or something, and he barely takes weekends off
**\<suraeNoether>** sarang is a very driven person
**\<sarang>** psh, do any of us?
**\<suraeNoether>** ikr
**\<sarang>** It's like Newman, who once opined that the mail never stops
**\<suraeNoether>** thing is, you see Ethereum people on twitter bragging about working 18 hours a day and you know they are producing some straight up crap in those conditions.
**\<sarang>** I suspect many of us will be effectively taking time off around Christmahannukwanzaka
**\<sarang>** for one reason or another
**\<suraeNoether>** OH there is one FFS i would like to direct everyone's attention to
**\<sarang>** ?
**\<suraeNoether>** TheCharlatan is proposing development of reproducible builds here: https://forum.getmonero.org/6/ideas/91098/funding-for-development-of-reproducible-builds
**\<sarang>** outreach?
**\<suraeNoether>** I strongly support this FFS project, and I think it would be a nice security gain for Monero
**\<sarang>** These have been desired for a while
**\<sarang>** So the whole request is for 6 XMR?
**\<suraeNoether>** yep, and i don't think it's out of line with endogenic's recent efforts to encourage reworking/refactoring Monero (i'm almost certainly mischaracterizing Endo's goals)
**\<suraeNoether>** it appears he's only asking us to pay for his VPS
**\<sarang>** I don't know the details of repro build complexity, but that seems like a great deal
**\<sarang>** unless we can get VPS support for free, as some others had indicated
**\<suraeNoether>** ^ he works at Shift, the hardware wallet developer, and he started gridcoin, and admittedly wildly insecure but super fun cryptocurrency experiment
**\<suraeNoether>** or at least, when i met him, he was doing work with Shift
**\<suraeNoether>** anyway
**\<suraeNoether>** I have no further information to report
**\<suraeNoether>** although I'm always interested in getting community feedback in general
**\<sarang>** cool
**\<sarang>** Any other fun news to report
**\<sarang>** ?
**\<suraeNoether>** aha, so MAGIC received its first non-board member donation today, so I'm totally energized to encourage folks interested in contributing to MAGIC to check out what we are about at https://www.magicgrants.org ... we are an educational and scientific non-profit focused on scholarships and research grants in cryptocurrencies.
**\<suraeNoether>** our scholarship program will be open starting in January and we are currently fundraising for next year
**\<suraeNoether>** if we were in a bubble I'd say "hey, come reduce your tax burden possibly" but I'm fully aware of the current state of the market. :P
**\<sarang>** lol
**\<parasew[m]>** this is amazing, congrats for magic!
**\<sarang>** I must take off shortly to meet up with someone
**\<suraeNoether>** thank you! hopefully we can reduce the financial burden of studying cryptocurrencies for students while also incentivizing universities to make cryptocurrency curricula
**\<suraeNoether>** and eventually? build primary schools, libraries, and computer labs in the developing world
**\<suraeNoether>** can't have a crypto infrastructure without comptuers (technically a false statement, but theory and practice disagree here :P)
**\<suraeNoether>** but since that's not research related and is a coin-agnostic project, it may be one of the last times I bring it up during an MRL research meeting
**\<suraeNoether>** okay
**\<suraeNoether>** i believe we are good to go on today's meeting
**\<suraeNoether>** EVERYONE. you must know this: i love you

404
_posts/2018-11-26-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-11-26.md Normal file
View file

@ -0,0 +1,404 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-11-26
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<sarang>** It's just about time to begin our meeting
**\<rehrar>** hope you're having all of the fun
**\<sarang>** all ofit
**\<suraeNoether>** allllright everyone, let's begin
**\<suraeNoether>** Greetings from MRL.
**\<sarang>** heyo
**\<suraeNoether>** before we really get rolling, does anyone have any questions to open the meeting wiht?
**\<IRS>** o/
**\<sarang>** I assume this meeting will be reasonably short, given U.S. Thanksgiving was last week and some of our folks are from U.S.
**\<suraeNoether>** fire away
**\<suraeNoether>** okay
**\<endogenic>** the IRS will never call or IRC you
**\<suraeNoether>** assuming no questions, let's get going I guess. sarang, want to share what you worked on for the past week or so?
**\<sarang>** Sure
**\<sarang>** I have a few things
**\<sarang>** First, there was interest expressed in possibly getting another researcher on board
**\<sarang>** It would get funded, but we'd need someone qualified and available
**\<sarang>** So this is more of a "if you know people, send them our way"
**\<sarang>** The second thing is that I'm working with those outside researchers from Australia on their spent-output stuff
**\<sarang>** Turns out they didn't invent the ideas on their papers :/ but it's good formalization
**\<suraeNoether>** (to be clear, sarang means an outside group has approached us offering to fund a new researcher)
**\<gingeropolous>** ^ wow
**\<Inge->** sweet
**\<sarang>** Third, still working more on cross-curve discrete log stuff
**\<rehrar>** what level of researcher are you looking for? full time?
**\<sarang>** We could easily fund full time, but part time is better than no time
**\<spaced0ut>** an academic group?
**\<sarang>** No, it's a foundation
**\<sarang>** Anyway, just throwing a line out there
**\<suraeNoether>** rehrar: take what we can get? we have a huge list of todos and all of us have full plates.
**\<rehrar>** well that's awesome
**\<suraeNoether>** I kind of feel like research does the following
**\<suraeNoether>** if human knowledge is a circle (think venn diagram), then the circumference is the interface with the unknown, and adding to the circle of knowledge just makes the circumference bigger
**\<suraeNoether>** so the problem is that if we add additional people without a firmly defined scope, I fear we will have a mission creep sort of thing happening
**\<suraeNoether>** i'm eager to have more hands and eyes on our project, for sure
**\<sarang>** Sure, but that doesn't mean we can't set a reasonable number of desired peeps
**\<suraeNoether>** ^ yep
**\<sarang>** For the limited current scope we have, I think at least one more person would be very useful
**\<sarang>** But again, cart before the horse
**\<suraeNoether>** I just think we should kick some ideas around on coming up with a more concrete scope
**\<suraeNoether>** so let's chat about that later, maybe? we have time to chat about it, for sure
**\<sarang>** First, does evenlessmoney (stick with a handle, dude!) want to talk about bloat?
**\<evenlessmoney>** yes, let me repost my message
**\<sarang>** ty
**\<suraeNoether>** so we can move on for now, but this has come up in several research meetings before, the prospect of adding to the MRL crew... so we should formalize our ideas about it this week
**\<sarang>** ArticMine chimed in earlier about it, FWW
**\<sarang>** FWIW
**\<evenlessmoney>** The block size adjustment algorithm has been on my mind in recent weeks. I was asked in another chat what the biggest caveats were with the dynamic block size, and after thinking about it, I concluded that a motivated attacker could pay the extra fee to bump the block size, and then maintain a perpetual low cost flood of transactions to bloat the utxo set.
**\<evenlessmoney>** https://link.medium.com/OrG5th051R
**\<evenlessmoney>** This article underscores the need for our nodes to remain syncable to the masses, it is doubly important that Monero remains syncable on commodity hardware long run, considering the privacy implications a remote node brings.
**\<evenlessmoney>** After some deliberation, I think capping block size in the code may be necessary, and that allowing it to be dynamic with no upper bound is dangerous. I would love to hear some input from people who are more informed than me on the matter.
**\<evenlessmoney>** articmine mentioned that he doesnt think that this is an issue, but I had a second question afterwards
**\<suraeNoether>** one moment let me process this
**\<ArticMine>** Reading the article
**\<evenlessmoney>** which involved the centralization of nodes - if our block size has too quick a growth rate, nodes cant sync on commodity hardware
**\<evenlessmoney>** which is what that article points out
**\<evenlessmoney>** most of the network would be forced to use remote nodes, unless I'm misunderstanding
**\<gingeropolous>** its a long article. TL/DR is ethereum is becoming unsyncable and therefore will become centralized
**\<spaced0ut>** at first glance. if possible to make the attack more expensive is an option it might be worth looking at vs capping the block size. does anyone really want to go there right now?
**\<evenlessmoney>** its worse for Monero IMO, because we really want to stress users running their own nodes
**\<gingeropolous>** and any network that becomes unsyncable becomes centralized
**\<evenlessmoney>** for privacy's sake, not even decentralization
**\<suraeNoether>** spaced0ut: one option is to add a nonlinear term to fees. another option is to add a momentum term to block size adjustment, or a resistance term, so to speak. however...
**\<suraeNoether>** evenlessmoney: when we changed our fees, we did make such an attack much less expensive to carry out, but I don't think it's particularly an issue... if folks think it is, we can maybe consider some simulations, etc, and add a resistance term to dynamic block size. this would prevent the block size from responding extremely elastically to network demand...
**\<suraeNoether>** but we can all see how that leads to an opposite problem, right, where the block size is too rigid and can't change with demand?
**\<ArticMine>** First unlike Ethereum and Bitcoin Cash there is a cost to bloating the Monero blockchain that is comparable to a 51% attack
**\<evenlessmoney>** Not on a continuous basis
**\<evenlessmoney>** only to raise the block size
**\<evenlessmoney>** once the size is up, you can perpetually fill those blocks with bloat txes for cheap
**\<ArticMine>** You havee to get it there in the first place
**\<ArticMine>** have
**\<gingeropolous>** and any pool can mine those txs in
**\<evenlessmoney>** You can do a couple percent a block
**\<evenlessmoney>** its not very expensive when you ratchet it over a few days
**\<suraeNoether>** evenlessmoney: cheaper than before, but not free, and maintaining a long-term flood is non-trivially expensive, even for super cheap monero fees
**\<evenlessmoney>** I'm more worried about baseline activity being that high
**\<evenlessmoney>** and cheap
**\<evenlessmoney>** in this situation
**\<evenlessmoney>** if Monero becomes the de facto BTC alternative
**\<suraeNoether>** in my mind, I don't see this as a practical attack. people have to blow their Monero in order to drag monero's blockchain down... seems like an incentivization problem, not a security problem. and going the opposite direction, by making monero block size more rigid, presents other scaling problems
**\<spaced0ut>** can we calculate the cost to double the size over time periods in between hard forks? or even calculate the cost to add a terabyte to the size?
**\<ArticMine>** The cost of bloating to a given size is close to independent of the rate of bloat. One can pay all at once or over time
**\<suraeNoether>** there are a few options to address this, that don't require deep changes nor totally fixed block sizes, i'm just not convinced of the power of an attacker, and ArticMine's fact re: cost of bloating is a really important factor
**\<gingeropolous>** well one thing to point out is that the median 100 is a parameter from the original implementation
**\<suraeNoether>** one option: momentum/resistance term, so that increasing block size is harder the further it is away from some fixed "ideal", which we can always change later
**\<gingeropolous>** and those guys didn't think some things through fully, so I think its fine to question the block growth rate
**\<suraeNoether>** another option: coupling block size with past block sizes in a moving average sort of way. similar to the momentum trick
**\<suraeNoether>** gingeropolous: I agree with that statement
**\<rehrar>** evenlessmoney: if this attack does turn out to be practical though, would a solution be to have to continue to pay a fee to keep the block size above default?
**\<evenlessmoney>** its not even an 'attack' so much as popularity
**\<suraeNoether>** another option: change the timescale of blocksize adjustment so that going up in block size requires a lot of statsitical evidence and, lacking htat, we have a rapid exponential decay back to baseline, or something like that
**\<gingeropolous>** ^^
**\<suraeNoether>** rehrar: yeah, having a fee penalty proportional to the difference between the current block size and the "resting" size would do the trick
**\<rehrar>** I think the biggest issue here is that one you pay the fee to bump the blocksize, as long as the block remains full, it's free to keep it at that blocksize, correct?
**\<ArticMine>** In creasing the median to more that 100 block will make this attack way more expensive and if the new median is chosen carefully will have little impact overall
**\<evenlessmoney>** there is no additional cost that I am aware of rehrar
**\<suraeNoether>** rehrar: that summarizes the potential issue. i'm not sure if it's an issue. :P
**\<suraeNoether>** after all, there's an argument: if they are paying fees, it ain't spam
**\<rehrar>** so my suggestion of miners having to continuously pay a fee for any blocksize above default is I think beneficial from a incentivization perspective, because it makes sure that blocks absolutely need to be that large
**\<rehrar>** or they start slipping back down
**\<gingeropolous>** rehrar, but that kind of breaks the scaling
**\<spaced0ut>** does anyone have some idea how how much money we're talking to perform this attack? are we looking to be safe vs nation states?
**\<gingeropolous>** someone ran some python on this recently
**\<ArticMine>** That is actually the case now since one does not get a rebate for mining below the effective median
**\<gingeropolous>** Isthmus, where u at
**\<suraeNoether>** i would like us to stop calling this an attack. It's not like a DOS attack or something like that.
**\<spaced0ut>** well it actually could be a DOS if well funded enough and nodes can't sync right?
**\<ArticMine>** I agree.
**\<suraeNoether>** how could you distinguish it from healthy usage without a lot of real-life extra information?
**\<rehrar>** this is the big issue, and where a lot of criticism of Bitcoin comes in
**\<ArticMine>** A DDOS against node is actually a weakness of fixed blocksize coins such as Bitcoin
**\<rehrar>** if Bitcoin tx goes up, some will say it's a spam attack, and some will say it's adoption
**\<rehrar>** and we simply do not have an oracle able to differentiate
**\<suraeNoether>** okay, let's do this
**\<rehrar>** and even if there was a reliable one, it would probably not be a decentralized one
**\<ArticMine>** There were spam attacks in Bitcoin to drive up fees. This works if hte block are full since most of the spam ts are not mined
**\<ArticMine>** But they cost andwith to the nodes
**\<gingeropolous>** to me it seems there is a small list of useful information needed to address the issue: 1) cost of attack, in XMR, to get to 3 GB / block in one day per Isthmus "\<Isthmus> 00:44 By the end of the 1st day: 3 goddamn GB per block"
**\<ArticMine>** bandwith
**\<suraeNoether>** let's just do some back of the napkin calculations today and see what we see. then we can talk about it more. :P
**\<suraeNoether>** why 3 GB/block?
**\<rehrar>** yes, concrete numbers are needed
**\<ArticMine>** Compare the cost to a 51% attack
**\<gingeropolous>** 2) current node processing ability. What is the existing blocksize tipping point for processing
**\<sarang>** Yes, without numbers or simulations (e.g. the work Isthmus and others have done) in this discussion, all this is speculation without data
**\<rehrar>** we may not be "academics" like Zcash (according to Snowden)
**\<gingeropolous>** suraeNoether, 3 GB / block because thats what Isthmus ran if you do the maximum possible expansion
**\<rehrar>** but we can still pretend to math, at least
**\<suraeNoether>** gingeropolous: wait do you mean "by the end of one day, block sizes could be 3Gb?"
**\<gingeropolous>** i.e., if you max out the equation, you can get to 3 GB / block in 1 day
**\<suraeNoether>** hmm
**\<suraeNoether>** yeah, let's merely estimate how much that would literally cost someone
**\<sarang>** I'd like to see this done on testnet
**\<suraeNoether>** ooooh
**\<suraeNoether>** yeah, why simulate it if you can just simulate it? :P
**\<sarang>** we literally have a toy network available
**\<ArticMine>** Sure and pay 4x the reward. Why not just do a 51% attack?
**\<sarang>** that we can nuke
**\<gingeropolous>** im just parroting Isthmus 's work
**\<moneromooo>** Don't spam testnet.
**\<gingeropolous>** https://usercontent.irccloud-cdn.com/file/UHG4yi8G/image.png
**\<sarang>** make a new testnet, toynet
**\<gingeropolous>** axis lbels be damned apaprently
**\<endogenic>** spamnet
**\<suraeNoether>** we need a testtestnet?
**\<spaced0ut>** do it on wow
**\<endogenic>** we shall have our own testnet! with spam, and DOS attacks!
**\<rehrar>** ^
**\<evenlessmoney>** ooh, yes
**\<evenlessmoney>** wownero pls
**\<rehrar>** let's finally make them useful for something
**\<evenlessmoney>** they're good for memes..
**\<sarang>** Anyway, this discussion hasn't really produced much IMO
**\<ArticMine>** In any case the parameter I would look at if this is an issue is the median number of blocks.
**\<gingeropolous>** ^^
**\<ArticMine>** for an increase
**\<evenlessmoney>** We can look into running some simulations
**\<evenlessmoney>** anyone got a cache of testnero?
**\<evenlessmoney>** needtestnero90
**\<gingeropolous>** ugh, lets not make testnet a pain to use
**\<Isthmus>** Hey, sorry for belated response. I'm on phone, at work, can't really hang in meeting, but just saw all the pings
**\<Isthmus>** https://github.com/noncesense-research-lab/Blockchain\_big\_bang/blob/master/Isthmus\_Bx\_big\_bang\_model.ipynb
**\<Isthmus>** Updated simulations are there
**\<evenlessmoney>** I'll speak with isthmus (we can maybe get together), we can talk about simulations and stuff
**\<ArticMine>** But keep in mind if a 51% attack is cheaper then what is the point of this attack?
**\<evenlessmoney>** and report back next meeting or something
**\<suraeNoether>** ArticMine: medians require 50% violation of data before the median shifts (breakdown point... https://en.wikipedia.org/wiki/Robust\_statistics )
**\<Isthmus>** https://usercontent.irccloud-cdn.com/file/EziXrd38/image.png
**\<gingeropolous>** a 51% attack costs energy, this attack costs units of account
**\<suraeNoether>** ArticMine: i don't think it's cheaper
**\<moneromooo>** smooth had a good suggestion, to have the penalty start before the median, so you'd get penalty free till, say, 90% of the median. This would cause a natural shrinking if the txpool is full of low fee txes.
**\<evenlessmoney>** oh
**\<evenlessmoney>** thats smart too
**\<evenlessmoney>** I like that one, one of my big issues has been that its basically free (base tx cost) to keep block sizes up atm
**\<suraeNoether>** isthmus, the axes of your graph are transparent on my computer and i can't read them. :P
**\<gingeropolous>** hell, someone could find a flaw in monero, print a bajillion monero, and then bring the network to its knees for nothin
**\<Isthmus>** https://usercontent.irccloud-cdn.com/file/X1So57dJ/image.png
**\<Isthmus>** Sorry, is that legiblbe?
**\<evenlessmoney>** ginger thats a threat if they get infinite monero no matter what our algo is
**\<Isthmus>** 51% and bloat are two totally unrelated attacks that accomplish different things. It's an apples/oranges comparison
**\<suraeNoether>** is graph over a day? Isthmus
**\<suraeNoether>** yeah i can read it now
**\<Isthmus>** Or maybe that was already discussed more earlier, I'm not caught up on scrollback and need to hop back to work
**\<ArticMine>** ut unites of account translate into energy via the lock reward
**\<suraeNoether>** ArticMine: the 51% attack requires hardware/POW. this bloat issue requires only cash, like a POS attack
**\<suraeNoether>** you can attack the network without being a miner if you have the capital using this approach
**\<ArticMine>** It is not like a POS attack because in this case hte cash is burned
**\<suraeNoether>** true, but it is like a POS attack because all it requires is capital
**\<suraeNoether>** not hardware
**\<spaced0ut>** wow 200k eur for 10TB in 2 days
**\<Isthmus>** Ok, I gotta bounce back to work. All of the info & FAQ are in that notebook, although it's a very rough draft that I had written up for internal use.
**\<ArticMine>** POS can use borrowed capital
**\<Isthmus>** There are probably some small bugs, feel free to fix it. :- 0
**\<gingeropolous>** thanks Isthmus
**\<suraeNoether>** Isthmus: sorry to bother you, i just want to make sure i understand: does that mean 1 million euros can drive the monero blockchain to be more than 1 million gigs in size?
**\<suraeNoether>** within a DAY?
**\<Isthmus>** I think it might take 2 days to get to 10 TB
**\<Isthmus>** But essentially.
**\<Isthmus>** This is taking into account the exponential accumulation
**\<suraeNoether>** wow. thanks
**\<ArticMine>** You are maxing out the penalty?
**\<suraeNoether>** okay, let me think about this more, but now I've shifted my opinion
**\<Isthmus>** Yes, totally override the penalty to make block ~2\*(median of last 100) for every block. It's very petal to the metal, deliberately sized attack
**\<gingeropolous>** yes, median 10k
**\<ArticMine>** Then it is 4x the lock reward
**\<ArticMine>** block
**\<suraeNoether>** I think we should have a term in our fees that is proportional to a super-linear function of the difference between current block size and a "target" block size, say 1MB right now
**\<spaced0ut>** what about raising the cost to increase again if the block size has recently increased in X amount of blocks?
**\<spaced0ut>** drastically raising maybe
**\<ArticMine>** Fees are driven by the penalty
**\<rehrar>** spaced0ut: in the event of rapid adption (should it ever happen), this would cripple the network for quite some time
**\<ArticMine>** So one needs to look at the penalty function.
**\<ArticMine>** The simplest an lees disruptive is to increase the 100 block median
**\<ArticMine>** less
**\<spaced0ut>** well assuming this hasn't happened before we can probably get pretty good data (maybe even from btc also) on the upper bound of how rapid real adoption could be. just a thought
**\<spaced0ut>** the size shouldnt need to double 10 times in a row
**\<evenlessmoney>** we risk the BTC people moving here en masse
**\<evenlessmoney>** or the ecosystem moving in
**\<gingeropolous>** and i ultimately think increase the 100 block median won't affect UX drastically. It will actually drive a fee market. Current activity is very burst-like.
**\<gingeropolous>** so delays will eventually clear
**\<gingeropolous>** and those needing priority can get it
**\<gingeropolous>** but if the network actually demonstrates a need for larger blocks, they come into existence
**\<gingeropolous>** and we somehow work a long tail into the decay
**\<lurkinandlearnin>** surely rapid adoption shouldn't be catered to above long term survivability against this type of attack
**\<ArticMine>** The only downside to increasing the median I can see is that the network may not e able to adapt to seasonal changes such as December
**\<evenlessmoney>** its not even an attack, if we get too popular and fees are too cheap for large blocks, we risk nodes becoming unsyncable
**\<evenlessmoney>** the unbounded block size is concerning imo
**\<suraeNoether>** increasing sample size for the median over 100 blocks will make such a drift attack slower (and therefore cost a lot more, because you have to do it over more and more blocks) but linearly slower. and is a rigid sort of decision, as ArticMine mentions re: December. Adding a nonlinear term to our fees seems sensible to me.
**\<evenlessmoney>** forcing average users to sync against remote nodes due to bandwidth constraints is dangerous
**\<sarang>** Yes evenlessmoney that's the whole point of Isthmus's posting
**\<spaced0ut>** if anyone needs to be secure against nation states it's XMR
**\<gingeropolous>** im interested to see what Isthmus 's multistate memory thing is
**\<rehrar>** but...and I hate to say it like this, hasn't this already been kinda known for a while?
**\<ArticMine>** Yes ut how do you enforce non linear fees?
**\<rehrar>** Because we have a dynamic blocksize, we can scale with adoptin
**\<suraeNoether>** multi-term memory sounds like moving averages of different spans of time to me
**\<moneromooo>** "secure against nation states" is ridiculous. They could fuck with us anytime they wanted to already.
**\<ArticMine>** That is the whole point
**\<rehrar>** although taht would mean maybe going up to several GB block sizes.
**\<spaced0ut>** moneromooo, fair enough but shouldn't that be the goal?
**\<suraeNoether>** rehrar: yeah, but just like a lot of other monero problems, we are learning about the size/scale of the issue.
**\<suraeNoether>** i agree with moneromooo :P
**\<sarang>** rehrar: yes, this has been known for a while
**\<evenlessmoney>** we didnt have hard numbers from isthmus until recently either
**\<evenlessmoney>** its been a bit more nebulous
**\<ArticMine>** A fixed block size has been proven to be a disaster for Bitcoin and as recent events have demonstrated for Bitcoin cash
**\<evenlessmoney>** Time will tell whether Bitcoin's decision was a disaster. I think the jury is still out.
**\<gingeropolous>** my thinking is, there is a hard cap. Its 2X the current blocksize. I really think we need a long perspective on the median. Like 6 months. however many blocks that is
**\<spaced0ut>** +
**\<suraeNoether>** gingeropolous what if we have a dynamic soft cap that is determined by a long time-scale measurement? :P
**\<gingeropolous>** thats prolly the multistate thing :)
**\<ArticMine>** My take is that increasing the median is the way to address this concern provided it is legitimate.
**\<ArticMine>** By legitimate I mean a cost comparison with a 51% attack
**\<lurkinandlearnin>** That sounds good to me. I would rather the network slow down in the rare december-like situation that someone being able to inflate the blockchain to unusable levels for less than the "cost" (however you quantify that because they are different) of a 51% attack
**\<spaced0ut>** definitely
**\<ArticMine>** Long medians with say a 6 month time frame will not lead to Bitcoin's problems
**\<moneromooo>** A 51% attack is recoverable from. That one seems not.
**\<ArticMine>** It depends on what the 51% attack does
**\<gingeropolous>** i think the problem, like the 51%, is that the cost is dynamic and unpredictable. I.e., it cost less to 51% the monero network 3 years ago. We don't know what the hardware will be in 5 years, or the state of network. The protocol needs to be hardware agnostic as much as it can
**\<rehrar>** with the volatility of Monero, this thing is unpredictable too
**\<rehrar>** since it requiers unit of account, this "attack" can be done while Monero is dirt cheap, and the effects stick around
**\<rehrar>** even if Monero goes way up and this isn't feasible anymore
**\<ArticMine>** ^^ es it has to be hardware agnostic
**\<ArticMine>** Yes
**\<suraeNoether>** i'm in agreement with articmine for now. both: 1) we need to estimate costs for 51% vs. bloat and 2) a long-time-scale soft cap seems super smart, especially considering how bursty the network is in general
**\<lurkinandlearnin>** Also because this resembles a PoS attack, you have to remember that it could be done for "free" if people/whales/exchanges are stolen/compromised
**\<sarang>** Sounds like a long-scale median increase is an adjustment that, while probably suboptimal, is better understood
**\<suraeNoether>** we can make it even softer by using that long-time-scale soft cap as the anchor point for a nonlinear penalty term
**\<gingeropolous>** so we gonna use a magic number or see if we can get an emergent one
**\<rehrar>** and even softer if we wrap the solution in fur
**\<ArticMine>** There is a lot of room between 3.4 hours and 6 months to tune the median
**\<ArticMine>** and make it optimmal
**\<suraeNoether>** ArticMine: given the 50% breakdwon point of medians...
**\<suraeNoether>** if we did 6 months, that implies that at least 3 months of \*all monero transactions\* would have to be bloat transactions
**\<suraeNoether>** for someone to raise the soft cap over time
**\<sarang>** Isthmus: would be nice to see the effects of a long-term median in your sims
**\<sarang>** IMO that's the best approach to this analysis right now
**\<suraeNoether>** moreover, if we don't actually cap anything but add a nonlinear penalty to block reward for block sizes above the "soft cap" chosen by a long-time-scale-median, temporary fluctuations in economic activity would be handled relatively easily
**\<suraeNoether>** we'll seek out more information
**\<suraeNoether>** and try to come up with a write-up
**\<suraeNoether>** after isthmus and noncesense have had their way with some analyses
**\<rehrar>** that's smart suraeNoether
**\<lurkinandlearnin>** Maybe finding medians/"target values" and softcaps might be an actual legitimate application of some TA haha
**\<suraeNoether>** lurkinandlearnin: other way around :D
**\<suraeNoether>** there are no legitimate applications of TA, but there are legitimate applications of statistics \*for use in\* TA :P hehe
**\<ArticMine>** A hybrid approach could be used to deal with seasonal issue. Essentially a stiff penalty over the long term median
**\<suraeNoether>** shit, we can easily do a seasonal model, too
**\<suraeNoether>** https://machinelearningmastery.com/sarima-for-time-series-forecasting-in-python/
**\<suraeNoether>** we wouldn't be using this for forecasting
**\<endogenic>** sarima noether
**\<ArticMine>** That implies baking in an eternal event
**\<lurkinandlearnin>** Yes that's what I mean. The whole point of the TA bullshit is to find patterns which would "look" reasonable given past results (and to claim this somehow predicts them). Whereas we want to put limits on what "looks reasonable" to apply incentives. Right?
**\<gingeropolous>** ima throw it out there... i think we should target this for protocol change spring 2019 fork
**\<gingeropolous>** if we have something fancy, great. If not, we just pick a larger median.
**\<suraeNoether>** gingeropolous: i'm fine with that. i think the large sample size median is going ot have some rigidity problems with the network, i'll work with isthmus to write something up maybe
**\<sarang>** Cool, I think that sums things up nicely for now, until we have data on this
**\<gingeropolous>** a rigid network is more useful than a broken one :)
**\<sarang>** In the interest of time, any other topics to discuss with the whole group?
**\<suraeNoether>** gingeropolous: sure :D
**\<suraeNoether>** okay, other than that
**\<suraeNoether>** over thanksgiving: i read papers on accumulators and learned some more about STARKs
**\<suraeNoether>** and sarang is still running some matching code for timing purposes
**\<suraeNoether>** my matching paper is coming along :D
**\<suraeNoether>** aaaand I don't have anythign else to talk about
**\<suraeNoether>** sarang? anything else? does anyone else have interesting projects they want to chat about? even if its not formally for MRL or kovri or monero specifically
**\<sarang>** Perhaps to sum up our meeting, does anyone have goals for the next network upgrade? This ties in with our earlier discussion
**\<suraeNoether>** ^ good question!
**\<endogenic>** ring size increase?
**\<suraeNoether>** hold on that until i have more information from matching. :P
**\<sarang>** Seems like a change to handle bloat would be good, PoW tweak...
**\<hyc>** everyone here following tevador's RandomX ?
**\<sarang>** and any recommendations from the matching that are urgent
**\<lurkinandlearnin>** IMO goals should be getting rid of the payment ID/integrated address/subaddress confusion and what was discussed today
**\<sarang>** Nuking payment IDs is a longer-term issue IMO
**\<sarang>** Setting a timeline is more reasonable
**\<gingeropolous>** its just standing up to exchanges
**\<sarang>** RIght
**\<endogenic>** we should deprecate and kill long pids for sure
**\<gingeropolous>** i think a timeline was proposed but never agreed on
**\<lurkinandlearnin>** exchanges laziness shouldn't slow down the improvement of the network
**\<gingeropolous>** ^^
**\<sarang>** But if we don't set a timeline, we become Zcash with their "deprecate transparent addresses SOMEDAY"
**\<moneromooo>** Whether or not to add IPv6 connectivity might be relevant. IPv4 scarcity is said to be a barrier to Sybils. How much though, I don't know.
**\<lurkinandlearnin>** is it reasonable to have a goal of having only subaddresses by the next September upgrade?
**\<hyc>** as an enforced consensus rule?
**\<sarang>** I don't have enough knowledge of exchange timelines to say
**\<sarang>** hyc: yes
**\<gingeropolous>** imo, deprecating pids isn;t an MRL thing
**\<sarang>** We've already said "please don't use them"
**\<pigeons>** the client could just make choices about how to diversify its connections if IPv6 is used
**\<sarang>** gingeropolous: yeah, only bringing it up because I asked about upgrade goals :D
**\<moneromooo>** Only works for outgoing connections.
**\<suraeNoether>** i feel like you are correct gingeropolous but I want to shy away from the "not my problem" effect
**\<hyc>** doesn't adopting i2p expose us to the same Sybil possibilities?
**\<moneromooo>** I don't know enough to say.
**\<suraeNoether>** okay, so it seems like we have hit all our major points
**\<hyc>** very long addresses, and you have no way to know where they originate from
**\<hyc>** worse than IPv6 in that regard
**\<suraeNoether>** and we can continue chatting about ipv4 and ipv6 and medians for the rest of the day
**\<suraeNoether>** but i think that's sufficient for our meeting today :D
**\<sarang>** Great, so action items are to get Isthmus and friends to examine median changes, and be thinking about upgrade
**\<moneromooo>** Oh. One other thing that's related:
**\<sarang>** sure
**\<moneromooo>** If the blockchain is split in N stripes, such that every peer selects a random stripe (that is, 4096 blocks every N\*4096). What is the optimal value of N (too small means you save less storage, too large means it gets harder to find the data you need to sync).
**\<evenlessmoney>** Do we use Bitcoin's default peer limit of 8?
**\<evenlessmoney>** If so, that should be factored in to n
**\<moneromooo>** 8 outgoing peers, unlimited incoming IIRC.
**\<sarang>** The optimal value depends on our metric, I suppose
**\<moneromooo>** OK. That was a bad question. A better question was "what is the best metric".
**\<suraeNoether>** hmm
**\<hyc>** I think it's just a question of, how much space do you need to save
**\<suraeNoether>** moneromooo: i feel like N < 3 risks byzantine consensus problems
**\<gingeropolous>** well, the goal is to save space, but the problem is that is a dynamic question for each user
**\<sarang>** If we assume good connectivity and number of peers, the number could be decently high
**\<hyc>** yes, and dynamic for the overall chain too since it continues to grow
**\<gingeropolous>** someone thats not gonna run software that takes up 80 gigs probably still won't run it if it takes up 40
**\<moneromooo>** suraeNoether: I do not understand.
**\<hyc>** In my blocktree ramblings I was envisioning 256-way branching
**\<suraeNoether>** moneromooo: i'm imagining each miner as being a member of one of N coalitions of possibly dishonest participants
**\<moneromooo>** Ah, one thing I neglected to mention: the pruned data is just range proofs and smaller bits. Not the whole chain.
**\<suraeNoether>** if everyone in control of one strip is totally dishonest, that information is no longer really accessible
**\<suraeNoether>** hmm
**\<suraeNoether>** this is a nontrivial problem
**\<sarang>** Yeah moneromooo brings up the question of "is old enough prunable data \_safe\_ to remove"
**\<sarang>** which is related
**\<suraeNoether>** moneromooo: I don't think we can pick a number without some knowledge of the underlying network topology
**\<gingeropolous>** this type of thing is ... unprecedented, right? Therefore, it might be the kind of thing that requires measurement. Once implemented, will nodes advertise which portions of the chain they keep?
**\<gingeropolous>** and therefore, the network could be crawled to obtain a census of adoption of this approach?
**\<moneromooo>** Yes, nodes adertise. And don't have to stripe if they want to keep all.
**\<gingeropolous>** right.
**\<hyc>** ... I would deterministically automate it. e.g., MAC address of first network interface & MASK = stripe #
**\<gingeropolous>** so, the thing we may want to measure is how many nodes join the network with N.
**\<hyc>** or some other already-visible node ID.
**\<gingeropolous>** so, say we start with N of 8, we could measure the increase nodecount that are using 8. Or maybe start with 4.
**\<gingeropolous>** because thats the goal, right? increase number of nodes?
**\<hyc>** back to moneromoo's clarification - this isn't striping the entire blockchain. just the prunable stuff, range proofs.
**\<hyc>** so aside from someone bootstrapping a new node, this has no real impact on data availability
**\<hyc>** wallets talking to nodes that they trust won't see any change at all
**\<suraeNoether>** i have a question for moneromooo : if we pick N = 8 and six months later want to change it to N = 11 or something weird, how much of a PITA is that? it means that miners need to pull a different stripe, that means a lot of data can be deleted and some new data needs to be downloaded...
**\<suraeNoether>** i guess my question is: what's the cost of picking a \*bad\* N for implementation?
**\<hyc>** there are consistent hashing algorithms to minimize that problem
**\<moneromooo>** It'd be kinda of a pita. Changing to 16 would be less so, as it's kinda made to allow this (would need some extra code though).
**\<hyc>** minimize the amount of reshuffling needed when N changes
**\<suraeNoether>** moneromooo: that's why i picked 11 :P coprime. heh
**\<moneromooo>** Also, picking 11 means divisions all the time.
**\<suraeNoether>** let's tell wownero to pick 24, and we pick 6, and we figure out the difference :P
**\<hyc>** stick to powers of 2
**\<suraeNoether>** (bad approach)
**\<suraeNoether>** hyc: or at least prime powers of some sort. makes changing it easier
**\<moneromooo>** BTW, if anyone wants to try a sync from scratch using the crash branch (which simulates this) is welcome ^\_^
**\<suraeNoether>** carbon crab incoming. :P
**\<suraeNoether>** cesium crab
**\<suraeNoether>** anyway
**\<sarang>** OK, I think we can officially call the meeting

181
_posts/2018-12-03-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-12-03.md Normal file
View file

@ -0,0 +1,181 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-12-03
summary: Surae work, Sarang work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / sarang
---
# Logs
**\<sarang>** OK, it's time to begin our meeting
**\<sarang>** ping suraeNoether and others (mass ping sucks)
**\<endogenic>** i am self-pinging
**\<serhack>** ping serhack
**\<serhack>** Hey!
**\<suraeNoether>** howdy everyone
**\<sarang>** If everyone pings three others, eventually the whole world is pinged
**\<sarang>** pinged? pung?
**\<suraeNoether>** multi-level pinging schemes
**\<suraeNoether>** consider myself punged
**\<sarang>** definitely pung
**\<suraeNoether>** it's like the purge, but pingier
**\<endogenic>** pang\*
**\<sarang>** I have several items on my provisional agenda today, as well as a round-the-horn to see what folks wish to share
**\<sarang>** First, the Lab landing page https://getmonero.org/resources/research-lab/ has been updated to add new papers
**\<endogenic>** very nice!
**\<sarang>** translations are welcome, now that we support them
**\<sarang>** I only added English abstracts
**\<sarang>** Second, suraeNoether and I will be posting new FFS requests for Q1 2019 shortly
**\<sarang>** We've been discussing, as we often to, the correct way to assess the amount
**\<sarang>** This ties in with discussions elsewhere about how best to approach multi-month funding on FFS
**\<serhack>** Whoa, translating abstracts to Italian? it would a pleasure for me
**\<sarang>** serhack: yass
**\<suraeNoether>** Given the 50% contraction each of the past two quarters, we are trying to decide the best way to price our next quarters. whether we should switch to monthly funding, etc.
**\<sarang>** The current FFS system doesn't allow for non-escrow payments, so we're stuck with whatever the market does
**\<sarang>** I've been traditionally using a 14-day EMA or 30-day EMA
**\<suraeNoether>** Last time, I tried to take trendline into account and I received some pushback, which is very understandable. so we wanted to open up the discussion to get some ideas.
**\<sarang>** Yeah, what are the group's thoughts on this?
**\<sarang>** (We'd be requesting through Mar 2019)
**\<endogenic>** could you make the question a little more concrete?
**\<endogenic>** for clarity
**\<sarang>** We could do shorter periods, like monthly, but that opens to donor fatigue
**\<sarang>** endogenic: what's the fairest exchange rate computation?
**\<suraeNoether>** i'm generally opposed to using moving averages: in an uptrend, the community ends up paying more and we receive disproportionately more than \*that\* by the time our paychecks come around... so we are arguably unfairly overcompensated... and in the downtrend, the opposite occurs, where donor cash doesn't go as far, and we still receive disproportionately less than \*that\* by the time our paychecks come around
**\<endogenic>** imo ideally you all shouldnt have to worry about that as you really want to have your compensation targeted for the currency you have to pay rent, taxes, etc in
**\<endogenic>** so it's whatever allows you not to have to worry about it
**\<endogenic>** i think it's a real issue though as a source of stress
**\<sarang>** Well, discussions of how to structure FFS in the future are good ones, but right now it is what it is
**\<suraeNoether>** endogenic: what if we list our desired salaries in USD and donating to pay our salaries could be a rolling thing; at the end of each month, we take a 48-hour average or something based on Kraken or whatever, and we dip into that fund according to that instantaneous exchange rate? it seems more fair to both donors and us to use a method like that
**\<endogenic>** that's interesting
**\<sarang>** It might encourage donors to delay donations
**\<sarang>** until they know the actual value being dispersed
**\<suraeNoether>** that may actually work out to everyone's benefit
**\<suraeNoether>** people see their XMR hit our account at much closer to their desired exchange rate
**\<suraeNoether>** or rather, we gain control over it at a more reasonable rate
**\<sarang>** Any big opposition to investigating this further? We'd need a decision very quickly
**\<suraeNoether>** so people's money isn't wasted on volatility and we get what we need to pay rent, etc
**\<suraeNoether>** fluffypony luigi1111w any thoughts?
**\<sarang>** ping binaryFate or luigi1111 or fluffypony
**\<suraeNoether>** ArticMine and binaryFate too
**\<sarang>** jinx
**\<endogenic>** when atomic pings
**\<suraeNoether>** cross-client atomic pings via SMS relayed by telegram (the literal wire, not the app)
**\<suraeNoether>** (not wire the app either)
**\<endogenic>** make it so
**\<suraeNoether>** anyway, let's put that on the back burner until we get feedback, hopefully in the next day or so
**\<sarang>** Anyway, until Core Team arrive, let's move on
**\<suraeNoether>** yep
**\<endogenic>** wow are you guys twins or something
**\<sarang>** suraeNoether: want to give your updates?
**\<cjd>** https://github.com/cjdelisle/RandomHash
**\<sarang>** hello
**\<cjd>** howdy
**\<cjd>** experimentation on randomized hash function
**\<suraeNoether>** well, recently I've been working on three things
**\<suraeNoether>** cjd thanks for the contribution
**\<suraeNoether>** first thing i've been working on is the matching paper, which i've handed off to sarang
**\<suraeNoether>** i had some ideas over the weekend on how to quantify some churn length methodology
**\<suraeNoether>** which is a step in the right direction
**\<suraeNoether>** the second thing i've been working on is reading more about accumulators and zero knowledge proofs of membership and nonmembership
**\<suraeNoether>** this is surae. this is surae catching up on large-anon-set-authentication-without-trusted-setups-to-replace-ring signatures. see surae cry.
**\<binaryFate>** Rolling fund sounds good
**\<suraeNoether>** binaryFate +1 thanks for the feedback :D
**\<suraeNoether>** the third thing I've been working on is mapping certain discrete-log-based crypto schemes over into a module-theoretic setting and constructing examples. this is a fun hobby for me that is brand new and sarang and i are going to write a paper on it
**\<suraeNoether>** i've also been working on non-research stuff related to the monero konferenco, and we just got back from our monero workshop in nashville, where we met up to do some research and brainstorming face to face
**\<suraeNoether>** oh, and i've been making some final edits to the thring sig paper before submitting for peer review
**\<suraeNoether>** and that's it
**\<suraeNoether>** oh, i started reading silur's verifiable shuffle
**\<sarang>** Any specific questions on suraeNoether's recent work?
**\<sarang>** going once, twice
**\<sarang>** OK, I'll make my update
**\<sarang>** suraeNoether has passed on the current draft of the graph matching paper to me for additional work; this is some really cool shit that will be worth everyone's time
**\<sarang>** I'm finalizing a tech note on discrete logs, reviewing several other papers by other researchers, and also finishing up some re-review of a ring representation paper from Matt Green's team from a while back
**\<sarang>** My goal is get the tech note, graph matching paper, etc. out the door as efficiently as possible
**\<sarang>** I want next quarter to focus more heavily on ringct replacements, as does suraeNoether
**\<sarang>** Any specific questions for me or for suraeNoether on these fast updates?
**\<sarang>** chirp chirp
**\<sarang>** Isthmus was unavailable but wanted me to share the following update (one sec):
**\<sarang>** https://www.irccloud.com/pastebin/UGzuSz5P/
**\<sarang>** sgp\_ was looking at pool output data to give more information that could lead to changes in how we handle pool and coinbase outputs
**\<endogenic>** very cool sgp\_
**\<sarang>** The upcoming Stanford Blockchain Conference has its free registration open now: https://cyber.stanford.edu/sbc19
**\<sarang>** Both suraeNoether and I applied to speak, but I have not heard back on this
**\<sarang>** An FFS to fund our presence was successful, but the market has been... unkind in the meantime
**\<endogenic>** as it is
**\<sarang>** Hopefully at least one of us is accepted, to offset those costs. It's an exceptionally worthwhile event
**\<sarang>** Does anyone else have work of interest to share with the group?
**\<suraeNoether>** sarang thanks for the link to SBC, i just registered :P
**\<h4sh3d>** I have worked on an atomic swap BTC/XMR https://github.com/GuggerJoel/XMR-BTC-atomic
**\<endogenic>** h4sh3d: did you see the feedback you got to that?
**\<moneromooo>** Worthy goal.
**\<h4sh3d>** endogenic: I didn't see feedback on IRC
**\<sarang>** Doesn't that scheme require knowledge of the same scalar across groups?
**\<endogenic>** h4sh3d: "vtnerd> h4sh3d the paper still has a magic zkp step. How are these values zkp'ed ?"
**\<sarang>** correct me if wrong
**\<sarang>** if so, that's a subtle step that is nontrivial
**\<h4sh3d>** Knowledge of a scalar on ed25519 (i.e. mod l) only
**\<h4sh3d>** and the SHA256 of the scalar
**\<sarang>** a proof of that equality in zero knowledge?
**\<h4sh3d>** that's the magic zkp needed, but with Bulletproofs it is possible to prove these constraints
**\<sarang>** Yeah, other proposals have had the same issue
**\<h4sh3d>** > a proof of that equality in zero knowledge?
**\<h4sh3d>** yes
**\<suraeNoether>** hey guys i have to go a bit early
**\<sarang>** np
**\<suraeNoether>** i'll be on for most of the day
**\<endogenic>** see you
**\<h4sh3d>** I started to write a proposal to work on that scheme, what do you think?
**\<sarang>** h4sh3d: I need to re-read your paper to remind myself of a few details, but does the sender on one chain guarantee return of funds if the protocol fails?
**\<h4sh3d>** sarang: yes if it fails Alice (XMR) get her XMR back and Bob (BTC) get his BTC baCK
**\<h4sh3d>** If Bob disappears Alice gains the BTC
**\<sarang>** High level: why does Alice get her XMR back?
**\<sarang>** Delayed signing and posting by Bob?
**\<h4sh3d>** Ok, what do you mean by "fail"? The zkp or after the firsts transactions on-chain?
**\<sarang>** why not either
**\<sarang>** Under whatever circumstances Alice is not guaranteed the BTC
**\<h4sh3d>** If after locking the BTC/XMR on-chain Bob does not follow the protocol anymore
**\<h4sh3d>** can be because Bob disappear or act malicious
**\<sarang>** So what transaction is posted to the XMR chain, and why can Alice get her funds back if it's posted and Bob disappears or pulls other shenanigans?
**\<sarang>** Proposals around refund transactions can take advantage of that new construction, but not with this proposal
**\<h4sh3d>** In this scheme the first XMR transaction move funds into the address controlled w/ (a,x) private key, where x is half controlled by Alice and half by Bob
**\<sarang>** OK, if Bob disappears, Alice can recover the key?
**\<h4sh3d>** no, but she can get the BTC
**\<sarang>** Does she wait until Bob has posted the BTC transaction before posting the XMR transaction?
**\<h4sh3d>** so if Bob disappears, Bob loose
**\<sarang>** (I'm being purposefully socratic to help me understand better)
**\<h4sh3d>** np
**\<h4sh3d>** https://github.com/GuggerJoel/XMR-BTC-atomic/blob/master/whitepaper/xmr-btc.pdf
**\<h4sh3d>** page 4
**\<sarang>** Yep, I read that. I want to ensure I understand the nature of protocol failure by asking you that question
**\<h4sh3d>** Yes, Alice waits enough conf before sending XMR tx
**\<sarang>** OK, and Bob takes advantage of BTC timelock in case of Alice's disappearance
**\<h4sh3d>** In fact we can say that Alice or Bob will "sell" half of the key in the Bitcoin tx
**\<h4sh3d>** Yes, exactly
**\<sarang>** My spidey sense tells me that someone else had a similar idea at some point, but I don't recall specifically
**\<sarang>** Even so, at face value a neat idea
**\<sarang>** made possible by bulletproofs (tm)
**\<sarang>** To what extent is knowledge of the ed25519 scalar as a hash preimage on the BTC chain group-specific?
**\<h4sh3d>** I've not finished my journey into Bulletproof, but I'm pretty sure that it's feasible with zkp tech today
**\<sarang>** h4sh3d: yes
**\<sarang>** bulletproofs can support this
**\<sarang>** verification isn't trivial and the circuit is ugly
**\<sarang>** But yeah, any time you're using values across groups, you have to account for how they are used
**\<h4sh3d>** Not sure that I understand the question about preimage on the BTC chain group-specific
**\<sarang>** ed25519 != secp256k1
**\<moneromooo>** None o that goes onto the chain though, right ?
**\<moneromooo>** (except the tx)
**\<sarang>** That's my question
**\<h4sh3d>** Yea I know but the x is not used with secp256k1
**\<sarang>** I obviously need to do deeper diving onto the guts of hash timelocks
**\<h4sh3d>** x\_0 or x\_1 is reveal into the unlock script in bitcoin
**\<rehrar>** sometimes I think you guys just make up words and terms to sound smart
**\<sarang>** What groups are those scalars in?
**\<sarang>** Is there any algebraic requirement beyond "throw it into a hash function as a byte string"?
**\<endogenic>** rehrar: you're not wrong
**\<h4sh3d>** I dont think so
**\<sarang>** h4sh3d: if there are no algebraic assumptions on the scalars and it's purely a matter of byte representation, that's one thing
**\<sarang>** otherwise you'd have to be very careful about crossing groups (we dealt with this recently do a discrete log equality proof across curves)
**\<sarang>** Anyway, we should continue to discuss this... but does anyone else have a short item to bring up, before we hit the end of our meeting time?
**\<sarang>** If not, we can adjourn and continue existing discussions
**\<sarang>** OK, officially adjourned

202
_posts/2018-12-10-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-12-10.md Normal file
View file

@ -0,0 +1,202 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-12-10
summary: Sarang work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / sarang
---
# Logs
**\<sarang>** OK, it's about time to begin our meeting
**\<sarang>** Greetings to everyone; who's here?
**\<sgp\_>** hello
**\<engelmensch\_>** hi
**\<sarang>** ping binaryFate endogenic gingeropolous hyc Isthmus moneromooo nioc parasew[m] rehrar smooth stoffu etc
**\<endogenic>** hello
**\<sarang>** suraeNoether will be away today
**\<sarang>** First off, updates on recent work
**\<sarang>** another tech note (MRL-0010) is merged to -site along with several others that now appear
**\<sarang>** https://getmonero.org/resources/research-lab/
**\<sarang>** soon lab.getmonero.org will direct there as well
**\<sarang>** MRL-0011 deals with graph matching and is being finalized
**\<sarang>** Along those lines, some interesting lit review
**\<sarang>** An older paper on quantum-resistant accumulators: https://eprint.iacr.org/2017/1154
**\<sarang>** One on highly expressive accumulator proofs: http://legacydirs.umiacs.umd.edu/~zhangyp/papers/accum.pdf
**\<sarang>** Publication of a paper we saw as a talk in London, about using nested merkle trees to avoid evil remote nodes: http://legacydirs.umiacs.umd.edu/~zhangyp/papers/accum.pdf
**\<sarang>** whoops, wrong paste: https://ieeexplore.ieee.org/abstract/document/8406557/
**\<sarang>** And the paper discussed this morning about cross-chain stats: https://arxiv.org/abs/1812.02808
**\<hyc>** cool stuff
**\<sarang>** Besides those, I'm reviewing additional non-published stuff, one of which is an alternate proposal for return addresses
**\<sarang>** sgp\_ suggested doing a youtube series called Breaking Monero
**\<sarang>** each short episode would talk about a common method of monero analysis
**\<engelmensch\_>** to help the DHS ;) ?
**\<sarang>** heh
**\<sgp\_>** want me to paste the initial description ideas?
**\<sarang>** please do sgp\_
**\<sgp\_>** I didn't update yet with your feedback
**\<sarang>** that's fine
**\<sgp\_>** https://www.irccloud.com/pastebin/XI0H2aU9/Breaking%20Monero%20Ideas
**\<sarang>** I think doing this will speak well to our transparency and get ahead of low-quality research
**\<sgp\_>** I also think it will help Monero research be more approachable to those who do not idle here all day
**\<sarang>** Any thoughts after reading this? (Or on my previous statements about lit review and MRL papers?)
**\<sarang>** ^^
**\<engelmensch\_>** is there a plan to add paper references to the episodes=
**\<engelmensch\_>** ?
**\<sarang>** We could
**\<sgp\_>** engelmensch\_: good idea. would take preparation, but would be worth it
**\<sarang>** Eh, or just short episode notes on a corresponding reddit post
**\<sarang>** Episode 0: A Preprint is Not Peer Review
**\<sarang>** The thought was to start the series next week
**\<sarang>** 15 minute-ish episodes, perhaps
**\<sarang>** informal
**\<sgp\_>** exactly. keep it pretty short to keep user attention
**\<sarang>** Anyway, be thinking about ideas and presentation. Consider them a shorter series similar to the Bulletproofs fireside chat that sgp\_ and I did a while back
**\<sgp\_>** initial timeline is announce next week, create most content in early Jan
**\<sarang>** ah ok, nvm then
**\<engelmensch\_>** any plans for video visualisations? that might help a lot to grasp the problem. or else a whiteboard
**\<sarang>** I misunderstood
**\<sgp\_>** first intro episode next week
**\<sgp\_>** yes, will include visualizations
**\<sarang>** the finest stick figures that paint can offer!
**\<engelmensch\_>** ;)
**\<sgp\_>** pretty much
**\<sarang>** But IMO that's fine
**\<sarang>** Too much flash and people will accuse you of being up to something
**\<hyc>** that's quite a list of episodes. looks good
**\<sarang>** "Here you go, now shut up about chain analysis"
**\<engelmensch\_>** not flash, but having too many references in you brain might break stuff, so a diagram is quite useful
**\<sarang>** agreed
**\<sarang>** On a funding note, FFS for suraeNoether and me have been posted for Q1 2019
**\<sarang>** and related to this, a rep from the Loki Foundation contacted me and said their group is interested in funding a researcher in fiat
**\<sarang>** they've offered 15000 USD for this
**\<sarang>** the escrow system is not set up for this, so any researcher who took them up on this would do so separately from FFS
**\<sarang>** I'd be interested to know people's thoughts on the idea of having a researcher partly paid by FFS and partly in fiat by this organization
**\<sgp\_>** up to the individual I suppose
**\<sarang>** Their original hope was to help out someone new, which would be great if we could find such a person
**\<sarang>** but they said that given the market and current FFS needs, they'd be open to doing this for me and/or surae
**\<notmike>** If only such a person existed!
**\<sarang>** The latter would obviously be a big change
**\<sarang>** I'm personally open to the idea, provided the community can be assured that there are no extra strings attached to the fiat
**\<sarang>** and that research directions aren't being influenced
**\<sarang>** Anyway, those are my updates. Does anyone else have work of interest to share?
**\<engelmensch\_>** in my opinion it looks the same as other funded researchers contributing to the comunity
**\<sarang>** Agreed, but community funding carries a certain onus
**\<notmike>** Any updates on konferenco?
**\<engelmensch\_>** I try to write up a simulation based security proof for the ringct
**\<sarang>** suraeNoether has been planning, but I do not know of updates (and he is away for the morning)
**\<sarang>** engelmensch\_: in what way?
**\<notmike>** What happened to the coral reef project?
**\<engelmensch\_>** in a semi-honest model and then hope to GMW compile it to the malicious model
**\<sarang>** What aspect of ringct?
**\<endogenic>** notmike how is that remotely appropriate for this channel? does anyone else find notmike disruptive?
**\<endogenic>** trying to have a meeting here
**\<engelmensch\_>** I want to show that the commitment do not leak any more information, as an attacker would find out anyway
**\<notmike>** excuse me endogenic can you take a step back and try to calm down, please
**\<endogenic>** no
**\<notmike>** I'm just curious as are many others about where the monero from the FFS is goin
**\<notmike>** If you haven't noticed this is something many are asking.
**\<sarang>** we can discuss that shortly if you don't mind
**\<endogenic>** go ask on reddit then. this is not your personal attention seeking venue
**\<sarang>** engelmensch\_: the amount commitments?
**\<notmike>** Nor have I tried to make it that guy. You should really try to calm yourself. :/
**\<engelmensch\_>** yes the amount commitments and the intermeidate stuff in the single, in my setting also the color commitments
**\<sarang>** well the commitment itself is a pedersen commitment, not much info gained there
**\<sarang>** is it something particular to the signature definition you're looking at?
**\<engelmensch\_>** not sure if I can only reduce the security of my contruction to the current monero
**\<engelmensch\_>** I use the MLSAG as a blackbox
**\<sarang>** Interesting
**\<sarang>** We'll be glad to help as needed
**\<engelmensch\_>** but for my paper I'd like a formal proof that it's sound and secure. And the best way to do this was via a simulation based proof
**\<sarang>** notmike: non-research FFS requests are outside of MRL's scope
**\<engelmensch\_>** at least, that was what a prof told me who is into it
**\<sarang>** OK
**\<sarang>** The existing analysis was essentially a 2-D version of the Liu proofs
**\<engelmensch\_>** yes, I saw this for the MLSAG and just reference it
**\<notmike>** sarang: well, consider the Loki Foundation's offer. There should be a serious effort to draw in other researchers before any consideration is made of paying present researchers with that cash.
**\<sarang>** We don't want to spread community donations too thin
**\<sgp\_>** at the moment even moneromooo's FFS has been open for a few days
**\<sarang>** If current researchers get fully funded, it makes more sense to investigate someone else
**\<notmike>** Its not clear that this would happen from bringing in other researchers, or that fully funding present researchers is the best use of the funds.
**\<sarang>** It's up to donors to decide what to do with their money
**\<endogenic>** notmike: i am calm. nice try though
**\<engelmensch\_>** is there a preprint/draft of MRL-0011?
**\<sarang>** engelmensch\_: privately, yes, but it's not in a state for public release yet
**\<engelmensch\_>** ok
**\<sarang>** it needs only a few more days
**\<sarang>** then will be posted to github and -site
**\<sarang>** One issue with bringing in other researchers is that most folks with training in this field are employed already, or are grad students
**\<engelmensch\_>** because we're writing a grant proposal to investigate cross-layer effects of privacy preserving p2p entworks and privacy preserving applications ontop of them
**\<sarang>** engelmensch\_: this work is purely about graph analysis
**\<sarang>** I'll be interested to see your simulation work on this engelmensch\_
**\<sarang>** Any other news or work of interest to share?
**\<engelmensch\_>** it might be related, as we did some work with DC nets on the p2p layer which also create some sort of anonymity set as the ringsig
**\<sarang>** hmm ok, let's talk after meeting about details
**\<engelmensch\_>** sorry if I'm too verbose
**\<sarang>** no prob
**\<sarang>** Hmm well it seems the well of information has run dry a bit early today
**\<sarang>** I suppose we could discuss more about engelmensch\_'s work given the timing
**\<sarang>** How do you see our analysis complementing the grant proposal?
**\<engelmensch\_>** by graph analysis I suppose it's tx graph analysis?
**\<sarang>** Our work is an examination of formalizing ring sigs as graph structures, and examining the computational complexity of proposing spend histories
**\<sarang>** it also can tie into other heuristics, like the guess-newest output heuristic
**\<engelmensch\_>** ok, and how does this hold, if you get auxiliary information from the p2p layer?
**\<sarang>** You can use heuristic information, like output age or presumably probabilities from p2p layer, to optimize your history selection
**\<sarang>** and for identified outputs, you can simply remove them from the graph altogether as you might expect
**\<sarang>** none of it is provable, of course, and the complexity is huge
**\<engelmensch\_>** jup. my effort on provable stuff was only considering 1 tx
**\<sarang>** Ah ok, this is a more global analysis
**\<sarang>** but it could be examined for smaller sets
**\<engelmensch\_>** the idea behind simulation based based sec proofs is that you create an ideal world, where there is e.g. a trusted third party and then you compare the views of different parties to the real ones. And if there is an algorithm which can create the view of an actor without access to it's secrets, it is considered secure
**\<engelmensch\_>** I'm in the process of understanding how these proofs actually work from: https://eprint.iacr.org/2016/046.pdf
**\<engelmensch\_>** maybe written down it makes more sense. I'm happy to have a working implementation of it in the meantime from postponing the theory work
**\<sarang>** Awesome
**\<sarang>** Well, looks like good work in progress on that analysis
**\<sarang>** We should have the first graph paper finished in a few days for review
**\<sarang>** There's definitely room to expand it to a second one as well
**\<engelmensch\_>** I'm happy to review it
**\<sarang>** That'd be excellent
**\<sarang>** I'll post it here when it's a good state
**\<sarang>** Original plan was to include a broader scope, but we dialed it back a bit and are removing some stuff
**\<sarang>** surae also has some code relating to it
**\<engelmensch\_>** cool
**\<sgp\_>** Side note: I made this post yesterday regarding attackers collecting IP broadcast data by running nodes: https://medium.com/@JEhrenhofer/attacker-collection-of-ip-metadata-27032e736371
**\<sgp\_>** m2049r got back to me with an estimate gingeropolous: 3183 Monero nodes, 64 of them with port 18089 open, 56 of those on the proper block height
**\<sarang>** Conclusions?
**\<sgp\_>** Attackers can run x many nodes to connect to y clients directly, therefore learning more about the transaction broadcast process
**\<sgp\_>** s/y clients/y other nodes
**\<engelmensch\_>** yes. there are some modified clients which connect to all possible nodes and do not relay any pending TX to figure out the timings when they receive the tx
**\<engelmensch\_>** this can be used to deduce the topology
**\<engelmensch\_>** we plan on running such a node
**\<engelmensch\_>** it is also useful to get metrics for 0-confirmation clients
**\<sarang>** sgp\_ had some estimates posted to reddit/twitter based on this
**\<engelmensch\_>** how long is a good time to wait before you can be sure that a TX will most likely be included in a block
**\<m2049r>** since each node reports who its connected to, the topology is clear. or what do you mean engelmensch\_ ?
**\<engelmensch\_>** no. when you collect the timings of when you get a tx from a node, you can infer the latency between nodes. If you do this with planetlab and have low latency to most peers and GPS timestamping, this gives you pretty good latency estimates
**\<sarang>** the IP information is a good indicator for the importance of i2p/tor routing
**\<sgp\_>** Yes. For my research, the next step is estimating the impact that server providers can have
**\<sgp\_>** m2049r is there a way to do an org lookup on these IPs?
**\<engelmensch\_>** you can use the location ISP database
**\<engelmensch\_>** that gives you decent results
**\<engelmensch\_>** http://lite.ip2location.com/
**\<sgp\_>** Cool, didn't know about this specific service
**\<engelmensch\_>** I played with it, when I was using zmap to scan 0.0.0.0/0 and knocked on some ports
**\<engelmensch\_>** it's a nice way to visualise, but should also serve well to track clients
**\<sarang>** So engelmensch\_ you are more interested in latency-based topology, as opposed to sgp\_'s interest in ip data from nodes?
**\<sarang>** if I'm understanding the difference properly
**\<sgp\_>** At the moment I've done no research with latency
**\<sarang>** right
**\<engelmensch\_>** we are 2 PhD students, I'm more on the blockchain layer and my colleague is more network oriented, so he leads this direction
**\<engelmensch\_>** but atm he wants to have a latency graph
**\<sarang>** engelmensch\_: is your interest more about adversarial data, or about propagation statistics?
**\<engelmensch\_>** when you have the propagation statistics, you can motivate a lot of research why latency is important. e.g. if you use a DS network to disseminate pending TX (to hide your position) it has to reach all nodes in an appropriate amout of time
**\<engelmensch\_>** so there are a lot of really good privacy preserving networks, but they normally have n² messages and therefore are unusable
**\<sgp\_>** fwiw I have a connection here at Minnesota to Professor Hopper, who does Tor latency and bandwidth research iirc. Could be a useful person to talk to
**\<sgp\_>** https://www-users.cs.umn.edu/~hoppernj/
**\<engelmensch\_>** I saw a lot of analysis from the guys in sardinia: http://blockchain.unica.it/
**\<engelmensch\_>** It's getting late in Europe ;) I'll read up later
**\<sarang>** Thanks for joining engelmensch\_
**\<engelmensch\_>** thanks for all the input and discussion
**\<m2049r>** http://lite.ip2location.com/ looks pretty good - is there a catch?
**\<sarang>** I guess we never formally adjourned, but thanks to everyone for joining
**\<sarang>** Seems the order of the day is network analysis

298
_posts/2018-12-17-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-12-17.md Normal file
View file

@ -0,0 +1,298 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-12-17
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<suraeNoether>** howdy everyone
**\<sarang>** heyo
**\<suraeNoether>** i've been sick all weekend
**\<suraeNoether>** I'M BACK THO
**\<suraeNoether>** not really
**\<suraeNoether>** still exhausted but INCREMENTALLY GETTING BETTER
**\<sarang>** just like monero
**\<suraeNoether>** heh
**\<suraeNoether>** allrighty everyone: as usual, we'll open with questions, then discuss the work we've done the past weeks since our last update
**\<suraeNoether>** does anyone have any questions before we open up?
**\<suraeNoether>** okay. cool :) we'll ask for questions as we go
**\<suraeNoether>** since last we met I received and started reviewing sarang's version of the matching paper, and I attended the coincenter workshop in san fransisco, and I met isthmus in person
**\<suraeNoether>** i paid for that trip out of pocket to not burden the community, fwiw
**\<sarang>** Anything more about the coincenter workshop? You had mentioned it a bit before
**\<suraeNoether>** so, to refresh the audience, coincenter writes policy reports to help inform lawmakers and regulators about cryptocurrency technologies, their true capabilities, and to advocate on behalf of financial privacy, to try to persuade lawmakers to not make stupid decisions
**\<suraeNoether>** if anyone saw the CFTC commissioner's speech in october: there was a small freakout that the CFTC may be prosecuting developers of smart contracts eventually: these are the sorts of things that coincenter is trying to advocate \*against\*
**\<suraeNoether>** the reports are extremely well written and contain some of the best arguments, in my mind, that financial privacy is necessary for an open society and that large-scale surveillance of financial transactions is basically antithetical to a free and open society
**\<sarang>** What did you bring to the table from your perspective?
**\<suraeNoether>** i brought a few arguments favoring privacy that i like a lot, tbh
**\<suraeNoether>** for example
**\<kayront>** clearly preserving financial privacy is a step in the right direction, but how to reconciliate regulator acceptance of something like monero, in a world of guilty by default, aml/kyc, FATCA and CRS? if you were to transpose the banking rules as they stand today to the crypto space, then it seems evident (unfortunately) that the general population having access to the famous swiss bank account in their pocket would go against the
**\<kayront>** direction of the last decade or two, which is granting government the ability to track anything and everything digital (specifically in regards to money flows in this discussion)
**\<suraeNoether>** i love it when fluffypony talks about how monero can be used to buy banned books in totalitarian regimes like north korea, for example, because it illustrates that \*using a technology that is morally neutral, and can be used for good or for evil\* is not inherently wrong or criminal, and can be used to do ostensibly "good" things for society
**\<suraeNoether>** kayront: actually
**\<suraeNoether>** not to hashtag-actually yoiu
**\<suraeNoether>** the thing is that the banking rules as they stand today give exhcanges like coinbase plenty of power and ability to comply
**\<sarang>** Exchanges are waiting for super-conservative Coinbase
**\<sarang>** I'm not convinced that accepting Zcash was a step in the right direction or not
**\<suraeNoether>** every single cryptocurrency, zcash and monero included, if you are using KYC/AML exchanges, can totally de-anonymize you. so you may ask a better question which is: "why are law enforcement asking for MORE power and control over this new technology?"
**\<sarang>** lol because they can
**\<suraeNoether>** for example kayront
**\<suraeNoether>** sarang: yeah the answer is obvious
**\<suraeNoether>** hence the political pushback and advocacy
**\<suraeNoether>** so, for example kayront, a bank today only needs to file a suspicious activity report about information that's happening inside their own bank
**\<kayront>** suraeNoether: "totally"? sure, they'll be able to track when you get in and out of monero, but after that, the ship has sailed
**\<suraeNoether>** the guys at Chase arent' responsible for filing an SAR about stuff that happened on Wells Fargo accounts, and vice versa
**\<kayront>** transfer to your own wallet, churn as you please for increased peace of mind, do whatever you want
**\<sarang>** I think he's saying that you give them your name and address and bank info, so of course the exchange knows who you are
**\<kayront>** i think this sort of thing scares the regulator
**\<sarang>** Sure it does
**\<suraeNoether>** so the recent trend where pols and law enforcement officials are asking for additional view key access is in contradiction with their current ability to comply
**\<suraeNoether>** with classic/traditional assets
**\<suraeNoether>** if Chase doesn't need to report anything beyond one hop outside their bank, why should Monero give outgoing view key access, for example? stuff like that
**\<sarang>** We need to convince exchanges that they can already comply
**\<suraeNoether>** so the coincenter workshop was a day of very smart and stimulating people from various coin projects and various non-profits around the world discussing how to convince lawmakers of stuff like this
**\<sarang>** but regulators are being super cagey about specifics
**\<kayront>** i find the whole argument very fallible, so don't misunderstand, of course I don't stand for that .. i don't quite understand how sending money to anyone you want to without asking for permission isn't basically the same as chatting up anyone online as you please without permission
**\<sarang>** kayront: ?
**\<kayront>** in fact, if you ask me, it opens up a whole new ocean of possibilities
**\<kayront>** i mean the "guilty until proven innocent" spin on things
**\<suraeNoether>** kayront there is a strong argumetn from the 1st and 4th amendment right that these financial transactions are free speech and demanding financial histories doesn't jive with the 4th amendment
**\<sarang>** That's much broader than financial regulation
**\<suraeNoether>** anyway
**\<suraeNoether>** not totally relevant
**\<sarang>** ya
**\<suraeNoether>** it's interesting
**\<sarang>** So... good meeting, I take it?
**\<oneiric\_>** what does MRL think about using hashcash or a reduced monero PoW (like pool mining shares) to secure anonymity networks for p2p?
**\<suraeNoether>** and political science-y, so we can call it research :D
**\<sarang>** And you had said that the documents will be published?
**\<kayront>** :D
**\<sarang>** oneiric\_: what does that mean exactly?
**\<suraeNoether>** yeah, sarang, i walked away feeling like it was a room full of allies both for financial privacy in general and for the twin monero-zcash ecosystems. i wasn't expecting that at all, tbqh
**\<sarang>** nice
**\<suraeNoether>** sarang: yes, all the reports will be made public on coincenter.org soon
**\<suraeNoether>** oneiric\_: if you elaborate i could form an opinion :D
**\<sarang>** In the meantime, anything else to share suraeNoether of interest?
**\<lurkinandlearnin>** Sounds really interesting. I'll look into those reports when they drop
**\<suraeNoether>** oneiric\_: i know that stellar uses a weird concensus mechanism involving picking neighbors to form a quorum vote, but rather than being a networking tool, it's intended to replace POW/POS
**\<lurkinandlearnin>** Hadn't even heard of coincenter until now
**\<suraeNoether>** sarang: I read the recent andrew miller paper on probing network topology blindly in bitcoin
**\<oneiric\_>** so, anonymity networks (and ipv6) make it much easier for attackers to perform sybil attacks by spinning up many addresses (nodes) for little cost. adding some form of PoW would help mitigate that possibility by adding some effort to spinning up a node
**\<sarang>** Interesting, I'd be interested to see how that would work
**\<sarang>** and how a PoW integrates to it
**\<suraeNoether>** sarang which is SUPER clever and it could be used similarly for boostrapping blockchain downloads or kovri networking or something like that, if a similar sort of feature can be exploited as in that paper
**\<sarang>** suraeNoether: link?
**\<sarang>** Not sure I saw that paper
**\<suraeNoether>** https://www.cs.umd.edu/projects/coinscope/coinscope.pdf
**\<sarang>** How new is it? Didn't see on IACR
**\<suraeNoether>** i saw it tweeted end of last week iirc
**\<sarang>** word
**\<suraeNoether>** it's clever: it uses inputs with no known outputs and a bitcoin node's behavior when it receives such an input
**\<suraeNoether>** it can't be relayed because it doesn't appear valid
**\<sarang>** Huh, I shall read it today, thanks
**\<suraeNoether>** yeha, they use a purposeful double spend attempt to suss out which nodes you are \*really\* connected to
**\<suraeNoether>** anyway: that paper, plus sarang and my matching paper, comprise most of my time last week and this week other htan the workshop
**\<suraeNoether>** (surae is done now)\\
**\<sarang>** The matching paper is under its reasonably final review
**\<sarang>** we'll post here for internal review soon, and then off to the presses
**\<suraeNoether>** although at the end of the meeting i have a small community announcement
**\<suraeNoether>** sarang we should also consider whether we want to publish our matching paper \*specifically in a journal\* or leave it as an MRL bulletin
**\<sarang>** I also spent a good deal of time on that, but kudos to surae for a lot of work on it
**\<sarang>** Right
**\<suraeNoether>** i feel like it would be valuable to publish in an applied graph theory journal
**\<lurkinandlearnin>** Sorry to interupt but could you explain what exactly "matching" means in this context?
**\<sarang>** And it opens up to additional matching/weighting work too
**\<suraeNoether>** lurkinandlearnin: ah, good question
**\<sarang>** lurkinandlearnin: you can apply graph theory to a transaction graph
**\<sarang>** and this means questions of Monero analysis can be reframed to known graph theory problems
**\<suraeNoether>** lurkinandlearnin: the idea is basically to link transactions in a transaction graph. if it's just a plain old graph with no additional information, mathematicians call it a "matching problem" or an "assignment problem" or sometimes a "marriage problem"
**\<sarang>** suraeNoether formalizes this
**\<sarang>** soon (tm)
**\<suraeNoether>** lurkinandlearnin: so we are applying known techniques to our graph, to get an overall sense of "how bad" our linkability really is, disregarding less complete approaches previous researchers have used
**\<sarang>** Once again, a "please stop publishing on this" to others =p
**\<lurkinandlearnin>** I see. So it's to abstract the data we can get from the blockchain to a form where these established techniques and theories can be applied?
**\<sarang>** Right, we don't have to reinvent the graph-theoretic wheel
**\<sarang>** and it also provides bounds
**\<suraeNoether>** yeah, the number one problem with ring signatures and monero going back years is small anon set sizes. fluffypony makes this an important part of almost every talk he gives, but people still regularly publish papers that re-invent the wheel over and over again. "look, if two signatures have the same ring, you can ... you can... oh boy! i'ma publish!"
**\<suraeNoether>** the novelty of our approach is we are able to find a lower bound on some specific instances of the matching problem
**\<sarang>** It's basically how other types of security proofs go... if you could break X, it'd mean you would have solved Famous Math Problem Y
**\<suraeNoether>** previous approaches have been able to say "well, matching monero is \*no worse\* than sharp P. https://en.wikipedia.org/wiki/%E2%99%AFP
**\<lurkinandlearnin>** Interesting. So is the paper "groundwork" towards using these techniques or have you already got findings?
**\<suraeNoether>** but that's like saying "it's no worse than the worst possible problemt hat God himself couldn't solve"
**\<suraeNoether>** lurkinandlearnin: we are sort of generalizing many previous techniques at once and showing how they fit under a common umbrella
**\<sarang>** We have some algorithmic findings
**\<sarang>** Again, it'll be posted here for internal review soon
**\<suraeNoether>** yerp
**\<suraeNoether>** it's a good paper
**\<suraeNoether>** i like it a lot
**\<suraeNoether>** it really highlights how linkable Monero will be until we get larger anon set authentications
**\<sarang>** Aside from that, Badass Benedikt Bunz put out a new paper on batching in accumulators: https://eprint.iacr.org/2018/1188
**\<sarang>** Unfortunately it applies most directly to RSA accumulators, which are a no-go for us
**\<lurkinandlearnin>** Thanks for the explanations. I'll look forward to it.
**\<sarang>** np
**\<sarang>** I'm working a ZtM update regarding spend proofs, which I realized are useful but missing from the tech documentation
**\<sarang>** as well as some arithmetic circuit research
**\<sarang>** Otherwise, just trucking along with lit review and code
**\<sarang>** A side note that several funding requests are open, including those that fund MRL and other developers: https://forum.getmonero.org/8/funding-required
**\<sarang>** In a bear market, pockets tend to shrink unfortunately :(
**\<sarang>** (disclaimer: one of those requests is for me)
**\<lurkinandlearnin>** Ain't that the truth
**\<sarang>** Loki Foundation is still willing to help fund one of us
**\<sarang>** to the tune of 15K USD total
**\<sarang>** If the funding requests don't complete, I would consider accepting the fiat donation under the right conditions
**\<kayront>** the bear spares no one
**\<lurkinandlearnin>** Loki Foundation?
**\<sarang>** Foundation associated to this group: https://loki.network/
**\<sarang>** Monero-based, so they wish to support researchers (and no doubt it's good PR too)
**\<sarang>** The Foundation as a legal entity is not allowed to donate in cryptoassets
**\<sarang>** so they'd have to donate directly in fiat
**\<lurkinandlearnin>** haha I searched before you answered and only found a german record label
**\<sarang>** Anyway, I welcome comments on such an arrangement
**\<sarang>** I would insist that there be no additional strings that wouldn't apply to any other FFS donor
**\<sarang>** to ensure research independence
**\<lurkinandlearnin>** Well I've never heard of them but if it can be guaranteed no strings then I don't see the problem
**\<sarang>** My goal would be to ensure that it doesn't change the nature of MRL's support
**\<sarang>** It wouldn't become MRL Brought To You By Loki Foundation
**\<sarang>** Anyway, it could be a moo point if the FFS are funded; then Loki would be interested in supporting a new researcher if one came around
**\<sarang>** Anyone else have interesting work to share with the group?
**\<ilyaAldanov>** I do!
**\<sarang>** carry on
**\<ilyaAldanov>** But I guess the important stuff should go first.
**\<ilyaAldanov>** I can go on after the meeting.
**\<sarang>** Nonsense, all researchers are welcome here
**\<sarang>** I'm finished with my update, please go ahead
**\<sarang>** This is the point of the meeting
**\<ilyaAldanov>** Today I want to present the return addresses.
**\<ilyaAldanov>** Return address is a GREAT idea.
**\<ilyaAldanov>** It's also MY idea, but that is unrelated.
**\<ilyaAldanov>** It's quite simple: include sender's subaddress to every transaction header.
**\<ilyaAldanov>** To make transactions unlinkable generate the subaddress from transaction's public key and sender's private key.
**\<ilyaAldanov>** This way it's trivial to generate corresponding private key even after wallet restore.
**\<sarang>** I was thinking about this earlier in the context of other timelock schemes
**\<ilyaAldanov>** What good a return addresses for?
**\<ilyaAldanov>** Many things!
**\<ilyaAldanov>** The most obvious one: a full or partial refund (interactive).
**\<ilyaAldanov>** A merchant can send you funds back without asking for your address.
**\<kayront>** i'm sodl
**\<ilyaAldanov>** Another one: an exchange can return funds that it can't bind to any account.
**\<ilyaAldanov>** the famous PaymentID problem.
**\<ilyaAldanov>** Or if the account is closed for some reason.
**\<ilyaAldanov>** There can be non-interactive services.
**\<ArticMine>** or AML / KYC
**\<ilyaAldanov>** Like micro-credits.
**\<kayront>** .. or returning unused FFS monies to their owners
**\<ilyaAldanov>** You send a coin to the public address and get two in a month.
**\<ilyaAldanov>** But even more!
**\<kayront>** more, you say!
**\<ilyaAldanov>** You send money to a specific address and receive a password to something in the dust.
**\<sarang>** It'd be ~2% increase in a 2-2 txn size
**\<ilyaAldanov>** Yes. But it's per-transaction, not per-output or per-input.
**\<suraeNoether>** ilyaAldanov: it's a very interesting idea. if it works out, that means we have two possible ways of going about doing some sort of return functionality
**\<ilyaAldanov>** It's the only 100% reliable link back to transaction owner.
**\<lurkinandlearnin>** This is a 10/10 idea. The usefulness of these features could help push the more general adoption of subaddresses (which imo is a urgent goal).
**\<sarang>** It'd be a fingerprinting method, as usual
**\<ilyaAldanov>** Yes, but I want to stress out that my return addresses is not limited to refunds.
**\<ilyaAldanov>** sarang ?
**\<sarang>** Anytime some transactions include data that not all do, it distinguishes them
**\<suraeNoether>** it'd be easy to discern who is using these return addresses and who isn't
**\<ilyaAldanov>** Every transaction should have one.
**\<ilyaAldanov>** No exceptions.
**\<suraeNoether>** i can see why you would say that
**\<suraeNoether>** or suggest it i mean
**\<sarang>** Yes, but of course you can't make randomness enforced
**\<lurkinandlearnin>** yes but you could see that the subaddress in the header has received funds in a future transaction, correct?
**\<suraeNoether>** its essentially, what, 32 Bytes additional per transaction? not so bad at all given the functionality that would come out of it
**\<sarang>** lurkinandlearnin: no, but you'd see an output in a ring
**\<sarang>** 64 bytes
**\<sarang>** 2% add-on to a 2-2 txn
**\<suraeNoether>** rihgt
**\<ilyaAldanov>** The return address is just a subaddress - nobody sees when it is used except the owner.
**\<lurkinandlearnin>** yes sorry that's what I meant
**\<suraeNoether>** i think we need a write-up before we can really judge how it's supposed to work, but it's v promising
**\<sarang>** There is one
**\<sarang>** not published tho
**\<ilyaAldanov>** I don't publish it because a) it's a draft b) don't want the coins I don't like to implement it first.
**\<sarang>** The construction of the subaddress is clever ilyaAldanov
**\<sarang>** Heh, Monero doesn't need to be first, just best
**\<suraeNoether>** sarang: there's a write-up for ilyaAldanov's idea?
**\<sarang>** It was sent privately during discussions
**\<kayront>** fwiw i find this a very interesting idea as well
**\<sarang>** The more we discuss it, the more I like it
**\<kayront>** opens up a lot of functionality
**\<ilyaAldanov>** I sent it to Sarang and Isthmus. Can send to you as well.
**\<suraeNoether>** seems less disruptive than DLSAG
**\<kayront>** if it can be made to work without meta/data leakage, sounds like a no brainer
**\<sarang>** Yes, but doesn't solve the same problems
**\<oneiric\_>** +1 sounds like a great improvment over payment id
**\<suraeNoether>** sarang: right, no timelock/block height stuff built in
**\<sarang>** oneiric\_: it doesn't really solve payment ID either
**\<sarang>** it acts as a band-aid for when they require payment ID and you forget it
**\<sarang>** also it's interactive
**\<sarang>** I'm just saying this is orthogonal to DLSAG
**\<suraeNoether>** would they be do-able together or would it be one or the other only?
**\<kayront>** DLSAG = ?
**\<sarang>** You could probably do a separate return subaddress per output address
**\<sarang>** MRL-0008: https://ww.getmonero.org/resources/research-lab/
**\<ilyaAldanov>** If you ask me, I came up with many more use cases for return addresses.
**\<sarang>** I definitely see the usefulness
**\<suraeNoether>** DLSAG = dual-output linkable spontaneous anonymous group signatures
**\<sarang>** But it's our job to rip every idea apart
**\<ilyaAldanov>** I want to talk about one exceptionally useful case tomorrow.
**\<sarang>** Not today?
**\<ilyaAldanov>** One feature per day!
**\<suraeNoether>** i.e.: usual ringCT but with two output keys and a trigger block before which the recipient of the first can spend the first and after which the recipient of the second can spend the second.
**\<ilyaAldanov>** There was Hybrid Mining and Emission Curve days already.
**\<sarang>** ilyaAldanov: it would be necessary to post the construction here for review
**\<sarang>** this would need to be public, of course
**\<ilyaAldanov>** Yes, of course.
**\<sarang>** After you'd brought it up earlier, I started considering the effects this would have if it were optional (or effectively optional), especially on fake selections
**\<ilyaAldanov>** But right now it's a draft. I really appreciate some comments, especially negative.
**\<sarang>** This is an important consideration
**\<sarang>** Even if it's mandatory, you should assume that wallets not using the functionality would be stupid and include all zeros or something
**\<ilyaAldanov>** It'd be useless if optional.
**\<lurkinandlearnin>** I like the fact that subaddresses have found another potential use.
**\<sarang>** and determine what an adversary would do if it saw ring inputs from txns that include a "fake" return address vs a "true" one
**\<sarang>** ilyaAldanov: I know, but you can't make randomness a consensus issue
**\<ilyaAldanov>** That's a perspective I didn't think about. Thanks.
**\<sarang>** It came up with payment IDs a while ago
**\<suraeNoether>** ilyaAldanov: think about it this way: someone publishes a txn with the return key 000000000000001
**\<suraeNoether>** how can you tell that's not genuinely random?
**\<suraeNoether>** should it be blacklisted and not propagated?
**\<suraeNoether>** what about 000..0?
**\<ilyaAldanov>** Yep, I get the idea.
**\<suraeNoether>** or what about 10101110010100111?
**\<suraeNoether>** coolio
**\<sarang>** The goal would be to ensure that even if wallets do this, it doesn't affect other users' rings
**\<ilyaAldanov>** But there're many places where wallets can misbehave.
**\<sarang>** Yes
**\<ilyaAldanov>** Like in the change output.
**\<sarang>** So we should assume they'll be awful and minimize the damage
**\<sarang>** ilyaAldanov: if you approve, I can send your document to suraeNoether
**\<ilyaAldanov>** I approve.
**\<suraeNoether>** or just email it to me at surae@getmonero.org
**\<ilyaAldanov>** But I want feedback!
**\<sarang>** Sure; you'll get the best feedback if/when you release the draft publicly, tho
**\<ilyaAldanov>** Are there any spies of the coins I don't like here?
**\<suraeNoether>** ilyaAldanov: probably, but they also are not very good at their jobs :D
**\<sarang>** probably
**\<ilyaAldanov>** I don't like coins with premines, developer's rewards and obnoxious leaders.
**\<sarang>** Welcome to Club Monero
**\<sarang>** I assume Monono will steal this, but I'm ok with that
**\<sarang>** So our time is nearly up... anyone else have info to share?
**\<nioc>** a while ago there was a request for a recommended ring size for the next hard fork which is April and the code freeze is Jan. I know research has been done to address this request. Where do we stand in regards to a possible ring size increase?
**\<sarang>** suraeNoether: you'd indicated you had a community announcement
**\<lurkinandlearnin>** I am a spy
**\<ilyaAldanov>** I'll publish it, just to put one more section about Shared Secret.
**\<sarang>** cool
**\<lurkinandlearnin>** oh wait I wasn't meant to say that out loud
**\<sarang>** I do not see a reason to increase at this time
**\<nioc>** but more is better :D
**\<suraeNoether>** nioc: recent research suggests that increasing ring size \*may not\* be super helpful, even though \*the min time required\* to generate a guess at the true Monero transaction history is proportional to r: double r and you double that min time required
**\<suraeNoether>** which sounds great
**\<suraeNoether>** but it's not very efficient
**\<suraeNoether>** i would rather: increase r by 1 and the difficulty doubles
**\<sarang>** suraeNoether: your community annoucement? (I don't want to go over if people need to leave)
**\<sarang>** Hmm he has vanished
**\<lurkinandlearnin>** Community announcement: https://www.youtube.com/watch?v=CiRu\_W9tzM8

271
_posts/2018-12-31-logs-for-the-Monero-Research-Lab-meeting-held-on-2018-12-31.md Normal file
View file

@ -0,0 +1,271 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-12-31
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<sarang>** OK, probably low attendance today, but might as well see what folks are up to
**\<sarang>** Hullo ll
**\<sarang>** \*all
**\<suraeNoether>** morning guys
**\<sarang>** taptap this thing on?
**\<endogenic>** good morning
**\<suraeNoether>** howdy :D
**\<dsc\_>** morn'
**\<suraeNoether>** i'm actually excited for this meeting because its' been like two weeks
**\<suraeNoether>** but i don't have much of an update, except "the matching paper is much \*shorter\* now"
**\<suraeNoether>** :P
**\<suraeNoether>** allrighty, so let's begin
**\<sarang>** Heh, no problem
**\<sarang>** I figure most people took it low this week anyway
**\<sarang>** as tends to happen
**\<suraeNoether>** as usual, we'll 1) open up with questions, 2) sarang and i will give some updates, and 3) we'll see if anyone else has been doing anything interesting
**\<suraeNoether>** so, before we get fired up
**\<suraeNoether>** who has some questions
**\<suraeNoether>** ?
**\<suraeNoether>** oh and, just before I forget: i want to bring the community up to speed on current thinking re: block size blowup
**\<suraeNoether>** seems like no one has any burning questions
**\<suraeNoether>** so, sarang, how about you jump in and give us a briefing on your holiday comings-and-goings
**\<dsc\_>** Oh I have a question; what's the status on getting rid of / dealing with payment id
**\<dsc\_>** (or integrated addresses, whatever the recent discussino was about)
**\<endogenic>** dsc\_: i think we need to bring it up at a dev meeting
**\<dsc\_>** ok cool
**\<endogenic>** but i dont know
**\<sarang>** There's general support for deprecation over time, but the question of how/when is still under active discussion
**\<suraeNoether>** dsc\_: sgp\_ recently posted a draft blag post on the matter
**\<sarang>** Right, but that should not be taken as any kind of consensus
**\<suraeNoether>** i'm not sure how much further the discussion has gotten than the pastebin: https://www.irccloud.com/pastebin/cRwyJViz/monero%20scheduled%20address%20upgrade%20timeline%20%5Bdraft%5D
**\<sarang>** very little
**\<suraeNoether>** rihgt
**\<suraeNoether>** this is still quite fluid
**\<endogenic>** dunno sgp\_'s pretty good at representing that stuff :)
**\<sarang>** Heh, very true
**\<dsc\_>** cheers
**\<sgp\_>** hello all
**\<endogenic>** eyyyy
**\<sarang>** Hi sgp\_
**\<sarang>** Want to talk at all about your post draft?
**\<sgp\_>** Sure. I outlined my best summary of how Monero will handle payment IDs going forward and how we got to that decision
**\<sgp\_>** Of course, we all still need to agree
**\<sarang>** I have been muddling over your post proposal
**\<suraeNoether>** i just started reading it this mroning and i'm going to reserve my comments for later today
**\<sarang>** A good deal of discussion centered around info leakage during multi-destination txns
**\<sarang>** since there's only one payment ID per txn (kind of a PITA honestly)
**\<sarang>** and not one per output, which is much simpler IMO
**\<sgp\_>** This assumes unencrypted (standalone) payment ID prohibition in April 2019 and encrypted payment ID prohibition (use subaddresses instead) in April 2020
**\<sarang>** To what extent do we have exchanges represented in the discussion?
**\<sarang>** I operate on the assumption that no exchange reps are in any channels
**\<sgp\_>** The most we've heard from any exchanges is from LocalMonero that helped initiate this discussion earlier this year afaik
**\<sarang>** While I don't think we should make decisions based on exchange wishes, they represent a good chunk of user interaction
**\<dsc\_>** To what extend would Sarang like to involve exchanges? I mean, probably most of us know some folk who work at exchanges, should an effort be made to get in contact?
**\<sarang>** My thought has been as follows
**\<sarang>** Exchanges need to do infrastructure work if we change pIDs
**\<sarang>** and have little incentive to move to safer alternatives (e.g. subaddresses) without being required t
**\<sarang>** to
**\<sarang>** Setting a firm timeline is important, as is providing sufficient time to change
**\<sarang>** There's almost certainly too few developers doing such things at exchanges
**\<sgp\_>** I wrote up this post to help exchanges and other services be prepared, but we've had a historically difficult time reaching these services
**\<dsc\_>** nice sgp\_
**\<sarang>** One option has been doing wallet defaults only, and not consensus
**\<sarang>** this at least makes most transactions more uniform
**\<endogenic>** just in my personal view i dont think we need to worry too much about third parties… they're going to have to adapt
**\<suraeNoether>** maybe part of our discussion should be to hold a call with some folks at exchanges or something like that, but my thoughts on the matter are in alignment with sarang's: the exchange will make whatever \*mandatory\* changes the core team decides upon, and it's not like they are going to be able to say "well, what if you guys did \*this\* instead, it'd be easier on us and it would lead to a better public key
**\<suraeNoether>** infrastructure" or something. that's not their "mission" so to speak
**\<sarang>** "we've had a historically difficult time reaching these services" <--- calls may be tough
**\<endogenic>** who's going to pay us to reach out to them though? :)
**\<sarang>** FFS to the rescue
**\<sarang>** heh
**\<dsc\_>** I can forward stuff to Kraken if neccesary
**\<endogenic>** bah
**\<endogenic>** the exchanges should
**\<suraeNoether>** if monero moved to pairings based crypto tomorrow and we modified our whole key structure, they would groan, roll their eyes, curse our names, and then make the changes without publicly complaining at all
**\<endogenic>** yes
**\<endogenic>** agreed
**\<sgp\_>** I may be able to talk to Circle and Poloniex. I have someone's email
**\<sarang>** Cool. Step 1: make a damn decision
**\<suraeNoether>** well, let's do a cursory reach-out. let's see if kraken, circle, and polo are willing to provide some feedback, even if it's "please don't make any changes for the love of god"
**\<sarang>** unless we want exchange input well in advance of decisions
**\<suraeNoether>** in the meantime, we'll prioritize a decision on this over the next few days
**\<hyc>** polo has historically been pretty open to communication
**\<endogenic>** feedback wont do harm
**\<sgp\_>** We can still approve or reject this recommendation. Give them a pre-release of the press release of sorts
**\<sarang>** that seems fair and in line with our transparency
**\<suraeNoether>** yeah
**\<dsc\_>** Cool. thanks guys.
**\<sarang>** thanks sgp\_ for taking the reins on the public-facing side of this
**\<sarang>** let's all review and think about options over the next few days as suraeNoether mentions
**\<sgp\_>** I've received feedback from a few people. I'll make the changes to the doc this afternoon, but the overall message is the same
**\<sarang>** esp. relating to timelines, consensus v wallet default, and the consequences on information leakage
**\<suraeNoether>** okay, since we are on specific topics, before we move on to get sarang's research update, we may as well talk about the blocksize blowup thing
**\<sgp\_>** One thing I claimed we are not doing: enforcing payment IDs. Are we in agreement here?
**\<suraeNoether>** yes
**\<sarang>** We can't effectively enforce encrypted IDs
**\<sgp\_>** Cool, thanks
**\<sarang>** and wallets can always be dumb about it anyway
**\<sarang>** but having the default wallet do the right thing will help a great deal
**\<suraeNoether>** okay, so regarding this blowup/dynamic block size problem
**\<suraeNoether>** first: solutions are easy and numerous, each with pros and cons, but most involve magic numbers of some sort
**\<suraeNoether>** for those of us in the audience, a magic number is \*arbitrarily chosen in code\*
**\<sarang>** and consensus, which places a firm deadline on changes
**\<suraeNoether>** yes
**\<suraeNoether>** and this is sufficiently urgent of a problem that we should come up with \*some solution\* asap
**\<sarang>** the gist of the problem: it's easy to blow up the block size by spending money, and it stays there
**\<suraeNoether>** it's cheap to keep block size big, too
**\<sarang>** yes
**\<sarang>** There was a clever proposal to start the penalty \_below\_ the median
**\<sarang>** to bring size down by default
**\<sarang>** others involve (at the very least) a high cap that still avoids the crazy blowup possibilities
**\<suraeNoether>** Options include but are not limited to
**\<suraeNoether>** 1) change sample size of median block size to something very large like a year. pro: easy, ensures that an attacker has to be executing an attack for at least half a year before expecting any success. con: adds inflexibility to monero block size.
**\<suraeNoether>** (it makes sense to make this increase in window size to be somehow proportional to our change in fees, to ensure that it doesn't cost \*less\* to attack today than before bulletproofs)
**\<suraeNoether>** 2) add a momentum term to block size so that bigger changes are harder to effect. pro: also easy, improved flexibility. con: unlike median, determining the strength of an attacker required to execute the attack over a sustained period is a trickier question.
**\<suraeNoether>** 3) change block size penalty to begin sub-median. pro: incentive against the attack! great! con: weak incentive, and a determined attacker is already blowing cash on this attack
**\<sarang>** We should also consider the two parts to this: (1) getting the block size big, (2) keeping it big
**\<suraeNoether>** yeah, we could add a rapid decay back to "small"
**\<suraeNoether>** that requires lots of funds to counteract
**\<suraeNoether>** 4) change block size dynamic updating to an \*additive\* update instead of a \*multiplicative update.\* Example: if median block size for the past N blocks is greater than some threshold, then change block size as S = S + diff\_S instead of S = r\*S for some r. Keep the \*decreases\* in blockchain size multiplicative. Pros: leads to an exponential decay in block size back to zero in the absence of demand, and leads
**\<suraeNoether>** to at best a linear increase in block size in the presence of demand. Con: Not intuitive?
**\<suraeNoether>** 5) limit the maximum change in block size over some time period by some factor. example: do not allow block size to grow more than 2x in a year. pro: easy to intuit, provides a cap on growth but still allows growth, etc. 2x a year is very fast exponential growth generally but we would have time to notice a bloat drift attack and maybe come up with other solutions. con: 2x a year is still very fast exponential
**\<suraeNoether>** growth.
**\<suraeNoether>** in all cases, we have to end up picking some magic numbers that would need to be justified to the community. example: why 2x a year instead of 1.05x a year, or 3x a year?
**\<spaced0ut>** isn't prevention a little more important than the cure? rapid decays back would solve one issue but wasn't it determined someone could grow the chain 30TB or something quickly?
**\<suraeNoether>** last I spoke to fluffypony about this, he said something like option (1) is most easy to get consensus on because we can justify a change based on the decreased fees. the change is pretty intuitive. with an 80% reduction in fees we could have a 5x increase in median sample size
**\<sarang>** This needs a robust long-term solution, but also a short-term solution
**\<suraeNoether>** spaced0ut: i agree with that sentiment
**\<endogenic>** suraeNoether: imo the community doesn't need things justified to them so much as you have to consider them justified from a model pov - community looks to you
**\<endogenic>** cause they'll be able to investigate what you propose
**\<suraeNoether>** endogenic: i disagree. look at bitcoin block size debate or our current ring size debate. everyone wants a justification of the magic numbers proposed.
**\<sarang>** FWIW the funds required to execute such a bloat attack to TB size are O(100K) USD IIRC
**\<endogenic>** suraeNoether: monero != bitcoin tho.. big differences
**\<sarang>** magic number != overall strategy tho
**\<endogenic>** wow r u me
**\<moneromooo>** If you ask for community consensus, you'll get the noisy ones to get their way, and they'll typically be short term profit people who \<backspace a bit>.
**\<sarang>** I want developer consensus
**\<endogenic>** ^
**\<moneromooo>** Oh, then that's much better. If you include people like ArticMine in this.
**\<sarang>** Everyone will/should agree that avoiding TB bloat is worth changing shit
**\<moneromooo>** People Who We Know Have A Clue.
**\<suraeNoether>** \*nod\* i agree with all the above, to be honest
**\<sarang>** at the very least, getting a worst-case short-term fix (like a high cap) in place for spring is the necessary starting point
**\<spaced0ut>** as long as the change clearly shows everything possible is being done to have to avoid setting a hard limit like BTC. not many will think negatively.
**\<suraeNoether>** i think for the spring hard fork, we should try for (1) and (3) together. start penalty at 80% median, and increase median sample size window by 5x.
**\<sarang>** spaced0ut: a hard limit while we actively determine a more robust solution isn't all bad
**\<sarang>** but I see the point
**\<suraeNoether>** but before we make that decision, i want to back-of-the-napkin the cost of the attack before and after the change
**\<suraeNoether>** Isthmus has been helping with some of that
**\<suraeNoether>** but we should also make a decision on this v soon, like end of week
**\<sarang>** Isthmus has a technical note draft on it
**\<suraeNoether>** the cost of changing block size dynamics a second time later this year is low; the cost of permanently bloated blockchain is much higher in my mind
**\<sarang>** If we establish an idea, we can compare to his original analysis
**\<sarang>** yes
**\<sarang>** doing nothing is the worst option
**\<suraeNoether>** sarang: yeah exctly.. when he's done sleeping and recovering from the past month of work. :P
**\<sarang>** OK, for the sake of this discussion, let's work up a proposal for combining options 1 and 3 from suraeNoether's list above
**\<sarang>** (not right now, but I mean as an initial proposal)
**\<spaced0ut>** sarang, i agree. its probably the safest option for XMR's longevity really. that won't be fun to explain so that most people understand though
**\<sarang>** that will make the attack slow and expensive, and bring block size back down after such an attack
**\<suraeNoether>** yep. let's shoot for end of week for our proposal
**\<sarang>** spaced0ut: it's easy if you say "the consequence of leaving it is TB blocks"
**\<sarang>** people hate bloat already
**\<spaced0ut>** yeah
**\<sarang>** These options have little effect on the average user if done properly
**\<suraeNoether>** we don't really have MIPs do we? :P
**\<sarang>** nope
**\<sarang>** Every Commit Is a MIP (tm)
**\<suraeNoether>** that should be on a t-shirt with several cows coding on the back
**\<suraeNoether>** paging rehrar[m] i'd buy several of those shirts
**\<suraeNoether>** well, two
**\<sarang>** So
**\<sarang>** This week I've been doing lit review in between Festivus celebrations, and doing some documentation writeups
**\<moneromooo>** The intent of the block size increase is to allow sustained spikes (to the extent it is not an oxymoron). A year's smoothing will prevent that from working.
**\<sarang>** moneromooo: yes, but at the cost of our simple model failing to prevent sustained bloat
**\<moneromooo>** That seems to be a false dichotomy.
**\<sarang>** Should sustained spikes not also yield a corresponding cost?
**\<suraeNoether>** moneromooo: ehhh it doesn't prevent it. it merely raises the bar for what is required to push block size up, so spikes have to be sustained longer for them to impact the base layer. but you are correct; any time we have a variable/dynamic capacity, this allows for bloat, but fixed capacity is inflexible
**\<suraeNoether>** but to be perfectly honest, if we find ourselves in a situation where people are regularly waiting until the next block to stash a transaction because the current block is full...
**\<moneromooo>** This is a negative question, so "sustained spikes should yield a corresponding cost".
**\<suraeNoether>** then in this situation, we probably will have some lead time to correct our block size dynamics to prevent it from being a systemic load problem
**\<moneromooo>** The point is, if ytou have to waiut for half a year for the thing to kick in, it's pointless for spikes.
**\<suraeNoether>** moneromooo: well, we can try one of the other methods that are more immediately flexible, like a momentum term or whatever
**\<suraeNoether>** or we could just make fees great again
**\<hyc>** yes ^
**\<sarang>** heh yes to which
**\<suraeNoether>** on the other hand, we could just recognize the dynamic block size flexibility to be a long-term flexibility instead of somethign designed to handle short-term volume spikes
**\<hyc>** fundamentally, the reason bloating the chain is cheap is because fees are cheap and XMR/fiat is cheap
**\<suraeNoether>** hyc yes
**\<spaced0ut>** Just throwing an incomplete idea out there. Has anyone thought about increasing fee's as block size increases then decreasing fees based on some median tx count?
**\<suraeNoether>** spaced0ut: the idea of blocksize-dependent fees is one that is very interesting to me, but i haven't dived into the idea
**\<suraeNoether>** but that allows for an attacker to bloat the blockchain and drive everyone else's fees up, ala the bitcoin bloat from ... whenever that was. 2017? sheeee
**\<tnsepta>** i think that one was just lots of real transaction activity?
**\<hyc>** yes, but the net effect is the same
**\<hyc>** everyone else's fees go up, to get their txs mined
**\<suraeNoether>** okay, we'll think about this a little harder this week and see what there is to see
**\<suraeNoether>** brb
**\<tnsepta>** which is what makes this problem hard, you have to increase the cost of bloat attack without also making transactions way too expensive
**\<tnsepta>** two sides of the same coin
**\<hyc>** I would say that's an impossibility
**\<tnsepta>** of course it's impossible to do both at the same time, i mean it's hard to balance the two right
**\<hyc>** you can't distinguish "real" txs from "bloat" txs
**\<spaced0ut>** the truth has been said in here multiple times already. it just sucks to admit. unfortunately our chain isn't insanely expensive to attack right now. there has to be a limit. make it complex or simple but it comes down to size not cost. can't make cost high enough without making it expensive for legit use.
**\<hyc>** standard tragedy of commons scenario
**\<sarang>** and size is dependent only on usage, of course... if you need to get N txns on chain, it costs O(N) in size no matter what
**\<sarang>** Aight, that's two items of priority: (1) fee structure; (2) payment ID timeline
**\<sarang>** Any other work of note?
**\<moneromooo>** I'm doing some more work on multiuser txes (the type you can use, eg, coinjoin with).
**\<moneromooo>** That might be interetsing to people here ?
**\<sarang>** go on...
**\<tnsepta>** is there a benefit of doing coinjoin when we're already doing RCT?
**\<moneromooo>** Yes. Even more privacy.
**\<moneromooo>** And atomic multi user spends.
**\<tnsepta>** ahh ok
**\<hyc>** does it require all participants to be online at once?
**\<moneromooo>** There \*might\* also be a way to have smaller range proofs, but I'm not sure.
**\<moneromooo>** No.
**\<sarang>** Go on...
**\<moneromooo>** Well, yes if you want it to be fast :D
**\<hyc>** I always want computers to be fast.
**\<sarang>** What's the basic structure moneromooo ?
**\<moneromooo>** I'm making it like multisig. You pass a file around, and write your things. 2N-1 comms though.
**\<sarang>** afaik this is the first I've heard of your work
**\<moneromooo>** atm, I've got a first N comms rounds with everyone adding their inputs/outputs, then another ~N with people signing after checking their I/O are what they specified.
**\<hyc>** who would want to use this approach?
**\<moneromooo>** People who want to use a coinjoin style tx, and people who want to atomically pay.
**\<hyc>** passing this file around sounds like it carries sensitive info, what's the danger of exposing it prematurely?
**\<moneromooo>** (ie, Alice and Bob want to pay Carol, but only if the other also does)
**\<moneromooo>** Not much I think.
**\<sarang>** you're effectively doing partial signatures?
**\<moneromooo>** You create MGs for the outputs you own.
**\<moneromooo>** So kinda yes.
**\<sarang>** MG?
**\<moneromooo>** I think that's a MLSAG.
**\<sarang>** The smaller range proof idea would be an MPC on a bulletproof?
**\<sarang>** which is possible, but we've never had a definite use case
**\<moneromooo>** I don't know. That'll be your job to find out :P
**\<sarang>** heh
**\<sarang>** well fwiw, bulletproof mpc is a known construction
**\<gingeropolous>** damn, missed the bloat thing. i like 1 and 2. I think 1 can be the quick easy fix for now... and if we can figure out the best double mechanism (#2) then we should probably switch to that, because that can allow for spikes
**\<moneromooo>** tnsepta: if you have more than one user, it breaks down some of the analysis you can do since you can't assume all inputs have a common owner.
**\<sarang>** moneromooo: is there a branch with any work? or is it just at the "here's the math" stage?
**\<moneromooo>** There's a "multi" branch, which has a PoC in core\_tests.
**\<moneromooo>** I've started working on the simplewallet tooling now.
**\<spaced0ut>** Could the same attack used to expand blocksize and bloat the chain also be used to create an insane amount of identical mixins to the point that future tx would have a high chance of having 10 identical mixins and your real spend?
**\<sarang>** How do you get so much done simultaneously moneromooo ?
**\<sarang>** Surely you burn the candle at all ends
**\<moneromooo>** I have four legs. Humans only use two hands to type.
**\<sarang>** spaced0ut: what do you mean?
**\<sarang>** Do you mean the ring union analysis method?
**\<sarang>** it's extremely unlikely to occur without active selection
**\<sarang>** Unless you mean that the adversary controls a large percentage of available outputs and therefore knows other true spends?
**\<spaced0ut>** okay. i wasn't sure if that held true in a scenario where the chain grew 100x larger and an attacker was sending the exact same amount every time. i'm a noob on input selection
**\<sarang>** In that case, sure, that's always a possibility for an attacker who wants to spam the chain
**\<sarang>** Amounts are irrelevant
**\<spaced0ut>** yes ofc. i worded that funny. you answered me though thanks
**\<sarang>** roger
**\<sarang>** moneromooo: your idea intrigues me, and I'll be interested to examine the details
**\<sarang>** Well, we have come to the end of our allotted time
**\<sarang>** Great discussion all around
**\<sarang>** We'll each move into the future sometime today; let us know what it's like when you get there

269
_posts/2019-01-07-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-01-07.md Normal file
View file

@ -0,0 +1,269 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2019-01-07
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<suraeNoether>** okay everyone
**\<suraeNoether>** time for our Monday research meeting
**\<suraeNoether>** before we get going, let's open up the meeting to questions! i like questions
**\<moneromooo>** I want to know whether knaccc's propose change to the ecdh mask is good/safe, so I can code it early enough for the fork.
**\<suraeNoether>** is knaccc around? i'm still unclear enough on the details of \*what exactly\* is being proposed. in terms of security, picking a mask from the same set as the value to be hidden is fine to do, but the devil is in the details
**\<sarang>** Right, so the idea was to make the ECDH amount mask deterministic from the shared secret
**\<suraeNoether>** i thought it was to select the mask from a smaller set so we can describe it with fewer bytes
**\<sarang>** e.g. mask = H('mask',z,i) for example
**\<sarang>** There was a separate idea to shrink the size of the encrypted amount data type
**\<sarang>** making the mask deterministic means you shave 32 bytes off each output
**\<suraeNoether>** ah, i see. and the question is "will this be good enough entropy because z itself is hashed?"
**\<sarang>** The only thing to consider, I think, is that outputs with the same index and shared secret share a mask
**\<suraeNoether>** if we are concerned with loss of entropy, we can use HMACs. they don't lose entropy after iteratively hashing in the same way... oh
**\<suraeNoether>** what if we add an additional nonce that indicates the index among the outputs, assuming the output keys are lexicographically ordered?
**\<sarang>** From an MLSAG perspective, we care only that the mask is uniformly distributed and known only to the sender/recipient
**\<sarang>** that's what the proposal includes
**\<suraeNoether>** ie H(m,z,i,j) where j = j^th output
**\<suraeNoether>** oh
**\<suraeNoether>** i'm clearly catching up on this. :P i didn't know this was written up, can I get a link?
**\<sarang>** I don't believe that was written up AFAIK
**\<suraeNoether>** oh, then i feel a little less bad
**\<suraeNoether>** wait quick question
**\<suraeNoether>** H('mask',z,i,j)... z is the amount being masked here?
**\<sarang>** No, z is the shared secret; z=arG in the standard address case
**\<sarang>** The encrypted amount is still included elsewhere in the ecdh data
**\<suraeNoether>** yeah, looks fine to me. my only concern is that an adversary gets some partial control over z
**\<sarang>** How?
**\<suraeNoether>** but that's taken care of by CDH
**\<suraeNoether>** sender picks r
**\<suraeNoether>** recipient picks a
**\<suraeNoether>** they both have a little control
**\<sarang>** Well previously we used a random mask and used z to encrypt that
**\<sarang>** So anyone who got z could compute the mask anyway
**\<sarang>** The difference here is that the mask is now completely deterministic
**\<oneiric\_>** is there a "known-best" algorithm, or set of algorithms, for generating a bounded random distribution?
**\<suraeNoether>** oneiric\_: you mean a uniform distribution on a bouned set or...?
**\<suraeNoether>** that's true, sarang, but ...
**\<sarang>** ...
**\<suraeNoether>** there's a difference here, and i need to figure out how to express it. one moment.
**\<sarang>** The way I see it, the difference is only that the mask is now deterministic but still limited to the view of sender/recipient
**\<sarang>** It's reused if the same shared secret is used elsewhere with identical index
**\<oneiric\_>** suraeNoether: mean like, obfs4 generates random padding for dpi resistance. they bin based on common tor packet sizes. would like to know if there are particular mutations should perform on sampled, binned sizes to get a good random distribution
**\<suraeNoether>** okay, so the difference here is that \*partial adversarial control over this z\* is being combined with using z as input for a one-way function that is allegedly masking some secret information.
**\<suraeNoether>** the sender presumably wants to protect their own amount
**\<suraeNoether>** the recipient could just reveal their own private view key if they want to be a jerk
**\<suraeNoether>** so control over view key a isn't a big deal
**\<sarang>** Our use of hash functions is about as uniform as you can expect (slight bias with H\_s)
**\<sarang>** Again, keep in mind that anyone who can compute the shared secret (e.g. view key) can \_already\_ decrypt the mask now
**\<suraeNoether>** right, the only fix i can think of would be computing H('mask', HMAC(z), i, j), which would sort of ensure that the security reduces to \*revealing z,\* following the strength of hmacs
**\<sarang>** and thereby reconstruct the amount commitment
**\<suraeNoether>** and i'm not sure what would be "fixed"
**\<suraeNoether>** other than, in general, i like avoiding using any adversarially controlled data as input for protecting a secret
**\<sarang>** Pro: shave off 32 bytes per output; commitments themselves are not deterministic
**\<sarang>** whoops, that was for the con list
**\<sarang>** Only downsides I see in practice relate to reuse of shared secrets
**\<suraeNoether>** well, if it's two separate transction,, the sender should select two distinct random keys
**\<sarang>** Sure, but they don't have to
**\<suraeNoether>** but what if a sender maliciously selects the same random transaction keys on purpose? what happens? the mask is the same for two different transactions.
**\<suraeNoether>** right
**\<suraeNoether>** but the sender already knows the amounts
**\<sarang>** In any case, it only leaks information that the two parties had already
**\<knaccc>** if you use the same r or s with the same recipient twice, i don't think that's a security breach
**\<knaccc>** it's a linkability breach though
**\<sarang>** But it was already
**\<knaccc>** yes
**\<suraeNoether>** knaccc: if i'm an observer and i know two transactions use the same mask, i can figure out which transaction is larger and i can compute the \*difference in amounts\* between those two transactions
**\<suraeNoether>** so i suppose this could be a way for a sender to surreptitiously leak transaction amounts to exterior parties without ever revealing anything to them directly
**\<sarang>** suraeNoether: that was already possible
**\<knaccc>** suraeNoether yes i agree
**\<knaccc>** right yes, they could always set the same mask twice
**\<knaccc>** now there is only one random variable to not screw up :)
**\<suraeNoether>** on the other hand, the problem can be avoided by computing the mask as H('mask', z, i, P\_output) where P\_output is the output key being masked.
**\<sarang>** Not even that... the encrypted amounts already use the shared secret
**\<suraeNoether>** why not H('mask', z, i, P)?
**\<knaccc>** sarang lol yes good point
**\<sarang>** In fact, encrypted amounts should also use P
**\<suraeNoether>** okay, so including P seems to be a good way to avoid the lex ordering above too
**\<knaccc>** holw on, what's z? the shared secret?
**\<suraeNoether>** heck, you could include as much crap in that hash as possible, like the signing ring and everything public
**\<sarang>** Oh heh, including P really does nothing
**\<suraeNoether>** knaccc: yeah, rA = aR
**\<sarang>** it's determined from z entirely
**\<sarang>** d'oh
**\<suraeNoether>** oh hehe
**\<sarang>** Reusing this to the same full address will gain you nothing
**\<sarang>** So: the motto is basically not to reuse shared secrets, or you're already being bad to yourself
**\<suraeNoether>** and you may be being bad to your recipients
**\<knaccc>** suraeNoether do you really mean Hs(aR||i)?
**\<suraeNoether>** knaccc: yes
**\<suraeNoether>** i think
**\<knaccc>** cool just checking
**\<suraeNoether>** \*thumbs up\*
**\<knaccc>** cos it's only the per-output shared secret that is ever used anywhere
**\<suraeNoether>** okay, moneromooo sarang
**\<suraeNoether>** oh wait
**\<sarang>** ...
**\<suraeNoether>** okay i agree, re-using transaction keys r is the root of all evil.
**\<suraeNoether>** but we need some way to order these keys for multiple outputs at least
**\<moneromooo>** So since money is the root of all evil... you make money by reusing transaction keys ?
**\<knaccc>** suraeNoether the ||i in the per-output shared secret does that, right?
**\<suraeNoether>** heh
**\<sarang>** yes
**\<suraeNoether>** yes
**\<suraeNoether>** yeah, that's a good way to deterministically derive masks
**\<suraeNoether>** i like it
**\<suraeNoether>** okay, moving along: do we have any further questions?
**\<sarang>** There was the question of a reduced amount ecdh size
**\<moneromooo>** I'd like to get that written out with details ^\_^
**\<oneiric\_>** just the one about random distributions...
**\<moneromooo>** The final "this is good, safe and vetted" version if you will.
**\<suraeNoether>** oneiric\_: i need a little bit more detail on your question
**\<moneromooo>** I thought the amount size one was already vetted ?
**\<knaccc>** very non-urgent, but there is the refund scheme. https://paste.fedoraproject.org/paste/lpM4dWKuV7KKCeAPn~P4Fw/raw
**\<suraeNoether>** knaccc: yeah i started reading that right before the meeting
**\<sarang>** Regarding the 64-bit amounts, I know it was discussed earlier but thought it best to bring up in meeting for a final thumbs-up
**\<oneiric\_>** suraeNoether: what more information do you need?
**\<suraeNoether>** oneiric\_: " they bin based on common tor packet sizes. would like to know if there are particular mutations should perform on sampled, binned sizes to get a good random distribution" <--- do you mean you have a histogram and you need to pick a random number from that histogram as if it were a probability distribuiton? i'm not sure what you mean yet.
**\<oneiric\_>** picking from a histogram sounds pretty close to what i want to do, or close to what obfs4 does
**\<suraeNoether>** sarang: let's collaborate on an ascii one-sheet for moneromooo on both amounts and masks for moneromooo
**\<suraeNoether>** oneiric\_: oh then the answer is: hells yes
**\<suraeNoether>** i'm not sure if this is sufficiently on-topic for the room
**\<oneiric\_>** ok, will keep looking elsewhere. thanks suraeNoether
**\<sarang>** Can we confirm people's thoughts on reducing ecdh amount size?
**\<suraeNoether>** oneiric\_: nah, i got you in PM
**\<sarang>** Right now encrypted\_amount = amount + H(z)
**\<oneiric\_>** :)
**\<sarang>** all are 32 bytes as usual
**\<sarang>** the proposal was to reduce amount to 8 bytes, take the bottom 8 bytes of H(z) and XOR
**\<sarang>** thereby keeping that data type down to 8 bytes
**\<knaccc>** moo has reimplemented that as encrypted\_amount = keccak("amount" || shared secret)
**\<knaccc>** mooo\*
**\<sarang>** Sure, that's even better
**\<sarang>** Er, wait
**\<sarang>** that's the final encrypted amount sent to the recipient?
**\<knaccc>** oops i left out tons. i meant encrypted\_amount = 8 byte amount XOR 8 bytes of keccak("amount" || shared secret)
**\<sarang>** aha
**\<sarang>** yes
**\<sarang>** I seem to remember suraeNoether had much to say about this earlier when it was first brought up?
**\<knaccc>** i think surae might have been thinking about what would happen if there was an auth tag or something to check brute force attempts against
**\<suraeNoether>** nope, i never should have brought auth into the discussion becuase it was aside the main point
**\<sarang>** Is output index also considered in this hash construction?
**\<suraeNoether>** so the main thing my concern was
**\<knaccc>** yes the entire thing is encrypted\_amount = 8 byte amount XOR 8 bytes of keccak("amount" || Hs(8aR||i))
**\<suraeNoether>** hiding an N-bit number with an N-bit number, mod 2^N
**\<suraeNoether>** why 8aR? aR is guaranteed to be on the curve if A and R are both on the curve...
**\<sarang>** Recipient can't guarantee anything about R
**\<knaccc>** yes, but instead of checking if R is in the subgroup of G, we just mul8 so no check is required
**\<knaccc>** everywhere you see people talking about aR, they really mean 8aR
**\<knaccc>** that's something people don't discover usually until they read the code
**\<knaccc>** because it's always ommitted for brevity
**\<suraeNoether>** oh fantastic, that's fine
**\<suraeNoether>** i usually only think about it when computing hash-to-piont
**\<suraeNoether>** point\*
**\<suraeNoether>** that's bad of me
**\<moneromooo>** When people tell me aR, I compute aR...
**\<sarang>** Hence writing up details on this as requested
**\<knaccc>** moneromooo well in the ecdh case, you were using a shared secret that was based on 8aR
**\<suraeNoether>** so, short answer on whether it's safe to just use 8 bytes of keccak to mask an 8 byte number
**\<suraeNoether>** is yeah, it should be fine
**\<knaccc>** partaay!
**\<suraeNoether>** although rather than only xor'ing the first 8 bytes
**\<suraeNoether>** you could break keccak(stuff) into 8 byte blocks and xor all of them
**\<knaccc>** lol
**\<sarang>** ?
**\<sarang>** there's nothing to be gained from that
**\<moneromooo>** Can I take this as a vote of non confidence in keccak ? :P
**\<suraeNoether>** 8 byte amount XOR first 8 bytes of keccak XOR next 8 bytes of keccak XOR ...
**\<suraeNoether>** no, it's simply using all the entropy from the output of keccak
**\<knaccc>** it's pretty standard practice when you have a csprng to just xor the stream against the plaintext
**\<sarang>** yes
**\<suraeNoether>** yeah, it is
**\<knaccc>** and you don't need more than 64 bits of entropy to encrypt 64 bits
**\<sarang>** moneromooo: sure, replace keccak with the identity function for simplicity
**\<moneromooo>** There is a pointless keccak you mean ?
**\<knaccc>** i don't know what sarang means either
**\<suraeNoether>** i'm just mentioning it's an option. if the first 8 bytes are indistinguishable from uniform, then great, but reducing the output of keccak to the first 8 bytes does a lot to hurt 2nd pre-image resistance.
**\<moneromooo>** Hmm. OK. There's a few places where that's done. Like the payment id stuff.
**\<moneromooo>** I think some subaddress stuff too.
**\<knaccc>** right, so the question is whether the first 8 bytes of keccak are indistinguishable from uniform, which I think it is
**\<knaccc>** otherwise it'd be a terrible hash
**\<sarang>** I was only joking :/
**\<knaccc>** hehe
**\<sarang>** Yes, a subset of the hash output is uniform
**\<suraeNoether>** i need to think about exactly how much 2nd pre-image resistance is even important here, though
**\<sarang>** Keep in mind that the recipient does a commitment reconstruction too
**\<sarang>** So any mismatch between encrypted amounts (which the sender can always just make up) and the commitment will be detected
**\<sarang>** We should always assume that the sender is lying about the amount
**\<suraeNoether>** even if we find two R, R' such that keccak("amount" || Hs(8aR||i)) is identical, we send two transactions to whoever controls the view key a, and the encrypted amount has the same xor mask... but so what? even if you took those two encrypted amounts and xor'd them together, you would cancel the mask, but then you just have two xor'd amounts... i don't know.
**\<suraeNoether>** anyway, we can avoid the problem of 2nd pre-image resistance by XOR'ing all the blocks
**\<suraeNoether>** i'm just not convinced it's important here
**\<knaccc>** i think keccak is immune
**\<suraeNoether>** keccak is pre-image resistant. truncations of keccak are not necessarily. easy example, the \*first bit\* of keccak is \*not\* second pre-image resistant
**\<moneromooo>** So something like this ? https://paste.debian.net/hidden/38907823/
**\<moneromooo>** (not tested yet)
**\<knaccc>** if the first bit was not 2ndpreimageresistant, then it would not be a decent hash
**\<suraeNoether>** moneromooo: that looks to do what i think it should do, yeah... but that's assuming sarang and others agree with me
**\<moneromooo>** Well, it can't hurt, even if it's pointless.
**\<suraeNoether>** knaccc: technically it's pre-image resistant \*asymptotically.\* but in the concrete sense of security, i can break 2nd pre-image resistance for the first bit in an astonishingly short period of time
**\<knaccc>** it only helps if the randomness in the hash is not evenly distributed
**\<suraeNoether>** moneromooo: yeah, the cost is a few milliseconds when signing. \*shrug\*
**\<knaccc>** suraeNoether maybe you'll have to spell out how you'd do that, but i don't think that's possible if the first bit is uniformly distributed
**\<suraeNoether>** knaccc: okay check it out
**\<suraeNoether>** pick a random number x
**\<suraeNoether>** compute keccak(x)
**\<suraeNoether>** select the first bit
**\<suraeNoether>** i have a 50% chance that your bit matches the first bit of keccak(0), and a 50% chance it matches keccak(1), and a 50% chance it matches keccak(2), and so on
**\<knaccc>** yes
**\<suraeNoether>** finding a 2nd pre-image for your bit is as rapid as finding a heads up fair coin
**\<sarang>** this seems... pedantic
**\<knaccc>** maybe i need to re-read the definition of 2nd pre-image resistance and why it matters in this scenario
**\<sarang>** for the level we're working with (2^64) it should not
**\<suraeNoether>** it is. i'm just saying truncating a secure hash function according to whatever security property we are talking about... in general.... doesn't result in a secure hash function.
**\<suraeNoether>** ^ it is \*pedantic\*
**\<suraeNoether>** knaccc the answer you are looking for perhaps is this: i have to try, in expectation, as many pre-images as there are possible outputs, before finding a 2nd pre-image
**\<suraeNoether>** so asymptotically with a security parameter that gives you the ridiculous 1-bit case, it's still technically a secure hash function, i guess
**\<suraeNoether>** it's just not practically one
**\<suraeNoether>** anyway
**\<suraeNoether>** sarang: how about you tell us about your work for the past week or so, and then i'll give my update, and anyone else doing any other work can chime in
**\<suraeNoether>** and we'll wrap it up
**\<knaccc>** suraeNoether ah sorry i know what you mean by 2nd pre-image resistance now, for some reason i was confused on terms. so yes, there is certainly a 2nd pre-image resistance issue at 64 bits
**\<knaccc>** but not in a way that actually matters
**\<sarang>** This past week has basically been a sandstorm of proposals to consider and review
**\<sarang>** Payment IDs
**\<sarang>** Refund addresses
**\<sarang>** Block size and penalty structure
**\<sarang>** and so on
**\<sarang>** as well as the release of the second episode of Breaking Monero
**\<knaccc>** oh yes i loved one of your metaphors in that vid
**\<suraeNoether>** knaccc: right, finding a 2nd pre-image at 64 bits itself takes a long time. it's not cryptographically long periods of time short of 80 bits... but i can't really think of what such a pre-image would gain an attacker, either, so like I said i'm not sure how much it's necessary
**\<knaccc>** can't remember what it was now
**\<sarang>** Was it burning the envelope as a heuristic?
**\<knaccc>** it was eating the envelope and walking away
**\<sarang>** heh
**\<knaccc>** i lolled like crazy on that
**\<sarang>** The current loose consensus seems to be that a two-median approach to block size cap is reasonable but not ideal
**\<sarang>** as it will at least slow the bloat
**\<sarang>** For payment IDs there is less consensus about the timeline
**\<suraeNoether>** my work this past week included: 1) some coding simulations for the matching paper, 2) working on the monero konferenco website, which should be up and running before jan 15, which is when i'm going to put out a formal call for papers (although i've already heard back from a few folks). 3) refund proposal by charuto (I think it was charuto?) and 4) block size stuff. i was going to participate in breaking
**\<suraeNoether>** monero this week but I got caught up on the block size stuff, unfortunately... it appears to me like the problem with the blocksize debate boils down to this: we don't necessarily know what we want from our own dynamic blocksize adjustment methods
**\<suraeNoether>** we know some loose ideas about what we want, like adapting for rapid short-term growth that handles, for example, the holiday season, and we want block sizes to stay small unless it's needed
**\<suraeNoether>** but the details of what behavior is considered malicious and which should be adapted for ... these aren't totally clear to me. so i've been thinking about those things, too.
**\<suraeNoether>** oh, and 5) fees. i've been thinking about fee strucutre. but that ties in with 4).
**\<suraeNoether>** i just have not had time to get into the payment ID discussion :(
**\<knaccc>** timelines are really about politics more than tech
**\<sarang>** yes
**\<sarang>** and the timelines for applications and users of pIDs
**\<suraeNoether>** sarang: since pay\_id isn't necessarily a security issue, but they are so freaking annoying, where do you stand on timeline for deprecation?
**\<sarang>** Well, they can be a problem if not enforced
**\<sarang>** Most complete option is full deprecation of unenc/enc, which I support doing all at once
**\<sarang>** probably fall 2019
**\<sarang>** at the very least, remove unenc and enforce enc (to the extent possible) with wallet default
**\<suraeNoether>** okay, guys, i want to continue some of these discussions for sure, but let's call it for the official meeting time
**\<suraeNoether>** sarang, thank you
**\<sgp\_>** Should I re-write my post to say all payment IDs are disallowed in the Fall 2019 upgrade?
**\<sarang>** sgp\_: you were interested in learning who uses unenc, right?
**\<sarang>** To get a better sense of who needs to switch over and for what uses
**\<moneromooo>** Shapeshift does.
**\<knaccc>** thanks guys
**\<oneiric\_>** thanks all for the meeting

358
_posts/2019-01-14-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-01-14.md Normal file
View file

@ -0,0 +1,358 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2019-01-14
summary: Upgrade items, Research, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / sarang
---
# Logs
**\<sarang>** But, let's begin
**\<sarang>** The agenda, as linked above: http://paste.debian.net/hidden/4ae0abc9/
**\<sarang>** 1. GREETINGS
**\<sarang>** hello all
**\<ArticMine>** hi
**\<oneiric\_>** o/
**\<sarang>** We have much to talk about today
**\<sarang>** I'm going to move the Matrix item to 1.5. META
**\<sgp\_>** hello!
**\<suraeNoether>** howdy
**\<sarang>** charuto asked if we could do a deeper Matrix integration of this room
**\<suraeNoether>** what does it entail?
**\<suraeNoether>** i'm neutral on bridges generally
**\<sarang>** Right now AFAIK, the room is a portal in matrix, and the desire is for a plumbed room
**\<sarang>** https://github.com/matrix-org/matrix-appservice-irc/wiki/Permissioning-in-Portal-vs-Plumbed-rooms
**\<sarang>** This would have the side effect of allowing Matrix-side ops to exercise control over Matrix users in the room, but not on the freenode side
**\<suraeNoether>** i'm not really grokking the benefit
**\<sarang>** And be consistent with how other rooms (e.g. monero-community) are set up already on Matrix
**\<sarang>** charuto: are you present?
**\<charuto>** yeah, it would mostly not change anything IRC side, just here on this side, would allow for a more visible monero research lab matrix room and some matrix moderation options
**\<sarang>** charuto is already matrix-side op for other monero rooms
**\<sarang>** Provided we have another admin as well, I am not opposed to this
**\<sarang>** However, I'll request loose consensus from the room now before enabling
**\<serhack>** Hi everyone
**\<charuto>** and yes, sarang is correct, it's mostly for matrix-side consistency, so matrix users can simply join #monero-research-lab:matrix.org
**\<suraeNoether>** okay, so i'm not really following why this is fine
**\<suraeNoether>** charuto, no offense intended, please, but
**\<suraeNoether>** if someone comes to the matrix room and thinks you are in charge... \*shrug\*
**\<suraeNoether>** i don't see a benefit to this
**\<sarang>** I originally had similar concerns, but that's possible right now with the portal room
**\<suraeNoether>** i see this as an opportunity for someone to act as a middle man to interact with me, and that makes me nervous
**\<suraeNoether>** sarang: we can't stop someone from starting a portal room but we don't have to give them permission to plumb
**\<suraeNoether>** i literally mean no offense, charuto, i am sure you are running the rooms responsibly but
**\<suraeNoether>** i'm open to changing my view
**\<suraeNoether>** if someone can explain the benefits other than consistency
**\<charuto>** i understand your concern, suraeNoether , but the alternative would be people not even getting to the room
**\<suraeNoether>** i thought there was already a room
**\<suraeNoether>** that is a portal
**\<suraeNoether>** so
**\<sarang>** If this makes it easier to use on the matrix side, and introduces no new problems that don't potentially already exist, I am fine with it
**\<suraeNoether>** how does that work then
**\<charuto>** the portal room will remain, im trying to add a plumbed room
**\<charuto>** cant remove portal rooms
**\<suraeNoether>** then how is the alternative people not getting in?
**\<suraeNoether>** maybe i'm confused about how matrix works
**\<charuto>** some people dont know how portal rooms work and only join publicly listed matrix native rooms
**\<charuto>** on other monero channels, portal rooms always have less matrix users than plumbed rooms
**\<charuto>** it's the difference of joining #monero:matrix.org or joining #freenode\_#matrix.org
**\<charuto>** typo, #freenode\_#monero:matrix.org
**\<suraeNoether>** uhm
**\<sarang>** Given that suraeNoether is an op in this room, we won't proceed at this time if he objects
**\<suraeNoether>** so i guess my question is now reverting to a rude one: are people who can't figure out how to go to freenode.net and typing /join #monero-research-lab going to be helpful contributors in this room
**\<sarang>** This issue will be tabled until after the meeting, so we can move on and respect attendees' time
**\<suraeNoether>** k
**\<sarang>** On to 2. UPGRADE ITEMS
**\<sarang>** The block size algorithm has been discussed at length here and in -dev
**\<hyc>** (I think that's a fair question surae)
**\<sarang>** Loose consensus seems to be that the recommended approach, a dual median cap, is a reasonable stopgap that slows bloat, but it not a long-term solution
**\<sarang>** ArticMine: given your deep involvement in this, can you comment?
**\<sarang>** the proposal on the table is to cap the next block at min[ 1.4\*median(100), 50\*median(100000) ]
**\<sarang>** (others are welcome to comment as well)
**\<suraeNoether>** i'm happy to endorse this
**\<suraeNoether>** Isthmus may have thoughts on simulations, but he's always super busy
**\<sarang>** A lot of debate centered around this not being a long-term solution, and I agree
**\<ArticMine>** Yes I can comment on this.
**\<sarang>** What this does is stretch the time required by a lot
**\<sarang>** ty ArticMine
**\<ArticMine>** Fist both the original proposal that I made and smooth's latest proposal fail because they are using the entire block to scale the long term median
**\<sarang>** smooth's proposal being... ?
**\<ArticMine>** So either one has an exponential that scales based upon 50x my original proposal or the burst is lost
**\<ArticMine>** smooth's proposal is above in this thread I will try to find it
**\<ArticMine> \<smooth>** A=median of last 100 blocks
**\<ArticMine> \<smooth>** B=median of last 100000 blocks (arbitary number, might be changed)
**\<ArticMine> \<smooth>** maximum block size is min(max(A,300KB)\*1.4,max(B,15MB)\*1.2) (again both numbers could be changed)
**\<ArticMine> \<smooth>** existing method is max(A,300KB)\*2
**\<sarang>** Since code freeze is presumably drawing near, what is your endorsement ArticMine for what to include in the next fork (Boron)?
**\<ArticMine>** Right now I am working on a solution that addresses both of the above issues
**\<ArticMine>** Basically I does not use the whole block to scale the long term median
**\<ArticMine>** but only that part of the block that would have been legal using the long term median
**\<suraeNoether>** ArticMine: is there a serious flaw in using min[ 1.4\*median(100), 50\*median(100000) ] ?
**\<sarang>** A benefit of the current approach is that it seems not too large of a fundamental change to include as a stopgap until more complex approaches can be studied more deeply
**\<ArticMine>** the 50x factor is applied at the end
**\<suraeNoether>** like... if we spend another week trying to come up with a better method, is that a good usage of time for the possible benefit of using a different method?
**\<ArticMine>** Also we leave the current block scaling formual alone
**\<ArticMine>** and instead restrict that effective median block weight to put a rolling cap on it using the long term median
**\<suraeNoether>** ArticMine: maybe i'm not following you... what do you mean by using the entire block to scale the long term median?
**\<suraeNoether>** and what do you mean "only that part of the block that would have been legal"?
**\<ArticMine>** Let us say that the long term median only allows 400000 bytes for a block
**\<ArticMine>** But the short term median allows for 500000 bytes
**\<ArticMine>** The lock is legal under both proposals because of the 50x factor on the long term median
**\<ArticMine>** Block
**\<ArticMine>** Under both current proposals the whole 500000 bytes is used to scale the long term median
**\<ArticMine>** What I am saying is that we only use 400000 bytes in that example
**\<ArticMine>** This avoids the 50 factor in scaling the long term median that smooth was concerned about
**\<suraeNoether>** okay, i'm still a little confused, but let me ask a follow-uyp
**\<suraeNoether>** well its the same question i asked earlier: what is the problem with using min[ 1.4\*median(100), 50\*median(100000) ] ? I'm still not following.. :(
**\<sarang>** You still get exponential growth over time
**\<sarang>** it's just slowed way down
**\<suraeNoether>** okay, i understand that part
**\<ArticMine>** The problem is that we are incorporating the 50 facto in scaling the long term median
**\<suraeNoether>** ArticMine: can you get us a write-up of your suggestions some time in the next few days?
**\<suraeNoether>** something formal to look at? at least a formula or something
**\<sarang>** We will need to make a decision ASAP on what to do
**\<ArticMine>** That is the essence of smooth'ss concern
**\<ArticMine>** Yes
**\<sarang>** Right now, the only slow-growth proposal that at least has a formula and a simulated graph is the one suraeNoether mentioned above
**\<sarang>** so I will consider that the current "best option" for now until/unless we get the same detail before freeze
**\<sarang>** moneromooo: when should freeze be?
**\<ArticMine>** When is freeze
**\<sarang>** We'll move on and assume freeze is "as soon as possible, and perhaps sooner"
**\<suraeNoether>** my concern is this: the only way to prevent a literal exponential blowup is to put in some sort of hard cap
**\<ArticMine>** I has to be a rolling hard cap.
**\<sarang>** In the interest of time, on to payment IDs
**\<ArticMine>** Never a fixed hard cap
**\<moneromooo>** Unknown. Pony wanted to have a first build end of january.
**\<sarang>** sgp\_: you looked into usage of payment IDs by popular services
**\<sarang>** ok ty moneromooo
**\<sarang>** I advocate no changes to block cap that haven't been simulated
**\<sgp\_>** yes sarang, and it's about a 50-50 split between unencrypted and encrypted
**\<moneromooo>** If ArticMine need one more week to finish proving his idea, then I'm totally fine waiting for this.
**\<ArticMine>** That will work very well for me
**\<sarang>** Awesome, thanks ArticMine
**\<sarang>** sgp\_ and others had proposed candidate timelines
**\<sarang>** and received some feedback from wallets
**\<sarang>** Can you explain your findings sgp\_ ?
**\<sgp\_>** Sure. Here is where we are at right now:
**\<sgp\_>** https://usercontent.irccloud-cdn.com/file/k06P021t/image.png
**\<sgp\_>** Though after speaking with Justin from X Wallet, they seem interested in meeting the April timeline to remove the payment ID field when sending
**\<sarang>** endogenic (who runs mymonero) expressed general concern about the rationale for removing encrypted IDs, particularly citing UX
**\<sgp\_>** Cake Wallet says they will remove support once exchanges no longer use it
**\<sarang>** Based on these timelines, there is no consensus change until fall 2019 (Carbon fork)
**\<suraeNoether>** endogenic: can you elaborate on your concerns?
**\<sarang>** endogenic said he'd be unlikely to be available for this meeting
**\<selsta>** sgp\_: No soft depreciation in the GUI?
**\<dEBRUYNE>** In my opinion, the most important goal should be to remove the long unencrypted payment IDs
**\<sgp\_>** Let me explain the timeline a little bit more
**\<dEBRUYNE>** They are detrimental to UX. Also, I am personally kind of ambivalent on integrated addresses versus subaddresses
**\<sarang>** Those with -lounge history should look at those logs from earlier today to see his full remarks
**\<sgp\_>** As sarang stated, no consensus changes until Oct 2019 (Carbon), when all payment IDs (encrypted and unencrypted) will be disallowed
**\<dEBRUYNE>** Subaddresses are obviously better, but I am not sure how feasible it would be to get all exchanges and services to implement them
**\<sgp\_>** In April 2019, the official GUI will no longer support sending transactions with unencrypted payment IDs, and the official CLI will force users to use annoying flags to send
**\<suraeNoether>** hmmm, endogenic makes some interesting points about the memory requirements for subaddresses at exchanges
**\<suraeNoether>** namely: a big exchange will have to have huge hash tables
**\<selsta>** sgp\_: The GUI PR I did is similar to the CLI, requires enabling in settings. Why did you mark it as no support?
**\<endogenic>** mooo points out it wont be crazy.. 8mb for a million entries?
**\<endogenic>** (i'm half here, half not. busybusy)
**\<sgp\_>** selsta: I thought the plan was to remove entirely. I can make it look like the CLI if that's what we want
**\<moneromooo>** I looked, it's actually 32 bytes + 8 bytes, so 40 bytes payload. Plus the tree overhead.
**\<dEBRUYNE>** Removing them entirely in the next version is going to lead to loads of user issues
**\<sarang>** dEBRUYNE: them = what
**\<dEBRUYNE>** The option to use long payment IDs
**\<dEBRUYNE>** To add them to a transaction that is
**\<selsta>** sgp\_: https://github.com/monero-project/monero-gui/pull/1866 Disabled by default, can be reenabled in the settings.
**\<sgp\_>** Is this preferred? https://usercontent.irccloud-cdn.com/file/4g4NYw3q/image.png
**\<selsta>** IMO yes.
**\<sarang>** It at least provides consistency for our default products
**\<sarang>** If we let encrypted pIDs stick around, there remain distinguishability problems between those txns and those w/ subaddresses and no pID
**\<sarang>** these are mitigated somewhat by the use of a wallet-default encrypted value
**\<moneromooo>** Those will get a 8 byte payment id (if only two outs).
**\<sarang>** subaddress txns?
**\<moneromooo>** Yes.
**\<sarang>** with a default enc value
**\<sarang>** excellent; I thought that wasn't the case
**\<sarang>** Meaning the two choices there are: (1) ban all pIDs at Carbon fork; or (2) allow encrypted with a wallet default for \_only\_ 2-out txns at Carbon fork
**\<sarang>** Are there other options that I'm missing here?
**\<moneromooo>** "Carbon" is confusing.
**\<sgp\_>** Carbon is Oct 2019
**\<sarang>** fall fork; the element is carbon
**\<moneromooo>** Wait. Carbon has 12 protons doesn't it ? Already there ?
**\<sgp\_>** If exchanges and pools batch Monero transactions now with payment IDs, then they will need to change their behavior nevertheless
**\<sgp\_>** actually wait, they can't do that. disregard
**\<sarang>** If we are specifying a wallet default encrypted ID for subaddress transactions as well, I am less concerned about what happens if encrypted is permitted
**\<moneromooo>** Ah, 14 protons \*and\* neutrons. Shame on me.
**\<suraeNoether>** since we cant' enforce payids to be encrypted/can't verify that the payid has been encrypted, this new chart says to me "we aren't doing antyhing about this until october":
**\<sarang>** What we're doing is encouraging exchanges to move off unencrypted
**\<sarang>** and requiring it in October
**\<suraeNoether>** \*nod\*
**\<sgp\_>** I would much rather move totally to subaddresses to streamline this process. mandatory encrypted payment IDs seems really clunky to me
**\<sarang>** Deciding on the fate of encrypted is important, so they know what to code
**\<sarang>** it's not mandatory
**\<suraeNoether>** no sarang, it looks like in october we are even deprecating the encrypted payids
**\<sarang>** StupidWallet2.0 can always put 0
**\<sgp\_>** even default seems clunky to me
**\<sarang>** suraeNoether: according to sgp\_'s proposal yes, but we're discussing the consequences of what happens if encrypted is allowed to live
**\<sgp\_>** no one should use payment IDs when sending funds to subaddresses
**\<suraeNoether>** ah
**\<sarang>** No, but they're important for distinguishability
**\<moneromooo>** You can tell subaddress vs non subaddresses btw: additional tx pubkeys.
**\<sgp\_>** For Carbon, I'd much rather remove all payment IDs to solve the distinguishability issue
**\<moneromooo>** It's all a bit shitty isn't it.
**\<sgp\_>** \*mitigate to the same extent
**\<suraeNoether>** i agree with sgp. this makes me ask why we are even specifying the difference between encrypted vs. unencrypted, if the plan is to deprecate both by the october upgrade, and nothing about them is changing before october, and we can't enforce any shift away from unenc anyway
**\<sarang>** Yes moneromooo but it doesn't give away info in the case of, say, exchange true inputs
**\<suraeNoether>** moneromooo: lol
**\<suraeNoether>** moneromooo: i knew a guy with a tattoo that said "life is a big shit sandwich and every day is another bite"
**\<suraeNoether>** seems like a similar sentiment
**\<sarang>** suraeNoether: ignoring the chart, the question at hand is what to do about encrypted: keep around, or get rid of it in fall 2019
**\<sarang>** sgp\_ recommends nixing them in fall
**\<sgp\_>** yes
**\<sarang>** endogenic and dEBRUYNE suggest keeping them around
**\<sarang>** If we keep encrypted around, the wallet needs to always include dummy values
**\<dEBRUYNE>** Suggest might be a bit excessive
**\<sarang>** ok
**\<suraeNoether>** sarang: if we keep encrypted around we may as well not make any changes
**\<dEBRUYNE>** I am just skeptical of the feasibility of forcing all exchanges to upgrade to subaddresses
**\<suraeNoether>** because there's no way to enforce that they are encrypted
**\<moneromooo>** I'll probably just start warning about them when used, like I did for 256 bit ones earlier.
**\<suraeNoether>** dEBRUYNE: it's more feasible than asking everyone nicely to only encrypt their payids
**\<sgp\_>** I think that given the timeline, we should be abitious and encourage them to update
**\<sarang>** suraeNoether: no, but we are nixing long pIDs in fall
**\<dEBRUYNE>** I suppose it could work if some workgroup started contacting exchanges soon
**\<sgp\_>** This is ~9 months away
**\<dEBRUYNE>** That provides them almost 10 months to implement stuff
**\<sarang>** so the wallets will always encrypt whatever value the exchange tells them
**\<sarang>** It is true that we cannot enforce legitimate encryption over random values etc
**\<sarang>** So for the upcoming spring (Boron) upgrade, CLI/GUI \_will\_ permit sending with long pIDs with a flag and terrifying warnings of death
**\<sarang>** And we will have public notice that long pIDs will be consensus-denied in fall 2019
**\<sarang>** We \_should\_ produce a decision about encrypted at the same time, so services know what to expect and start developing for
**\<sarang>** But I am not seeing any firm agreement about the latter
**\<sgp\_>** I argue that we should write a post including the aggressive timeline. Luckily, if there is an implementation disaster, we can always walk back with nearly no effort
**\<suraeNoether>** fact of the matter is, either we want people using subaddresses, or not, and we certainly dont' want to keep adding mroe and more address types. usual address + unenc payid, usual address + enc payid, integrated address, subaddresses... especially since subaddresses are (1) efficient for users and (2) cover all the use cases, and since (3) we can't enforce the difference between the first three, but we can
**\<suraeNoether>** enforce subaddresses, the way forward to me is totally clear
**\<sarang>** moneromooo: why
**\<sarang>** because of daemon parsing?
**\<moneromooo>** Because it's always coming back.
**\<moneromooo>** Yes.
**\<sarang>** Is it more than parsing for size?
**\<moneromooo>** I don't understand that question.
**\<dEBRUYNE>** It has to parse tx\_extra afaik
**\<sarang>** We're already over time, and we still need to bring up another upgrade change: commitment amount/mask changes
**\<sarang>** Commitment masks will be generated deterministically and not included separately in the ECDH data, saving a bit of space
**\<sarang>** Amounts will be shrunk to 8 bytes and XORed with shared-secret-hash data
**\<sarang>** This is probably... less controversial than the other changes :/
**\<sarang>** Any questions/comments on it?
**\<sarang>** This was proposed by knaccc and talked about earlier here and in -dev
**\<sarang>** moneromooo has a branch for it
**\<suraeNoether>** yeah, sarang and i have considered it and we agree that this still provides the perfect hiding property of pedersen commitments, and commitments to amounts are as binding as they were before our proposed change
**\<suraeNoether>** it's a small space optimization. knaccc had the idea, right? or who came up with iut?
**\<sarang>** knaccc
**\<sarang>** it's simple and clever
**\<oneiric\_>** clever in a good way?
**\<sarang>** yes
**\<oneiric\_>** cool
**\<dEBRUYNE>** Just in general, do you feel it's the worth the (potential) risk? Imo the size savings are not that significant
**\<sarang>** Yes
**\<sarang>** It doesn't leak additional information that sender/receiver didn't already hold
**\<knaccc>** it's 56 bytes per output, but that's significant on a pruned transaction
**\<sarang>** OK, in the interest of time, very briefly on to 3. RESEARCH
**\<sarang>** There are now a few options on the table for refund addresses
**\<sarang>** knaccc proposed one that involves no consensus changes
**\<sarang>** another uses a non-interactive DLSAG approach but requires substantial overhaul to the plumbing with many subtleties, but could allow for payment channels etc.
**\<sarang>** and another was posted (link in the agenda)
**\<sarang>** just stuff to chew on, likely not before the upgrade IMO
**\<sarang>** since it requires a lot of wallet fun
**\<sarang>** moneromooo has been working on coinjoin-style fundamentals
**\<sarang>** I'll be writing up some bulletproofs mpc for that
**\<moneromooo>** thank you ^\_^
**\<sarang>** I posted a few papers of interest in the agenda
**\<suraeNoether>** ( still on the previous topic, but just a quick comment dEBRUYNE: the savings aren't that significant, but afaict, the security is concretely very similar (if not identical). It's a no-loss decision, in my mind )
**\<sarang>** Since we're over time, any very quick updates from others? Then we'll review action items
**\<suraeNoether>** sarang, are your comments on the matching paper complete? was our conversation last week all your thoughts or am i waiting on more notes from you?
**\<dEBRUYNE>** I am just warry of the change somehow being exploited later on
**\<moneromooo>** One question about refund addresses: only one of those proposals helps with payment channels ?
**\<sarang>** I am nearly complete, was derailed by an unrelated topic
**\<dEBRUYNE>** Does it necessarily matter we're over time btw? I don't mind continuing :p
**\<sarang>** for non-interactive use
**\<suraeNoether>** i started a "linear techniques in applied cryptography" document to keep my notes on Ruffing's scheme, Schnorr signatures, Bulletproofs, and Bootle's polynomial commitments all in one neat and tidy place. i may tweak it over the next year in little ways with the long term goal of writing a book
**\<sarang>** We don't have a concrete proposal for integrating knaccc's or Ilya's schemes into a payment channel system safely
**\<suraeNoether>** moneromooo: DLSAG is good for payment channels... cryptonote++ or ilya's paper... i believe that is non-channel based refund addresses
**\<sarang>** DLSAG ensures you can properly track spends
**\<sarang>** hence the tomfuckery with key images and signature style
**\<sarang>** So for the sake of sanity, here are the action items that are time-sensitive:
**\<sarang>** (a) block size cap algorithm: we need a method that has been simulated in time for freeze
**\<sarang>** (b) payment ID timeline: we need to know the fate of each address type to make a unified statement for services to use for planning
**\<sarang>** (c) any objections to the ECDH data change are at the "speak now" phase
**\<sarang>** Non-sensitive items:
**\<sarang>** (d) we can talk after the meeting about the Matrix room integration
**\<sarang>** (e) the MRL-0011 paper will be released to this group when I get my reviewing ass in gear again
**\<sarang>** (f) refund address options should be investigated more thoroughly to decide what route(s) to take
**\<sarang>** That's all I wanted to get through. We can open the floor now to continuation of anything and everything
**\<sarang>** Sorry for being a hardass on time today; wanted to make sure we hit everything
**\<suraeNoether>** in order to address (c), we should write up a formal technical note on (i) how amount commitments are currently computed, (ii) our proposal for the new computation and (iii) proofs of equal security in terms of hiding and binding properties\\
**\<suraeNoether>** and i can work with knaccc on that this week
**\<knaccc>** Not sure if MRL is the right place for this, bu re: the embedded Java-I2P router idea, I've almost finished it. Just need to test my scripts a bit more. Available here: https://github.com/knaccc/embedded-i2p-java-router-with-sam
**\<sarang>** OK, have you seen the branch moneromooo has already?
**\<sarang>** it's in code
**\<moneromooo>** 5052
**\<suraeNoether>** oh man
**\<suraeNoether>** i'll check that out
**\<suraeNoether>** thanks moneromooo
**\<sarang>** I know moneromooo and knaccc and I have looked it over
**\<suraeNoether>** yeah, and i recall writing up a proof of the idea and satisfying myself about it, but that was on paper
**\<suraeNoether>** which branch?
**\<sarang>** rctb
**\<sarang>** https://github.com/moneromooo-monero/bitmonero/tree/rctb
**\<oneiric\_>** knaccc: cool work on the java-i2p embedded router
**\<zlatinb>** knaccc: let me know if you need any help with the java embedding
**\<suraeNoether>** found it right after i asked :P thanks sarang
**\<knaccc>** oneiric\_ zlatinb thanks, any comments or suggestions welcome
**\<moneromooo>** Are you adding i2p/monero connectivity ?
**\<oneiric\_>** do you know if there are any hardening flags available for jlink?
**\<knaccc>** not sure what you mean by hardening
**\<oneiric\_>** aslr pie stuff like that
**\<knaccc>** i don't think those things apply to Java
**\<oneiric\_>** no?
**\<knaccc>** that's kinda the point of Java
**\<knaccc>** buffer overflows etc are impossible
**\<knaccc>** even if you're brain dead
**\<oneiric\_>** hrm, the jvm is still in c tho no?
**\<zlatinb>** C++
**\<knaccc>** oh the jvm itself is hardened over 2.5 decades by Sun/Oracle, in theory
**\<knaccc>** there are no user flags i'm aware of for hardening it further, but i'll check
**\<zlatinb>** jlink doesn’t really “link” anything in the sense of C/C++ linking
**\<knaccc>** correct
**\<knaccc>** it's static linking of java stuff
**\<oneiric\_>** so, in java dev, there is no sense of hardening outside of writing good code?
**\<zlatinb>** not really
**\<suraeNoether>** OH GUYS I HAD AN ANNOUNCEMENT
**\<suraeNoether>** as some of you know, Sarang and I have started a non-profit together called MAGIC - Multidisciplinary Academic Grants in Cryptocurrencies
**\<suraeNoether>** and we are opening up our scholarship program this month!
**\<oneiric\_>** congrats!
**\<suraeNoether>** we are giving out 5 $1000 USD scholarships for this fall, and we are giving out 2 $3000 USD research grants in the upcoming spring
**\<dEBRUYNE>** moneromooo: I think that's the intention
**\<knaccc>** congrats surae
**\<suraeNoether>** so, by the end of this month, our application will be available on https://magicgrants.org for anyone registered at an accredited school in the US, South Africa, or the EU or EFTA nations or micronations within the EU or EU-eligible nations.
**\<suraeNoether>** all this is made possible by a single anonymous donor so far
**\<suraeNoether>** i know the market has screwed all of us essentially, but if anyone wants to give, there are donation links both through globee for crypto and stripe for fiat on that webpage
**\<knaccc>** very cool suraeNoether!
**\<suraeNoether>** thanks knaccc!
**\<suraeNoether>** hopefully by 2022 we can start building primary schools all over the world libraries and computer labs
**\<suraeNoether>** well, in the listed nations for now. :P
**\<sarang>** Side update: suraeNoether is fine with the Matrix plumbed room, as am I. Unless there are objections now (this was mentioned earlier to other room ops, with no reply) we'll go ahead and allow it
**\<suraeNoether>** ah yeah i removed my objection because i realized we can always undo the decision later. :P
**\<suraeNoether>** and i don't think charuto is a personel risk, although having a second mod would be keen
**\<sarang>** Block cap algo is in ArticMine's court for now, with the current proposed dual-median in the wings
**\<sarang>** Payment ID timeline is still annoyingly up in the air
**\<sarang>** If anything, we should figure that damn thing out
**\<knaccc>** moneromooo just in case it's not clear, I don't know a thing about the C side of things, e.g. how to add libsam3 to the Monero C code in order to talk to the embedded i2p router via the SAM protocol. But I am able to figure out how to produce an embedded JVM/I2P binary that can be bundled with zero installation and zero dependencies
**\<moneromooo>** OK.
**\<suraeNoether>** do we have an issue on github yet re: replacing pay\_id with subaddresses?
**\<suraeNoether>** it'd be helpful to have some coherent arguments laid out in all the different directions
**\<suraeNoether>** also does anyone have thoughts on this: https://github.com/monero-project/research-lab/issues/46
**\<sarang>** That was brought up on reddit earlier, presumably by the same person
**\<moneromooo>** When I see a post that has "it's going to be brushed off", I want to brush it off just because it said that. OTOH, a game theoretic analysis of this would be very nice, if possible.
**\<sarang>** Yeah, I said that person is free to do it or put it out there for someone else to do, either volunteer or for FFS donations
**\<moneromooo>** s/possible/not made up of mostly unknowable factors/
**\<sarang>** ArticMine has brought up his views on supply but AFAIK they are not really documented anywhere
**\<sarang>** and they should be

211
_posts/2019-01-21-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-01-21.md Normal file
View file

@ -0,0 +1,211 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2019-01-21
summary: Ongoing work, New work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<sarang>** FYI meeting begins shortly
**\<sarang>** Current agenda: https://github.com/monero-project/meta/issues/301
**\<sarang>** Shall we begin?
**\<suraeNoether>** sure
**\<sarang>** Greetings, everyone
**\<suraeNoether>** letsdothis.gif
**\<oneiric\_>** o/
**\<sarang>** I dislike mass pings, but given certain topics, a special ping to sgp\_ ArticMine moneromooo knaccc
**\<sarang>** First, ONGOING WORK
**\<ArticMine>** Hi
**\<sarang>** Much discussion about payment ID deprecation has occurred
**\<sarang>** sgp\_ is holding an open meeting to discuss this, on 25 January: https://github.com/monero-project/meta/issues/299
**\<sarang>** THe current proposal intends to discuss is a deprecation of unencrypted pIDs at next upgrade, followed by a ban on all payment IDs in fall
**\<sarang>** The main source of contention at this point seems to be whether keeping encrypted pIDs around, whether or not the wallet supports them by default, is necessary or desired
**\<sarang>** Unless there's something important to talk about regarding this, and its relationship to the upcoming fork, we can table it until sgp\_'s meeting
**\<suraeNoether>** i think it's wise to table the discussion until the meeting
**\<sarang>** moneromooo has been working on wallet handling of payment IDs, as well as the use of default payment IDs for transaction indistinguishability
**\<sarang>** ok!
**\<sarang>** Next is block size scaling
**\<sarang>** ArticMine recently posted a new proposal \\
**\<sarang>** So the two on the table right now are the dual-median option (presented last time) and ArticMine's new one
**\<ArticMine>** I can go over the details and answer questions
**\<sarang>** ty ArticMine
**\<sarang>** Here is the paste on this idea, linked earlier: http://paste.debian.net/hidden/50f142a6/
**\<lurkinandlearnin>** To confirm, the old proposal is this? https://github.com/noncesense-research-lab/Blockchain\_big\_bang/blob/master/models/Isthmus\_Bx\_big\_bang\_model.ipynb
**\<ArticMine>** The key part of my proposal is to separate the block weight into a long term portion LongTermBlockWeight and the balance
**\<ArticMine>** LongTermBlockWeight - BlockWeight
**\<sarang>** lurkinandlearnin: look at notebook line [3]
**\<ArticMine>** LongTermBlockWeight does not include the burst potion that can go up to 50x
**\<ArticMine>** So the LongTermMedianBlockWeight does not compound at 50x
**\<suraeNoether>** fwiw for the folks in the audience: one of the reasons block size based on medians is a difficult question is the way medians behave...
**\<suraeNoether>** most equations that have been proposed here introduce an effective time delay between how max block size is responding to previous block sizes... and it's a difference equation... and introducing time delay to difference equations can introduce very strange behavior like chaos. (example: https://advancesindifferenceequations.springeropen.com/articles/10.1186/s13662-015-0374-1 )
**\<suraeNoether>** chaos is bad
**\<suraeNoether>** so most of these proposals are most easily analyzed with simulations, which provide no guarantee that things won't go crazy. i've been looking into mean-based appraoches instead of median-based approaches; this introduces the possibility that outliers become disproportionately important, but it removes chaos from the equations, so we may be able to design a globally stable approach.
**\<suraeNoether>** in addition to evaluating articmine's proposal
**\<ArticMine>** This is the key difference with the prior proposal that compounds the LongTermMedianBlockWeight using the entire block
**\<ArticMine>** the
**\<sarang>** Including the simple two-median approach, right ArticMine ?
**\<ArticMine>** Yes the simple two median approach fails
**\<suraeNoether>** i'm still not clear on the properties we want out of max block size adjustments
**\<ArticMine>** Since it either compounds the 50x burst (my initial version) or kills the burst over time (smooth's version)
**\<sarang>** ArticMine: is that paste complete as written?
**\<suraeNoether>** beyond "ability to go 50x over a slow day to accommodate a christmas day, and to not allow a big bang"
**\<ArticMine>** Yes
**\<sarang>** Isthmus and I plan to work this in to our existing simulations
**\<sarang>** His is more complete, but I am doing one for my own education and as a separate check
**\<sarang>** We shall need to make a decision by freeze time
**\<sarang>** ArticMine: there are a few subtleties that I'll want to ask you about later
**\<sarang>** But I also would like to hear the answer to suraeNoether's question
**\<nioc>** I did not see any response to smooth's comment.....
**\<nioc>** you can avoid any sort of consensus issues on \*1.4 by making it 1.375 which is adding 3/8
**\<nioc>** 10:50 PM or some such, but that should be close enough
**\<nioc>** 10:56 PM overall looks good to me at first reading
**\<nioc>** 11:02 PM i guess 4/10 is fine too, just slower (but not significant)
**\<sarang>** that was a rounding issue, I suppose
**\<moneromooo>** If people will fuck up with 1.4, they will fuck up with 1.375.
**\<moneromooo>** For interested people, the amp branch has ArticMine's change (untested).
**\<suraeNoether>** we should just pick a number that can be represented exactly in a computer
**\<moneromooo>** (just the top patch)
**\<moneromooo>** Better to pick one that can't. You don't want people to use floating point and think they did it right bevause the number was chosen to make things look right.
**\<sarang>** branch link: https://github.com/moneromooo-monero/bitmonero/commit/f1ee51c55963d05a78db916d41da7dc5948bb05a
**\<suraeNoether>** representing 1.4 in a computer is inexact and will cause floating point rounding problems in different pieces of software, but i think 1.375 can be represented in binary exactly and so there is no roundoff problem in that regard...
**\<sarang>** also, hot dang that was fast moneromooo
**\<suraeNoether>** one of the things i, personally, would like out of the block size adjustment is this
**\<ArticMine>** smooth's comment would e an improvement if the BlockWeight were a factor of 8 in bytes, but it is not. So in reality it is not a material change
**\<suraeNoether>** moneromooo: that's a strong argument actually
**\<suraeNoether>** so, i think block size adjustment can benefit from: forcing the marginal cost of adding an additional transaction in terms of block reward penalty to be greater than the standard fees gained by including that transaction
**\<suraeNoether>** even if we pick some exotic max\_block\_size calculation, we should also be changing the block reward penalty this way
**\<ArticMine>** Still I see as an improvement. As per suraeNoether comment above. So we can make the change from 1.4 to 1.375
**\<suraeNoether>** of course, if the block is nearly full and the block reward is almost zero, adding almost any transaction fees will make up for it
**\<suraeNoether>** ArticMine: moneromooo just made a strong argument \*against\* that
**\<suraeNoether>** so this marginal cost approach will be most effective when block sizes are nowhere near the big bang levels
**\<suraeNoether>** which is good: providing an incentive to stay reasonable when they are already reasonable
**\<ArticMine>** No When block weight is close to big bang levels LongTermBlockWeight is << BlockWeight
**\<suraeNoether>** i'm not talking about your block size proposal; i'm talking about block reward penalty as a function of block size
**\<lurkinandlearnin>** Has any thought been given towards an incentive for miners to create smaller blocks when transaction volume is low? To slow blockchain growth
**\<suraeNoether>** that's what i was just talking about lurkinandlearnin
**\<pigeons>** lower blockchain growth is probably less important than quicker validation and propogation but the same point applies
**\<sarang>** lurkinandlearnin: all txns get added eventually if the fee market allows
**\<suraeNoether>** something isthmus brought up to me: there are only about 150,000 blocks between us and the next hard fork. with the \*simple\* two-median method will forbid a blowup before the next hard fork.
**\<suraeNoether>** woops i mean between March and October hard forks
**\<moneromooo>** Yes, starting the penalty before 100% (idea from smooth).
**\<suraeNoether>** we should consider implementing the simple method \*first\* and spending time thinking about a more optimal solution, rather than trying to go for broke
**\<lurkinandlearnin>** moneromooo: that sounds like a great idea
**\<suraeNoether>** moneromooo: yep, smooth had the initial idea of sub-100%-median block penalty; my idea is to make the drop-off nonlinear so that it's more expensive to push block sizes larger in the absence of a healthy fee market
**\<sarang>** Well, simulations will shortly be done for ArticMine's proposal compared to the current approach and the simple two-median
**\<sarang>** Presumably the next upgrade will do one of the two options
**\<suraeNoether>** okay, i don't think we're going to come to any conclusions on this, but it's been a good update
**\<suraeNoether>** let's move past scaling
**\<sarang>** Sure thing. We'll talk after simulation data are available
**\<sarang>** Next is transaction size reduction, for which there is a PR from moneromooo
**\<sarang>** AFAIK there are no new updates on this otherwise
**\<sarang>** unless moneromooo you wish to say anything about it?
**\<moneromooo>** I'd just like one of you Noethers to review the code before it goes in.
**\<moneromooo>** suraeNoether said he'd have a look.
**\<suraeNoether>** sarang let's do that \*together\* tomorrow morning? we can do it over a vidchat since we were going to meet tomorrow anyway
**\<sarang>** Roger; the math looked correct to me, but I may have neglected to add a comment
**\<sarang>** ok suraeNoether can do
**\<suraeNoether>** fun
**\<suraeNoether>** as for the semi-final point on the agenda... what's the deal with bulletproofs, anyway? seinfeld.gif
**\<sarang>** lol
**\<suraeNoether>** DID YOU GUYS MAKE THINGS FASTER AGAIN
**\<sarang>** Only a brief update that some BP verifier optimizations didn't make it into the 0.13 release
**\<sarang>** a very unscientific test on my box resulted in a 64-batch of 2-proofs verifying 60% faster
**\<sarang>** kudos to moneromooo for continuing to squeeze speed out of those suckers
**\<lurkinandlearnin>** holy smokes
**\<lurkinandlearnin>** 60% faster than current impl or than pre-BP?
**\<sarang>** than the 0.13 release code
**\<suraeNoether>** jeez
**\<sarang>** that is, 0.13 vs master
**\<sarang>** as of a few days ago
**\<suraeNoether>** where did this speedup come from?
**\<sarang>** Folding in some multiexponentiation operations, as well a host of other voodoo moneromooo can dooo
**\<sarang>** So we can brag about the next release making txns smaller and faster again :D
**\<moneromooo>** I did not keep track of which change sped up by how much. I think sarang's single multiexp change is probably the biggest one though.
**\<sarang>** Let's now discuss NEW WORK
**\<suraeNoether>** cool!
**\<sarang>** suraeNoether: your personal updates?
**\<suraeNoether>** personally, this past week was largely a konferenco administration week for me, contacting speakers and vendors and getting my bank compliant with me
**\<suraeNoether>** i did research on bulletproofs, linear algebra in cryptography, and our matching paper
**\<sarang>** I'm sooper excited for this conference
**\<suraeNoether>** but a lot of my work this week was contacting possible speakers
**\<sarang>** sounds like we'll have some big names joining us
**\<suraeNoether>** yes, it's pretty great so far; we are adding more names this week
**\<sarang>** Any updates on the matching paper suraeNoether ?
**\<suraeNoether>** my simulations aren't passing unit tests
**\<suraeNoether>** once they do, i'm making a commit
**\<suraeNoether>** and then collecting data
**\<suraeNoether>** so: it's moving forward
**\<sarang>** excellent
**\<sarang>** Any questions for suraeNoether ?
**\<sarang>** OK, I'll go next
**\<suraeNoether>** oh i had one more thing to bring up
**\<suraeNoether>** sorry sarang, i don't want to interrupt
**\<sarang>** np go ahead
**\<lurkinandlearnin>** is there a list of speakers for the conference?
**\<suraeNoether>** i found all those old Monero Protocol Standards documents I started writing last year, and I'm wondering if folks still want me to compose the v0.1 versions of these rather short text documents into something to put up on our github
**\<lurkinandlearnin>** or not official yet?
**\<suraeNoether>** lurkinandlearnin: check out konferenco.xyz
**\<suraeNoether>** the benefit of having the standards instead of a single big zero-to-monero document is this:
**\<suraeNoether>** we can update each one piecemeal and only update it if something has changed. this reduces overhead work on documentation. and if it's on github, anyone can update them, we don't have to go find kurt magnus or koe
**\<sarang>** FWIW the ZtM doc is on github and can be PRed
**\<sarang>** but I see the point about modularity
**\<sarang>** My pessimistic side worries that updates would fall behind, as they already have on ZtM
**\<lurkinandlearnin>** What aspects of the protocol are covered? Could be something useful to incorporate into the often neglected wiki
**\<lurkinandlearnin>** as they both sound modular
**\<suraeNoether>** lurkinandlearnin: essentially similar to the cryptonote standards they released after i reviewed their whitepaper years ago, like this: https://cryptonote.org/cns/cns006.txt
**\<suraeNoether>** (my whitepaper review would have been moderately better if they wrote those standards before the whitepaper, but hey)
**\<suraeNoether>** sarang your points are valid
**\<suraeNoether>** which is why i'm not sure if it's a good idea to devote time to it
**\<Isthmus>** Wiki is a good idea, specs are a good idea. Having experience as a book editor, people making random PRs is a huge nightmare to text style and continuity and often took 4x as long to polish then if SerHack and I had written ourselves.
**\<suraeNoether>** okay, how about this
**\<sarang>** Whatever is made available, whether ZtM or wiki or standards, keeping up to date is the most important aspect IMO
**\<sarang>** I cringe at "text-rendered math" though...
**\<Isthmus>** Maybe we should pick one to be the "reference" documentation and the others follow suite?
**\<sarang>** Who's responsible for maintenance of each one?
**\<lurkinandlearnin>** Well as long as the version at time of writing is very clear keeping it updated is not so critical
**\<suraeNoether>** sarang who's responsbile for maintaining anything around here?
**\<sarang>** lurkinandlearnin: I disagree
**\<suraeNoether>** how about i just post what i have after making it a little more readable, and if someone wants to run with it they can
**\<lurkinandlearnin>** nice, but not disastrous. If anything having info about how things used to work out there is also useful.
**\<suraeNoether>** i can post it on my personal github to avoid cluttering the primary\\
**\<sarang>** suraeNoether: I think that'd be useful, to get a better sense of scope of audience
**\<suraeNoether>** sarang: we can always label them clearly DEPRECATED AND NOT USEFUL. but i think it'd be better to have them out there
**\<sarang>** good point
**\<suraeNoether>** okay handing it back to sarang
**\<sarang>** As long as it's clear what can be considered "closer to canonical"
**\<sarang>** So I've had some testing and minor optimizations to BPs for the next release, as mentioned earlier
**\<sarang>** Minor work on simulating block size changes to confirm work by Isthmus on scaling etc.
**\<sarang>** Recording of new Breaking Monero episodes with sgp\_
**\<sarang>** The usual new lit and project review
**\<sarang>** and some work on a safe MPC protocol for Bulletproofs for future use
**\<sarang>** as well as a lot of back-and-forth administrivia on the topics for the Boron upgrade
**\<sarang>** I am personally in favor of either Boron Betelgeuse or Boron Bellatrix
**\<sarang>** (as far as names go)
**\<sarang>** and of course the math for graph matchings, which has been passed back to suraeNoether for simulation data that he is obtaining
**\<lurkinandlearnin>** Betelgeuse will lead to a schism in the community over pronounciation
**\<sarang>** precisely
**\<sarang>** It's like the naming of iPhone X... by making it hard to get right, it forces you to think it's better than you are
**\<sarang>** humbles us all
**\<lurkinandlearnin>** "It gets the people going!"
**\<sarang>** Any questions for me?
**\<lurkinandlearnin>** what's the next breaking monero topic?
**\<moneromooo>** Hmm... Lightning network things ?
**\<sarang>** moneromooo: what questions on that?
**\<Isthmus>** "Boron borealis" ?? I think there's a Harry Potter character called Bellatrix, which could get confusing with all the HP-themed MimbleWimble names.
**\<sarang>** lurkinandlearnin: we have several topics in the lineup, to be arranged
**\<Isthmus>** Also, Breaking Monero = awesome, thanks for all the time going into that series :- D
**\<moneromooo>** Was anything done or thought about recently about anything monero needs for LN or LN style system ?
**\<sarang>** moneromooo: some of it was an efficient and fungible way to handle protocol aborts, a la noninteractive refunds
**\<sarang>** that was quietly tabled as several proposals for interactive refunds were thrown around
**\<moneromooo>** Ah yes. It would be nice to see a list of things that are needed in monero as building blocks. In terms of parenthesized AND/OR. I always forget. Or never knew.
**\<sarang>** That's a good point. Having a well-considered status update will be useful for longer-term planning
**\<sarang>** Does anyone else have updates to share, before we adjourn?
**\<sarang>** righto
**\<sarang>** Thanks to everyone for joining
**\<sarang>** Our current action items:
**\<sarang>** (a) simulation data for block size proposals, to make a decision before freeze
**\<sarang>** (b) final review of transaction size reduction PR
**\<sarang>** (c) meeting to decide on payment ID deprecation (PLEASE attend or comment on github issue if you have an opinion on this, with justification/data)
**\<sarang>** at ease, soldiers

311
_posts/2019-01-28-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-01-28.md Normal file
View file

@ -0,0 +1,311 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2019-01-28
summary: Ongoing work, MRL going to SBC, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / surae
---
# Logs
**\<suraeNoether>** allrighty, well, it's 17 UTC
**\<serhack>** Hi!
**\<suraeNoether>** howdy everyone
**\<ardyfy>** HI
**\<oneiric\_>** ohiyo
**\<Xeagu>** Hey
**\<learninandlurkin>** Salutations
**\<ArticMine>** hi
**\<suraeNoether>** today, our agenda is here: https://github.com/monero-project/meta/issues/302
**\<Mochi101>** woohoo!
**\<suraeNoether>** allrighty, so let's begin with payment ID deprecation
**\<Mochi101>** Very sad.
**\<suraeNoether>** my understanding is that some folks are opposed to the proposed timeline for switching over to subaddresses
**\<Mochi101>** Don't you guys think that such drastic changes hurts Monero adoption?
**\<Xeagu>** It is new information to me that this was not already default
**\<xiphon>** Mochi101: payment id is actually what "hurts Monero adoption"
**\<xiphon>** ^ standalone one
**\<suraeNoether>** mochi101 what drastic change are you referring to? deprecating payment IDs? or enforcing subaddresses?
**\<Mochi101>** Both actually.
**\<learninandlurkin>** Drastic changes is what Monero is all about. 6 month forks and whatnot.
**\<ArticMine>** I am in favor of this, the only possible issue I see is timing on which I am neutral
**\<suraeNoether>** in my opinion, switching to a system with fewer moving parts with fewer ways for users or wallet developers to accidentally screw up, this is a net win for monero users, the ecosystem in general.
**\<gingeropolous>** ^^
**\<Mochi101>** Yes, Monero feels like a really high maintenance, needy girlfriend sometimes.
**\<suraeNoether>** i don't know about you, but "idiot proof" cryptography is sort of a myth, but it'd be really really great if we could take incremental steps toward systems with fewer complications glued on top just to make it work
**\<Xeagu>** In the unknown future, will Monero no longer require network upgrades every 6 months?
**\<suraeNoether>** xeagu i believe we are intending on keeping 6 month network upgrade schedules for the foreseeable future, with the intention of \*eventually\* slowing them down
**\<suraeNoether>** i don't know what timescale "eventually" means here, practically, though. fluffypony has mentioned it before but I don't recall the timescale
**\<Xeagu>** Do you think a timeline would help those with concerns about that activity hurting adoption?
**\<learninandlurkin>** The unknown future is unknown
**\<silur>** I aggree that in the anctient security vs UX war we need to stick with security
**\<silur>** and moving/changing parts is a golden rule in crypto
**\<silur>** even if it's more surface for users to screw up
**\<suraeNoether>** ArticMine: thank you for supporting the change. i'm with you on both timeline and supporting the upgrade. i'm asking if anyone here has specific timeline objections they want to bring up; last I recall, sgp\_ had a great chart, but perhaps the discussions have changed a bit since then?
**\<dEBRUYNE>** UX issues stemming from payment IDs are predominantly caused by the long, unencrypted payment IDs. Thus, imo, it's imperative that we remove those
**\<suraeNoether>** ^^
**\<Mochi101>** As far as I know there's not even any real documentation on subaddress generation, identifying the last index which has been used, etc.
**\<Mochi101>** That's pretty bad when you're going to force it.
**\<sgp\_>** Mochi101: https://github.com/monero-project/meta/issues/299
**\<sgp\_>** lots of details there, including a basic upgrade guide for services
**\<suraeNoether>** thanks for the link to the previous PayID discussion, sgp\_ ! i am bookmarking that rn
**\<sgp\_>** services have nearly half a year to upgrade, which is reasonable given the requirements. We have spoken to exchanges and payment processor services who think the timeline is aggressive but realistic
**\<sgp\_>** Mochi101: the logs for the meeting are also available at the same link
**\<suraeNoether>** sgp\_: cool! personally, I think this is a win for monero users in terms of privacy, a win for developers in terms of elegance, and a win for the ecosystem in terms of efficiency
**\<sgp\_>** I recommend you read them
**\<Xeagu>** I admit I don't understand how subaddresses work
**\<suraeNoether>** I don't want to speak for sarang; perhaps when he gets back he can jump in and provide an opinion.
**\<Xeagu>** There is a need in the market for distributed education
**\<suraeNoether>** Xeagu: the main idea is you take your wallet address (A,B) and you generate a family of addresses deterministically all sharing the same view key, and allowing you to mass-scan all the subaddresses simultaneously for incoming transactions
**\<suraeNoether>** it's a little more complciated than that because they don't \*actually\* share a view key
**\<Mochi101>** Thanks. But you're only seeing this from your "in the loop" perspective. I looked for information about this and couldn't find any in the places that I expected them to be. Really people using Monero should not have to search through GitHub to find this stuff. If it's a major issue like this it should be front and center on something like getmonero.org
**\<suraeNoether>** but they can all be \*scanned\* with a single view key
**\<Xeagu>** Yes I am confused on the order that subaddresses are selected during generation
**\<Xeagu>** If they are deterministic, no?
**\<gingeropolous>** is there anything research-y about payment IDs / encrypted / subaddresses at this point? I mean, its pretty solid that anything except subaddresses is sub-optimal, right?
**\<suraeNoether>** you use deterministic nonces while hashing, so they appear random but always come up to be the same
**\<sgp\_>** Xeagu: read this: https://medium.com/@anhdres/how-moneros-accounts-and-subaddresses-work-in-monerujo-4fa7df0a58e4
**\<selsta>** Mochi101: You should subscribe to the newsletter.
**\<dEBRUYNE>** Mochi101: It was announced on the mailing list
**\<sgp\_>** Yes, please join that. It's essential for staying up-to-date
**\<Xeagu>** Alright so basically I need to read through Mastering Monero again
**\<suraeNoether>** gingeropolous: yeah. this is a question (subaddresses) about key infrastructures. not really in doubt that subaddresses are objectively superior in terms of engineering and in terms of simplicity. keeping around old systems for no good reason is not going to help adoption.
**\<suraeNoether>** also as far as I understand it, the MRL contributors sgp and knaccc are both working on documentation
**\<gingeropolous>** right. it just seems at this point we gotta bite the bullet and go through the suck.
**\<suraeNoether>** we can continue this conversation after the meeting
**\<Xeagu>** Subaddresses mean you only really need to memorize a single wallet seed, as I understand it.
**\<sgp\_>** yes Xeagu, and best to table this discussion imo
**\<Xeagu>** Let's move on
**\<suraeNoether>** let's move along to the oh-so-contentious block size scaling discussion
**\<suraeNoether>** articmine is currently validating some cost analyses by sarang
**\<OWLisFLOWN>** Sup n00bs
**\<suraeNoether>** i whipped up two ideas, one wacky and one not for block size debate, and i'll be contributing these two ideas to the mix to see about how it all fits together
**\<suraeNoether>** in terms of cost analyses
**\<Xeagu>** What are the two ideas?
**\<ArticMine>** I presented my overall proposal
**\<suraeNoether>** my first idea is a simple low-pass filter, and my complicated idea is inspired by some discontinuous reset models from neuroscience, which sounds fancy, but is in no way "modeling brains on the blockchain" or anything like that, please do not run away with my words
**\<suraeNoether>** ArticMine: yeah, i thought you and sarang were working together to make sure cost analyses were apples-to-apples comparisons?
**\<ArticMine>** https://paste.debian.net/hidden/556a3a8a/
**\<suraeNoether>** aha!
**\<suraeNoether>** thanks articmine
**\<suraeNoether>** that's articmine's proposal
**\<Xeagu>** Interesting okay. Can you explain the low-pass filter? I'd like to discuss the brains on the blockchain idea later.
**\<ArticMine>** There was one addition: We can use LongTermBlockWeight as opposed to BlockWeight in the fee calculation
**\<suraeNoether>** xeagu essentially all our proposals revolve around discrete-time dynamical systems, including my discontinuous reset idea. so "how to update next\_max\_block\_size as a function of previous block sizes... so that the blockchain doesn't get caught in a feedback loop and blow up for a determined and moderately wealthy attacker?"
**\<Xeagu>** This is trying to determine future dynamic block size scaling?
**\<suraeNoether>** yep.
**\<silur>** wait
**\<silur>** I have a paper on this issue
**\<suraeNoether>** great!
**\<suraeNoether>** please link!
**\<silur>** it's originally for PoS
**\<silur>** but does address the problem
**\<suraeNoether>** i believe articmine's approach is good in the sense that it forces an attacker attempting to force bloat to drag out an attack over a long timescale in order to have a decent influence, which costs more and more money.
**\<silur>** of keeping this wealth blowup in check
**\<silur>** https://arxiv.org/abs/1809.07468v2
**\<suraeNoether>** interesting, thank you. i believe someone had an idea where miners vote on the max block size for the next N blocks using proof of work, but i haven't looked further into it yet
**\<suraeNoether>** wb sarang
**\<Xeagu>** I am not familiar with ArticMines proposal
**\<suraeNoether>** xeagu he linked it a moment ago, and sarang has been running simulations and comparing costs
**\<silur>** this one has a formula for how to calculate the next reward based on the current parameters
**\<silur>** maybe we can generalize it for blocksize?
**\<Xeagu>** I need it in ELI5 terms
**\<ArticMine>** interesting, thank you. i believe someone had an idea where miners vote on the max block size for the next N blocks using proof of work, but i haven't looked further into it yet] <--- This is one of many failed Bitcoin proposals
**\<moneromooo>** As long as we finalize ArticMine's proposal soon, before the fancy new stuff gets worked on :)
**\<Xeagu>** How does the dynamic block size change from its current state?
**\<suraeNoether>** ArticMine: also good to know
**\<suraeNoether>** xeagu right now
**\<sarang>** The newer proposals do away with the idea of a single median
**\<suraeNoether>** we allow next max block size to be 2\*Median(last N blocks)
**\<suraeNoether>** i forget N
**\<moneromooo>** Xeagu: https://paste.debian.net/hidden/556a3a8a/
**\<moneromooo>** 100000
**\<sarang>** Details that have been previously reviewed can probably be discussed more deeply after meeting, IMO
**\<Xeagu>** moneromooo: that's too high level for me
**\<moneromooo>** And 1.4 IIRC, not 2.
**\<Xeagu>** I'll review other notes sure
**\<suraeNoether>** moneromooo: oh! that's good :D
**\<suraeNoether>** xeagu i'll get you after the meeting
**\<sarang>** atm, I am waiting to see what cost details are added by ArticMine to ensure we understand the relative cost of bloat under the different options
**\<Xeagu>** Okay
**\<suraeNoether>** basically: block size scaling is still under discussion, we are working on formalizing articmine's proposal and comparing it to our present proposal as well as at least one other proposal.
**\<suraeNoether>** and i think sarang and i can collaborate on a technical note describing all this
**\<suraeNoether>** moving along to MRL 11's status update: MRL 11 is essentially about traceability and linkability in Monero, and comparing techniques across multiple blockchains like Zcash + Monero together
**\<suraeNoether>** if you guys have seen matthew green and binaryfate and fluffypony sparring on twitter about ring sizes compared to the shielded pool in zcash
**\<suraeNoether>** this is that
**\<Xeagu>** Zcash doesn't scale
**\<silur>** ah :D
**\<suraeNoether>** the current status is that sarang passed it back to me more than a week ago, and i've been tinkering with simulations
**\<ArticMine>** My proposal uses the current 2x maximum for the short term median and 1.4x for the long term median
**\<Xeagu>** You can't let every transaction be shielded without huge data storage
**\<suraeNoether>** i want to simulate something like the following, and it's quite challenging to formalize this (i'm bringing my hangup to the crowd so you guys know what i'm stuck on)... I want to create a formal statistical hypothesis, and it's eluding me...
**\<suraeNoether>** essentially, i want to capture the EABE scenario that started this whole paper last year
**\<suraeNoether>** and churn
**\<Xeagu>** EABE scenario?
**\<sarang>** Poisoned outputs
**\<Xeagu>** Oh got it
**\<suraeNoether>** I want to generate a random blockchain (somehow) and embed within it the spending behavior masking "churn" between receiving a possibly "marked note" and then later trying to cash it out at a KYC/AML exchange
**\<suraeNoether>** then i want to apply our matching technique to see the probability that this behavior is caught, if someone is looking for it
**\<Xeagu>** But as I understand if you just show view key, the exchange will accept it
**\<suraeNoether>** xeagu that's the final vertex in the transaction graph
**\<suraeNoether>** there may be many intermediate vertices as you churn
**\<suraeNoether>** most importantly, we need somehow to gauge the entire confusion table; false positives, false negatives, true positives, and true negatives
**\<Xeagu>** Like how far back do exchanges care about poisoned outputs?
**\<sarang>** unknown
**\<suraeNoether>** and i can do this \*under certain hypotheses\* but i can't do it in general. all i really i want is a practical comparison of our technique to a real world scenario like a miner trying to hide that he's depositing a mined coin on an exchange
**\<sarang>** You should conservatively assume "all the way back"
**\<sarang>** Anyway, feels like we're getting off topic somewhat
**\<Xeagu>** Was regarding MRL 11
**\<Xeagu>** Traceability comparison
**\<suraeNoether>** so, to summarize MRL 11: we have an algorithm, we have timing estimates, we are working on simulations and comparisons of our technique across multiple blockchains at once, and we are basically gearing up to figure out how many churns is enough... or... alternatively... we are gearing up to figure out how to show the depth of the wastefulness of having a massive anonymity set like the whole zcash shielded
**\<suraeNoether>** pool
**\<suraeNoether>** sarang: think that was an okay summary? i don't want to speak for you
**\<sarang>** Yes, the computational bounds are the most interesting part IMO
**\<suraeNoether>** yeah, same actually
**\<sarang>** they set a framework for analyzing certain behavior
**\<suraeNoether>** the interesting thing to me is we were able to put lower bounds on how fast an attacker can generate a "guess" at a possible spend history
**\<suraeNoether>** bad news: it's pretty fast. good news: there are lots and lots of possible spend histories, like cryptographically many
**\<suraeNoether>** how much is the practical security compared to a zk-snark scenario? we'll find out
**\<sarang>** So you earlier discussed block size scaling (waiting on cost analysis)... did I also miss anything on output selection?
**\<suraeNoether>** spoiler: if both blockchains exist together at the same time, one with an opt-out transparent pool and both with users interacting at KYC/AML exchanges... then security on both are wildly compromised
**\<suraeNoether>** sarang eek I forgot to add output selection to the agenda, that's my bad
**\<sarang>** OK, is now a good time for this?
**\<suraeNoether>** perfect time actually
**\<sarang>** Great
**\<Xeagu>** It's not on the agenda but I wanted to make sure we discussed the rumor of ASIC/FPGAS on the network.
**\<sarang>** moneromooo had asked me earlier about reviewing our windowing approach to gamma selection
**\<sarang>** He had an idea about further weighting selection probability of a block based on output count
**\<sarang>** with a possible goal of reducing the coinbase-to-non-coinbase ratio in rings to that of the whole chain
**\<suraeNoether>** xeagu we'll get to that in a sec, thanks for reminding me :\\
**\<sarang>** e.g. 6-10% of outputs are coinbase, so 6-10% of a ring should be as well
**\<sarang>** moneromooo can explain it better, but the idea would be to take the gamma probability of block selection and further weight by the block's output count, and then uniformly select within that block
**\<sarang>** I'm working up some code based on chain stats
**\<sarang>** but I'll put it out there for comment
**\<suraeNoether>** sarang #actually
**\<suraeNoether>** the distribution in the ring should be "whatever the probability that the next transaction is a coinbase output."
**\<Xeagu>** I think miners churning newly mined coins would help against poisoned outputs
**\<suraeNoether>** so if miners typically hodl for long long long times, then mimicing the distribution of the outputs that care coinbases will drastically over-sample the coinbase outputs.
**\<suraeNoether>** xeagu i agree
**\<gingeropolous>** \<sarang> e.g. 6-10% of outputs are coinbase, so 6-10% of a ring should be as well >>>>> but 99% of coinbase outputs are owned by about 15 people
**\<suraeNoether>** i think a lot of miners churn in order to mask that they are mining
**\<suraeNoether>** gingeropolous: exactly!
**\<sarang>** I know, but we have no good metric for "how many coinbase in a ring is ok"
**\<suraeNoether>** unfortunately we don't really have a way of estimating how often any given subsets of our blockchain are spent
**\<sarang>** Currently it's 1-3 outputs per ring on average that are coinbase
**\<moneromooo>** The idea I had is meant to (I think) make the selection process match the gamma from an ideal blockchain (ideal being, every block has the same number of outputs).
**\<moneromooo>** And indeed, in that particular case, the two distributions match.
**\<moneromooo>** The idea has two steps:
**\<sarang>** Nice, did you run sims?
**\<moneromooo>** - for each block, calculate its probability of being picked by the gamma distribution pick
**\<moneromooo>** - for each block, multiply that number by the number of outputs in that block
**\<moneromooo>** Then you just pick a random block from those weights using a discrete distribution.
**\<moneromooo>** I did not run sims, because I do not know how to calculate the first step.
**\<suraeNoether>** MOO
**\<suraeNoether>** you brilliant bastard
**\<suraeNoether>** you want to know why that works?
**\<sarang>** moneromooo had pointed out earlier that this also solves the issue of a fixed window size
**\<moneromooo>** Well, I see how it'd work by, er... intuition really. Why does it work ?
**\<suraeNoether>** you are estimating an empirical distribution: when you multiply that number by the number of outputs in the block, you are computing the expected number of outputs to be selected from that block. then you built a histogram and selected from that!
**\<sarang>** Yeah
**\<suraeNoether>** it's cool
**\<suraeNoether>** expectation as a linear operator
**\<suraeNoether>** fun stuff
**\<suraeNoether>** \*ahem\*
**\<sarang>** the scaling of coinbase outputs in this case is also independent of the gamma distribution, which I find neat
**\<suraeNoether>** very frequentist. hem hem
**\<suraeNoether>** yeah, you could use this with any underlying hypothetical distribution
**\<sarang>** I'm confirming that it does so, and writing up some sims to convince myself of it
**\<suraeNoether>** \\me eats oatmeal
**\<sarang>** kudos moneromooo, it's a clever approach that fixes the issues with windowing
**\<gingeropolous>** so there's still a probability that multiple coinbases will be selected, but because tiny blocks have low probability, we should expect less outputs selected from tiny blocks?
**\<suraeNoether>** it actually fixes several other things i'd been thinking about
**\<suraeNoether>** it's a great framework.
**\<moneromooo>** Thanks. Still needs a way to compute the first number. I fear it might involve integrals.
**\<Xeagu>** I don't understand :/
**\<sarang>** moneromooo: probably not =p
**\<suraeNoether>** gingeropolous: yeah, exactly. each output has a gamma age, and then you select from all outputs. rather than selecting an output age from a gamma and then selecting from all the outs with that age. subtle flipping of the order of things
**\<sarang>** I believe it should reduce the ring ratio to that of the whole chain
**\<Xeagu>** I don't know what gamma means
**\<sgp\_>** In the most extreme case, we can say 0 coinbase are necessary and force independent miners to churn their received funds if they care. Pools don't care and are the main cause of this debate. But there doesn't seem to be enough support for this, and it comes with other tradeoffs. I just think it's important to keep mentioning
**\<moneromooo>** A particular random distribution.
**\<sarang>** the way we select ring members using math Xeagu
**\<gingeropolous>** Xeagu, you can think of gamma as a droopy triangle
**\<suraeNoether>** xeagu there is a long statistical background on the gamma distribution. we'll catch you up after the meeting
**\<gingeropolous>** right triangle, 90 degrees on the right side. the hypotenuse is the droopy side
**\<sarang>** sgp\_: we can enforce coinbase-only rings as a first churn, but that doesn't solve the heuristic of "coinbase are bad"
**\<sarang>** it just moves it along the transaction graph a teeny bit
**\<sarang>** so I feel ya
**\<suraeNoether>** you flip a coin until you get a heads up and right down the number of flips. then you do that 10 times. then you add those wait-times-until-heads-up together
**\<sgp\_>** sarang: this would just accept "coinbases are bad" and not touch them whenever possible
**\<Xeagu>** So if gamma is a process (verb) how is it acting as an adjective modifying a noun (age)?
**\<gingeropolous>** i dunno what parameters we use, but https://en.wikipedia.org/wiki/Gamma\_distribution#/media/File:Gamma\_distribution\_pdf.svg
**\<gingeropolous>** i'd guess we look like the red line
**\<suraeNoether>** and then you ask "what is the probability that i got wait times of 3, 2, 0, 1, 1, 0, 1, 2, 1, 0?" that's essentially a gamma distribution
**\<gingeropolous>** Xeagu,
**\<sarang>** The heuristic would move from "coinbase in a ring are decoys" to "outputs generated in a coinbase-only ring are decoys"
**\<suraeNoether>** sarang i'm not sure i follow that
**\<sarang>** unless you convince miners to churn more out of the goodness of their pooled hearts
**\<suraeNoether>** oh i think i follow you
**\<sarang>** Right now you might throw out all coinbase ring members as decoys
**\<sarang>** Now you look back one step, and throw out an output generated from an obvious coinbase churn
**\<sarang>** You gain very little from this
**\<suraeNoether>** yeah, i think i follow yoiu
**\<sarang>** So I like the idea of shooting for a ring member ratio matching the chain
**\<sarang>** and this weighted approach should do that for us
**\<sarang>** to be confirmed by sanity-check sims!
**\<suraeNoether>** okay, so the output selection method proposed by moneromooo is actually a really clever way of computing expectations, and as a consequence, gives us a better output selection method. we should glance through the code, but i'm happy with that
**\<suraeNoether>** FPGA/ASIC stuff
**\<sarang>** Neat
**\<suraeNoether>** let's move along
**\<suraeNoether>** i hear some nonce distributions are non-uniform
**\<sarang>** and they recently changed as of the new year-ish
**\<suraeNoether>** fun
**\<suraeNoether>** so, i'm not really prepared to talk about monero POW and asic-resistance right now, tbqh
**\<suraeNoether>** i happened upon some reading this weekend on sponge constructions, so i'm currently on the path toward learning more about hash functions and pseudorandom functions
**\<suraeNoether>** but i don't have any thoughts i want to make public right now
**\<suraeNoether>** sarang?
**\<suraeNoether>** (i'm not keeping anything from anyone either, I harbor no secret opinions on this either)
**\<sarang>** I have been working on sims relating to output selection and block size, and continue side work on bulletproofs MPC and related things
**\<sarang>** I'll be attending the Stanford academic crypto conference this week
**\<suraeNoether>** Yeah, sarang and endogenic and i and isthmus will all be there
**\<silur>** \*not envy\*
**\<suraeNoether>** CONVENIENTLY i found my LAST FOUR MRL shirts, so you know
**\<suraeNoether>** i'll be forcing everyone to wear them for a photo
**\<sarang>** Does anyone else have work to share before we review action items?
**\<Xeagu>** I have to go
**\<suraeNoether>** i have been doing some reading on alternatives to ring signatures
**\<Xeagu>** Great meeting everyone
**\<suraeNoether>** i plan on writing up a technical note summarizing different options in different cryptographic hardness settings, timing and space comparisons
**\<learninandlurkin>** Alternatives without huge resource drain?
**\<suraeNoether>** learninandlurkin: so, some of that is tricky
**\<sarang>** that's always the kicker
**\<suraeNoether>** for example, i came across some short-integer-solution methods with lattices that are FAST AS HECK but HUGE
**\<silur>** oh yes
**\<suraeNoether>** the tradeoff isn't there yet, but it's worth summarizing it all
**\<silur>** my favorites
**\<silur>** they are also good for accumulators
**\<silur>** I have some demos on that
**\<silur>** been working with SIS for long
**\<suraeNoether>** silur ooh, i'd love to see a link of some sort
**\<silur>** I've got really into noncommutative crypto recently
**\<suraeNoether>** so i'll be summarizing i think four papers in the coming days, to communicate some of the options we have to the community
**\<silur>** it feels like a graveyard because except for the primitives everything is broken
**\<sarang>** Action items for this week?
**\<silur>** but I asessed all attacks and stuff that are still holding in the recent months
**\<silur>** main focus on zk stuff now
**\<sarang>** I am looking forward to ArticMine's sim code updates to reflect rational miner costs, which will allow us to assess our options for next upgrade
**\<suraeNoether>** my action items are: matching simulations and hypothesis testing, and my alternatives-to-ring-signatures-aren't-much-better technical note
**\<learninandlurkin>** I'll look forward to that suraeNoether. With ringsigs being our main weakness and also the main missing component of Grin (as compared to XMR) I think this are of research will have big implications.
**\<silur>** ringsigs are our main weakness?
**\<silur>** what happenned with RTRS?
**\<sarang>** It remains an option, but one that requires a lot of overhauling for still being ring sigs :.
**\<sarang>** :/
**\<suraeNoether>** silur: sarang has gotten them to be suitably fast with multiexponentiation so that we could, say, use ring sizes up to, say, 20-30. however, there are some other sublinear schemes that are available, each with their own trade-offs, which is why i'm writing my paper
**\<silur>** wow
**\<suraeNoether>** i was hoping that once we broke a certain speed barrier, the path forward would be a no-brainer
**\<silur>** okay, I'll be waiting for it
**\<silur>** the paper I mean
**\<suraeNoether>** but we have certain issues we're dealing with and it's not totally clear whether overhauling the system for such a small ring size boost would be worth it if there could be another option with a relatively bigger boost eventually
**\<sarang>** well said
**\<suraeNoether>** replace that last word "eventually" with "presently"
**\<suraeNoether>** cool, /meeting