monero-project/monero-site
monero-project/monero-site
1
0
Fork 0
mirror of https://github.com/monero-project/monero-site.git synced 2025-01-10 21:05:04 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Logs for the Kovri and Dev meetings held on 2017-03-26

Browse source
This commit is contained in:
dEBRUYNE-1 2017-03-27 18:17:44 +02:00
parent 2fabae42fc
commit ae99d4e832
No known key found for this signature in database
GPG key ID: B9145F6EBFA81C32
2 changed files with 588 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

246
_posts/2017-03-26-logs-for-the-Kovri-dev-meeting-held-on-2017-03-26.md Normal file
View file

@ -0,0 +1,246 @@
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2017-03-26
summary: Brief review of what has been completed since last meeting, Monero HackerOne Bounty, and code & open tickets discussion
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*March 26th, 2017*
# Logs
**\<anonimal>** 1. Greetings
**\<anonimal>** 2. Brief review of what's been completed since the previous meeting
**\<i2p-relay> {-vtnerd}** oh I guess there is one more thing. the backend was going to hopefully push updates to connected clients
**\<anonimal>** 3. Monero HackerOne Bounty https://www.reddit.com/r/Monero/comments/5zmywx/monero_bounty_for_hackerone/
**\<i2p-relay> {-fluffypony}** ok anonimal, all yours
**\<anonimal>** 3. Code + ticket discussion / Q & A
**\<anonimal>** 4. Any additional meeting items
**\<anonimal>** 5. Confirm next meeting date/time
**\<anonimal>** Greetings.
**\<samsunggalaxyplayer>** hey!
**\<guzzi>** Hi
**\<i2p-relay> {-olark}** o/
**\<guzzi>** Sweet olark
**\<i2p-relay> {-olark}** Yeah I missed the monero meeting unfortunately :/
**\<i2p-relay> {-olark}** I'll read the logs
**\<guzzi>** Really good meeting
**\<anonimal>** On topic please
**\<anonimal>** 2. Brief review of what's been completed since the previous meeting
**\<anonimal>** https://forum.getmonero.org/9/work-in-progress/86967/anonimal-s-kovri-full-time-development-funding-thread?page=&noscroll=1#post-90733
**\<anonimal>** ^ for a summary on my part
**\<anonimal>** moroccanmalinois has done some great work since the previous meeting. We have a new utility binary with multiple features. He's also done work elsewhere in the codebase.
**\<moroccanmalinois>** :)
**\<anonimal>** guzzi has also contributed to the utility binary. guzzi can you link to your FFS if you're doing work summaries/reports?
**\<moneromooo>** What does this utility binary do, in a nutshell ?
**\* anonimal** wants to say ./kovri-util -h
**\<guzzi>** I will add summary tonight
**\<guzzi>** On phone
**\<moneromooo>** OK, I'll try to pull someday and check :P
**\<anonimal>** guzzi: then give us a tl;dr for point 2. please
**\<moroccanmalinois>** moneromooo base32, base64, routerinfo( reads a RI file) and su3file (reads an su3file)
**\<moroccanmalinois>** and the crypto benchmark
**\<guzzi>** Added benchmarks to utility
**\<anonimal>** guzzi: I already said that, didn't you do other things too? Like research, etc.?
**\<guzzi>** Starting in on instance class refactor a d todos
**\<guzzi>** Researched address book for possible lmdb
**\<guzzi>** Sgould be easy
**\<guzzi>** Should
**\<anonimal>** What should be easy? None of that looks easy...
**\<anonimal>** Anyway, we'll save that for later. Anything else on point 2.?
**\<guzzi>** Relatively easy from db perspective. Difficult from kovri perspective yes
**\<anonimal>** 3. Monero HackerOne Bounty https://www.reddit.com/r/Monero/comments/5zmywx/monero_bounty_for_hackerone/
**\<anonimal>** fluffypony: ^ thoughts?
**\<i2p-relay> {-fluffypony}** so my thoughts is that we should just do a general fund across all the projects
**\<i2p-relay> {-fluffypony}** because HackerOne let's us basically apportion stuff as needed
**\<i2p-relay> {-fluffypony}** so we don't have to give out the entire bounty for some stupid XSS attack
**\<anonimal>** Ok. I'll have to talk with them about setting up Monero. Do we include the GUI into /monero or create /monero-gui? We can probably wrap it into /monero if needed. Do we create /monero-site ?
**\<i2p-relay> {-fluffypony}** anonimal: everything goes under the Monero umbrella / bounty, right?
**\<i2p-relay> {-fluffypony}** just that each actual sub project can be represented
**\<anonimal>** I'm speaking purely about H1 accounts.
**\<anonimal>** We do whatever we want with fund management.
**\<anonimal>** fluffypony: it's possible but then all monero developers have access to all bug reports for all subprojects
**\<anonimal>** So that brings up a trust issue. I'm fine with the idea but it should be mentioned.
**\<i2p-relay> \* fluffypony** ponders
**\<anonimal>** Also I'd like to have access to the account as account holder. This is something I couldn't do if we throw into one account.
**\<anonimal>** And whoever is the account holder for all subprojects has *that* responsibility. And if the single account is ever compromised...
**\<anonimal>** In other words, it's not very decentralized in terms of who controls accounts.
**\<i2p-relay> {-fluffypony}** anonimal: doesn't really matter if it's compromised, because there's no money there?
**\<anonimal>** fluffypony: it's about access to reports. If we don't care about who has access to reports, then there's not much reason to use HackerOne
**\<i2p-relay> {-fluffypony}** mooneroo: for the monero-project GitHub account the core team all have the password, because there's no easy way to share that control otherwise - could we not do the same for H1?
**\<anonimal>** I mean, there are features/benefits, but access to vulnerabilities is a big issue.
**\<i2p-relay> {-fluffypony}** amongst maintainers I mean
**\<anonimal>** pinging mooneroo or moneromooo?
**\<anonimal>** We could do that I think.
**\<moneromooo>** Well, some members of hte monero core team are pretty much inactive AIUI. So no need to get them access to this.
**\<i2p-relay> {-fluffypony}** whoops
**\<i2p-relay> {-fluffypony}** I meant anonimal
**\<i2p-relay> {-fluffypony}** sorry ignore typo
**\<i2p-relay> {-fluffypony}** anonimal: for the monero-project GitHub account the core team all have the password, because there's no easy way to share that control otherwise - could we not do the same for H1?
**\<i2p-relay> {-fluffypony}** moneromooo: would be among maintainers
**\<i2p-relay> {-fluffypony}** lol
**\<i2p-relay> {-fluffypony}** the core team have passwords for stuff like this as a fallback
**\<anonimal>** I don't think inactive people should have access to H1. Only on a as-needed basis. Maybe when they become active again?
**\* moneromooo** misread anonimal's ping, nevermind
**\<ArticMine>** The drop dead theory
**\<i2p-relay> {-fluffypony}** ^^
**\<i2p-relay> {-fluffypony}** it's just an anti-bus factor
**\<i2p-relay> {-fluffypony}** the main people using it would be maintainers, which are currently just me and anonimal
**\<moneromooo>** I was given access a while back (though might have been rescinded by now).
**\<anonimal>** No, you have access to kovri
**\<i2p-relay> {-fluffypony}** and I don't think there's a big issue with maintainers having visibility on other reports
**\<anonimal>** As does EinMByte but is he still alive?
**\<anonimal>** Alright, so any other big issues with merging everything into a single account?
**\<anonimal>** And how many subprojects do we apply this too? I can PR the VRP to all appropriate subprojects and update docs as needed.
**\<i2p-relay> {-fluffypony}** we can always split it out later
**\<i2p-relay> {-fluffypony}** I think the only relevant projects are: GUI, CLI, Kovri, site
**\<anonimal>** I imagine the site and forum could gain from this too.
**\<i2p-relay> {-fluffypony}** forum is being deprecated, so let's leave it off
**\<i2p-relay> {-fluffypony}** but there will be some forum functionality moving into the site (FFS in particular)
**\<i2p-relay> {-fluffypony}** so keeping the site there is necessary
**\<anonimal>** Ok
**\<i2p-relay> {-fluffypony}** anonimal: maybe an infrastructure one too, which is pigeons' domain?
**\<jacobjeweler>** Nodepool code perhaps?
**\<moneromooo>** Meh. And no real maintainer.
**\<jacobjeweler>** Snipa's work
**\<i2p-relay> {-fluffypony}** @JacobJeweler no, that's not a core project
**\<i2p-relay> {-fluffypony}** external projects can do their own H1 stuff
**\<anonimal>** fluffypony: sure, as long as we can communicate that to people e.g., use the Meta repo has a point of contact + place to post VRP etc.
**\<i2p-relay> {-fluffypony}** I think we should come up with a paragraph for the READMEs
**\<anonimal>** Ok. We need the VRP somewhere though. It's solid (moreso than having nothing).
**\<pigeons>** we lost irc2p again
**\<i2p-relay> {-pigeons}** ok i'll file a few reports as someone else for a bounty then
**\<i2p-relay> {-fluffypony}** works here pigeons
**\<moneromooo>** One thing also that's probably needed: a list of "this does not count". Like all that's known already.
**\<i2p-relay> {-pigeons}** hmm yeah, just some selective drops, oh well
**\<moneromooo>** But this is easily a bone of contention otherwise.
**\<anonimal>** moneromooo: that's included in H1. We can incorporate that into one of the features they have.
**\<i2p-relay> {-fluffypony}** moneromooo: agreed
**\<i2p-relay> {-fluffypony}** every report is subjective
**\<anonimal>** (iirc)
**\<anonimal>** Ok, so I will contact them and move these into a single account.
**\<anonimal>** And do all the related things necessary.
**\<anonimal>** As for funding,
**\* anonimal** reads backlog for fluffypony's message
**\<anonimal>** "general fund across all projects"
**\<anonimal>** Ok,
**\<anonimal>** separate from the dev fund? i.e., separate address too?
**\<i2p-relay> {-fluffypony}** this will be an FFS
**\<i2p-relay> {-fluffypony}** just open-ended with some minimum
**\<anonimal>** Ok, so no separate donation address. All FFS, and funds are held like the dev fund?
**\<anonimal>** (or like any FFS project)
**\<i2p-relay> {-fluffypony}** yes
**\<i2p-relay> {-olark}** How much money should we aim to raise for H1?
**\<i2p-relay> {-olark}** Assuming this will need to be replenished every now and then.
**\<i2p-relay> {-fluffypony}** I have no idea - suggestions?
**\<anonimal>** https://forum.getmonero.org/6/ideas/87597/monero-bounty-for-hackerone suggested 500 total for all projects
**\<anonimal>** (500 XMR)
**\* anonimal** checks value
**\<i2p-relay> {-fluffypony}** olark: yes but bounties are normally denominated in USD
**\<i2p-relay> {-fluffypony}** so potentially it wouldn't need to be replenished, or hardly
**\<i2p-relay> {-fluffypony}** unless we have lots and lots of exploits
**\<anonimal>** Hmmm... well, at current price, 500 seems reasonable IMHO. That could attract some serious researchers.
**\<anonimal>** Thoughts?
**\<i2p-relay> {-olark}** Probably easier to outline what the rewards should be for LOW, MEDIUM, and HIGH severity of vulnerabilites and then figure out how much money should be raised.
**\<anonimal>** We don't have X thought: X being how many of Y.
**\<anonimal>** *though
**\<anonimal>** If we run out of the fund, we can always open a new FFS.
**\<i2p-relay> {-olark}** 500 xmr seems like a good start anyway.
**\<i2p-relay> {-fluffypony}** yeah let's just stick to that and see how it goes
**\<anonimal>** Ok
**\<i2p-relay> {-olark}** Right.
**\<anonimal>** Awesome. Anything else on point 3.?
**\<i2p-relay> {-fluffypony}** next?
**\<anonimal>** Do we extend 20 minutes or are we screwed because of earlier?
**\<moneromooo>** There are two point 3s.
**\<moneromooo>** Extend, and whoever wants to leave leaves :)
**\<i2p-relay> {-fluffypony}** we can extend to finish up, but let's do it ASAP so I can move on to tagging and releasing
**\<anonimal>** lol, yes. Github turns that into 4 if I copypasta. If I get original text, it's 3.
**\<anonimal>** 4. Code + ticket discussion / Q & A
**\<anonimal>** Damn, well, I could easily spend 20-30 minutes on this point because we haven't had a meeting in so long.
**\* anonimal** grabs link instead
**\<anonimal>** Ok, here we are https://github.com/monero-project/kovri/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.1.0-alpha
**\<moroccanmalinois>** A little question about the reload : what is supposed to happen if no param changed ?
**\<anonimal>** #187 isn't as obvious as I had hoped. I'll have to approach it differently, from the basics, and start by actually getting some unit-tests for ntcp.
**\<moroccanmalinois>** if the user didn't specified a port, should it get a new random one ?
**\<anonimal>** So that will be fun.
**\<anonimal>** As for #340, #369 is moot because of the other open ticket for cutting out all unnecessary sig types,
**\<anonimal>** #305 should actually be closed for now,
**\<anonimal>** guzzi is working on #96. It's not mandatory for 0.1.0-alpha release so I may move it to next milestone,
**\<anonimal>** #9 needs review and may not really be needed after all
**\<guzzi>** I can work on those unit tests for ntcp if u want
**\<anonimal>** No that's fine guzzi, thank you.
**\<anonimal>** All that leaves is #46 and #362
**\<anonimal>** ajs is on #46. He's supposed to be in talks with pigeons I think. I haven't heard from ajs in a little while though. ping ajs.
**\<anonimal>** #362 comes at the very end once we tag. I'll throw it on AUR and away we go.
**\* anonimal** reads moroccanmalinois's lines
**\<anonimal>** moroccanmalinois: if no port specified in config, that would be a default option. I don't like that though.
**\<anonimal>** What I think we should do is add a default random port to the config somehow.
**\<anonimal>** Otherwise we jump through these kinds of hurdles. But doing that for binary releases... hmm...
**\<i2p-relay> {-olark}** We could just set a random port when a new router context is initialized.
**\<anonimal>** moroccanmalinois: worst case scenario, if the app is still running during restart (assuming because client and core are the only things being restarted), we reuse the previous port.
**\<moroccanmalinois>** ok
**\<i2p-relay> {-olark}** It currently just defaults to 0 afaik.
**\<anonimal>** ?
**\<i2p-relay> {-olark}** In router context.
**\<i2p-relay> {-olark}** m_Port
**\<i2p-relay> {-olark}** Assuming we are talking about the same thing.
**\<anonimal>** Nope, you're not looking in the right area.
**\<i2p-relay> {-olark}** k
**\<anonimal>** I can explain more after the meeting. moroccanmalinois can probably too because it sounds like he understands the design as well.
**\<moroccanmalinois>** m_Port == 0 means choose a random one. another question : i read somewhere in the java doc about a "Laptop mode", i think the pb it tries to solve is more about dynamic ips. Is it on the roadmap ?
**\<anonimal>** Nope, not on the roadmap but it can be.
**\<anonimal>** Just open a feature request.
**\<moroccanmalinois>** :) ok
**\<pero>** it was just brought to my attention yesterday? that there's a ticket for pr'ing the logo - i was under the impression that my involvement with that was done, but looks like there's some miscommunication and i can get around to that soon-ish
**\<anonimal>** Anything else on point 4.? We don't have to rush this part if needed.
**\<anonimal>** What/
**\<anonimal>** ?
**\<anonimal>** Link?
**\<guzzi>** Learning the instance class
**\<pero>** what what
**\<guzzi>** Anyone apposed to creating member variables for router context and client context.
**\<guzzi>** And giving them proper constructors
**\<guzzi>** It was a todo to find out why they are this way currently
**\<anonimal>** guzzi: please provide line number and file
**\<anonimal>** pero: what's your question?
**\<pero>** there is no question
**\<anonimal>** guzzi: for the TODO
**\<anonimal>** pero: there's a question mark. What is your point?
**\<pero>** where is there a question mark
**\<moneromooo>** After "yesterday".
**\<moneromooo>** Looks like a typo for "".
**\<pero>** this is ticket discussion isnt it - i was chiming in on something that was ostensibly assigned to me without my knowledge
**\<ajs>** anonimal: pigeons said he got a server for #46, but waiting for access to move over files
**\<anonimal>** pero: nothing was assigned to you
**\<anonimal>** ajs: ok thanks
**\<pero>** alright well i guess there's nothing to do then
**\<guzzi>** Instance.cc
**\<guzzi>** Initialize function
**\<guzzi>** First comment inside
**\<guzzi>** Sorry github mobile has no li e numbers
**\<guzzi>** Line
**\<i2p-relay> {-fluffypony}** ok maybe this discussion should happen later when you're at a computer, guzzi
**\<anonimal>** Good idea.
**\<i2p-relay> {-pigeons}** i'm gonna confirm some things from ya'll in a few, fqdn and git repo to pull from
**\<anonimal>** Anything else on 4.?
**\<guzzi>** I will comment in the pr later
**\<anonimal>** guzzi: I know what you're talking about and see what you want, let's talk more later
**\<guzzi>** Cool
**\<anonimal>** 5. Any additional meeting items
**\<anonimal>** No additional items from me afaict
**\<moroccanmalinois>** One last question : an external app that wants to use kovri (like monero GUI), should it includes only the libs ? or it can include things from src/app ?
**\<anonimal>** Nothing from app. I see no reason for it to include anything from app.
**\<anonimal>** Which means we get things out of app that we need elsewhere. I wrote TODO's.
**\<moroccanmalinois>** Perfect. thx
**\<anonimal>** Anything else on 5.?
**\<moroccanmalinois>** not for me
**\<anonimal>** k
**\<anonimal>** 30 seconds...
**\<anonimal>** 6. Confirm next meeting date/time
**\<i2p-relay> {-fluffypony}** 2 weeks (tm)
**\<anonimal>** 18:00 UTC two weeks from today as usual?
**\<anonimal>** Ok
**\<i2p-relay> {-fluffypony}** April 9th
**\<anonimal>** Thanks everyone

342
_posts/2017-03-26-overview-and-logs-for-the-dev-meeting-held-on-2017-03-26.md Normal file
View file

@ -0,0 +1,342 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2017-03-26
summary: 0.10.3.1 release, light wallets, fireice-uk's proposal, and 0MQ
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
---
*March 26th, 2017*
# Overview
An overview [can be found on MoneroBase](https://monerobase.com/wiki/DevMeeting_2017-03-26).
# Logs
**\<fluffypony>** 2. Brief review of what's been completed since the previous meeting
**\<fluffypony>** ok so since the last meeting I guess the main thing is we tagged and released 0.10.3
**\<fluffypony>** which we're about to deprecate
**\<fluffypony>** lol
**\<fluffypony>** are there any issues with 0.10.3 besides the cumulative block size thing?
**\<fluffypony>** now's the time to point them out
**\<hyc>** no idea, but I'm running a build from a couple days ago
**\<Jaquee>** me too. no issues so far
**\<johnalan>** Been running on OSX since yesterday. No issue.
**\<fluffypony>** moneromooo: any idea why the issue seems to affect so few?
**\<hundehausen>** Smart Mining is not working for me on newest macOS
**\<moneromooo>** Dunno. Low level processor specifics I guess, but... shrug.
**\<fluffypony>** hundehausen: it only works on Linux
**\<fluffypony>** not on anything else
**\<samsunggalaxyplayer>** I have smart mining running on Windows right now
**\<Jaquee>** yeah. windows + linux iirc
**\<Jaquee>** but not osx i think
**\<luigi1112>** lunch time
**\<fluffypony>** I like to pretend that Windows doesn't exist
**\<fluffypony>** :-P
**\<Jaquee>** lol
**\<moneromooo>** What is it ?
**\<fluffypony>** moneromooo: you open them to let air in
**\<moneromooo>** Ah, doors.
**\<hyc>** usually lets bugs in too
**\<amiuhle>** smaller sized doors basically
**\<gingeropolous>** drumroll
**\<fluffypony>** lol hyc
**\<btcltcxmrmaximal>** winblows sucks
**\<hyc>** windows and doors in Ireland have no screens. I dunno what's with these people.
**\<fluffypony>** anyhoo
**\<fluffypony>** let's move on
**\<fluffypony>** 3. Discussion of fireice-uk's proposal (as started in #1828
**\<fluffypony>** I'd like to move this to Funding Required
**\<fluffypony>** and fireice-uk updated the funding costs based on current pricing
**\<fluffypony>** obviously there are some consensus-critical aspects to it, so I think it's worth discussing
**\<moneromooo>** Wasn't this a wallet thing ?
**\<btcltcxmrmaximal>** https://github.com/monero-project/monero/issues/1828
**\<xmreric>** Yes. Speedup on Intel/AMD processors, which is helpful considering RingCT has slowed sync down.
**\<fireice-uk>** it is a wallet thing (unless you want to use it somewhere else)
**\<hyc>** ringCT has slowed wallet sync?
**\<fluffypony>** moneromooo: if we replace SUPERCOP then it's consensus critical
**\<vtnerd>** I don't see how ringct slowed down wallet sync ... ?
**\<moneromooo>** Then no consensus issue. And if it proves good for a while, *then* it can be used in consensus.
**\<pigeons>** xmreric: how has ringct slowed down sync?
**\<xmreric>** I thought I had heard that from others
**\<vtnerd>** the additional work comes when a output match is found
**\<fluffypony>** so I guess wallets with thousands and thousands of ringct outputs?
**\<xmreric>** https://monero.stackexchange.com/questions/3718/when-syncing-moneros-blockchain-from-scratch-why-does-it-begin-fast-and-end-sl
**\<fluffypony>** xmreric: that's daemon, not wallet
**\<fluffypony>** 1828 is a proposal for a wallet change
**\<xmreric>** ok
**\<vtnerd>** its more work on the node verifying the block, but not the wallet since its not reading it. I suppose there is some additional time for transmission/marshalling/unmarshalling, but this is smaller than any crypto
**\<moneromooo>** The bottleneck's the daemon anyway.
**\<btcltcxmrmaximal>** daemon sync time seems a lot more important than wallet sync time (in comparison) if our primary goal was to encourage more full nodes.
**\<vertp>** Unless you're using a remote node, no?
**\<hyc>** this complicates the build if we want a crypto/ subtree just for wallet and one just for daemon
**\<moneromooo>** Hmm, fair point.
**\<fluffypony>** ok so then here's a suggestion
**\<Jaquee>** the amount of tx's/day is higher since the date around ringct was activated. So wallet sync slows down. but not really related to ringct
**\<fluffypony>** what if we had cryptoopsbuilder run on build
**\<fireice-uk>** build won't be more more complicated - just more symbols
**\<fluffypony>** and use the existing stuff by default, but optionally use the newer SUPERCOP / whatever
**\<fireice-uk>** my suggestion would be to use ge64* symbols for the new code
**\<moneromooo>** BTW, is that not what you wanted to replace by... tweetnacl or whatver it was ?
**\<fluffypony>** moneromooo: yes
**\<fluffypony>** but only when TweetNaCl has finished formal verification
**\<moneromooo>** And that proposal replaces it with this, or another replacement ?
**\<moneromooo>** Alright...
**\<hyc>** I'd prefer we just keep the generated code statically committed to git
**\<hyc>** no idea what environment the builder might break on
**\<fluffypony>** hyc: the builder is pretty simple (just splicing text really), but it does add a python dep to the build process
**\<hyc>** yeah, let's not do that.
**\<moneromooo>** fireice-uk: did you try running a wallet refresh without any crypto to see how much faster it was at best possible gain ? IIRC, my bottleneck is the daemon (SSD, though CoW fs).
**\<fluffypony>** either way, in the long run I'd like to have a default "safe" crypto implementation, and an optional fast one
**\<moneromooo>** s/without any crypto/with the actual tx scanning disabled/
**\<fireice-uk>** moneromoo: bottleneck is the poor fetching from the daemon
**\<moneromooo>** So changing the crypto won't do a thing right now, right ?
**\<fireice-uk>** it somehow mananges not to max anything
**\<fireice-uk>** that is the part 2
**\<fireice-uk>** crypto is part 1
**\<pigeons>** so likely this is a premature optimization for now
**\<fireice-uk>** pigeons: want to swap round the order?
**\<vertp>** why not swap the orders fireice-uk? And do daemon fetching optimization
**\<fluffypony>** not a bad idea
**\<moneromooo>** Oh ok. There are two things that should be easy win there: store non prunable separately, and maybe fetch a bunch of them at once (wallet refresh always has pretty much N..N+dN txes).
**\<gingeropolous>** so part 2 is the actual optimization? and part 1 is... ?
**\<moneromooo>** I wanted to do the daemon thing for a while, but looks like I won't have to :D
**\<fireice-uk>** gingeropolous: part 1 is crypto optimziation, part 2 is parallelism opt
**\<hyc>** but current discussion says crypto opt will be overshadowed by daemon
**\<fluffypony>** ok so we swap them around and do part 2 first, and then revisit how to structure part 1 after that?
**\<hyc>** makes sense
**\<fluffypony>** fireice-uk: that sound ok?
**\<moneromooo>** Well, that's my recollection of my particular machine anyway. Might differ for others.
**\<fireice-uk>** my suggestion would be to do part 1 first - this way you can have a loot at it before merging
**\<fireice-uk>** \*look
**\<moneromooo>** I want to have a look at 2 also before merging.
**\<hyc>** lol
**\<vertp>** lol.
**\<fireice-uk>** of course, but i assume 1 will require more time
**\<fluffypony>** lol
**\<vertp>** but if its has more immediate benefits, why not go with 2 first?
**\<hyc>** yeah it's sounding like 1's benefits will be unmeasurable for now
**\<vertp>** it makes even more sense to do part 2 first if it is less complex/faster to implement.
**\<Jaquee>** +1
**\<moneromooo>** Yes, do the easy wins first, and the possibly dangerous stuff might not be needed (and will only work on x8664 anyway AIUI).
**\<fireice-uk>** ok, that's fine with me
**\<moneromooo>** Keeping in mind you also need the full blocks to serve syncing peers.
**\<vertp>** great!
**\<fluffypony>** ok cool - I'll move the proposal to funding after the 0.10.3.1 tag
**\<samsunggalaxyplayer>** so in like 3 months /s
**\<fluffypony>** hah hah
**\<fluffypony>** touché
**\<vertp>** Since we are on a similar topic, could I bring up ZMQ? That should also speed up sync time/provide faster wallet func at some point no?
**\<tewinget>** nah, fluffypony doesn't run on tewinget Time™
**\<fluffypony>** vertp: it should provide better scalability for multiple wallets hitting the same daemon
**\<fluffypony>** but I don't think it'll provide speed benefits beyond that
**\<vertp>** so light-wallets. Is there anything new on that front tewinget.
**\<tewinget>** agreed
**\<tewinget>** well, I've been working on merging from upstream this morning
**\<tewinget>** I think I've *just* got it sorted
**\<hyc>** yay
**\<vertp>** woo!
**\<gingeropolous>** !!!!
**\<johnalan>** Nice
**\<fluffypony>** let's stick to the schedule plx
**\<tewinget>** few things changed in core that threw wrenches in the merge >**>**
**\<tewinget>** sorry fluffypony :)
**\<vertp>** yes, sorry.
**\<fluffypony>** ok so
**\<fluffypony>** 4. Remote nodes (ie. a discussion of #605)
**\<moneromooo>** Well, I was thinking about this, and I will do a wallet mode where a full wallet (ie, phone) can connect to a view wallet (ie, home server), and update from it. That should be super fast.
**\<fluffypony>** moneromooo: that's exactly what vtnerd is doing
**\<moneromooo>** tewinget: I think I kinda added a new RPC... a few days ago...
**\<fluffypony>** so would be duplication of work
**\<moneromooo>** Oh, OK.
**\<johnalan>** Won't that only show incoming though?
**\<fluffypony>** but let's back up a second
**\<hyc>** so a wallet can sync from another wallet?
**\<fluffypony>** because I think that maybe there's some value in the *idea* of 605
**\<moneromooo>** In my idea, yes (really, transfer output data).
**\<fluffypony>** but the specifics aren't great
**\<fluffypony>** for eg.
**\<moneromooo>** But I dunno what vtnerd is doing.
**\<xmreric>** Lots of GUI users want this on some level or another.
**\<xmreric>** I'm pretty big on emphasizing away from using remote nodes as best-practice.
**\<fluffypony>** what if an unsynced daemon, when it has a wallet client requesting outputs from a certain height, picks a random peer and asks that peer for the data
**\<xmreric>** But for people in developing nations, etc it's a good option to offer
**\<samsunggalaxyplayer>** I know that we all want everyone to run a full node, but I imagine less than half actually will, and that percentage will only decrease over time with new, non-technical users
**\<fluffypony>** ie. without range proofs / sigs / etc.
**\<gingeropolous>** the random peer has its rpc open?
**\<fluffypony>** the peer could lie, but the node will eventually know that it has
**\<fluffypony>** gingeropolous: no
**\<fluffypony>** we don't need RPC for this, we're already talking to the peer using the p2p protocol
**\<moneromooo>** Why would the wallet request outputs for a given height, if the daemon isn't synced to that yet ?
**\<fluffypony>** moneromooo: restored wallet, or loading a wallet file
**\<Jaquee>** if the daemon isnt synced it shouldnt be used by the wallet
**\<fluffypony>** or creating a new wallet
**\<moneromooo>** Restored wallet would not, it has no idea about where it has outputs.
**\<fluffypony>** moneromooo: restored from seed has a hardcoded restore height
**\<guzzi>** It is similar to how hadoop works
**\<moneromooo>** New wallet wouldn't either. They'd get that info from the daemon, who'd necessarily be synced up to that point.
**\<guzzi>** Here is the first answer it may be wrong
**\<moneromooo>** Unless you delete your blockchain after the wallet learns abvout those. But then, your problem.
**\<fluffypony>** moneromooo: in each of the instances we either have a block height or we have a date that we can correlate
**\<moneromooo>** Oh, you want *all* outputs ?
**\<fluffypony>** from that height or date, yes
**\<guzzi>** I like it. The attack would bre someone setting up a ton of fake nodes.
**\<fluffypony>** basically have the daemon tunnel "remote node" functionality to a peer
**\<moneromooo>** OK, so essentially, syncing the chain with no vcerification whatsoever.
**\<fluffypony>** moneromooo: yes - "pre-syncing" it
**\<fluffypony>** because the node will catch up, and then the wallet will know if outputs have been withheld
**\<moneromooo>** I actually had an idea about this a few days ago, where you could sync to a daily set of key images and outputs. Daily, verifying nodes hash it into the blockchain.
**\<guzzi>** Basically a no lock read
**\<moneromooo>** So you can sync to that, check hash, then sync the last day's chain on top.
**\<gingeropolous>** but this would leave the wallet in a state where it can't create transactions until proper sync'd?
**\<fluffypony>** moneromooo: the problem with that model are the oracles
**\<moneromooo>** It does require *some* trust, though.
**\<moneromooo>** Go on ?
**\<pigeons>** so the tricky part is the rules to make the block invalid if the miner lies
**\<gingeropolous>** er, until the daemon is proper syncd?
**\<fluffypony>** gingeropolous: the daemon could also tunnel requests for ring outputs or whatever
**\<fluffypony>** the trust model is the same as using some random guy's remote node
**\<Jaquee>** good idea. but still doesnt help users without enough disk or those on a slow connection
**\<guzzi>** True
**\<samsunggalaxyplayer>** That's what I proposed #602 for
**\<samsunggalaxyplayer>** People who do not want to run a full node
**\<pero>** i had a kind of mostly trustless idea for this
**\<fluffypony>** people that don't want to run a full node at all have to then use something like the MyMonero apps using the MyMonero backend instead of their own
**\<fluffypony>** or Exodus or Coinomi or whatever else exists
**\<pero>** that would poll multiple nodes for the same outputs and verify them
**\<pero>** and store those locally
**\<fluffypony>** pero: that's even worse than a remote node
**\<pero>** fluffypony: +1
**\* pero** sees himself out
**\<guzzi>** Or this and never sync tge daemon
**\<guzzi>** Lol
**\<rehrar>** What if the time connected to a remote node is limited? Just setting up the GUI it connects to a remote node, and they can use right away, while stuff is going on in the background? (Sorry, just an idea I had. Not a developer so I don't know if possible)
**\<fluffypony>** the larger issue here is that we can't do something like SPV
**\<fluffypony>** so we really have nothing between "run your own node" and "use a centralised service"
**\<rehrar>** Stuff = syncing
**\<ArticMine>** Should we looking at people connecting to their own remote node form say a mobile device?
**\<fluffypony>** rehrar: that's exactly what I'm suggesting, but let the daemon "tunnel" the requests through
**\<fluffypony>** ArticMine: the model here is people who don't want to run a node at all, not at home, not on a VPS, not at all
**\<Jaquee>** rehrar: that's what #605 does
**\<fluffypony>** we already have a solution for people who are willing to run a node
**\<rehrar>** Sorry. A lot of the tech is going above my head to catch it all. :)
**\<moneromooo>** Well, they can use paypal, and come back in 5 years.
**\<rehrar>** Tech talk
**\<Jaquee>** #605 connects to a remote node while local node is syncing
**\<jacobjeweler>** I agree, fluffy. I think the real issue is people not having enough knwoledge to install nodes. An installer on windows and .deb in apt would increase full nodes immensly.
**\<gingeropolous>** i like it. the pre-sync idea. using the daemon. it opens up the whole network as a source of remote nodes, which decentralizes the effort
**\<xmreric>** What if all this work gets done, but then this audience just uses web/mobile wallets anyways
**\<pigeons>** keep improving the ability for people to run their own node before making it easier for people to use a different model
**\<gingeropolous>** and because the daemon *is* running
**\<gingeropolous>** it will be synchronizing its own copy of the blockchain
**\<fluffypony>** @xmreric that's the most likely outcome
**\<hyc>** that is trickier
**\<fluffypony>** people *are* going to use MyMonero / Exodus / Coinomi even if we have a magical remote node model that doesn't vampire the network
**\<guzzi>** It could even hold part of the chain and randomly ask for missing parts
**\<hyc>** block data sync'd this way will need to be stored differently than from regular syncing
**\<pigeons>** peopl are going to use worse options than those even
**\<fluffypony>** hyc: agreed
**\<fluffypony>** pigeons: store on an exchange :-P
**\<samsunggalaxyplayer>** I like the pre-sync as well. But until we have MyMonero/Edodus/Coinomi, people will use a remote node in an inefficient way
**\<fluffypony>** @samsunggalaxyplayer then let's not make it easier by having a drop-down
**\<gingeropolous>** ^
**\<Jaquee>** why not make it easy while waiting for a better solution?
**\<fluffypony>** remember that a lot of decisions we make today, we're stuck with for 5+ years
**\<gingeropolous>** the effort wall to hack the system to use a remote node isn't that steep anyway
**\<fluffypony>** Jaquee: because ^^
**\<fluffypony>** people become reliant on quick fixes
**\<hyc>** So somewhere we need the doc to say "you must have a computer with at least xx GB of disk space that you are willing to leave running 24/7"
**\* tewinget** knows this, and as such leaves most decision making to fluffypony so he can be blamed in 5 years.
**\<moneromooo>** Ah, tewinget the Wise.
**\<endogenic>** in 2023
**\<Jaquee>** i just don't think we should be holding back on UX just because we don't have a better solution yet
**\<pigeons>** have a nice message, now that you have verified the blockchain, we notice you have been screwed, pick a better node next time
**\<fluffypony>** lol
**\<moneromooo>** Anyway, this has turned to a disparate set of confusing stuff now.
**\<guzzi>** Lol
**\<fluffypony>** Jaquee: the GUI is meant to operate with a full node that you operate, it's not a lightweight GUI
**\<ArticMine>** Do we want to encourage people connecting to a untrusted random node
**\<fluffypony>** ArticMine: no we don't
**\<samsunggalaxyplayer>** Summary: for smart syncing with fluffy's "pre-sync" approach, against anything that makes using a remote node easier
**\<guzzi>** For ppl who want to use a phone could it never sync?
**\<cryptocomicon>** sounds like we need a monero node appliance, like the wifi router that everyone has in their house / flat
**\<samsunggalaxyplayer>** I agree #602 is a short-term solution. I think it's better than telling people to go to MoneroWorld to get a random node, but if we have a better solution going forward, that's preferable
**\<johnalan>** Good idea
**\<hyc>** yes but wifi routers tend to be 32bit
**\<jacobjeweler>** Thats why i think installer for windows and adding .deb to apt repositories will have it so people can be guided through an install and proper installation can be verified
**\<guzzi>** And always use a random?
**\<fluffypony>** guzzi: phone would be MyMonero + your own node / MyMonero backend OR Exodus OR Coinomi
**\<gingeropolous>** and they're not cheap
**\<guzzi>** Ok thanks
**\<jacobjeweler>** Adoption rate will increase full node usage
**\<fluffypony>** @JacobJeweler we're definitely working on improving that with the GUI
**\<ArticMine>** I say make it easy for people to set up their own node to connect to. Appliance like
**\<guzzi>** That is horse poop
**\<fluffypony>** with the auto-update thing
**\<pero>** perhaps there's room for an unofficial gui fork
**\<guzzi>** No way ppl walñnt full nodes
**\<fluffypony>** gingeropolous: http://imgur.com/a/3mMBE
**\<gingeropolous>** in my mind the remote node thing has 2 components: 1) instant on 2) no blockchain storage.
**\<fluffypony>** gingeropolous: pigeons is working on it
**\<hyc>** right now the only way I see to make this easy is with kovri, so we can ignore firewall and port forwarding issues
**\<fluffypony>** hyc: +1
**\<gingeropolous>** we can address instant on with lots of things
**\<gingeropolous>** we can't address no blockchain storage. And those that don't want to store the blockchain will always use some lighter weight thing, so ... i think im rambling.
**\<jacobjeweler>** Good point hyc!
**\<amiuhle>** How about creating SD card images with the blockchain preloaded for a specific monerod release. You'd "just" have to download the image, flash it and start up monerod
**\<johnalan>** +1 hyc
**\<amiuhle>** ah, like for the Pine64 or something similar
**\<hyc>** pretty big downloads. they don't compress well at all.
**\<hyc>** 13GB now
**\<Jaquee>** and pine64 is to slow
**\<johnalan>** Does it even have native AES?
**\<fluffypony>** pine64 isn't too slow?
**\<amiuhle>** hyc: didn't you say you're running your full node fine on yours?
**\<hyc>** pine64 yes
**\<pero>** pine64 can run a node
**\<hyc>** yeah pine64 works ok as a fullnode. buy an expensive microSD
**\<fluffypony>** alright
**\<tewinget>** I'll brb in like 10 min, fyi
**\<fluffypony>** let's move on
**\<fluffypony>** 5. Code + ticket discussion / Q & A
**\<Jaquee>** ok. so #605 will not be merged?
**\<fluffypony>** (we can carry on discussing this after the Kovri meeting)
**\<Jaquee>** all right
**\<fluffypony>** Jaquee: no not with the drop down
**\<hyc>** you can release the bootleg edition
**\<fluffypony>** lol
**\<amiuhle>** I've gotten the impression that there should be more unit tests from reading the last dev meeting
**\<fluffypony>** amiuhle: yes
**\<jacobjeweler>** Lets be honest, most users have windows. And harddisks that can easily fit the lmdb database. If you want great adoption and more full nodes on the network (people installing and usong their local node for gui/cli). Thats where the focus on something like an installer should be at.
**\<amiuhle>** what if we at least request tests for new PRs?
**\<moneromooo>** Then you won't get PRs.
**\<vtnerd>** that would help, but could be frustrating in a few components
**\<fluffypony>** amiuhle: we don't want PRs from new contributors mired in a list of things-the-PR-must-have
**\<vtnerd>** for instance, I added some to epee::stringtools, but those are isolated functions so its easy to setup the test env
**\<hyc>** some of this stuff won't be easily detected in tests anyway. race condition with mining blocks, etc.
**\<fireice-uk>** one more thing regarding wallet2.cpp
**\<jacobjeweler>** Sorry am on phone typing, slow to respond.
**\<vtnerd>** hyc: yup. but figuring out a base framework for some areas might be helpful to get a baseline. but its decent chunk of work
**\<fireice-uk>** it is already at an unwieldy 5kloc, what's the opinion on splitting it into smaller parts?
**\<hyc>** can't detect some of these with code coverage testing either. code cov can't tell you about logic you're missing.
**\<moneromooo>** Tests can be added after the fact btw.
**\<moneromooo>** Is there a split that makes sense ?
**\<moneromooo>** And 5k is wieldy for any sane editor.
**\<fireice-uk>** moneomoo: takes 2gb+ to compile
**\<hyc>** yeah I wouldn't worry about wallet2.cpp at the moment.
**\<vtnerd>** mooo Im guessing vim ?
**\<hyc>** 2GB+ to compile comes from all the boost headers and shit
**\<moneromooo>** What I want is avoiding spamming the git log, as I use it a lot.
**\<fireice-uk>** ok
**\<moneromooo>** vim works fine with 5k, but most other editors are also not shit.
**\<vtnerd>** fireice-uk: thats partially coming from the epee headers though, but some split may help a bit
**\<moneromooo>** Or... I assume. 5k is not much.
**\<hyc>** I've done the experiment before.
**\<fluffypony>** bbedit handles it fine
**\* anonimal** coughs
**\<hyc>** splitting the file up to try to fit it under 2GB
**\<fluffypony>** ok guys
**\<fluffypony>** Kovri meeting
**\<hyc>** made no diff. it's the headers, not the cpp source
**\<fluffypony>** next meeting in 2 weeks, no time for Q&A, thanks for coming