monero-site/_posts/2016-06-19-overview-and-logs-for-the-dev-meeting-held-on-2016-06-19.md

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