---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2017-05-07
summary: Sub / disposable addresses, smart mining GUI, 0MQ, and MyMonero-in-tree discussion
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
---

### Overview  

An overview [can be found on MoneroBase](https://monerobase.com/wiki/DevMeeting_2017-05-07).  

### 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. MyMonero-in-tree discussion  
**\<fluffypony>** 5. Any additional meeting items  
**\<fluffypony>** 6. Confirm next meeting date/time  
**\<fluffypony>** so let's start with 1. Greetings (aka roll call)  
**\<fluffypony>** hi  
**\<johnalan>** hi  
**\<vtnerd>** present  
**\<sgp>** hello!  
**\<fluffypony>** tewinget apologises, he'll be late  
**\<ajs>** Sup  
**\<endogenic>** o/  
**\<rehrar>** Yo  
**\<fluffypony>** hyc / luigi1111 / ArticMine / othe / smooth / anonimal / binaryFate / dEBRUYNE / dnaleor / gingeropolous / iDunk / IPGlider / Jaquee / jwinterm / kenshi84 / knaccc / luigi1112 / luigi1115 / NoodleDoodle / papalazzarou / pigeons / RedLion[m] / redlion  
**\<Jaquee>** hhelo  
**\<pigeons>** :)  
**\<vtnerd>** also me  
**\<Jaquee>** medusa  
**\<fluffypony>** anyone I forgot  
**\<iDunk>** o/  
**\<vtnerd>** oh those are not present whoops  
**\<fluffypony>** lol vtnerd  
**\<fluffypony>** ok so  
**\<fluffypony>** 2. Brief review of what's been completed since the previous meeting  
**\<fluffypony>** merged a bunch PRs  
**\<fluffypony>** kenshi84's GPG key changed  
**\<fluffypony>** I've confirmed it via sidechannel  
**\<fluffypony>** we have a new sweepbelow function in the CLI, which you may find useful  
**\<fluffypony>** we also have a new heavier bias in output selection towards newer outputs  
**\<fluffypony>** moneromooo can fill us in on that  
**\<ArticMine>** Hi  
**\<othe>** oi  
**\<fluffypony>** smart mining is enabled in the GUI  
**\<fluffypony>** as in the selection box  
**\<moneromooo>** Hmm, I just twiddled the settings for the recent output selection, really. To match some data in the Miller et al paper.  
**\<fluffypony>** which is pretty cool  
**\<sgp>** indeed  
**\<fluffypony>** also Jaquee has done some work on getting iOS back on track after it borked (visually)  
**\<fluffypony>** well iOS / mobile  
**\<fluffypony>** which brings us to  
**\<fluffypony>** 3. Code + ticket discussion / Q & A  
**\<Jaquee>** yes. and there's some new translations added to gui  
**\<fluffypony>** we have a number of open PRs  
**\<fluffypony>** when tewinget is off his bus he can update us on 0MQ  
**\<fluffypony>** which I'd REALLY like to move forward with ASAP  
**\<fluffypony>** it's been sitting in a holding pattern for ages  
**\<fluffypony>** Snipa: also if you're around maybe you can update us on the testing on that ?  
**\<moneromooo>** I'd like it to be optional, so it can be merged (and thus tested), without causing massive breakage if it does break.  
**\<fluffypony>** afaik that was the case  
**\<Jaquee>** sounds like a good idea  
**\<fluffypony>** also disposable addresses is still hanging around - I think that's pending a review from one of the luigis?  
**\<moneromooo>** AFAIK yes. Also RandomRun had an idea to make it better.  
**\<fluffypony>** I don't think there's a problem with that hanging around and being improved  
**\<fluffypony>** as long as the parallel MRL write-up is there  
**\<fluffypony>** I'd like to discuss 1998  
**\<fluffypony>** the PR, not the year  
**\<fluffypony>** https://github.com/monero-project/monero/pull/1998  
**\<fluffypony>** at this point in time I'm still swaying towards prevent-user-stupidity-by-default  
**\<fluffypony>** at the slight inconvenience for a power user / sysadmin who might go "omg really" and then add the flag  
**\<fluffypony>** I know vtnerd feels the same way, which is why he added it in the first place  
**\<fluffypony>** I'd be interested in strong arguments for removing the flag  
**\<Jaquee>** wouldnt a text disclaimer be enough?  
**\<Jaquee>** i don't have a strong opinion  
**\<fluffypony>** Jaquee: if you try bind externally and start it without the --confirm-external-bind flag then it refuses to start  
**\<fluffypony>** and it tells you why  
**\<Jaquee>** ok. apparently hyc started the discussion. Are you around?  
**\<fluffypony>** I know hyc doesn't like it  
**\<fluffypony>** vtnerd: has anyone else expressed disdain for it?  
**\<vtnerd>** AFAIK, just the people on that PR and the one referenced  
**\<vtnerd>** and possibly one person in IRC, but they seemed to be questioning why it was necessary (I think)  
**\<vtnerd>** its somewhat low effort to get around it, so most people just add the flag I thnk  
**\<vtnerd>** no one has privately contacted me about it for any reason if that was the question  
**\<fluffypony>** ok  
**\<fluffypony>** unless hyc comes in I move to close the PR, we can always re-open it later  
**\<Jaquee>** ok with me  
**\<fluffypony>** ok next PR for discussion is 2011  
**\<fluffypony>** moneromooo had concerns that it was touching consensus critical issues  
**\<fluffypony>** so/issues/part of the code  
**\<moneromooo>** Yes, but it turns out it's actually bypassed when a tx comes from a block. The patch is fine.  
**\<moneromooo>** I OK'd it since.  
**\<fluffypony>** ah ok'  
**\<moneromooo>** Well, wait.  
**\* fluffypony** stops...hammer time  
**\<moneromooo>** It's really uneeded (only the wallet bit was wanted). But it's not forkworthy. That said...  
**\<moneromooo>** Older wallets *might* create txes which aren't relayed by newer daemons.  
**\<moneromooo>** That's fairly unlikely, since my code targets 2/3 of max size, but the size approximation is not very precise.  
**\<moneromooo>** That said, I think it's fine to merge.  
**\<hyc>** hey. just popped in. reading history  
**\<fluffypony>** hi hyc !  
**\<dEBRUYNE>** Re: 2011, perhaps it also should be dependent on the fee priority level used  
**\* fluffypony** plays elevator hold music  
**\<hyc>** ok, if n0b0dy else cares about that external bind thing then whatever. to me it's redundant  
**\<fluffypony>** ok  
**\<hyc>** since you had to explicitly request a non-localhost address already  
**\<fluffypony>** sure, but you'd be surprised how few people know that 0.0.0.0 exposes everything :-P  
**\<endogenic>** ^  
**\<hyc>** it d0esn't protect against typos/accidents. it only pisses off people who expect the computer to do as it's told  
**\<fluffypony>** hyc: view it like a weak password warning  
**\<fluffypony>** you can't just expect the computer to accept 1234 as a password  
**\<hyc>** yeah, ok...  
**\<moneromooo>** Well, I would...  
**\<fluffypony>** lol  
**\<fluffypony>** moneromooo is the exception to every rule :-P  
**\<fluffypony>** now on the GUI side, the only thing I wanted to bounce around is 688  
**\<fluffypony>** tooltips are fine, but if we're going to do some sort of unified help then I would veer towards an overlay that shows once the first time you enter a screen, and can be re-called by clicking the [?] button on the taskbar  
**\<fluffypony>** https://s-media-cache-ak0.pinimg.com/originals/c1/e1/bf/c1e1bfd7fb2770f6745d95af8bf89865.jpg  
**\<johnalan>** like that style  
**\<fluffypony>** https://s-media-cache-ak0.pinimg.com/originals/43/6e/74/436e746b35142f41d5f9bb8e765963e4.jpg  
**\<fluffypony>** http://eyeviewportal.com/filecache/b38/73d/85-cropped-w545-h409-of-1-FFFFFF-evappguiguidecontentimage002.jpg  
**\<fluffypony>** like that  
**\<hyc>** sounds good  
**\<johnalan>** :+1:  
**\<Jaquee>** problem is [?] is not around if you use native title bar  
**\<fluffypony>** Jaquee: where else could we add a help button? bottom left?  
**\<endogenic>** one suggestion i'd make for that is to make it c lear to the user they can recall it easily by doing "X" so that they don't fret about having to memorize everything before it's closed  
**\<endogenic>** recall it -> the help screen  
**\<Jaquee>** i think ^ is good as a start  
**\<moneromooo>** Where is it on the title bar then, since it's not a WM thing ?  
**\<fluffypony>** endogenic: agreed  
**\<moneromooo>** s/Where/Why/  
**\<Jaquee>** but some buttons could need longer desriptions  
**\<Jaquee>** like sweepunmixable and paymentid for example  
**\<fluffypony>** Jaquee: there's enough space in the help overlay, we can use a smaller font to explain them  
**\<redlion>** how breadwallet on ios handles it when setting up is quite good  
**\<fluffypony>** or move the help to somewhere where there's space  
**\<fluffypony>** and use an arrow  
**\<Jaquee>** yeah. we could find a place for that help button  
**\<fluffypony>** ok - any other PRs that need discussion or can we move on? there's general Q&A shortly  
**\<sgp>** I'd like to merge 261 on monero-site  
**\<fluffypony>** sgp: there's a website meeting after the Kovri one  
**\<fluffypony>** so we can discuss it then  
**\<sgp>** ok  
**\<fluffypony>** ok so  
**\<fluffypony>** 4. MyMonero-in-tree discussion  
**\<fluffypony>** so basically this is about nose-covering and making sure I'm not abusing my position as a maintainer and member of the Monero Core Team  
**\<fluffypony>** currently MyMonero has a working API (largely unspecced to be sure), two client implementations (website and app), two server implementations (the live backend and OpenMonero), with a third one coming  
**\<fluffypony>** I'd like to make sure there is general acceptance and buy-in that the API can be implemented as the general API for lightweight wallets (ie. wallet that use remote viewkey scanning)  
**\<hyc>** is it carved in stone now  
**\<hyc>** if we need to tweak it we can still do that?  
**\<redlion>** is the license unrestricted?  
**\<fluffypony>** and that MyMonero-written or MyMonero-derived code is generally acceptable to be merged into the source tree (ie. the open-source backend implementation that vtnerd is working on)  
**\<fluffypony>** redlion: BSD 3-clause  
**\<fluffypony>** hyc: as long as mWo12 changes it, and we match the changes in the live backend and the new backend then yse  
**\<fluffypony>** yes  
**\<fluffypony>** we can make any changes, and we WILL make changes to make it smarter  
**\<moneromooo>** If it's beneficial to monero and it works fully by itself without needing proprietary gunk, then I'm OK with it.  
**\<fluffypony>** eg. tx history comes in raw, instead of paginated  
**\<fluffypony>** so that needs to change  
**\<hyc>** +1 moneromooo  
**\<fluffypony>** moneromooo: yeah the new backend will use LMDB instead of mysql  
**\<fluffypony>** so it will be unencumbered in the source  
**\<ArticMine>** As long as there are no proprietary dependencies I am fine  
**\<hyc>** I like it even more now ;)  
**\<johnalan>** I think it beneficial too  
**\<moneromooo>** Maybe a separate repo (similar to monero-core) might be best, but that's details.  
**\<johnalan>** \*its  
**\<moneromooo>** it's  
**\<iDunk>** it's  
**\<jollymort>** can't wait to run a mymonero node myself!  
**\<vtnerd>** also the current "primary" wrapper around the DB is actually C, so theres that for you guys  
**\<fluffypony>** moneromooo: I thought about that, but it's a single daemon that *should* exist in the repo alongside the wallet RPC etc.  
**\<hyc>** doesn't it supersede wallet-rpc?  
**\<fluffypony>** now  
**\<fluffypony>** hyc: no  
**\<fluffypony>** wallet-rpc is good for integration, this isn't  
**\<johnalan>** there is obviously an element of centralisation, but it’s nearly impossible to avoid  
**\<fluffypony>** also on this topic  
**\<fluffypony>** Jaquee has begun working on client integration in the CLI and GUI  
**\<moneromooo>** "client integration" ?  
**\<vtnerd>** you mean for light-wallets?  
**\<fluffypony>** that will mean that both CLI and GUI will be able to run in lightweight / remote-scanner / MyMonero mode  
**\<fluffypony>** moneromooo: as opposed to implementing the server protocol  
**\<hyc>** sounds good  
**\<moneromooo>** Oh, mymonero client integration ?  
**\<fluffypony>** moneromooo: let's call it something else  
**\<moneromooo>** That went pretty damn fast :D  
**\<fluffypony>** "lightweight wallet"  
**\<jollymort>** it's not really centralization if any `monerod` acts as a server  
**\<hyc>** but I'm still missing why we need old wallet-rpc if this mymonero api exists  
**\<jollymort>** it's literally my monero :)  
**\<fluffypony>** hyc: wallet-rpc is completely different  
**\<johnalan>** so the core GUI will be able to interact with MyMonero backend too?  
**\<vtnerd>** for people that want to run VPS node but keep their viewkey ?  
**\<moneromooo>** Yes, would be nice to see what bits are needed where, and the actual API (even if roughly).  
**\<fluffypony>** it provides an API for integrators  
**\<fluffypony>** @johnalan yes  
**\<fluffypony>** so basically  
**\<johnalan>** is this needed with the MyMonero Desktop wallet?  
**\<ArticMine>** With what as the backed / server  
**\<moneromooo>** That can be posted later though, :49 now.  
**\<ArticMine>** monerod?  
**\<fluffypony>** lightweight wallets will have 3 server options:  
**\<fluffypony>** 1. OpenMonero  
**\<fluffypony>** 2. the new in-source backend that vtnerd is working on  
**\<fluffypony>** 3. the live MyMonero backend  
**\<fluffypony>** it will also have multiple client options:  
**\<hyc>** afaik the main difference btw an ordinary wallet and mymomero is you tell mymonero your viewkey  
**\<fluffypony>** 1. OpenMonero's web wallet (clone of the current MyMonero web wallet)  
**\<hyc>** and the ordinary wallet has all your keys  
**\<fluffypony>** 2. the MyMonero applications  
**\<fluffypony>** 3. monero-wallet-cli  
**\<fluffypony>** 4. monero-wallet-rpc  
**\<fluffypony>** 5. the Monero GUI  
**\<fluffypony>** hyc: monero-wallet-rpc can still use this on the backend  
**\<fluffypony>** so it's unrelated  
**\<hyc>** ok  
**\<ArticMine>** ok  
**\<jollymort>** about #2011 - you could modify it to (median)+0.6% for it to be mine-worthy, or even have the wallet check for fee setting and then it would be matched like 1: +0.6%, 2: +2.4%, 3: +12%, 4:+100%  
**\<fluffypony>** also this will mean that the GUI / CLI may end up supporting the MyMonero 13-word seed derivation by virtue of the integration effort  
**\<fluffypony>** does anyone have a fundamental issue with that ?  
**\<ArticMine>** no  
**\<fluffypony>** I mean, I do, because I don't want to be abusing my position, but it is what it is :-P  
**\<jollymort>** didn't you deprecate 13-word?  
**\<moneromooo>** Did you not say the 13 word seed was going to be obsoleted ?  
**\<endogenic>** jollymort: working on it  
**\<johnalan>** no  
**\<endogenic>** but client still needs to be able to read 'em  
**\<redlion>** electrum/mycelium support a few different seed lengths iirc  
**\<redlion>** works well  
**\<jollymort>** also luigi was playing around with an idea for 17-word, integrating creation height in it etc  
**\<fluffypony>** moneromooo: it's import only  
**\<fluffypony>** not create  
**\<endogenic>** https://github.com/mymonero/mymonero-app-js/issues/77  
**\<knaccc>** doesn't it put a huge load on mymonero when someone asks it to scan the blockchain from zero with their view key? How long does mymonero take to scan the entire blockchain?  
**\<moneromooo>** Anyway, I'm fine with that as presented.  
**\<hyc>** that all sounds like a win to me. people have been whining about not being able to import their 13-word seed into regular CLI wallet  
**\<shuannelson>** so monero-wallet-cli/monero GUI will not be able to create light-wallets?  
**\<fluffypony>** knaccc: yes it does - about 10 minutes  
**\<jollymort>** yeah import only sounds lovely  
**\<ArticMine>** If we are setting the stage for a competitive market based upon FLOSS then I am fine with it  
**\<vtnerd>** I do have the ASM code working, so hopefully that will tighten up some too (altough there is something else blocking that)  
**\<fluffypony>** shuannelson: yes they will  
**\<fluffypony>** but with 25 word seed, not 13  
**\<fluffypony>** we have 7 minutes left - so I'd like to move on to the last item  
**\<shuannelson>** awesome!  
**\<fluffypony>** we can discuss MyMonero more after the meeting  
**\<redlion>** @shaunnelson, I think it's just that the CLI/GUI won't create 13-word seeds, but will accept already created ones  
**\<hyc>** yeah sounds fine  
**\<fluffypony>** 5. Any additional meeting items  
**\<knaccc>** 10 mins is quite a speedup vs downloading the entire blockchain, so sounds awesome.  
**\<jollymort>** any thoughts on future of penalty/blocksize? i kind of left the research open-ended  
**\<hyc>** ^^ get a faster CPU and it'll be quicker ')  
**\<redlion>** Does anyone have a working monero-core or mymonero build on ios currently? I've been fiddling around and I can't seem to get either properly functional on the sim/device, though I may be missing something  
**\<fluffypony>** lol hyc  
**\<endogenic>** redlion: pls come join #mymonero but yes i do :)  
**\<Jaquee>** redlion: i have. it has some nasty bugs but it's running  
**\<redlion>** ok thanks, I'll talk to you after this  
**\<hyc>** btw iOS still limits process VM size to 4GB so we won't be running monerod native on iOS any time soon  
**\<fluffypony>** @jollymort let's discuss it after the meeting, or maybe next week - there are 2 more meetings to go tonight :)  
**\<fluffypony>** and that's a large topic  
**\<jollymort>** sure, another time  
**\<redlion>** thanks jaquee, are there any build instructions or a (sort of) working build posted somewhere?  
**\<fluffypony>** 6. Confirm next meeting date/time  
**\<fluffypony>** May 21  
**\<fluffypony>** day before Consensus  
**\<hyc>** cool  
**\<hyc>** oh. this week I expect to have wolf miner fully ported to Android, with GPU support too  
**\<fluffypony>** endogenic can come to my hotel and we can do the meeting together :-P  
**\<endogenic>** oooh  
**\<tewinget>** anyway, I have the daemon's side of the code rebased and *nearly* ready to PR and merge.  I mean, it could be merged now, but I should clean it up a little/address a few more of the comments on the existing PR first.  
**\<tewinget>** the wallet side of things will be based on that, and won't take too long.  I just thought it made sense to separate it into two PRs (and rebase while I'm at it because why not?)  
**\<fluffypony>** suweet  
**\<fluffypony>** just check the meeting logs for the bit from moneromooo about it  
**\<tewinget>** (the wallet stuff is still "done already", but as with the daemon side there are comments/suggestions to address as I rebase it as well.)  
**\<tewinget>** at any rate, I plan today to finish with the cleanup of the daemon side of things, close the existing PR, and open a new one for the daemon that should be mergeable.  
**\<fluffypony>** great stuff  
**\<fluffypony>** pigeons: did you see the 96boards thing?  
**\<tewinget>** fluffypony: sorry I didn't respond right away to your pinging on the github PR, but when I said it was already rebased I meant on a different branch, as I'm leaving that branch up (and separate) until I finish rebasing.  
**\<fluffypony>** ok cool  
**\<moneromooo>** tewinget: is the 0MQ stuff deselectable if needed (so if it somehow breaks, you can run the wallet with the existing JSON comms) ?  
**\<moneromooo>** wallet/daemon  
**\<tewinget>** moneromooo: I'll make it so when I rebase the wallet side of things.  
**\<moneromooo>** Excellent, thank you :)