2017-02-19-overview-and-logs-for-the-dev-meeting-held-on-2017-02-19.md 13.6 KB
Newer Older
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204
---
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
---

*February 19th, 2017*  

# 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