---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-09-11
summary: brief update on 0MQ, Ring CT, and the official GUI, and hardfork schedule, and introduction of pigeons (sysops/devops)
tags: [dev diaries, core, crypto, 0mq]
author: dEBRUYNE / fluffypony
---

*September 11th, 2016*

# Logs

**\<fluffypony>** Hi all
**\<fluffypony>** I'm on my phone
**\<ArticMine>** Hi all
**\<tooquick_4u>** hello
**\<DaveyJones>** NoodleDoodle, TheKoziTwo,
**\<DaveyJones>** anyone else?
**\<pigeons>** hola
**\<DaveyJones>** luigi1112, listening or cruising ;)
**\<DaveyJones>** jwinterm
**\<fluffypony>** lol
**\<fluffypony>** hyc and moneromooo are around afaik
**\<tewinget>** fluffypony: if you wanna just give a list of things to cover, one of us can conduct the meeting.  (assuming you don't wanna have to type a shitload on your phone)
**\<fluffypony>** Well I think let's start with 0MQ, tewinget
**\<fluffypony>** Then you can talk and I don't have to
**\<fluffypony>** :-P
**\<tewinget>** well, I wanted to have more news, but I'm having to do a full distro upgrade to get a newer boost on this craptop, and the internet is slow as balls...so I don't really have much in the way of updates.  Soon™.  Need to merge RingCT stuff into my zmq branch, then make the new RingCT-related RPC calls (as well as updating any others as needed), then should be golden for basic implementation.
**\<tewinget>** will try to get most of that done today or tomorrow.
**\<fluffypony>** This is daemon only right now right?
**\<tewinget>** daemon RPC, and a lib to use it that libwallet will call into.
**\<fluffypony>** ok - and then next thing after daemon is buttoned up is a wallet 0MQ endpoint right?
**\<tewinget>** but yes, for right now I'm working on the daemon's RPC.  Once that's in a good spot I can move onto wallet RPC.  Oh, and I think since the last dev meeting I redid the formatting of the RPC commands to get JSON-RPC 2.0 compliant.
**\<fluffypony>** Ok so tewinget let me ask about the backwards-compatible stub
**\<fluffypony>** Coz obviously we still need a stub for those that insist on touching the daemon using old RPC
**\<fluffypony>** Is that just a matter of refactoring it out of the daemon?
**\<tewinget>** well...so *my* plan was to leave the old RPC in place until we decide "yea, that's for sure deprecated and gonna be removed now"
**\<fluffypony>** That's fine - I meant as a later exercise
**\<fluffypony>** Just trying to gauge the amount of effort it's going to take
**\<tewinget>** hmm, well, a wrapper around the old RPC to hook into the new wouldn't be *too* hard...
**\<tewinget>** just tedious
**\<fluffypony>** I know it's tedious
**\<fluffypony>** What if we made it generic
**\<fluffypony>** Like it translated the RPC call directly
**\<fluffypony>** If it fails pass the error back
**\<fluffypony>** Oh wait that won't work
**\<fluffypony>** The 0MQ calls are different
**\<tewinget>** not hugely different, but different in some cases, yes.  with good reason...
**\<fluffypony>** Ok so tedious because it requires everything implemented as a 0MQ client, got it
**\<fluffypony>** As a practical matter
**\<fluffypony>** We need to consider something like cppnetlib for TLS and auth
**\<tewinget>** I'm trying to make switching costs as low as possible, but I can't make it nonzero.
**\<fluffypony>** And implement that as a matter of some urgency, since the entire net_skeleton thing was a colossal waste of time
**\<fluffypony>** Ok tks tewinget - anything else from your side?
**\<tewinget>** yea, I might make TLS and auth a priority ahead of wallet RPC (since it will need auth anyway)
**\<tewinget>** other than that, not really.
**\<tewinget>** carry on.
**\<moneromooo>** "I can't make it nonzero" <-- excellent!
**\<fluffypony>** Hokay
**\<fluffypony>** LOL
**\<fluffypony>** Nice catch
**\<hyc>** lol
**\<fluffypony>** breaking: Monero contributor works for free!
**\<hyc>** just tuning in, was teaking my ARM code
**\<tewinget>** god dammit.
**\<fluffypony>** Instant delivery!
**\<tewinget>** well, moneromooo, I can't
**\<tewinget>** because it has to use ZERO MQ
**\<fluffypony>** Hah hah
**\<tewinget>** #SavedIt
**\<hyc>** :P
**\<fluffypony>** #dadjokes
**\<fluffypony>** At any rate
**\<fluffypony>** I'd like to introduce pigeons
**\<fluffypony>** He's recently started doing some stuff with me
**\<fluffypony>** and he's kindly going to help us redo our sysops / devops
**\<fluffypony>** For all projects, including Kovri
**\<hyc>** nice
**\<pigeons>** Hi guys. :)
**\<moneromooo>** Hi
**\<hyc>** hey there
**\<fluffypony>** pigeons: tell us a bit about yourself or whatever
**\<fluffypony>** "Long walks on the beach" and all that
**\<hyc>** I guess the population explosion kinda demanded more ops
**\<moneromooo>** I see what a sysop is, but not a devop.
**\<pigeons>** I like pina coladas and getting lost in te rain. Ive been syadmin type stuff forever.
**\<ArticMine>** Hi pigeons
**\<fluffypony>** moneromooo: devops is like CI and build boxes and that
**\<pigeons>** devops is the new term for brogrammers who use docker and jenkins CI etc
**\<moneromooo>** Oh nice :)
**\<fluffypony>** Hah hah
**\<hyc>** I think a devop is a developer with rootpw on all production machines. sysaop's worst nightmare :P
**\<fluffypony>** Devops-as-a-Service
**\<fluffypony>** lol
**\<pigeons>** but yeah im gonna try and get buildbot ci going the system chromium and some others use
**\<pigeons>** get builds and tests for arm, windows, mac, freebsd, linux 32 64
**\<fluffypony>** Also the immediate aim is to be able to push nightlies to the site
**\<hyc>** nice
**\<iDunk>** #1047 did this
**\<iDunk>** oops
**\<i2p-relay> {-guzzi}** hi pigeons
**\<fluffypony>** So the broader community can test without waiting for fluffypony to build
**\<pigeons>** eventually look at gitian style reproducible builds
**\<hyc>** ARM is gonna be 3 distinct builds, ARMv6, ARMv7, ARMv8
**\<hyc>** rapidly proliferating...
**\<pigeons>** ok cool
**\<fluffypony>** hyc: I think we'll have to drop ARMv6 for performance concerns
**\<fluffypony>** If not now then soon
**\<hyc>** ok, fair enough
**\<fluffypony>** Also on that note
**\<hyc>** yeah, the perf/watt just isn't there on ARMv6
**\<fluffypony>** Am I correct in saying that QEMU is about the only way we're going to get arm7/8 build boxes?
**\<fluffypony>** Or does anyone know of hosted native arm boxes?
**\<hyc>** there's an ARM VPS provider out there
**\<pigeons>** yeah what are they called again, there is one
**\<tewinget>** someone recommended one to me just the other day, oddly enough...can't remember the name.
**\<fluffypony>** lol
**\<bitjedi>** awww. i still use my pi zero nodes
**\<bitjedi>** which are arm v6
**\<fluffypony>** bitjedi: they'll choke on RingCT
**\<iDunk>** scaleway.com ?
**\<hyc>** scaleways?
**\<hyc>** yeah
**\<bitjedi>** are u sure it's cpu and not io?
**\<fluffypony>** Awesome
**\<fluffypony>** Isn't scaleways native and not virtualised?
**\<fluffypony>** I seem to vaguely recall
**\<tewinget>** I think it was Scaleway
**\<hyc>** hm, they claim bare metal, yeah
**\<pigeons>** theres one ovhi or somone in scandanavia
**\<fluffypony>** Ok
**\<fluffypony>** Also the implication is that anyone relying on the Mac / 32-bit test boxes should expect an impending change
**\<fluffypony>** I think anonimal primarily uses them
**\<fluffypony>** Also we'll hopefully be able to provide broader access to test hardware in future
**\<i2p-relay> {-anonimal}** * has yet to use 32-bit boxes
**\<fluffypony>** Ok then FreeBSD
**\<fluffypony>** Has anyone tried the WIP boost 1.60 port on BSD?
**\<hyc>** haven't touched BSD in years
**\<i2p-relay> {-anonimal}** Last I checked, build failed hard on freebsd for monero.
**\<i2p-relay> {-anonimal}** Works with kovri.
**\<fluffypony>** xmj is our resident BSD expert and even he hasn't touched boost 1.60
**\<fluffypony>** If anyone wants to volunteer to play with that great
**\<fluffypony>** We also need to start thinking about packaging
**\<fluffypony>** lol relevant PR is relevant
**\<fluffypony>** hyc how do you guys handle packaging for like Debian / Ubuntu?
**\<hyc>** eh, OpenLDAP Project is source-code only, distros do their own packaging
**\<fluffypony>** Coz my concern with farming it out is that we end up with old versions on old distros
**\<i2p-relay> {-anonimal}** fluffypony: I was planning to work with the monero bsd build (only freebsd though) once we get kovri releases going
**\<hyc>** yes, that's a pervasive problem with distros
**\<fluffypony>** Tks anonimal - I'll also fiddle
**\<fluffypony>** When I have time, so never :-P
**\<fluffypony>** Ok next thing
**\<fluffypony>** moneromooo: want to talk about the rct serialisation changes?
**\<fluffypony>** And the impact on testnet
**\<moneromooo>** It's finished. It's on github ready to merge. And it will need reorganizing on testnet, yes.
**\<moneromooo>** So, I guess someone with hash power will have to pop N blocks till before v4, and mine.
**\<moneromooo>** After a few daysm it'll reorg for everyone :)
**\<moneromooo>** And we'll get to test deep reogs.
**\<hyc>** so anyone mining testnet right now should stop
**\<moneromooo>** Unless you want to test stuff.
**\<iDunk>** i exported the raw blockchain up to 800499. that's before v3, right?
**\<tewinget>** well that's not entirely necessary >**_>**
**\<moneromooo>** Yes.
**\<iDunk>** and v4 is... ?
**\<iDunk>** 802000 or so iirc ?
**\<moneromooo>** 801220
**\<jjiia>** XMR up or down
**\<iDunk>** ah, k
**\<fluffypony>** I think my miner is off atm
**\<fluffypony>** it had that hiccup and I never fixed it coz stuff
**\<moneromooo>** rct soon!
**\<fluffypony>** ok so moneromooo
**\<ArticMine>** It had to be done
**\<MalMen>** are you guys forking the testnet ?
**\<fluffypony>** when it loads the blockchain on the new code
**\<MalMen>** im gonnad do a testnet classic
**\<fluffypony>** it *should* freak out
**\<i2p-relay> {-anonimal}** Is this the meeting where we can discusses CI for CD?
**\<fluffypony>** and rollback?
**\<fluffypony>** anonimal: CD? like compact discs?
**\<i2p-relay> {-anonimal}** Laser-only releases
**\<moneromooo>** It'll probably moan a bit, but not overly.
**\<fluffypony>** :-P
**\<fluffypony>** ok but what I mean is
**\<fluffypony>** when we load a blockchain off disk we don't re-verify
**\<MalMen>** the dev meeting is still going on or to late ?
**\<fluffypony>** so will we have to manually pop blocks?
**\<dEBRUYNE>** still going on MalMen 
**\<moneromooo>** Yes.
**\<fluffypony>** ok so I'll merge tomorrow afternoon, gives us a day for review
**\<moneromooo>** Just the miner. Others will just reorg when the miner passes the old chain's diff.
**\<moneromooo>** (hopefully)
**\<fluffypony>** and then I'll do some block-popping tomorrow night
**\<fluffypony>** and hopefully deep reorgs
**\<moneromooo>** luigi1112: btw, you'll want to read the latest get_transaction_hash and comment. It's still 3 parts.
**\<fluffypony>** ok
**\<fluffypony>** then the next thing is our hard fork date and the next release
**\<fluffypony>** we're planning on finalising final bits and releasing 0.10 shortly
**\<fluffypony>** but obviously RingCT (ie. v4 blocks) is not ready for even a final inclusion in this code freeze
**\<fluffypony>** given that we're still making changes
**\<fluffypony>** so I'd like some input from contributors and those present as to how to handle the v4 fork, since we have a couple of options
**\<fluffypony>** either:
**\<fluffypony>** 1. we leave v4 till March 2016
**\<iDunk>** 2017
**\<fluffypony>** tks 2017
**\<fluffypony>** 2. we change the "complain about a fork" date to like end-of-November, with an aim to forking to v4 end of December
**\<fluffypony>** so coded freeze beginning of December
**\<fluffypony>** (this would make RCT transactions potentially available on mainnet from Jan 1)
**\<fluffypony>** but obviously there's the risk of breakage
**\<hyc>** maybe December is too soon, how about January?
**\<fluffypony>** so if we had to do Jan, then when do we do v5?
**\<fluffypony>** March is too close to Jan for v5, imho
**\<ArticMine>** fluffypony My preference is 2, but my biggest concern is the amount of time left for finalization of development and testing
**\<dEBRUYNE>** We don't necessarily have to decide the exact dates now, but I think option 2 would be best
**\<fluffypony>** ok so what if we did 2, but then pushed the v5 fork to September next year
**\<hyc>** if we have v4 in January then June/July would be OK
**\<fluffypony>** that way RCT is available on mainnet early on, but if anything breaks we have 9 months to fix it
**\<fluffypony>** hyc: I don't want to go too far away from our schedule
**\<hyc>** ok
**\<dEBRUYNE>** \<hyc> if we have v4 in January then June/July would be OK <= Fine with that too
**\<DaveyJones>** sounds reasonable to me
**\<dEBRUYNE>** Like I said, we can always decide on the exact dates later
**\<fluffypony>** like this is major enough to warrant a change, but we should aim for a singular change
**\<hyc>** so march/september is the cadence we're aiming for?
**\<ArticMine>** Yes I like the idea of advancing V4 fork but keeping the v5 fork on schedule
**\<tewinget>** I agree, singular deviation from the schedule is preferable.
**\<hyc>** ok
**\<fluffypony>** hyc: yep
**\<dEBRUYNE>** fluffypony: most people will use Ring CT transactions anyway
**\<fluffypony>** so we bring v4 a bit forward, and leave v5 as scheduled
**\<lurker>** yes
**\<fluffypony>** dEBRUYNE: we can always make it the non-default, like we did with transfer_new
**\<hyc>** sounds good
**\<dEBRUYNE>** yeah agree
**\<ArticMine>** agree
**\<fluffypony>** ok so we'll move the freak-out to early December, and actual fork block height will be decided at that code freeze
**\<fluffypony>** but likely late Dec / early Jan or so
**\<fluffypony>** and v5 stays for September 2017
**\<fluffypony>** consensus: reached!
**\<DaveyJones>** \o/
**\<fluffypony>** (it's so easy when you're tiny and only like 5 people have to agree, lol)
**\<fluffypony>** I think that's about it from my side, there's something else but I completely can't remember
**\<fluffypony>** is there anything else that anyone wants to bring up?
**\<ferretinjapan>** I dunno multisig for bitcoin was a bitch...
**\<hyc>** current freeze, release date?
**\<tewinget>** since Ilya's not here...
**\<i2p-relay> {-anonimal}** I moved kovri logo decision agenda to the beginning of kovri meeting in 10'ish minutes so we can catch everyone before they leave
**\<ferretinjapan>** that only had 8 guys
**\<fluffypony>** ferretinjapan: lol
**\<lurker>** a quick update on multisig preferably
**\<moneromooo>** Do you want to wait for the fee change before binaries ?
**\<fluffypony>** lurker: https://shnoe.wordpress.com/2016/03/22/ring-multisignature/
**\<fluffypony>** it's whitepaper-only right now
**\<kintaji>** fluffpony - the GUI wallet. Languages and regional variations.
**\<fluffypony>** oh
**\<Kermit_>** Hi guys can I ask about public wallet build release dates
**\<fluffypony>** yes moneromooo thanks for reminding me
**\<fluffypony>** tag->release->binaries will be in the coming week, hopefully
**\<fluffypony>** there are two things still remaining
**\<fluffypony>** 1. fee changes (lower min-fee, bind it to the inverse of the block median as suggested by ArticMine)
**\<fluffypony>** 2. ideally, if anyone is up for it, we seriously need our DNSSEC check expanded to *actually* check from the root cert down, at the moment it's relying on the DNS server to send back a "secure" flag, which is breaking it on lots of routers
**\<MalMen>** tewinget can you point me to the list of 0qm commands that you have already?
**\<fluffypony>** and we rely on DNSSEC for MoneroSeeds and MoneroPulse
**\<MalMen>** I have some sugestion
**\<ArticMine>** moneromooo is coding the fee changes
**\<fluffypony>** there's some time pressure on that, but it's not a huge piece of work, so if anyone is up for it then that would be appreciated
**\<fluffypony>** if not it'll have to hold off till the next release
**\<moneromooo>** Yes, I started looking at it this afternoon. Not a simple change, since it'll require a new RPC, and access to median block size calc in misc places.
**\<fluffypony>** ok
**\<dEBRUYNE>** fluffypony: would it be feasible to provide trezor binaries? 
**\<fluffypony>** dEBRUYNE: I haven't actually looked at it properly, and NoodleDoodle isn't around to give his opinion
**\<dEBRUYNE>** I see, he's still working on the Ring CT bit, so probably better to wait until that is finished to provide them
**\<fluffypony>** kintaji: re: languages / variants, I think we'll hold off on that a bit as there are large parts of the GUI that are non-functional right now
**\<fluffypony>** Kermit_: do you mean the GUI wallet, or the next tagged release?
**\<Kermit_>** Yes gui
**\<kintaji>** fluffypony - Okay. Just to say there are some oddities with the current flag page. Can expand at a later time.
**\<fluffypony>** Kermit_: not certain yet - I'll look at building beta binaries in the next week or so
**\<Kermit_>** Thanks
**\<fluffypony>** kintaji: yeah maybe best thing to do is drop it out the wizard initially
**\<fluffypony>** and add it back in later on
**\<tewinget>** MalMen: have a look at https://www.github.com/tewinget/bitmonero/tree/zmq-dev, file src/rpc/daemon_messages.h.  I need to do a bit of write-up, but that's a good place to start.
**\<kintaji>** fluffypony - yep. sounds like a good idea.
**\<fluffypony>** ok anything else or can we start the Kovri meeting?
**\<hyc>** any other volunteers to test ARMv8 builds?
**\<fluffypony>** oooh I will hyc
**\<pero>** yea i can
**\<hyc>** cool, I'll have atarball ready later tonight
**\<MalMen>** tewinget you are writing your rcp calls with up letters right ?
**\<pero>** fluffy i have centos 64bit on my rpi3 fyi
**\<fluffypony>** hyc: is an R8 ARM processor an armv8?
**\<fluffypony>** coz if so then I have a bunch of C.H.I.Ps lying around that I can test on
**\<hyc>** I don't know what R8 is. what box is that?
**\<tewinget>** MalMen: the class names are CamelCase, but the methods (currently) are "word_word_word".  No reason that can't change, of course.
**\<MalMen>** ahhhh, nice
**\<fluffypony>** AllWinner R8
**\<MalMen>** I was in mind that you where using WordWordWord
**\<hyc>** ok I see it
**\<MalMen>** would sugest wordWordWord
**\<fluffypony>** "Allwinner R8 is SoC designed based on A13 featuring one core Cortex-A8 ARM CPU with Cedar Engine VPU and Mali 400 GPU"
**\<hyc>** nope . Cortex-A8 is ARMv7
**\<fluffypony>** ah ok
**\<fluffypony>** well that sucks
**\<fluffypony>** hi meeting-bot!
**\<tewinget>** MalMen: the method names (as in, the method field in the RPC call on the wire) are "word_word_word" to conform with the previous RPC, but I have no particular attachment to that format.
**\<MalMen>** well, I am checking the bitcoin rcp and they use wordwordword, I think i like word_word_word better