19 KiB
| layout | title | summary | tags | author | |||
|---|---|---|---|---|---|---|---|
| post | Overview and Logs for the Dev Meeting Held on 2017-05-07 | Sub / disposable addresses, smart mining GUI, 0MQ, and MyMonero-in-tree discussion |
|
dEBRUYNE / fluffypony |
Overview
An overview can be found on MoneroBase.
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> 👍
<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 :)
