monero-project/monero-site
monero-project/monero-site
1
0
Fork 0
mirror of https://github.com/monero-project/monero-site.git synced 2024-12-23 20:19:29 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge pull request #1 from monero-project/master

Browse source 
Up to date?
This commit is contained in:
rehrar 2017-05-27 11:34:15 +03:00 committed by GitHub
commit 3d36468f8c
18 changed files with 1900 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
README.md
View file

@ -4,8 +4,8 @@ Copyright (c) 2014-2017, The Monero Project
## Development Resources
Web: [getmonero.org](http://getmonero.org)
Mail: [dev@getmonero.org](mailto:dev@getmonero.org)
Web: [getmonero.org](http://getmonero.org)
Mail: [dev@getmonero.org](mailto:dev@getmonero.org)
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

16
_data/merchants.yml
View file

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

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

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

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

103
_posts/2017-04-19-an-unofficial-response-to-an-empirical-analysis-of-linkability.md Normal file
View file

@ -0,0 +1,103 @@
---
layout: post
title: An Unofficial Response to "An Empirical Analysis of Linkability in the Monero Blockchain"
summary: A community-drafted response to Andrew Miller, et al.
tags: [core, crypto, research]
author: Justin Ehrenhofer (SamsungGalaxyPlayer) and the Monero community
---
# Preface
This release attempts to contain the opinions of the Monero community. It is possible that not every viewpoint is expressed, but this paper includes the best response to the author's ability that encapsulates all these opinions. The author opens all discussion to how certain viewpoints are represented, and the purpose of this response is solely for easier documentation by interested parties. He has done the best to include sources wherever possible, and to be as accurate as possible. For any concerns with this publication, please express them to the [author's Reddit account](https://www.reddit.com/u/SamsungGalaxyPlayer) or on [the Monero subreddit](https://www.reddit.com/r/Monero/). This version has been updated for clarity, though the core content has remained unchanged.
The Monero contributors and community at large always appreciate any research done on Monero's technology. They heavily encourage constructive criticism of all cryptocurrencies.
# Notable Findings
The Monero contributors appreciate the effort that has gone into this mentioned publication and research methods. It helps quantify several realizations that had already been known to the Monero community at large for a long time (ref: [MRL-0001](https://lab.getmonero.org/pubs/MRL-0001.pdf) and [MRL-0004](https://lab.getmonero.org/pubs/MRL-0004.pdf)), including the following:
1. 0-mixin transactions (those that only include the real input and no others) are traceable on the blockchain. [MRL-0001](https://lab.getmonero.org/pubs/MRL-0001.pdf) (published September 2014) also points this out, and Monero reacted to the concern by prohibiting 0-mixin transactions from the network in April 2016. The current minimum mixin allowed on the network is 2, which was mandated in March 2016. In September 2017, the minimum will be increased to at least 4, though there is [some discussion](https://github.com/monero-project/monero/issues/1673) going on in the community to choose the exact value. For clarification of terms used, ringsize is a newly-adopted term to replace mixin with the intentions of removing comparisons to traditional mixing services. Ringsize = mixin + 1.
2. The prohibition of 0-mixin transactions has allowed the network to recover relatively quickly by making it harder to know which input is used. This paper helps quantify this recovery, from about 95% traceable to 20% traceable (see appendix).
3. The proportion of transactions that have their inputs deducible has fallen substantially from 1 January 2016 to 1 Feb 2017 with 2 and 4 mixin transactions. Respectively, these fell from 82% and 72% to 41% and 23% (see appendix). Furthermore, this proportion is down to 0% with RingCT transactions, which are now [over 99% of all new transactions on the network](http://moneroblocks.info/stats).
4. The phenomenon where the most recent input is the real one is a concern when using Monero. There is no way to prove that this input is indeed the correct one, and with recent transactions, the assertion is nearly impossible to prove and is accurate less than half of the time. As the report states, there is about a 40% chance that the most recent input in a default transaction is the real one. Ideally, this number should be closer to 20% (1 in 5). Note that this does not mean that there is a 40% chance that this transaction is traceable (see appendix). Increasing the transaction ringsize has only a marginal improvement.
# Recommendations and Responses
The following are the recommendations listed in the paper and responses to them:
1. The mixing sampling distribution should be modified to closer match the real distribution. We agree with this recommendation. The discussion covering the possible ways to do this, along with all associated research, [can be seen on GitHub](https://github.com/monero-project/monero/issues/1673) . As the paper acknowledges, we made a temporary improvement to the selection algorithm to choose more recent inputs (instead of pure random selection) in December 2016. Further improvements are required, and they are planned to be ready before or at the September 2017 hardfork date. As the paper notes, this change is not consensus-critical. It can be done the day after completion without a hardfork.
2. The Monero community should engage in further data-backed analysis of privacy claims. We agree with this recommendation. Data-backed claims are an excellent way to improve the Monero privacy and security features. As stated in the paper, the threats discussed in the paper were discussed in the community previously. Unlike the paper claims, these discussions were not "informal"; instead, they were published in our [MRL-0004](https://lab.getmonero.org/pubs/MRL-0004.pdf) research paper in January 2015. Nevertheless, several of these attack vectors explained in the Decentralized Systems Lab paper are quantified for the first time.
3. Monero users should be warned that their prior transactions are likely vulnerable to linking analysis. We mostly disagree with this recommendation. The vulnerabilities of 0-mixin transactions were well-documented and continuously shared with the Monero community while they were still allowed. The first research paper shared in the Monero community ([MRL-0001](https://lab.getmonero.org/pubs/MRL-0001.pdf)) was published in September 2014. Furthermore, most of Monero's community growth occurred after these 0-mixin transactions were prohibited across the network.
# Concerns
The Monero community would like to list several concerns with this research paper. They are documented below:
1. We believe that a large proportion of 0-mixin transactions are pool payouts. These transactions should come to no one's surprise that they are traceable, since the pools themselves publish the payment amount to each transaction hash. Thus, we believe that the claims stemming from the traceability of transactions before 0-mixin transactions were banned to be misplaced. If, for example, 50% of non-pool payouts used a positive mixin and 0% of pool payouts did, then the traceability is less for the transactions that use these mixins and greater for pool payouts. We recommend that this is acknowledged in a later iteration of the paper. Ideally, the proportion of pool payouts can be found and compared to the proportion of non-pool payouts, with different traceability proportions for each. There are several reasons why these transactions neither reduce the anonymity of the transaction itself or other users. In regards to the former, coinbase transactions (ie: new rewards given to the pool) are 0-mixin, since having mixins is useless if the input is brand new and seen for the first time. Anyone who mines understands that the source of their money is clear, and so pools received little pressure to increase the ringsize for payout transactions. In regards to other transactions, the pool payouts occur within the day, reducing the negative impact spending these transactions has on other users who may have borrowed the input for their transaction. Thus, pool payouts should include additional mixins, but excluding them has relatively minimal harm. The larger threat is the opportunity cost, where the additional mixins could provide greater levels of privacy for other users. Furthermore, all transactions are still unlinkable by the MRL definition of the word (see "Other Information" point 4) ([source](https://www.reddit.com/r/Monero/comments/65dj7u/an_empirical_analysis_of_linkability_in_the/dga1rza/?context=1)).
2. We think further emphasis should have been placed in the paper to explain that the claims are only minimally applicable with the state of Monero transactions since March 2016, with the relevance decreasing over time. Though it is mentioned that their first analysis method has little if any current or future relevance, the claims still include these transactions. 0-mixin transactions were prohibited in March 2016, and most transaction volume for the year occurred during and after August. Nevertheless, many of these post-March transactions have inputs that can be deducible, but the traceability typically is not as severe as with 0-mixin transactions. The transactions that are most vulnerable are those in 2014 and 2015, as well as some time needed for the network to recover.
3. Under the "ethics" section, they state that the paper was published immediately before countermeasures could be deployed. While this is understandable from the given perspective that the blockchain history is not going away anytime soon (or ever), we wish that they had given us an advance copy of the finished draft so that we could have discussed our concerns with the report itself. We wish not to censor any of the research (instead, we encourage research!); however, we hope that future care can be taken before the release of misleading assertions.
4. Andrew Miller was named in the paper as a consultant to the Zerocoin Electric Coin Company and a board member of the ZCash Foundation. ZCash is a cryptocurrency with a focus on privacy that uses different technology than Monero. However, [he downplayed his involvement in an interview](https://cointelegraph.com/news/monero-transactions-history-can-be-revealed-and-exposed-research) about this paper. We feel author involvement in cryptocurrencies with similar interests should be fully disclosed, though he did refer people to the first page of the report. Nevertheless, we feel that Miller's disclosure of his contribution to a competing project was unsatisfactory, given the severity of the allegations in the paper.
# Other Information
1. The timing of the publication. This paper was released approximately an hour before the hardfork. While it is impossible to know the reason for the specific timing without an admission, we speculate that this was timed to draw as much attention to the paper as possible. More people would have been tuning in to see how the hardfork was proceeding than typical community participation traffic. Andrew Miller has responded to this criticism in a Reddit comment, saying "the timing of our release with the imminent hard fork was totally unintentional and a coincidence. No one on the team noticed there was a hardfork planned, and we'd definitely have delayed till afterward if we had."
2. This paper was shared as "new research" about Monero. While the research is itself new and some of the analysis is the first time that some concerns have been quantified, these concerns themselves are not new. In sharing the paper, the authors often posted misleading claims that asserted these concerns were new.
3. The Monero Core Team was given an advance draft of the report on 15 March 2017. This report at the time looked only at transactions before January 2017. All further edits to the paper were published before consulting with the Core Team. Riccardo Spagni, known to many as fluffypony or fluffyponyza, responded commending the efforts and stated at the time that the 0-mixin analysis confirmed previous work on [MRL-0004](https://lab.getmonero.org/pubs/MRL-0004.pdf). During the email exchange, Spagni suggested that the research also be published in the Monero Research Lab research, an idea Andrew Miller seemed open to at the time. Furthermore, the real release date was later than the target given to the Core Team, and the Core Team was not given a new estimated date of release.
4. The paper refers to the traceability of transactions in the blockchain as "linkability". We encourage the authors to change the terminology to "traceability", since linkability typically refers to the ability to connect cryptocurrency wallet location to real-world locations. This will help clear up misconceptions held by many community members, since the Monero Research Lab refers to the connection of funds within the cryptocurrency as "traceability."
5. This paper has not yet been published, is not finalized, and is not yet peer reviewed. Thus, there will most certainly be changes to this research paper before publication. We suggest that all claims and research be taken as preliminary and not concrete, since not enough people have evaluated their methods of research yet.
# Conclusion
We appreciate the effort that went into this research paper, but we suggest the following changes for later improvements:
1. A re-evaluation of recommendation #3.
2. A consideration among 0-mixin transactions for pool payouts.
3. A clearer explanation of claims made in the paper, with separations for the history of all transactions and those used since March 2016. It is disappointing to treat the blockchain data as static when the technology has evolved significantly since Monero's launch.
4. Future drafts to be shared with the Monero Core Team before release. Their contact information is [dev@getmonero.org](mailto:dev@getmonero.org).
5. Be more conservative sharing the results. We understand that the authors have an incentive to share the results with others and we also want them to be shared, but we ask that they refrain from using misleading claims to gather traffic (see appendix for example).
6. Consider cooperating with Riccardo Spagni to permanently include the research portion of this paper in our Monero Research Lab documents.
# Appendix
**Figure 5 from the report showing the fraction of deducible inputs. Notice the large drops following block height 1,000,000, when 0-mixin transactions were prohibited. Furthermore, these inputs likely do not include all those used in a single transaction. For instance, for a mixin 9 transaction, 5 may be deduced. This means that the inputs would be reported here as deducible, even if the transaction is not traceable.**
<img src="/blog/assets/linkability-response/figure5.jpg" style="width: 600px;"/>
**Table 2 from the report showing the proportion of transactions with a positive mixin that can be deduced. We want to make clear that the findings of this chart and analysis method have absoutely zero relevance to RingCT transactions.**
<img src="/blog/assets/linkability-response/table2.jpg" style="width: 800px;"/>
**Table 3 from the report showing the proportion of deducible transactions where the real input is also the most recently used one in the transaction.**
<img src="/blog/assets/linkability-response/table3.jpg" style="width: 800px;"/>
**Examples of statements we find misleading**
This is a tweet from a contributor to the paper.
<img src="/blog/assets/linkability-response/tweet.jpg" style="width: 600px;"/>
This image is from the [CoinTelegraph interview](https://cointelegraph.com/news/monero-transactions-history-can-be-revealed-and-exposed-research). Based on the wording, you may think an attacker could determine with certainty which input is yours. However, the attacker can guess and be correct less than half of the time. Furthermore, even if the attacker guesses correctly, there is no way of proving this with certainty with data from the blockchain alone.
<img src="/blog/assets/linkability-response/cointelegraph.jpg" style="width: 600px;"/>
Andrew Miller asked us to include other statements from the researchers or ZCash Foundation members that we feel is misleading. This paper is not supposed to be a comprehensive list of such statements. It is only useful in providing a few examples.
This draft was shown to Andrew Miller before release on the website. Some of his considerations have been included in this response.

91
_posts/2017-04-23-logs-for-the-Kovri-dev-meeting-held-on-2017-04-23.md Normal file
View file

@ -0,0 +1,91 @@
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2017-04-23
summary: Brief review of what has been completed since last meeting, Monero HackerOne Bounty, 96boards OpenHours showcase, Github repo privilege discussion, website discussion, and code & open tickets discussion
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*April 23th, 2017*
# Logs
**\<anonimal>** 1. Greetings
**\<anonimal>** 2. Brief review of what's been completed since the previous meeting
**\<anonimal>** 3. More preparation for [96boards.org OpenHours showcase for Kovri / Monero](https://github.com/monero-project/meta/issues/46) (@fluffypony @danrmiller location status, @anonimal "de-anon consideration" status)
**\<anonimal>** 4. Status (again) of [Monero HackerOne umbrella and bounty](https://github.com/monero-project/meta/issues/39). [hackerone.com/monero](https://hackerone.com/monero) is online but we need to resolve FFS funding before inviting researchers. VRP status for all projects + bounty status
**\<anonimal>** 5. Website status (@rehrar @bigreddmachine @alvinjoelsantos @danrmiller)
**\<anonimal>** 6. Code + ticket discussion / Q & A
**\<anonimal>** 7. Any additional meeting items
**\<anonimal>** 8. Confirm next meeting date/time
**\<anonimal>** Hello. It looks like fluffypony is MIA.
**\<anonimal>** 2. Brief review of what's been completed since the previous meeting
**\<anonimal>** https://github.com/monero-project/kovri/pulse/monthly \<-- #615 to #629, in particular #627
**\<anonimal>** Anything else before we move onto 3.?
**\<anonimal>** 3. More preparation for [96boards.org OpenHours showcase for Kovri / Monero](https://github.com/monero-project/meta/issues/46) (@fluffypony @danrmiller location status, @anonimal "de-anon consideration" status)
**\<anonimal>** fluffypony is MIA, I think pigeons is MIA, I'm not de-anoning for the time being.
**\<anonimal>** Anything else on 3.?
**\<guzzijones12>** on 2 i am working on removing the global client context.
**\<anonimal>** Whatever your strategy is, the same strategy *should* apply to core context, just FYI.
**\* anonimal** we can talk more in 6.
**\<anonimal>** 4. Status (again) of [Monero HackerOne umbrella and bounty](https://github.com/monero-project/meta/issues/39). [hackerone.com/monero](https://hackerone.com/monero) is online but we need to resolve FFS funding before inviting researchers. VRP status for all projects + bounty status
**\<anonimal>** fluffypony needs to move this to funding required https://forum.getmonero.org/6/ideas/87597/monero-bounty-for-hackerone
**\<anonimal>** We can't move forward until that happens.
**\<anonimal>** I've submitted a VRP to monero/#1995
**\<moneromooo>** luigi1112: is that something you have privs to do ?
**\<moneromooo>** (also surae's).
**\<anonimal>** Once #1995 is fleshed out, I'll submit to the core repo and the website with relevant adjustments (as we discussed in previous meeting(s))
**\* anonimal** not sure if luigi is around, anything else on 4.?
**\<moroccanmalinois>** Before the alpha release, if i find a bug that can, for example, crash a router, should i go through the process or is it cool to just PR ?
**\<anonimal>** moroccanmalinois: PR. We probably won't even apply our VRP until we are in beta, btw.
**\<anonimal>** We should add a note if that will be the case.
**\<moroccanmalinois>** ok
**\<anonimal>** 5. Website status (@rehrar @bigreddmachine @alvinjoelsantos @danrmiller)
**\* anonimal** has nothing on 5., will await any response
**\<anonimal>** Alright, more no-shows AFAICT :/
**\<anonimal>** 6. Code + ticket discussion / Q & A
**\<guzzijones12>** like you said move to the other contexts after client context for me.
**\<anonimal>** moroccanmalinois: re: #624, I received a response saying that he'll look into the issue.
**\<moroccanmalinois>** ok
**\<anonimal>** guzzijones12: you can PR the client one first before moving onto core. There may be related issues to resolve anyway.
**\<anonimal>** (as long as it works)
**\<guzzijones12>** yes ok.
**\<anonimal>** Anything else on 6.? Questions?
**\<anonimal>** 7. Any additional meeting items
**\<anonimal>** None from me. Anyone else?
**\<guzzijones12>** i am good.
**\<ArticMine>** I am good
**\<anonimal>** 8. Confirm next meeting date/time
**\<anonimal>** Two weeks, same time.
**\<anonimal>** Thanks everyone. In under 20 minutes!
**\<rehrar>** Sorry here.
**\<rehrar>** Lel. I was expecting meeting at 1.
**\<johnalan>** tumbleweeds
**\<johnalan>** ;)
**\<johnalan>** hows the Kovri site?
**\<johnalan>** any news on that end?
**\<rehrar>** Well, I showed the design for it, which was based off of the chosen Monero design.
**\<rehrar>** I've been making Monero wires.
**\<rehrar>** The Kovri site should be easier since there's not as much info.
**\<johnalan>** cool - great work
**\<rehrar>** Because of that, I'd like to make custom pages for each Kovri page based on the same CSS framework that will be developed for Monero.
**\<rehrar>** The goal for both sites is to make upkeep and adding/editing pages as simple as possible. As simple as copy and pasting out of a HTML/css assets document to construct the blocks of pages.
**\<johnalan>** fab
**\<johnalan>** sounds good my man
**\<rehrar>** If you'd like to take a look at the wires, let me know.
**\<rehrar>** I'm still toying with the garlic logo when I feel inclined. :P
**\<johnalan>** :)
**\<johnalan>** got a link to the latest wires?
**\<guzzijones12>** hard to make the logo and make it look garlic with those colors. imo
**\<rehrar>** Sure. I'll PM them to you.
**\<luigi1112>** sorry afk. will be around later, ping again if you think about it
**\<anonimal>** luigi1112: can you move this to funding required? fp said he would do it soon after the last meeting IIRC https://forum.getmonero.org/6/ideas/87597/monero-bounty-for-hackerone
**\<luigi1112>** I probably can, not at computer right now though
**\<anonimal>** k
**\<anonimal>** moroccanmalinois: new proposal open. #630
**\<ajs>** 5. Website status: @pigeons got the site I worked on up and running on a server, but I guesss we will go with @rehrar design since it is better
**\<needmultisig90>** as far as the deanon goes, I actually like that our figurehead working on Kovri is anonymous
**\<needmultisig90>** just food for thought
**\<needmultisig90>** Perhaps I'm in the minority, but I think it's both prudent (from a rubber hose attack perspective) and aligns with the ethos of the project.
**\<needmultisig90>** @anonimal
**\<anonimal>** Sounds fair.

201
_posts/2017-05-07-logs-for-the-Kovri-dev-meeting-held-on-2017-05-07.md Normal file
View file

@ -0,0 +1,201 @@
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2017-05-07
summary: Brief review of what has been completed since last meeting, Monero HackerOne Bounty, 96boards OpenHours showcase, website discussion, and code & open tickets discussion
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*May 7th, 2017*
# Logs
**\<anonimal>** 1. Greetings
**\<anonimal>** 2. Brief review of what's been completed since the previous meeting
**\<anonimal>** 3. More preparation for [96boards.org OpenHours showcase for Kovri / Monero](https://github.com/monero-project/meta/issues/46) (@fluffypony @danrmiller location status)
**\<anonimal>** 4. Status (again) of [Monero HackerOne umbrella and bounty](https://github.com/monero-project/meta/issues/39). [hackerone.com/monero](https://hackerone.com/monero) is online but we need to resolve FFS funding before inviting researchers. VRP status for all projects + bounty status
**\<anonimal>** 5. Open forum for https://github.com/monero-project/kovri/issues/630
**\<anonimal>** 6. Website status (@rehrar @bigreddmachine @alvinjoelsantos @danrmiller)
**\<anonimal>** 7. @EinMByte ...where is he? Github repo privilege discussion
**\<anonimal>** 8. Code + ticket discussion / Q & A
**\<anonimal>** 9. Any additional meeting items
**\<anonimal>** 10. Confirm next meeting date/time
**\<anonimal>** Hello
**\<moroccanmalinois>** hi
**\<sgp>** hey!
**\<endogenic>** o/
**\<ajs>** Here
**\<iDunk>** \o
**\<i2p-relay> {-fluffypony}** hi!
**\<rehrar>** Here for a bit, then gone, then back.
**\<anonimal>** Yay, enough people for a party.
**\<Heretoobserve>** Hello
**\<anonimal>** 2. Brief review of what's been completed since the previous meeting
**\<rehrar>** 3...2...1... KOVRI!!!
**\<ArticMine>** hello
**\<anonimal>** For me, see http://forum.getmonero.org/9/work-in-progress/86967/anonimal-s-kovri-full-time-development-funding-thread?page=&noscroll=1#post-90900
**\<anonimal>** moroccanmalinois can fill us in on his work.
**\<moroccanmalinois>** i've been playing with fuzz testing
**\<i2p-relay> {-fluffypony}** nice
**\<anonimal>** I've looked through the PR's, looks like fun.
**\<moroccanmalinois>** it's the beginning. More tests to come
**\<anonimal>** Any questions/comments on point 2?
**\<i2p-relay> {-fluffypony}** and guzzi ?
**\<anonimal>** guzzi is not here, ...again...
**\<anonimal>** He says he's doing work but I haven't seen a commit or question from him in over 7 weeks, AFAICT.
**\<anonimal>** I think he's trying to separate the contexts from the singleton. At least that's the end goal.
**\<i2p-relay> {-fluffypony}** guzzi: when you read this, please make an effort to attend meetings
**\<i2p-relay> {-fluffypony}** I know you're around at other times, but meetings are important
**\<anonimal>** Yes, please.
**\<anonimal>** Ok, anything else on 2.?
**\<i2p-relay> {-fluffypony}** no
**\<anonimal>** 3. More preparation for [96boards.org OpenHours showcase for Kovri / Monero](https://github.com/monero-project/meta/issues/46) (@fluffypony @danrmiller location status)
**\<anonimal>** Is pigeons still in Africa? This point was moved from last meeting.
**\<i2p-relay> {-pigeons}** i returned yesterday
**\<moneromooo>** Are you suggesting pigeons migrate ?
**\<i2p-relay> {-pigeons}** i saw rock doves
**\<anonimal>** fluffypony? How's it going?
**\<i2p-relay> {-fluffypony}** anonimal: it's a podcast, right?
**\<anonimal>** https://www.96boards.org/openhours/, there are videos too.
**\<i2p-relay> {-fluffypony}** ok well I'm ready whenever
**\<i2p-relay> {-fluffypony}** I don't really prepare for stuff like this
**\<bigreddmachine>** sorry i'm late!
**\<anonimal>** Ok well what time/date works for you?
**\<anonimal>** fluffypony ^
**\<i2p-relay> {-fluffypony}** anonimal: my PA would have to schedule it - probably best to get my PA to schedule myself and pigeons and them
**\<i2p-relay> {-fluffypony}** she's good at that
**\<i2p-relay> {-fluffypony}** it's literally her job :-P
**\<i2p-relay> {-pigeons}** I was thinking ask hyc if he's interested, he's been playing with arm and monero i think
**\<i2p-relay> {-fluffypony}** cool
**\<i2p-relay> {-fluffypony}** hyc is a beautiful man
**\<bigreddmachine>** +1 Ric's PA. She was great when i wanted to schedule a podcast
**\* anonimal** pinged him in #monero-dev
**\<anonimal>** Ok well at this point, IMHO, fluffypony I think it would be good for you to touch base / introduce yourself to sdrobertw in #OpenHours on freenode.
**\<anonimal>** I think I can only play the middleman for so long.
**\<i2p-relay> {-fluffypony}** email is better for Shay, I don't think I can teach her IRC :-P
**\<anonimal>** Contact info? I have none.
**\<i2p-relay> {-fluffypony}** for them?
**\<i2p-relay> {-fluffypony}** didn't we reach out to them via email first?
**\<i2p-relay> {-fluffypony}** \* can't remember
**\<anonimal>** For Shay
**\<anonimal>** No, not via email, all IRC.
**\<i2p-relay> {-fluffypony}** oh lol
**\<i2p-relay> {-fluffypony}** pa@spagni.net
**\<anonimal>** Alright, anything else on this point before moving on?
**\<anonimal>** 4. Status (again) of [Monero HackerOne umbrella and bounty](https://github.com/monero-project/meta/issues/39). [hackerone.com/monero](https://hackerone.com/monero) is online but we need to resolve FFS funding before inviting researchers. VRP status for all projects + bounty status
**\<anonimal>** I've sent a VRP to monero, it's been merged. I believe we're funded at ~500 XMR, which is great.
**\<anonimal>** Any questions?
**\<anonimal>** We just need to launch after submitting VRP to the GUI (and site?)
**\<anonimal>** Sound good?
**\<bigreddmachine>** Is the bounty held in xmr or something else?
**\<anonimal>** Yes. Link to FFS in the meta issue.
**\<ArticMine>** https://forum.getmonero.org/8/funding-required/87597/monero-bounty-for-hackerone It was funded to 500 XMR and then increased to 1000 XMR for further funding
**\<bigreddmachine>** ty
**\<anonimal>** I think we can start now before funding is at 1000.
**\<anonimal>** (it won't mean we'll find researchers immediately anyway)
**\<anonimal>** Any questions/comments before moving onto next point?
**\<i2p-relay> {-fluffypony}** yrah
**\<i2p-relay> {-fluffypony}** agreed
**\<i2p-relay> {-fluffypony}** we can continue to increase it as necessary
**\<anonimal>** Ok. Moving on,
**\<anonimal>** 5. Open forum for https://github.com/monero-project/kovri/issues/630
**\<anonimal>** Comments needed before we move on this.
**\<i2p-relay> {-fluffypony}** I agree with MoroccanMalinois, but I think it's manageable if we set a severity
**\<i2p-relay> {-fluffypony}** and some caveats
**\<moneromooo>** Maybe a strict validity domain definition would do good (ie, "we only accept vulns in the following categories").
**\<moneromooo>** And then expand the list as stuff matures.
**\<bigreddmachine>** moneromooo - why would we restrict?
**\<moneromooo>** To prevent known problems from being reported, or problems in stuff that is known to be unfinished.
**\<i2p-relay> {-pigeons}** because the code has a bunch of legacy mess and is early state with low hanging fruit that is just later on the to fix when that section gets refactored
**\<anonimal>** Yes. So, with that said, I don't know what categories we could even have.
**\<anonimal>** *at this stage*
**\<anonimal>** moneromooo: did you have any ideas on categories for this stage?
**\<moneromooo>** No. I've not really looked at kovri yet, despite saying I would (sorry).
**\<i2p-relay> {-pigeons}** i2p consensus related issues
**\<i2p-relay> {-pigeons}** if we implement like X we might cause incompatibility
**\<i2p-relay> {-pigeons}** maybe those but again maybe those are known and will be fixed when those sections are given love
**\<moneromooo>** Anything which can leak keymat. Good starting point.
**\<moneromooo>** Ideally you'd start giving bounties when you know you've done what you could, and the bounty to find bugs is less than what your time is worth looking at it :)
**\<anonimal>** pigeons: Well, then I think that's java I2P's problem because they would then have to keep up with us. What we could do now though is start with a research-related category for general specifications?
**\<moneromooo>** So it's a bit subjective.
**\<anonimal>** moneromooo: indeed, and this is border-lining on simply hiring a new dev too with the funds available.
**\<moneromooo>** Well, the draw is that the bounty ensures results for the money.
**\<moneromooo>** So expert time.
**\<anonimal>** What if we opened bounty for non-implementation research? I know this is an MRL area though.
**\<anonimal>** Or we could open more categories for implementation but the payout is smaller because code is Alpha?
**\<moneromooo>** For finding bugs in the theory, definitely worth doing so (for monero anyway, I expect kovri's following established research already).
**\<anonimal>** (then they would risk waiting to beta to 0day to get bigger payout?)
**\<rehrar>** what up kids? I'm here.
**\<anonimal>** I think monero's research is more vetted than I2P's, even though I2P has been around longer. Simply because there are less moving parts.
**\<moroccanmalinois>** +1 for bounty for non-implementation research
**\<moneromooo>** Interesting.
**\<anonimal>** Just my opinion. I've read the I2P papers available, I'm not blown away but it's better than nothing.
**\<anonimal>** And not like I'm in a position to drop everything to do purely research so...
**\<anonimal>** We'll add categories for bounty? One obvious one being research. Maybe crypto implementation sooner than later since that's a big one.
**\<anonimal>** Sound fair?
**\<moneromooo>** From a relative outsider, it seems like a sensible start.
**\<bigreddmachine>** yes. is "leaked info" too broad of a category?
**\<moroccanmalinois>** yes for me
**\<anonimal>** Yes because a leak would cover too much code that hasn't been vetted.
**\<anonimal>** \* could cover
**\<anonimal>** Ok, I'll get that going then.
**\<anonimal>** Moving on. 6. Website status (@rehrar @bigreddmachine @alvinjoelsantos @danrmiller)
**\<i2p-relay> {-pigeons}** I need to talk with fluffypony about a potential dns thing
**\<rehrar>** aight, so just in case somebody hasn't seen the Kovri web design here it is: http://imgur.com/a/An8K8
**\<rehrar>** it's the top one
**\<i2p-relay> {-pigeons}** then the demo of ajs' site should be up
**\<i2p-relay> {-fluffypony}** I got msgs about it
**\<i2p-relay> {-fluffypony}** will look at it tomorrow
**\<rehrar>** it's based on the same framework as the getmonero.org website, so once the custom framework is made for one, it is easy to make pages for the other
**\<rehrar>** my update is that we're making the framework even now, and it's coming along well, I should be able to make a few experimental Kovri pages soon
**\<rehrar>** The question is content.
**\<anonimal>** I think the "It's I2P, but in C++" phrase should go; we should use our standard "A secure, private, untraceable C++ implementation of the [I2P anonymous network](https://getmonero.org/knowledge-base/moneropedia/i2p)"
**\<ajs>** I will work with rehrar to write up some content, but need direction on what should be included.
**\<rehrar>** that's fine. Copy is not indicative. :)
**\<bigreddmachine>** My past month has been packed getting ready for my phd comprehensive exam (1 step before the defense). So I haven't looked at the site yet, but talked briefly with ajs about it and plan to get more involved now that that's done.
**\<anonimal>** Other than that, can we move this item to the website meeting in #monero in 10 minutes?
**\<rehrar>** sure, that sounds alright.
**\<moneromooo>** It looks nice (says the cow who's got no clue about design).
**\<ajs>** K
**\<anonimal>** bigreddmachine ajs: will you be around in 10 minutes in #monero?
**\<ajs>** Yes
**\<bigreddmachine>** yeah, i'm also editing tonight's podcast episode so i may take a minute to reply
**\<anonimal>** rehrar: yes, what moneromooo said, looks nice
**\<rehrar>** cool. If people have ideas for content that are not on the demo site
**\<anonimal>** Ok, moving on. 7. @EinMByte ...where is he? Github repo privilege discussion
**\<rehrar>** let me know
**\<rehrar>** I'd like to have a simple website for alpha release :)
**\<anonimal>** fluffypony: so... his last commit was from Septemeber 19th, he's not responded to 99% of my pings since then...
**\<bigreddmachine>** i haven't seen him since i started getting involved in Jan
**\<anonimal>** I speak highly of him and his work, I think he's a great contributor and wish he was around more.
**\<bigreddmachine>** could be a legal issue?
**\<anonimal>** The problem is he's not around anymore, he has assigned issues of which I've had to assign myself since he's not around to do them.
**\<anonimal>** And he has repository push access. If something happened to him and his account is compromised, we could be left in an embarrassing trolling situation where someone deletes the repo.
**\<anonimal>** I don't want to send any wrong signals but I also think access privileges should be on an as-needed basis.
**\<bigreddmachine>** i think that's fair. can always be re-established if he comes back and he can be verified
**\<bigreddmachine>** in that vein, should things like Salti tracking be moved to another place?
**\<anonimal>** I don't know, we'll have to bring that up at the next meeting I think since we're running out of time.
**\<anonimal>** fluffypony: any thoughts about this? Will you remove EinMByte's github push access privileges?
**\<moneromooo>** I think it's fair to revoke for inactivity and failure to reply to pings. Reinstate when back.
**\<bigreddmachine>** okay, can we add #619 to next meeting's agenda?
**\<moneromooo>** I'd also want to remove warptangent's key (unlikely to be back to use it) and a few others.
**\<anonimal>** bigreddmachine: oh, sure I guess, more research/info needed.
**\<bigreddmachine>** k i'll just reply to the issue and talk about it there for now. sorry to jump into other discussion about that.
**\<anonimal>** No problem
**\<anonimal>** Since we're running out of time, 8. Code + ticket discussion / Q & A
**\<bigreddmachine>** last update from me — mozilla work continues with the proxy stuff, but not ready yet. i don't have a good feel for how long
**\<anonimal>** Anything pressing? Questions/comments that can't be answered on github or after the meeting?
**\<anonimal>** Ok, thanks bigreddmachine
**\<rehrar>** not from me, I'll be in contact :(
**\<rehrar>** :)
**\<anonimal>** 9. Any additional meeting items
**\<bigreddmachine>** none. thanks anonimal!
**\<anonimal>** Nothing from me, other than I need to AFK rehrar so, bigreddmachine ajs pigeons if you want to talk more about kovri-site then I'll have to read backlog
**\<rehrar>** aight, thanks.
**\<sgp>** Now over to monero!
**\<ajs>** K
**\<anonimal>** Thank you all if you keep the torch burning for the site, awesome.
**\<anonimal>** 10. Confirm next meeting date/time
**\<anonimal>** 2 weeks, same time?
**\<rehrar>** indeed
**\<anonimal>** Ok. Thanks everyone :)

291
_posts/2017-05-07-overview-and-logs-for-the-dev-meeting-held-on-2017-05-07.md Normal file
View file

@ -0,0 +1,291 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2017-05-07
summary: Sub / disposable addresses, smart mining GUI, 0MQ, and MyMonero-in-tree discussion
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
---
*May 7th, 2017*
# Overview
An overview [can be found on MoneroBase](https://monerobase.com/wiki/DevMeeting_2017-05-07).
# Logs
**\<fluffypony>** 1. Greetings
**\<fluffypony>** 2. Brief review of what's been completed since the previous meeting
**\<fluffypony>** 3. Code + ticket discussion / Q & A
**\<fluffypony>** 4. MyMonero-in-tree discussion
**\<fluffypony>** 5. Any additional meeting items
**\<fluffypony>** 6. Confirm next meeting date/time
**\<fluffypony>** so let's start with 1. Greetings (aka roll call)
**\<fluffypony>** hi
**\<johnalan>** hi
**\<vtnerd>** present
**\<sgp>** hello!
**\<fluffypony>** tewinget apologises, he'll be late
**\<ajs>** Sup
**\<endogenic>** o/
**\<rehrar>** Yo
**\<fluffypony>** hyc / luigi1111 / ArticMine / othe / smooth / anonimal / binaryFate / dEBRUYNE / dnaleor / gingeropolous / iDunk / IPGlider / Jaquee / jwinterm / kenshi84 / knaccc / luigi1112 / luigi1115 / NoodleDoodle / papalazzarou / pigeons / RedLion[m] / redlion
**\<Jaquee>** hhelo
**\<pigeons>** :)
**\<vtnerd>** also me
**\<Jaquee>** medusa
**\<fluffypony>** anyone I forgot
**\<iDunk>** o/
**\<vtnerd>** oh those are not present whoops
**\<fluffypony>** lol vtnerd
**\<fluffypony>** ok so
**\<fluffypony>** 2. Brief review of what's been completed since the previous meeting
**\<fluffypony>** merged a bunch PRs
**\<fluffypony>** kenshi84's GPG key changed
**\<fluffypony>** I've confirmed it via sidechannel
**\<fluffypony>** we have a new sweepbelow function in the CLI, which you may find useful
**\<fluffypony>** we also have a new heavier bias in output selection towards newer outputs
**\<fluffypony>** moneromooo can fill us in on that
**\<ArticMine>** Hi
**\<othe>** oi
**\<fluffypony>** smart mining is enabled in the GUI
**\<fluffypony>** as in the selection box
**\<moneromooo>** Hmm, I just twiddled the settings for the recent output selection, really. To match some data in the Miller et al paper.
**\<fluffypony>** which is pretty cool
**\<sgp>** indeed
**\<fluffypony>** also Jaquee has done some work on getting iOS back on track after it borked (visually)
**\<fluffypony>** well iOS / mobile
**\<fluffypony>** which brings us to
**\<fluffypony>** 3. Code + ticket discussion / Q & A
**\<Jaquee>** yes. and there's some new translations added to gui
**\<fluffypony>** we have a number of open PRs
**\<fluffypony>** when tewinget is off his bus he can update us on 0MQ
**\<fluffypony>** which I'd REALLY like to move forward with ASAP
**\<fluffypony>** it's been sitting in a holding pattern for ages
**\<fluffypony>** Snipa: also if you're around maybe you can update us on the testing on that ?
**\<moneromooo>** I'd like it to be optional, so it can be merged (and thus tested), without causing massive breakage if it does break.
**\<fluffypony>** afaik that was the case
**\<Jaquee>** sounds like a good idea
**\<fluffypony>** also disposable addresses is still hanging around - I think that's pending a review from one of the luigis?
**\<moneromooo>** AFAIK yes. Also RandomRun had an idea to make it better.
**\<fluffypony>** I don't think there's a problem with that hanging around and being improved
**\<fluffypony>** as long as the parallel MRL write-up is there
**\<fluffypony>** I'd like to discuss 1998
**\<fluffypony>** the PR, not the year
**\<fluffypony>** https://github.com/monero-project/monero/pull/1998
**\<fluffypony>** at this point in time I'm still swaying towards prevent-user-stupidity-by-default
**\<fluffypony>** at the slight inconvenience for a power user / sysadmin who might go "omg really" and then add the flag
**\<fluffypony>** I know vtnerd feels the same way, which is why he added it in the first place
**\<fluffypony>** I'd be interested in strong arguments for removing the flag
**\<Jaquee>** wouldnt a text disclaimer be enough?
**\<Jaquee>** i don't have a strong opinion
**\<fluffypony>** Jaquee: if you try bind externally and start it without the --confirm-external-bind flag then it refuses to start
**\<fluffypony>** and it tells you why
**\<Jaquee>** ok. apparently hyc started the discussion. Are you around?
**\<fluffypony>** I know hyc doesn't like it
**\<fluffypony>** vtnerd: has anyone else expressed disdain for it?
**\<vtnerd>** AFAIK, just the people on that PR and the one referenced
**\<vtnerd>** and possibly one person in IRC, but they seemed to be questioning why it was necessary (I think)
**\<vtnerd>** its somewhat low effort to get around it, so most people just add the flag I thnk
**\<vtnerd>** no one has privately contacted me about it for any reason if that was the question
**\<fluffypony>** ok
**\<fluffypony>** unless hyc comes in I move to close the PR, we can always re-open it later
**\<Jaquee>** ok with me
**\<fluffypony>** ok next PR for discussion is 2011
**\<fluffypony>** moneromooo had concerns that it was touching consensus critical issues
**\<fluffypony>** so/issues/part of the code
**\<moneromooo>** Yes, but it turns out it's actually bypassed when a tx comes from a block. The patch is fine.
**\<moneromooo>** I OK'd it since.
**\<fluffypony>** ah ok'
**\<moneromooo>** Well, wait.
**\* fluffypony** stops...hammer time
**\<moneromooo>** It's really uneeded (only the wallet bit was wanted). But it's not forkworthy. That said...
**\<moneromooo>** Older wallets *might* create txes which aren't relayed by newer daemons.
**\<moneromooo>** That's fairly unlikely, since my code targets 2/3 of max size, but the size approximation is not very precise.
**\<moneromooo>** That said, I think it's fine to merge.
**\<hyc>** hey. just popped in. reading history
**\<fluffypony>** hi hyc !
**\<dEBRUYNE>** Re: 2011, perhaps it also should be dependent on the fee priority level used
**\* fluffypony** plays elevator hold music
**\<hyc>** ok, if n0b0dy else cares about that external bind thing then whatever. to me it's redundant
**\<fluffypony>** ok
**\<hyc>** since you had to explicitly request a non-localhost address already
**\<fluffypony>** sure, but you'd be surprised how few people know that 0.0.0.0 exposes everything :-P
**\<endogenic>** ^
**\<hyc>** it d0esn't protect against typos/accidents. it only pisses off people who expect the computer to do as it's told
**\<fluffypony>** hyc: view it like a weak password warning
**\<fluffypony>** you can't just expect the computer to accept 1234 as a password
**\<hyc>** yeah, ok...
**\<moneromooo>** Well, I would...
**\<fluffypony>** lol
**\<fluffypony>** moneromooo is the exception to every rule :-P
**\<fluffypony>** now on the GUI side, the only thing I wanted to bounce around is 688
**\<fluffypony>** tooltips are fine, but if we're going to do some sort of unified help then I would veer towards an overlay that shows once the first time you enter a screen, and can be re-called by clicking the [?] button on the taskbar
**\<fluffypony>** https://s-media-cache-ak0.pinimg.com/originals/c1/e1/bf/c1e1bfd7fb2770f6745d95af8bf89865.jpg
**\<johnalan>** like that style
**\<fluffypony>** https://s-media-cache-ak0.pinimg.com/originals/43/6e/74/436e746b35142f41d5f9bb8e765963e4.jpg
**\<fluffypony>** http://eyeviewportal.com/filecache/b38/73d/85-cropped-w545-h409-of-1-FFFFFF-evappguiguidecontentimage002.jpg
**\<fluffypony>** like that
**\<hyc>** sounds good
**\<johnalan>** :+1:
**\<Jaquee>** problem is [?] is not around if you use native title bar
**\<fluffypony>** Jaquee: where else could we add a help button? bottom left?
**\<endogenic>** one suggestion i'd make for that is to make it c lear to the user they can recall it easily by doing "X" so that they don't fret about having to memorize everything before it's closed
**\<endogenic>** recall it -> the help screen
**\<Jaquee>** i think ^ is good as a start
**\<moneromooo>** Where is it on the title bar then, since it's not a WM thing ?
**\<fluffypony>** endogenic: agreed
**\<moneromooo>** s/Where/Why/
**\<Jaquee>** but some buttons could need longer desriptions
**\<Jaquee>** like sweepunmixable and paymentid for example
**\<fluffypony>** Jaquee: there's enough space in the help overlay, we can use a smaller font to explain them
**\<redlion>** how breadwallet on ios handles it when setting up is quite good
**\<fluffypony>** or move the help to somewhere where there's space
**\<fluffypony>** and use an arrow
**\<Jaquee>** yeah. we could find a place for that help button
**\<fluffypony>** ok - any other PRs that need discussion or can we move on? there's general Q&A shortly
**\<sgp>** I'd like to merge 261 on monero-site
**\<fluffypony>** sgp: there's a website meeting after the Kovri one
**\<fluffypony>** so we can discuss it then
**\<sgp>** ok
**\<fluffypony>** ok so
**\<fluffypony>** 4. MyMonero-in-tree discussion
**\<fluffypony>** so basically this is about nose-covering and making sure I'm not abusing my position as a maintainer and member of the Monero Core Team
**\<fluffypony>** currently MyMonero has a working API (largely unspecced to be sure), two client implementations (website and app), two server implementations (the live backend and OpenMonero), with a third one coming
**\<fluffypony>** I'd like to make sure there is general acceptance and buy-in that the API can be implemented as the general API for lightweight wallets (ie. wallet that use remote viewkey scanning)
**\<hyc>** is it carved in stone now
**\<hyc>** if we need to tweak it we can still do that?
**\<redlion>** is the license unrestricted?
**\<fluffypony>** and that MyMonero-written or MyMonero-derived code is generally acceptable to be merged into the source tree (ie. the open-source backend implementation that vtnerd is working on)
**\<fluffypony>** redlion: BSD 3-clause
**\<fluffypony>** hyc: as long as mWo12 changes it, and we match the changes in the live backend and the new backend then yse
**\<fluffypony>** yes
**\<fluffypony>** we can make any changes, and we WILL make changes to make it smarter
**\<moneromooo>** If it's beneficial to monero and it works fully by itself without needing proprietary gunk, then I'm OK with it.
**\<fluffypony>** eg. tx history comes in raw, instead of paginated
**\<fluffypony>** so that needs to change
**\<hyc>** +1 moneromooo
**\<fluffypony>** moneromooo: yeah the new backend will use LMDB instead of mysql
**\<fluffypony>** so it will be unencumbered in the source
**\<ArticMine>** As long as there are no proprietary dependencies I am fine
**\<hyc>** I like it even more now ;)
**\<johnalan>** I think it beneficial too
**\<moneromooo>** Maybe a separate repo (similar to monero-core) might be best, but that's details.
**\<johnalan>** \*its
**\<moneromooo>** it's
**\<iDunk>** it's
**\<jollymort>** can't wait to run a mymonero node myself!
**\<vtnerd>** also the current "primary" wrapper around the DB is actually C, so theres that for you guys
**\<fluffypony>** moneromooo: I thought about that, but it's a single daemon that *should* exist in the repo alongside the wallet RPC etc.
**\<hyc>** doesn't it supersede wallet-rpc?
**\<fluffypony>** now
**\<fluffypony>** hyc: no
**\<fluffypony>** wallet-rpc is good for integration, this isn't
**\<johnalan>** there is obviously an element of centralisation, but it’s nearly impossible to avoid
**\<fluffypony>** also on this topic
**\<fluffypony>** Jaquee has begun working on client integration in the CLI and GUI
**\<moneromooo>** "client integration" ?
**\<vtnerd>** you mean for light-wallets?
**\<fluffypony>** that will mean that both CLI and GUI will be able to run in lightweight / remote-scanner / MyMonero mode
**\<fluffypony>** moneromooo: as opposed to implementing the server protocol
**\<hyc>** sounds good
**\<moneromooo>** Oh, mymonero client integration ?
**\<fluffypony>** moneromooo: let's call it something else
**\<moneromooo>** That went pretty damn fast :D
**\<fluffypony>** "lightweight wallet"
**\<jollymort>** it's not really centralization if any `monerod` acts as a server
**\<hyc>** but I'm still missing why we need old wallet-rpc if this mymonero api exists
**\<jollymort>** it's literally my monero :)
**\<fluffypony>** hyc: wallet-rpc is completely different
**\<johnalan>** so the core GUI will be able to interact with MyMonero backend too?
**\<vtnerd>** for people that want to run VPS node but keep their viewkey ?
**\<moneromooo>** Yes, would be nice to see what bits are needed where, and the actual API (even if roughly).
**\<fluffypony>** it provides an API for integrators
**\<fluffypony>** @johnalan yes
**\<fluffypony>** so basically
**\<johnalan>** is this needed with the MyMonero Desktop wallet?
**\<ArticMine>** With what as the backed / server
**\<moneromooo>** That can be posted later though, :49 now.
**\<ArticMine>** monerod?
**\<fluffypony>** lightweight wallets will have 3 server options:
**\<fluffypony>** 1. OpenMonero
**\<fluffypony>** 2. the new in-source backend that vtnerd is working on
**\<fluffypony>** 3. the live MyMonero backend
**\<fluffypony>** it will also have multiple client options:
**\<hyc>** afaik the main difference btw an ordinary wallet and mymomero is you tell mymonero your viewkey
**\<fluffypony>** 1. OpenMonero's web wallet (clone of the current MyMonero web wallet)
**\<hyc>** and the ordinary wallet has all your keys
**\<fluffypony>** 2. the MyMonero applications
**\<fluffypony>** 3. monero-wallet-cli
**\<fluffypony>** 4. monero-wallet-rpc
**\<fluffypony>** 5. the Monero GUI
**\<fluffypony>** hyc: monero-wallet-rpc can still use this on the backend
**\<fluffypony>** so it's unrelated
**\<hyc>** ok
**\<ArticMine>** ok
**\<jollymort>** about #2011 - you could modify it to (median)+0.6% for it to be mine-worthy, or even have the wallet check for fee setting and then it would be matched like 1: +0.6%, 2: +2.4%, 3: +12%, 4:+100%
**\<fluffypony>** also this will mean that the GUI / CLI may end up supporting the MyMonero 13-word seed derivation by virtue of the integration effort
**\<fluffypony>** does anyone have a fundamental issue with that ?
**\<ArticMine>** no
**\<fluffypony>** I mean, I do, because I don't want to be abusing my position, but it is what it is :-P
**\<jollymort>** didn't you deprecate 13-word?
**\<moneromooo>** Did you not say the 13 word seed was going to be obsoleted ?
**\<endogenic>** jollymort: working on it
**\<johnalan>** no
**\<endogenic>** but client still needs to be able to read 'em
**\<redlion>** electrum/mycelium support a few different seed lengths iirc
**\<redlion>** works well
**\<jollymort>** also luigi was playing around with an idea for 17-word, integrating creation height in it etc
**\<fluffypony>** moneromooo: it's import only
**\<fluffypony>** not create
**\<endogenic>** https://github.com/mymonero/mymonero-app-js/issues/77
**\<knaccc>** doesn't it put a huge load on mymonero when someone asks it to scan the blockchain from zero with their view key? How long does mymonero take to scan the entire blockchain?
**\<moneromooo>** Anyway, I'm fine with that as presented.
**\<hyc>** that all sounds like a win to me. people have been whining about not being able to import their 13-word seed into regular CLI wallet
**\<shuannelson>** so monero-wallet-cli/monero GUI will not be able to create light-wallets?
**\<fluffypony>** knaccc: yes it does - about 10 minutes
**\<jollymort>** yeah import only sounds lovely
**\<ArticMine>** If we are setting the stage for a competitive market based upon FLOSS then I am fine with it
**\<vtnerd>** I do have the ASM code working, so hopefully that will tighten up some too (altough there is something else blocking that)
**\<fluffypony>** shuannelson: yes they will
**\<fluffypony>** but with 25 word seed, not 13
**\<fluffypony>** we have 7 minutes left - so I'd like to move on to the last item
**\<shuannelson>** awesome!
**\<fluffypony>** we can discuss MyMonero more after the meeting
**\<redlion>** @shaunnelson, I think it's just that the CLI/GUI won't create 13-word seeds, but will accept already created ones
**\<hyc>** yeah sounds fine
**\<fluffypony>** 5. Any additional meeting items
**\<knaccc>** 10 mins is quite a speedup vs downloading the entire blockchain, so sounds awesome.
**\<jollymort>** any thoughts on future of penalty/blocksize? i kind of left the research open-ended
**\<hyc>** ^^ get a faster CPU and it'll be quicker ')
**\<redlion>** Does anyone have a working monero-core or mymonero build on ios currently? I've been fiddling around and I can't seem to get either properly functional on the sim/device, though I may be missing something
**\<fluffypony>** lol hyc
**\<endogenic>** redlion: pls come join #mymonero but yes i do :)
**\<Jaquee>** redlion: i have. it has some nasty bugs but it's running
**\<redlion>** ok thanks, I'll talk to you after this
**\<hyc>** btw iOS still limits process VM size to 4GB so we won't be running monerod native on iOS any time soon
**\<fluffypony>** @jollymort let's discuss it after the meeting, or maybe next week - there are 2 more meetings to go tonight :)
**\<fluffypony>** and that's a large topic
**\<jollymort>** sure, another time
**\<redlion>** thanks jaquee, are there any build instructions or a (sort of) working build posted somewhere?
**\<fluffypony>** 6. Confirm next meeting date/time
**\<fluffypony>** May 21
**\<fluffypony>** day before Consensus
**\<hyc>** cool
**\<hyc>** oh. this week I expect to have wolf miner fully ported to Android, with GPU support too
**\<fluffypony>** endogenic can come to my hotel and we can do the meeting together :-P
**\<endogenic>** oooh
**\<tewinget>** anyway, I have the daemon's side of the code rebased and *nearly* ready to PR and merge. I mean, it could be merged now, but I should clean it up a little/address a few more of the comments on the existing PR first.
**\<tewinget>** the wallet side of things will be based on that, and won't take too long. I just thought it made sense to separate it into two PRs (and rebase while I'm at it because why not?)
**\<fluffypony>** suweet
**\<fluffypony>** just check the meeting logs for the bit from moneromooo about it
**\<tewinget>** (the wallet stuff is still "done already", but as with the daemon side there are comments/suggestions to address as I rebase it as well.)
**\<tewinget>** at any rate, I plan today to finish with the cleanup of the daemon side of things, close the existing PR, and open a new one for the daemon that should be mergeable.
**\<fluffypony>** great stuff
**\<fluffypony>** pigeons: did you see the 96boards thing?
**\<tewinget>** fluffypony: sorry I didn't respond right away to your pinging on the github PR, but when I said it was already rebased I meant on a different branch, as I'm leaving that branch up (and separate) until I finish rebasing.
**\<fluffypony>** ok cool
**\<moneromooo>** tewinget: is the 0MQ stuff deselectable if needed (so if it somehow breaks, you can run the wallet with the existing JSON comms) ?
**\<moneromooo>** wallet/daemon
**\<tewinget>** moneromooo: I'll make it so when I rebase the wallet side of things.
**\<moneromooo>** Excellent, thank you :)

49
_posts/2017-05-17-disclosure-of-a-major-bug-in-cryptonote-based-currencies.md Normal file
View file

@ -0,0 +1,49 @@
---
layout: post
title: Disclosure of a Major Bug in CryptoNote Based Currencies
summary: Patched in Monero and others, but still in the wild
tags: [core, crypto, research]
author: luigi1111 and Riccardo "fluffypony" Spagni
---
# Overview
In Monero we've discovered and patched a critical bug that affects all CryptoNote-based cryptocurrencies, and allows for the creation of an unlimited number of coins in a way that is undetectable to an observer unless they know about the fatal flaw and can search for it.
We patched it quite some time ago, and confirmed that the Monero blockchain had NEVER been exploited using this, but until the hard fork that we had a few weeks ago we were unsure as to whether or not the entire network had updated.
Once we were certain that the network had updated, we notified all active and affected CryptoNote coins, including CryptoNote themselves, Bytecoin, Forknote, Boolberry, DashCoin, and DigitalNote.
***Note that, at this time, only Monero, Aeon, Boolberry, and Forknote have updated.*** We have given the other currencies as much time as possible, but cannot hold back disclosure any longer.
***We strongly caution against anyone using, trading, exchanging, or running services involving the following currencies affected by this issue: Bytecoin, DashCoin, DigitalNote***
# Timeline
2017-02-19: A member of the Monero Research Lab discovers the exploit, triggered by a detailed discussion of the [XEdDSA signature schemes](https://whispersystems.org/docs/specifications/xeddsa/) on the [Curves mailing list](https://moderncrypto.org/mail-archive/curves/2017/000846.html)
2017-02-20: The Monero blockchain is scanned to see if this had ever been exploited; thankfully it had not and the blockchain is intact.
2017-02-21: The patch is surreptitiously snuck into the Monero codebase in [pull request #1744](https://github.com/monero-project/monero/pull/1744). It is kept secret to prevent it being used to attack other CryptoNote coins.
2017-02-22: A [point release of Monero is rushed out](https://github.com/monero-project/monero/releases/tag/v0.10.2) so that exchanges and mining pools can update, under the guise of it preventing a RingCT DoS attack (such attack did not exist, but it seemed a fair explanation).
2017-03-15: The hash of the details of the problem is committed to the Monero blockchain in tx dff7a79e44f9392e19fe5205c389d3e799f89c62d90d624219618d754b806e04
2017-03-26: A further [point release of Monero](https://github.com/monero-project/monero/releases/tag/v0.10.3.1) is put out to prepare for a hard fork in April.
2017-04-14: The Monero network hard forks to increase the dynamic block size minimum median, but this has the added bonus of ensuring the entire network is protected.
2017-04-17: All CryptoNote coins are contacted, and told that they have until mid-May to patch their coins, before there will be a public disclosure of the issue.
2017-04-17: As noted by [Riccardo "fluffypony" Spagni on Twitter](https://twitter.com/fluffyponyza/status/854029169667309569), the hash of the message sent to the various CryptoNote currencies is committed to the Monero blockchain.
# Problem
The so-called "key image" as used in CryptoNote coins utilising elliptic curve ed25519 can be modified in a special way, allowing double-spends. This effectively allows someone to create an infinite amount of coins in a way that is impossible to detect without knowing about the exploit and explicitly writing code to check for it.
# Mitigation
Several options exist for mitigation. The simplest, least invasive is noted below.
To mitigate, check key images for correctness by multiplying by the curve order l. Check that the result is the identity element.
Hexadecimal values of each:
Identity element = "0100000000000000000000000000000000000000000000000000000000000000"
Curve order (little endian) = "edd3f55c1a631258d69cf7a2def9de1400000000000000000000000000000010"
For each transaction key image, check ((key image * curve order) == (identity element)); reject transaction if false.

BIN
blog/assets/linkability-response/cointelegraph.jpg Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 60 KiB

BIN
blog/assets/linkability-response/figure5.jpg Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 96 KiB

BIN
blog/assets/linkability-response/table2.jpg Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 257 KiB

BIN
blog/assets/linkability-response/table3.jpg Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 271 KiB

BIN
blog/assets/linkability-response/tweet.jpg Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 193 KiB

2
knowledge-base/moneropedia/block.md
View file

@ -7,7 +7,7 @@ summary: "a container of transactions, a sequence of which forms a blockchain"
### The Basics
A block is a container of @transactions, with a new block being added to the @blockchain once every 60 seconds, on average.
A block is a container of @transactions, with a new block being added to the @blockchain once every 2 minutes (see constant `DIFFICULTY_TARGET_V2` defined as 120 seconds), on average.
Blocks also contain a special type of transaction, the @coinbase-transaction, which add newly created Monero to the network.