--- layout: post title: Overview and Logs for the Dev Meeting Held on 2016-09-11 summary: brief update on 0MQ, RingCT, the hardfork schedule, and a new contributor, pigeons (sysops/devops) tags: [dev diaries, core, crypto, 0mq] author: dEBRUYNE / fluffypony --- ### 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