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

Meeting Logs - Dev Meeting (2017-12-03), Community Meeting (2017-12-09), and Monero Research Lab Meeting (2017-12-11)

Browse Source
This commit is contained in:
dEBRUYNE-1 2017-12-13 16:57:48 +01:00
parent 9bfeb9b382
commit 4c059ae9ad
No known key found for this signature in database
GPG Key ID: B9145F6EBFA81C32
3 changed files with 882 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

264
_posts/2017-12-03-overview-and-logs-for-the-dev-meeting-held-on-2017-12-03.md Normal file
View File

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

256
_posts/2017-12-09-logs-for-the-Community-meeting-held-on-2017-12-09.md Normal file
View File

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

362
_posts/2017-12-11-logs-for-the-Monero-Research-Lab-meeting-held-on-2017-12-11.md Normal file
View File

@ -0,0 +1,362 @@
---
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
**\<suraeNoether>** i was just looking at our average fees on monero.how
**\<sarang>** I think there'd be a bit of a PR hit if we kept it out of March (though that is *not* an endorsement against proper testing)
**\<sarang>** My preference is to continue beating the bejeezuz out of it in testnet and determine where that takes us
**\<suraeNoether>** yeah, PR is not relevant to security. thing is, unless price increases by an order of magnitude (we should be so lucky), I feel like fees still aren't a big deal. they are quite low in monero compared to bitcoin, in best, worst, and average case
**\<sarang>** Hoping to hit March, but not making the testing dependent on that timeline
**\<suraeNoether>** but thats measured in fiat
**\<endogenic>** in that case, is a bounty a good idea?
**\<endogenic>** seems it might incentivize some testing
**\<suraeNoether>** i like the idea of bounty-ing bulletproofs
**\<sarang>** As do I
**\<endogenic>** may i bring up something related?
**\<endogenic>** but not to bulletproofs specifically
**\<sarang>** For better or worse, BPs have been hyped, and anything that gets them tested is a Good Thing
**\<suraeNoether>** we can simply dump 2\^N bulletproofs into a file and challenge the community: if you can open even one without knowing our secret masks, we'll give you such and such amount of XMR
**\<sarang>** Well, that's not the only thing we care about
**\<suraeNoether>** endogenic yes, let's append that to the "other stuff people are working on"
**\<suraeNoether>** yeah, also the computational waste
**\<sarang>** e.g. choosing "random" values in a clever way, or generating edge cases
**\<sarang>** Or gaining partial info about amounts w/o exact values
**\<suraeNoether>** oh i see
**\<sarang>** endogenic: fire away
**\<endogenic>** ok, similarly, i've been wondering how much traditional pentesting etc has been done on Monero… i've heard some fuzzing has been done, but i'm wondering as well if a more organized effort will be valuable
**\<endogenic>** i think it would be
**\<sarang>** Well, we already have a bounty program, no?
**\<sarang>** A general one?
**\<sarang>** And there was a recent large FFS for bounty
**\<suraeNoether>** do we have a set of formal security games for bulletproofs defined for the properties we are concerned about breaking on mainnet? i know that something like a spam attack isn't easily model-able that way, but there are other properties from my understanding.
**\<endogenic>** i've been curious about that too \^
**\<suraeNoether>** endogenic: can you elaborate?
**\<endogenic>** er sorry, on which?
**\<suraeNoether>** i feel like since monero is a cryptocurrency there is a large financial incentive for penetration
**\<sarang>** suraeNoether: the paper establishes security definitions
**\<sarang>** proved for MO, for which SO is a degenerate case
**\<endogenic>** suraeNoether: yeah but there might also be disincentives to let us know about it :P
**\<suraeNoether>** endogenic: true...
**\<suraeNoether>** well in regards to the BP, does anyone have any strong opinions on this or are we just going back and forth on speed of implementation?
**\<suraeNoether>** and by speed i mean how quickly we are moving to mainnet not verification time
**\<suraeNoether>** ok, sarang, anything else for you?
**\<suraeNoether>** from\*
**\<ArticMine>** My only questions relate to pricing vs cost when there is a cost that does not scale the same way as size
**\<sarang>** I'm assisting suraeNoether with finalizing his paper
**\<sarang>** And doing background work on recent zk-snark developments
**\<sarang>** More to discuss in our "future work" segment
**\<suraeNoether>** ArticMine: can you elaborate?
**\<suraeNoether>** sarang: yeah no kiding
**\<ArticMine>** This would relate to the scaling of verification time
**\<sarang>** ArticMine: yes, the discussions on fee/penalty structure have been around this
**\<sarang>** Fortunately they only really apply to MO-BPs, and not SO-BPs
**\<ArticMine>** I know this may be premature at this time
**\<sarang>** No, it's good to discuss ASAP
**\<sarang>** But in parallel to SO deployment
**\<suraeNoether>** i think our fee structure needs to be evaluated so that it's properties hold more or less invariant over the longrun. if it's possible that our blockchain changes over the next few years so much that miners are getting massive fees for verifying super cheap bulletproofs, or vice versa, we should change the way we compute the fees (even if we think current fee amounts are fair... which, personally, i
**\<suraeNoether>** don't see too much of a problem with current *amounts*
**\<suraeNoether>** on the other hand
**\<ArticMine>** It comes down to the cost of verification vs size
**\<sarang>** yes
**\<suraeNoether>** yep. however... what has been banging around in my head is to take all the improved cost of verification and dump it into larger ring signatures
**\<suraeNoether>** using RTRS RingCT
**\<sarang>** We want to encourage the use of MO-BPs (as opposed to multiple SO) while avoiding scaling differences
**\<suraeNoether>** hmm
**\<ArticMine>** But size alone will do that
**\<suraeNoether>** i need to read up on BPs. now that sarang is working on the multisig paper, i have time to learn about them.
**\<sarang>** The bottom line is that size scales as O(log2(M)) and verification scales as O(M)
**\<sarang>** for M outputs
**\<ArticMine>** At what point does verification become an issue
**\<sarang>** Miners should prefer MOs (or protocol should enforce them vs multiple SOs)
**\<suraeNoether>** is our fee structure based on size as opposed to verification time?
**\<sarang>** yes
**\<suraeNoether>** i think it is
**\<suraeNoether>** yeah
**\<suraeNoether>** hmm
**\<ArticMine>** Our fee structure is currently only based upon size
**\<sarang>** ArticMine: verifying multiple SOs already scales as O(M)
**\<suraeNoether>** what if we merely take a joint model where we take A\*size + B\*verification time for appropriately chosen constants A and B?
**\<suraeNoether>** as our fee
**\<ArticMine>** So id the blocksize penalty
**\<sarang>** It's actually a little less for an MO
**\<suraeNoether>** pick A to determine how much the miner should be compensated for storing the BP, pick B to determine how much the miner should be compensated for burning verification time on something other than hashrate
**\<ArticMine>** I have to give this a lot of thought
**\<suraeNoether>** yeah, this is not a simple one-and-done discussion.
**\<ArticMine>** because it also impact the question of exchange
**\<suraeNoether>** what do you mean by that?
**\<sarang>** And a solid general approach to it would help address future developments that affect size vs computation time
**\<ArticMine>** Purchasing power of Monero should scale with the number to outputs
**\<luigi1111w>** \<suraeNoether> yep. however... what has been banging around in my head is to take all the improved cost of verification and dump it into larger ring signatures \<= I disagree. Of course there's no perfect answer, but cpu cost is currently quite on the high side IMO, and I'd like to see it lower overall.
**\<ArticMine>** So we may have to scale the output part of the fee with the total number of outputs in the block as opposed to the blocksize
**\<ArticMine>** Essentially two fee components one size based and one output based
**\<suraeNoether>** ArticMine: i will need to think about that. i think computing expected verification time of a transaction should be very simple, and is a more direct measurement of how much the miner is burning on that transaction
**\<sarang>** Yes let's continue to think about and discuss this going forward
**\<sarang>** suraeNoether this ends my report
**\<ArticMine>** Yes it is an other "effective penalty"
**\<hyc>** that's the obvious way forward - if you are accounting for both storage space and CPU cost, you need the two factors present in the fee
**\<suraeNoether>** so, actually, i want to address luigi's point
**\<suraeNoether>** because we are tugging at two ends of the rope, cpu efficiency versus privacy
**\<suraeNoether>** i think if monero users want to enjoy privacy over the long run, we need either zk-stark whole-blockchain-like signatures, or we need very large ring sizes. and in both cases, we can't have authenticating data like signatures scale linearly in size, or we are sunk in the water.
**\<suraeNoether>** i've been using the attitude that each gain in speed or performance can be matched with a bigger RTRS RingCT so that users don't necessarily notice any performance change, their privacy merely increases
**\<suraeNoether>** on the other hand, we can make things faster while keeping monero's privacy where it's at
**\<suraeNoether>** the goal is hopefully to meet in the middle somehow
**\<suraeNoether>** underneath the entire BP discussion is which direction we are going to take Monero over the next few months or years
**\<suraeNoether>** which was why I wanted to bring up point 4) before, about "the future."
**\<hyc>** along the lines of that question - if CPUs get faster over time, that should mean we can increase ringsize in the future
**\<endogenic>** imo better to prioritize privacy
**\<luigi1111w>** or keep up with increased use
**\<hyc>** since we're talking about linear increases in verification cost, is there a tradeoff in traceability?
**\<ArticMine>** Yes but we also have to keep in mind blocksize
**\<suraeNoether>** what's that one economic principle? make something more efficient and people just use more of them instead of the overall system using fewer things. Jevon's paradox?
**\<hyc>** e.g. if CPUs get 2x faster, does it become 2x easier to analyze the blockchain?
**\<sarang>** https://en.wikipedia.org/wiki/Snackwell_effect ?
**\<luigi1111w>** hyc I don't think so
**\<ArticMine>** It is starting to look like verification time rather than size becomes the dominant cost parameter
**\<moneromooo>** If CPUs get faster, we have more users and larger blocks.
**\<suraeNoether>** (by the way, for point (3): the past weeks I've been working on multisig and that's essentially all. After handing it off to sarang I am now extremely excited to read about BPs and the new zk-starks, which could simply make this whole discussion moot anyhow.)
**\<luigi1111w>** that would be some entity data crunching. They'd just add as many cpus as needed
**\<luigi1111w>** I guess technically it'd be cheaper too, but the cost is likely not high enough to matter one way or the other
**\<ArticMine>** Yes but the cost of verification scales exponentially relative to size
**\<suraeNoether>** ArticMine: the verification time does appear to have become the most important feature of new cryptoschemes, to me
**\<ArticMine>** It could become dominant eventually because of the different scaling rates
**\<suraeNoether>** hyc: if it's exponentially difficult (in # of blocks say O(2\^i)) to analyze the monero blockchain, and you double your blocks/s of analysis, you still have an exponential amount of time for analysis O(2\^(i-1))
**\<hyc>** Ok so that implies we wouldn't need to increase ringsize very often in the future
**\<ArticMine>** However we must keep in mind that not all users will move to large MO proofs
**\<luigi1111w>** why wouldn't they?
**\<sarang>** If the vast majority of txns are still 2 outputs, that wouldn't change
**\<moneromooo>** Mymonero users ? :)
**\<ArticMine>** It is only advantageous to very large payers
**\<luigi1111w>** moneromooo I think endogenic is working on copying the c++ wallet code, so it'd likely include that
**\<luigi1111w>** otherwise I'll add it to JS probably
**\<moneromooo>** Great.
**\<endogenic>** we may even be able to transpile that C++ back to JS for the new web wallet, but the rest will run on the C++ yes
**\<luigi1111w>** well I'll add it to JS anyway, for my own stuff, but probably mymonero.com too if needed
**\<suraeNoether>** so, in terms of "The Future:" sarang and I want to write up the Monero Standards, which we are excited about, and in those standards we simply want 1) to describe what the monero codebase currently does, 2) why those choices seem to have been made (if monero) or kept (if cryptonote reference), and 3) an outline of possible future algorithms for use in place of each piece. This whole discussion about
**\<suraeNoether>** verification time, etc, goes back to a question of which algorithms we might in "possible future algorithms," and our motivations/design philosophies for doing so.
**\<serhack>** suraeNoether: Monero standards will be helpful for me in order to write the ebook.
**\<suraeNoether>** serhack: the Monero Standards are going to be extremely helpful to the community for a long time afterwards. they are going to be extremely un-sexy to the community
**\<suraeNoether>** "Now unveiling... Monero Standards! Where we tell you what we are already doing!"
**\<hyc>** lol
**\<suraeNoether>** "Turns out we never had a manual all along!"
**\<serhack>** thanks suraeNoether
**\<suraeNoether>** but i suspect htey will be referenced over and over and over and over and over
**\<suraeNoether>** so, this is obviously an ongoing discussion. anyway. I also had an idea for educational outreach
**\<suraeNoether>** aaaand I'm not sure if I want to talk about it yet. just like the last idea fell through, I am glad I never mentioned a specific university.
**\<suraeNoether>** buuuut I think the community will like the idea, and I'll be hopefully announcing something about it in the middle of next month
**\<suraeNoether>** on another note, this POW contest idea
**\<suraeNoether>** if it were used for message authentication or anything like that, cryptonight would be wildly dangerous as a home-brewed hash function
**\<hyc>** why so?
**\<sarang>** In terms of public scrutiny?
**\<suraeNoether>** unlike other hash functions, it sort of rolls a die, picks a random hash function from a certain list based on that die, hashes its random data. then it swaps some bits around, i believe there is an AES stage, and then repeat. does this for a number of rounds
**\<suraeNoether>** until the L3 cache is totally filled up with this randomness
**\<suraeNoether>** I believe
**\<hyc>** pretty much, yeah
**\<hyc>** ok so it'd be crap for signatures
**\<suraeNoether>** point is: in 2013, if you were a 19 year old sitting around smoking pot trying to come up with a way to invent an asic resistant hash function, and all you knew about computers was that L3 functions are slow and that these handful of hash functions are considered good, this is *EXACTLY* the hash function you would come up with.
**\<suraeNoether>** s/L3 functions/L3 cache (oy)
**\<suraeNoether>** so the POW alternative thing is something that has been niggling at my mind for awhile
**\<suraeNoether>** and i'm thinking i'm willing to match the Monero community up to a certain amount in XMR for a nice, big, public contest on the matter
**\<luigi1111w>** the dice is at the end btw
**\<hyc>** L3 isn't that slow, and it's faster than main RAM. this was a pretty good approach to prevent trivial optimization (fitting into L2 or faster)
**\<luigi1111w>** https://github.com/monero-project/monero/blob/master/src/crypto/slow-hash.c#L488
**\<suraeNoether>** luigi1111w: ah, thanks, i thought i had the order mixed up
**\<suraeNoether>** hyc yes, you are correct
**\<sarang>** It'd be important to determine what you'd want out of a new PoW suraeNoether
**\<suraeNoether>** right
**\<suraeNoether>** we need a rubric for judging the submissions
**\<suraeNoether>** we need a panel of judges that are more or less impartial
**\<hyc>** you want another asymmetric function, like PKI. slow to prove, fast to verify.
**\<suraeNoether>** yep
**\<suraeNoether>** if it's ASIC-able, it should be commoditized already for improved egalitarian mining and for improved environmental impact
**\<suraeNoether>** i'm not sold that Nakamoto hash-based PoW is "the best" idea, although I know that whatever "the best" process is, it should end up being a poisson process
**\<suraeNoether>** i want provable security for every attacker % up to and including 50%
**\<suraeNoether>** etc etc
**\<suraeNoether>** i'm wondering if anyone else would be willing to match some XMR
**\<sarang>** Well hash-based has the advantage of being extremely fast to verify
**\<sarang>** and well understood if you use an accepted hash function
**\<suraeNoether>** because a prize could get really hefty really fast if some folks promise matching.
**\<suraeNoether>** yep sarang there are an enormous number of advantages with hash functions
**\<suraeNoether>** by the way, my idea i talked about yesterday on using discrete log + nakamoto PoW... I later in the day proved that it was a bad idea
**\<suraeNoether>** i have a nice little theorem "Do not implement this scheme."
**\<suraeNoether>** provably true
**\<hyc>** lol
**\<luigi1111w>** fast to verify is important
**\<luigi1111w>** slow to prove is pretty meh
**\<hyc>** cryptographic hashes are designed to be fast. and they don't have the desired asymmetry
**\<luigi1111w>** resistant to excessive speedup, sure
**\<hyc>** slow to prove is an essential component of the original PoW definition
**\<hyc>** applied to anti-spam email service
**\<luigi1111w>** that is provided by difficulty though
**\<suraeNoether>** it's sufficient to replace "slow to prove" with "exponential space-time tradeoff in proving time." This way, if someone can manage a speedup, they are paying the cost with necessary storage space.
**\<suraeNoether>** so either way you have to sink cost into hardware to participate
**\<hyc>** I would assume one of the goals is to be reasonable on existing deployed CPUs
**\<hyc>** whether in PCs or smartphones
**\<suraeNoether>** so, what are people's feelings on hosting such a contest? I think I would have a 3-6 month submission deadline or something along those lines. At least 3 months so that a student can spend a full semester working on the problem with their adviser, if they want.
**\<suraeNoether>** hyc \^ this assumes we do POW on a CPU as opposed to proof-of-storage-and-retrieval on a hard drive... and i don't want to restrict the contest submissions to PoW only.
**\<endogenic>** i'd be concerned to confirm strategy for handling technicalities with running the contest… deciding a singular winner… what happens if there is no winner…
**\<endogenic>** i know you already mentioned it surae
**\<sarang>** It'd be a highly nontrivial thing to do
**\<sarang>** You need lots of external testing
**\<sarang>** that's why the NIST contests take so freaking long
**\<moneromooo>** I really don't like the idea of creating an expectation we'll change to whatever this unearths.
**\<iDunk>** ^^
**\<luigi1111w>** I don't think that is expected
**\<luigi1111w>** or if it is, cancel that
**\<luigi1111w>** (expectation)
**\<sarang>** the incentive to test NIST standards is the understanding of widespread adoption
**\<suraeNoether>** moneromooo: we can say the default entry is the cryptonight algorithm submitted by the general fund.
**\<suraeNoether>** everyone is competing against htat
**\<luigi1111w>** I would be curious to see the parameters I guess
**\<suraeNoether>** to get into the second round of judging, if we have multiple rounds, requires outrunning the bear: cryptonight. to get into the third round of judging requires outrunning each other.
**\<hyc>** and is ASIC-resistance part of the criteria?
**\<sarang>** I'd think so
**\<suraeNoether>** i'm okay with ASICs if they are already commoditized (somehow)
**\<suraeNoether>** if they are asic-able and someone can come in and blow a million bucks to own the entire monero asic market, that's a losing proposal
**\<endogenic>** but that requires ppl to buy new hardware just to compete in mining, no?
**\<hyc>** that seems like a bad idea to me. it means everyone who wants to participate on a level playing field has to buy new hardware.
**\<endogenic>** seems to change the asic resistence idea
**\<hyc>** it leaves out the vast percentage of the world that has a smartphone in their pocket
**\<luigi1111w>** if you can blow a million bucks to own the market, something is very wrong
**\<luigi1111w>** why can't I come in and also blow a million to take half (and so on)
**\<ArticMine>** There a patent risks with ASICs - ASIC boost in Bitcoin comes to mind
**\<moneromooo>** I really like how people have started mining on CPUs for new reasons. This is only possible because mining on a CPU is feasible. Those are gimmicks, granted.
**\<endogenic>** but they might become much more widespread soon
**\<endogenic>** people are enabling web miners etc
**\<ArticMine>** Coinhive opened a can of worms
**\<endogenic>** ArticMine: passive mining in an app was mostly a matter of convenience then
**\<endogenic>** bc ppl can still bundle a mining lib and run it in the bg
**\<endogenic>** if they want to go to the effort
**\<ArticMine>** The trouble is who controls the mining
**\<suraeNoether>** hmm. interesting. the whole goal of ASIC resistance is egalitarian mining, in my mind. i don't really care so much about the asic resistance as the egalitarian mining.
**\<suraeNoether>** so let me rephrase the above
**\<ArticMine>** The user or the app developer
**\<endogenic>** ArticMine: who controls the target of the reward, or who controls the algo, or who controls the % of cpu used..? not sure which you mean, or if all three, etc
**\<ArticMine>** All three
**\<ArticMine>** In a typical mobile device it is not the end user, and that is a problem
**\<suraeNoether>** ok, so it sounds to me like people are willing to entertain the idea if the kinks of the governing contest judging body are ironed out, and as long as a rubric is publicly agreed upon. we are quibbling about details on the rubric right now, and that tells me people are receptive to the overall idea.
**\<hyc>** well... if it ain't broke don't fix it. what's broken?
**\<iDunk>** "So there is a chance" :D
**\<moneromooo>** That argument is invalid.
**\<suraeNoether>** lol iDunk
**\<suraeNoether>** hyc: if it ain't broke, no one will come up with a better idea
**\<suraeNoether>** and the money goes back to the general fund
**\<luigi1111w>** in the schwarz
**\<suraeNoether>** well
**\<luigi1111w>** schwartz
**\<luigi1111w>** idk
**\<suraeNoether>** if i offer to match some amount of XMR, and the thing doesn't get funded... the contest doesn't go through, you know?
**\<endogenic>** yeah but we'd hate to see money spent mistakenly
**\<endogenic>** guess ppl are just saying we need to be cautious
**\<ArticMine>** What are the advantages?
**\<serhack>** fund what?
**\<endogenic>** lol serhack just woke up
**\<suraeNoether>** serhack see above, i was talking about a PoW replacement contest
**\<luigi1111w>** the only thing missing from the current pow that I personally care about is verification speed
**\<luigi1111w>** it's slow
**\<serhack>** +1 suraeNoether
**\<serhack>** hello endogenic
**\<suraeNoether>** ArticMine: 1) coming up with a possibly more egalitarian POW, 2) coming up with a possibly faster verification POW, 3) avoiding an eerily-designed hash function that is essentially unique in its structure
**\<luigi1111w>** and what does #1 mean? :)
**\<suraeNoether>** honestly? i don't know yet. measuring egalitarian-ness... doesn't that go back to like ancient greece?
**\<suraeNoether>** heh
**\<endogenic>** but people are not equal
**\<endogenic>** (i looked it up)
**\<endogenic>** surae has better math ability than i
**\<luigi1111w>** impossible
**\<hyc>** I don't see #3 being detrimental in current cryptonight. it's using a bunch of heavily vetted hash algos in combination
**\<luigi1111w>** ok #2 definitely
**\<luigi1111w>** #3 I agree with hyc
**\<suraeNoether>** I'm not terribly concerned about 3) because if cryptonote was designed by scammers, and if cryptonight was designed maliciously, it would be difficult to discern this and it would provide the original miners with a disproportionate hash rate compared to users with similar computers. i'm a little less concerned about 2). But overall? I'm just not convinced that cryptonight is a particularly
**\<suraeNoether>** well-thought-out way to bring ASIC resistance/egalitarian mining into the hash computation world.
**\<suraeNoether>** add: "and its not like the original cryptonote founders are a huge % of the mining network"
**\<suraeNoether>** hit enter a little too soon
**\<suraeNoether>** and i'm a little *more* concerned about 2). good heavens
**\<suraeNoether>** seems like the community is more luke warm on the idea than i had hoped. that's cool. i'll shelve it for a few months
**\<suraeNoether>** okay, does anyone have any other topics to bring up?
**\<suraeNoether>** Okay, well, meeting adjourned I suppose. luigi, out of curiosity: could you do me a favor? can you come up with some numbers on per-output transaction verification times (total, including ring signatures and range proofs) and PoW verification times that you consider "worst case," we never want to go slower? it would help me figure out whether we can optimize BP + RTRS RingCT to get both large ring
**\<suraeNoether>** sizes and get verification times down
**\<suraeNoether>** i feel like per-transaction, we should be trying to keep verification time down under 50ms, but maybe that's too slow
**\<endogenic>** who's on the monerophone? nobody.
**\<endogenic>** or everybody.
**\<endogenic>** or anybody?
**\<sarang>** In the old days, it was a "party line"
**\<luigi1111w>** for what hardware ^\_^
**\<luigi1111w>** and yes definitely under 50ms
**\<luigi1111w>** complicated question though
**\<moneromooo>** Not my my hardware then ^\_^
**\<suraeNoether>** luigi1111w: the question i suppose is for the average node.
**\<suraeNoether>** and, again, just need upper bounds
**\<suraeNoether>** i know how to optimize a problem "subject to some cost \<= max\_cost"
**\<suraeNoether>** in this case verificaiton time
**\<luigi1111w>** can just use 50 for now
**\<gingeropolous>** re: i think it'd be nice if we had something waiting in the wings if a change in PoW *was* needed, because right now it seems there's a gestalt that the PoW would change if there was a miracle ASIC.
**\<gingeropolous>** woops. that should have read re: PoW -
**\<gingeropolous>** re:
**\<gingeropolous>** gah, sorry. this ergonomic keyboard. Re: ringsize, privacy, computation time - I have a hunch that we can extract a very useful dynamic parameter from network difficulty.
**\<suraeNoether>** gingeropolous: yeah, we don't even need to switch to the winner immediately. it could just be the one we put into our long-term piecemeal backup plans.
**\<hyc>** we know that there are Cryptonight implementations for FPGA already
**\<hyc>** and apparently they're profitable, now that XMR price has risen
**\<hyc>** the other aspect of using industry-standard algorithms - you can get impls of them off the shelf, and lump them together as Cryptonight uses them, without much hassle
**\<ArticMine>** So time may be of the essence to change the POW algorithm
**\<ArticMine>** In any case this POW algorithm change seems positive to me
**\<nioc>** othe has already stated that if an asic is produced, a few changes that would be simple to implement in mining software would make those asics useless
**\<nioc>** I believe he has already done some work on this
**\<unknownids>** \^ i recall that too