Merge pull request #1 from monero-project/master

Up to date?

README.md

@@ -4,8 +4,8 @@ Copyright (c) 2014-2017, The Monero Project
 
 ## Development Resources
 
-Web: [getmonero.org](http://getmonero.org)  
-Mail: [[email protected]](mailto:[email protected])  
+Web: [getmonero.org](http://getmonero.org)
+Mail: [[email protected]](mailto:[email protected])
 IRC: [#monero-dev on Freenode](irc://chat.freenode.net/#monero-dev)
 
 ## About this Project
@@ -20,7 +20,7 @@ Pages and formats should be based off existing pages to maintain a consistent lo
 
 - changes made to _layouts, _includes, and home.php will need to use {% t x.x %} translation tags to pull in the YAML tag from _strings_en.yml, as this is required for multi-language support later on
 - with the exception of something like blog/index.html (that is required to be a .html file for Jekyll's pagination to work) all pages should be .md files
-- since all static content (CSS/JS/images) is hosted in a separate, non-public repository, changes can be suggested via Github issues and we will cross-apply them to that repo, crediting you in the commit message
+- static content (CSS/JS/images) can be found in the [monero-forum](https://github.com/monero-project/monero-forum) repo
 - SVG should be used in header icons and diagrams, and FontAwesome icons can be used in text
 - Moneropedia entries require nothing more than creating the .md file in knowledge-base/moneropedia/, please use the 00-base-00 file as a boilerplate
 - To create a CLI screen shot, prefix the text block with {:.cli-code}, and use span elements for the colours; see getting-started/running.md, getting-started/accepting.md, and the account.md Moneropedia entry

_data/merchants.yml

@@ -44,10 +44,14 @@
       url: http://moneroblocks.info
     - name: MoneroExplorer
       url: https://explorer.xmr.my/
-    - name: Moneroworld Blockchain Explorer
-      url: http://explore.moneroworld.com/
+    - name: MoneroHash Explorer
+      url: https://monerohash.com/explorer/
+    - name: xmrchain.net
+      url: https://xmrchain.net/
 - category: Payment Gateways
   merchants:  
+    - name: Living Room of Satoshi
+      url: https://www.livingroomofsatoshi.com/?sc=xmr  
     - name: Monero Merchants
       url: https://monero-merchants.com
     - name: Paybee (Private Beta)
@@ -58,8 +62,8 @@
       url: https://github.com/PsychicCat/monero-nodejs
     - name: python-monero (Python)
       url: https://github.com/tippero/python-monero
-    - name: pymonero (Python)
-      url: https://github.com/Monero-Monitor/pymonero
+    - name: MoneroPy (Python)
+      url: https://github.com/bigreddmachine/MoneroPy
     - name: moneronjs (NodeJS)
       url: https://github.com/netmonk/moneronjs
     - name: MoneroApi.Net (.NET)
@@ -88,6 +92,8 @@
       url: https://chrome.google.com/webstore/detail/monero-monitor/ojekadcfnkkihlleaafggfgbggdckpgo
 - category: Services
   merchants:
+    - name: Azur Samui - Luxury Apartment and Villa Development, Koh, Samui, Thailand
+      url: http://www.azursamui.com
     - name: California Fintech Network
       url: https://www.californiafintech.org/plans/
     - name: Infield Loan Services - Atlanta, Construction Consulting, Contract review, Feasibility, Funds Escrow
@@ -104,6 +110,8 @@
       url: https://mymonero.com
     - name: Pradeep Atluri, Psychiatrist, New York
       url: http://dr.mindsci.com/
+    - name: Simple, no non-sense hosting
+      url: https://rootbox.host/
     - name: Web Developer - Stefanos
       url: http://www.stefanosioannou.com/web-development-monero-accepted
     - name: XMR.to Monero to Bitcoin Payment Service

_posts/2016-12-22-monero-core-gui-beta-released.md

@@ -22,7 +22,7 @@ Download links are at the bottom of this post, and please take note of the known
 
 ## FAQ
 
-- *Can I use a remote node?* This is certainly possible. In the wizard, change the daemon address from `localhost:18081` to the address of the remote node. For instance, if you want to use the remote node of moneroworld.com, change `localhost:18081` to `node.moneroworld.com:18081` or `2nodez.moneroworld.com:18081`. Alternatively, you can specify a daemon address on the `Settings` page.
+- *Can I use a remote node?* This is certainly possible. In the wizard, change the daemon address from `localhost:18081` to the address of the remote node. For instance, if you want to use the remote node of moneroworld.com, change `localhost:18081` to `node.moneroworld.com:18081`. For more open node options, please check out the [MoneroWorld open node directory.](https://moneroworld.com/#nodes) Alternatively, you can specify a daemon address on the `Settings` page.
  
 - *What do I do if the GUI is showing `Wrong Version` at the bottom left?* If you see this message the daemon you are using is incompatible with the GUI. The daemon supplied in the binaries is compatible with the GUI. Thus, if you are seeing this message you are likely using a remote node, which is running a daemon that is incompatible with the GUI. Note that you will be able to receive funds. However, you *won't* be able to send funds.
  
@@ -86,4 +86,4 @@ If you would like to verify that you have downloaded the correct file, please us
 - monero.gui.win.x64.beta.zip, cb8bdf36fb56739a0fa746bec8dd51fb3479d51a3b8f0ce41a771f1d5a924bdb
 - monero.gui.mac.x64.beta.tar.bz2, 907bfb4832c74de6cec7df730dfce5d9ccc1e6de09b6a4546cb9eee1f8242968
 - monero.gui.linux.x64.beta.tar.bz2, cecbe4b23f777442de861bc0981af0857dab043ed63be98f768cdd00825a8d09
-- monero.gui.linux.x86.beta.tar.bz2, daabd11b271685cedf5d6321cbde5e6b7c2691630a4355a973fc0cb99b1d2dc9
+- monero.gui.linux.x86.beta.tar.bz2, daabd11b271685cedf5d6321cbde5e6b7c2691630a4355a973fc0cb99b1d2dc9
\ No newline at end of file

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

+---
+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  
\ No newline at end of file

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

+---
+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