DevMeeting 2017-05-07

Submitted by aerbax on Sun, 05/07/2017 - 16:21

Highlights[ ]

  • Several Github Pull Requests(PR) have been merged.
    • "sweep_below" function in the CLI
    • Heavier bias in output selection towards newer inputs.
    • Smart Mining is enabled in the GUI
    • Jaquee fixed up an iOS GUI visual issue.
    • New translations added to GUI.
  • Renewed focus on ZeroMQ(0MQ)
  • Disposable addresses is pending review.
  • "Removed --confirm-external-bind from monerod and monero-wallet-rpc"
    • Motion moved to close this PR.
  • "Remove the 1.25 multiplier for max transaction size"
    • Mooo originally had some objections, but upon closer inspection, it's fine to merge.
    • hyc... ... ...agrees
  • Add tip text to labels
    • Fluffy suggests an overlay on first use that can provide help. And re-shows itself on a "?" click. Similar to this
  • MyMonero-in-tree - Is it appropriate for the new MyMonero supporting code to be included in the main Monero source?
    • Fluffy views it as a working API for lightwallets. This could help fast-track development of new wallets.
    • It uses a BSD "3 Clause"
    • Everyone seems to agree that it's fine - as long as it doesn't require any proprietary dependencies.
    • Will switch from MySQL to LMDB as the backend.
    • It does *not* supercede the existing wallet-rpc application.
    • Jaquee has started integrations with the GUI and this proposed MyMonero open backend.
    • This may also allow for the MyMonero 13 word seed to be supported natively.
  • Next meeting is scheduled for May 21st, 2017.

Full Log[ ]

<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
<_Slack> <johnalan> hi
<vtnerd_> present
<_Slack> <sgp_> hello!
<fluffypony> tewinget apologises, he'll be late
<_Slack> <ajs> Sup
<endogenic> o/
<_Slack> <rehrar> Yo
<fluffypony> hyc / luigi1111 / ArticMine / othe / smooth / anonimal / binaryFate / dEBRUYNE / dnaleor / gingeropolous / iDunk / IPGlider / Jaquee / jwinterm / kenshi84 / knaccc / luigi1112 / luigi1115 / NoodleDoodle / papa_lazzarou / 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 sweep_below 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
* Biilly_ (adefe1c4@gateway/web/freenode/ip.redacted) has joined
<_Slack> <sgp_> indeed
* lalu_ has quit (Remote host closed the connection)
<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> 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
* barry95 has quit (Remote host closed the connection)
<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
* lalu_ ( has joined
* peteyb ( has joined
<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...
* xyxyxyxyxyx (415e17d3@gateway/web/freenode/ip.redacted) has joined
<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.
* maitscha (d5e107de@gateway/web/freenode/ip.redacted) has joined
<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
* maitscha has quit (Ping timeout: 260 seconds)
* monero (~monero@redacted) has joined
<monero> [monero] moneromooo-monero opened pull request #2017: wallet2: fix sweep_unmixable assuming wrong minimum mixin at v5 (master...suv5)
* monero (~monero@redacted) has left
<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 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
<_Slack> <johnalan> like that style
<fluffypony> like that
<hyc> sounds good
<_Slack> <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 sweep_unmixable and payment_id 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
* bigreddmachine has quit (Quit: Leaving.)
<fluffypony> ok - any other PRs that need discussion or can we move on? there's general Q&A shortly
<_Slack> <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
<_Slack> <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 ;)
<_Slack> <johnalan> I think it beneficial too
<moneromooo> Maybe a separate repo (similar to monero-core) might be best, but that's details.
<_Slack> <johnalan> *its
<moneromooo> it's
<iDunk> it's
<_Slack> <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
<_Slack> <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"
<_Slack> <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
<_Slack> <jollymort> it's literally my monero :)
<fluffypony> hyc: wallet-rpc is completely different
<_Slack> <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
<_Slack> <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)
* PuebloZag (506d1957@gateway/web/freenode/ip.redacted) has joined
<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
* DrOlmer has quit (Ping timeout: 260 seconds)
<hyc> ok
<ArticMine> ok
<_Slack> <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
<_Slack> <jollymort> didn't you deprecate 13-word?
<moneromooo> Did you not say the 13 word seed was going to be obsoleted ?
* DrOlmer (~DrOlmer@unaffiliated/drolmer) has joined
<endogenic> jollymort: working on it
<_Slack> <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
<_Slack> <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
<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
<shuan_nelson_> so monero-wallet-cli/monero GUI will not be able to create light-wallets?
<fluffypony> knaccc: yes it does - about 10 minutes
<_Slack> <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> shuan_nelson_: 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
<shuan_nelson_> awesome!
<fluffypony> we can discuss MyMonero more after the meeting
<redlion_> @shaun_nelson, 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.
<_Slack> <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
<_Slack> <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
<endogenic> 👍
<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
<fluffypony> and with that
<fluffypony> we end the meeting on time
<hyc> (whether the hashrate is enough to bother is still an open question)
<fluffypony> with 2 minutes to spare
<fluffypony> because we're that cool