--- layout: post title: Overview and Logs for the Dev Meeting Held on 2017-02-19 summary: 0MQ, 10.2 release, and background mining tags: [dev diaries, core, crypto, 0mq] author: dEBRUYNE / fluffypony --- ### 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. Any additional meeting items **\<fluffypony>** 5. Confirm next meeting date/time **\<hyc>** hola **\<fluffypony>** so greetings **\<fluffypony>** hi! **\<ArticMine>** hi **\<tewinget>** (here) **\<vtnerd>** also present **\<moneromooo>** hi **\<tewinget>** I'll be sorta afk for the next 5ish minutes, but I'm around. **\<fluffypony>** ok **\<fluffypony>** 2. Brief review of what's been completed since the previous meeting **\<fluffypony>** so **\<fluffypony>** second meeting of the year **\<fluffypony>** and we've been pushing ahead solidly **\<fluffypony>** we've had a bunch of PRs by newcomers **\<jollymort>** once you go solid state you never go back **\<fluffypony>** including tpltnt, and IPGlider has also pushed a few PRs **\<fluffypony>** we switched to EasyLogging++, which is a pretty big change **\<fluffypony>** and MoroccanMalinois made Android builds happen **\<fluffypony>** tdprime also pushed their first PR **\<fluffypony>** and then the usual rash of PRs from moneromooo, vtnerd, hyc, NanoAkron, and Jaquee **\<fluffypony>** (I've probably missed someone) **\<pigeons>** reveler with the background mining **\<hyc>** revler **\<fluffypony>** yes thanks pigeons **\<fluffypony>** oh and pigeons had a PR too **\<jollymort>** kenshi84 disposable addresses **\<fluffypony>** and kenshi84 **\<fluffypony>** ok - anything else major I missed that happened in the last two weeks before we move on to 3? **\<moneromooo>** All the new one time address stuff from knaccc, randomrun, kenshi, jollymort. **\<knaccc>** yes subaddresses are back! **\<moneromooo>** And luigi. **\<fluffypony>** moneromooo: I was going to get to that in 3 **\<hyc>** ok, sounds like we move on to 3 **\<fluffypony>** since it's in the MRL repo **\<fluffypony>** 3. Code + ticket discussion / Q & A **\<jollymort>** I wasn't following that discussion, focused on study on fees atm **\<fluffypony>** ok so there have been a few long-form discussions going on in various issues **\<jollymort>** also the one for ring size **\<fluffypony>** yeah the ring size one is one I wanted to bring up **\<fluffypony>** I think the discussion has mostly been positive, nobody's gotten crazy out-of-hand or anything **\<fluffypony>** it *is* a complex topic **\<fluffypony>** and I think that we have enough time to figure out a good route forward **\<fluffypony>** does anyone have an objection to it continuing in the GitHub issue? **\<hyc>** seems like all the context is there **\<hyc>** so it should continue there **\<jollymort>** I feel like it's more suitable for an issue under MRL, any thoughts of moving it there (if possible)? **\<jwinterm>** I haven't been following the issue too closely, but is there still some sentiment building around fixing ring size for all txs? **\<fluffypony>** jollymort: I think the GH issue is fine, it can kinda be anywhere, but if we're going to turn that into a publication that explores the various options and reasons for recommendations then it would develop as PRs to the research-lab repo **\* jwinterm** goes to github **\<jollymort>** I meant, keep it as a GH issue, but under another repo so it doesn't get buried under all code/bug related issues **\<jwinterm>** as someone not following the issue, it does kind of get lost in the noise with 164 open issues **\<jwinterm>** #1673? **\<fluffypony>** yeah it would be nice if GH let you subscribe to just a single issue **\<fluffypony>** I'm not opposed to moving it to the research-lab repo **\<fluffypony>** how would we do that tho **\<hyc>** no idea **\<pero>** someone creates a synopsis of where the discussion is at currently in the new ticket and links back to older ticket **\<hyc>** yeah, new text **\<hyc>** with @mentions of original participants **\<fluffypony>** ok I'll suggest it in the thread **\<fluffypony>** then on the topic of discussion **\<fluffypony>** I'd like to encourage us to also take some Q&A / discussion items to StackExchange where we can **\<fluffypony>** and to redirect people who open issues to just ask a question to StackExchange **\<hyc>** hm, I would expect that SE is for "settled" questions **\<fluffypony>** SE is a great place for canonical information that is updated over years **\<jollymort>** I'd just like to add that SE is not really a format for discussions, more for things with an actual answer existing **\<fluffypony>** hyc: nope, anyone can edit an accepted answer with new information **\<jollymort>** like hyc said **\<jollymort>** there's SE chat, though - which nobody uses **\<fluffypony>** jollymort: some of the questions on GitHub issues are perfect for SE **\<jollymort>** sure **\<fluffypony>** https://github.com/monero-project/monero/issues/1751 as an example **\<hyc>** monero clone? **\<fluffypony>** hyc: probably, I thought that too **\<fluffypony>** but that's a good question for SE **\<fluffypony>** which also has a larger group of answer-ers than the GH repo **\<taushet>** it is already answered though, sort of http://monero.stackexchange.com/questions/2886/how-can-i-create-a-new-monero-genesis-block **\<fluffypony>** taushet: yes but SE has tools to close as a duplicate and redirect them to the answer **\<fluffypony>** and moderators can do that without us needing to **\<taushet>** fluffypony - agreed. also the 'issue' was not so much an issue with the code as much as it was a question but a user/tinkerer who could not get something to work **\<taushet>** anyway **\<fluffypony>** yeah exactly **\<Slack> \<nanoakron>** What if someone went through and opened parallel SE questions for all those types of question, redirected the original asker, then we shut the issue? **\<hyc>** sounds good **\<fluffypony>** @NanoAkron yes that's exactly my recommendation **\<Slack> \<nanoakron>** Ok I might see what I can do if I get any free time tonight **\<fluffypony>** then you even get SE karma or points or rep or whatever it's called **\<Slack> \<nanoakron>** Woo! **\<fluffypony>** gamification ftw! **\<fluffypony>** ok anything else under Q&A ? **\<hyc>** specific tickets? **\<hyc>** like 0MQ PR? **\<fluffypony>** yep I believe tewinget said he had to check if it was working with RingCT **\<fluffypony>** tewinget: ^^ **\<Slack> \<nanoakron>** Any thoughts about 0.10.2? **\<fluffypony>** @NanoAkron yes **\<fluffypony>** we've been discussing it **\<fluffypony>** because it will coincide with beta 2 of the GUI **\<Slack> \<nanoakron>** Oh nice **\<fluffypony>** as we're marrying daemon / GUI versions **\<Slack> \<nanoakron>** Makes good sense. Will #1746 be addressed too? **\<jollymort>** do you intend to code in stuff for the next HF in 0.10.2? **\<Slack> \<nanoakron>** I.e. Auto starting daemon **\<fluffypony>** there are a few things that need to be done in the daemon / GUI before the next release **\<tewinget>** sry **\<fluffypony>** jollymort: no **\<fluffypony>** we only have to finalise that by like July **\<tewinget>** just got my second monitor back from a friend, was setting it up real quick. **\<jollymort>** ok, thanks **\<fluffypony>** @NanoAkron I don't see why we can't make sure 1746 is sorted, Jaquee any thoughts ? **\<tewinget>** so Snipa was kind enough to chuck a battery of tests at my zmq branch, which is great. It seems there are a couple things I need to look at, which is expected, but his tests seem rather comprehensive, so once those are passing it should be good to go. **\<moneromooo>** Does this keep a backward compat layr for the current JSON API ? **\<tewinget>** moneromooo: currently it neither replaces nor modifies any current RPCs **\<Slack> \<nanoakron>** Esp since the number of rpc commands has increased **\<fluffypony>** moneromooo: long term yes - the current JSON API will be in its own binary, like monero-rpc-server, and that will use 0MQ to communicate with the daemon **\<tewinget>** but also short-term yes because I haven't done anything to the existing RPCs **\<Slack> \<nanoakron>** I heard it would be passing plaintext commands/JSON and not binary. Or am I mistaken? **\<tewinget>** nanoakron: that is correct, everything is marshalled via json **\<tewinget>** this is so that higher-level languages have no problem using the RPC **\<pigeons>** or jaxx :P **\<tewinget>** as the (de)serialization takes no time at all compared to the computations/fetching **\<tewinget>** pigeons: hope springs eternal **\<hyc>** this is for wallet-style client RPCs only then **\<Slack> \<nanoakron>** Doesn't that mean that there are now two sets of commands to maintain in sync - JSON-RPC (won't be deprecated) and JSON-over-ZMQ? **\<fluffypony>** JSON-RPC *will* be deprecated for the daemon **\<fluffypony>** we won't add new RPC commands to it **\<fluffypony>** JSON RPC for the wallet will continue to evolve and exist **\<fluffypony>** because web apps rely on it **\<fluffypony>** communication with the daemon will be relegated to 0MQ only **\<moneromooo>** !bookie no-json-rpc-added-ever-again yes no **\<Slack> \<nanoakron>** But in JSON format **\<moneromooo>** aw... **\<fluffypony>** (eventually) **\<fluffypony>** @NanoAkron yes **\<fluffypony>** so existing apps that interact with the daemon, eg. pool software, can continue by adding a 0MQ library **\<fluffypony>** and modifying any calls that have changed **\<tewinget>** (which won't be many, there were just a few that seemed silly in some ways, and changed accordingly, but none of that is set in stone) **\<fluffypony>** anything else? **\<fluffypony>** or I guess we can include that in the next item on the agenda **\<fluffypony>** 4. Any additional meeting items **\<Slack> \<nanoakron>** Neigh **\<fluffypony>** lol **\<fluffypony>** we should use HAY and NEIGH instead of ACK and NACK **\<Slack> \<nanoakron>** Lol **\<tewinget>** I'll keep updating over the next couple days, fwiw. Gotta get with Snipa to see if he can make a couple of modifications to the tests for me to make issues track-down-able, but he's afk until tomorrow. **\<moneromooo>** Hmm, range sig reduction... multisig... fee formula change... **\<Slack> \<nanoakron>** Yes **\<pigeons>** Snipa: are these tests in your github? **\<fluffypony>** oh I have an item for brief discussion **\<jollymort>** it's not just the fee, penalty needs tweaking **\<fluffypony>** as everyone knows, the dynamic block adjuster isn't adjusting very well since the txs became larger **\<pero>** snipa is afk until tmrw iirc **\<jollymort>** either by increasing the min. blocksize, or having a transition formula **\<fluffypony>** does everyone think we should leave it as-is until September, with the occasional backlog **\<fluffypony>** or should we have some intermediary hard fork ? **\<ArticMine>** We may need one **\<hyc>** If we have a fix now, would be nice to deplot it sooner **\<hyc>** deploy **\<Slack> \<nanoakron>** But it has to be smart enough to account for potential future changes in range proof and therefore Tx size **\<jollymort>** it accounts :) **\<pero>** september is a long time away **\<Slack> \<nanoakron>** As well as ring size. Txes will become much more standardised in size and non-parametrically distributed **\<fluffypony>** ok I think that's reasonable consensus, as soon as we have something workable we'll put it out to the community as a hard fork and see how they feel **\<Slack> \<nanoakron>** So medians etc may not make statistical sense **\<DaveyJones>** you could HF at around the time when originally the ringct hf was supposed to happen **\<ArticMine>** nanoakron We are looking at a fall in tx size? **\<Slack> \<nanoakron>** Hopefully. Size would fall will range proof improvements, but distribution of sizes would flatten with ring size standardisation. Parametric statistics would no longer apply. **\<fluffypony>** DaveyJones: that's in March, too soon for a planned fork **\<Slack> \<nanoakron>** So adjusting based on moving medians would be meaningless. We'd need to deploy alternate statistical tests. **\<moneromooo>** Can you explain that ? **\<fluffypony>** ok **\<fluffypony>** anything else before we close the meeting ? **\<fluffypony>** (we can discuss specifics after the meeting) **\<Slack> \<nanoakron>** Even now with a mix of rct and non-rct transactions the median is meaningless because the size distribution is non parametric **\<jollymort>** it's some typical size which is most important, currently at 13kB **\<hyc>** calculate two separate medians. one for rct and one for non-rct. **\<jollymort>** doesn't matter if it's +/- 1kB **\<Slack> \<nanoakron>** It's instead bimodal **\<hyc>** sounds like we're done with the meeting side of things then **\<jollymort>** I mean, if you roll out some change to TX format, you already know the next typical size it will cause **\<fluffypony>** last item is the next meeting time **\<jollymort>** and you will need to HF anyway, so all you'd need to do is adjust one parameter for the dynamic blocksize/fee **\<fluffypony>** 2 weeks from now **\<fluffypony>** March 5th **\<hyc>** cool **\<fluffypony>** I will be on a plane to London, but should have wifi and should be able to attend the meeting **\<fluffypony>** thanks guys