Monero Weekly Dev Meeting Notes – 2016-03-19
Logs
351 lines
dEBRUYNEdev meeting in 5 min, FYI
hycdingdong
gingeropoloushello
dEBRUYNEfluffypony, smooth, othe, ArticMine, luigiw, NoodleDoodle, tewinget, moneromooo
floofyponythere we go
dEBRUYNEdid I forget anyone?
tewingetoh, hello
luigiis warptangent around?
ArticMineHello
hyche's been fighting a flu last we heard
moneromooohi
NoodleDoodleHello. I'm here but I'm fighting the apocalypse.
NoodleDoodleof flus.
luigikeep doing it
luigiwait you're alive that's good to hear
dEBRUYNEfluffypony seems ded
fluffyponysorry
fluffyponywas eating
fluffyponywelcome everyone
fluffyponyso as you know we pushed out 0.9.2
fluffyponyhowever, there are some nagging issues from the ReadTXN work
fluffyponyhyc has nailed a major one as of a few hours ago
fluffyponyso we'll probably do a point release on Monday or so
fluffyponyalso that means that the way we use LMDB has changed a bit
fluffyponyhyc can you tell us briefly how we should wrapping access to LMDB, both read and write operations?
hycAre you talking about the CRITICAL_REGION stuff?
fluffyponyyes, and the cursors vs. txns stuff
hycok, the critical_region stuff actually is not a change at all.
hycbasically, when you're setting up to do a write, you need exclusive access to the DB
hycthis appears to have been a long-standing bug, unrelated to the readtxn changes
hycso as for reads - there is now a long-lived read txn per thread
hycand a set of read cursors to go with each
hycthe TXN_PREFIX_RDONLY macro sets that up in a particular function, grabbing the thread-local-storage for it
hycand RCURSOR(dbname) sets up a read cursor for a particular DB
hycthese are analogous to the CURSOR(dbname) macro for getting a write cursor to a DB
hycthe point of all this is to avoid a bunch of malloc/free/seek when accessing a DB
hycthe old code was allocating a readtxn and cursors inside each function
hyclikewise for writes
hycby reusing the same cursors acros a set oof functions we get a pretty good performance gain
hycok?
fluffyponyneat
fluffyponyalso on the topic of stuff-hyc-did-lately
fluffyponyif 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
fluffyponyso that should get us all on the same page with testing etc.
hycand one success story replied to it already ;)
fluffyponywe've also dropped support for BDB as the default database, and switched to LMDB as the default
fluffyponyincluding on -bit and ARM
fluffyponyBDB will remain supported for the moment, primarily as a mechanism for contributors to understand how to build out DB support
fluffyponykrongle)
fluffyponyshew we have the entire xmr.to team here today, that's awesome
binaryFatefluffypony good memory P
fluffyponywe shared a podcast together, binaryFate -P
krongleyes - impressive nick-name recollection
fluffyponyhah hah
fluffyponywhile we have you guys here, are you guys doing anything cool you want to talk about?
binaryFatewe're doing many cool things, but nothing we can talk about at this stage
fluffyponyhah hah
fluffyponyit does lead to an interesting point of conversation
binaryFateseriously considering btc -> xmr direction
fluffyponyplugins
iam6yearsoldIf 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?
fluffyponyiam6yearsold Shen's offline at the moment, I'll ask him to update the Reddit thread with some info )
fluffyponyre plugins, we've spoken briefly about options for the GUI
dEBRUYNEiam6yearsold There is a bit of info here -> https//imgur.com/a/HZL7k
binaryFateiam6yearsold for MiniNero integration you'd have to see with NobleSir. The API doc is at http//xmrto-api.readthedocs.org/en/latest/
fluffyponybut I guess we could have "plugins", of a sort, that add functionality
fluffyponylike xmr.to or shapeshift integration right in wallet2 / wallet2_api
dEBRUYNEI think we should be fairly strict on which plugins to allow
binaryFatefluffypony we wanted to discuss that plugin integration soon in fact )
arnuschkywe're quite interested to all secondary questions related to plugins
fluffyponyI guess the major question becomes
arnuschkyso plugin repository/db, packaging, distribution etc
fluffyponydo we allow "permissionless" plugin development, or do we just have a central repo that we git submodule in?
ArticMineThe main question I see with plugins is trust
fluffyponyArticMine exactly
arnuschkyyes. It puts quite a bit responsibility on the dev team
gingeropolouswell 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?
fluffyponyconsidering the recent Google Chrome Bitcoin stealing malware I think that premissionless plugins are dangerous
gingeropolousas we've seen with 3rd party GUIs
luigiyou obviously can't stop permissionless dev, you can discourage users from trusting it I guess
hycwe can start signing binaries, ohjoy
dEBRUYNEI would prefer the latter
fluffyponyluigi I mean permissionless within core
luigioh
luigiI think no
arnuschkyit'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
binaryFatefluffypony I'd see both possible all together. Unpermissioned scale and central repo for a selected subset would ease experience and trust for user
arnuschkyso if plugins are interpreted (eg python), things become a whole lot easier
iam6yearsoldfor the record I hated the twittter plugin idea I saw a while back
ArticMineMy take permissionless has to be allowed. The end user has to be made aware who is signing and if to trust the plugin
fluffyponywell the Electrum model works well
moneromoooI agree with ArticMine
arnuschky(inspection in case of central repo, but also self-distribution by plugin devs)
fluffyponyThomasV will merge basically any plugin, as long as it's not malicious
fluffyponyand plugins are part of the core code, effectively just in a subfolder
fluffyponyI think it's a testament to Electrum that they haven't had a malicious plugin ever
arnuschkyhow do they deal with the upgrade/maintenance workload? Or do they just disable broken plugins?
dEBRUYNEIs there a way to make a subfolder in the subfolder? i.e. (1) signed and approved by core-team, (2) optional
fluffyponyarnuschky yeah they just disable broken plugins, and eventually they get deprecated out
ArticMineWe should allow self distribution with appropriate warning
fluffyponyArticMine anyone can compile their own build, which would be the same thing
arnuschkyare you planning for compiled plugins or interpreted ones? that's quite a differens IMHO
fluffyponyarnuschky so
arnuschkyself-distribution is a mess for compiled ones…
fluffyponyI was thinking we have a repo, say it's called monero-plugins
arnuschkyaudit as well
fluffyponyand then anyone can PR to that repo
fluffyponyand that repo is pulled into the main Monero source as a git submodule
fluffyponythere are two advantages to this
fluffypony1. as it gets bigger and harder to deal with, we can step back and other known members of the community can manage that repo
fluffypony2. if we come up with a standard set of functionality hooks, then other projects can pull that same repo in
fluffyponyeg. jwinterm's lightwallet
fluffyponyalso it means that the compiled Monero binaries have those plugins baked in, and you can't add extra plugins post-compile
fluffyponyso no need to deal with interpreted code and securing that on disk and in memory
hycbaked 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
binaryFateSounds all good to us. If distribution is done through official channels it's great.
fluffyponyhyc yes
fluffyponyno dynamic loading
hyccool
fluffyponytewinget 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
arnuschkyfluffypony that would be really great.
fluffyponyok - I think next steps would be to consider some of the hooks we need to provide to add functionality
fluffyponywe can use the Monero wikia as a collaboration area for that
ArticMineIt is a good balance for plugins
fluffyponyand then we'll just update the Monero Slack
arnuschkywell securing the plugins can always happen by signature - no matter if interpreted or binary
fluffyponyI'm kidding, we don't have a Slack
fluffyponywe're not that cool
aerbaxWould these plugins allow for interpreted languages like Lua or Python?
arnuschky:)
fluffyponyaerbax I don't see why not, individual CMake files in each plugin folder that allow it to produce a library fix everything
binaryFateWe could financially support development of plugin architecture if xmr.to is the first instanciation of those plugins.
fluffyponyif it spits out a .so / .a / .dll with the right hooks then it's fine
tewingetfluffypony> 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
tewingetjust like any random site on the web can offer binaries for download and we can't secure that either
tewingetcaveat emptor has to come into play at some point, I think
fluffyponythe binaries present a single attack surface, and there's GPG-signed hashes
fluffyponyif we have to do GPG-signed hashes for a bunch of .py files I think I'll go mad -P
tewingetI'm not saying I think it should be one way or another, I'm merely pointing out flaws in your argument P
fluffyponyfair enough
fluffyponybinaryFate 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
ArticMineAs long as people can compile their own version with non permissioned plugins this can work
luigithey can always do that
fluffyponyyep
fluffyponyand in fact that would be the testing model
luigiwe're not apple )
fluffyponyfork the repo, and build a binary to test your new plugin
iam6yearsoldasking noobs to compile will limit adoption
ArticMineluigi Exactly
fluffyponyiam6yearsold why would noobs be writing their own plugins?
gingeropolousfor security
dEBRUYNElol gingeropolous
fluffyponylol
arnuschkyfluffypony championing the first plugin or the whole infrastructure?
tewingetWhat 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
fluffyponyarnuschky championing the design, I guess
arnuschkytewinget I would prefer that.
iam6yearsoldhow about 1 version with binaries and gpg sig and no plugins? caveat emptor for the rest
arnuschkymostly due to auditing, and there's no build/distribution mess attached
fluffyponyI would prefer we remain language agnostic
fluffyponyiam6yearsold that's what we already have
tewingetfluffypony language-agnostic is fine, but…well, how do you imagine that will work out?
iam6yearsoldthanks pony. I like the current situation then
fluffyponytewinget read up
arnuschkyah even language agnostic. I thought up to now it's supposed to be a C++ only API
tewingetas 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^^
smoothis here
fluffyponyalso what if a plugin wants to call a function in the core crypto library, for instance?
arnuschkydesign-wise, that's sounds like a nightmare, no?
moneromoooOh, so linked directly ? I kinda assumed it was gointg to be RPC based.
fluffyponyok well I think we're getting into an implementation discussion that's outside of the scope of this meeting
arnuschkyI mean, if you don't have a small and defined API, every bigger change in the wallet will break plugins
arnuschkytrue )
fluffyponyafter the dev meeting we can continue this conversation if you guys want
fluffyponybut let's first circle back around
luigithis deserves some kind of design thread like ringct imo
moneromoooOh, link ?
fluffyponymoneromooo: "this deserves"
fluffyponyso nothing yet
moneromooo"like ringct"
fluffyponyoh
fluffyponyI see what you were asking
luigioh
moneromoooOh
fluffyponyOH
luigi"like ringct is supposed to get"
moneromoooFair enough.
fluffyponyso basically this is all luigi's fault
luigiwarp was gonna go it!@
gingeropolousits true. i mis-called out luigi on that one
fluffyponywarptangent is off sick at the moment
luigiyes
luigiso I blame that
fluffyponyI blame Canada
fluffyponyok back on track
fluffyponysince the last meeting the bulk of the PRs have been bug fixes
fluffyponyand changes to the way we access the DB as discussed at the beginning
fluffyponywe also had a huge discussion about how to handle mixins below the minimum in the RPC call
fluffyponywhich was then implemented in #715
fluffyponyI'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
luigioh I was gonna do that
luigibut then I didn't
fluffyponyluigi we can do it together
luigiawwww
fluffyponyI can show you the world, shining shimmering splendid
gingeropoloustake you wonder by wonder
fluffyponylol
fluffyponyalso #728 was a little contentious
fluffyponyso we created a company called Mixinstream that has hired all the contributors
palexanderheh heh
fluffyponyand gingeropolous has launched Monero Classic
gingeropolous( sorry )
fluffypony-P
fluffyponyok so #728 is Ilya's work as part of the GUI effort
dEBRUYNECan I launch unlimited?
fluffyponyhe was struggling with wallet2, and decided to break it out into something more logical and usable
fluffypony(to him at any rate)
ArticMineWhat makes it contentious?
fluffyponyArticMine I'll get to that now
fluffyponyhe's unintuitively called it wallet2_api, which is a little confusing
fluffyponybut basically a lot of it is a wallet2_api call which then does little additional logic, and mainly just passes stuff back to wallet2
fluffyponyand there's a lot of DRY-violating code because of it
fluffyponyobviously there was some push back, not to prevent merging it
fluffyponybut more to understand the thought process
moneromoooDefine DRY ?
iam6yearsoldDRY violating scares the shit out of me
gingeropoloushttps//en.wikipedia.org/wiki/Don%t_repeat_yourself
gingeropolousmaybe
fluffyponyyes
fluffyponyiam6yearsold DRY violations are just where you have a piece of code in two places
fluffyponyso any changes have to happen in both
fluffyponywe can treat the DRY-violating code as a temporary issue, though
iam6yearsoldtwo places = more opportunity for error
fluffyponyas we're going to wait until Ilya is done with it
ArticMineWhich makes maintenance much harder
fluffyponyand then we'll either drop wallet2 and replace it with the new wallet API
fluffypony(ie. replace the simplewallet calls as well)
fluffyponyor if it's just a pointless layer we'll have to go the opposite route
fluffyponyand change his Qt callers to use wallet2
fluffyponyas it stands it's kinda undecided and we'll have to see how Ilya goes
ArticMineIs Ilya aware of the concern?
fluffyponyArticMine yes, we had some discussion on the PR, and othe has also spoken to him afaik
fluffyponyhe was responsive on the PR comments, but this isn't Bitcoin
fluffyponywe don't ACK NACK utACK for years before merging somethingm
fluffyponyaintnobodygottimeforthat.gif
luigiutNACK
fluffyponyluigi #networknerd
moneromoooutACK was not a typo ?
luigino
luigimeans untested
luigiconceptACK or similar
fluffyponyyeah
fluffyponymoneromooo https//lists.linuxfoundation.org/pipermail/bitcoin-dev/-December/71.html
fluffyponyif you're interested
hyccrap
fluffyponyLOL
fluffyponyPasteGate 2.0
gingeropolousinternets
otheur pasting skills suck
dEBRUYNEHahah
fluffyponyothe pasting is a scam
hycthat's how I write all my patches
fluffyponyI just copy-and-paste code from StackExchange
gingeropolousthats my job
fluffyponyheh
fluffyponyok so anyone who can reproduce the 0.9.2 segfault please try latest master
fluffyponyand if you're still segfaulting let us know
fluffyponyelse we're going to do a point release on Monday
fluffypony0.9.3, I guess?
luigihrm
fluffyponyor 0.9.2.1
luigiwe're gonna run out of numbers at this rate
fluffyponyyeah we are
luigioh wait
hyc0921
luigiwe have 0.10
luiginevermind
iam6yearsoldwill 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
fluffyponyyes we just do a Bitcoin
moneromoooNo chance, there's an infinity of those.
fluffypony0.11
fluffyponyiam6yearsold yes, and we've reached out to as many of them as we can
luigiis 0.10 supposed to be for next hard fork?
fluffyponyluigi fork that
fluffyponywhen warptangent is back we'll see how it goes on ringCT
fluffyponyand make a more concrete decision as to the timing of the next fork
dEBRUYNEiam6yearsold The hardfork will approximately take place at 13:00 UTC, so both US and Europe will probably be awake
dEBRUYNEand Asia of course
luigieveryone will be awake
fluffyponyeven me
dEBRUYNEhawaii will probably be asleep
dEBRUYNE-P
fluffyponyheh
dEBRUYNEfwiw!
luigiwat
Wolf`lol
smoothwe should also consider what else we should go in the next major version besides ringct (doesn't need to be discussed now)
dEBRUYNEuh I meant UTC btw
dEBRUYNEyou muricans with AM/PM
Wolf`who got drunk and posted about a party in #monero-dev
luigioh
luigithen america won't be up
moneromoooThe db reorg seems like a good candidate.
luigioh well
fluffyponysmooth agreed
dEBRUYNEeast coast will right?
luigisure ish
dEBRUYNEYou better set your alarm luigi
dEBRUYNE:-P
fluffyponySurae is also going to be picking up MRL-6 in the summer
fluffyponyhe has some ideas about how to complete that
dEBRUYNEMRL-6 is multisig?
iam6yearsoldI will party hard if fork happens with no drama
fluffyponydEBRUYNE: no
fluffyponyhttps//github.com/monero-project/research-lab/tree/master/publications/MRL-%-%Difficulty%Adjustment%Algorithms%in%Cryptocurrency%Protocols
dEBRUYNEoh cool, thanks
moneromoooHow do get cmake to tell you the commands it's running ?
luigiwe have diff, we have db stuff, we have fee stuff
fluffyponymoneromooo: I normally make VERBOSE=1
moneromoooThanks, I was trying V=1
luigiI like my V=2
fluffyponyok - any last things to add
fluffyponyor can we call it?
luigicall it
Sources and notes
- Meeting log: Overview and Logs for the Dev Meeting Held on 2016-03-19, getmonero.org. The official post carried the raw log and pointed readers to Hello Monero for the overview.
- Original Hello Monero URL slug recovered from the Wayback Machine index; the original page content did not survive, so this reconstruction carries the log as archived by the Monero Project.