diff --git a/_posts/2016-03-19-overview-and-logs-for-the-dev-meeting-held-on-2016-03-19 b/_posts/2016-03-19-overview-and-logs-for-the-dev-meeting-held-on-2016-03-19 new file mode 100644 index 00000000..fb9a1b86 --- /dev/null +++ b/_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 + **\** 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 +**\<@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? +**\** Are you talking about the CRITICAL_REGION stuff? +**\<@fluffypony>** 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? +**\<@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 +**\** ^ 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. +**\** 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 +**\** fluffypony good memory P +**\<@fluffypony>** we shared a podcast together, binaryFate -P +**\** 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? +**\** 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 +**\** seriously considering btc -> xmr direction +**\<@fluffypony>** 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? +**\<@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 +**\** 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/ +**\<@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 +**\** 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 +**\<@fluffypony>** I guess the major question becomes +**\** 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? +**\** The main question I see with plugins is trust +**\<@fluffypony>** 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 +**\tewinget>** \ 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 +**\** 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 +**\<@fluffypony>** 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 +**\<@fluffypony>** well the Electrum model works well +**\** I agree with ArticMine +**\** (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 +**\** 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 +**\<@fluffypony>** arnuschky yeah they just disable broken plugins, and eventually they get deprecated out +**\** We should allow self distribution with appropriate warning +**\<@fluffypony>** 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 +**\<@fluffypony>** arnuschky so +**\** self-distribution is a mess for compiled ones... +**\<@fluffypony>** I was thinking we have a repo, say it's called monero-plugins +**\** 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 +**\** 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. +**\<@fluffypony>** hyc yes +**\<@fluffypony>** no dynamic loading +**\** 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 +**\** 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 +**\** It is a good balance for plugins +**\<@fluffypony>** and then we'll just update the Monero Slack +**\** 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 +**\** Would these plugins allow for interpreted languages like Lua or Python? +**\** :) +**\<@fluffypony>** 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. +**\<@fluffypony>** 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 +**\<@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 +**\** 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 +**\** As long as people can compile their own version with non permissioned plugins this can work +**\** they can always do that +**\<@fluffypony>** yep +**\<@fluffypony>** and in fact that would be the testing model +**\** we're not apple ) +**\<@fluffypony>** fork the repo, and build a binary to test your new plugin +**\** asking noobs to compile will limit adoption +**\** luigi Exactly +**\<@fluffypony>** iam6yearsold why would noobs be writing their own plugins? +**\** for security +**\** lol gingeropolous +**\<@fluffypony>** 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 +**\<@fluffypony>** 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 +**\<@fluffypony>** I would prefer we remain language agnostic +**\<@fluffypony>** 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 +**\<@fluffypony>** 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? +**\<@fluffypony>** [] / 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? +**\** design-wise, that's sounds like a nightmare, no? +**\** 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 +**\** I mean, if you don't have a small and defined API, every bigger change in the wallet will break plugins +**\** true ) +**\<@fluffypony>** after the dev meeting we can continue this conversation if you guys want +**\<@fluffypony>** but let's first circle back around +**\** this deserves some kind of design thread like ringct imo +**\** Oh, link ? +**\<@fluffypony>** moneromooo: "this deserves" +**\<@fluffypony>** so nothing yet +**\** "like ringct" +**\<@fluffypony>** oh +**\<@fluffypony>** I see what you were asking +**\** oh +**\** Oh +**\<@fluffypony>** OH +**\** "like ringct is supposed to get" +**\** Fair enough. +**\<@fluffypony>** so basically this is all luigi's fault +**\** warp was gonna go it!@ +**\** its true. i mis-called out luigi on that one +**\<@fluffypony>** warptangent is off sick at the moment +**\** yes +**\** 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 +**\** oh I was gonna do that +**\** but then I didn't +**\<@fluffypony>** luigi we can do it together +**\** awwww +**\<@fluffypony>** I can show you the world, shining shimmering splendid +**\** 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 +**\** heh heh +**\<@fluffypony>** and gingeropolous has launched Monero Classic +**\** ( sorry ) +**\<@fluffypony>** -P +**\<@fluffypony>** ok so #728 is Ilya's work as part of the GUI effort +**\** 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) +**\** 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 +**\** Define DRY ? +**\** DRY violating scares the shit out of me +**\** https//en.wikipedia.org/wiki/Don%t_repeat_yourself +**\ ** 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 +**\** two places = more opportunity for error +**\<@fluffypony>** as we're going to wait until Ilya is done with it +**\** 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 +**\** 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 +**\** utNACK +**\<@fluffypony>** luigi #networknerd +**\** utACK was not a typo ? +**\** no +**\** means untested +**\** conceptACK or similar +**\<@fluffypony>** yeah +**\<@fluffypony>** moneromooo https//lists.linuxfoundation.org/pipermail/bitcoin-dev/-December/71.html +**\<@fluffypony>** if you're interested +**\** crap +**\<@fluffypony>** LOL +**\<@fluffypony>** PasteGate 2.0 +**\** internets +**\** ur pasting skills suck +**\** Hahah +**\<@fluffypony>** othe pasting is a scam +**\** that's how I write all my patches +**\<@fluffypony>** I just copy-and-paste code from StackExchange +**\** 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? +**\** hrm +**\<@fluffypony>** or 0.9.2.1 +**\** we're gonna run out of numbers at this rate +**\<@fluffypony>** 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 +**\<@fluffypony>** yes we just do a Bitcoin +**\** 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 +**\** 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 +**\** 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 +**\<@fluffypony>** even me +**\** hawaii will probably be asleep +**\** -P +**\<@fluffypony>** 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 +**\<@fluffypony>** smooth agreed +**\** east coast will right? +**\** sure ish +**\** You better set your alarm luigi +**\** :-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 +**\** MRL-6 is multisig? +**\** 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 +**\** 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 +**\<@fluffypony**> moneromooo: I normally make VERBOSE=1 +**\** Thanks, I was trying V=1 +**\** I like my V=2 +**\<@fluffypony>** ok - any last things to add +**\** or can we call it? +**\** call it