--- 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 --- # Logs **\** dev meeting in 5 min, FYI **\** dingdong **\** hello **\** fluffypony, smooth, othe, ArticMine, luigiw, NoodleDoodle, tewinget, moneromooo **\** there we go **\** did I forget anyone? **\** oh, hello **\** is warptangent around? **\** Hello **\** he's been fighting a flu last we heard **\** hi **\** Hello. I'm here but I'm fighting the apocalypse. **\** of flus. **\** keep doing it **\** wait you're alive that's good to hear **\** fluffypony seems ded **\** sorry **\** was eating **\** welcome everyone **\** so as you know we pushed out 0.9.2 **\** however, there are some nagging issues from the ReadTXN work **\** hyc has nailed a major one as of a few hours ago **\** so we'll probably do a point release on Monday or so **\** also that means that the way we use LMDB has changed a bit **\** hyc can you tell us briefly how we should wrapping access to LMDB, both read and write operations? **\** Are you talking about the CRITICAL\_REGION stuff? **\** yes, and the cursors vs. txns stuff **\** ok, the critical\_region stuff actually is not a change at all. **\** basically, when you're setting up to do a write, you need exclusive access to the DB **\** this appears to have been a long-standing bug, unrelated to the readtxn changes **\** so as for reads - there is now a long-lived read txn per thread **\** and a set of read cursors to go with each **\** the TXN\_PREFIX\_RDONLY macro sets that up in a particular function, grabbing the thread-local-storage for it **\** and RCURSOR(dbname) sets up a read cursor for a particular DB **\** these are analogous to the CURSOR(dbname) macro for getting a write cursor to a DB **\** the point of all this is to avoid a bunch of malloc/free/seek when accessing a DB **\** the old code was allocating a readtxn and cursors inside each function **\** likewise for writes **\** by reusing the same cursors acros a set oof functions we get a pretty good performance gain **\** ok? **\** neat **\** also on the topic of stuff-hyc-did-lately **\** if anyone missed it, we now have a win environment guide up on forum.getmonero.org **\** ^ https//forum.getmonero.org/5/support//building-monero-v0-9-2-on-winMonero **\** so that should get us all on the same page with testing etc. **\** and one success story replied to it already ;) **\** we've also dropped support for BDB as the default database, and switched to LMDB as the default **\** including on -bit and ARM **\** BDB will remain supported for the moment, primarily as a mechanism for contributors to understand how to build out DB support **\** krongle) **\** shew we have the entire xmr.to team here today, that's awesome **\** fluffypony good memory P **\** we shared a podcast together, binaryFate -P **\** yes - impressive nick-name recollection **\** hah hah **\** while we have you guys here, are you guys doing anything cool you want to talk about? **\** we're doing many cool things, but nothing we can talk about at this stage **\** hah hah **\** it does lead to an interesting point of conversation **\** seriously considering btc -> xmr direction **\** plugins **\** 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? **\** iam6yearsold Shen's offline at the moment, I'll ask him to update the Reddit thread with some info ) **\** re plugins, we've spoken briefly about options for the GUI **\** iam6yearsold There is a bit of info here -> https//imgur.com/a/HZL7k **\** iam6yearsold for MiniNero integration you'd have to see with NobleSir. The API doc is at http//xmrto-api.readthedocs.org/en/latest/ **\** but I guess we could have "plugins", of a sort, that add functionality **\** like xmr.to or shapeshift integration right in wallet2 / wallet2\_api **\** I think we should be fairly strict on which plugins to allow **\** fluffypony we wanted to discuss that plugin integration soon in fact ) **\** we're quite interested to all secondary questions related to plugins **\** I guess the major question becomes **\** so plugin repository/db, packaging, distribution etc **\** do we allow "permissionless" plugin development, or do we just have a central repo that we git submodule in? **\** The main question I see with plugins is trust **\** ArticMine exactly **\** yes. It puts quite a bit responsibility on the dev team **\** well no ones going to trust anything that doesn;t come from core **\** \ we shared a podcast together, binaryFate -P <-- wasn't I there for that? **\** considering the recent Google Chrome Bitcoin stealing malware I think that premissionless plugins are dangerous **\** as we've seen with 3rd party GUIs **\** you obviously can't stop permissionless dev, you can discourage users from trusting it I guess **\** we can start signing binaries, ohjoy **\** I would prefer the latter **\** luigi I mean permissionless within core **\** oh **\** I think no **\** 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 **\** fluffypony I'd see both possible all together. Unpermissioned scale and central repo for a selected subset would ease experience and trust for user **\** so if plugins are interpreted (eg python), things become a whole lot easier **\** for the record I hated the twittter plugin idea I saw a while back **\** My take permissionless has to be allowed. The end user has to be made aware who is signing and if to trust the plugin **\** well the Electrum model works well **\** I agree with ArticMine **\** (inspection in case of central repo, but also self-distribution by plugin devs) **\** ThomasV will merge basically any plugin, as long as it's not malicious **\** and plugins are part of the core code, effectively just in a subfolder **\** I think it's a testament to Electrum that they haven't had a malicious plugin ever **\** how do they deal with the upgrade/maintenance workload? Or do they just disable broken plugins? **\** Is there a way to make a subfolder in the subfolder? i.e. (1) signed and approved by core-team, (2) optional **\** arnuschky yeah they just disable broken plugins, and eventually they get deprecated out **\** We should allow self distribution with appropriate warning **\** ArticMine anyone can compile their own build, which would be the same thing **\** are you planning for compiled plugins or interpreted ones? that's quite a differens IMHO **\** arnuschky so **\** self-distribution is a mess for compiled ones... **\** I was thinking we have a repo, say it's called monero-plugins **\** audit as well **\** and then anyone can PR to that repo **\** and that repo is pulled into the main Monero source as a git submodule **\** there are two advantages to this **\** 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 **\** 2. if we come up with a standard set of functionality hooks, then other projects can pull that same repo in **\** eg. jwinterm's lightwallet **\** also it means that the compiled Monero binaries have those plugins baked in, and you can't add extra plugins post-compile **\** so no need to deal with interpreted code and securing that on disk and in memory **\** baked in means no dynamic loading? **\** \ 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 **\** Sounds all good to us. If distribution is done through official channels it's great. **\** hyc yes **\** no dynamic loading **\** cool **\** 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 **\** fluffypony that would be really great. **\** ok - I think next steps would be to consider some of the hooks we need to provide to add functionality **\** we can use the Monero wikia as a collaboration area for that **\** It is a good balance for plugins **\** and then we'll just update the Monero Slack **\** well securing the plugins can always happen by signature - no matter if interpreted or binary **\** I'm kidding, we don't have a Slack **\** we're not that cool **\** Would these plugins allow for interpreted languages like Lua or Python? **\** :) **\** aerbax I don't see why not, individual CMake files in each plugin folder that allow it to produce a library fix everything **\** We could financially support development of plugin architecture if xmr.to is the first instanciation of those plugins. **\** if it spits out a .so / .a / .dll with the right hooks then it's fine **\** 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 **\** just like any random site on the web can offer binaries for download and we can't secure that either **\** caveat emptor has to come into play at some point, I think **\** the binaries present a single attack surface, and there's GPG-signed hashes **\** if we have to do GPG-signed hashes for a bunch of .py files I think I'll go mad -P **\** I'm not saying I think it should be one way or another, I'm merely pointing out flaws in your argument P **\** fair enough **\** 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 **\** As long as people can compile their own version with non permissioned plugins this can work **\** they can always do that **\** yep **\** and in fact that would be the testing model **\** we're not apple ) **\** fork the repo, and build a binary to test your new plugin **\** asking noobs to compile will limit adoption **\** luigi Exactly **\** iam6yearsold why would noobs be writing their own plugins? **\** for security **\** lol gingeropolous **\** lol **\** fluffypony championing the first plugin or the whole infrastructure? **\** 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 **\** arnuschky championing the design, I guess **\** tewinget I would prefer that. **\** how about 1 version with binaries and gpg sig and no plugins? caveat emptor for the rest **\** mostly due to auditing, and there's no build/distribution mess attached **\** I would prefer we remain language agnostic **\** iam6yearsold that's what we already have **\** fluffypony language-agnostic is fine, but...well, how do you imagine that will work out? **\** thanks pony. I like the current situation then **\** tewinget read up **\** ah even language agnostic. I thought up to now it's supposed to be a C++ only API **\** as in, how do we become language-agnostic so that we can remain so? **\** [] \ Would these plugins allow for interpreted languages like Lua or Python? **\** [] \ aerbax I don't see why not, individual CMake files in each plugin folder that allow it to produce a library fix everything **\** ^^ **\* smooth** is here **\** also what if a plugin wants to call a function in the core crypto library, for instance? **\** design-wise, that's sounds like a nightmare, no? **\** Oh, so linked directly ? I kinda assumed it was gointg to be RPC based. **\** ok well I think we're getting into an implementation discussion that's outside of the scope of this meeting **\** I mean, if you don't have a small and defined API, every bigger change in the wallet will break plugins **\** true ) **\** after the dev meeting we can continue this conversation if you guys want **\** but let's first circle back around **\** this deserves some kind of design thread like ringct imo **\** Oh, link ? **\** moneromooo: "this deserves" **\** so nothing yet **\** "like ringct" **\** oh **\** I see what you were asking **\** oh **\** Oh **\** OH **\** "like ringct is supposed to get" **\** Fair enough. **\** so basically this is all luigi's fault **\** warp was gonna go it!@ **\** its true. i mis-called out luigi on that one **\** warptangent is off sick at the moment **\** yes **\** so I blame that **\** I blame Canada **\** ok back on track **\** since the last meeting the bulk of the PRs have been bug fixes **\** and changes to the way we access the DB as discussed at the beginning **\** we also had a huge discussion about how to handle mixins below the minimum in the RPC call **\** which was then implemented in #715 **\** 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 **\** oh I was gonna do that **\** but then I didn't **\** luigi we can do it together **\** awwww **\** I can show you the world, shining shimmering splendid **\** take you wonder by wonder **\** lol **\** also #728 was a little contentious **\** so we created a company called Mixinstream that has hired all the contributors **\** heh heh **\** and gingeropolous has launched Monero Classic **\** ( sorry ) **\** -P **\** ok so #728 is Ilya's work as part of the GUI effort **\** Can I launch unlimited? **\** he was struggling with wallet2, and decided to break it out into something more logical and usable **\** (to him at any rate) **\** What makes it contentious? **\** ArticMine I'll get to that now **\** he's unintuitively called it wallet2\_api, which is a little confusing **\** 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 **\** and there's a lot of DRY-violating code because of it **\** obviously there was some push back, not to prevent merging it **\** but more to understand the thought process **\** Define DRY ? **\** DRY violating scares the shit out of me **\** https//en.wikipedia.org/wiki/Don%t\_repeat\_yourself **\** maybe **\** yes **\** iam6yearsold DRY violations are just where you have a piece of code in two places **\** so any changes have to happen in both **\** we can treat the DRY-violating code as a temporary issue, though **\** two places = more opportunity for error **\** as we're going to wait until Ilya is done with it **\** Which makes maintenance much harder **\** and then we'll either drop wallet2 and replace it with the new wallet API **\** (ie. replace the simplewallet calls as well) **\** or if it's just a pointless layer we'll have to go the opposite route **\** and change his Qt callers to use wallet2 **\** as it stands it's kinda undecided and we'll have to see how Ilya goes **\** Is Ilya aware of the concern? **\** ArticMine yes, we had some discussion on the PR, and othe has also spoken to him afaik **\** he was responsive on the PR comments, but this isn't Bitcoin **\** we don't ACK NACK utACK for years before merging somethingm **\** aintnobodygottimeforthat.gif **\** utNACK **\** luigi #networknerd **\** utACK was not a typo ? **\** no **\** means untested **\** conceptACK or similar **\** yeah **\** moneromooo https//lists.linuxfoundation.org/pipermail/bitcoin-dev/-December/71.html **\** if you're interested **\** crap **\** LOL **\** PasteGate 2.0 **\** internets **\** ur pasting skills suck **\** Hahah **\** othe pasting is a scam **\** that's how I write all my patches **\** I just copy-and-paste code from StackExchange **\** thats my job **\** heh **\** ok so anyone who can reproduce the 0.9.2 segfault please try latest master **\** and if you're still segfaulting let us know **\** else we're going to do a point release on Monday **\** 0.9.3, I guess? **\** hrm **\** or 0.9.2.1 **\** we're gonna run out of numbers at this rate **\** yeah we are **\** oh wait **\** 0921 **\** we have 0.10 **\** nevermind **\** 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 **\** yes we just do a Bitcoin **\** No chance, there's an infinity of those. **\** 0.11 **\** iam6yearsold yes, and we've reached out to as many of them as we can **\** is 0.10 supposed to be for next hard fork? **\** luigi fork that **\** when warptangent is back we'll see how it goes on ringCT **\** and make a more concrete decision as to the timing of the next fork **\** iam6yearsold The hardfork will approximately take place at 13:00 UTC, so both US and Europe will probably be awake **\** and Asia of course **\** everyone will be awake **\** even me **\** hawaii will probably be asleep **\** -P **\** heh **\** fwiw! **\** wat **\** lol **\** we should also consider what else we should go in the next major version besides ringct (doesn't need to be discussed now) **\** uh I meant UTC btw **\** you muricans with AM/PM **\** who got drunk and posted about a party in #monero-dev **\** oh **\** then america won't be up **\** The db reorg seems like a good candidate. **\** oh well **\** smooth agreed **\** east coast will right? **\** sure ish **\** You better set your alarm luigi **\** :-P **\** Surae is also going to be picking up MRL-6 in the summer **\** he has some ideas about how to complete that **\** MRL-6 is multisig? **\** I will party hard if fork happens with no drama **\** dEBRUYNE: no **\** https//github.com/monero-project/research-lab/tree/master/publications/MRL-%-%Difficulty%Adjustment%Algorithms%in%Cryptocurrency%Protocols **\** oh cool, thanks **\** How do get cmake to tell you the commands it's running ? **\** we have diff, we have db stuff, we have fee stuff **\ moneromooo: I normally make VERBOSE=1 **\** Thanks, I was trying V=1 **\** I like my V=2 **\** ok - any last things to add **\** or can we call it? **\** call it