4rkal/monero-site
1
0
Fork 0
mirror of https://github.com/monero-project/monero-site.git synced 2025-01-28 18:56:33 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge pull request #241

Browse Source 
eed3c0d Logs for the Kovri and Dev meetings held on 2017-04-09 (dEBRUYNE-1)
ae99d4e Logs for the Kovri and Dev meetings held on 2017-03-26 (dEBRUYNE-1)
This commit is contained in:
Riccardo Spagni 2017-05-05 12:09:14 +02:00
commit b74d9b2d60
No known key found for this signature in database
GPG Key ID: 55432DF31CCD4FCD
4 changed files with 1147 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

282
_posts/2017-04-09-logs-for-the-Kovri-dev-meeting-held-on-2017-04-09.md Normal file
View File

@ -0,0 +1,282 @@
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2017-04-09
summary: Brief review of what has been completed since last meeting, Monero HackerOne Bounty, website discussion, and code & open tickets discussion
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*April 9th, 2017*
# Logs
**\<anonimal>** 1. Greetings
**\<anonimal>** 2. Brief review of what's been completed since the previous meeting
**\<anonimal>** 3. Preparation for [96boards.org OpenHours showcase for Kovri / Monero](https://github.com/monero-project/meta/issues/46)
**\<anonimal>** 4. Status of [Monero HackerOne umbrella and bounty](https://github.com/monero-project/meta/issues/39)
**\<anonimal>** 5. Code + ticket discussion / Q & A
**\<anonimal>** 6. Any additional meeting items
**\<anonimal>** 7. Confirm next meeting date/time
**\<anonimal>** Hellloooo
**\<i2p-relay> {-olark}** Hello party people
**\<i2p-relay> [gingeropolous]** howdy!
**\<guzzi>** Hello
**\<moroccanmalinois>** hi
**\<rehrar>** Hi (observing excitedly)
**\<i2p-relay> {-iDunk}** Hi
**\* moneromooo** greets again
**\<i2p-relay> [endogenic]** no excitement allowed rehrar
**\<bigreddmachine>** hi
**\<rehrar>** I'll see myself out then.
**\<anonimal>** 2. Brief review of what's been completed since the previous meeting
**\<anonimal>** For me, the past two weeks have spent focusing on 4 things: fixing the OpenBSD dynamic build, PR review/fixes/collaboration, NTCP, and RI (router info).
**\<anonimal>** a. Jeff at crypto++ has not been responsive lately so my CMake fix for their dynamic OpenBSD is still sitting in PR hell.
**\<anonimal>** b. Both moroccanmalinois and rakhimov have been PR'ing some great work
**\<anonimal>** c. Over time I've done bits and pieces of work on the NTCP implementation but hadn't had the chance to do a full study in java I2P's implementation until recently.
**\<anonimal>** Combined with more spec review (forunately, the spec is small) I've come up with 33 questions/TODOs specifically about, and for, our implementation.
**\<anonimal>** Once that was done, it turned out that I couldn't move forward until I worked out any potential RI issues.
**\<anonimal>** d. That lead me to the unmaintainable mess of our forked RI implementation, which has been neglected, so now at a minimum I'm working on a RI parser/reader/writer refactor. From there, unit-test *and then* back to NTCP so I can close that damn milestone issue >:|
**\<anonimal>** So, that's just on my end. Anyone else?
**\<anonimal>** I know guzzi is doing study for RAII refactoring.
**\<bigreddmachine>** Salti's holding pattern for webextensions in FF is making progress
**\<anonimal>** Oooo cool
**\<anonimal>** How are they doing on that front?
**\<bigreddmachine>** 1 of two issues i'm tracking are finished, second is still a ways off
**\<guzzi>** Review client context implimenting raii
**\<bigreddmachine>** and no dev docs yet
**\<moroccanmalinois>** Looking at reload server tunnels https://github.com/monero-project/kovri/blob/master/src/client/context.cc#L321
**\<anonimal>** Excellent, that all sounds good. Anything else before we move onto 3.?
**\<i2p-relay> {-olark}** I have been slowly evaluating what will be needed to replace supercop with tweetnacl
**\<anonimal>** (well, I'm hoping FF will move faster but it sounds like they're at least *moving*)
**\<i2p-relay> {-olark}** Can rip out all the ecdsa sig types at the same time to work towards the identity refactor work
**\<bigreddmachine>** anonimal: yes. progress is progress.
**\<anonimal>** olark: ok this is for #485, sounds good. Would you be able to resolve #345 in the mean time?
**\<i2p-relay> {-olark}** For EdDSA
**\<i2p-relay> [fluffypony]** major thunderstorm here, so if I don't respond it's because I've been struck by lightning (or my house has)
**\<anonimal>** Eeek! No charred pony!
**\<i2p-relay> {-olark}** anonimal: Sure
**\<anonimal>** fluffypony can you see the meeting or is internet intermittent?
**\<anonimal>** olark: nice!
**\<anonimal>** Ok, moving forward,
**\<i2p-relay> {-olark}** I will find the time. I have been neglecting kovri :(
**\<anonimal>** Yes, come back soon ;)
**\<anonimal>** 3. Preparation for [96boards.org OpenHours showcase for Kovri / Monero](https://github.com/monero-project/meta/issues/46)
**\<anonimal>** Speaking of neglecting, I hope we don't let this opportunity slip by ^
**\<anonimal>** Does anyone know of any effect voice masking software? Military grade (if there is such a thing).
**\<anonimal>** \*effective
**\<i2p-relay> [fluffypony]** anonimal: nothing I know of, but I also don't know if that would be worthwhile or weird
**\<i2p-relay> \* fluffypony** tries to convince anonimal to come out the pseudonymous closet
**\<i2p-relay> {-pigeons}** yeah its annoying as hell to listen to
**\<i2p-relay> {-pigeons}** mouthful of marbles works ok though
**\<anonimal>** I hear that Barry Manilow recently came out of the closet.
**\<guzzi>** Pennies
**\* anonimal** not that I'm a fan, nor am I in that sort of closet
**\<anonimal>** Well, I'm curious to hear the public's opinion on whether I should de-anon. Thoughts?
**\<i2p-relay> [endogenic]** yes!
**\<anonimal>** moneromooo ^ #monero-dev
**\<i2p-relay> [endogenic]** i will be your bodyguard
**\<anonimal>** lol awesome! X)
**\<i2p-relay> [fluffypony]** anonimal: only reason I suggest it is because Kovri does need a voice, but ultimately it's your call
**\<i2p-relay> [gingeropolous]** weren't you already on the monero missives?
**\<i2p-relay> [fluffypony]** gingeropolous: no, that was jeff
**\<moneromooo>** What ? What's in #monero-dev ?
**\<i2p-relay> [endogenic]** anonimal: just think… we can hang out at meetups and such :)
**\<i2p-relay> {-olark}** Ultimately your choice anonimal.
**\<i2p-relay> {-olark}** Don't feel pressured to come out becuase people want you to ;)
**\<sgp>** ^ seconded
**\<anonimal>** gingeropolous: ^ not Jeff at crypto++, Jeff a former problem contributor who, as he said, has family in U.S. intelligence.
**\<i2p-relay> [gingeropolous]** he's satoshi.
**\<anonimal>** moneromooo I meant 'what's your opinion if any?'
**\* anonimal** and also threw question at #monero-dev in same line, sorry
**\<i2p-relay> [gingeropolous]** my apologies. I obviously know whos who here.
**\<moneromooo>** Of whether you should de-anon ? I wouldn't want to influence you to.
**\<anonimal>** Oh np, just clarifying since I said "Jeff" earlier.
**\<moneromooo>** My view is that the more people actively keep their privacy, the less the massive pressure on everyone else to shed their privacy is.
**\<anonimal>** Hmm, good point.
**\<moneromooo>** Not really related to this particular case, but having 99% of people not care about their privacy means that companies and everyone can just screw privacy and not get any noticeable blowback.
**\<i2p-relay> [endogenic]** think only anonimal's in the position anonimal's in as kovri lead tho
**\<moneromooo>** So I use Tor for random run off the mill browsing partly for that reason too.
**\<i2p-relay> [fluffypony]** moneromooo: yes, but this is about his status as a contributor and maintainer
**\<i2p-relay> [fluffypony]** after all, things get really boring if I'm the only one talking at conferences
**\<moneromooo>** Well, his choice, and I don't want to interfere in it. But thanks for asking :)
**\<i2p-relay> [endogenic]** \<3
**\<i2p-relay> [endogenic]** i wouldn't go that far fluffy
**\<i2p-relay> [gingeropolous]** you could just "hire" a spokesperson to be your IRL talking head
**\<i2p-relay> [gingeropolous]** and they *just* happen to know a *whole* lot about everything
**\<i2p-relay> [endogenic]** rent-a-body
**\<anonimal>** Ok, so I'm hearing that if I de-anon I get a free(?) bodyguard and can freely promote more-so than what I can do now. I'm also hearing that no one wants to put that kind of pressure of a decision on me.
**\<anonimal>** I have to say though, I'm wearing more than 1 cap at any given time. Maybe one-too-many? It was a relief to finally sit down and write some code this week. It had been way too long since I've done that and I'm ALWAYS HERE working on kovri!
**\<iDunk>** I think gingeropolous suggested you should invent an alter ego for public appearances :)
**\<i2p-relay> [endogenic]** you can choose when to do talks and when to reply to ppl imo
**\<i2p-relay> [endogenic]** and i bet others will jump in to help
**\<i2p-relay> [fluffypony]** "I'm fluffy...errrr...fluffynonimal, and I'm a Kovri developer"
**\<i2p-relay> [endogenic]** just a question of letting us know how we can help
**\<i2p-relay> {-pigeons}** even if you do come out, still consider the marbles for talks
**\<i2p-relay> [gingeropolous]** well iDunk now its ruined
**\<iDunk>** Damn
**\<anonimal>** lol, I'll just show up with marbles in my mouth.
**\<anonimal>** I must say that, adding public-relations, I love the thought, but I do also love writing code.
**\<anonimal>** And people love targets, so that's always something to concern myself with.
**\<sgp>** You can still do both. Choose the proportion you want
**\<anonimal>** "just a question of letting us know how we can help" \<-- thanks endogenic. I think what will help are 2 things:
**\<anonimal>** sgp good point
**\<i2p-relay> [fluffypony]** anonimal: I think that there's probably less scope to talk about Kovri at conferences right now anyway, but it would be nice for someone to do some podcasts etc. in future
**\<i2p-relay> [endogenic]** podcasts are a great idea. i honestly doubt most ppl who want to use something like tor even know tor needs an alternative
**\<i2p-relay> [endogenic]** and i'd enjoy learning more about the kovri tech in that format
**\<anonimal>** What would help: 1. more people get more familiar with kovri technology so they can answer questions and promote too. And 2. maybe everyone present can give me a solid "yes" or "no" on if they want me to de-anon (i.e., putting aside any other thoughts and responding purely on instinctual feelings)
**\<anonimal>** bigreddmachine: ^ re: podcast, my decision sooner than later will effect that
**\<i2p-relay> [gingeropolous]** just go full Mr. Robot. Loose touch with reality, veer into psychosis, and then even *you* don't know who you are.
**\<anonimal>** lololol gingeropolous X)
**\<sgp>** I just started watching that show. 1 season in. No spoilers please!
**\<ArticMine>** To de-anon should be personal chice in my opinion
**\<anonimal>** Ok I'd say we're on a tangent for point 3 but this kind of needs to be done IMHO.
**\<ArticMine>** choice
**\<anonimal>** All in favor of me de-anoning: yay or nay?
**\* anonimal** don't be shy!
**\<i2p-relay> [endogenic]** i personally agree it must be personal too. sry to be difficult. there are tradeoffs for sure
**\<sgp>** Pros: can talk about it more openly, attract new talent with greater outreach, better inform community about developments. Cons: more likely to be a target, maybe you're really ugly
**\<i2p-relay> [endogenic]** it's a kind of burden i think
**\<sgp>** (just kidding on second con)
**\<i2p-relay> [fluffypony]** anonimal: I don't know if we should vote for that, it's your call
**\<anonimal>** lol sgp maybe I'm missing a face entirely...
**\<anonimal>** fluffypony ok
**\<anonimal>** So resolving 3., fluffypony + pigeons, how's your schedule lately?
**\<i2p-relay> [fluffypony]** pigeons is down my side of the world for a couple of weeks, so we can make time around that
**\<anonimal>** Oh neat! Should I contact Robert to schedule a definitive date now?
**\<i2p-relay> [fluffypony]** well it depends on if you want to do me + pigeons or you + pigeons
**\<bigreddmachine>** anonimal: soory, was afk. re the podcast bit, if you do decide to de-anon yourself, i'd be happy to host your coming out of the closet party! but garbling voice is doable too.
**\<i2p-relay> [fluffypony]** or all 3 of us
**\<anonimal>** fluffypony: I would think either all 3 (or at minimum just you 2). bigreddmachine I'd like to hear/learn more about any garble tech available, even if it's annoying.
**\<i2p-relay> [fluffypony]** anonimal: ok let's talk afterwards, and we can schedule it with them
**\<anonimal>** Ok will do
**\<anonimal>** bigreddmachine: I'll PM you later too
**\<anonimal>** Anything else on 3.?
**\<moneromooo>** Voice garbling sounds very reversible (unless it's voice recogniation plus text to speech).
**\<bigreddmachine>** TTS certainly would work.
**\* anonimal** considered TTS, maybe I should learn to type faster first
**\<anonimal>** (or prepared statements?)
**\<anonimal>** (defeats the fun of interviews/speeches/conferences?)
**\<anonimal>** Ok, we'll talk more later.
**\<i2p-relay> [endogenic]** hehe seems a little creepy
**\<anonimal>** 4. Status of [Monero HackerOne umbrella and bounty](https://github.com/monero-project/meta/issues/39)
**\<moneromooo>** Copy and "paste" words from movies, paste them one by one to make up sentences. Like the old words cut off from a newspaper :D
**\<anonimal>** lol moneromooo, not serial-killer-like in any way whatsoever...
**\<anonimal>** re: 4. We have hackerone.com/monero !
**\<i2p-relay> [fluffypony]** anonimal: has anything for 4. been written up in the style of an FFS proposal or not yet?
**\* anonimal** grabs only FFS for 4.
**\<anonimal>** Links is in the meta issue, one moment.
**\<anonimal>** https://forum.getmonero.org/6/ideas/87597/monero-bounty-for-hackerone
**\<anonimal>** Is that what you mean?
**\<i2p-relay> [fluffypony]** ok - do you want me to move that to Funding Required in its current form?
**\<anonimal>** Eek, I should update?
**\<anonimal>** The prop looks unclear as-is
**\<i2p-relay> [fluffypony]** probably worthwhile
**\<anonimal>** We decided on 500 to start
**\<anonimal>** Ok, I'll edit after the meeting or do you need me to do that now?
**\<i2p-relay> [fluffypony]** no after is fine
**\<anonimal>** Ok
**\<anonimal>** So for 4, I still have to PR VRP's to the various repos.
**\<anonimal>** Also invite the appropriate people to H1. But fluffypony I think you'll want to do that?
**\<i2p-relay> [fluffypony]** sure
**\<anonimal>** moneromooo is already in there. luigi is not yet though.
**\<anonimal>** Alright. From there we should raise the funds first and *then* start inviting hackers on H1.
**\<anonimal>** Any agreements/disagreements?
**\<sgp>** I agree
**\<anonimal>** Btw, many hackers are already *on* H1, by invite I mean invite to start looking at our projects.
**\<anonimal>** Ok. Anything else on 4.?
**\<anonimal>** 5. Code + ticket discussion / Q & A
**\<i2p-relay> [fluffypony]** nothing else from my side on 4
**\* anonimal** takes peek
**\<anonimal>** re: website issue, is ajs here?
**\<ajs>** present
**\<anonimal>** Hi!
**\<anonimal>** Any news the website front?
**\<i2p-relay> {-pigeons}** No I am the holdup there
**\<anonimal>** Ok. ETA on resolving any holdups?
**\<bigreddmachine>** shoot, i was just about to ask about that. didn't realize we had monero-project/kovri-site. how can i help?
**\<ajs>** have backed up work that has been done and waiting for access to a server
**\<anonimal>** Btw rehrar popped in recently and said him and/or his wife would give a try a logo redesign.
**\<rehrar>** Hi. Yes. :D
**\<i2p-relay> {-pigeons}** i'll try to set something up in 24 hours or so
**\<anonimal>** Wow, that fast? Cool.
**\<i2p-relay> [pero]** so what happened to the logo i did
**\<anonimal>** pero: it was NACK'ed. This was clearly stated in github issue that I posted in the previous meeting.
**\<rehrar>** I'd also like to give the Kovri website a go, pending on the logo and branding. :)
**\<i2p-relay> [pero]** why?
**\<anonimal>** pero: I don't have the files though if that's what you mean.
**\<anonimal>** fluffypony: ^
**\<i2p-relay> [pero]** you were sent the files
**\<i2p-relay> [pero]** so as i see it, a contributor contributed a bunch of time and spiffied up the previous logo
**\<anonimal>** Not anymore. Tis' the magic of deleted emails.
**\<i2p-relay> [pero]** the community was involved too...
**\<i2p-relay> [pero]** then it unilaterally 'nack'd'
**\<anonimal>** Yes. This was all clearly stated in the github PR.
**\<anonimal>** Where is your logo work PR?
**\<i2p-relay> [pero]** wow what a shitty way to waste contributor's time
**\<anonimal>** You PR'd nothing. Community opinion does not equal final decision.
**\<anonimal>** Off you go pero, the resident troll.
**\<i2p-relay> [pero]** lol?
**\<anonimal>** You knew from the start that fluffypony and I would make a final decision. Do I really need to bring up logs from months ago?
**\<i2p-relay> [pero]** the logo assets were emailed to you and pony
**\<i2p-relay> [pero]** there was no request to pr anything
**\<ajs>** rehrar bigreddmachine - I made a very basic Jekyll site.. files at: https://github.com/anonimal/kovri-site
**\<i2p-relay> [pero]** the request was for the files to be emailed
**\<i2p-relay> [pero]** and your 'troll' remark is uncalled for and rude?
**\<i2p-relay> [pero]** wtf is that
**\<anonimal>** pero you have two options: 1. being kicked from this channel for disrupting a meeting or 2. venting into https://github.com/monero-project/kovri/pull/488 for all the world to see.
**\<i2p-relay> [bigreddmachine]** ty ajs. will this be affected by the re-design that rehrar is doing?
**\<rehrar>** Well, I think ideally the redesign that is done for getmonero.org should have an influence on the Kovri website (just influence, not dictate)
**\<rehrar>** and the logo redesign I will propose (just a proposal) I think definitely should have a larger influence on the website
**\<i2p-relay> [pero]** whats so hard about contacting the person that did the work?
**\<anonimal>** rehrar: that sounds good
**\<rehrar>** So before I start working on anything Kovri website related, we're going to try to get a logo to you guys before this week is over.
**\<rehrar>** I'll drop it on here and the Kovri repo as an issue to look over when it's done.
**\<rehrar>** And it is obviously open to suggestions or tweaks when we show it
**\<i2p-relay> [bigreddmachine]** ty rehrar - but from a content standpoint, the re-design is sort-of content agnostic, right? as in, i could write a page and the formatting might change but if it's in a markdown file jekyll will just ingest it and reformat, right?
**\<rehrar>** for Kovri, not getmonero.org, right?
**\<anonimal>** Did you have any plans to re-use material from monero site (as to save time, etc.)?
**\<i2p-relay> [bigreddmachine]** well, both i suppose, but kovri specifically
**\<ajs>** bigreddmachine: site design is rudimentary and could be easily changed if need be
**\<rehrar>** The content is going to be restructured for getmonero.org, I'm not going to do a lot of work on copy, unless people think it's really needed.
**\<i2p-relay> [bigreddmachine]** (sorry, i got us off topic)
**\* anonimal** whatever is easiest to maintain IMHO
**\<rehrar>** Pages will be shuffled around, and some things within pages will be shuffled around (all of this will be submitted in designs prior to everything being built)
**\<rehrar>** as for Kovri, it won't have nearly as much content yet, so I don't think it'll be a huge issue.
**\<rehrar>** does that answer your question?
**\<rehrar>** If not, the short answer is yes, it should be content agnostic, and I will work with you guys in the rare cases where it is not.
**\<i2p-relay> [bigreddmachine]** not entirely but close enough, thanks.
**\<i2p-relay> [bigreddmachine]** ahh, yeah that last bit helps
**\<rehrar>** great!
**\<anonimal>** Question:
**\<anonimal>** rehrar: IMHO, from the work of yours I've seen, since you're an actual designer/creator/implementer, I'm wondering if you, bigreddmachine, ajs and pigeons would consider being the 'website team' to get this up-and-running. I can move the repo when we're online. Does this sound fair or something of interest?
**\<anonimal>** It sounds like you're already doing that, I'm just wondering for my own piece of mind (e.g. do I need to re-schedule my work load for website work, etc.)
**\<i2p-relay> [endogenic]** But not both!
**\<rehrar>** That sounds fine with me. Pardon me for my ignorance, but what will be bigredmachine, ajs, and pigeons roles?
**\<i2p-relay> [bigreddmachine]** i'm happy to help with some content, as i am trying to learn about the tech anyway so documenting it is an obvious step.
**\<anonimal>** endogenic too, hop on the site train!
**\<rehrar>** if you can focus more on Kovri, I would do it.
**\<anonimal>** rehrar: re: bigreddmachine ajs and pigeons, let's chat after the meeting since we're out of time
**\<i2p-relay> [bigreddmachine]** design-wise, i can give my two cents but i'd like to be hands off there. just more of a feedback guy, like "hey, this isn't intuative" or whatever
**\<rehrar>** I don't think any of us have a problem bugging you if we need something.
**\<rehrar>** I'm not able to stick around for much longer, actually.
**\<rehrar>** We can set up a meeting time for alter this week?
**\<rehrar>** \*later
**\<anonimal>** rehrar: just pop in anytime if you want to make an official website meeting
**\<rehrar>** sounds good
**\<rehrar>** gotta split. Seeya homes.
**\<i2p-relay> [bigreddmachine]** i can't, but just summarize discussions on github issue and tag me
**\<anonimal>** bigreddmachine: that's right, you're not always irc'able.
**\<i2p-relay> [fluffypony]** Can I take the bot down? I'm in a YouTube show mow
**\<i2p-relay> [fluffypony]** Now
**\<i2p-relay> [bigreddmachine]** anonimal: i try to stay off during week to stay focused on my job.
**\<i2p-relay> [endogenic]** anonimal: oh no not me, i was just trolling about "fair or of interest"
**\<i2p-relay> [bigreddmachine]** meow\*
**\<anonimal>** Ok, moving on 6. Any additional meeting items
**\<anonimal>** None from me. guzzi said like 2 lines.
**\<i2p-relay> [endogenic]** I think pero could be of help on the site too as i think he has lots of exp there
**\<anonimal>** 7. Confirm next meeting date/tim
**\<i2p-relay> [bigreddmachine]** just that i'll keep tracking FF proxy and looking for alternatives.
**\<i2p-relay> [bigreddmachine]** 23 Apr?
**\<anonimal>** Yes, same time in two weeks.
**\<i2p-relay> [fluffypony]** Yep
**\<anonimal>** Thank you everybody!

277
_posts/2017-04-09-overview-and-logs-for-the-dev-meeting-held-on-2017-04-09.md Normal file
View File

@ -0,0 +1,277 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2017-04-09
summary: 0.10.3.2 release, repository naming, website redesign, decoy output selection algorithm, and static ring sizes
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
---
*April 9th, 2017*
# Overview
An overview [can be found on MoneroBase](https://monerobase.com/wiki/DevMeeting_2017-04-09).
# Logs
**\<fluffypony>** ok
**\<fluffypony>** 2. Brief review of what's been completed since the previous meeting
**\<fluffypony>** so the main thing was the 0.10.3.1 release
**\<fluffypony>** which has mostly been fine, no major breaking issues
**\<fluffypony>** there are some GUI fixes that will go into 0.10.3.2, which we aim to tag and release soon
**\<medusa>** before or after the fork ?
**\<fluffypony>** which brings us to
**\<moneromooo>** There's this bug with not merging destinations, which is overeager in not merging.
**\<fluffypony>** 3. Code + ticket discussion / Q & A
**\<fluffypony>** medusa: probably before, due to the thing that moneromooo just pointed out, which is a bit of an annoyance for exchanges
**\<medusa>** allright thats good. i think a possible bugfix release after the fork shoudl be completely seperate too
**\<fluffypony>** medusa: is there something you're expecting will break at the fork? :-P
**\<medusa>** lets hope nothing is needed \<3
**\<medusa>** no
**\<fluffypony>** ok shew
**\<fluffypony>** I'm planning on merging PRs over the next couple of days
**\<fluffypony>** are there any that are don't-merge-yet?
**\<vtnerd1112>** The one I have outstanding for bin2hex
**\<xmr\_eric>** Before merging the PR to name Monero GUI back to Monero Core, I thought it would be good to have a discussion here about that. But perhaps that can be saved for the end of today's meeting.
**\<moneromooo>** Oh, I'd kinda forgot-ish about that one...
**\<Jaquee>** #658 and #667 obviously
**\<vtnerd1112>** It's currently unmergeable and I don't know if anyone looked at it recently
**\<fluffypony>** xmr\_eric - we can discuss it now, it's part of this section anyway
**\<vtnerd1112>** monermooo I will revise and push later today
**\<luigi1112>** is he copying me
**\<vtnerd1112>** rebase, damn phone
**\<fluffypony>** vtnerd1112: I haven't since looking at it the first time, sounds good
**\<endogenic>** lol
**\<fluffypony>** luigi1112: yes
**\<fluffypony>** /nick fluffypony1112
**\<xmr\_eric>** Ok, well I'd like to hear from Jaquee. But my thoughts are that we rename Monero GUI back to Monero Core. Gingeropolous originally named it back to Monero GUI at the time, which was a decent idea, but I think in the end the central Monero software that the public is going to use should be called Core
**\<fluffypony>** @xmr\_eric that was among the reasons for calling it Core initially
**\<xmr\_eric>** I spent some time yesterday trying to find a word other than Core to differentiate ourselves from Bitcoin, like Monero Essentials or something, but none really work as well.
**\<xmr\_eric>** Right. I think we should go back to that.
**\<fluffypony>** also because I think that the current monero repo will become libmonero
**\<pero>** and then monero-cli?
**\<fluffypony>** yeah
**\<pero>** makes sense
**\<Jaquee>** so we end up with 3 repos?
**\<Jaquee>** gui, cli and lib?
**\<fluffypony>** Jaquee: yes eventually
**\<Jaquee>** ok cool
**\<fluffypony>** Jaquee: what are your thoughts on GUI vs. Core
**\<Jaquee>** libwallet API is only used by gui for now. so i'm thining it could be moved to gui repo.
**\<Jaquee>** i would prefer GUI
**\<Jaquee>** https://github.com/monero-project/monero-core/issues/663
**\<endogenic>** how about 'official' instead of 'core'? cause it'll be specified as the official 'gui', cli etc
**\<xmr\_eric>** This isn't just naming the repo, this is naming the piece of software the repo produces
**\<bigreddmachine>** As for names, I assume "Monero Qt" is out? That was once the standard for cryptocurrency wallets but seems to have lost favor.
**\<xmr\_eric>** Essentially, it is branding
**\<pero>** if we're going to have lib and cli, and those seems like the optimal nomenclature for those, then i think the logical one for the gui is gui
**\<Jaquee>** +1
**\<endogenic>** or maybe core gui..
**\<xmr\_eric>** The public doesn't think in terms of CLI GUI
**\<xmr\_eric>** People won't know what GUI means
**\<Jaquee>** do they know what core means?
**\<Jaquee>** i don't :P
**\<pero>** yea but core is kind of confusing since core seems to be lib
**\<fluffypony>** pero: I was thinking more like libmonero, monero-tools, monero-core
**\<bigreddmachine>** pero: i'd argue the optimal name for a gui should *not* have "gui" in the name. They aren't called FireFox GUI, Chrome GUI, Word GUI, etc
**\<gingeropolous>** just Monero
**\<xmr\_eric>** No, but the point is Core is a word that people will begin to associate with that piece of software
**\<hrumag2>** gingeropulos I agree
**\<xmr\_eric>** What does Linux mean?
**\<jwinterm>** I think core does have a bit of stench to it now
**\<hyc>** at worst, monero app
**\<hrumag2>** The application has to be the most atomic
**\<jwinterm>** bigreddmachine: there's no lynx like version of firefox or chrome tho
**\<jwinterm>** that I'm aware of
**\<hrumag2>** To the public I mean
**\<xmr\_eric>** The problem with naming it just Monero is that no other piece of software gets to be called Monero
**\<xmr\_eric>** Which I'm ok with
**\<pero>** yes i can see reason in that argument bigreddmachine
**\<hyc>** MoneroUser
**\<xmr\_eric>** But it isn't good from a nomenclature standpoint
**\<bigreddmachine>** "Monero Wallet"?
**\<pero>** what's monero-tools fluffypony ? the cli?
**\<fluffypony>** pero: yes
**\<fluffypony>** especially since they ship with the GUI
**\<sgp>** ^ anyone can make their own wallet
**\<moneromooo>** Could we maybe get on with the *dev* meeting...
**\<fluffypony>** so that seems to make some sense
**\<fluffypony>** ok let's table this for the next meeting, we can open a thread or discuss it further under an existing one
**\<fluffypony>** s/thread/issue
**\<xmr\_eric>** Great
**\<hrumag2>** At least "Monero node", "Monero wallet cli", "Monero wallet gui"
**\<gingeropolous>** moneromooo, I like this bike shed. It can fit many bikes
**\<fluffypony>** and then we'll make a decision at the next meeting
**\<Jaquee>** sounds good
**\<anonimal>** Two cents: 2 repos: libmonero and monero. monero has optional cli build alongside gui.
**\<fluffypony>** ok so 4. GetMonero.org redesign discussion
**\<fluffypony>** rehrar wanted to show us the designs and get our input on it
**\<rehrar>** I don't want to take much time. Just want to get a special opinion from all the devs about the two proposed designs.
**\<rehrar>** If you haven't seen them already, you can find them here
**\<rehrar>** Design 1: http://imgur.com/a/MwyxX
**\<rehrar>** Design 2: http://imgur.com/a/H9i3z
**\<anonimal>** github link too?
**\<unknownids>** design 1 third draft imo
**\<rehrar>** The idea will be to redesign the current website and also to make an assets document that will have the HTML and CSS framework that we make so anyone can easily make more pages.
**\<i2p-relay> {-olark}** Will these sites still be usable with javascript disabled?
**\<rehrar>** No JavaScript will be used.
**\<anonimal>** https://github.com/monero-project/monero-site/issues/245
**\<rehrar>** All in Jekyll
**\<rehrar>** Sorry, thank you anonimal
**\<vertp>** design 1 - draft 3 is the most popular on reddit. Most people are asking to add some of the community sponsored youtube vids to the homepage as well.
**\<hrumag2>** 1 totally. Marketing addicted
**\<pero>** im pretty big on the 2nd one
**\<gingeropolous>** will these sites still be editable via github by random people, like the current site?
**\<fluffypony>** design 2 is nice, but a little too clean
**\<fluffypony>** gingeropolous: yes
**\<pero>** the first one is too generic and reminds me of shitty webapps/startups
**\<pero>** first one with some tweaks
**\<pero>** erm
**\<endogenic>** i agree, maybe some pretty-fication to #2
**\<aerbax>** I think it's important to include one of the Monero introductory videos on the frontpage of whatever design is chosen.
**\<pero>** second one\*
**\<i2p-relay> {-olark}** Ok
**\<endogenic>** cause it's an OSS / tech project after all
**\<fluffypony>** vertp: I don't know if we really need multiple videos on the home page, just the intro one
**\<rehrar>** I think the second design is the most modular and easy to adapt to others making more pages as the site progresses after I'm done with it.
**\<Jaquee>** i also prefer #2
**\<sgp>** As I mentioned, I still like 1.3 the best. 2 is still better than what we have right now though
**\<anonimal>** Since no one here will probably read that github issue, #2 looks like a tech spec but #1 can be worked with. If reddit has good response for #1 draft 3 then that direction is something to consider.
**\<fluffypony>** endogenic / pero: I'm leaning that way too
**\<tewinget>** didn't realize we were doing a meeting this week; I'll be around in like an hour, have to catch a bus.
**\<vertp>** fluffypony: yes, good point. shouldn't have used the plural tense.
**\<rehrar>** We were playing with adding some color to design 2
**\<fluffypony>** anonimal: otoh we can take some of the elements from design 1, draft 3 and incorporate them into design 2 - @rehrar?
**\<rehrar>** And I think we have a good idea of how to do it.
**\<rehrar>** We should have something for it soon.
**\<rehrar>** Yes, we'll work on that.
**\<pero>** site should be an information portal ultimately, the first design is getting the user to download an app asap imo
**\<rehrar>** Any particular things from that design to Port?
**\<pero>** it is not aligned with what the site's goals should be
**\<gingeropolous>** i like #2
**\<rehrar>** I agree.
**\<anonimal>** Site's goals? It's a website.
**\<pero>** yes the goal of providing information
**\<rehrar>** Monero is a unique project, and having a standard site is doing Monero a disservice imo.
**\<fluffypony>** @rehrar the world background and the different sections are nice
**\<fluffypony>** backgrounds for different sections I mean
**\<rehrar>** I agree that design 2 is a bit sterilized.
**\<anonimal>** Old people need to be able to use this too. Old people don't like to read most of the time because fonts are too small and if they are computer illiterate they don't know how to zoom.
**\<anonimal>** Technical illiteracy = most of planet earth.
**\<xmr\_eric>** Websites are absolutely about a main goal first. That's what good design is about. Funneling people into a path that they already want to go. Eg "What is this Monero thing?"
**\<pero>** that argument is pointless anonimal
**\<pero>** old people that are actively using the internet have learned how to deal with those issues
**\<fluffypony>** anonimal: old people aren't going to use Monero, they'll use some L2 or L3 system on top of it
**\<anonimal>** pero this is a dev meeting, feel free to leave anytime.
**\<anonimal>** You are not a dev.
**\<pero>** else they wouldnt be using it
**\<pero>** lol
**\<fluffypony>** so it's also got to serve the target audience
**\<moneromooo>** Yeah, maybe we could have dev meeting and monero meeting.
**\<rehrar>** If the overwhelming majority thinks design 1 even after draft 3 of design 2 then I will probably go with it
**\<fluffypony>** moneromooo: this is specifically to get dev input on the design
**\<rehrar>** But we're going to add some color to the design 2.
**\<hrumag2>** I think it should be given more underlining about how to buy Monero. Where do you think to put the link?
**\<rehrar>** Monero just has very...Specific branding colors. XD
**\<fluffypony>** @rehrar let's see what you come up with on design 2 and then see
**\<rehrar>** Aight. Will do.
**\<fluffypony>** hrumag2: no, definitely not, that sort of funnel makes us liable
**\<hrumag2>** ... more than "get involved" I think
**\<anonimal>** When I say 'old', I mean plebeian elders of planet earth.
**\<rehrar>** That's all from me.
**\<rehrar>** Any last second opinions?
**\<pero>** i have a concern with project scope/budget
**\<pero>** i think the work effort is being underestimated and it's underbudgeted
**\<rehrar>** Not underestimated, but underbudgeted for sure.
**\<fluffypony>** @rehrar well we do a second FFS if needed, let's see how it goes
**\<rehrar>** On purpose. Part of it is my donation to the community. I believe in it.
**\<rehrar>** Ok. :)
**\<fluffypony>** ok on that note
**\<fluffypony>** let's move on to 5. Any additional meeting items
**\<fluffypony>** only thing I want to ask is just to find out from Jaquee if he managed to get hold of Qt
**\<Jaquee>** no, sorry. i've had a busy week
**\<moneromooo>** Well, I had this list of bugs I think can be closed. Which should be greppable with mooo.\*bug.\*clos
**\<Jaquee>** will take care of that issue in a couple of days
**\<fluffypony>** np
**\<fluffypony>** moneromooo: yep I'll be closing issues in the next few days too
**\<moneromooo>** Thanks.
**\<fluffypony>** anything else?
**\<bigreddmachine>** I have a Q: What is the "correct" way to propose an improvement / protocol change to Monero? Bitcoin has the BIP system, whereas for Monero things are basically handled via GitHub issues in the main repo. That means that, though discussions are documented permanently, they can be difficult to find and track over time. Is Monero getting to where it is big enough and has enough contributors that maybe we s
**\<bigreddmachine>** hould have a BIP-like process?
**\<fluffypony>** bigreddmachine: easiest way is just for us to have a label on Github (for consensus-critical changes)
**\<i2p-relay> {-olark}** I have a few things I would like to talk about regarding https://github.com/monero-project/monero/issues/1673 I should post another update soon
**\<i2p-relay> {-olark}** I can wait
**\<bigreddmachine>** fluffypony: but is that the ideal way to do it? after getting merged, closed, etc, those discussions are very tough to find. Something like BIP is a much better long-term place for those discussions
**\<fluffypony>** bigreddmachine: I think that changes should be written up as an MRL paper
**\<bigreddmachine>** I'm not asking because I have a specific proposal to make, but because it seems we don't have an ideal system that can grow well
**\<bigreddmachine>** fluffypony: and submitted to MRL?
**\<fluffypony>** yes
**\<fluffypony>** available permanently as an MRL research bulletin, which makes recommendations to the implementors, and exists as a living document
**\<bigreddmachine>** okay - then shouldn't that be the case for anything consensus changing?
**\<bigreddmachine>** what got me thinking about it is that the discussions behind this month's hard fork are very tough to find. i know it's a small change, but i feel like we don't have a precedent set
**\<fluffypony>** bigreddmachine: mostly yes, although I think some things are a little small to write up and might have to be bundled together
**\<fluffypony>** let's give that a spin and see how it goes, we can always change the process later on
**\<bigreddmachine>** what makes something "too small" though? I guess my point is that maybe we need to add guidelines to the main repo that explain all this for people to see in the future
**\<fluffypony>** olark: do you want to discuss 1673 now? we still have 19 mins before the Kovri meeting
**\<bigreddmachine>** I am happy to do that and make the PR,
**\<i2p-relay> {-olark}** Sure
**\<i2p-relay> {-olark}** I just wanted to talk about a couple quick things
**\<fluffypony>** bigreddmachine: it's subjective - when we changed the block time from 1 min to 2 mins, for eg., the reasons were obvious - yes please do write it up and PR it
**\<i2p-relay> {-olark}** What people think about having 3 static ringsizes for monero similar to how we have static fee priorities.
**\<i2p-relay> {-olark}** This was an idea moneromooo had brought up in the issue
**\<sgp>** What ringsizes are you proposing?
**\<i2p-relay> {-olark}** To protect users from making foolish mistakes reusing irregular ringsizes
**\<moneromooo>** I was about to write "I like it", so I now see why I do... :D
**\<fluffypony>** olark: I like it because it removes fingerprinting / metadata leaks
**\<i2p-relay> {-olark}** Well if September is mandatory 4 i was thinking like 4, 12, 50 or something similar the details don't matter at this moment but just what people think about having this in place.
**\<fluffypony>** I'm fine with it, but 4 is way too small as the minimum, even per the old MRL recommendations
**\<i2p-relay> {-olark}** The other thing was since I have been surveying the bitcoin blockchain for a while there is large bias for spent outputs in the past day
**\<bigreddmachine>** to clarify - unlike fees, which *could* be changed on the user-end to something else, this will make non-standard ring sizes be against the consensus protocol?
**\<i2p-relay> {-olark}** and how this affects the attack in MRL-001
**\<fluffypony>** bigreddmachine: yes
**\<moneromooo>** We could wait to see luigi1112's final ringct sizes, then see how those vary with increasing mixin.
**\<fluffypony>** moneromooo: agreed
**\<jwinterm>** why only three choices?
**\<fluffypony>** jwinterm: so that people actually use the two other than the default
**\<moneromooo>** To avoid splitting txes in too many classes.
**\<sgp>** So how about 10, 20, 50, 100? Something like that. Pending the research of course
**\<fluffypony>** you want to get lost in the mix, remember :)
**\<vtnerd1112>** So fireice\_uk is working on the rpc download changes before any crypto stuff ... ?
**\<i2p-relay> {-olark}** The assumption in MRL-001 is that an attacker would need roughly 80% of outputs in the entire blockchain to de-anon a transaction but in reality if we use an output selection algo similar to what my survey results convey than in reality an attacker would only need 70%ish of spent outputs in the past day to reliably de-anon some transactions
**\<vtnerd1112>** Oops thought that topic was done
**\<sgp>** ^ with what ringsize?
**\<fluffypony>** vtnerd1112: yes - we decided in the last meeting that he'd switch milestone orders around
**\<moneromooo>** Oh, that ought to be done on 0MQ then.
**\<i2p-relay> {-olark}** Smooth and myself had come to a conclusion that mixin 4 is fine but if the attack in MRL-001 is made easier with a selection algo like I am suggesting we may need to increase the mandatory ringsizes to protect against an attack like MRL-001
**\<fluffypony>** olark: this changes with zipf, right?
**\<fluffypony>** ie. a great portion of the ring uses the past day's outputs
**\<vtnerd1112>** Ok, pigeons told me mymonero seemed to be under lots of load. Ive got some preliminary work done that he could continue to completion
**\<vtnerd1112>** Just enough to give mymonero a bump hopefully
**\<fluffypony>** vtnerd1112: that's fine, maybe ping him and tell him that? fireice\_uk never attends dev meetings and is never on IRC
**\<moneromooo>** Maybe that's not actually bad.
**\<i2p-relay> {-olark}** What to increase it to is up in the air obviously. Still have more work to do
**\<i2p-relay> {-olark}** fluffypony: Yes. Based on the survey I have done so far roughly 70% of spent outputs are from the past day. Future surveying will be going over 2011-2012 to see if there is any change in the distributions.
**\<fluffypony>** ok I'm fine with that - olark, what are your thoughts on writing it up as an MRL paper later on once the discussion is finalised?
**\<moneromooo>** I think current min is still 2. We could go to 4 in september, and still increase later.
**\<sgp>** I think we should increase it >4 in September
**\<bigreddmachine>** -olark: is there a way to see what the distribution looks like for txs not related to mining? i'd guess a lot of the quickness in spending is from pools transfering out coins to miners, but in the future this might be a much smaller proportion
**\<xmr\_eric>** Are we still playing around with having a static ringsize?
**\<moneromooo>** Pool payment txes are often with more than 2 outputs.
**\<sgp>** @xmr\_eric yes
**\<xmr\_eric>** Cool
**\<fluffypony>** moneromooo: with the new range proofs etc. it might be worthwhile just making the min based on that
**\<moneromooo>** Not a guarantee of course. Especially now -\_-
**\<i2p-relay> {-olark}** fluffypony: Sure I can write an MRL paper once I have more of it fleshed out.
**\<fluffypony>** can always use like a 10 output tx as a measuring bar
**\<moneromooo>** fluffypony: sounds good
**\<gingeropolous>** ^ interesting
**\<i2p-relay> {-olark}** xmr\_eric: The idea is having 3 static ringsizes for varying levels of paranoia similar to the different fee priorities we have.
**\<xmr\_eric>** Right
**\<bigreddmachine>** moneromooo: if we're just looking for a filter on pool txs, we can always use the pools' apis to get txids. my point was those txs might be 50% of all txs now, but 5% two years from now, which impacts the math.
**\<gingeropolous>** are disposable / one-time addresses happening? I didn't see it make the list of things not to pull in.
**\<moneromooo>** That allows me to...
**\<moneromooo>** luigi1112: is kenshi84's disposable address patch ready in the theoretical sense, you think ? ie, can I go over it again assuming the math/crypto's final ?
**\<fluffypony>** I haven't looked at it in a while, I'll have to re-review the PR to both the MRL and normal repos
**\<fluffypony>** ok we need to wrap up - let's discuss it further later on
**\<fluffypony>** 6. Confirm next meeting date/time
**\<fluffypony>** April 23