4rkal/monero-site
1
0
Fork 0
mirror of https://github.com/monero-project/monero-site.git synced 2024-12-04 23:51:11 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity

Dev and MRL meeting logs from 2019-06-16/17

Browse Source
This commit is contained in:
el00ruobuob 2019-06-18 14:35:45 +02:00
parent 09c4d9b496
commit df940ae876
No known key found for this signature in database
GPG Key ID: 8794A50E11FE51A0
2 changed files with 354 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

173
_posts/2019-06-16-logs-for-the-dev-meeting-held-on-2019-06-16.md Normal file
View File

@ -0,0 +1,173 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2019-06-16
summary: Development status, Code & ticket discussion, payment ID, CLSAG, and miscellaneous
tags: [dev diaries, core, crypto]
author: el00ruobuob / rehrar
---
# Logs
**\<rehrar>** Meeting time! Who all is here?
**\<rbrunner>** Hi all
**\<hyc>** hey
**\<fullmetalScience>** Hi
**\<dEBRUYNE>** Here
**\<rehrar>** 2. Brief review of what's been completed since the previous meeting
**\<hyc>** v0.14.1.0 is out in the world
**\<rbrunner>** CLI so far, yes ...
**\<rehrar>** so I hear. And I even hear deterministic builds are doing their thing ok
**\<jtgrassie>** hi
**\<hyc>** they are being deterministic now, yes
**\<dEBRUYNE>** Some small improvements still for deterministic builds, but I'd argue it was a excellent first round :P
**\<rehrar>** nothing left to be done on the CLI front then for this little release?
**\<rehrar>** but then also, looking to the next release, what's going on, do we know?
**\<rehrar>** for 0.15
**\<rbrunner>** little release is actually a pretty big release
**\<rbrunner>** feature-wise
**\<hyc>** there may be a few small bug reports for v0.14.1. might want a v0.14.1.1
**\<dEBRUYNE>** I think the intention was to release it way earlier this time, because we can already add all the consensus changes early on
**\<dEBRUYNE>** Unless CLSAG is also going to go in I guess
**\<moneromooo>** It'll depend on whether it gets a review I think.
**\<hyc>** Is 0.15 the October release?
**\<moneromooo>** (in time)
**\<rehrar>** sarang suraeNoether, can you speak to the potential timeline of review for CLSAG?
**\<dEBRUYNE>** hyc: Yeah
**\<rehrar>** dsc\_ selsta dEBRUYNE anything from GUI?
**\<dEBRUYNE>** hyc: So we have about four months left I guess
**\<dEBRUYNE>** GUI v0.14.1.0 has been tagged and fluffypony is working on the builds
**\<hyc>** so when are we expecting to freeze 0.15 ?
**\<dEBRUYNE>** rehrar: Some new stuff for the GUI:
**\<dEBRUYNE>** - White theme
**\<dEBRUYNE>** - Addressbook redesign
**\<dEBRUYNE>** - History redesign
**\<dEBRUYNE>** - Trezor and Ledger Nano X support
**\<dEBRUYNE>** - Fiat price conversion
**\<dEBRUYNE>** - macOS fullscreen support
**\<dEBRUYNE>** Also an update checker + Hindi translation
**\<dEBRUYNE>** And xiphon did a lot of work on improving the communication between the (integrated) daemon and the GUI
**\<rehrar>** oooooh. Looks juicy. thanks dEBRUYNE
**\<rehrar>** so it'll be faster?
**\<dEBRUYNE>** hyc: I guess that is going to depend on whether we want to add CLSAG. If not, we could do a first 0.15 release after RandomX has been merged (e.g. in August)
**\<dEBRUYNE>** And then another point release a month before the fork
**\<dEBRUYNE>** rehrar: Yes and less 'laggy'
**\<moneromooo>** Does someone want to review the share-rpc (pay for RPC service) branch ? :)
**\<moneromooo>** It goes well with a CPU friendly PoW...
**\<hyc>** I may take a look after I get back from konferenco
**\<rehrar>** I assume we don't have any core team here?
**\<moneromooo>** \\o/
**\<rehrar>** but if not, we can still kind of talk about Payment ID stuff
**\<dEBRUYNE>** Btw moneromooo, you already coded up a rough implementation of CLSAG right?
**\<rehrar>** which is number 4.
**\<moneromooo>** Yes.
**\<moneromooo>** Well, sarang did, and I plugged it in.
**\<dEBRUYNE>** rehrar: That's kind of my fault, I forgot to ping them in advance (I did earlier today, but probably too late :/)
**\<dEBRUYNE>** Anyway, we can still discuss it, as there is plenty of opinions on the meta ticket
**\<hyc>** rough? is it something you'd deploy for real, and what we'd submit to auditors to review?
**\<moneromooo>** Both, assuming the review passes.
**\<hyc>** ok
**\<dEBRUYNE>** hyc: With 'rough' I kind of meant that, as far as I could see, it wasn't fully finished yet
**\<moneromooo>** If you have suggestions for changes, go for it.
**\<dEBRUYNE>** moneromooo: I just thought it wasn't fully finished yet, if it is I stand corrected :-P
**\<moneromooo>** Well, I don't know what you've seen before, but AFAIK it is finished now, unless comments.
**\<rehrar>** alright, let's discuss the whole PID thing then, if we can, with the people represented here giving their opinions as well.
**\<dEBRUYNE>** I see, thanks for clarifying
**\<rehrar>** dEBRUYNE: is correct that actually many of core had made their opinions known on the meta discussion
**\<rehrar>** can you link that real fast dEBRUYNE ?
**\<moneromooo>** Did any exchange/merchant switch from long payment ids since... half a year ago, say ?
**\<dEBRUYNE>** I think some smaller ones did, but the big ones (Bittrex, Bitfinex, Binance) did not
**\<dEBRUYNE>** rehrar: sure
**\<dEBRUYNE>** smooth: https://github.com/monero-project/meta/issues/356#issuecomment-500187077 & https://github.com/monero-project/meta/issues/356#issuecomment-501168062
**\<dEBRUYNE>** binaryFate: https://github.com/monero-project/meta/issues/356#issuecomment-499968785
**\<rehrar>** at the end of the thread in particular, ArticMine brings up his revised opinion about potentially looking at removing tx\_extra
**\<dEBRUYNE>** ArticMine: https://github.com/monero-project/meta/issues/356#issuecomment-501347185
**\<ErCiccione[m]>** some big ones like kraken already use subadresses moneromooo, iirc somebody as a list of the status of some exhanges and services
**\<dEBRUYNE>** https://github.com/monero-project/meta/issues/356#issuecomment-499936642 & https://github.com/monero-project/meta/issues/356#issuecomment-499948904
**\<rbrunner>** Yeah, but it would be interesting to see whether somebody \*switched\*
**\<ErCiccione[m]>** maybe sgp\_?
**\<dEBRUYNE>** rehrar: As far as I can see, people don't like temporary banning payment IDs by parsing tx\_extra
**\<dEBRUYNE>** As it is essentially a slippery slope
**\<dEBRUYNE>** So that leaves us with (i) Phase them out by removing all support from the official software or (ii) banning the tx\_extra field entirely
**\<rehrar>** dEBRUYNE: agreed. I see that reflected as well.
**\<rehrar>** yes ^
**\<sgp\_>** I had a list in January, not sure if it is up-to-date anymore
**\<rehrar>** can I ask people to give opinions on the above two options presented by dEBRUYNE?
**\<dEBRUYNE>** rbrunner: The announcement has only been up for 10 days though
**\<rehrar>** I particularly want to hear arguments for or against removing tx\_extra
**\<rbrunner>** dEBRUYNE: Yes, saw it, but we make noises a lot longer :)
**\<sgp\_>** rehrar: I have personally head some arguments against removing tx\_extra from legacy financial services
**\<dEBRUYNE>** The arguments for are, for example, (i) a clean and definitive way to phase out long payment IDs and (ii) improves fungibility
**\<sgp\_>** Zcash has an encrypted memo field that they use to claim support for many traditional remittance services
**\<rehrar>** dEBRUYNE: I think (ii) is kind of massive, given that's our shtick
**\<dEBRUYNE>** moneromooo: I vaguely remember you working on some kind of encrypted memo field too, is that correct?
**\<sgp\_>** ftr I only support parsing for current payment ID behavior to force services to switch. I am not for the removal of tx\_extra in its entirety
**\<dsc\_>** \< rehrar> dsc\_ selsta dEBRUYNE anything from GUI? \<== Past 4 days been working on development related tooling to support QML development, this is unrelated to my CCS
**\<moneromooo>** I have a partial patch for this somewhere. I stopped because it's a bit chicken and egg since you need tx tx key to decrypt the rest and I was not sure what to do yet.
**\<rbrunner>** Likewise. Erasing tx\_extra completey is going overboard somehow for me
**\<rehrar>** sgp\_ rbrunner are there any other reasons for keeping it around?
**\<sgp\_>** rehrar: mostly flexibility
**\<dEBRUYNE>** sgp\_: How is that field used exactly in that context?
**\<rehrar>** and is there a good reason why something like it can't be kept track of externally via third party, and why it needs to be on the base currency?
**\<rbrunner>** Up to a point, it should be possible for the users of the currency to do like they want ... to a certain degree, with a single field
**\<sgp\_>** See "what people will do with this" https://electriccoin.co/blog/encrypted-memo-field/
**\<dEBRUYNE>** On the other hand, do we want to give people the ability to potentially hurt privacy of other participants on the network?
**\<rbrunner>** And who knows, maybe one day we will have some emergency and want to put something in there ourselves. A currency with exactly zero flexibility ... I don't know
**\<sgp\_>** When I was doing payment ID research back in January, someone specifically asked that tx\_extra remained for this flexibility
**\<rehrar>** let me look at the dollar. Does the dollar have this field?
**\<rbrunner>** Marking one's own txs is quite a small privacy risks for others, if you ask me
**\<rehrar>** or are memos and stuff kept and integrated in dollar management software?
**\<rbrunner>** Yes, bank transfers have something like a short memo, right?
**\<sgp\_>** rehrar: I'm not an expert here, I'm just relaying some information to say the flexibility could be useful
**\<rehrar>** rbrunner: sure, but that isn't built into the dollar bill itself
**\<rehrar>** which is my point
**\<rehrar>** is this necessary as a part of Monero itself? Or can monero management software be built to have these memos?
**\<rehrar>** My initial thoughts are the latter
**\<rbrunner>** Hmm, I think that comparison limps a little ..
**\<sgp\_>** my personal opinion is that the flexibility shouldn't be removed unless there's a problem, and we should try to address that more head-on. If we already tried to kill payment IDs and they used a different format in tx\_extra, that would be one thing. But we're in a situation now where we are trying it for the first time and I think a simple parsing would be successful at making people switch over
**\<rbrunner>** Uh, no, several incompatible memo transfer systems will crop up for sure
**\<rbrunner>** Why not fill \*every\* tx\_extra with fake data, if that's such a problem?
**\<rehrar>** hyc, dEBRUYNE, moneromooo? care to chime in at all?
**\<moneromooo>** Not really.
**\<sgp\_>** rbrunner: that's basically what zcash does with the encrypted memo field
**\<moneromooo>** We've gone over that enough for me.
**\<rbrunner>** Yes, and we now with the short payment ids, right?
**\<hyc>** as a protocol guy I tend to favor having extensiblity
**\<hyc>** there's certainly a risk of dumping tons of spam into the chain with a totally open-ended extention field
**\<hyc>** might want to constrain it to "any individual tx\_extra can't be greater than N bytes" etc
**\<moneromooo>** That could be made to weigh extra for the fee fwiw.
**\<hyc>** N=512, 1024, dunno
**\<rehrar>** isn't that what minergate does when they find a block or is that somethign different?
**\<rehrar>** I recall somebody saying they add a bunch of weird data
**\<moneromooo>** They did.
**\<dEBRUYNE>** sgp\_: Lots of people are opposed to parsing though, I don't think that is going to find consensus
**\<rehrar>** alright well, anything else to say on this topic?
**\<rehrar>** we can continue in the issue
**\<dEBRUYNE>** rehrar: In general I am kind of ambivalent, I think we can achieve a lot by removing all functionality from the software
**\<sgp\_>** dEBRUYNE: I understand, I just personally think there is some middle ground that doesn't need to include full tx\_extra. I think we've exhausted this topic for now
**\<dEBRUYNE>** Currently, we removed it, but it is easily to reenable
**\<sgp\_>** \*full tx\_extra removal
**\<luigi1111>** instead of command line, move to compile time
**\<dEBRUYNE>** Next step could be that they need to add code theirselves for payment ID support
**\<hyc>** VARIANT\_TAG(binary\_archive, cryptonote::tx\_extra\_merge\_mining\_tag, TX\_EXTRA\_MERGE\_MINING\_TAG);
**\<rbrunner>** But the code would be missing at the people's systems, where the exchanges could not get it in again
**\<hyc>** if tx\_extra is needed to support merge mining then removing it is kinda out of the question, no?
**\<dEBRUYNE>** rbrunner: Yes, that as well
**\<dEBRUYNE>** But there may be some third party wallets that retain support
**\<rbrunner>** As long as they don't threaten to fork and come up with MoneroLPID (long payment id variant) ...
**\<rehrar>** alright, let's go ahead and move along
**\<rehrar>** there is also discussion blocked out for this meeting
**\<rehrar>** but we talked about it a bit, and I don't see any MRL people here
**\<hyc>** seems like there are a lot of current valid uses for tx\_extra, so you can't remove it outright
**\<rehrar>** still want to discuss, or table?
**\<hyc>** CLSAG can wait for next meeting I think
**\<rehrar>** ok
**\<rehrar>** any additional items?
**\<hyc>** surae is busy taking care of konferenco now anyway
**\<rehrar>** code/ticket discussion?
**\<moneromooo>** Anyone else than hyc wants to review share-rpc ? :)
**\<moneromooo>** Or even use it as backend to add pay-for-downloading-torrents or whatever.
**\<rehrar>** I lack the skills :)
**\<rehrar>** \*:(
**\<rehrar>** alright everyone, I think we can call it here
**\<rehrar>** two weeks from now?
**\<rehrar>** thanks for coming! have a good couple weeks.

181
_posts/2019-06-17-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-06-17.md Normal file
View File

@ -0,0 +1,181 @@
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2019-06-17
summary: Surae work, Sarang work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / sarang
---
# Logs
**\<sarang>** GREETINGS
**\<parasew[m]>** hello!
**\<sarang>** So much happening this week...
**\<sarang>** suraeNoether: care to go first with your roundtable? Although I can probably guess what it'll be =p
**\<suraeNoether>** yeah, just konferenco stuff this week
**\<suraeNoether>** getting banners printed, etc
**\<sarang>** super excited
**\<suraeNoether>** there are THREE free volunteer tickets available for Konferenco
**\<suraeNoether>** you just need to DM @moneroKon on twitter to set it up
**\<sarang>** Take a look at banner, Michael!
**\<suraeNoether>** exchange 6 hours of work-ish time for a free ticket to this killer event :D
**\<suraeNoether>** Basically everything is coming crashing toward us like a freight train, but we have had everything set up and waiting for its arrival for a few weeks. working with sgp on streaming and video, etc. etc.
**\<suraeNoether>** we were originally going to record the whole thing and put it on youtube, but sgp is rigging up a livestream for us, which is fantastic and saving us a few grand on A/V costs
**\<sarang>** sounds... grand
**\<suraeNoether>** other than that, i'm more here to answer questions today. i've been doing light reading for research, including piratechain and nipopow and re-reading omniring, but my productivity is going toward monkon right now
**\<sarang>** cool
**\<suraeNoether>** and to take some marching orders from sarang re: omni
**\<sarang>** heh
**\<suraeNoether>** and the comparative analysis paper mooo mentioned
**\<sarang>** Any questions for suraeNoether?
**\<sarang>** Now is a good time for Konferenco questions probably
**\<sfhi>** Is the livestream from Monerokon going to be via Youtube?
**\<suraeNoether>** i believe that is the case, yes
**\<sarang>** Where will be the best place for non-attendees to get information about streams and videos and relevant links?
**\<sarang>** Here? r/Monero?
**\<suraeNoether>** the joint panel with zcon1 will be streamed by them, and i'm not sure which outlet they'll be using for that; i'm 99% sure they are also using youtube
**\<sfhi>** From awareness perspective, youtube is certainly the best platform to gain views, assuming the video and audio quality are good of course
**\<sfhi>** Okaya great
**\<suraeNoether>** sarang absolutely, we'll be throwing more information up into the Monero Konferenco general megathread on reddit, including links to the streaming talks. hopefully some folks will be livetweeting and liveredditing (is that... is that a thing?) and linking to the videos
**\<sarang>** Will slides be posted?
**\<sarang>** (for those presenters who choose to / have the rights to)
**\<sfhi>** sarang: Yeah, good question!
**\<suraeNoether>** i believe sgp is currently working on rigging a way to actually integrate them with the stream, not merely post slides after the talks
**\<sarang>** Neat... would still be nice to have posted too
**\<sarang>** esp. for things like charts/plots
**\<suraeNoether>** yes, i just need to seek permission from each speaker, which I will be doing when I start receiving their slides
**\<sarang>** Cool!
**\<sarang>** I like how BPASE did it, where they add links to the schedule
**\<sarang>** Keeps it all easy to find
**\<suraeNoether>** yeah, i liked that, too
**\<suraeNoether>** in fact, i really hate the monkon website, but that's a problem for next year I think. :P
**\<sarang>** Definitely a table view for schedule next time
**\<sfhi>** Currently there are 46 student, 126 general and 43 platinium tickets left. Does anyone remember what was the original amount for each?
**\<sarang>** or a more integrated platform for it
**\<suraeNoether>** sfhi the venue has a capacity of 280, but i dont' recall exactly how many tickets i made available in each category. I \*think\* it was 50 for students and platinum and 150 for general
**\<suraeNoether>** but i'm also having inventory issues with our backend and we have sold (a few) more tickets than are reflected there
**\<suraeNoether>** i believe our attendance will be around 110 after we count speakers and sponsors
**\<sfhi>** Alright thx, it seems that it just now that people are getting active and buying tickets (no surprise there)
**\<sarang>** Not too shabby for a first run!
**\<nioc>** could be wrong but it may have been 200/50/50
**\<sfhi>** Okay
**\<suraeNoether>** nioc that sounds more accurate and is closer to the numbers i'm seeing in my guest list.
**\<sfhi>** Cannot attend personally, but very much looking forward to the livestream :)
**\<sarang>** Any other questions for suraeNoether?
**\<suraeNoether>** (one of my action items for AFTER the konferenco will be to make a post mortem, including financials, media outreach, stuff like that, so that next year 1) we can decentralize the thing so more people are working on it and 2) we can learn our lessons, etc, and make the second annual more of a splash.
**\<suraeNoether>** but to be honest: i'm freaking thrilled at the attendance
**\<sarang>** I've been working on a few things this week, all of which were action items for me
**\<sgp\_>** That will be very useful
**\<sarang>** First was getting my MonKon presentation done... very excited to share data on how our transactions have changed over time for efficiency
**\<parasew[m]>** sgp\_ has been posting on meta to use the "frab" system for monero conferences and events in the future. i can highly recommend it, have been using it for the CCC and for other events already. imho something to look for in a longer term.
**\<sarang>** I finished an analysis of the Lelantus transaction protocol, which now includes prototyping code for Monero-to-Lelantus output migration
**\<sarang>** https://github.com/SarangNoether/skunkworks/blob/lelantus/lelantus/analysis.md
**\<sarang>** Spend (i.e. not mint or migration) transactions are around 3-4 kB, plus ring representation
**\<suraeNoether>** sarang, good job on that lelantus report
**\<sarang>** Verification for a 2-2 txn is ~34 ms... and a batch works out to ~13 ms/txn
**\<suraeNoether>** when you say "plus ring rep" do you mean "not including ring rep?" or do you mean "and that includes ring rep?"
**\<sarang>** not including
**\<sarang>** because that depends how it's done
**\<suraeNoether>** is the improvement in verf time due to batching dependent on the number of txns being batched?
**\<sarang>** Big giant scary caveat: every spend requires a churn
**\<suraeNoether>** ^ important
**\<sarang>** suraeNoether: yes, of course
**\<sarang>** Many multiexp generators are shared
**\<suraeNoether>** so when you say the batch works out to 13 ms/txn... oh that's per txn
**\<sarang>** so the cost is amortized across all proofs for these generators
**\<suraeNoether>** \*hits forehead\*
**\<sarang>** I assume batched txns do \_not\_ share ring members
**\<suraeNoether>** so that's room for increased speed, too
**\<sarang>** btw those numbers are for 128-rings
**\<suraeNoether>** can you give us some intuition about what about the lelantus protocol requires the churn? is it the key image?
**\<sarang>** Increasing to, say, 1024-rings bumps the batch ver time to ~80 ms each
**\<sarang>** Well, serial numbers for the commitments
**\<sarang>** Those are revealed at spend time, and the original sender knows it too
**\<sarang>** A churn is required so that sender no longer knows the serial number at next spend tiem
**\<suraeNoether>** sarang, do you mind if i publicly share the report you just publicly shared?
**\<sarang>** Yes, but... all the data contained therein has \_not\_ been verified by anyone else
**\<sarang>** and in fact, I'd like one of your action items, suraeNoether, to be checking my math
**\<sarang>** It's possible there are glaring problems with it
**\<suraeNoether>** want me to do checking before i share it, then, instead of the other way around? :P
**\<sarang>** Up to you!
**\<sarang>** I have been working with one of the Omniring authors to do the same analysis for that construction
**\<sarang>** that is not finished
**\<sarang>** Finally, moneromooo has taken my CLSAG code and fully integrated it into a branch for testing
**\<sarang>** moneromooo and I got it working for multisig and tweaked things a bit for non-malleability
**\<sarang>** https://github.com/moneromooo-monero/bitmonero/commits/crash
**\<sarang>** I am currently soliciting auditors for that code... no word yet
**\<suraeNoether>** yay!
**\<suraeNoether>** that's super exciting, sarang and moneromooo !
**\<moneromooo>** (it'll be in a separate branch for review, it's just in crash for convenience for now)
**\<sarang>** roger
**\<rehrar>** may I ask a question/make a suggestion for MRLs consideration?
**\<sarang>** As far as ACTION ITEMS go, mine is to complete the Omniring review, which will be a good check against the authors, who are doing the same
**\<sarang>** rehrar: sure
**\<rehrar>** Sorry if I'm dropping this at a poor time, but I am about to leave for something.
**\<sarang>** np
**\<rehrar>** One of the big issues we have had in the past with regards to definitive statements on privacy/fungibility is the fact that the "adversary" is always poorly defined.
**\<sarang>** Yes, because formalizing it is very tricky when done precisely
**\<rehrar>** Threat models are vast and varied, and so making a blanket statement about Monero's abilities to protect is fool hardy, and would lead to some believing it would help them when it wouldn't or ice versa
**\<rehrar>** But not doing anything about this leaves us floating in a strange limbo like state where no claims are made, except for the ambiguous ones like "private digital money"
**\<rehrar>** my suggestion is for the MRL to put out a bulletin or paper or whatever, where there common threat models are chosen (of varying severity), along with some assumptions about the adversaries in those models.
**\<sarang>** Yeah, this has been brought up a few times
**\<rehrar>** And Monero's ability to protect and keep things private is held against these three standards.
**\<sarang>** Part of me cringes every time, because you end up making such specific threat models
**\<suraeNoether>** it's worth noting, rehrar, that formalizing "the adversary" for ring confidential transactions is an active area of research. one of the reasons omniring is interesting (and one of ruffing's previous prints with a sublinear scheme) is that they were able to formalize a variety of threat models that had not yet been formalized
**\<rehrar>** At the very least, this gives us something to point to
**\<Isthmus>** I would be happy to contribute toward "an incomplete list of adversary models"
**\<sarang>** The big issue is external data
**\<sarang>** We can prove all sorts of things within the cryptography itself
**\<sarang>** but throw in things like "my ISP and my exchange are in contact with the government" and all the formal analysis falls apart
**\<rehrar>** sarang: right, but we don't know the extent of power the ambiguous "threat" has
**\<rehrar>** still, despite this, I see projects like tor and I2p have stated threat models that they will defend against, with "no guarantees" for anything else
**\<suraeNoether>** rehrar tor and I2p have literal security definitions to compare against
**\<rehrar>** and I would like to see Monero, being a respectable privacy project like it is, have something similar
**\<suraeNoether>** that's after several decades of research into private networking
**\<suraeNoether>** and mixnets, and so on
**\<rehrar>** hmmm...I see
**\<suraeNoether>** in one sense, what you are describing is exactly our job at MRL
**\<suraeNoether>** it just may take a \*loooong\* time
**\<rehrar>** well this perspective is helpful then
**\<suraeNoether>** in fact, some of the security models in the omni paper are relevant here
**\<suraeNoether>** and one of my security models in my ongoing churn analysis is also relevant
**\<sarang>** Yeah, you're taking many layers (signature schemes, proof of work, network layer, communication between colluding adversaries, graph analysis) and throwing them all together
**\<suraeNoether>** compiling a comprehensive source for all this? very important work. but ...
**\<suraeNoether>** but you are right: we should start collecting our security assumptions in a common and easily referenced locations so that we can point to them later
**\<suraeNoether>** having anything in this regard is going to be better than completely ignoring it and being vague
**\<sarang>** Still, I agree that it's good to think about. Part of why we did Breaking Monero was to try to peel apart some of these threats and explain them
**\<suraeNoether>** ^ \*nod\*
**\<rehrar>** I see. Thank you for the explanation.
**\<rehrar>** I do see the gigantic difference between Tor and Monero fwiw
**\<rehrar>** Tor is just networking/mixnet stuff, and that's just ONE FACET of Monero's security stuffs
**\<rehrar>** anyways, just thought I'd pop that out for consideration (again, evidently)
**\<sarang>** A very good topic to keep in mind, though
**\<rehrar>** thank you for entertaining me in this matter. :)
**\<rehrar>** have to split. Carry on.
**\<sarang>** thanks rehrar, see ya
**\<sarang>** My action items, besides giving a kickass MonKon talk, will be to continue Omniring analysis much in the same way that I did for Lelantus
**\<sarang>** and to continue further review of the code in moneromooo's branch
**\<sarang>** additional eyes on it, especially for multisig, would be welcome
**\<sarang>** Also a huge thanks to everyone who supported my CCS funding request, either financially or in spirit
**\<suraeNoether>** i'll review those numbers to the best of my ability today after I get back from a few printshops (banners and stuff)
**\<suraeNoether>** OH GOD THE CCS
**\<sarang>** ty suraeNoether
**\<sarang>** Speaking of action items... what are yours, suraeNoether? :D
**\<suraeNoether>** my action items are to write my research report for the past 90 days, request my funding for the next 90 days, to put on this conference, to review sarang's numbers, and to finally submit the thring signature paper to a peer-reviewed journal
**\<sarang>** Were there any questions on my work the past week?
**\<sarang>** (forgot to ask)
**\<suraeNoether>** in the past 6 months, MRL has put out 3 signature papers (thring sigs, clsag, dlsag), is hosting a conference, has attended two workshops, has had a public presence at MCC, and has put out several episodes of breaking monero. this has been a good couple of months. good job sarang, good job sgp, good job isthmus, good job moneromooo, and everyone else who has contributed
**\<sarang>** Plenty more to do :/
**\<sarang>** but that's the point of research :D
**\<sarang>** OK, anything else to cover before we formally adjourn?
**\<sarang>** going once
**\<suraeNoether>** OH OH
**\<suraeNoether>** i think i mentioned it but i'll say it again
**\<suraeNoether>** we have a few FREE volunteer tickets for konferenco. trade 6 hours of volunteer work checking people in and setting up tables, come to konferenco for free! DM @monerokon on twitter.
**\<suraeNoether>** aaand now i'm done
**\<Isthmus>** My action items are just finishing up slides and trying to not miss my flight
**\<sarang>** heh, nice!
**\<sarang>** OK, going twice...
**\<Isthmus>** Ooh and brainstorming about incomplete adversary list
**\<sarang>** going thrice...
**\<sarang>** Adjourned!