Commit d8db0fc7 authored by antanst's avatar antanst
Browse files
parents 3b624401 13095202
- platform: Windows, 64-bit
icon: windows.svg
url: win64
hash: 246115b0da133e0203dc78d26bbc82e9b76a178939bff8d4541bf04a02a19854
hash: 9d939613c0eba872a3dacd7fda572f4c7d2279207ce1ec0b15b46da4e1ccd5b9
tag: Hydrogen Helix
blockchain: win
- platform: Windows, 32-bit
icon: windows.svg
url: win32
hash: 4663222a810ad854da1fc9d665e51252e61ddb1a8f69de3a31ad195386d445a2
hash: c9e4abc19c767ab570c2d0a9d504ba75d73eea26e7cf719a1260fdbb9469c250
tag: Hydrogen Helix
blockchain: win
- platform: Mac OS X, 64-bit
icon: apple.svg
url: mac64
hash: f471a420485413d5fcb1b19065a3b4e9a68c49596ddd6291787ad34121bad32c
hash: ded52162d34d5a726b53ffd14ebbf02388d9b396f3f4e278a4755e5286b1aeab
tag: Hydrogen Helix
blockchain: mac
- platform: Linux, 64-bit
icon: linux.svg
url: linux64
hash: 9e6747b69642389e98ca5f70cec7276f7af7156e5dce95409a8da7cccff5876e
hash: 0b3610c9b301ea14174ce700923a604909fa7cbd9335849112c9d6cfb07a1a43
tag: Hydrogen Helix
blockchain: linux
- platform: Linux, 32-bit
icon: linux.svg
url: linux32
hash: 90c51c4a68f78ac2262a7b5a676f02d43ba7b9b6800b8b150d89980604c969f2
hash: c070125bb885c5b887d3adce866e9bb941ed790485ef34444e62e0881fe8852a
tag: Hydrogen Helix
blockchain: linux
......@@ -22,7 +22,7 @@
- slug: i2p
name: i2p
- slug: i2p
- slug: i8n
name: Internationalisation
- slug: rpc
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-03-19
summary: Open PRs, GUI commits, app/add-on infrastructure, versioning
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
*March 19th, 2016*
# Logs
**\<dEBRUYNE>** dev meeting in 5 min, FYI
**\<hyc>** dingdong
**\<gingeropolous>** hello
**\<dEBRUYNE>** fluffypony, smooth, othe, ArticMine, luigiw, NoodleDoodle, tewinget, moneromooo
**\<floofypony>** there we go
**\<dEBRUYNE>** did I forget anyone?
**\<tewinget>** oh, hello
**\<luigi>** is warptangent around?
**\<ArticMine>** Hello
**\<hyc>** he's been fighting a flu last we heard
**\<moneromooo>** hi
**\<NoodleDoodle>** Hello. I'm here but I'm fighting the apocalypse.
**\<NoodleDoodle>** of flus.
**\<luigi>** keep doing it
**\<luigi>** wait you're alive that's good to hear
**\<dEBRUYNE>** fluffypony seems ded
**\<fluffypony>** sorry
**\<fluffypony>** was eating
**\<fluffypony>** welcome everyone
**\<fluffypony>** so as you know we pushed out 0.9.2
**\<fluffypony>** however, there are some nagging issues from the ReadTXN work
**\<fluffypony>** hyc has nailed a major one as of a few hours ago
**\<fluffypony>** so we'll probably do a point release on Monday or so
**\<fluffypony>** also that means that the way we use LMDB has changed a bit
**\<fluffypony>** hyc can you tell us briefly how we should wrapping access to LMDB, both read and write operations?
**\<hyc>** Are you talking about the CRITICAL\_REGION stuff?
**\<fluffypony>** yes, and the cursors vs. txns stuff
**\<hyc>** ok, the critical\_region stuff actually is not a change at all.
**\<hyc>** basically, when you're setting up to do a write, you need exclusive access to the DB
**\<hyc>** this appears to have been a long-standing bug, unrelated to the readtxn changes
**\<hyc>** so as for reads - there is now a long-lived read txn per thread
**\<hyc>** and a set of read cursors to go with each
**\<hyc>** the TXN\_PREFIX\_RDONLY macro sets that up in a particular function, grabbing the thread-local-storage for it
**\<hyc>** and RCURSOR(dbname) sets up a read cursor for a particular DB
**\<hyc>** these are analogous to the CURSOR(dbname) macro for getting a write cursor to a DB
**\<hyc>** the point of all this is to avoid a bunch of malloc/free/seek when accessing a DB
**\<hyc>** the old code was allocating a readtxn and cursors inside each function
**\<hyc>** likewise for writes
**\<hyc>** by reusing the same cursors acros a set oof functions we get a pretty good performance gain
**\<hyc>** ok?
**\<fluffypony>** neat
**\<fluffypony>** also on the topic of stuff-hyc-did-lately
**\<fluffypony>** if anyone missed it, we now have a win environment guide up on
**\<dEBRUYNE>** ^ https//
**\<fluffypony>** so that should get us all on the same page with testing etc.
**\<hyc>** and one success story replied to it already ;)
**\<fluffypony>** we've also dropped support for BDB as the default database, and switched to LMDB as the default
**\<fluffypony>** including on -bit and ARM
**\<fluffypony>** BDB will remain supported for the moment, primarily as a mechanism for contributors to understand how to build out DB support
**\<fluffypony>** krongle)
**\<fluffypony>** shew we have the entire team here today, that's awesome
**\<binaryFate>** fluffypony good memory P
**\<fluffypony>** we shared a podcast together, binaryFate -P
**\<krongle>** yes - impressive nick-name recollection
**\<fluffypony>** hah hah
**\<fluffypony>** while we have you guys here, are you guys doing anything cool you want to talk about?
**\<binaryFate>** we're doing many cool things, but nothing we can talk about at this stage
**\<fluffypony>** hah hah
**\<fluffypony>** it does lead to an interesting point of conversation
**\<binaryFate>** seriously considering btc -> xmr direction
**\<fluffypony>** plugins
**\<iam6yearsold>** If NobleSir or team could talk more about integration at MiniNero that would be great.... also are 2 way conversions coming to soon?
**\<fluffypony>** iam6yearsold Shen's offline at the moment, I'll ask him to update the Reddit thread with some info )
**\<fluffypony>** re plugins, we've spoken briefly about options for the GUI
**\<dEBRUYNE>** iam6yearsold There is a bit of info here -> https//
**\<binaryFate>** iam6yearsold for MiniNero integration you'd have to see with NobleSir. The API doc is at http//
**\<fluffypony>** but I guess we could have "plugins", of a sort, that add functionality
**\<fluffypony>** like or shapeshift integration right in wallet2 / wallet2\_api
**\<dEBRUYNE>** I think we should be fairly strict on which plugins to allow
**\<binaryFate>** fluffypony we wanted to discuss that plugin integration soon in fact )
**\<arnuschky>** we're quite interested to all secondary questions related to plugins
**\<fluffypony>** I guess the major question becomes
**\<arnuschky>** so plugin repository/db, packaging, distribution etc
**\<fluffypony>** do we allow "permissionless" plugin development, or do we just have a central repo that we git submodule in?
**\<ArticMine>** The main question I see with plugins is trust
**\<fluffypony>** ArticMine exactly
**\<arnuschky>** yes. It puts quite a bit responsibility on the dev team
**\<gingeropolous>** well no ones going to trust anything that doesn;t come from core
**\<tewinget>** \<fluffypony> we shared a podcast together, binaryFate -P <-- wasn't I there for that?
**\<fluffypony>** considering the recent Google Chrome Bitcoin stealing malware I think that premissionless plugins are dangerous
**\<gingeropolous>** as we've seen with 3rd party GUIs
**\<luigi>** you obviously can't stop permissionless dev, you can discourage users from trusting it I guess
**\<hyc>** we can start signing binaries, ohjoy
**\<dEBRUYNE>** I would prefer the latter
**\<fluffypony>** luigi I mean permissionless within core
**\<luigi>** oh
**\<luigi>** I think no
**\<arnuschky>** it's related to how plugins are written. If it's binary blobs, it's a) hard to build, distribute etc, and b) hard to examine
**\<binaryFate>** fluffypony I'd see both possible all together. Unpermissioned scale and central repo for a selected subset would ease experience and trust for user
**\<arnuschky>** so if plugins are interpreted (eg python), things become a whole lot easier
**\<iam6yearsold>** for the record I hated the twittter plugin idea I saw a while back
**\<ArticMine>** My take permissionless has to be allowed. The end user has to be made aware who is signing and if to trust the plugin
**\<fluffypony>** well the Electrum model works well
**\<moneromooo>** I agree with ArticMine
**\<arnuschky>** (inspection in case of central repo, but also self-distribution by plugin devs)
**\<fluffypony>** ThomasV will merge basically any plugin, as long as it's not malicious
**\<fluffypony>** and plugins are part of the core code, effectively just in a subfolder
**\<fluffypony>** I think it's a testament to Electrum that they haven't had a malicious plugin ever
**\<arnuschky>** how do they deal with the upgrade/maintenance workload? Or do they just disable broken plugins?
**\<dEBRUYNE>** Is there a way to make a subfolder in the subfolder? i.e. (1) signed and approved by core-team, (2) optional
**\<fluffypony>** arnuschky yeah they just disable broken plugins, and eventually they get deprecated out
**\<ArticMine>** We should allow self distribution with appropriate warning
**\<fluffypony>** ArticMine anyone can compile their own build, which would be the same thing
**\<arnuschky>** are you planning for compiled plugins or interpreted ones? that's quite a differens IMHO
**\<fluffypony>** arnuschky so
**\<arnuschky>** self-distribution is a mess for compiled ones...
**\<fluffypony>** I was thinking we have a repo, say it's called monero-plugins
**\<arnuschky>** audit as well
**\<fluffypony>** and then anyone can PR to that repo
**\<fluffypony>** and that repo is pulled into the main Monero source as a git submodule
**\<fluffypony>** there are two advantages to this
**\<fluffypony>** 1. as it gets bigger and harder to deal with, we can step back and other known members of the community can manage that repo
**\<fluffypony>** 2. if we come up with a standard set of functionality hooks, then other projects can pull that same repo in
**\<fluffypony>** eg. jwinterm's lightwallet
**\<fluffypony>** also it means that the compiled Monero binaries have those plugins baked in, and you can't add extra plugins post-compile
**\<fluffypony>** so no need to deal with interpreted code and securing that on disk and in memory
**\<hyc>** baked in means no dynamic loading?
**\<tewinget>** \<fluffypony> so no need to deal with interpreted code and securing that on disk <-- if securing an interpreted plugin on disk became an issue, securing the binary would be an issue anyway, so I don't know of that bit matters
**\<binaryFate>** Sounds all good to us. If distribution is done through official channels it's great.
**\<fluffypony>** hyc yes
**\<fluffypony>** no dynamic loading
**\<hyc>** cool
**\<fluffypony>** tewinget I mean we can't secure it in the path from random-site-on-the-web down to random-download-folder and eventually into secure-disk-location
**\<arnuschky>** fluffypony that would be really great.
**\<fluffypony>** ok - I think next steps would be to consider some of the hooks we need to provide to add functionality
**\<fluffypony>** we can use the Monero wikia as a collaboration area for that
**\<ArticMine>** It is a good balance for plugins
**\<fluffypony>** and then we'll just update the Monero Slack
**\<arnuschky>** well securing the plugins can always happen by signature - no matter if interpreted or binary
**\<fluffypony>** I'm kidding, we don't have a Slack
**\<fluffypony>** we're not that cool
**\<aerbax>** Would these plugins allow for interpreted languages like Lua or Python?
**\<arnuschky>** :)
**\<fluffypony>** aerbax I don't see why not, individual CMake files in each plugin folder that allow it to produce a library fix everything
**\<binaryFate>** We could financially support development of plugin architecture if is the first instanciation of those plugins.
**\<fluffypony>** if it spits out a .so / .a / .dll with the right hooks then it's fine
**\<tewinget>** fluffypony> tewinget I mean we can't secure it in the path from random-site-on-the-web down to random-download-folder and eventually into secure-disk-location <-- and yet, we provide binary "random site on the web" could be managed the same as said binary downloads
**\<tewinget>** just like any random site on the web can offer binaries for download and we can't secure that either
**\<tewinget>** caveat emptor has to come into play at some point, I think
**\<fluffypony>** the binaries present a single attack surface, and there's GPG-signed hashes
**\<fluffypony>** if we have to do GPG-signed hashes for a bunch of .py files I think I'll go mad -P
**\<tewinget>** I'm not saying I think it should be one way or another, I'm merely pointing out flaws in your argument P
**\<fluffypony>** fair enough
**\<fluffypony>** binaryFate I think the stumbling block will be that somebody needs to champion this and run with it, and I won't be able to lead it due to travelling in a week
**\<ArticMine>** As long as people can compile their own version with non permissioned plugins this can work
**\<luigi>** they can always do that
**\<fluffypony>** yep
**\<fluffypony>** and in fact that would be the testing model
**\<luigi>** we're not apple )
**\<fluffypony>** fork the repo, and build a binary to test your new plugin
**\<iam6yearsold>** asking noobs to compile will limit adoption
**\<ArticMine>** luigi Exactly
**\<fluffypony>** iam6yearsold why would noobs be writing their own plugins?
**\<gingeropolous>** for security
**\<dEBRUYNE>** lol gingeropolous
**\<fluffypony>** lol
**\<arnuschky>** fluffypony championing the first plugin or the whole infrastructure?
**\<tewinget>** What about a curated repo of plugins (as suggested) but with those plugins written in python/lua? Someone modifying the python/lua on a target's disk is the same as someone modifying the binary anyway, and python/lua plugins would be far easier to develop and audit I think
**\<fluffypony>** arnuschky championing the design, I guess
**\<arnuschky>** tewinget I would prefer that.
**\<iam6yearsold>** how about 1 version with binaries and gpg sig and no plugins? caveat emptor for the rest
**\<arnuschky>** mostly due to auditing, and there's no build/distribution mess attached
**\<fluffypony>** I would prefer we remain language agnostic
**\<fluffypony>** iam6yearsold that's what we already have
**\<tewinget>** fluffypony language-agnostic is fine, but...well, how do you imagine that will work out?
**\<iam6yearsold>** thanks pony. I like the current situation then
**\<fluffypony>** tewinget read up
**\<arnuschky>** ah even language agnostic. I thought up to now it's supposed to be a C++ only API
**\<tewinget>** as in, how do we become language-agnostic so that we can remain so?
**\<fluffypony>** [] \<aerbax> Would these plugins allow for interpreted languages like Lua or Python?
**\<fluffypony>** [] \<fluffypony> aerbax I don't see why not, individual CMake files in each plugin folder that allow it to produce a library fix everything
**\<fluffypony>** ^^
**\* smooth** is here
**\<fluffypony>** also what if a plugin wants to call a function in the core crypto library, for instance?
**\<arnuschky>** design-wise, that's sounds like a nightmare, no?
**\<moneromooo>** Oh, so linked directly ? I kinda assumed it was gointg to be RPC based.
**\<fluffypony>** ok well I think we're getting into an implementation discussion that's outside of the scope of this meeting
**\<arnuschky>** I mean, if you don't have a small and defined API, every bigger change in the wallet will break plugins
**\<arnuschky>** true )
**\<fluffypony>** after the dev meeting we can continue this conversation if you guys want
**\<fluffypony>** but let's first circle back around
**\<luigi>** this deserves some kind of design thread like ringct imo
**\<moneromooo>** Oh, link ?
**\<fluffypony>** moneromooo: "this deserves"
**\<fluffypony>** so nothing yet
**\<moneromooo>** "like ringct"
**\<fluffypony>** oh
**\<fluffypony>** I see what you were asking
**\<luigi>** oh
**\<moneromooo>** Oh
**\<fluffypony>** OH
**\<luigi>** "like ringct is supposed to get"
**\<moneromooo>** Fair enough.
**\<fluffypony>** so basically this is all luigi's fault
**\<luigi>** warp was gonna go [email protected]
**\<gingeropolous>** its true. i mis-called out luigi on that one
**\<fluffypony>** warptangent is off sick at the moment
**\<luigi>** yes
**\<luigi>** so I blame that
**\<fluffypony>** I blame Canada
**\<fluffypony>** ok back on track
**\<fluffypony>** since the last meeting the bulk of the PRs have been bug fixes
**\<fluffypony>** and changes to the way we access the DB as discussed at the beginning
**\<fluffypony>** we also had a huge discussion about how to handle mixins below the minimum in the RPC call
**\<fluffypony>** which was then implemented in #715
**\<fluffypony>** I'm also going to try to personally spend some time on the text that users see, things like the level 0 logging output and the CLI flag help
**\<luigi>** oh I was gonna do that
**\<luigi>** but then I didn't
**\<fluffypony>** luigi we can do it together
**\<luigi>** awwww
**\<fluffypony>** I can show you the world, shining shimmering splendid
**\<gingeropolous>** take you wonder by wonder
**\<fluffypony>** lol
**\<fluffypony>** also #728 was a little contentious
**\<fluffypony>** so we created a company called Mixinstream that has hired all the contributors
**\<palexander>** heh heh
**\<fluffypony>** and gingeropolous has launched Monero Classic
**\<gingeropolous>** ( sorry )
**\<fluffypony>** -P
**\<fluffypony>** ok so #728 is Ilya's work as part of the GUI effort
**\<dEBRUYNE>** Can I launch unlimited?
**\<fluffypony>** he was struggling with wallet2, and decided to break it out into something more logical and usable
**\<fluffypony>** (to him at any rate)
**\<ArticMine>** What makes it contentious?
**\<fluffypony>** ArticMine I'll get to that now
**\<fluffypony>** he's unintuitively called it wallet2\_api, which is a little confusing
**\<fluffypony>** but basically a lot of it is a wallet2\_api call which then does little additional logic, and mainly just passes stuff back to wallet2
**\<fluffypony>** and there's a lot of DRY-violating code because of it
**\<fluffypony>** obviously there was some push back, not to prevent merging it
**\<fluffypony>** but more to understand the thought process
**\<moneromooo>** Define DRY ?
**\<iam6yearsold>** DRY violating scares the shit out of me
**\<gingeropolous>** https//\_repeat\_yourself
**\<gingeropolous>** maybe
**\<fluffypony>** yes
**\<fluffypony>** iam6yearsold DRY violations are just where you have a piece of code in two places
**\<fluffypony>** so any changes have to happen in both
**\<fluffypony>** we can treat the DRY-violating code as a temporary issue, though
**\<iam6yearsold>** two places = more opportunity for error
**\<fluffypony>** as we're going to wait until Ilya is done with it
**\<ArticMine>** Which makes maintenance much harder
**\<fluffypony>** and then we'll either drop wallet2 and replace it with the new wallet API
**\<fluffypony>** (ie. replace the simplewallet calls as well)
**\<fluffypony>** or if it's just a pointless layer we'll have to go the opposite route
**\<fluffypony>** and change his Qt callers to use wallet2
**\<fluffypony>** as it stands it's kinda undecided and we'll have to see how Ilya goes
**\<ArticMine>** Is Ilya aware of the concern?
**\<fluffypony>** ArticMine yes, we had some discussion on the PR, and othe has also spoken to him afaik
**\<fluffypony>** he was responsive on the PR comments, but this isn't Bitcoin
**\<fluffypony>** we don't ACK NACK utACK for years before merging somethingm
**\<fluffypony>** aintnobodygottimeforthat.gif
**\<luigi>** utNACK
**\<fluffypony>** luigi #networknerd
**\<moneromooo>** utACK was not a typo ?
**\<luigi>** no
**\<luigi>** means untested
**\<luigi>** conceptACK or similar
**\<fluffypony>** yeah
**\<fluffypony>** moneromooo https//
**\<fluffypony>** if you're interested
**\<hyc>** crap
**\<fluffypony>** LOL
**\<fluffypony>** PasteGate 2.0
**\<gingeropolous>** internets
**\<othe>** ur pasting skills suck
**\<dEBRUYNE>** Hahah
**\<fluffypony>** othe pasting is a scam
**\<hyc>** that's how I write all my patches
**\<fluffypony>** I just copy-and-paste code from StackExchange
**\<gingeropolous>** thats my job
**\<fluffypony>** heh
**\<fluffypony>** ok so anyone who can reproduce the 0.9.2 segfault please try latest master
**\<fluffypony>** and if you're still segfaulting let us know
**\<fluffypony>** else we're going to do a point release on Monday
**\<fluffypony>** 0.9.3, I guess?
**\<luigi>** hrm
**\<fluffypony>** or
**\<luigi>** we're gonna run out of numbers at this rate
**\<fluffypony>** yeah we are
**\<luigi>** oh wait
**\<hyc>** 0921
**\<luigi>** we have 0.10
**\<luigi>** nevermind
**\<iam6yearsold>** will there be multiple devs in IRC at time of hard fork this week just in case? I see a few pools still on old cold and probably a few users too
**\<fluffypony>** yes we just do a Bitcoin
**\<moneromooo>** No chance, there's an infinity of those.
**\<fluffypony>** 0.11
**\<fluffypony>** iam6yearsold yes, and we've reached out to as many of them as we can
**\<luigi>** is 0.10 supposed to be for next hard fork?
**\<fluffypony>** luigi fork that
**\<fluffypony>** when warptangent is back we'll see how it goes on ringCT
**\<fluffypony>** and make a more concrete decision as to the timing of the next fork
**\<dEBRUYNE>** iam6yearsold The hardfork will approximately take place at 13:00 UTC, so both US and Europe will probably be awake
**\<dEBRUYNE>** and Asia of course
**\<luigi>** everyone will be awake
**\<fluffypony>** even me
**\<dEBRUYNE>** hawaii will probably be asleep
**\<dEBRUYNE>** -P
**\<fluffypony>** heh
**\<dEBRUYNE>** fwiw!
**\<luigi>** wat
**\<Wolf\`>** lol
**\<smooth>** we should also consider what else we should go in the next major version besides ringct (doesn't need to be discussed now)
**\<dEBRUYNE>** uh I meant UTC btw
**\<dEBRUYNE>** you muricans with AM/PM
**\<Wolf\`>** who got drunk and posted about a party in #monero-dev
**\<luigi>** oh
**\<luigi>** then america won't be up
**\<moneromooo>** The db reorg seems like a good candidate.
**\<luigi>** oh well
**\<fluffypony>** smooth agreed
**\<dEBRUYNE>** east coast will right?
**\<luigi>** sure ish
**\<dEBRUYNE>** You better set your alarm luigi
**\<dEBRUYNE>** :-P
**\<fluffypony>** Surae is also going to be picking up MRL-6 in the summer
**\<fluffypony>** he has some ideas about how to complete that
**\<dEBRUYNE>** MRL-6 is multisig?
**\<iam6yearsold>** I will party hard if fork happens with no drama
**\<fluffypony>** dEBRUYNE: no
**\<fluffypony>** https//
**\<dEBRUYNE>** oh cool, thanks
**\<moneromooo>** How do get cmake to tell you the commands it's running ?
**\<luigi>** we have diff, we have db stuff, we have fee stuff
**\<fluffypony**> moneromooo: I normally make VERBOSE=1
**\<moneromooo>** Thanks, I was trying V=1
**\<luigi>** I like my V=2
**\<fluffypony>** ok - any last things to add
**\<fluffypony>** or can we call it?
**\<luigi>** call it
layout: post
title: Monero 0.9.4 Released
summary: A point release of Monero Hydrogen Helix containing important bug fixes
tags: [releases]
author: Riccardo Spagni (fluffypony)
*April 2nd, 2016*
## Summary of Changes
This has important bug fixes to 0.9.3 *Hydrogen Helix*
- Fix remaining issues with coinbase transactions
- Removed ```connectivity_tool```
- Switched to new Clang move diagnostics
- Added a new ```--generate-from-json``` flag to simplewallet to allow wallet creation from a JSON file
- Add a new and improved version of ```sweep_dust```
- Various bug fixes to handle failures such as map resize failures and bad simplewallet exits
## Official Download Links
- [Windows, 64-bit](
- [Windows, 32-bit](
- [OS X, 64-bit](
- [Linux, 64-bit](
- [Linux, 32-bit](
## Download Hashes
If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:
-, a6f171c942a2b75432573c3cea6ca3becb10769a08eaaea5cca080c92b8ee297
-, c9e4abc19c767ab570c2d0a9d504ba75d73eea26e7cf719a1260fdbb9469c250
- monero.linux.x64.v0-9-4-0.tar.bz2, 0b3610c9b301ea14174ce700923a604909fa7cbd9335849112c9d6cfb07a1a43
- monero.linux.x86.v0-9-4-0.tar.bz2, c070125bb885c5b887d3adce866e9bb941ed790485ef34444e62e0881fe8852a
- monero.mac.x64.v0-9-4-0.tar.bz2, ded52162d34d5a726b53ffd14ebbf02388d9b396f3f4e278a4755e5286b1aeab
\ No newline at end of file
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-04-24
summary: A review and discussion of open PRs, moving forward with Ring CT
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
*April 24th, 2016*
# Logs
**\<hyc>** hey what's on our agenda for today anyway
**\<hyc>** slideshow from fluffypony's trip to Asia?
**\<dEBRUYNE>** we could do that :D
**\<dEBRUYNE>** hyc: More seriously, I suppose some Ring CT stuff + something about the performance branch
**\<fluffypony>** lol
**\<dEBRUYNE>** hyc: Plus I think there are still some PRs open for review
**\<hyc>** sounds good. looking at NobleSir's DB schema, doesn't seem like there's much new needed on the DB side of things
**\<dEBRUYNE>** hyc, fluffypony: I could make a list of which PRs are still open for review if you want?
**\<hyc>** 13 open right now
**\<dEBRUYNE>** all right
**\<hyc>** moneromooo already reviewed PR#806
**\<dEBRUYNE>** Oh yeah this is easier to spot ->
**\<dEBRUYNE>** :-P
**\<hyc>** yep
**\<dEBRUYNE>** smooth and moneromooo had a little chat about 818 & 819 earlier today
**\<hyc>** I've browsed thru them but frankly don't know enough about how things work to know their implications
**\<moneromooo>** I felt like that abour your/warp's DB perf branch :P
**\<hyc>** ;)
**\<hyc>** looking at git history I'd guess tewinget or NoodleDoodle would have breezed thru them
**\<fluffypony>** hokay
**\<fluffypony>** t -1 hour
**\<dEBRUYNE>** t -5 min
**\<ArticMine>** hello
**\<JonathanD_>** hi
**\<hyc>** hola
**\<smooth>** bonjour
**\<xmrpromotions>** bonjour
**\<fluffypony>** Comment allez-vous ?
**\<fluffypony>** la réunion d'aujourd'hui aura lieu en français
**\<bigreddmachine>** laissez les bon temps rouler
**\<fluffypony>** lol
**\<xmrpromotions>** Konnichiwa
**\<fluffypony>** ok so
**\<fluffypony>** welcome to the dev meeting
**\<fluffypony>** after a brief intermission we're back on every 2 weeks
**\<luigi1112>** I'm here but not really
**\<fluffypony>** I've been trying to keep up whilst travelling, but there's some backlog I didn't read
**\<fluffypony>** I think before we discuss #805 and the performance PR, let's just touch base on the smaller ones
**\<fluffypony>** #810, #814, #818, all seem to have been reviewed and are ready for merge
**\<moneromooo>** smooth had reservations about 810.
**\<moneromooo>** Or hyc. Or both.
**\<fluffypony>** smooth / hyc: any new thoughts beyond the one comment on the PR?
**\<hyc>** both I think, but I don't remember smooth's comments
**\<moneromooo>** I think it was just extra complexity htat might not be worth it.
**\<hyc>** my point - the current pool code calls getblocktemplate 1/second but doesn't do anything with the response if the height is the same as before
**\<hyc>** the pool code ought to just call getblockcount in that case, which executes in 0ms
**\<dEBRUYNE>** smooth commented on #810 ->
**\* DaveyJones**: quotes deBRUYNE from yesterday : dEBRUYNE pages othe, NoodleDoodle, smooth, tewinget, binaryFate
**\<fluffypony>** so then the pool code is bad, right ?
**\<hyc>** yeah, in my perspective anyway
**\<xmrpromotions>** No comment on the code for but is there some way we can reach out to the family of warptangent to let them know we are very greatful for his contributions?
**\<smooth>** i added a comment to 810
**\<dEBRUYNE>** ^ His dad commented in the thread
**\<fluffypony>** xmrpromotions: they're already speaking to us, and we've let them know
**\<dEBRUYNE>** but let's stick to -dev decisions for now
**\<smooth>** 818 i think needs review by a cryptographer before we release that feature
**\<fluffypony>** agreed
**\<smooth>** hyc> the pool code ought to just call getblockcount in that case <= this is incorrect as we discussed before, but not relevant to 810
**\<moneromooo>** getinfo returns top hash.
**\<moneromooo>** And seems fairly lightweight.
**\<smooth>** it should check the top block hash, not height, but in any case even calling getblocktemplate 1/second isn't obvious to me would be a performance issue at all
**\<moneromooo>** Maybe PCFiL can test. He reported high CPU use when there were like 15 txes in the pool, and calming down at ~3.
**\<moneromooo>** Or I could test it actually, just curl that URI.
**\<smooth>** maybe we should look at why it takes so long then. when happens when there are 500?
**\<hyc>** fair enough, re: getinfo. still, it seems like this cache should be unnecessary
**\<fluffypony>** we can pack a bunch of transactions into testnet's mempool to see
**\<smooth>** next topic?
**\<hyc>** sounds like a good plan. perf optimizations should always have before/after metrics.
**\<fluffypony>** 811 / 812 / 813, any thoughts or objections on them ?
**\<hyc>** 811 seems pretty straightforward
**\<hyc>** tho moneromooo mentioned that the test in question never actually gets run
**\<hyc>** anyway, compiling unit tests is broken without it, so 811 needs to go in
**\<fluffypony>** ok
**\<fluffypony>** 812 seems fine too
**\<smooth>** those all look fine, noting that the net code is a complete black box to me so i can't really have an opinion there
**\<fluffypony>** ok - has anyone tested 815?
**\<moneromooo>** Well, I did :)
**\<fluffypony>** lol
**\<fluffypony>** 816 is also pretty straightforward
**\<fluffypony>** I'll review 817 later when I'm merging
**\<fluffypony>** and 819 is obvious
**\<moneromooo>** 818 won't apply once 816 is merged (duplicate -8 new error code), I'll update once this is done.
**\<hyc>** yeah 816 looks fine
**\<fluffypony>** I wouldn't bother yet - wait until there's been an MRL review on 818, moneromooo
**\<moneromooo>** OK
**\<fluffypony>** 810 I'll hold off on and let it bounce around, final decision at the next meeting if not before
**\<fluffypony>** ok so 806, the PR that fixes issue 805 - any final thoughts on it or can I merge?
**\<hyc>** works for me ;)
**\<moneromooo>** Seems fine. I didn' try it though.
**\<hyc>** it will make starting up a new wallet less painful for new users
**\<fluffypony>** oh and then unwind, I forgot about that - moneromooo you commented today that you're going to do some more work on that, do you want to merge and then submit further PRs for improvement, or work off that PR?
**\<moneromooo>** Leave it out for now.
**\<fluffypony>** k
**\<fluffypony>** so then performance
**\<fluffypony>** are we going to merge it, or leave it for 0.10.0 ?
**\<hyc>** conclusion - migrating DB schema in-place is much slower than just export/reimport from scratch
**\<fluffypony>** hyc: yeah I know, the conversion tool was always horrendously slow by comparison
**\<smooth>** im not sure that invalidates it
**\<fluffypony>** but in-place migration has its place
**\<fluffypony>** eg. when running as a service
**\<smooth>** easy of use matters, and if advanced users want to do it faster they can use th etools
**\<fluffypony>** agreed
**\<smooth>** sync from scratch is an option too, if they dont care about bandwidth
**\<fluffypony>** I guess the overriding factor here is that we suck at communicating with the end users that are running nodes
**\<fluffypony>** the fork taught me that, at any rate, so we have to assume people won't be reading release notes
**\<hyc>** ok. but are they going to notice that their newly restarted server isn't talking to anyone on the network for 1+ hour?
**\<fluffypony>** I don't think they'll care if it's an unattended server
**\<fluffypony>** we do need a way to universally respond to RPC calls with an error that explains that it's busy and this is the conversion % or something
**\<hyc>** ok
**\<gingeropolous>** i guess the use case to consider is shapeshift
**\<fluffypony>** yeah
**\<moneromooo>** RPC calls that care about this do return busy.
**\<moneromooo>** If not, file a bug with details.
**\<fluffypony>** moneromooo: a conversion will lock almost everything out, though ?
**\<fluffypony>** except I guess blindly broadcasting transactions
**\<moneromooo>** Oh, nevermind.
**\<smooth>** even then it probably has to verify them
**\<fluffypony>** yeah so I think the entire RPC interface has to error with a status
**\<moneromooo>** I'm guessing the RPC server will not be up yet if it's converting the db.
**\<hyc>** yeah, the conversion is firing up from db open
**\<hyc>** I don't think anything else is up yet
**\<fluffypony>** ah point
**\<smooth>** whats the problem with refusing to start until they do something with their db?
**\<smooth>** i mean error out at startup, no conversion
**\<smooth>** you can either delete/rename it (and therefore resync) or convert it
**\<fluffypony>** smooth: because in background mode / windows service mode you won't know that it's dying
**\<smooth>** you'll know its not working, there must be some way to indicate a reason
**\<fluffypony>** so practically: I have Bitcoin and Monero on a Windows node
**\<smooth>** maybe leave a message file behind and the cli can report the message
**\<moneromooo>** system("xmessage \"help\"")
**\<fluffypony>** and at some point the Bitcoin DB got corrupted (multiple times)
**\<fluffypony>** I have the service set to restart on fail, and eventually restart the whole machine
**\<fluffypony>** so it was restarting the machine every 15 minutes, and since I was only using the Monero node on it I had no idea
**\<gingeropolous>** right, so the overarching question is monero's philosophy on un-managed nodes
**\<gingeropolous>** (perhaps)
**\<hyc>** if truly no one is monitoring, then the daemon can do its conversion in however many hours it takes and no one will be bothered
**\<hyc>** if anyone is doing a health check they're gonig to wonder why it's not responding
**\<hyc>** Aside from that I'd feel more comfortable if someone besides me has tested the current branch with migration happening