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