Skip to content
GitLab
Unverified Commit 6722b832 authored by luigi1111's avatar luigi1111 Committed by GitHub
Browse files

Merge pull request #512 from dEBRUYNE-1/master 

Meeting Logs - Dev Meeting (2017-12-03), Community Meeting (2017-12-09), and Monero Research Lab Meeting (2017-12-11)
parents 54b24ec4 4c059ae9
Show whitespace changes
Inline Side-by-side
_posts/2017-12-03-overview-and-logs-for-the-dev-meeting-held-on-2017-12-03.md 0 → 100644
View file @ 6722b832
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2017-12-03
summary: Discussion of open PRs and issues, Bulletproofs, Monero Research Lab, RNGs, 0MQ, and miscellaneous
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
---
# Overview
An overview can be found on [MoneroBase](https://monerobase.com/wiki/DevMeeting_2017-12-03).
# Logs
**\<fluffypony>** 1. Greetings
**\<fluffypony>** 2. Brief review of what's been completed since the previous meeting
**\<fluffypony>** 3. Code + ticket discussion / Q & A
**\<fluffypony>** 4. Any additional meeting items
**\<fluffypony>** 5. Confirm next meeting date/time
**\<fluffypony>** so 1. Greetings
**\<fluffypony>** hi
**\<ArticMine>** Hi
**\<fluffypony>** luigi1111 (if you're back) / smooth / hyc / moneromooo etc.
**\<moneromooo>** here
**\<gingeropolous>** etc here
**\<fluffypony>** 2. Brief review of what's been completed since the previous meeting
**\<fluffypony>** lots of stuff
**\<sarang>** MRL has working Java test code for complete multi-output bulletproofs
**\<sarang>** It's being ported over to C++
**\<moneromooo>** (not the multi output one)
**\<sarang>** The Java part is complete
**\<moneromooo>** Sorry, I meant just about the port ^\_^
**\<sarang>** Discussions are ongoing about if/how the fee structure would be modified to prevent large-output txn DoS
**\<fluffypony>** what's wrong with per-byte fees?
**\<sarang>** You can load a txn with tons of outputs
**\<sarang>** but verification is linear in the # of outputs
**\<dEBRUYNE>** fluffypony: verification is linear, whilst size is log
**\<dEBRUYNE>** basically
**\<sarang>** So for low fees you can force the network to verify
**\<fluffypony>** ah ok, makes sense
**\<sarang>** So we need to incentivize the use of aggregate BPs while basically scaling the fee to the number of outputs etc.
**\<sarang>** But things are looking good
**\<sarang>** Verification is still quite efficient
**\<sarang>** and with the multi-output setup, space savings are unreal
**\<moneromooo>** In fact, the per byte fee needs to be done first, as per kB is way too coarse for this.
**\<sarang>** Yeah a single output BP is about 704 bytes, while a 2-output BP is something like 768 bytes
**\<sarang>** (including commitments)
**\<sarang>** it's just too damn good
**\<fluffypony>** nice
**\<dEBRUYNE>** For clarification, a single output is currently \~ 6 kB, whereas a 2-output is \~ 12 kB
**\<* hotoatmeal** was about to ask
**\<sarang>** So we'll continue moving forward with porting and testing
**\<manifest>** serhack here?
**\<dEBRUYNE>** A typical Monero transaction has 2 ins + 2 outs
**\<serhack>** yep manifest
**\<manifest>** i was wondering who was the m8 that was gonna work on the go-library since i started on it myself a little bit swell
**\<fluffypony>** dEBRUYNE: this would also be a major cost-saving for pool payments
**\<fluffypony>** manifest: we're in a meeting
**\<sarang>** For reference, the size of an M-output BP is 32\*(2\*log(64\*M)+9) bytes (this doesn't count the amount commitments)
**\<sarang>** add 32 bytes for each of the M amount commitments if you want to include them
**\<sarang>** (log is base 2)
**\<rehrar>** manifest you can hop on mattermost.getmonero.org. Serhack is also there and you guys can PM and chat so as not to disrupt the meeting. Thanks. :)
**\<ArticMine>** I have to give some thought to the fees to deal with the verification issue
**\<fluffypony>** ok so beyond BP is there anything else worth noting?
**\<sarang>** We do require a power of 2 in the # of outputs
**\<pigeons>** So sometimes you just create an additional change output, or how do you cause always a power of 2?
**\<sarang>** We'll need to either pad with dummy outputs or split into power-of-2 proofs
**\<ArticMine>** Split the change into two tx
**\<pigeons>** OK
**\<sarang>** The dummy output doesn't need to actually represent anything
**\<sarang>** It just needs to be there for the proof
**\<sarang>** It can be amount 0
**\<ArticMine>** that will work also
**\<sarang>** Anyway, that's my 3 cents
**\<luigi1111>** Better to split
**\<luigi1111>** Space is cheap gp
**\<luigi1111>** Cpu is expensive\*
**\<ArticMine>** We will have to price cpu
**\<moneromooo>** There's a possible optimization for "filler" outs AIUI.
**\<luigi1111>** Probably not as good as not using them :)
**\<sarang>** There aren't any security proofs for a non-power-of-2 proof
**\<moneromooo>** I was led to think it was not inherent in the scheme, though ?
**\<sarang>** It is
**\<moneromooo>** aw...
**\<sarang>** At least for right now
**\<sarang>** There's a recursive step that split arrays in half
**\<ArticMine>** The issue I see is that the penalty only prices space
**\<sarang>** The authors of the paper are looking into a generalization, but it doesn't exist yet
**\<luigi1111>** That's interesting
**\<fluffypony>** ok so
**\<fluffypony>** anything else from the last two weeks worth noting?
**\<sarang>** suraeNoether is completing review for multisig
**\<sarang>** He is unable to be here today
**\<Gdhhyfjjs467>** Has a code freeze date for the next for been set yet?
**\<fluffypony>** Gdhhyfjjs467: yeah we'll be branching towards the end of the month
**\<fluffypony>** assuming our comfort levels are ok
**\<rehrar>** This was discussed briefly in MRL channel with the idea that if BPs are not too far off, would it be worth delaying the next hard fork by a couple months so it can be in?
**\<dEBRUYNE>** The plan is to include multisig right?
**\<dEBRUYNE>** \^ fluffypony
**\<luigi1111>** Yes
**\<fluffypony>** no need to delay the hard fork
**\<luigi1111>** I don't think the upcoming fork does anything useful though
**\<luigi1111>** So there's that
**\<fluffypony>** if BP is ready it'll go into the Sept fork
**\<dEBRUYNE>** Should we fork if there's nothing to fork for?
**\<luigi1111>** Who knows ^\_^
**\<fluffypony>** luigi1111: consistency, then
**\<fluffypony>** well, that's what we committed to with the fork schedule
**\<fluffypony>** "even if it's just bumping the block version number"
**\<dEBRUYNE>** Sure, but didn't we also discuss slowing things down once the ecosystem got bigger?
**\<moneromooo>** We did not commit to an exact fork schedule.
**\<luigi1111>** And who is this we :)
**\<moneromooo>** I, at least, did not :P
**\<hotoatmeal>** does the wallet release schedule track the protocol fork schedule exactly?
**\<hotoatmeal>** or do they have different cadences
**\<moneromooo>** The wallet needs to update for a fairly large subset of consensus changes.
**\<pigeons>** the wallet-cli and wallet-rpc are included with the daemon release that supports the fork
**\<moneromooo>** So it's convenient to release at the same time.
**\<fluffypony>** dEBRUYNE: I don't think we're at a point where we can go to annual
**\<moneromooo>** Besides, the wallet and daemon rely on the same libs.
**\<rehrar>** Isn't ZMQ also in the new release? Or has that been there for a while now?
**\<fluffypony>** yes ZMQ is in the new release
**\<moneromooo>** There's some of it in, but some of it's still missing.
**\<pigeons>** there is some support for zmq over rpc, and more is comming, like tx/block notify and some changes to the existing zmq rpc
**\<pigeons>** \*rpc over zmq
**\<hotoatmeal>** moneromooo: yeah, mainly thinking about when I need to spend time to get those two memwipe patches (and the third I haven't written yet) reviewed/merged
**\<pigeons>** the notify is what the people i hear from are waiting for, and tewinget told me a few weeks ago he's got the basics worked out
**\<rehrar>** Are we still waiting on him for stuff?
**\<moneromooo>** There's a patch waiting on changes IIRC.
**\<moneromooo>** (for 0mq)
**\<rehrar>** *sigh* tewinget, can you please get this stuff done? Seriously.
**\<moneromooo>** Especially as I think some of the large pool speedups were lost.
**\<moneromooo>** (not 100% sure)
**\<hotoatmeal>** is there a way to detect that the network has forked, and your client hasn't gone with it?
**\<moneromooo>** Kinda.
**\<hotoatmeal>** my local daemon got left behind on the last one, because I forgot to update
**\<fluffypony>** you can make an educated guess
**\<hotoatmeal>** cue colorful headscratching
**\<moneromooo>** Current daemon should moan if it sees blocks with a higher version than what it knows about.
**\<fluffypony>** and there's auto-update records that notify
**\<moneromooo>** The block verison thing is a bit vulnerable to someone mining a bad block on purpose to make you think there's been a fork though.
**\<fluffypony>** yeah
**\<moneromooo>** Losing 10 monero in the process or whatever it is :)
**\<fluffypony>** ok let's move it along, then
**\<fluffypony>** 3. Code + ticket discussion / Q & A
**\<fluffypony>** are there any issues that could do with some input / resolution?
**\<moneromooo>** The handful of oldest ones.
**\<moneromooo>** The PRNG one.
**\<moneromooo>** ones.
**\<moneromooo>** For multisig, I think it's pretty much ready to go in, stoffu's done a lot of careful reviewing.
**\<fluffypony>** ok - what's the blocker on switching to the Bitcoin one?
**\<hotoatmeal>** moneromooo: what still needs doing / deciding on your part of the memwipe ones, and how can I help there?
**\<moneromooo>** Mainly deciding whether we want to, or not.
**\<moneromooo>** And bitcoin has two RNGs, the one I ported, and one that's closer to what we have. so there's the possibility of entropy attrition using only the "good" one.
**\<moneromooo>** hotoatmeal: the only thing left IIRC was switching from std::vector\<char> to std::unique\_ptr\<char[]> and I feel more confident getting it right with vector.
**\<moneromooo>** Other than that, nothing I think.
**\<fluffypony>** moneromooo: by "good" one you mean the ported one?
**\<moneromooo>** That can be done later by someoine who's familiar with how the refcounting works with operators though.
**\<moneromooo>** Yes. The one that uses getrandom, etc.
**\<fluffypony>** ok so I think if they haven't hit entropy attrition problems over the past few years it's unlikely we will - thoughts?
**\<moneromooo>** Let me rephrase:
**\<moneromooo>** Bitcoin has two RNGs: a good one using HW, and a... hmmm, less good ? one similar to our keccak based one
**\<moneromooo>** Using the keccak based one does not deplete entropy nearly as fast as using the good one. Monero can use a lot of entropy (eg, range proofs).
**\<moneromooo>** Therefore, I'm wondering whether using the good one all the time is worse than not.
**\<hotoatmeal>** moneromooo: ok, I'll pick up the vector vs unique\_ptr part of that later this month
**\<moneromooo>** Thanks
**\<fluffypony>** ok so what if we used the good one for critical stuff like privkey generation
**\<fluffypony>** and output selection
**\<hotoatmeal>** and if you give me some pointers, can look at whatever that refcounted operators thing is in Jan
**\<fluffypony>** and the stream one for range proofs
**\<moneromooo>** Well, if I knew that, I'd know the answer to my question, since they're opposites.
**\<moneromooo>** Anyway, to go back to multisig, I tihnk it's good to go now. If you haven't yet reviewed it, and want to do so, do so now.
**\* hotoatmeal** drops out
**\<fluffypony>** ok
**\<fluffypony>** 4. Any additional meeting items
**\<moneromooo>** When do we want bulletproofs on testnet ?
**\<dEBRUYNE>** Tomorrow!
**\<fluffypony>** hah hah
**\<moneromooo>** A day may be a bit short to get people to update in time.
**\<fluffypony>** are we going to wait for the multi output stuff?
**\<sarang>** I think we should
**\<moneromooo>** Not sure. This is not quite finished (multiple of 2 requirement), and has a non trivial impact on fees.
**\<sarang>** Hrmm true, the fee thing
**\<sarang>** :/
**\<moneromooo>** And I'd really, really like to get smaller txes double plus quick.
**\<fluffypony>** ok so how would this work
**\<ArticMine>** A lot of people do
**\<sarang>** In case it's relevant, every single-output proof is still a valid multiproof
**\<moneromooo>** That's nice.
**\<sarang>** (provided we define the Gi and Hi in the same order)
**\<sarang>** (not sure if my extended code addressed that, will check)
**\<moneromooo>** So, no clear votes for or against. Except me ^\_^ so that's 100% of expressed votes :P
**\* sarang** checks the math on that
**\<fluffypony>** moneromooo: I asked how it would work
**\<moneromooo>** The fork ? I imagine similar to rct. Allow bulletproofs at fork f, optionally disallow borromean at f+1.
**\<moneromooo>** (the code currently does not do that second part)
**\<moneromooo>** That might become a bit more complicated if we start allowing aggregated proofs at f+1.
**\<moneromooo>** But not very much.
**\<dEBRUYNE>** so moneromooo, you'd like to start with single output right? And then eventually switch to multioutput
**\<moneromooo>** Yes.
**\<rehrar>** Sorry if this was answered, but is there an ETA on multioutput port from Java?
**\<moneromooo>** No. It doesn't appear to be a lot of work though.
**\<fluffypony>** so then txs with more than 1 output would use borromean?
**\<moneromooo>** No. They'd use two bulletproofs.
**\<sarang>** yup
**\<rehrar>** Which is still a savings.
**\<sarang>** Still great space savings
**\<sarang>** And no DoS issues
**\<dEBRUYNE>** 2 bulletproofs is 1.3 kb give or take right?
**\<fluffypony>** ok
**\<dEBRUYNE>** And we can keep our current fee structure
**\<sarang>** dEBRUYNE: yes
**\<moneromooo>** Most of it, in fact. Txes are ~2.2 kB.
**\<rehrar>** I think that's worth it. And then it can be enhanced even further with multioutput later. But the immediate savings would be appreciated.
**\<rehrar>** And gives time for the fee dislogue
**\<fluffypony>** and what's our confidence level like in this? like is it March-fork-worthy?
**\<rehrar>** Dialogue\*
**\<moneromooo>** Well, we can know better if we fork in a couple days on testnet :)
**\<ArticMine>** I have an idea on the fee issue
**\<rehrar>** It can be deployed to testnet asap no.
**\<rehrar>** ?
**\<moneromooo>** That's what I'm asking about, yes.
**\<fluffypony>** could we fork testnet this coming weekend?
**\<moneromooo>** Works for me. Gives time for review.
**\<rehrar>** Exciting!
**\<sarang>** Yes and the code should definitely be reviewed by others
**\<endogenic>** who?
**\<endogenic>** if you had your pick
**\<JollyMort[m]>** could someone do me a favor and send me the log of this channel from 2017-04-18?
**\<sarang>** Ideally andytoshi since he's a paper author
**\<moneromooo>** If I had my pick...
**\<sarang>** suraeNoether
**\<fluffypony>** Satoshi
**\<endogenic>** fluffypony: on it
**\<sarang>** Someone who digs the maths
**\<Gdhhyfjjs467>** So Evan duffield?
**\<dEBRUYNE>** luigi1111 I guess
**\<endogenic>** vtnerd hyc fyi
**\<moneromooo>** Oh yeah, luigi1111 is a good one.
**\<rehrar>** Let's just get all hands on deck for this?
**\<endogenic>** ok that means you too rehrar
**\<Gdhhyfjjs467>** Lol jk. I like andytoshi idea
**\<sarang>** I'm sure we'll find additional optimizations... I know for a fact my implementation of scalar operations into vectors could be refactored
**\<rehrar>** I will understand none of it, but I'll look at it and either nod approvingly or cringe based on a coin toss.
**\<sarang>** but I didn't in Java in order to keep it clean and understandable
**\<endogenic>** i move to instate rehrar as new RNG
**\<moneromooo>** The slice op ? Yes, but I don't think it takes much time compared to the muls.
**\<sarang>** Random Nod Generator?
**\<sarang>** Well and operations involving many vector ops could run a single loop per element, instead of per operation
**\<sarang>** but they're generally fast and it makes things clean
**\<sarang>** I'm not a huge fan of sacrificing clarity for a tiny speedup
**\<sarang>** I'd like to chat with moneromooo post-meeting about our basepoint selection, to ease the transition into multiproofs later
**\<sarang>** For those who want to compare code to paper, this is the paper: http://web.stanford.edu/~buenz/pubs/bulletproofs.pdf
**\<moneromooo>** I pushed the patch as 2883 if people want to start reviewing ^\_^
**\<rehrar>** Can I make a Reddit post calling devs to review it?
**\<moneromooo>** Reddit.. devs ?
**\<dEBRUYNE>** \^ that lol
**\<rehrar>** :P nvm then
**\<dEBRUYNE>** The people able to review it will be watching Github
**\<endogenic>** rehrar: answer is in the question :P
**\<fluffypony>** oh
**\<fluffypony>** I guess meeting ~done
**\<fluffypony>** 5. Confirm next meeting date/time
**\<fluffypony>** Sunday the 17th
\ No newline at end of file
_posts/2017-12-09-logs-for-the-Community-meeting-held-on-2017-12-09.md 0 → 100644
View file @ 6722b832
---
layout: post
title: Logs for the Community Meeting Held on 2017-12-09
summary: Community highlights, Forum Funding System updates, RFC-HWALLET-1, Monero video series, Malware Response Workgroup, and miscellaneous
tags: [community, crypto]
author: dEBRUYNE / fluffypony
---
# Logs
**\<sgp>** Thanks everyone for waiting
**\<sgp>** 0. Introduction
**\<sgp>** We would like to welcome everyone to this Monero Community Meeting!
**\<sgp>** Link to agenda on GitHub: https://github.com/monero-project/meta/issues/141
**\<sgp>** Monero Community meetings are a discussion place for anything going on in the Monero Community. We use meetings to encourage the community to share ideas and provide support.
**\<sgp>** I have a presentation at noon, so this meeting will be a little shorter than normal. You are welcome to carry on the open ideas time even after I need to leave.
**\<sgp>** 1. Greetings
**\<cryptochangements>** hola amigos
**\<serhack>** Hello
**\<brendanmcmanus>** hey all!
**\<ErCiccione>** Ciao everybody
**\<msvb-fab>** Hello folks.
**\<sgp>** 2. Community highlights
**\<sgp>** For a great weekly summary, please read the Monero Observer: http://monero-observer.com/
**\<sgp>** 3. FFS updates
**\<sgp>** a. RFC-HWALLET-1 project progress
**\<sgp>** @msvb-fab, you have the floor
**\<rehrar>** Hi
**\<ajs>** Hello
**\<ArticMine>** hi
**\<fluffypony>** ola
**\<msvb-fab>** Oh okay.
**\<xmr\_eric>** Hullo
**\<msvb-fab>** Hardware wallet.
**\<msvb-fab>** Dozens of parts have arrived including panelized PCBs, and some unplanned holiday goodies.
**\<msvb-fab>** We'll be assembling in the next week, in order to deliver a end of year dividend to anybody who has contributed in even the smallest way.
**\<msvb-fab>** Consider this the last chance to sign up as a tester and complete the one minute of duties required to receive the first ever Monero hardware wallet prototype.
**\<msvb-fab>** Our star designer in this round is i\_a, who created the 'Julian Candy' release seen here:
**\<msvb-fab>** https://taiga.getmonero.org/media/attachments/8/3/9/3/164be48259ead3bc4127f70a5c85bae7edf39227413cd0cef260b6ca1b4e/julianpanel-2.jpeg
**\<msvb-fab>** But as you see from our main page, there are other parallel efforts as well:
**\<msvb-fab>** https://taiga.getmonero.org/project/michael-rfc-hwallet-1-implementation/
**\<msvb-fab>** To become a tester and get a board, I need your mailing address and a couple other 1 minute things. If you have 5 minutes, then read:
**\<msvb-fab>** https://taiga.getmonero.org/project/michael-rfc-hwallet-1-implementation/wiki/preview/
**\<msvb-fab>** We also had our first Monero hardware team meeting this week on #monero-hardware.
**\<msvb-fab>** ...which went well for a first try. One hour long, we'll probably do one per month.
**\<msvb-fab>** That's all unless other members of the Monero hardware team want to inform...?
**\<ErCiccione>** msv-fab: the prototype only for americans, right? :(
**\<msvb-fab>** ErCiccione: Heh? Actually we are three assemblers and all in different european countries.
**\<serhack>** why americans Erciccione?
**\<msvb-fab>** So all the south and north americans are lucky to get something.
**\<sgp>** Thanks msvb-fab
**\<msvb-fab>** This is universal, even for folks in the ISS space station they can get a prototype.
**\<ErCiccione>** uh, really? i didn't subscrive because i was sure was only available in america. my bad, you have a new tester :)
**\<msvb-fab>** Doesn't have to be planet earth.
**\<sgp>** lol
**\<sgp>** b. Monero Video Series
**\<sgp>** We would like community comments on the final community script: https://github.com/alvinjoelsantos/promo-video/blob/master/community.md
**\<sgp>** Please make comments on GitHub.
**\<ErCiccione>** don't know why but i was absolutely sure :P
**\<msvb-fab>** I'm on site at a fabricator right now cutting enclosure pieces, so please let me take a 5 minute break to adjust the laser okay?
**\<sgp>** Let's make this video as good or better than the other ones
**\<sgp>** c. Monero Meetup Kit
**\<msvb-fab>** I'll be back in five minutes...
**\<serhack>** I think monero video need translators for subtitles
**\<sgp>** @serhack yes it does. Speak with ErCiccione after the meeting about these
**\<ajs>** If you have any suggestions for script, PR welcomed.
**\<serhack>** great, sgp
**\<sgp>** I have finished all the milestones for the Meetup Kit. I will give the last of my stuff out during a meeting in Madison that starts in 40 mins
**\<sgp>** Does anyone else have a FFS update?
**\<serhack>** We are working hardly on Opencart.
**\<serhack>** you can go on sgp
**\<msvb-fab>** serhack: Working hard or hardly working?
**\<serhack>** Working hard\*
**\<sgp>** Great to hear
**\<sgp>** 4. Discuss formation of Malware Response Group
**\<sgp>** Fluffypony and tuckerpreston asked me to reserve some time to discuss the response to malware and botnets.
**\<fluffypony>** ok
**\<fluffypony>** so
**\<fluffypony>** this is really an optics problem
**\<sgp>** Fluffypony, welcome!
**\<fluffypony>** basically the issue of poor optics with relation to Monero is going to be an increasing challenge
**\<fluffypony>** some areas we don't have much influence / control over
**\<fluffypony>** but with malware there is something we can do
**\<fluffypony>** we can help people who are infected with malware
**\<fluffypony>** so when someone has found a malicious miner, for instance, what can they do about it?
**\<fluffypony>** well, a Malware Response Group can help that person
**\<fluffypony>** they can provide them with a guide to clearing out the malware
**\<dEBRUYNE>** Perhaps write a guide that shows how to remove malware and alternatively explains how to do a fresh OS install
**\<fluffypony>** yes
**\<fluffypony>** however
**\<msvb-fab>** fluffypony: By optics, you mean how people perceive us right? Like regardless of quality, if folks believe Monero is high quality.
**\<fluffypony>** msvb-fab: yes
**\<fluffypony>** so the other thing that happens is that malware can be found in the wild
**\<fluffypony>** and maybe it uses a particular mining pool
**\<fluffypony>** the Malware Response Group can approach that pool's operator and ask them to please block that address
**\<fluffypony>** which his good for the pool, too, because malware has a negative performance impact on pools
**\<serhack>** what will Malware Response group do if a big company has malicious miner?
**\<fluffypony>** serhack: they can do both - help the company figure out how to remove the malware, and try block it at a pool level
**\<serhack>** cool
**\<ArticMine>** It is a start.
**\<ArticMine>** but I am not that optimistic
**\<fluffypony>** ArticMine: it lets us answer the question reporters often ask: "what are you doing about cryptojacking / malicious miners?"
**\<fluffypony>** then we can just point to the existence of the Malware Response Workgroup
**\<ArticMine>** True
**\<sgp>** ArticMine, it's not about stopping all malware. It's about optics and providing some level of help
**\<fluffypony>** whether they are effective or not doesn't matter
**\<serhack>** fluffypony: what do you mean by malicious miners? Coinhive could be a malicious miner.
**\<ArticMine>** Yes this is the problem the gray area
**\<fluffypony>** serhack: yes absolutely, as is botnet malware
**\<xmr\_eric>** The solution doesn't need to be comprehensive. It just needs to address the basics.
**\<msvb-fab>** fluffypony: Is part of the problem that the affected click on 'vulnerability response' and send email to you and Luigi?
**\<msvb-fab>** ...thus overwhelming just a couple security officers?
**\<fluffypony>** msvb-fab: nope, not at all
**\<fluffypony>** this has nothing to do with the VRP
**\<fluffypony>** this is about Monero being used in malware, typically via mining
**\<QuickBASIC>** It's a nice thought, but if the MRW is ineffective at reducing the amount of malware then it's just going to be a big joke.
**\<fluffypony>** but later on also ransomware
**\<fluffypony>** QuickBASIC: how will anyone know if they're effective?
**\<msvb-fab>** I'm imagining what I would do when going to getmonero.org and trying to find an easy way to solve my security problem.
**\<msvb-fab>** I would click 'vulnerability respons' because I don't see anything else related.
**\<fluffypony>** msvb-fab: we're mostly dealing with senior infosec people, they're not dumb enough to do that
**\<msvb-fab>** We're dealing with senior cisos and they can't secure their mining rigs? that's surprising.
**\<QuickBASIC>** My background is in IT support. I've done mostly internal IT for the last several decades... It's anecdotal, but a user that allows their box to be owned by malware to that degree is not going to be able to be assisted in removing their own malware... even if we had a call center full of folks walking them thru it.
**\<fluffypony>** msvb-fab: no no, they're called in to clients who are infected, or they're researchers who find malware in the wild
**\<fluffypony>** QuickBASIC: we're not going to provide assistance at that level
**\<QuickBASIC>** fluffypony: I'll ask you a question to answer your question. How will people know that it IS effective?
**\<fluffypony>** QuickBASIC: this is optics, the very existence of the MRW is enough
**\<ErCiccione>** I agree with QuickBASIC, i see an high possibility of fighting windmill with live support, but create some kind of documentation sound good
**\<QuickBASIC>** I wasn't suggesting we provide assistance at that level.
**\<fluffypony>** we're not providing live support, guys, let's put that idea out of everyone's head right now
**\<fluffypony>** this is almost entirely about how we interact with infosec researchers, and what we can say to reporters
**\<QuickBASIC>** But a couple of guides on a webpage isn't going to *actually* help anyone... It's just window dressing.
**\<ArticMine>** Exactly
**\<sgp>** QuickBASIC: that's literally the point
**\<netg>** i like the idea
**\<ArticMine>** In fact it can make things worse
**\<sgp>** @ArticMine how could it make things worse?
**\<QuickBASIC>** Anyone with the level of competence to understand that they need assistance with removing malware is going to have the knowledge to seek out other resources that already provide that assistance.
**\<ArticMine>** It can give a person wrong advice. There is no we can identify every king of malware based upon Monero
**\<ArticMine>** I had to deal with Malware infected FLOSS that was distributed via Google ads
**\<ArticMine>** It caught a very experienced Windows administrator
**\<fluffypony>** this is the stuff we're fighting against
**\<fluffypony>** https://twitter.com/MalwarePatrol/status/938130889401303040
**\<QuickBASIC>** What happened to the party line "we can't control what people do with Monero". If we start having the appearance of taking ownership of what people do maliciously with Monero, it could be a bad look for the Monero community... i.e. Look they have a Malware workgroup and look how ineffective it is at making all the bad stuff in the world stop happening.
**\<fluffypony>** https://twitter.com/acotino/status/938112236211658753
**\<fluffypony>** https://twitter.com/ostinjohn/status/937735578619170816
**\<ArticMine>** It was on a fresh install of Windows XP
**\<fluffypony>** https://twitter.com/Wayne_Bridgeman/status/936782031933005824
**\<fluffypony>** that's all in the past week
**\<ArticMine>** The infected software was VLC
**\<ArticMine>** I only caught it because of a GPL violation
**\<ArticMine>** I had to reinstall XP in order to connect o Windows server
**\<cryptochangements>** devil's advocate: if we start trying to "combat" malware does that mean we also have to help LE with DNMs since they give us a bad image?
**\<QuickBASIC>** I understand that what you're proposing is supposed to diminish the negative views of Monero in the press, but I think it's the wrong tact... I think positive use cases will outweigh any kind of reduction in peoples view of Monero because of some people choosing to use it for malicious purposes.
**\<ArticMine>** It is a huge problem in FLOSS F-Droid Android apps that are infected with malware and uploaded to goggle play
**\<fluffypony>** cryptochangements: why do you think we don't allow DNM posts on /r/monero ?
**\<msvb-fab>** DNM \=\= ?
**\<fluffypony>** msvb-fab: darknet markets
**\<dEBRUYNE>** fluffypony: fwiw, I remove any thread that somewhat reeks of illegality
**\<fluffypony>** dEBRUYNE: yep I know
**\<cryptochangements>** not allowing people to talk about something!= helping (more or less effectivly) people stop something
**\<netg>** i mean having such a group and educating our own community is by itself positive
**\<netg>** people getting ripped of their xmr by malware are mostly lost for the project
**\<fluffypony>** netg: agreed
**\<ErCiccione>** QuickBASIC and ArticMine have both good points, how can we provide some kind of assistance (at least minimal) but always "at distance"? The group could be the point of contact, but shouldn't give practical solutions (to avoid responsabilities of eventual mistakes) They can provide documentation and other kind of support (like suggesting who to speak with, more info about Monero's technology)
**\<fluffypony>** ErCiccione: we write guides, and we make those guides available
**\<cryptochangements>** i just dont want things to come off as hypocritical if we address one "bad" thing but not another
**\<fluffypony>** the guides are non-specific
**\<netg>** cryptochangements: malware would be an attack against the project (our users)
**\<ArticMine>** The most effective tools I can think of are 1) A resource directory on malware that points to resources on malware removal 2) Having a working group as fluffypony has suggested 3) Aggressive trademark enforcement 4) I know this is controversial moving to a copyleft license
**\<sgp>** I have the meetup and need to run, but please continue this discussion and move to open ideas time if there is some extra time
**\<sgp>** The next meeting will two weeks from today on 23 December at 17:00 UTC.
**\<ArticMine>** 3) and 4) allow us to use existing legal channels to go after the grey / white area
**\<fluffypony>** ok sgp, all I really wanted to do in this meeting as well is find someone to head the workgroup up and run with the idea
**\<ErCiccione>** fluffypony: beside guides, my point is that we should decide how deep the eventual support should be
**\<fluffypony>** so if anyone wants to volunteer please ping me
**\<ArticMine>** I am talking DMCA take downs etc
**\<netg>** ArticMine: bitcoin, debian, tor never needed aggressive trademark enforcement
**\<netg>** and wtf, people doing harm dont respect laws anyway
**\<netg>** no free project needs that
**\<netg>** super lame
**\<ArticMine>** I mean the grey / white area not black
**\<ArticMine>** Actually there has been a DMCA breakdown over Ubuntu against the MPAA
**\<ArticMine>** about 11 years ago
**\<ArticMine>** It was over GPL violations
**\<sgp>** @fluffypony I am happy to work on this
**\<fluffypony>** ok cool
**\<ArticMine>** Matthew Garrett did ti
**\<fluffypony>** so then if anyone else wants to volunteer for the MRW ping sgp :)
**\<ArticMine>** What is interesting is any contributor can do it on their own
**\<ErCiccione>** we have ten more minutes. Open ideas time?
**\<serhack>** sgp what do you think?
**\<ArticMine>** netg when targeting for profit entities and large corps it is not super lame. It is ust a does of their won medicine
**\<ErCiccione>** ok my idea: I'm building a taiga bot, so we will have live updates from taiga on irc, will let know when ready so who needs it can use it
**\<serhack>** my idea: Mastering Monero ebook. https://www.reddit.com/r/Monero/comments/7imsr9/hello_world_mastering_monero_is_coming_soon/ :)
**\<ErCiccione>** (btw i think we still need to define better the MRW team's duties before starting the actual recruiting)
**\<ErCiccione>** If we are considering the meeting over, the discussion about the MRL can restart
**\<msvb-fab>** We still have five minutes left...
**\<msvb-fab>** parasew[m] pablonero[m]: Any action with planning Monero December, what progress has been made in the first week of December?
**\<msvb-fab>** We have quite a nice activities list in December, the Vienna RIAT group (I think that stands for Research Institute of Austria) is hosting.
**\<rehrar>** Msvb, I'll fill out the stuff today soon. :)
**\<msvb-fab>** A number of us will be travelling on Thursday 14 December, and spend the weekend.
**\<msvb-fab>** rehrar: You mean about the RIAT hosted meetings in Vienna?
**\<rehrar>** No. For wallet test.
**\<msvb-fab>** rehrar: Oh, you mean I think... Yes. That's great, thanks.
**\<msvb-fab>** I think the two who know most/best about the Vienna stuff are parasew[m] pablonero[m], so look for them on #monero-ccc for more information.
**\<rehrar>** Sorry for not being here today. Wife graduating. :) If anyone needs something from me, send me a ping.
**\<rehrar>** Will go over log soon.
**\<msvb-fab>** ErCiccione: We can chat about MRW now?
**\<ErCiccione>** ok, i'll do the sgp/rehrar of the situation :D [8] Meeting is over thanks everybody for partecipating!
**\<ErCiccione>** let's talk about MRW now
**\<netg>** what we always should highlight is what, separates monero from the rest of the projects, its is the mindset and strong belief, that an completely anonymous egalitarian cryptocurrencies is strongly needed, by alot of people world-wide, and if existing would improve whole humanity
**\<ErCiccione>** This is what I was talking about with this comment: https://github.com/monero-project/meta/issues/141#issuecomment-350490380). Discussions rarely continue after the meeting. A very participated and important discussion died.
**\<ErCiccione>** fluffypony ^^
**\<fluffypony>** ErCiccione: further discussion about the MRW can happen within the MRW :)
**\<fluffypony>** I unfortunately wouldn't have been able to continue the discussion anyway, I'm busy fixing MyMonero problems
**\<ErCiccione>** sure, but this shows that the problem actually exist. This happened and will happen with other subjects. We need to find a way to optimize and don't cut these discussions
**\<endogenic>** ErCiccione: can't anyone bring up the issue when they want and ping the involved parties?
**\<endogenic>** involved -> interested even
**\<ErCiccione>** that doesn't solve the problem. A discussion flows during a meeting, but if it gets interrupted is gonna be hard to remake the logical processes. Meetings are the place for this kind of discussions, it's psicologically hard to restart this conversations with the same intention, the feeling of "officiality" get lost. this means that another meeting will be necessary to make the discussion official. I don't know if i explained
**\<ErCiccione>** well my point
**\<ErCiccione>** but this is my opinion, if i'm the only one feeling the problem, we can just keep going like this. I still think a lot of time will be wasted though
**\<endogenic>** sorry, what's the problem?
**\<netg>** ErCiccione: monero development isnt super fast anyway, because its based on long-term considerations
**\<ErCiccione>** endogenic: https://github.com/monero-project/meta/issues/141#issuecomment-350487067
**\<endogenic>** no i know ErCiccione
**\<endogenic>** i'll type somethin out
**\<endogenic>** sec
**\<netg>** its a top 10 coin, has a healthy community, is building the first infrastructure and is considered the best contender in its niche
**\<endogenic>** the officiality aspect comes from people agreeing on the existence and importance of a problem… 
**\<netg>** what do you need more
**\<endogenic>** ErCiccione: example then
**\<endogenic>** did you see Jaquee post this? https://www.reddit.com/r/Monero/comments/7ingmi/transferred_3100_usd_to_mymonero_over_4_days_ago/dr01xy2/
**\<endogenic>** i wanted to reply saying that this is a real foss project so someone must do it and if it's not he who will write the code or design the solutions and he still thinks he knows something then it's on him to inspire others to be the hero to solve it
**\<endogenic>** now i would suggest that'd be an example of leadership for him
**\<endogenic>** if i wanted to solve the problem he wanted to solve i'd just make it specific what the issue is, then take it to the people who are working on it, and show them it's real
**\<endogenic>** if they don't think it's an issue then i can tell others "this person didn't think it was an issue"
**\<endogenic>** it's just facts
**\<endogenic>** wonder if that makes any sense?
**\<Jaquee>** endogenic: he posted the same message in several places. i also wrote this answer: https://www.reddit.com/r/Monero/comments/7ingmi/transferred_3100_usd_to_mymonero_over_4_days_ago/dr02f7i/?st=jazoidya&sh=ca6b4e35
**\<ErCiccione>** mmmh I think we went out of track, sorry I didn't explain myself well :) . My point is just: can we make meetings longer so we don't cut out important conversations? I think this is more about the conception each of us has of the meeting. For me all formal discussions should be done during meetings. But this is how I'm used to for my personal experience. if it's not perceived as a problem. Ok, fine for me :D
**\<endogenic>** ErCiccione: have you ever heard the theory about how widening highways doesn't actually solve traffic problems?
**\<endogenic>** i think it might be similar with meeting times
**\<netg>** +1 for longer meetings
**\<fluffypony>** why not just have meeting once a week instead of every 2 weeks?
**\<ErCiccione>** I'm talking for my personal experience. I've been doing meetings for about 12 years and sometimes they lasted even 6 hours for that very reason. But i'm talking about a completely different environment
**\<ErCiccione>** fluffypony: I would personally prefer longer meetings than more often, but that could be a solution
**\<fluffypony>** I'd kill myself if I had to sit in a 6 hour meeting
**\<ErCiccione>** and wasn't a friendly environment, I was very close to :)
**\<netg>** i just think, we dont need a hard stop at the planed finishing time
**\<netg>** 10 till 30 mins longer depending on if there is something left to talk
**\<netg>** would be ok, IMHO
**\<ErCiccione>** netg: I agree, that's basically what i suggested here: https://github.com/monero-project/meta/issues/141#issuecomment-350490380
**\<DaveyJones>** some kind of meeting reflecting + discussion
**\<DaveyJones>** reflection
**\<netg>** like a sprint review in scrum?
\ No newline at end of file
_posts/2017-12-11-logs-for-the-Monero-Research-Lab-meeting-held-on-2017-12-11.md 0 → 100644
View file @ 6722b832
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2017-12-11
summary: Bulletproofs (range proofs), ASIC resistance, and miscellaneous
tags: [community, crypto]
author: dEBRUYNE / fluffypony
---
# Logs
**\<suraeNoether>** yes we do
**\<suraeNoether>** good morning everyone
**\<suraeNoether>** moneromooo, smooth, andytoshi, ArticMine, stoffu, fluffypony, endogenic, gingeropolous
**\<suraeNoether>** pero pigeons stoffu vtnerd unknownids
**\<hyc>** pero is here?
**\<suraeNoether>** *shrug* his name is on the list, but i haven't heard him say anything since before we funded sarang
**\<sarang>** "He was never here, Trebek..."
**\<suraeNoether>** hyc
**\<suraeNoether>** research meeting in 11 minutes, plus or minus the time it takes people to show up
**\<sarang>** I set out some coffee and muffins for the meeting, but nobody is taking any
**\<sarang>** Might have wasted my moneys on that one
**\<unknownids>** lol
**\<suraeNoether>** someone had a nice diagram or flowchart of the multisig key usage... anyone remember where it may be stashed? i meant to save it
**\<luigi1111>** JollyMort[m]: ^^
**\<suraeNoether>** ah yes
**\<suraeNoether>** now i can scan my logs for it
**\<endogenic>** meeting adjourned
**\<suraeNoether>** lol
**\<suraeNoether>** Welcome everyone to the Nth MRL research meeting
**\<sarang>** hullo
**\<suraeNoether>** agenda: 1) hellos, 2) sarang's work recently, 3) my work recently, 4) a grander discussion of "what's next after the multisig paper"
**\<suraeNoether>** oh, and actually insert between 3) and 4) above: any other interesting research anyone else is doing
**\<ArticMine>** hi
**\<suraeNoether>** i know that we have at least two (i think) computer science folks in here working on things.
**\<suraeNoether>** howdy everyone
**\<suraeNoether>** ok, well... sarang, you want to catch us up to speed on your past few weeks?
**\<sarang>** Sure
**\<sarang>** Updates to the BP code (both single- and multi-output) were completed for compatibility with our existing commitment formats
**\<sarang>** initial unit testing looks good
**\<sarang>** The single output case has been tossed over to testnet
**\<sarang>** A blog post was made to getmonero.org to explain our two-stage process
**\<sarang>** First single-output (SO), then multi-output (MO)
**\<sarang>** Doing SO first will let us sidestep the fee question for now
**\* suraeNoether** just got a phone call from the "tax crime investigation department of the IRS." Everyone be aware: the IRS contacts you by mail not phone!
**\<sarang>** while still gaining a lot in terms of space and verification efficiency
**\<sarang>** Now, there are still opportunities to speed up verification
**\<suraeNoether>** that's great news to hear
**\<sarang>** I want to get us a better multiexponent method
**\<sarang>** andytoshi has been working up some code for his curve of choice with his collaborators
**\<sarang>** I did some rough testing that didn't perform as well as expected, but that can be worked on going forward
**\<suraeNoether>** if we can get it even faster, we can play a nice game optimizing a balance between RTRS RingCT sizes and transaction throughput
**\<sarang>** Nice thing is that any verification optimization is a drop-in function replacement
**\<sarang>** The savings will be more relevant when we move to MO
**\<sarang>** since that increases the number of fixed curvepoints we use in the algorithm
**\<sarang>** I also know there's good discussion happening about the best timetable for both SO and MO
**\<sarang>** whether or not doing SO in March is too fast, or just right, etc.
**\<suraeNoether>** what is your opinion on that, and what are the arguments for/against going slower/faster?
**\<sarang>** Well, it's a new method, and there are arguments against using the absolute newest stuff
**\<sarang>** But it's also very good
**\<sarang>** I think having it in testnet makes sense
**\<suraeNoether>** do we have an opinion on putting up a bounty for exploits before moving it to mainnet?
**\<sarang>** and it does address major concerns that our public has about bloat and feez