2016-06-19-overview-and-logs-for-the-dev-meeting-held-on-2016-06-19.md 16.5 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 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-06-19
summary: C4, open PRs, and brief update on Ring CT and 0MQ
tags: [dev diaries, core, crypto, 0mq]
author: dEBRUYNE / fluffypony
---

*June 19th, 2016*

# Overview (by Aerbax)

An overview [can be found on Hello Monero](https://hellomonero.com/article/monero-bi-weekly-dev-meeting-note-highlights-2016-06-19)

# Logs

**\<fluffypony>** ok
**\<fluffypony>** hello and welcome
**\<tewinget>** ack
**\<wallet42>** Sup fluffypony
**\<fluffypony>** so first things first
**\<meeting-bot>** [anonimal] EinMByte: ^ Monero meeting now, Kovri in about an hour or so (just FYI)
**\<fluffypony>** after the last meeting, which was mostly focused on C4, we bounced some of that around
**\<fluffypony>** I think the spirit of C4 is good, and will help keep Monero inclusionary towards new contributors
**\<fluffypony>** but moneromooo in particular disagreed with some of the specifics
**\<fluffypony>** or where C4 is a little vague
**\<fluffypony>** so what we're going to do is fork C4 from Unprotocols / yrashk into the Monero repo
**\<meeting-bot>** [psi] c4?
**\<fluffypony>** and we'll tweak it from there, keeping it in step with changes made upstream in Unprotocols
**\<fluffypony>** psi: the Collaborative Code Construction Contract, see last meeting's minutes for an intro and discussion
**\<meeting-bot>** [anonimal] Or Kovri's contributing guide.
**\<fluffypony>** yup
**\<fluffypony>** I think everyone is aware that this is security software we're dealing with
**\<fluffypony>** and we can't be crazy and accept things that may contain backdoors
**\<fluffypony>** but we also want some structure that makes contributors feel welcome, even if their contributions need some work and aren't up to a standard we'd like
**\<fluffypony>** somewhere inbetween being completely permissive and miring contributions in PR hell is a nice balance, and we'll figure it out
**\<ArticMine>** We need to balance security and making contributors welcome
**\<fluffypony>** yup exactly
**\<fluffypony>** ok so on to more fiddly code bits, less soft skills
**\<fluffypony>** I was hoping tewinget could update us on the 0MQ work, which is about to go up on the forum for funding
**\<tewinget>** ok
**\<moneromooo>** My point was not security, it was more about the crazy wish to keep obvious crap in.
**\<tewinget>** https://www.github.com/tewinget/bitmonero/tree/zmq-dev  **\<-- there's the branch, gimme one min to take care of something then I can brief
**\<fluffypony>** ok
**\* fluffypony plays hold music
**\* tewinget is typing
**\* DaveyJones just watches
**\<tewinget>** ok, so far I've got cryptonote::classes to/from json for a majority of what will need to be serialized for RPC.  I have a couple of RPC calls actually written and working via ZMQ (get_height get_transactions, and key_images_spent)
**\<tewinget>** that's more or less a summary of progress
**\<tewinget>** as far as process
**\<tewinget>** the idea is to try to create RPC as we want it to be, rather than trying to modify the existing structure, and then plug in backwards-compatibility later
**\<fluffypony>** tewinget: so using the structure that is / was on the Wikia ?
**\<meeting-bot>** [psi] to rehash, you are redoing monero's wire protocol to use zmq correct?
**\<fluffypony>** psi: no, not wire protocol, that will use ZMTP (a part of the 0MQ project) and come later
**\<tewinget>** psi: more or less, but a bit more than just that
**\<tewinget>** oh
**\<tewinget>** I mean, kinda wire, but not p2p yet
**\<tewinget>** rpc
**\<fluffypony>** this is redoing the communication between the node and "clients" like miners / mining pool software / wallets / etc.
**\<meeting-bot>** [psi] kk
**\<meeting-bot>** [psi] zmtp is still being drafted correct?
**\<fluffypony>** nope all done, afaik: http://zmtp.org
**\<tewinget>** \<fluffypony> tewinget: so using the structure that is / was on the Wikia ?  <-- well, yes, but also I was hoping to get some input today (not necessarily now) from anyone who would like to comment on the future of RPC
**\<fluffypony>** it's already on v3
**\<fluffypony>** ok so maybe one of the things we need to do now is move that design doc from the Wikia to the Github wiki
**\<fluffypony>** wallet42: are you up to doing that, or busy travelling atm ?
**\<tewinget>** I can say that the few commands I've done don't necessarily conform to any spec like json-rpc, but that's easy to change -- structure is currently placeholder while functionality is implemented
**\<tewinget>** oh, one important detail I left out
**\<tewinget>** I think it's best if the RPC is straight json.  This comes at a very, very minor cost in speed, but means that implementation in other languages will be far less intimidating for new contributors
**\<tewinget>** and I know I don't personally plan to write libMonero for every language out there...
**\<fluffypony>** oh I agree - the idea behind 0MQ is for a language to use 0MQ bindings and just be able to talk straight to the daemon
**\<tewinget>** yup, and this way for any language that has json and zmq bindings, all one needs to do is give the language a cursory understanding of cryptonote structs
**\<fluffypony>** if JSON is the way we want to do that that's fine, we can always modify it later to support Google's protobufs or something later on
**\<tewinget>** https://paste.fedoraproject.org/379294/14659488/  <-- there's an example of get_transactions
**\<tewinget>** it's also very nice to do ad-hoc testing via python :)
**\<fluffypony>** cool
**\<tewinget>** any thoughts, anyone?
**\<wallet42>** fluffypony: In about 3 weeks im back in Berlin, right now i only have like 1 day a week. But yes the wiki will get more data as I am moving myself trough the code
**\<wallet42>** Especially better wiki documentation of the datatypes/protocol
**\<wallet42>** wiki.bitcoin.it/wiki/Protocol basically
**\<fluffypony>** tewinget: how hard would it be to implement different schemes in future, like JSON / protobufs / ASN.1 BER ?
**\<fluffypony>** wallet42: ok cool, thank you
**\<tewinget>** fluffypony: wouldn't be too bad, I'm trying to make things pretty modular.  It wouldn't be too bad to make it a bit more generic than json
**\<tewinget>** it's already 90% ready for that as-is
**\<fluffypony>** kk
**\<fluffypony>** alright, tewinget anything else or can we move on to the next thing ?
**\<tewinget>** the ZMQ-side of things was pretty trivial tbh
**\<tewinget>** oh, anyone averse to having a separate listening port for publish/subscribe such as "new_block_notify" etc?
**\<fluffypony>** you mean a separate port for pub-sub than the IPC port ?
**\<tewinget>** well, there will be a port for "request thing from daemon"
**\<tewinget>** can't use the same port for publish/subscribe, I'm pretty sure
**\<fluffypony>** I don't see a problem with that
**\<tewinget>** without an unholy amount of added complexity that isn't worth at all
**\<fluffypony>** one thing you may want to do is also look at Bitcoin's 0MQ effort
**\<fluffypony>** I don't think wumpus is around at the moment
**\<fluffypony>** but they've been pecking away at 0MQ for some time
**\<moneromooo>** Isn't the point of 0MQ to abstract comms to allow things like that ?
**\<fluffypony>** moneromooo: pub-sub is a different beast to control / request
**\<tewinget>** 0MQ uses different socket types like Request-Reply, or Pub/Sub
**\<fluffypony>** normally for pub-sub you're sending a request once and then receiving "push" notifications forever
**\<tewinget>** and one socket can only be one type, and I don't think you can bind two sockets to the same port, as how would it route that?
**\<fluffypony>** Bitcoin has walletnotify and blocknotify that work in that way
**\<tewinget>** so using the same port for req-rep and pub-sub would require...well, no, just no
**\<fluffypony>** it would end up looking gross like the RPC stuff at the moment
**\<tewinget>** moreso, in fact
**\<fluffypony>** different HTTP paths for the JSON and HTTP RPCs
**\<tewinget>** \<fluffypony> alright, tewinget anything else or can we move on to the next thing ? <-- happy to give a few minutes for any comments from anyone, but other than that I think that's about it
**\<fluffypony>** cool if anything pops up over the rest of the meeting then we can see
**\<tewinget>** oh, and feel free to give feedback on the branch, I'll repaste the link in a sec.  Feedback here or via github is fine
**\<tewinget>** https://www.github.com/tewinget/bitmonero/tree/zmq-dev
**\<fluffypony>** ok next, moneromooo do you feel like giving an update on RingCT? looks like it's making nice headway :)
**\<moneromooo>** It kinda works. I'm fixing bugs now.
**\<fluffypony>** moneromooo: is it going to be a hard fork where all new transactions are v3 / ringCT, but they can spend pre-ringCT outs?
**\<moneromooo>** They
**\<fluffypony>** they = transactions
**\<othe>** coinbase will use non-ringct tho?
**\<fluffypony>** othe: yes afaik
**\<moneromooo>** They'll be v2 and can spend either pre rct outputs or rct ones.
**\<fluffypony>** moneromooo: ooooh, so a soft fork? :-P
**\<moneromooo>** Hmm. I haven't thought about the distinction tbh.
**\<moneromooo>** Theoretically, coinbase might not even need to be in the clear I think. Though it'd require some shen magic.
**\<fluffypony>** I think it'd be a hard fork, because old nodes won't understand rct outs
**\<fluffypony>** so we'd have to bump the block version anyway
**\<ArticMine>** But will non RingCT other than coninbase transactions be valid?
**\<moneromooo>** Oh they'd reject new txes, yes.
**\<yrashk>** fluffypony: I'm thinking of an unprotocol for describing diverged unprotocols
**\<yrashk>** So meta
**\<fluffypony>** moneromooo: ok then that's hard fork
**\<fluffypony>** lol yrashk
**\<yrashk>** But I'm actually serious
**\<yrashk>** :)
**\<fluffypony>** yrashk: what's that Unprotocol for creating protocols with consensus?
**\<tewinget>** ArticMine: I think post-fork that all non-coinbase tx will be ringCT, but I'm not sure.
**\<moneromooo>** ArticMine: if you mean "will non RingCT outputs other than coninbase transactions be valid?", then I'd choose no, but it could be made either way.
**\<yrashk>** fluffypony: COSS? There's nothing about consensus there
**\<fluffypony>** yrashk: yes that - but it's about creating new protocols as a group, right ?
**\<yrashk>** Kind of but very very lightweight
**\<fluffypony>** kk
**\<yrashk>** Which is a good thing generally
**\<CFP>** Greetings fellas
**\<fluffypony>** moneromooo: I tend to agree with you - coinbase txs is fine, but after that it should be rct only
**\<CFP>** Crazyflashpie stoping by to say hello
**\<yrashk>** fluffypony: are you interested to collaborate on the protocol divergence protocol? (PDP)
**\<fluffypony>** hi CFP
**\<CFP>** Looks like the # of nodes in China is climbing?
**\<fluffypony>** yrashk: let's chat after the meeting, definitely interested in discussing it, as it's relevant to us
**\<yrashk>** I can explain my motivations behind it
**\<yrashk>** Today?
**\<yrashk>** Ping me on telegram or here when ready
**\<fluffypony>** kk
**\<fluffypony>** ok next I just wanted to bounce through some open PRs
**\<fluffypony>** #818 is still open pending luigi1111w / luigi1112 coming up with those spec changes, no rush there
**\<ArticMine>** moneromooo I would expect non RingCT outputs other than coinbase to be invalid after a given block
**\<fluffypony>** #775 is ready to be merged - moneromooo, just to double check, you're fine with that, right ?
**\<ArticMine>** With the 6 month upgrade cycle built in
**\<fluffypony>** ArticMine: agreed
**\<luigi1112>** Yes I'll try to do that this week
**\<moneromooo>** Yes. It's a wee bit spammier now in the logs, but other than that it's good to go.
**\<fluffypony>** ok then #810, the caching thing, I'm still confused as to whether we must merge or not
**\<moneromooo>** Not sure. I think enough said no.
**\<fluffypony>** ok I'll close it, we can reopen later
**\<moneromooo>** But then nobody patched the pool code :)
**\<fluffypony>** and pools can manually pull that in if they need
**\<fluffypony>** then the gcc 6.1 stuff - as I understand it there are more changes than what is covered in those two PRs
**\<fluffypony>** so do we close the PRs and just note that "gcc 6.1 not supported yet"
**\<meeting-bot> [anonimal]** Noooooooo.........
**\<fluffypony>** or do we merge them in preparation for supporting 6.1 ?
**\<meeting-bot> [anonimal]** Please nooooooo....
**\<fluffypony>** lol anonimal
**\<moneromooo>** If they'll be needed anyway...
**\<meeting-bot> [anonimal]** This also re: #846?
**\<moneromooo>** One of them is a superset of the other IIRC.
**\<fluffypony>** anonimal: yeah, 846 and 845
**\<meeting-bot> [anonimal]** radfish's work builds, so is the problem more eyes/more time to review?
**\<fluffypony>** anonimal: it was more that I was travelling, so I don't really know which is the superset of which, and which to close / merge / bail out of entirely :-P
**\<meeting-bot> [anonimal]** Oh, well I can spend some time this week giving input if that helps.
**\<moneromooo>** 846 seems to be the superset.
**\<tewinget>** PR X is a superset of PR Y seems like an odd situation to be in...
**\<tewinget>** especially if both are open
**\<fluffypony>** tewinget: quite
**\<neosilky_>** I had to merge them to get the repo to compile as GCC 6.1 is default for Arch
**\<fluffypony>** kk
**\<meeting-bot> [anonimal]** re: that ^, I only merged #846 and builds fine.
**\<meeting-bot> [anonimal]** I see the issue of both PR's being open, I can comment further this week after looking at them if they are still open by then.
**\<neosilky_>** Yep, only needed #846. @tewinget should enable testing repo too :)
**\<fluffypony>** ok then I'll close 845 and merge 846
**\<meeting-bot> [anonimal]** Ok.
**\<fluffypony>** then #856 I've reviewed and will merge
**\<fluffypony>** #855 seems fine to me, I defer to hyc's knowledge of his own product ;)
**\<fluffypony>** #863 seems fine too
**\<fluffypony>** #862 - luigi1112 can I take your comment as a review?
**\<moneromooo>** Oh. Let me change it now...
**\<gingeropolous>** tewinget, i may try and put this in a comment on the https://www.github.com/tewinget/bitmonero/tree/zmq-dev , but is this the space wherein the daemon could have multiple rpc ports with different characteristics?
**\<luigi1112>** I think it's fine yeah
**\<moneromooo>** pushed
**\<fluffypony>** k
**\<meeting-bot> [anonimal]** Has there been any definitive decisions re: C4 since previous meeting? I know there are differing arguments.
**\<fluffypony>** anonimal - yes, my comments at the beginning of the meeting, will let you know when the log is up if you missed them
**\<tewinget>** gingeropolous: not entirely sure what you mean to ask there
**\<meeting-bot> [anonimal]** "we'll figure it out" <-- was that it?
**\<gingeropolous>** i.e., port 18081 would be full access, and 18082 could be less access.
**\<fluffypony>** anonimal: yes basically the next step is fork ->** adjust accordingly ->** decide to abandon or adopt the iteration
**\<gingeropolous>** right now if you want different permissions for remote access to the daemon, you need multiple daemons and multiple databases
**\<othe>** isnt an auth system with permissons better for this
**\<fluffypony>** gingeropolous: I'm of a mind that we need a finer distinction than "trusted daemon" and "not trusted"
**\<fluffypony>** we need a proper ACL
**\<fluffypony>** what othe said
**\<fluffypony>** so shelve it as a thing to do later on
**\<gingeropolous>** word
**\<fluffypony>** ok I think that's it from my side - anything else before we move to the Kovri meeting?
**\<tewinget>** glad someone else could answer that while I was rebooting.  Stupid computer crashes frequently, pretty sure it's hardware.
**\<fluffypony>** tewinget: you should buy a Mac :-P
**\<ArticMine>** No
**\<tewinget>** fluffypony: I thought we were friends...
**\<tewinget>** tbh if a newer Mac (not new, with that single port, but new-ish) landed on my lap I'd throw Linux on it and use it
**\<tewinget>** but I'd never buy one, they're way too expensive for what they are.
**\<othe>** actually the macbook pro are good value for money compared to other ultrabooks; anyway kovir next :p
**\<fluffypony>** Pro Retina is great, although I've switched my Purism Librem 13 + Qubes for anything remotely sensitive
**\<antanst1>** Hackintosh user here :-) It's pretty easy to install OSX if you choose hardware carefully.
**\<antanst1>** works pretty much perfectly.
**\<othe>** correct, also run a hackintosh desktop
**\<ArticMine>** I see the software not the hardware as the issue with Mac
**\<meeting-bot> * anonimal** has 8 year old hackbook pro running Arch :/
**\<meeting-bot> [anonimal]** Still alive, surprisingly.
**\<fluffypony>** nice