monero-project/monero-site
monero-project/monero-site
1
0
Fork 0
mirror of https://github.com/monero-project/monero-site.git synced 2024-11-18 18:11:13 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge branch 'master' of ssh://github.com/monero-project/monero-site

Browse source
This commit is contained in:
antanst 2016-05-22 14:28:53 +03:00
commit d8db0fc7e8
8 changed files with 867 additions and 25 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
_data/downloads.yml
View file

@ -1,40 +1,40 @@
- platform: Windows, 64-bit
icon: windows.svg
url: win64
hash: 246115b0da133e0203dc78d26bbc82e9b76a178939bff8d4541bf04a02a19854
version: 0.9.3.0
hash: 9d939613c0eba872a3dacd7fda572f4c7d2279207ce1ec0b15b46da4e1ccd5b9
version: 0.9.4.0
tag: Hydrogen Helix
blockchain: win
- platform: Windows, 32-bit
icon: windows.svg
url: win32
hash: 4663222a810ad854da1fc9d665e51252e61ddb1a8f69de3a31ad195386d445a2
version: 0.9.3.0
hash: c9e4abc19c767ab570c2d0a9d504ba75d73eea26e7cf719a1260fdbb9469c250
version: 0.9.4.0
tag: Hydrogen Helix
blockchain: win
- platform: Mac OS X, 64-bit
icon: apple.svg
url: mac64
hash: f471a420485413d5fcb1b19065a3b4e9a68c49596ddd6291787ad34121bad32c
version: 0.9.3.0
hash: ded52162d34d5a726b53ffd14ebbf02388d9b396f3f4e278a4755e5286b1aeab
version: 0.9.4.0
tag: Hydrogen Helix
blockchain: mac
- platform: Linux, 64-bit
icon: linux.svg
url: linux64
hash: 9e6747b69642389e98ca5f70cec7276f7af7156e5dce95409a8da7cccff5876e
version: 0.9.3.0
hash: 0b3610c9b301ea14174ce700923a604909fa7cbd9335849112c9d6cfb07a1a43
version: 0.9.4.0
tag: Hydrogen Helix
blockchain: linux
- platform: Linux, 32-bit
icon: linux.svg
url: linux32
hash: 90c51c4a68f78ac2262a7b5a676f02d43ba7b9b6800b8b150d89980604c969f2
version: 0.9.3.0
hash: c070125bb885c5b887d3adce866e9bb941ed790485ef34444e62e0881fe8852a
version: 0.9.4.0
tag: Hydrogen Helix
blockchain: linux

2
_data/tags.yml
View file

@ -22,7 +22,7 @@
- slug: i2p
name: i2p
- slug: i2p
- slug: i8n
name: Internationalisation
- slug: rpc

342
_posts/2016-03-19-overview-and-logs-for-the-dev-meeting-held-on-2016-03-19.md Normal file
View file

@ -0,0 +1,342 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-03-19
summary: Open PRs, GUI commits, app/add-on infrastructure, versioning
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
---
*March 19th, 2016*
# Logs
**\<dEBRUYNE>** dev meeting in 5 min, FYI
**\<hyc>** dingdong
**\<gingeropolous>** hello
**\<dEBRUYNE>** fluffypony, smooth, othe, ArticMine, luigiw, NoodleDoodle, tewinget, moneromooo
**\<floofypony>** there we go
**\<dEBRUYNE>** did I forget anyone?
**\<tewinget>** oh, hello
**\<luigi>** is warptangent around?
**\<ArticMine>** Hello
**\<hyc>** he's been fighting a flu last we heard
**\<moneromooo>** hi
**\<NoodleDoodle>** Hello. I'm here but I'm fighting the apocalypse.
**\<NoodleDoodle>** of flus.
**\<luigi>** keep doing it
**\<luigi>** wait you're alive that's good to hear
**\<dEBRUYNE>** fluffypony seems ded
**\<fluffypony>** sorry
**\<fluffypony>** was eating
**\<fluffypony>** welcome everyone
**\<fluffypony>** so as you know we pushed out 0.9.2
**\<fluffypony>** however, there are some nagging issues from the ReadTXN work
**\<fluffypony>** hyc has nailed a major one as of a few hours ago
**\<fluffypony>** so we'll probably do a point release on Monday or so
**\<fluffypony>** also that means that the way we use LMDB has changed a bit
**\<fluffypony>** hyc can you tell us briefly how we should wrapping access to LMDB, both read and write operations?
**\<hyc>** Are you talking about the CRITICAL\_REGION stuff?
**\<fluffypony>** yes, and the cursors vs. txns stuff
**\<hyc>** ok, the critical\_region stuff actually is not a change at all.
**\<hyc>** basically, when you're setting up to do a write, you need exclusive access to the DB
**\<hyc>** this appears to have been a long-standing bug, unrelated to the readtxn changes
**\<hyc>** so as for reads - there is now a long-lived read txn per thread
**\<hyc>** and a set of read cursors to go with each
**\<hyc>** the TXN\_PREFIX\_RDONLY macro sets that up in a particular function, grabbing the thread-local-storage for it
**\<hyc>** and RCURSOR(dbname) sets up a read cursor for a particular DB
**\<hyc>** these are analogous to the CURSOR(dbname) macro for getting a write cursor to a DB
**\<hyc>** the point of all this is to avoid a bunch of malloc/free/seek when accessing a DB
**\<hyc>** the old code was allocating a readtxn and cursors inside each function
**\<hyc>** likewise for writes
**\<hyc>** by reusing the same cursors acros a set oof functions we get a pretty good performance gain
**\<hyc>** ok?
**\<fluffypony>** neat
**\<fluffypony>** also on the topic of stuff-hyc-did-lately
**\<fluffypony>** if anyone missed it, we now have a win environment guide up on 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

38
_posts/2016-04-02-monero-0.9.4-released.md Normal file
View file

@ -0,0 +1,38 @@
---
layout: post
title: Monero 0.9.4 Released
summary: A point release of Monero Hydrogen Helix containing important bug fixes
tags: [releases]
author: Riccardo Spagni (fluffypony)
---
*April 2nd, 2016*
## Summary of Changes
This has important bug fixes to 0.9.3 *Hydrogen Helix*
- Fix remaining issues with coinbase transactions
- Removed ```connectivity_tool```
- Switched to new Clang move diagnostics
- Added a new ```--generate-from-json``` flag to simplewallet to allow wallet creation from a JSON file
- Add a new and improved version of ```sweep_dust```
- Various bug fixes to handle failures such as map resize failures and bad simplewallet exits
## Official Download Links
- [Windows, 64-bit](https://downloads.getmonero.org/monero.win.x64.v0-9-4-0.zip)
- [Windows, 32-bit](https://downloads.getmonero.org/monero.win.x86.v0-9-4-0.zip)
- [OS X, 64-bit](https://downloads.getmonero.org/monero.mac.x64.v0-9-4-0.tar.bz2)
- [Linux, 64-bit](https://downloads.getmonero.org/monero.linux.x64.v0-9-4-0.tar.bz2)
- [Linux, 32-bit](https://downloads.getmonero.org/monero.linux.x86.v0-9-4-0.tar.bz2)
## Download Hashes
If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:
- monero.win.x64.v0-9-4-0.zip, a6f171c942a2b75432573c3cea6ca3becb10769a08eaaea5cca080c92b8ee297
- monero.win.x86.v0-9-4-0.zip, c9e4abc19c767ab570c2d0a9d504ba75d73eea26e7cf719a1260fdbb9469c250
- monero.linux.x64.v0-9-4-0.tar.bz2, 0b3610c9b301ea14174ce700923a604909fa7cbd9335849112c9d6cfb07a1a43
- monero.linux.x86.v0-9-4-0.tar.bz2, c070125bb885c5b887d3adce866e9bb941ed790485ef34444e62e0881fe8852a
- monero.mac.x64.v0-9-4-0.tar.bz2, ded52162d34d5a726b53ffd14ebbf02388d9b396f3f4e278a4755e5286b1aeab

219
_posts/2016-04-24-overview-and-logs-for-the-dev-meeting-held-on-2016-04-24.md Normal file
View file

@ -0,0 +1,219 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-04-24
summary: A review and discussion of open PRs, moving forward with Ring CT
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
---
*April 24th, 2016*
# Logs
**\<hyc>** hey what's on our agenda for today anyway
**\<hyc>** slideshow from fluffypony's trip to Asia?
**\<dEBRUYNE>** we could do that :D
**\<dEBRUYNE>** hyc: More seriously, I suppose some Ring CT stuff + something about the performance branch
**\<fluffypony>** lol
**\<dEBRUYNE>** hyc: Plus I think there are still some PRs open for review
**\<hyc>** sounds good. looking at NobleSir's DB schema, doesn't seem like there's much new needed on the DB side of things
**\<dEBRUYNE>** hyc, fluffypony: I could make a list of which PRs are still open for review if you want?
**\<hyc>** 13 open right now
**\<dEBRUYNE>** all right
**\<hyc>** moneromooo already reviewed PR#806
**\<dEBRUYNE>** Oh yeah this is easier to spot -> 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
**\<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

117
_posts/2016-05-08-logs-for-the-kovri-dev-meeting-held-on-2016-05-08.md Normal file
View file

@ -0,0 +1,117 @@
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2016-05-08
summary: Mac / BSD support moving forward
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*May 8th, 2016*
# Logs
**\<anonimal>** Hi fluffypony
**\<fluffypony>** hiiii
**\<fluffypony>** was just about to check if you're around :)
**\<anonimal>** Hi everyone, I think meeting-bot is still online
**\<fluffypony>** yes it is
**\<fluffypony>** coming through loud and clear on this side
**\* anonimal** reading backlog
**\<anonimal>** Hi moneromoo.
**\<anonimal>** Hi psi, uncrustify configs? Can you explain?
**\<psi>** uncrustify is a code styler for c/c++
**\<fluffypony>** I've never heard of it, plz tell me more psi?
**\<psi>** it auto formats the code
**\* psi** gets relevant links
**\<psi>** https://github.com/uncrustify/uncrustify
**\<anonimal>** I know that psi, but why for *.conf?
**\<psi>** i don;t understand?
**\<psi>** what about *.conf?
**\<fluffypony>** oh anonimal
**\<fluffypony>** not for *.conf
**\<fluffypony>** he means conf file for uncrustify matching our coding style
**\<psi>** damn lag
**\* psi** waits to catch up
**\<psi>** fluffypony: right
**\* anonimal** back
**\<fluffypony>** wb
**\<anonimal>** To answer the question, no I don't have an uncrustify config for kovri.
**\<anonimal>** Just a simple .vimrc.
**\<anonimal>** I can take a look at creating a config after #174 is resolved.
**\<anonimal>** fluffypony: I saw your comment in #56, what system are you runnning?
**\<fluffypony>** anonimal: Ubuntu 14.04
**\<fluffypony>** and there's no Boost 1.59 / 1.60 available
**\<fluffypony>** but that little hack worked
**\<anonimal>** 1.54 should work though
**\* anonimal** triple checks
**\<fluffypony>** I can't use 1.54
**\<fluffypony>** incompatible with Monero
**\<psi>** monero needs .56 or higher ?
**\<fluffypony>** .55 or higher
**\<psi>** kk
**\<fluffypony>** so basically .59 or higher if you want both
**\<anonimal>** I need about 5-15 minutes to build on bsd and osx so I can open the new linkage error tickets I talked about in #174
**\<fluffypony>** kk
**\<psi>** :\
**\* anonimal** the only time I have is now and a bit later but the meeting is now so I want to throw it into the topic
**\* anonimal** still compiling, should be done in 5 or so
**\<anonimal>** #monero-dev, FYI, our meetings have always been more organized, on-point, and I've almost always been prepared.
**\<anonimal>** This one caught me off guard.
**\<anonimal>** (last minute suggestion by fluffypony)
**\<anonimal>** Sorry for the wait.
**\<fluffypony>** don't stress, ours are always by the seat of our pants
**\* anonimal** opening tickets
**\<anonimal>** Hmf, I need to work with the bsd a bit more before posting.
**\<anonimal>** Anyway, https://github.com/monero-project/kovri/issues/175
**\<anonimal>** I'm only sitting with this again since I left off < 24 hours or so ago so,
**\<anonimal>** I haven't drawn any conclusions yet.
**\<anonimal>** Has anyone seen this before? #monero-dev?
**\* fluffypony** clicks
**\<fluffypony>** moneromooo: seen anything like that before ?
**\<fluffypony>** "Undefined symbols for architecture x86_64"
**\<anonimal>** The usual 'Undefined symbols for architecture x86_64' has been an osx complaint on this machine in the past.
**\<moneromooo>** Not as such. I've seen plenty of really annoying linking issues though.
**\<fluffypony>** this is gcc on OS X tho, right ?
**\<anonimal>** fluffypony: Yes.
**\<fluffypony>** maybe we're chasing our tails on that
**\<anonimal>** I don't have time to deal with clang. If we want multi-distro builds, I need to streamline our process.
**\<anonimal>** for macosx, clang won't build because it doesn't like the things I did for the reseed rewrite and,
**\<anonimal>** I don't have time to keep-up with llvm development.
**\<anonimal>** So, thoughts?
**\<fluffypony>** rewrite everything in C :-P
**\<anonimal>** lol
**\<fluffypony>** ok my suggestion is that we eschew OS X / BSD compatibility for the moment
**\<fluffypony>** until we can fix Clang support
**\<anonimal>** Thanks moneromoo. I'm glad this isn't just a kovri thing.
**\<fluffypony>** rather than trying to fudge it
**\<anonimal>** Well that's the problem, this won't be the only issue.
**\<fluffypony>** yeah I know
**\<anonimal>** And I'll end up wasting time juggling compilers instead of working on other things.
**\<fluffypony>** I mean that can be a later piece of work
**\<fluffypony>** let's focus on getting it working on one Linux and Windows, where we're running gcc and it's fine
**\<anonimal>** fluffypony: what part will be the later piece of work?
**\<fluffypony>** anonimal: fixing Clang incompatibilities
**\<moneromooo>** I don't use OSX btw, so kinda ignore what I said above.
**\<anonimal>** Ok sounds great, I'll focus on linux/win building.
**\<anonimal>** Should we remove osx/bsd build instructions from BUILDING.md?
**\<anonimal>** Or I'll just open the bsd ticket and maybe someone will see it?
**\<fluffypony>** yeah, I think let's make a note that it's broken on OS X / BSD for the moment, and that contributors are welcome to fix
**\<fluffypony>** kk
**\<anonimal>** Ok, I'll add the note.
**\<anonimal>** Any other questions/comments on #175?
**\<fluffypony>** no not yet
**\<fluffypony>** I mean no not atm, lol
**\<anonimal>** Ok, I'll add a note in #174 about what we discussed.
**\<anonimal>** And part 1) in #174, apparently there is an env variable I can set to get it to work.
**\<anonimal>** Not the first travis issue I've had to deal with.
**\<anonimal>** Oh well, they are growing quite nicely IMHO.
**\<fluffypony>** travis issues are growing quite nicely ?
**\<anonimal>** lol, yes, and I meant their project as a whole.
**\<fluffypony>** lol
**\<anonimal>** Ok, hour is up. Anything else pressing?
**\<fluffypony>** I don't think so - this was kinda an interim meeting because Kovri's was last week
**\<fluffypony>** so this brings them into line
**\<fluffypony>** next one on May 22nd, same time
**\<anonimal>** Ok, I'll mark the calendar.
**\<anonimal>** Thanks everyone.
**\<fluffypony>** thank you

127
_posts/2016-05-08-overview-and-logs-for-the-dev-meeting-held-on-2016-05-08.md Normal file
View file

@ -0,0 +1,127 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-05-08
summary: Clarification on ringCT next steps, 0MQ, discussion of open PRs
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
---
*May 8th, 2016*
# Logs
**\<fluffypony>** hyc, moneromooo, smooth, luigi1111w, luigi1112, luigi1114, ArticMine, NoodleDoodle, tewinget: meeting starting
**\<hyc>** hey
**\<fluffypony>** and othe
**\<fluffypony>** just waiting for the relay to come up
**\<fluffypony>** there we go
**\<luigi1112>** Not here
**\<fluffypony>** hello, and welcome to the 75th annual hunger games
**\<bigreddmachine>** crap, luigi1112's not here.
**\<fluffypony>** luigi1112 is literally a ghost
**\<fluffypony>** ok so we have a couple of PRs hanging around
**\<bigreddmachine>** is that why there are always 2-3 of him?
**\<fluffypony>** bigreddmachine: exactly :)
**\<luigi1112>** Hoooooo can say
**\<fluffypony>** I've reviewed #831 and it's ready for merge
**\<fluffypony>** same with 827
**\<fluffypony>** has anyone had further thoughts on 818 or are we ok with merging that functionality in its current form ?
**\<fluffypony>** bearing in mind that this will haunt us basically forever
**\<fluffypony>** and we pretty much can't change it ever again
**\<fluffypony>** no pressure or anything
**\<fluffypony>** (just kidding, we can definitely version it)
**\* fluffypony** waaaaaits
**\<hyc>** I haven't looked at 818, it's a crypto question still
**\<fluffypony>** yeah I think shen looked at it
**\<fluffypony>** ok we'll put a peg on that pending input from moneromooo and smooth
**\<ArticMine>** What are shen's thoughts on 818?
**\<MRL-Relay>** {-shen} I took a glance at it, but if desired I can look deeper
**\<MRL-Relay>** {-shen} at glance looked ok
**\<fluffypony>** shen: I think take a closer look if you can, given how we \*are\* stuck with it forever we may as well try get it right off the bat
**\<MRL-Relay>** {-shen} ok I will budget some time today or tomorrow
**\<fluffypony>** ok cool
**\<fluffypony>** then with the performance branch (794) we found an issue with the initial migration, messed up a global index on some txos
**\<luigi1112>** Is that the sig thing?
**\<fluffypony>** this appears to be fixed with the new / faster migration
**\<fluffypony>** luigi1112: yes
**\<luigi1112>** Ok
**\<fluffypony>** luigi1112: also I think if you have a second do you want to glance at the output format, maybe we need to give it a version prefix and a suffix of some sort
**\<fluffypony>** ok so performance is ready for merge, unless anyone has an objection
**\<hyc>** sounds good to me
**\<fluffypony>** then 810, I'm still unclear as to whether we're dropping that idea or we're merging it
**\<hyc>** given the increased locking requirements I'm against it.
**\<fluffypony>** ok
**\<hyc>** and as said before, I think fixing the pool code to use cheaper queries is better
**\<fluffypony>** I'm onboard with that
**\<fluffypony>** so now that we're getting the performance branch out the way
**\<fluffypony>** the next two major things on the radar are 0MQ and ringct
**\<fluffypony>** at the moment we have that stall in the dev branch, not sure whether it's time to nuke it and start the new one
**\<fluffypony>** I'll wait for input from moneromooo on that
**\<fluffypony>** and then ringct - hyc, did you say you were going to do some of that? I can't even remember
**\<hyc>** I looked into it but no, moneromooo should take lead
**\<fluffypony>** ok
**\<fluffypony>** shen
**\<hyc>** I can do whatever DB additions are needed
**\<fluffypony>** what's the status of your implementation code ?
**\<dEBRUYNE>** perhaps hyc can assist with the DB stuff
**\<dEBRUYNE>** oh he was quicker than me already
**\<MRL-Relay>** {-shen} Should be ready for test net at least
**\<fluffypony>** ok
**\<fluffypony>** it's time for a testnet fork anyway, so we can work towards that
**\<fluffypony>** basically everything else requires moneromooo and smooth, so we can put a peg in them till next meeting
**\<fluffypony>** speaking of which
**\<fluffypony>** next one on the 22nd
**\<dEBRUYNE>** perhaps they will show up within the next 30 minutes :-P Just page them 3 times!
**\<fluffypony>** hah hah
**\<dEBRUYNE>** Btw fluffypony, will the performance branch be used for a new point release?
**\<fluffypony>** dEBRUYNE: yes
**\<dEBRUYNE>** All right
**\<dEBRUYNE>** Btw, if moneromooo and smooth show up later tonight and have a chat about 0MQ we could just add that to the dev logs
**\<fluffypony>** ok
**\<bigreddmachine>** q: for the next point release... will it include arm7 binaries? 0.9.4 does not
**\<fluffypony>** it should
**\<bigreddmachine>** okay. unreleated, probably for hyc... you mentioned that simplewallet now only needs to sync ~30 MB instead of 3 GB with the new improvements. What was the savings? was there just a lot of data being shared that was unnecessary?
**\<luigi1112>** fluffypony: I'll think about that
**\<hyc>** bigreddmachine: sync of irrelevant blocks, only needed to use hashes
**\<bigreddmachine**> kk, thats what i figured
**\<bigreddmachine>** now just syncing block headers?
**\<hyc>** up to a given refresh height it only syncs hashes
**\<fluffypony>** moneromooo: we can carry on chatting about the bits you missed after the kovri meeting, if that's ok ?
**\<moneromooo>** Sure.
**\<fluffypony>** ok back to the Monero side
**\<fluffypony>** moneromooo: have you had a chance to read the meeting backlog ?
**\<moneromooo>** I did.
**\<fluffypony>** ok - thoughts on 0MQ / dev branch?
**\<fluffypony>** if you have the dev branch on your fork we can nuke it and reset
**\<moneromooo>** I think you can nuke the dev branch.
**\<moneromooo>** As for 0mq... whenever I get to start it, it's going to be a largeish amount of work at once I think.
**\<fluffypony>** ok
**\<moneromooo>** I happen to be not super motivated to code these days, after day job spent debugging stuff.
**\<fluffypony>** sometimes you gotta take a break and work on fun stuff
**\<dEBRUYNE>** perhaps Ring CT qualifies as fun stuff, perhaps not :-P
**\<moneromooo>** What's more important btw, 0mq or ringct ?
**\<fluffypony>** I would think ringct
**\<dEBRUYNE>** I'd say Ring CT too
**\<dEBRUYNE>** Iirc ring CT needs to be some time on testnet too anyway
**\<moneromooo>** And we can ask the "did nobody test this ?" peanut gallery in to test it :D
**\<fluffypony>** awesome
**\<moneromooo>** One other thing I wanted to do, which is interesting from a user's point of view, is to allow the wallet to see/decode pool txes.
**\<moneromooo>** That's probably not too much work.
**\<dEBRUYNE>** lol moneromooo
**\<dEBRUYNE>** Btw moneromooo, in case you hadn't read it yet hyc can assist you with the DB stuff
**\<dEBRUYNE>** More specifically -> \<hyc> I can do whatever DB additions are needed
**\<moneromooo>** I saw that. It's good so I don't break it all.
**\<dEBRUYNE>** Btw fluffypony, I forgot to ask earlier. Not sure if he is here, but any plans to opensource NoodleDoodle's trezor code soon^tm?
**\<fluffypony>** you'd have to ask NoodleDoodle that
**\<dEBRUYNE>** all right, perhaps he responds :-P
**\<moneromooo>** Oh: about reviewing the signature patch, IIRC smooth said that code was only used for the debug commands, so the CN people might not have make it so resistant to misuse or something. So might be worth looking at its internals (I expect it uses the same building blocks as ring signatures, but I don't really know).
**\<dEBRUYNE>** Also, regarding #810, a pool op commented the following: "Adding this to the current HEAD 8b0d22a reduces CPU by an order of magnitude on a pool wallet: 80% usage on a core down to 8%. Seems like a significant performance win to me." Since there is a mixed feeling about the PR itself I figured perhaps just close it and send the pool ops a mail that they could possibly apply the code/patch to their own code if they want to do so. I could
**\<dEBRUYNE>** gather email addresses and setup a standardized mail.
**\<dEBRUYNE>** ^ fluffypony
**\<moneromooo>** Changing the pool code to call getinfo and check top hash would also drop CPU usage a lot.
**\<fluffypony>** shen, see above ^^
**\<fluffypony>** (before the pool code stuff)
**\<MRL-Relay>** {-shen} ok
**\<MRL-Relay>** {-shen} good point
**\<dEBRUYNE>** moneromooo: I see, well then it's more up to the pool ops instead of the contributors/developers imo
**\<moneromooo>** Up to whoever gets his butt in gear to do it, as usual :D

27
downloads/hashes.txt
View file

@ -1,27 +1,26 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hash: SHA256
This GPG-signed message exists to confirm the SHA256 sums on Monero binaries.
Please verify the signature against the signature for fluffypony in the
source code repository (/utils/gpg_keys).
246115b0da133e0203dc78d26bbc82e9b76a178939bff8d4541bf04a02a19854 monero.win.x64.v0-9-3-0.zip
4663222a810ad854da1fc9d665e51252e61ddb1a8f69de3a31ad195386d445a2 monero.win.x86.v0-9-3-0.zip
f471a420485413d5fcb1b19065a3b4e9a68c49596ddd6291787ad34121bad32c monero.mac.x64.v0-9-3-0.tar.bz2
9e6747b69642389e98ca5f70cec7276f7af7156e5dce95409a8da7cccff5876e monero.linux.x64.v0-9-3-0.tar.bz2
90c51c4a68f78ac2262a7b5a676f02d43ba7b9b6800b8b150d89980604c969f2 monero.linux.x86.v0-9-3-0.tar.bz2
c312ba0810bf04ab2e28b61a50de2a83c1c614fd789bab4cacacb716134a7239 monero.linux.arm7.v0-9-3-0.tar.bz2
9d939613c0eba872a3dacd7fda572f4c7d2279207ce1ec0b15b46da4e1ccd5b9 monero.win.x64.v0-9-4-0.zip
c9e4abc19c767ab570c2d0a9d504ba75d73eea26e7cf719a1260fdbb9469c250 monero.win.x86.v0-9-4-0.zip
ded52162d34d5a726b53ffd14ebbf02388d9b396f3f4e278a4755e5286b1aeab monero.mac.x64.v0-9-4-0.tar.bz2
0b3610c9b301ea14174ce700923a604909fa7cbd9335849112c9d6cfb07a1a43 monero.linux.x64.v0-9-4-0.tar.bz2
c070125bb885c5b887d3adce866e9bb941ed790485ef34444e62e0881fe8852a monero.linux.x86.v0-9-4-0.tar.bz2
Riccardo "fluffypony" Spagni
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJW8UP6AAoJEFVDLfMczU/NYYIH/i46PXwNyt2ghnpslGXGrMhv
72ozR4OjdkNzl/z1PwcE2lAY8Z8od/OiZRB6zJl77555J+MxrP8rNa1i4fLRMAQn
5hIss+dhy6dRf+Tfgd6sZo6iXE5zmvgeOHgIfdtU6TRUC0ak0TRuFeQsTd8sXUCW
u6bIhRS2Bgo3C/Nj/o4k8zPUBjElc4XQyFFMqaM3PUuG8Ok/j0Nzyd+P0Av+jdfe
4SItOYH13V80ZnqEcp7QKeFKNYQVs7aGKzEMs/QNZvoscuiUA1RStkvwJ9pGfno/
F0cWnZSzGhYErIRldeQcTwJKIGtk1GcVnZLK1jkjlZeXq7MLtyKDblfctBfUmn8=
=MkuA
iQEcBAEBCAAGBQJXAqWrAAoJEFVDLfMczU/NVQQH/jbdEH8y2+M8f3ZTPVqU5rla
I7u0O4e9gVdZX+nfjjVx9ElUgzvrSbt1LN+LNX9/uY2T9udHrF3NmxamK9oqoE2x
6ZzS6qagXVL/REZfUZP8xduyKL3mXqrUs+WK3c9KdWWgViiJGcjqztayuVmd4ItH
wRYMIS7mi1c06j+BiFk9b4TfNhlDRjyVSnjt7iebvFxeGVWl02T/08RoW0oxmWy/
DfZBsQYmnDF+nQjrtW9IAJfpzLuXG7APV/rtKfTIqRNwl1bogvvdg/BRPR0QIC5J
vSH1cqP0DUjh4/CNmRlX6KdNe5c5Q6t+KcihK13jJfck4o18g1Ap5qxXAQ8tmCE=
=faLM
-----END PGP SIGNATURE-----