Merge pull request #114 from dEBRUYNE-1/master

Dev logs for 2016-04-24 (fifth dev meeting) and 2016-03-19 (fourth dev meeting)

_posts/2016-03-19-overview-and-logs-for-the-dev-meeting-held-on-2016-03-19

@@ -0,0 +1,341 @@
+---
+layout: post
+title: Overview and Logs for the Dev Meeting Held on 2016-03-19
+summary: Few PRs were discussed, GUI commit(s), app/add-on infrastructure, version structure
+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 forum.getmonero.org
+**\<dEBRUYNE>** ^ https//forum.getmonero.org/5/support//building-monero-v0-9-2-on-winMonero
+**\<@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 xmr.to 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 xmr.to team could talk more about xmr.to integration at MiniNero that would be great.... also are 2 way conversions coming to xmr.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//imgur.com/a/HZL7k
+**\<binaryFate>** iam6yearsold for MiniNero integration you'd have to see with NobleSir. The API doc is at http//xmrto-api.readthedocs.org/en/latest/
+**\<@fluffypony>** but I guess we could have "plugins", of a sort, that add functionality
+**\<@fluffypony>** like xmr.to 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 xmr.to 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 downloads...so "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 it!@
+**\<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//en.wikipedia.org/wiki/Don%t_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//lists.linuxfoundation.org/pipermail/bitcoin-dev/-December/71.html
+**\<@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 0.9.2.1
+**\<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//github.com/monero-project/research-lab/tree/master/publications/MRL-%-%Difficulty%Adjustment%Algorithms%in%Cryptocurrency%Protocols
+**\<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

_posts/2016-04-24-overview-and-logs-for-the-dev-meeting-held-on-2016-04-24

@@ -0,0 +1,219 @@
+---
+layout: post
+title: Overview and Logs for the Dev Meeting Held on 2016-04-24
+summary: Mainly discussion of open PRs and bit of 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 -> https://github.com/monero-project/bitmonero/pulls
+**\<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 -> https://github.com/monero-project/bitmonero/pull/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 https://github.com/monero-project/bitmonero/pull/794 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
+[2016-04-24T18:11:12+0200] <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
+**\<@fluffypony>** I will
+**\<hyc>** we know the perf code itself, not counting the migrate bit, is working fine
+**\<@fluffypony>** hyc: if I start it up with a current blockchain it'll just convert, right?
+**\<hyc>** yep
+**\<@fluffypony>** ok I'll give it a spin on a few devices
+**\<@fluffypony>** so then I guess the final question is whether this goes into 0.9.x or 0.10.0 ?
+**\<othe>** perf code itself i run on multiple nodes, from 32 bit arm to 64bit x86 - works absolutely flaweless here
+**\<gingeropolous>** peanut gallery here - makes more sense to call it 0.9.x . big number change seems appropriate for consensus mechanism changes (i.e., ringct)
+**\<bigreddmachine>** yeah i agree with gingeropolous in general... iterate the version on huge changes, subversion on consensus changes, and point on small changes that don't break consensus.
+**\<@fluffypony>** gingeropolous: I don't disagree, I'm also leaning towards it being a point release
+**\<ArticMine>** Also if there is down time for the nodes during conversion a more gradual approach in 0.9.x is preferable
+**\<bigreddmachine>** that maintains the idea that all 0.9.x are compatible, and not compatible for 0.10.x
+**\<@fluffypony>** well with a 0.9.x release everyone won't update at once
+**\<hyc>** well, they're compatible on the wire, at least
+**\<bigreddmachine>** and that's what matters in the long run... say 2-3 years from now there are lots of companies with various implementations and such, like in Bitcoin. a switch to 0.10.x indicates to them "get your stuff together or be left behind"
+**\<@fluffypony>** yeah
+**\<bigreddmachine>** so might as well use that precedence earlier rather than later.
+**\<@fluffypony>** ok I think that's it from my side - does anyone have anything they want to ask / add / discuss ?
+**\<smooth>** i think anything with a conversion process like that should be branded as a major/semi-major upgrade, especially since you can't easily downgrade
+**\<dEBRUYNE>** perhaps a bit about ring CT? Though hyc kind of already said something about that before the discussion
+**\<dEBRUYNE>** more specifically -> \<hyc> sounds good. looking at NobleSir's DB schema, doesn't seem like there's much new needed on the DB side of things
+**\<@fluffypony>** smooth: can definitely make that clear in the release
+**\<dEBRUYNE>** oh and fluffypony, perhaps a bit about the 0MQ stuff as well?
+**\<@fluffypony>** hyc is better suited to update us on RingCT
+**\<smooth>** 0mq is kind of a big issue i think, maybe leave for the next meeting
+**\<xmrpromotions>** Is omq the only/primary reason why work is still being done on master instead of dev branch?
+**\<smooth>** thats part of the whole issue of how the repo is organized and the workflow
+**\<@fluffypony>** yeah I think that's a discussion we can have at the next meeting
+**\<hyc>** sorry I've got very little intelligent to say about ringct
+**\<hyc>** i've compiled the code and run the test successfully
+**\<hyc>** but I don't really think i'm in position to merge it, don't understand the pieces
+**\<moneromooo>** I'm better acquainted with monero in general, though less with the db side.
+**\<moneromooo>** And IANAC.
+**\<@fluffypony>** you are not a cat ?
+**\<@fluffypony>** obviously, you're a moo!
+**\<moneromooo>** That is true.
+**\<moneromooo>** Maybe we can get riddick on the job.
+**\<@fluffypony>** that's riddick-ulous
+**\<moneromooo>** OK then. No cats.
+**\<moneromooo>** Thing is, I'm wary of starting a large piece of work these days, as I don't have as much free time as I used to.
+**\<dEBRUYNE_>** hyc, moneromooo: Perhaps the two of you could collaborate with NobleSir on it
+**\<bigreddmachine>** Once the meeting is adjourned, can i hijack everyone/someone's attention for 2 mins to ask a question? it's not an official dev question, but still related i guess.
+**\<othe>** just throw it out
+**\<xmrpromotions>** can I ask about multi sig? Am I right that ring ct will be a prerequisit for it? I ask because it sounds like it will be needed for bitsquare (at least to be used as intended)
+**\<othe>** no ringct is no prerequesite for multisig
+**\<othe>** and no bitshares doesnt need it
+**\<othe>** bitsquare
+**\<@fluffypony>** lol bitshares
+**\<smooth>** notsquares
+**\<othe>** all they need is some gui changes like payment id support or alternatively its enough to use integrated addresses instead
+**\<othe>** and then they need support for the spendkey stuff to proof a payment, thats it
+**\<moneromooo>** Multisig happens as a byproduct of ringct withou much extra work though AIUI.
+**\<@fluffypony>** yeah
+**\<xmrpromotions>** ok thank you. maybe I read about dev priorities and misinterpreted a comment about ringct coming before multi sig
+**\<bigreddmachine>** Can I get someone's opinion on something? The "incoming_transfers" simplewallet method with "all" as the type returns a list of all transfers with in XMR coming into the wallet, including change from outgoing txs. For the wallet i've been working on, I have introduced a way to track outgoing transactions locally and store them using IndexedDB, since there’s not a good way to do that over rpc. I’d like
+**\<bigreddmachine>**  to present users with a "pseudo-ledger" so-to-speak that showed incoming txs and outgoing txs, and should add up to the balance for a wallet. Would it be correct/good/valid for me to check the returns from "incoming_transfers" to see if any tx_ids match those from the outgoing transfers database, and if they do match, don't display them? That would result in the displayed "incoming transfers" to only be
+**\<bigreddmachine>** transfers from another source.
+**\<moneromooo>** incoming_transfers shows the raw outputs. So you need to subtract those coming back from the ones leaving with the same txid.
+**\<moneromooo>** But I'll add RPC for the others in the near future.
+**\<binaryFate>** moneromooo can you be more explicit, what do you intend to add?
+**\<bigreddmachine>** Well, the data i record in the database is only the amount that leaves the wallet (it is ignorant of the fact that there is change leaving and coming back). Although, come to think of it, it also is ignorant of the fee paid... hmm, okay, i'll need to think on this more
+**\<moneromooo>** RPC for getting the same info that show_transfers displays.
+**\<binaryFate>** ok
+**\<bigreddmachine>** ^that would solve all my issues and i'd love you forever. in a manly way.
+**\<dEBRUYNE_>** othe: afaik Bitsquare needs it if you want XMR/fiat markets
+**\<othe>** altcoins are the fiat markets in bitsquares atm i think
+**\<bigreddmachine>** dEBRUYNE_: that's correct. but based on the interview on daily decrypt, i don't think he plans to have fiat markets other than BTC anytime soon. he kind of alluded to that.
+**\<bigreddmachine>** he said in the interview that if you wanted to trade an altcoin for fiat, you'd have to go through bitcoin because that's what has the best liquidity and what multisig is implemented in the market
+**\<othe>** correct