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

Overview and Logs for the Dev Meeting Held on 2018-01-28 & Logs for the Monero Research Lab Meeting Held on 2018-01-29

Browse source 
Add research tag
This commit is contained in:
dEBRUYNE-1 2018-02-01 19:12:57 +01:00
parent ae3c59fd2f
commit 0e1cfc4557
No known key found for this signature in database
GPG key ID: B9145F6EBFA81C32
2 changed files with 474 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

218
_posts/2018-01-28-overview-and-logs-for-the-dev-meeting-held-on-2018-01-28.md Normal file
View file

@ -0,0 +1,218 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2018-01-28
summary: Discussion of open PRs and issues, Bulletproofs, March HF, fees, Debian package, GUI update, and miscellaneous
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
---
# Overview
An overview can be found on [MoneroBase](https://monerobase.com/wiki/DevMeeting_2018-01-28).
# Logs
**\<hyc>** meeting time
**\<rehrar>** ye
**\<rehrar>** agenda: https://github.com/monero-project/meta/issues/166
**\<rehrar>** as always, start with 1. Greetings
**\<sarang>** yo
**\<msvb-lab>** Hi there.
**\<hyc>** hey
**\<rbrunner>** Hoi zämme
**\<iDunk>** Hi
**\<pebx>** hi
**\<rehrar>** ArticMine fluffypony luigi1111 luigi1111w smooth NoodleDoodle anonimal anonimobile endogenic gingeropolous vtnerd pigeons
**\<pigeons>** hi
**\<vtnerd>** hi
**\<rehrar>** dEBRUYNE Jaquee dsc dsc2 ?
**\<gingeropolous>** oh theres a meeting?
**\<rehrar>** anyone else?
**\<endogenic>** no ginger
**\<iDunk>** moneromooo
**\<dEBRUYNE>** I am her
**\<dEBRUYNE>** e
**\<rehrar>** medusa moneromooo othe
**\<smooth>** 1
**\<rehrar>** Well, welcome everyone! :)
**\<rehrar>** 2. Brief review of what's been completed since the previous meeting
**\<rehrar>** Anyone have any exciting stuff to report for development?
**\<medusa>** hi
**\<sarang>** MRL Goes To Stanford
**\<sarang>** It was observed that bulletproofs can have batch verification, which will be great time savings even between separate transaction
**\<ArticMine>** hi
**\<bearretinjapan>** hi
**\<hyc>** batching is always interesting. have to balance batch size vs latency, waiting for enough txs to arrive to fill a batch
**\<sarang>** This can be useful for new nodes
**\<smooth>** currently the code waits for all the txs before doing anythign with them anyway, although that could change
**\<sarang>** Initial testing by andytoshi indicated that subsequent proofs were only ~15% of the time complexity of a separate verification
**\<hyc>** nice
**\<sarang>** Yeah, it merges all the multiexp operations into one
**\<sarang>** effectively replacing group operations with scalar operations
**\<sarang>** So the time savings really depend on the relative timing between those ops
**\<sarang>** Anyway, mostly excellent talks at the conference, and good lessons learned
**\* sarang** will be quiet now
**\<rehrar>** Anyone else? :) GUI have anything?
**\<medusa>** the GUI project has merged sub addresses. also we removed the ability for the user to generate payment ids and integrated addresses
**\<medusa>** in addition, there is a new monerod start up flag, called --boostrap daemon https://github.com/monero-project/monero/pull/3165
**\<hyc>** ^^ this looks very good. I wonder if the GUI should use that by default
**\<medusa>** the GUi will make use of this too, so there dont exist several implementations of the same thing
**\<gingeropolous>** is that supplanting Jaquee 's thing?
**\<medusa>** PR is allready here hyc https://github.com/monero-project/monero-gui/pull/1091
**\<medusa>** gingeropolous:as far as i understand it, yes
**\<rehrar>** I'll repaste xmrscott[m]'s message so people who don't want to click don't have to
**\<rehrar>** David Mirza Ahmad, president of Subgraph OS, has put together a byte-for-byte matching Debian package and is requesting comment on some final pieces: "There some decisions to make for us, like: where does the blockchain data go? Do we start the daemon with systemd by default (feeling like no, as it can be started in GUI)? Appreciate thoughts on this." No one has provided comments on these matters so if anyone here could do so it woul
**\<rehrar>** d be appreciated. https://github.com/monero-project/monero/issues/2395
**\<rehrar>** \^
**\<pebx>** thanks for the update medusa! this looks very good. we shouldn't forget that GUI is the interface to the rest of the world...
**\<msvb-lab>** rehrar: Byte for byte matching, you mean as in reproducible build? Gitian?
**\* rehrar** applauds the GUI people for their consistent quality work
**\<pigeons>** I looked at his repo and i didnt see the debian control files to reproduce
**\<rehrar>** xmrscott[m] \^ msvb-lab's question
**\<ArticMine>** Any idea on timeline from an update at out end to the repo?
**\<xmrscott[m]>** I believe so. I'm not familliar with build terminoogy,
**\<xmrscott[m]>** The sha256 sums match: d5b0295d55f9951a6995e2ecc1516898799b22686ed81ca07b05b493175f2f66
**\<xmrscott[m]>** (THis is shown on the comments in the GitHub issue)
**\<rehrar>** Any answer for ArticMine's question?
**\<hyc>** unknowable
**\<rehrar>** bam
**\<hyc>** distro release schedules are seldom anywhere near upstream release cycles
**\<ArticMine>** My concern is stale Monero in the distro
**\<hyc>** yes
**\<hyc>** it's a frequent occurrence in distro packages
**\<ArticMine>** With a six month hard for cycle
**\<ArticMine>** fork
**\<hyc>** which is why I've never put much priority on distrok packaging. reproducible builds are a good thing in and of themself though.
**\<rehrar>** Alright, if nothing else, we can move on to 3. March hardfork items + code freeze
**\<rehrar>** Anything to be discussed about the upcoming hard fork? Is there a code freeze date yet?
**\<dEBRUYNE>** Preferably very soon. Then we don't have to rush stuff
**\<ArticMine>** ... and bulletproofs
**\<sarang>** What about BPs?
**\<hyc>** seems they're off the table for March, since audits haven't been completed
**\<hyc>** 3rd party audits
**\<sarang>** Correct
**\<rehrar>** missed the meeting last week ArticMine
**\<rbrunner>** Have any been *started* in the meantime?
**\<sarang>** I'm waiting on a formal SoW from one of the groups
**\<sarang>** Then I'll present my recommendations among all groups
**\<medusa>** since BP seems to be off the table, is the new wallet option the only planned change to address current high fee situation ?
**\<sarang>** We're looking at ~40K per professional audit
**\<sarang>** and hopefully get benedikt to do a review of at least the Java since he wrote the damn thing
**\<sarang>** for $
**\<rehrar>** medusa: we should crash the price in the meantime
**\<sarang>** Should we include batch BP verification in the audited code?
**\<sarang>** Or put that aside
**\<endogenic>** rehrar: was that a preannouncement? :)
**\<endogenic>** sarang: perhaps as optional extra credit?
**\<hyc>** we should audit whatever we hope to release in Sept.
**\<hyc>** otherwise we'll just need to do all this again for each incremental improvement. ??
**\<sarang>** It'll be included in an updated whitepaper in Feb
**\<sarang>** by benedikt et al., not by me
**\<rbrunner>** Well, maybe plan in a way that makes pretty damn sure we will be ready in September :)
**\<pebx>** what about the fees medusa mentioned? it's also something the average user sees first and complains about... if we don't release BPs there should be some lowering of fees beside the low to standard thing
**\<dEBRUYNE>** I suppose we can discuss lowering the low priority level since it's arbitrary anyway, but we can't lower the default because we'd have to tweak the penalty as well
**\<ferretinjapan>** BPs being released in March was also cited as a reason for onot loweiring fees.
**\<smooth>** we can lower the default a little i think, but no one has taken the time to study it
**\<smooth>** so actually no, we can't
**\<sarang>** As to BP funding, I plan to open an FFS with "checkpoints" for an amount covering at least one pro audit and another for a review by one of the paper authors
**\<endogenic>** i was just going to ask about that, smooth
**\<smooth>** 'default' isn't really the right term though. the pending PR changes the 'default' to be dynamic
**\<dEBRUYNE>** old default then? :P
**\<smooth>** yeah "medium" whatever you want to call it
**\<smooth>** "normal"
**\<rbrunner>** base fee?
**\<dEBRUYNE>** smooth: any opinion about lowering the lowest level?
**\<smooth>** etc.
**\<rehrar>** Base fee sounds good
**\<smooth>** base fee doesn't seem like the best term to me
**\<smooth>** implies that is actually the fee you pay
**\<smooth>** it is more like a 'fee reference value' or something
**\<rehrar>** I think it should be more than 'medium' though, because it's the one that will increase the block size. Something a little more souped up than 'medium'?
**\<ferretinjapan>** floating reference fee?
**\<rehrar>** Either way, thoughts on lowering the arbitrary 'Low Fee'?
**\<ArticMine>** We have to be careful with the low fee level relative to the 1 tx at penalty (default)
**\<ArticMine>** Spam attacks becomes possible if the probability of mining becomes too low
**\<pebx>** the crypto "market" might crash in the meantime, but it also might not and what if monero's market price until september rises like within the last 8 months?
**\<smooth>** ArticMine: but doesn't the probability of mining just depend on how many of each there are and not the fee amount?
**\<pebx>** the minimum fee is a good protection but also a pain...
**\<smooth>** the issue i see with too much of a gap between levels is the incentive to circumvent (just bump up your own fee a little so you are above all the others in the same level but not all the way to the next level)
**\<dEBRUYNE>** pebx: I'd leave any price predictions out of this discussion. Tomorrow's price is most likely today's price
**\<smooth>** the more gap the greater the incentive to do that
**\<pebx>** dEBU
**\<pebx>** is it not about price when it comes to fees?
**\<smooth>** other than that the low level seems aalmost comletely arbitrary to me
**\<dEBRUYNE>** Price surely influence fees (as they are denominated in XMR). I was just saying that we should leave *price* prediction out of it
**\<rehrar>** Well if we want a code freeze "soon", we should try to decide this "soon" too, no? Or would this not be affected really by the freeze?
**\<dEBRUYNE>** *prediction*
**\<ArticMine>** I mean how low on the min fee do people want to go?
**\<endogenic>** can we put together a study on fees and spam? having a shared model (and simulated results) we can reference and improve collectively would be great… certainly would ease the knowledge gap
**\<pebx>** i didn't want to include any prediction, so i told it might continue or not
**\<dEBRUYNE>** smooth: I guess if we had 1/5th or 1/6th (current is 1/4th) the gap would be still sufficiently small? Also people would have to tweak the code and compile it themselves to make use of the gap
**\<smooth>** endogenic: it has been done. we can do another one but until it is done we can't rely on it
**\<endogenic>** smooth: do you mean the recent writeup?
**\<smooth>** endogenic: that one, the older one. whatever is done we can rely on. we can't rely on something that is 'can we do' especially with an imminent freeze
**\<smooth>** of course we can do more studies
**\<endogenic>** smooth: i would only suggest inaction until after study/ confirmation
**\<ArticMine>** and then nothing for March, after which we will have BP
**\<rehrar>** Which brings us full circle :P
**\<moneromooo>** Can we finish the meeting first, and go back to the fee stuff ?
**\<endogenic>** lol mooo
**\<rehrar>** Alright. Moving on then! 4. Code + ticket discussion / Q & A
**\<pebx>** nice to see you, mooo
**\<dEBRUYNE>** pebx: Your sentence sounded like that, hence my statement. I could've misinterpreted you though.
**\<ArticMine>** I sugest we leave fees aslon for March or at most introduce the wallet side adaptive fee between default and min
**\<ArticMine>** alone
**\<medusa>** thats allready merged afaik ArticMine
**\<smooth>** the adaptive should go in if at all possible from a stability perspective imo
**\<smooth>** oh i didn't know it was merged. great
**\<pebx>** dEBRUYNE my point is, that at some point fees can get insane like they have been / are in bitcoin
**\<ArticMine>** Then if it is merged that is all
**\<gingeropolous>** ^^
**\<medusa>** this one no ? https://github.com/monero-project/monero/pull/3123
**\<smooth>** yes. lets move on: rehrar>** Alright. Moving on then! 4. Code + ticket discussion / Q & A
**\<rbrunner>** I have a little thing: The Windows installer missed the Fall releases. But surely the March release is a perfect opportunity to finally put it into service ...?
**\<hyc>** yeah sounds like we're fine for now on fee
**\<gingeropolous>** all this code and ticket discussion
**\<iDunk>** 3186 and 3198 need merging to fix some builds.
**\<rbrunner>** I hope it's not itself controversial that having a Windows installer would be nice
**\<medusa>** absolutely rbrunner, the worlk load regarding that is mostly on the shoulder of the binary builder (pony). we cant really do anything to speed it up i fear
**\<rbrunner>** Ah well, March is early enough :)
**\<rbrunner>** Just do not forget it :)
**\<luigi1111>** I personally prefer portable exe but both are fine with me
**\<moneromooo>** "portable" and "exe", hmmm :)
**\<hyc>** lol
**\<dEBRUYNE>** pebx: I surely hope the dynamic fee algo has kicked in by then. Anyway, I'll refrain from commenting on fees now.
**\<luigi1111>** :)
**\<pebx>** dEBRUYNE hope is good... but i'll also not comment fees in this meeting any more.
**\<rehrar>** Anything else for code and ticket discussion?
**\<rehrar>** 5. Any additional meeting items (besides fees)?
**\<msvb-lab>** Or hardware questions.
**\<rehrar>** did you want to share something msvb-lab?
**\<msvb-lab>** Nothing to share. We're working on the next gen prototype.
**\<msvb-lab>** Questions are welcome in any case.
**\<rehrar>** Alright then.
**\<rehrar>** 6. Confirm next meeting date/time
**\<rehrar>** Feb 11th?
**\<hyc>** sounds right
**\<rehrar>** luigi has mentioned a couple times about switching the time
**\<hyc>** btw, I'll be at FOSDEM next week. anyone else going?
**\<medusa>** i want to thank everyone that is working on making the build envs green. you guys are heros **\<3
**\<rehrar>** don't know if he was serious, but does anyone else agree?
**\<hyc>** switch to what time?
**\<msvb-lab>** hyc: I'll be there too, at FOSDEM in Bruxelles.
**\<rehrar>** luigi1111 luigi1111w?
**\<rehrar>** I guess just as a general question, is this time inconvenient for other people?
**\<hyc>** seems ok to me
**\<rehrar>** hyc has spoken
**\<moneromooo>** IIRC ArticMine objected.
**\<rehrar>** I'll probably open a meta issue and ask for opinions.
**\<ArticMine>** I would prefer an hour earlier
**\<hyc>** good idea
**\<rehrar>** For now we can have next dev meeting same time, and see about moving others.
**\<endogenic>** i'm fine with an hour earlier
**\<rehrar>** Sound ok for everyone?
**\<pebx>** hyc can't wait for your talk to see it at least online!
**\<rbrunner>** Yes, one hour earlier is ok as well
**\<rehrar>** Hmmm...ok, tentative next meeting time Feb 11 at 16:00 UTC
**\<rehrar>** The time will be open for discussion on the meeting issue
**\<rehrar>** Meeting over. Thanks for coming everyone. You're all the best, and don't let anyone tell you otherwise.

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

@ -0,0 +1,256 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2018-01-29
summary: MRL direction, ideas for research, and miscellaneous
tags: [community, crypto, research]
author: dEBRUYNE / fluffypony
---
# Logs
**\<sarang>** Let us begin
**\<suraeNoether>** howdy everyone!
**\<suraeNoether>** maybe we should ping people
**\<endogenic>** vtnerd smooth fluffypony othe stoffu knaccc ArticMine kenshi84 pigeons gingeropolous dEBRUYNE
**\<endogenic>** :P
**\<endogenic>** ferretinjapan
**\<endogenic>** silur (absent?)
**\<endogenic>** hyc
**\<endogenic>** endogenic
**\<suraeNoether>** fluffypony luigi1111 andytoshi anonimal dEBRUYNE endogenic ErCiccione gingeropolous hyc vtnerd smooth othe stoffu silur ArticMine kenshi84 pigeons john\_alan medusa Mouchicc nioc unknownids
**\* andytoshi** breakfast meeting, afk, sorry
**\<anonimal>** Hello
**\<ErCiccione>** Hi! (thanks for the ping)
**\<suraeNoether>** So, today I want Sarang and I to give an account of our experience at BPASE18, and then talk about the January roadmap
**\<hyc>** hey
**\<suraeNoether>** and our overall work for this year
**\<suraeNoether>** if anyone is curious, I live-tweeted the majority of talks at BPASE
**\<sarang>** Several talks highlighted topics relating to smart contracts that have little relevance to us
**\<sarang>** However, there were talks on SPECTRE/PHANTOM and bulletproofs that were well presented and well received
**\<sarang>** among many others
**\<sarang>** We'll be able to integrate a brand-new batch verification technique for bulletproofs
**\<suraeNoether>** yes, that was big news
**\<suraeNoether>** PHANTOM is sort of an interesting layer on top of SPECTRE, which leads to probabilistically picking only honest blocks, interesting analysis led to that
**\<suraeNoether>** also, it turns out bulletproofs are crazy adaptible
**\<suraeNoether>** like, you can put SHA256 into a bulletproof and proof that you know the pre-image to a hash
**\<suraeNoether>** without revealing the pre-image
**\<suraeNoether>** etc
**\<suraeNoether>** very interesting stuff
**\<sarang>** Mhmm, it's a general tool for arithmetic circuits
**\<sarang>** Anyone else working on fun research they wish to share as well?
**\<hyc>** very cool... all of this raises a question in my mind - when do we consider "new" technology to be "mature" ?
**\<hyc>** we're taking extra care integrating BPs because they're "new"
**\<anonimal>** When we stop saying sha256 ;)
**\<anonimal>** How does sha384/512 fit into the picture?
**\<sarang>** Maybe when people stop being excited about it and consider it just a tool?
**\<suraeNoether>** that's a good question hyc
**\<suraeNoether>** here's the thing: our current impelmentation of bullet proofs is specifically a range proof implementation
**\<suraeNoether>** iirc
**\<sarang>** yes
**\<suraeNoether>** so in order ot make it to other things, we need to make new implementations
**\<suraeNoether>** so the failure model or threat model for each implementation will be different
**\<sarang>** Not necessarily. The security model for ACs is pretty well defined
**\<sarang>** We just happen to only be using these for range proof
**\<suraeNoether>** the reason it is so important to validate our implemenation of BP-range-proofs is because if that breaks, then people can mint money. but if we implement some other NIZK proof of knowledge with a BP, we may not need to be so nervous, because the failure of the new implementation may be small in scale, as opposed to "free-mint-ALLTHEMONEY" sort of failure model
**\<suraeNoether>** sarang yeah: for a general AC the implementation analysis i usppose will boil down to analyzing the AC
**\<sarang>** yes
**\<hyc>** ok, makes sense. thanks surae
**\* suraeNoether** thumbs up
**\<suraeNoether>** In addition to that, gmaxwell had a brilliant idea on bug bounties
**\<suraeNoether>** but it only kind of works for their implementation of libsecp256k1, because they have a super robust test suite
**\<suraeNoether>** the idea is to put a bug bounty up for altering the test suite in a way such that all current tests *still pass* but you have uploaded some sort of other test that fails despite that
**\<suraeNoether>** so if I can put a new test into the test suite, call it D, and the test suite already has tests A, B, and C... if D is a failure but A,B,C still pass, then you essentially found a new test and a new weakness, so boom, you get the bug bounty
**\<suraeNoether>** not super helpful in our situation because our test suites are not yet robust
**\<suraeNoether>** but it's an interesting model of bug bounties and unit tests
**\<sarang>** Perhaps we should move on to the roadmap to allow plenty of time to discuss?
**\<suraeNoether>** yep
**\<suraeNoether>** So, here's the deal
**\<suraeNoether>** well one of many deals
**\<suraeNoether>** sarang and I are sort of trying to figure out which direction MRL should go over the next year
**\<suraeNoether>** and we need input. Other htan writing up the Monero Standards, and finishing the multisig paper... we sort of suffer a problem where work is done in jerks and starts
**\<sarang>** It's partly the unfortunate nature of research
**\<suraeNoether>** like a few weeks will go by with apparently not too much to get done, then BOOM all of a sudden it's time to implement and review bulletproofs or BOOM, rtrs ringct or whatever
**\<sarang>** I mean, I want to continue a deeper investigation of DAG structures and consensus models
**\<suraeNoether>** and that makes it feel like we're *reactive* instead of proactive
**\<sarang>** I think that will become increasingly more important
**\<suraeNoether>** yeah, i do too
**\<suraeNoether>** i've been working on an adaptable population-driven model of a cryptocurrency network to assess dynamics and how various algorithms affect them. for example, if we want to study a different consensus model or a different PoW algorithm or if we want to study how difficulty metrics respond to changes in hashrate, etc
**\<suraeNoether>** so we can model long-term scaling issues on a controlled simulation
**\<sarang>** Smaller things include broader implementation of curve/scalar optimizations, but that's just housekeeping stuff
**\<suraeNoether>** I also have been working on SPECTRE and finishing up the multisig paper
**\<sarang>** Developing outreach curricula is a non-research side of things, of course, but I believe still important for this group
**\<suraeNoether>** which, btw, after speaking with pietr wuille in Zurich and Stanford, two separate routes an attacker could take have been made clear to me. One of them our code already accounts for. The other is something I need to speak with luigi1111 and moneromooo about
**\<sarang>** In what regard?
**\<hyc>** multisig?
**\<suraeNoether>** yes for multisig i mean
**\<suraeNoether>** there is a simple-ish fix too
**\<suraeNoether>** it's not a huge deal, but it's a big enough deal that I want to speak in private with folks about it before proceeding
**\<gingeropolous>** would it be worth investing time in a network simulator? i know there are various blockchain / p2p sims out there, and it might be more of a technical issue (more admin than research) ....
**\<sarang>** Depends on what we want to model
**\<suraeNoether>** gingeropolous: that's sort of what i'm coding. i'm dissatisfied with several of the other pieces of simulation software out there
**\<hyc>** are you talking open source projects that we can tweak to suit ourselves?
**\<suraeNoether>** of course
**\<hyc>** \^ to ginger actually
**\<suraeNoether>** oh i see what you mean hyc
**\<suraeNoether>** yeah my mistake
**\<gingeropolous>** im imagining something public facing, with a GUI so an average user can go "oh lets drop the fee to 0.0001 and see what happens"
**\<gingeropolous>** some web interface
**\<suraeNoether>** ah so gingeropolous
**\<gingeropolous>** but that could be phase 2
**\<suraeNoether>** forget about fees, because i'm oinly looking at block dynamics
**\<sarang>** You'd need a much deeper understanding of how nodes/users respond to such factors though?
**\<suraeNoether>** not transaction dynamics
**\<suraeNoether>** but the point is to eventually build it up to do that sort of thing
**\<gingeropolous>** cool
**\<hyc>** quite a lot of variables to model
**\<suraeNoether>** animate it with ggplot or something to make pretty videos
**\<suraeNoether>** hyc yep, it's a very general model, makes it suitable for arbitrary plug-n-play sort of analyses
**\<suraeNoether>** but back to the roadmap
**\<suraeNoether>** i guess what i'm asking is:
**\<suraeNoether>** what do people want to see out of MRL over the next 6 months?
**\<suraeNoether>** other than the completed multisig paper
**\<sarang>** To be honest, I don't think the broader Monero community really has specific opinions on research directions, if that's what you mean
**\<suraeNoether>** hyc you are never opinion-less
**\<hyc>** lol
**\<hyc>** All the things you already outlined sound like important goals to me. some of it sounds like we need more people.
**\<moneromooo>** Modelling of spent output age. Take real distribution since last release, subtract the distribution we use, get the real distribution. See if it matches miller et al.
**\<hyc>** "get the real distribution" --> how?
**\<moneromooo>** Then try to do that at several historical times, every month maybe. And then deduce a formula to vary gamma function over time to use a new fake outdistribution.
**\<moneromooo>** By subtracting the fake outs distribution from the real+fake one.
**\<moneromooo>** May or may not be good enough, I don't know.
**\<suraeNoether>** moneromooo: if we can get a bayesian estimate that updates each hard fork, that'd be great, but it requires being able to "unmask" transactions to see their real spendable output, or to base the estimate on transactions that have already been "unmasked", or to base the estimate on another currency. Each of these have obstacles, obviously
**\<suraeNoether>** we need some ground truth underlying data to make an estimate, and monero doesn't really allow for that
**\<ErCiccione>** The community is pushing a lot the "fee are too high" thing and i feel will be worst with time passing. Is it possible to produce some documentation to instruct people about how Monero fees work and what are the plans for the future on this matter?
**\<moneromooo>** I was suggesting deducing the real outs distribution.
**\<ErCiccione>** i also agree with hyc, er should search fore more researchers
**\<sarang>** I hear gmaxwell is unattached =p
**\<moneromooo>** This would be assuming all txes since last release use our fake outs distribution, though, which mymonero might not. Damn.
**\<hyc>** to some extent, that's all good news - it means the system is no longer analyzable.
**\<dEBRUYNE>** ErCiccione: I wrote a blog about it, you can link that
**\<suraeNoether>** so, ErCiccione: yes, fees are an important part of the discussion around bulletproofs. you are corredct that we should at least put out a statement
**\<suraeNoether>** hyc: without access to KYC/AML data from an exchange, anyway :D
**\<suraeNoether>** i suppose we could ask for some sanitized data from one of the exchanges...
**\<suraeNoether>** actually that's the first time that i've been hopeful about deducing true age distribution
**\<suraeNoether>** but here's the REAL problem
**\<ferretinjapan>** does the current research on multisig cover more complex things like assurance contracts? I think people would definitely be keen to help fund research in enabling those types of things.
**\<suraeNoether>** ferretinjapan: the current paper will not cover that except lightly, but i would loooove to write up a document on "applications of multisig in nearly-smart contracts."
**\<suraeNoether>** let's say there's a really massive anonymity set: the probability of picking any one of them out for usage in a ring is really really small
**\<ferretinjapan>** Because that could mean 100% decentralised FFS :)
**\<suraeNoether>** and if you pulled randomly from the whole blockchain...
**\<suraeNoether>** then the true output you are signing with *probably* hasn't been used in a signature before
**\<suraeNoether>** and more people got into monero recently rather than in 2014
**\<suraeNoether>** so the output being spent is *probably* the youngest one
**\<hyc>** true
**\<suraeNoether>** and this will *always* be the case, unless we make wallet software actively try to de-anonymize the blockchain and we publish a blacklist of known-spent outputs
**\<suraeNoether>** or unless we make wallet software that tries to pick as many transactions from "recently" that have not yet been used in any ring signature
**\<suraeNoether>** another way of looking at this: the first ring signature an output appears in *is likely* to be the one that actually spends it
**\<suraeNoether>** it's not so much a matter of the age of the output
**\<ErCiccione>** dEBRUYNE: right, i forgot about that, but i still think we should be more informative about fees, i see a lot of confusion in the average user, at least on reddit,
**\<suraeNoether>** but how many other ring signatures already reference it
**\<suraeNoether>** ErCiccione: absolutely +1
**\<suraeNoether>** okay, so fees are going on my list
**\<suraeNoether>** for analysis and a nice big public explanation, probably drawing heavily on the blog post by dEBRUYNE
**\<suraeNoether>** speaking of which dEBRUYNE send us all a link :D
**\<dEBRUYNE>** https://getmonero.org/2017/12/11/A-note-on-fees.html
**\<suraeNoether>** awesome thanks
**\<dEBRUYNE>** re: spent age of outputs, perhaps we could take a look at other chains as well?
**\<suraeNoether>** silur has been working on a C implementation of RTRS ringct
**\<ferretinjapan>** dEBRUYNE, aeon could be a decent model, unless it requires 100% transparency...
**\<suraeNoether>** dEBRUYNE: that comes with its own set of assumptions. i'm actually (I think) more comfortable asking "how long does an average 50 euro bill stay in someone's wallet before being spent?" than "bitcoin"
**\<suraeNoether>** ferretinjapan: aeon suffers the same problem we do i think
**\<ferretinjapan>** ah
**\<suraeNoether>** has anyone else been working on anything they want to talk about?
**\<dEBRUYNE>** ferretinjapan: was more thinking about LTC, BTC
**\<dEBRUYNE>** suraeNoether: whislt that it true, it may be good for pointers
**\<ferretinjapan>** yeah, LTC is actually a good one, had a similar mining start to monero.
**\<suraeNoether>** even if we had a good estimate of true velocity of money, it changes over time so we would need something like a bayesian updating. https://en.wikipedia.org/wiki/Velocity_of_money
**\<suraeNoether>** sarang, do you have anything else you want to chat about?
**\<ferretinjapan>** suraeNoether, true, but I'd wager that LTC and XMR's normal distribution after a year is probably very similar. It's probably clsest you'd get without cracking open monero proper and looking inside.
**\<sarang>** Assembling the formal audit materials as they become available
**\<sarang>** I still wish we had a more concrete guideline for if/when/how we'll do such things in the future
**\<sarang>** But for now this is a Good Thing
**\<suraeNoether>** ferretinjapan: you are assuming it's normal... it isn't, it's heavy-tailed and possibly non-unimodal. :D but you are probably correct that LTC would be a better metric than BTC imho
**\<suraeNoether>** i am curious about one thing
**\<suraeNoether>** Up to your concerns about opsec/privacy, gimme a +1 if you are currently an undergraduate university student
**\<ferretinjapan>** yeah, I'm definitely not saying it's perfect just close-ish compared to the rest of the premined coins out there ;)
**\<suraeNoether>** ferretinjapan: i agree that litecoin could be a good proxy for monero for estimating otherwise unestimable statistics
**\<suraeNoether>** i'd also be in favor of doing it for all transparent coins and obtaining a confidence interval
**\* anonimal** question regarding the MRL over the next 6 months
**\<anonimal>** I first got in contact with sarang back in late August about kovri work but nothing came of it.
**\<anonimal>** That then lead to a late October chat about said kovri work but nothing came of it.
**\<anonimal>** Should I just not count any kovri collaboration from the Noethers? I understand, no hard feelings.
**\<anonimal>** We simply need more researchers.
**\<ferretinjapan>** yeah, do some box plots on a couple dozen and you might get a ballpark figure that helps.
**\<sarang>** anonimal to be honest I didn't think we'd have so much work with RingCT and BPs occupying time
**\<suraeNoether>** i think you are right anonimal
**\<sarang>** It has nothing to do with lack of interest
**\<suraeNoether>** i recall that contact
**\<sarang>** but I apologize if it seemed that way
**\<suraeNoether>** anonimal: is there either an explanatory text or a link or something you would you mind giving us for a look?
**\<suraeNoether>** depending on exactly what sort of questions you are asking, there may be intersection with other work we are doing
**\<anonimal>** What explanatory text would you like exactly?
**\<suraeNoether>** is there a thread someplace that birthed the idea behind kovri?
**\<anonimal>** Oh. Well those IRC logs were unfortunately pasted to a now-defunct website. I can give TL;DRs if needed though.
**\<anonimal>** Ideally our website/docs would explain everything you need to know but rehrar and I are still WIP with them.
**\<suraeNoether>** ok, so i'll devote a few hours this week to learning about kovri to see *whether* i can help
**\<suraeNoether>** keeping in mind the halting problem
**\<suraeNoether>** (can never really know how long something is going to take until you do it).
**\<anonimal>** How realistic/effective would a noether tweetnacl review be?
**\<anonimal>** tweetnacl has had a lot of eyes
**\<sarang>** You want additional eyes on it?
**\<anonimal>** (relatively speaking, imo)
**\<anonimal>** No, just asking your professional opinion on if that would be a cost-effective use of your time.
**\<anonimal>** IIRC fluffypony wanted teetnacl in monero as some point. I'm not sure where that conversation ended though.
**\<selsta>** some other “news”. Sumokoin team member confirmed me today that they will donate to the BP audit with some of the premine money. i don’t really believe it yet though lol
**\<anonimal>** Crypto++ has recently implemented tweetnacl and, once they implement a crypto++-friendly interface, kovri will drop ref10 supercop for tweetnacl.
**\<suraeNoether>** let me learn a little about tweetnacl, and then i can assess wheter going deeper will be a rabbit hole or ... not
**\<anonimal>** ok
**\<suraeNoether>** i haven't tried to ignore it
**\<suraeNoether>** squeaky wheels and all that
**\<suraeNoether>** i'm curious about how it works
**\<suraeNoether>** but i don't want to go on a two month bender learning a new tech while current projects languish either
**\<suraeNoether>** i think hiring an additional person would be fantastic, for the record
**\<sarang>** Well it does the basic ed25519 operations suraeNoether as well as hashing operations
**\<suraeNoether>** we could get a mathjobs.org employer account and put out a *real* call for applications
**\<suraeNoether>** sarang: well that's nice
**\<suraeNoether>** ok, anonimal thank you so much for bringing this up
**\<suraeNoether>** one hard part about this job
**\<sarang>** yes indeed
**\<anonimal>** You're welcome. I'm just really excited to finally get to use it.
**\<suraeNoether>** is that everyone has their personal pet project they want to see analyzed, some of them are important like multisig and kovri and some not so much, and so it's difficult to figure out where priorities should go to avoid context-switching, etc
**\<suraeNoether>** sometimes it feels like no one knows what job sarang and i have. :P
**\<suraeNoether>** we need a suresh noether
**\<suraeNoether>** Okay, well
**\<anonimal>** I think this tweetnacl business would come at the end of 6 months if even within the next 6 months. Too many other priorities imho
**\<suraeNoether>** any other concerns, questions, gentle or not so gentle priority nudges folks want to bring up?
**\<sarang>** If anything I'd like to devote time to a review of existing analyses of tweetnacl anonimal
**\<sarang>** to at least get a better sense of its current place
**\<anonimal>** ok awesome
**\<dEBRUYNE>** \<suraeNoether> we could get a mathjobs.org employer account and put out a *real* call for applications \<= I don't think this will be efficient
**\<dEBRUYNE>** Preferably you need someone that already has a passion for Monero
**\<ferretinjapan>** I'll just say you guys are doing a great job keeping up with all these moving targets :)
**\<suraeNoether>** dEBRUYNE: true
**\<suraeNoether>** thanks ferretinjapan
**\<suraeNoether>** oh my god tweetnacl is kind of crazy, i like it ...just reading a quick description
**\<suraeNoether>** i love the idea of a hyper compact auditable li-berry
**\<anonimal>** +1
**\<sarang>** Yeah the key is auditable
**\<suraeNoether>** well, we probably can't hire andytoshi out from under blockstream. :P
**\<suraeNoether>** or rather, i'd rather not attempt that sort of game
**\<suraeNoether>** i'd rather find someone who is very interested in monero and may be late grad school
**\<suraeNoether>** hmm
**\<suraeNoether>** i can construct a call for applications e-mail and send it to a few specific departments that are crypto + CS heavy in their math programs
**\<ErCiccione>** suraeNoether: can you make a post somwhere public with the skills you guys need from a researcher? so i can directly link that to people who may be interested
**\<suraeNoether>** yeah, i will make the call for applications public, probably, ErCiccione
**\<suraeNoether>** anyway
**\<suraeNoether>** I am probably going to hold off on that for at least two weeks, though
**\<ErCiccione>** ok thanks
**\<suraeNoether>** to think about what it is we will need 6 months from now
**\<suraeNoether>** in a new researcher
**\<suraeNoether>** it's a tough question, and if anyone has any thoughts, shoot me a line at suraeNoether@gmail.com
**\<ErCiccione>** ok, so, in case, will directly give your contact for now
**\<suraeNoether>** okay, so without further ado, I suppose we can bid adieu on this meeting.
**\* suraeNoether** cringes
**\<anonimal>** Thanks noethers, thanks everyone.
**\<ErCiccione>** thank you for the updates guys, and awesome job as always :)
**\<ferretinjapan>** same \^