diff --git a/_posts/2017-05-07-logs-for-the-Kovri-dev-meeting-held-on-2017-05-07.md b/_posts/2017-05-07-logs-for-the-Kovri-dev-meeting-held-on-2017-05-07.md new file mode 100644 index 00000000..b7c199a6 --- /dev/null +++ b/_posts/2017-05-07-logs-for-the-Kovri-dev-meeting-held-on-2017-05-07.md @@ -0,0 +1,201 @@ +--- +layout: post +title: Logs for the Kovri Dev Meeting Held on 2017-05-07 +summary: Brief review of what has been completed since last meeting, Monero HackerOne Bounty, 96boards OpenHours showcase, website discussion, and code & open tickets discussion +tags: [dev diaries, i2p, crypto] +author: dEBRUYNE / fluffypony +--- + +*May 7th, 2017* + +# Logs + +**\** 1. Greetings +**\** 2. Brief review of what's been completed since the previous meeting +**\** 3. More preparation for [96boards.org OpenHours showcase for Kovri / Monero](https://github.com/monero-project/meta/issues/46) (@fluffypony @danrmiller location status) +**\** 4. Status (again) of [Monero HackerOne umbrella and bounty](https://github.com/monero-project/meta/issues/39). [hackerone.com/monero](https://hackerone.com/monero) is online but we need to resolve FFS funding before inviting researchers. VRP status for all projects + bounty status +**\** 5. Open forum for https://github.com/monero-project/kovri/issues/630 +**\** 6. Website status (@rehrar @bigreddmachine @alvinjoelsantos @danrmiller) +**\** 7. @EinMByte ...where is he? Github repo privilege discussion +**\** 8. Code + ticket discussion / Q & A +**\** 9. Any additional meeting items +**\** 10. Confirm next meeting date/time +**\** Hello +**\** hi +**\** hey! +**\** o/ +**\** Here +**\** \o +**\ {-fluffypony}** hi! +**\** Here for a bit, then gone, then back. +**\** Yay, enough people for a party. +**\** Hello +**\** 2. Brief review of what's been completed since the previous meeting +**\** 3...2...1... KOVRI!!! +**\** hello +**\** For me, see http://forum.getmonero.org/9/work-in-progress/86967/anonimal-s-kovri-full-time-development-funding-thread?page=&noscroll=1#post-90900 +**\** moroccanmalinois can fill us in on his work. +**\** i've been playing with fuzz testing +**\ {-fluffypony}** nice +**\** I've looked through the PR's, looks like fun. +**\** it's the beginning. More tests to come +**\** Any questions/comments on point 2? +**\ {-fluffypony}** and guzzi ? +**\** guzzi is not here, ...again... +**\** He says he's doing work but I haven't seen a commit or question from him in over 7 weeks, AFAICT. +**\** I think he's trying to separate the contexts from the singleton. At least that's the end goal. +**\ {-fluffypony}** guzzi: when you read this, please make an effort to attend meetings +**\ {-fluffypony}** I know you're around at other times, but meetings are important +**\** Yes, please. +**\** Ok, anything else on 2.? +**\ {-fluffypony}** no +**\** 3. More preparation for [96boards.org OpenHours showcase for Kovri / Monero](https://github.com/monero-project/meta/issues/46) (@fluffypony @danrmiller location status) +**\** Is pigeons still in Africa? This point was moved from last meeting. +**\ {-pigeons}** i returned yesterday +**\** Are you suggesting pigeons migrate ? +**\ {-pigeons}** i saw rock doves +**\** fluffypony? How's it going? +**\ {-fluffypony}** anonimal: it's a podcast, right? +**\** https://www.96boards.org/openhours/, there are videos too. +**\ {-fluffypony}** ok well I'm ready whenever +**\ {-fluffypony}** I don't really prepare for stuff like this +**\** sorry i'm late! +**\** Ok well what time/date works for you? +**\** fluffypony ^ +**\ {-fluffypony}** anonimal: my PA would have to schedule it - probably best to get my PA to schedule myself and pigeons and them +**\ {-fluffypony}** she's good at that +**\ {-fluffypony}** it's literally her job :-P +**\ {-pigeons}** I was thinking ask hyc if he's interested, he's been playing with arm and monero i think +**\ {-fluffypony}** cool +**\ {-fluffypony}** hyc is a beautiful man +**\** +1 Ric's PA. She was great when i wanted to schedule a podcast +**\* anonimal** pinged him in #monero-dev +**\** Ok well at this point, IMHO, fluffypony I think it would be good for you to touch base / introduce yourself to sdrobertw in #OpenHours on freenode. +**\** I think I can only play the middleman for so long. +**\ {-fluffypony}** email is better for Shay, I don't think I can teach her IRC :-P +**\** Contact info? I have none. +**\ {-fluffypony}** for them? +**\ {-fluffypony}** didn't we reach out to them via email first? +**\ {-fluffypony}** \* can't remember +**\** For Shay +**\** No, not via email, all IRC. +**\ {-fluffypony}** oh lol +**\ {-fluffypony}** pa@spagni.net +**\** Alright, anything else on this point before moving on? +**\** 4. Status (again) of [Monero HackerOne umbrella and bounty](https://github.com/monero-project/meta/issues/39). [hackerone.com/monero](https://hackerone.com/monero) is online but we need to resolve FFS funding before inviting researchers. VRP status for all projects + bounty status +**\** I've sent a VRP to monero, it's been merged. I believe we're funded at ~500 XMR, which is great. +**\** Any questions? +**\** We just need to launch after submitting VRP to the GUI (and site?) +**\** Sound good? +**\** Is the bounty held in xmr or something else? +**\** Yes. Link to FFS in the meta issue. +**\** https://forum.getmonero.org/8/funding-required/87597/monero-bounty-for-hackerone It was funded to 500 XMR and then increased to 1000 XMR for further funding +**\** ty +**\** I think we can start now before funding is at 1000. +**\** (it won't mean we'll find researchers immediately anyway) +**\** Any questions/comments before moving onto next point? +**\ {-fluffypony}** yrah +**\ {-fluffypony}** agreed +**\ {-fluffypony}** we can continue to increase it as necessary +**\** Ok. Moving on, +**\** 5. Open forum for https://github.com/monero-project/kovri/issues/630 +**\** Comments needed before we move on this. +**\ {-fluffypony}** I agree with MoroccanMalinois, but I think it's manageable if we set a severity +**\ {-fluffypony}** and some caveats +**\** Maybe a strict validity domain definition would do good (ie, "we only accept vulns in the following categories"). +**\** And then expand the list as stuff matures. +**\** moneromooo - why would we restrict? +**\** To prevent known problems from being reported, or problems in stuff that is known to be unfinished. +**\ {-pigeons}** because the code has a bunch of legacy mess and is early state with low hanging fruit that is just later on the to fix when that section gets refactored +**\** Yes. So, with that said, I don't know what categories we could even have. +**\** *at this stage* +**\** moneromooo: did you have any ideas on categories for this stage? +**\** No. I've not really looked at kovri yet, despite saying I would (sorry). +**\ {-pigeons}** i2p consensus related issues +**\ {-pigeons}** if we implement like X we might cause incompatibility +**\ {-pigeons}** maybe those but again maybe those are known and will be fixed when those sections are given love +**\** Anything which can leak keymat. Good starting point. +**\** Ideally you'd start giving bounties when you know you've done what you could, and the bounty to find bugs is less than what your time is worth looking at it :) +**\** pigeons: Well, then I think that's java I2P's problem because they would then have to keep up with us. What we could do now though is start with a research-related category for general specifications? +**\** So it's a bit subjective. +**\** moneromooo: indeed, and this is border-lining on simply hiring a new dev too with the funds available. +**\** Well, the draw is that the bounty ensures results for the money. +**\** So expert time. +**\** What if we opened bounty for non-implementation research? I know this is an MRL area though. +**\** Or we could open more categories for implementation but the payout is smaller because code is Alpha? +**\** For finding bugs in the theory, definitely worth doing so (for monero anyway, I expect kovri's following established research already). +**\** (then they would risk waiting to beta to 0day to get bigger payout?) +**\** what up kids? I'm here. +**\** I think monero's research is more vetted than I2P's, even though I2P has been around longer. Simply because there are less moving parts. +**\** +1 for bounty for non-implementation research +**\** Interesting. +**\** Just my opinion. I've read the I2P papers available, I'm not blown away but it's better than nothing. +**\** And not like I'm in a position to drop everything to do purely research so... +**\** We'll add categories for bounty? One obvious one being research. Maybe crypto implementation sooner than later since that's a big one. +**\** Sound fair? +**\** From a relative outsider, it seems like a sensible start. +**\** yes. is "leaked info" too broad of a category? +**\** yes for me +**\** Yes because a leak would cover too much code that hasn't been vetted. +**\** \* could cover +**\** Ok, I'll get that going then. +**\** Moving on. 6. Website status (@rehrar @bigreddmachine @alvinjoelsantos @danrmiller) +**\ {-pigeons}** I need to talk with fluffypony about a potential dns thing +**\** aight, so just in case somebody hasn't seen the Kovri web design here it is: http://imgur.com/a/An8K8 +**\** it's the top one +**\ {-pigeons}** then the demo of ajs' site should be up +**\ {-fluffypony}** I got msgs about it +**\ {-fluffypony}** will look at it tomorrow +**\** it's based on the same framework as the getmonero.org website, so once the custom framework is made for one, it is easy to make pages for the other +**\** my update is that we're making the framework even now, and it's coming along well, I should be able to make a few experimental Kovri pages soon +**\** The question is content. +**\** I think the "It's I2P, but in C++" phrase should go; we should use our standard "A secure, private, untraceable C++ implementation of the [I2P anonymous network](https://getmonero.org/knowledge-base/moneropedia/i2p)" +**\** I will work with rehrar to write up some content, but need direction on what should be included. +**\** that's fine. Copy is not indicative. :) +**\** My past month has been packed getting ready for my phd comprehensive exam (1 step before the defense). So I haven't looked at the site yet, but talked briefly with ajs about it and plan to get more involved now that that's done. +**\** Other than that, can we move this item to the website meeting in #monero in 10 minutes? +**\** sure, that sounds alright. +**\** It looks nice (says the cow who's got no clue about design). +**\** K +**\** bigreddmachine ajs: will you be around in 10 minutes in #monero? +**\** Yes +**\** yeah, i'm also editing tonight's podcast episode so i may take a minute to reply +**\** rehrar: yes, what moneromooo said, looks nice +**\** cool. If people have ideas for content that are not on the demo site +**\** Ok, moving on. 7. @EinMByte ...where is he? Github repo privilege discussion +**\** let me know +**\** I'd like to have a simple website for alpha release :) +**\** fluffypony: so... his last commit was from Septemeber 19th, he's not responded to 99% of my pings since then... +**\** i haven't seen him since i started getting involved in Jan +**\** I speak highly of him and his work, I think he's a great contributor and wish he was around more. +**\** could be a legal issue? +**\** The problem is he's not around anymore, he has assigned issues of which I've had to assign myself since he's not around to do them. +**\** And he has repository push access. If something happened to him and his account is compromised, we could be left in an embarrassing trolling situation where someone deletes the repo. +**\** I don't want to send any wrong signals but I also think access privileges should be on an as-needed basis. +**\** i think that's fair. can always be re-established if he comes back and he can be verified +**\** in that vein, should things like Salti tracking be moved to another place? +**\** I don't know, we'll have to bring that up at the next meeting I think since we're running out of time. +**\** fluffypony: any thoughts about this? Will you remove EinMByte's github push access privileges? +**\** I think it's fair to revoke for inactivity and failure to reply to pings. Reinstate when back. +**\** okay, can we add #619 to next meeting's agenda? +**\** I'd also want to remove warptangent's key (unlikely to be back to use it) and a few others. +**\** bigreddmachine: oh, sure I guess, more research/info needed. +**\** k i'll just reply to the issue and talk about it there for now. sorry to jump into other discussion about that. +**\** No problem +**\** Since we're running out of time, 8. Code + ticket discussion / Q & A +**\** last update from me — mozilla work continues with the proxy stuff, but not ready yet. i don't have a good feel for how long +**\** Anything pressing? Questions/comments that can't be answered on github or after the meeting? +**\** Ok, thanks bigreddmachine +**\** not from me, I'll be in contact :( +**\** :) +**\** 9. Any additional meeting items +**\** none. thanks anonimal! +**\** Nothing from me, other than I need to AFK rehrar so, bigreddmachine ajs pigeons if you want to talk more about kovri-site then I'll have to read backlog +**\** aight, thanks. +**\** Now over to monero! +**\** K +**\** Thank you all if you keep the torch burning for the site, awesome. +**\** 10. Confirm next meeting date/time +**\** 2 weeks, same time? +**\** indeed +**\** Ok. Thanks everyone :) \ No newline at end of file diff --git a/_posts/2017-05-07-overview-and-logs-for-the-dev-meeting-held-on-2017-05-07.md b/_posts/2017-05-07-overview-and-logs-for-the-dev-meeting-held-on-2017-05-07.md new file mode 100644 index 00000000..0443fc29 --- /dev/null +++ b/_posts/2017-05-07-overview-and-logs-for-the-dev-meeting-held-on-2017-05-07.md @@ -0,0 +1,291 @@ +--- +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 +--- + +*May 7th, 2017* + +# Overview + +An overview [can be found on MoneroBase](https://monerobase.com/wiki/DevMeeting_2017-05-07). + +# Logs + +**\** 1. Greetings +**\** 2. Brief review of what's been completed since the previous meeting +**\** 3. Code + ticket discussion / Q & A +**\** 4. MyMonero-in-tree discussion +**\** 5. Any additional meeting items +**\** 6. Confirm next meeting date/time +**\** so let's start with 1. Greetings (aka roll call) +**\** hi +**\** hi +**\** present +**\** hello! +**\** tewinget apologises, he'll be late +**\** Sup +**\** o/ +**\** Yo +**\** hyc / luigi1111 / ArticMine / othe / smooth / anonimal / binaryFate / dEBRUYNE / dnaleor / gingeropolous / iDunk / IPGlider / Jaquee / jwinterm / kenshi84 / knaccc / luigi1112 / luigi1115 / NoodleDoodle / papalazzarou / pigeons / RedLion[m] / redlion +**\** hhelo +**\** :) +**\** also me +**\** medusa +**\** anyone I forgot +**\** o/ +**\** oh those are not present whoops +**\** lol vtnerd +**\** ok so +**\** 2. Brief review of what's been completed since the previous meeting +**\** merged a bunch PRs +**\** kenshi84's GPG key changed +**\** I've confirmed it via sidechannel +**\** we have a new sweepbelow function in the CLI, which you may find useful +**\** we also have a new heavier bias in output selection towards newer outputs +**\** moneromooo can fill us in on that +**\** Hi +**\** oi +**\** smart mining is enabled in the GUI +**\** as in the selection box +**\** Hmm, I just twiddled the settings for the recent output selection, really. To match some data in the Miller et al paper. +**\** which is pretty cool +**\** indeed +**\** also Jaquee has done some work on getting iOS back on track after it borked (visually) +**\** well iOS / mobile +**\** which brings us to +**\** 3. Code + ticket discussion / Q & A +**\** yes. and there's some new translations added to gui +**\** we have a number of open PRs +**\** when tewinget is off his bus he can update us on 0MQ +**\** which I'd REALLY like to move forward with ASAP +**\** it's been sitting in a holding pattern for ages +**\** Snipa: also if you're around maybe you can update us on the testing on that ? +**\** I'd like it to be optional, so it can be merged (and thus tested), without causing massive breakage if it does break. +**\** afaik that was the case +**\** sounds like a good idea +**\** also disposable addresses is still hanging around - I think that's pending a review from one of the luigis? +**\** AFAIK yes. Also RandomRun had an idea to make it better. +**\** I don't think there's a problem with that hanging around and being improved +**\** as long as the parallel MRL write-up is there +**\** I'd like to discuss 1998 +**\** the PR, not the year +**\** https://github.com/monero-project/monero/pull/1998 +**\** at this point in time I'm still swaying towards prevent-user-stupidity-by-default +**\** at the slight inconvenience for a power user / sysadmin who might go "omg really" and then add the flag +**\** I know vtnerd feels the same way, which is why he added it in the first place +**\** I'd be interested in strong arguments for removing the flag +**\** wouldnt a text disclaimer be enough? +**\** i don't have a strong opinion +**\** Jaquee: if you try bind externally and start it without the --confirm-external-bind flag then it refuses to start +**\** and it tells you why +**\** ok. apparently hyc started the discussion. Are you around? +**\** I know hyc doesn't like it +**\** vtnerd: has anyone else expressed disdain for it? +**\** AFAIK, just the people on that PR and the one referenced +**\** and possibly one person in IRC, but they seemed to be questioning why it was necessary (I think) +**\** its somewhat low effort to get around it, so most people just add the flag I thnk +**\** no one has privately contacted me about it for any reason if that was the question +**\** ok +**\** unless hyc comes in I move to close the PR, we can always re-open it later +**\** ok with me +**\** ok next PR for discussion is 2011 +**\** moneromooo had concerns that it was touching consensus critical issues +**\** so/issues/part of the code +**\** Yes, but it turns out it's actually bypassed when a tx comes from a block. The patch is fine. +**\** I OK'd it since. +**\** ah ok' +**\** Well, wait. +**\* fluffypony** stops...hammer time +**\** It's really uneeded (only the wallet bit was wanted). But it's not forkworthy. That said... +**\** Older wallets *might* create txes which aren't relayed by newer daemons. +**\** That's fairly unlikely, since my code targets 2/3 of max size, but the size approximation is not very precise. +**\** That said, I think it's fine to merge. +**\** hey. just popped in. reading history +**\** hi hyc ! +**\** Re: 2011, perhaps it also should be dependent on the fee priority level used +**\* fluffypony** plays elevator hold music +**\** ok, if n0b0dy else cares about that external bind thing then whatever. to me it's redundant +**\** ok +**\** since you had to explicitly request a non-localhost address already +**\** sure, but you'd be surprised how few people know that 0.0.0.0 exposes everything :-P +**\** ^ +**\** it d0esn't protect against typos/accidents. it only pisses off people who expect the computer to do as it's told +**\** hyc: view it like a weak password warning +**\** you can't just expect the computer to accept 1234 as a password +**\** yeah, ok... +**\** Well, I would... +**\** lol +**\** moneromooo is the exception to every rule :-P +**\** now on the GUI side, the only thing I wanted to bounce around is 688 +**\** 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 +**\** https://s-media-cache-ak0.pinimg.com/originals/c1/e1/bf/c1e1bfd7fb2770f6745d95af8bf89865.jpg +**\** like that style +**\** https://s-media-cache-ak0.pinimg.com/originals/43/6e/74/436e746b35142f41d5f9bb8e765963e4.jpg +**\** http://eyeviewportal.com/filecache/b38/73d/85-cropped-w545-h409-of-1-FFFFFF-evappguiguidecontentimage002.jpg +**\** like that +**\** sounds good +**\** :+1: +**\** problem is [?] is not around if you use native title bar +**\** Jaquee: where else could we add a help button? bottom left? +**\** 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 +**\** recall it -> the help screen +**\** i think ^ is good as a start +**\** Where is it on the title bar then, since it's not a WM thing ? +**\** endogenic: agreed +**\** s/Where/Why/ +**\** but some buttons could need longer desriptions +**\** like sweepunmixable and paymentid for example +**\** Jaquee: there's enough space in the help overlay, we can use a smaller font to explain them +**\** how breadwallet on ios handles it when setting up is quite good +**\** or move the help to somewhere where there's space +**\** and use an arrow +**\** yeah. we could find a place for that help button +**\** ok - any other PRs that need discussion or can we move on? there's general Q&A shortly +**\** I'd like to merge 261 on monero-site +**\** sgp: there's a website meeting after the Kovri one +**\** so we can discuss it then +**\** ok +**\** ok so +**\** 4. MyMonero-in-tree discussion +**\** 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 +**\** 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 +**\** 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) +**\** is it carved in stone now +**\** if we need to tweak it we can still do that? +**\** is the license unrestricted? +**\** 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) +**\** redlion: BSD 3-clause +**\** hyc: as long as mWo12 changes it, and we match the changes in the live backend and the new backend then yse +**\** yes +**\** we can make any changes, and we WILL make changes to make it smarter +**\** If it's beneficial to monero and it works fully by itself without needing proprietary gunk, then I'm OK with it. +**\** eg. tx history comes in raw, instead of paginated +**\** so that needs to change +**\** +1 moneromooo +**\** moneromooo: yeah the new backend will use LMDB instead of mysql +**\** so it will be unencumbered in the source +**\** As long as there are no proprietary dependencies I am fine +**\** I like it even more now ;) +**\** I think it beneficial too +**\** Maybe a separate repo (similar to monero-core) might be best, but that's details. +**\** \*its +**\** it's +**\** it's +**\** can't wait to run a mymonero node myself! +**\** also the current "primary" wrapper around the DB is actually C, so theres that for you guys +**\** moneromooo: I thought about that, but it's a single daemon that *should* exist in the repo alongside the wallet RPC etc. +**\** doesn't it supersede wallet-rpc? +**\** now +**\** hyc: no +**\** wallet-rpc is good for integration, this isn't +**\** there is obviously an element of centralisation, but it’s nearly impossible to avoid +**\** also on this topic +**\** Jaquee has begun working on client integration in the CLI and GUI +**\** "client integration" ? +**\** you mean for light-wallets? +**\** that will mean that both CLI and GUI will be able to run in lightweight / remote-scanner / MyMonero mode +**\** moneromooo: as opposed to implementing the server protocol +**\** sounds good +**\** Oh, mymonero client integration ? +**\** moneromooo: let's call it something else +**\** That went pretty damn fast :D +**\** "lightweight wallet" +**\** it's not really centralization if any `monerod` acts as a server +**\** but I'm still missing why we need old wallet-rpc if this mymonero api exists +**\** it's literally my monero :) +**\** hyc: wallet-rpc is completely different +**\** so the core GUI will be able to interact with MyMonero backend too? +**\** for people that want to run VPS node but keep their viewkey ? +**\** Yes, would be nice to see what bits are needed where, and the actual API (even if roughly). +**\** it provides an API for integrators +**\** @johnalan yes +**\** so basically +**\** is this needed with the MyMonero Desktop wallet? +**\** With what as the backed / server +**\** That can be posted later though, :49 now. +**\** monerod? +**\** lightweight wallets will have 3 server options: +**\** 1. OpenMonero +**\** 2. the new in-source backend that vtnerd is working on +**\** 3. the live MyMonero backend +**\** it will also have multiple client options: +**\** afaik the main difference btw an ordinary wallet and mymomero is you tell mymonero your viewkey +**\** 1. OpenMonero's web wallet (clone of the current MyMonero web wallet) +**\** and the ordinary wallet has all your keys +**\** 2. the MyMonero applications +**\** 3. monero-wallet-cli +**\** 4. monero-wallet-rpc +**\** 5. the Monero GUI +**\** hyc: monero-wallet-rpc can still use this on the backend +**\** so it's unrelated +**\** ok +**\** ok +**\** 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% +**\** also this will mean that the GUI / CLI may end up supporting the MyMonero 13-word seed derivation by virtue of the integration effort +**\** does anyone have a fundamental issue with that ? +**\** no +**\** I mean, I do, because I don't want to be abusing my position, but it is what it is :-P +**\** didn't you deprecate 13-word? +**\** Did you not say the 13 word seed was going to be obsoleted ? +**\** jollymort: working on it +**\** no +**\** but client still needs to be able to read 'em +**\** electrum/mycelium support a few different seed lengths iirc +**\** works well +**\** also luigi was playing around with an idea for 17-word, integrating creation height in it etc +**\** moneromooo: it's import only +**\** not create +**\** https://github.com/mymonero/mymonero-app-js/issues/77 +**\** 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? +**\** Anyway, I'm fine with that as presented. +**\** 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 +**\** so monero-wallet-cli/monero GUI will not be able to create light-wallets? +**\** knaccc: yes it does - about 10 minutes +**\** yeah import only sounds lovely +**\** If we are setting the stage for a competitive market based upon FLOSS then I am fine with it +**\** I do have the ASM code working, so hopefully that will tighten up some too (altough there is something else blocking that) +**\** shuannelson: yes they will +**\** but with 25 word seed, not 13 +**\** we have 7 minutes left - so I'd like to move on to the last item +**\** awesome! +**\** we can discuss MyMonero more after the meeting +**\** @shaunnelson, I think it's just that the CLI/GUI won't create 13-word seeds, but will accept already created ones +**\** yeah sounds fine +**\** 5. Any additional meeting items +**\** 10 mins is quite a speedup vs downloading the entire blockchain, so sounds awesome. +**\** any thoughts on future of penalty/blocksize? i kind of left the research open-ended +**\** ^^ get a faster CPU and it'll be quicker ') +**\** 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 +**\** lol hyc +**\** redlion: pls come join #mymonero but yes i do :) +**\** redlion: i have. it has some nasty bugs but it's running +**\** ok thanks, I'll talk to you after this +**\** btw iOS still limits process VM size to 4GB so we won't be running monerod native on iOS any time soon +**\** @jollymort let's discuss it after the meeting, or maybe next week - there are 2 more meetings to go tonight :) +**\** and that's a large topic +**\** sure, another time +**\** thanks jaquee, are there any build instructions or a (sort of) working build posted somewhere? +**\** 6. Confirm next meeting date/time +**\** May 21 +**\** day before Consensus +**\** cool +**\** oh. this week I expect to have wolf miner fully ported to Android, with GPU support too +**\** endogenic can come to my hotel and we can do the meeting together :-P +**\** oooh +**\** 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. +**\** 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?) +**\** suweet +**\** just check the meeting logs for the bit from moneromooo about it +**\** (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.) +**\** 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. +**\** great stuff +**\** pigeons: did you see the 96boards thing? +**\** 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. +**\** ok cool +**\** tewinget: is the 0MQ stuff deselectable if needed (so if it somehow breaks, you can run the wallet with the existing JSON comms) ? +**\** wallet/daemon +**\** moneromooo: I'll make it so when I rebase the wallet side of things. +**\** Excellent, thank you :) \ No newline at end of file