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