Logs for the Kovri and Dev meetings held on 2017-07-23

_posts/2017-07-23-logs-for-the-Kovri-dev-meeting-held-on-2017-07-23.md

+---  
+layout: post  
+title: Logs for the Kovri Dev Meeting Held on 2017-07-23  
+summary: Brief review of what has been completed since last meeting, discussion of meta issues, and code & open tickets discussion  
+tags: [dev diaries, i2p, crypto]  
+author: dEBRUYNE / fluffypony  
+---  
+  
+*July 23th, 2017*  
+  
+# Logs  
+  
+**\<anonimal>** 1. Greetings  
+**\<anonimal>** 2. Brief review of what's been completed since the previous meeting  
+**\<anonimal>** 3. Contributor FFS check-in / status  
+**\<anonimal>** 4. Meta Issue #27 : Where should we officially host the IRC server?  
+**\<anonimal>** 5. Open Meta issue review https://github.com/monero-project/meta/issues  
+**\<anonimal>** 6. Code + ticket discussion / Q & A  
+**\<anonimal>** 7. Any additional meeting items  
+**\<anonimal>** 8. Confirm next meeting date/time  
+**\<anonimal>** SYN -\>  
+**\<MoroccanMalinois>** hi  
+**\<anonimal>** ACK \<-  
+**\<anonimal>** Hi :)  
+**\<sgp>** Hi!  
+**\<rehrar>** Hi hi  
+**\<anonimal>** Hi  
+**\<ajs>** Sub  
+**\<anonimal>** 2. Brief review of what's been completed since the previous meeting  
+**\<anonimal>** SSU fixes have been merged, testnet fixes/features, new Inno Setup windows installers!, bash installer update (for all platforms), repo + build fixes/work, doc updates, kovri-docs + kovri-site work, resolinvg kovri-site/#6 (joy),  
+**\<anonimal>** in addition to that (for me) PM collab work with rehrar on various issues. Did I miss anything?  
+**\<rehrar>** 2. Should we name anonimal Kount Kovri?  
+**\* anonimal** starts growing fangs  
+**\<anonimal>** Anything else on 2.?  
+**\<rehrar>** As for me, wife and I have been pouring lots of time into Kovri logo. We've got something new that's super cool (a new one you haven't seen yet anonimal) and I'm super excited to share it.  
+**\<rehrar>** But not yet. ;)  
+**\<anonimal>** Cool, I look forward to seeing it.  
+**\<anonimal>** Was it a development on what you and I worked on earlier?  
+**\<rehrar>** Also got my PGP key up to the repo, and am learning not to nuke website history  
+**\<rehrar>** No, this one is a brand new, fresh idea. But we're developing the other two as well and have a cool direction for both  
+**\<rehrar>** We'll show you guys soon when they're done and we can get opinions.  
+**\<anonimal>** Ok  
+**\<anonimal>** 3. Contributor FFS check-in / status  
+**\<MoroccanMalinois>** i've submited a summary for a milestone  
+**\<anonimal>** Link?  
+**\<MoroccanMalinois>** https://forum.getmonero.org/9/work-in-progress/87082/proposal-for-kovri-dev  
+**\<MoroccanMalinois>** sorry https://forum.getmonero.org/9/work-in-progress/87082/proposal-for-kovri-dev?page=&noscroll=1#post-91407  
+**\<anonimal>** Thanks  
+**\* anonimal** clicks  
+**\<anonimal>** Very nice MoroccanMalinois, congratulations :)  
+**\<MoroccanMalinois>** thanks :)  
+**\* anonimal** will comment in that post  
+**\<anonimal>** When can you start the next milestone (or have you already)?  
+**\<MoroccanMalinois>** already started, i have a bunch of commits that just needs some run tests  
+**\* MoroccanMalinois** should be full time on kovri for the next month  
+**\<anonimal>** Woo hoo!  
+**\<anonimal>** Sounds great :)  
+**\<MoroccanMalinois>** :)  
+**\<ajs>** :+1:  
+**\<rehrar>** Goodjob.jpg  
+**\<anonimal>** As for me on point 3., I'm at 94.151666666667 billable hours for this milestone but want to get more things resolved before submitting a summary for review.  
+**\<anonimal>** Everytime I want to sit down and work on a very specific area, I end up having X number of project responsibilities that take me away from the few things I want to work on for that milestone.  
+**\<anonimal>** *But* it's all needed, especially the testnet, so it all works out in the end.  
+**\<MoroccanMalinois>** That's exactly what i hated most when i had a company (with employees)  
+**\<anonimal>** Note: billable hours *doesn't* include the all the time at my machine when working on the project (most, but not all)  
+**\<anonimal>** MoroccanMalinois: I hear you!  
+**\<MoroccanMalinois>** :)  
+**\<anonimal>** MoroccanMalinois: any thoughts/ideas on how to streamline our productivity?  
+**\<anonimal>** We're the MEA now. We have MEAT tokens to take care of ;)  
+**\<MoroccanMalinois>** lol  
+**\* anonimal** oh wait, we should probably move that topic to the end of meeting, ajs is waiting  
+**\<MoroccanMalinois>** k  
+**\<anonimal>** Anything else on 3.?  
+**\<rehrar>** Nyet  
+**\<rehrar>** Нет  
+**\<anonimal>** 4. Meta Issue #27 : Where should we officially host the IRC server?  
+**\<rehrar>** It's Monero and Kovri right?  
+**\* moneromooo** listens  
+**\<anonimal>** This is tricky and requires auth from the core dev team. I don't think we have this written anywhere though we should.  
+**\<anonimal>** Whoever has the kovri privkeys to the irc server, rules the universe.  
+**\<ajs>** Got a test server up and running... Current open issues are here: https://github.com/alvinjoelsantos/ircxmr/issues  
+**\<ajs>** It would be best if one of the core members runs the server  
+**\<anonimal>** pigeons is running the i2p instance of getkovri, but I wonder if he's up for hosting an irc server too.  
+**\<moneromooo>** What are the reasons one might want to host the IRC server elsewhere ?  
+**\<anonimal>** To decentralize pigeons' workload/influence? I can't think of any others off the top of my head.  
+**\<anonimal>** I don't trust any VPS not owned/ran by/maintained by a monero person.  
+**\<anonimal>** \*core team or recommendation by core team  
+**\<moneromooo>** OK, I've found the reason in #27.  
+**\<moneromooo>** It's just the I2P part.  
+**\<pigeons1[m]>** I'm assuming an irc server connected only to irc2p wouldnt be a bad resources and maintenance load, unlike a public ircd  
+**\<anonimal>** lol oh yeah, I gave more reasons https://github.com/monero-project/meta/issues/27#issue-195122544  
+**\<anonimal>** pigeons1[m]: yes, I don't think it would be as bad on resources or maintenance compared to a public ircd  
+**\<anonimal>** I think permissions/jailing could be worked out so a 2nd person can ssh into the box to take care of the ircd instance if needed too.  
+**\<anonimal>** And of course exclude them from any access to the kovri/i2p privkeys  
+**\<pigeons1[m]>** Actually i heard from fluffy that the project is getting some infrastructure servers so we should be able to run that  
+**\<anonimal>** Awesome! Is there an ETA for those machines? Would we have to wait on those before setting up the official ircd instance?  
+**\<pigeons1[m]>** I dont know. Soon (tm)  
+**\<rehrar>** I too have an interest in the ETA of the infrastructure servers.  
+**\<anonimal>** Do we have machine space to start making something official now? pigeons1[m] would you even have the time to start setting that up with ajs?  
+**\<pigeons1[m]>** I'll start looking into with ajs  
+**\<anonimal>** Alright. ajs are you ok with that?  
+**\<ajs>** Okay. Should we go with domain irc.kovri.i2p?  
+**\<anonimal>** Yes, I believe I already registered that a long while ago. The keys are waiting to be used.  
+**\* anonimal** checks  
+**\<anonimal>** Yep.  
+**\<anonimal>** Once we're all settled on our end is when we'd give notice to #irc2p about our instance and then integrate with the rest of irc2p. Otherwise we would be running a lone irc server.  
+**\<ajs>** With relays?  
+**\<anonimal>** Huh?  
+**\<anonimal>** I don't understand the question.  
+**\<ajs>** To connect with Slack, bots  
+**\<ajs>** Or just run solo  
+**\<anonimal>** Oh, we wouldn't need to do anything about that because those are regular "users" who simply connect.  
+**\<rehrar>** We gun' be moving from Slack btw. It will die a horrible death that should please the OSS gods  
+**\<moneromooo>** Oooh, OSS gods. I'll fork my own and play.  
+**\<ajs>** Got it  
+**\<anonimal>** That's great news. They will be pleased.  
+**\<anonimal>** ajs: btw, https://github.com/alvinjoelsantos/ircxmr/blob/master/README.md says "freenet" but that is an actual project/technology. I think you meant "clearnet" instead.  
+**\<anonimal>** Anyway, we can chat more about that after the meeting.  
+**\<anonimal>** Anything else on 4. and the irc2p issue?  
+**\<ajs>** Oops will correct  
+**\<anonimal>** 5. Open Meta issue review https://github.com/monero-project/meta/issues  
+**\* anonimal** reads  
+**\<rehrar>** #70 is concerning  
+**\<anonimal>** https://github.com/monero-project/meta/issues/46 \<-- the July 27th date has now been officially rescheduled for August 17th  
+**\<anonimal>** 96boards had to reschedule our July 27th date. I got the email re: Aug 17th and it should be a packed show (at least 15 people on the call)  
+**\<anonimal>** So we'll monero it up there.  
+**\* anonimal** checks #70  
+**\<rehrar>** #43 is dependent on the new logo  
+**\<anonimal>** re: #70, rehrar what's concerning about it?  
+**\<rehrar>** Because I'll be putting a sort of "outreach" package together, and I'd like the new branding nailed down.  
+**\<rehrar>** That it's not closed. :P  
+**\<anonimal>** lol  
+**\<pigeons1[m]>** If anonimal types +resolved on a line by itself as a comment it will close in 10 minutes  
+**\<anonimal>** re: #43, ok, but we really don't need to wait for the logo to resolve #43.  
+**\<anonimal>** (re: #43, but I don't think anyone will jump at #43 until then anyway)  
+**\<moneromooo>** The +resolved bot is live now ?  
+**\<anonimal>** pigeons1[m]: yay, thanks pigeons  
+**\<rehrar>** Well, other people can Call for Developers too, obviously.  
+**\* anonimal** \+resolves moneromooo  
+**\<pigeons1[m]>** moneromooo: for the meta repo it is  
+**\<moneromooo>** I'm not try /close, nice try :P  
+**\<moneromooo>** Oh OK.  
+**\<anonimal>** This meta issuebot is nifty.  
+**\<rehrar>** Pigeons, am I right in assuming that the new servers mentioned before will also be used for the Taiga and MatterMost?  
+**\<pigeons1[m]>** Yes  
+**\<rehrar>** Here you go pigeons: https://imgur.com/gallery/hRHyYNh  
+**\<anonimal>** rehrar: I enjoyed those test instances of taiga + mattermost.  
+**\<pigeons1[m]>** :)  
+**\* anonimal** looks forward to going live  
+**\<rehrar>** I'm working on an action plan to talk with some local universities and their CS departments regarding Monero/Kovri and will be handing out information packets if I can talk with some professors.  
+**\<pigeons1[m]>** I would go over that with surae and surang who have a decent connection to acadamia  
+**\<rehrar>** Maybe even see if they wouldn't be willing to give college credit for a student contributing to the project in a measurable way. I remember when I was in college that professors were looking for opportunities like that in the field (though I was in Biology)  
+**\<rehrar>** I'll talk to them.  
+**\<rehrar>** It's shooting high, and may be improbable, but if you never ask you never know.  
+**\<moneromooo>** s/surang/sarang/  
+**\<rehrar>** You know what they say, shoot for the moon, if you miss you will be in the deep black void of space and die alone. :(  
+**\<rehrar>** Anyone know about opensource.com ?  
+**\<anonimal>** Whoever ends up doing that could also expand into non-CS depts. Monero for all (with a computer).  
+**\<rehrar>** They run articles every one in a while, and I was thinking about contacting them for maybe asking about what is needed for a Kovri article.  
+**\<rehrar>** I don't know how much clout it has, but if frequent OSS contributors look at it (or a similar site), then it may bring us to the attention of some potentially interested people.  
+**\<anonimal>** Media interaction is a probably a topic in it's own right. We're out of time though so let's move it to the next meeting or chat more after the meeting.  
+**\<rehrar>** Anyways, sorry, just some ideas I've been having regarding outreach to devs.  
+**\<anonimal>** Anything else on any open meta issues?  
+**\<anonimal>** 6. Code + ticket discussion / Q & A  
+**\<anonimal>** MoroccanMalinois and I do almost all code discussion outside of meetings. Anyone else on 6.?  
+**\<anonimal>** 7. Any additional meeting items  
+**\<rehrar>** No (Spanish for "no")  
+**\<anonimal>** Nothing from me since we're out of time. rehrar will you post your idea(s) into #43?  
+**\<rehrar>** Sure thing.  
+**\<anonimal>** Thank you. We can bring it up at next meeting too if needed (but that sounds like a future issue).  
+**\<anonimal>** 8. Confirm next meeting date/time  
+**\<anonimal>** August 6th, 18:00 UTC?  
+**\<anonimal>** (the ususal  
+**\<anonimal>** )  
+**\<rehrar>** Ye  
+**\<anonimal>** Alright, thanks everyone!  
+**\<anonimal>** And thanks dEBRUYNE for logging these meetings.  
\ No newline at end of file

_posts/2017-07-23-overview-and-logs-for-the-dev-meeting-held-on-2017-07-23.md

+---
+layout: post
+title: Overview and Logs for the Dev Meeting Held on 2017-07-23
+summary: Discussion of open PRs and issues, 0MQ, MyMonero/OpenMonero daemon integration, Surae's research, multisig, and miscellaneous
+tags: [dev diaries, core, crypto]
+author: dEBRUYNE / fluffypony
+---
+
+*July 23th, 2017*  
+
+# Overview  
+
+There is no overview for this week.  
+
+# Logs  
+
+**\<serhack>** Oh  
+**\<serhack>** Where is meeting? Here?  
+**\<pigeons1[m]>** Should be yea  
+**\<Jaquee>** anyone else noticed a memory leak in monerod from master?  
+**\<balambala>** Hello there  
+**\<moneromooo>** erikd did.  
+**\<serhack>** Jaquee: oh, is memory leak dangerous?  
+**\<moneromooo>** If you have hints, they're welcome.  
+**\<rehrar>** so...  
+**\<tewinget>** talkaboutdangedol...yo, man  
+**\<Jaquee>** no hints unfortunately.  got an OOM crash after running for an hour or two. could've been something else  
+**\<Jaquee>** i will find out soon enough  
+**\<rehrar>** fluffypony ArticMine luigi1111 othe luigi1114 moneromooo hyc anonimal tewinget pigeons Jaquee  
+**\<Jaquee>** did i hear meeting?  
+**\<Jaquee>** o/  
+**\<ArticMine>** Hi  
+**\<rbrunner>** Grüezi mitenand  
+**\<rehrar>** it seems fluffypony isn't here to run the meeting, or he's on his way. Anyone heard from him?  
+**\<tewinget>** negative  
+**\<rehrar>** well, I'm obviously not a dev, so I can't help with the conversation, but the agenda is here: https://github.com/monero-project/meta/issues/97 it's pretty normal  
+**\<vtnerd>** fluffypony is in las vegas according to his tweets  
+**\<rehrar>** right, he's at defcon  
+**\<rehrar>** probably gambling  
+**\<vtnerd>** or no wait, was a few days ago have kept up with that  
+**\<rehrar>** I'm obviously not qualified to facilitate the things in this meeting, but I can just put each item to discuss, unless someone wants to volunteer  
+**\* pero** volunteers moneromooo   
+**\<rehrar>** do it!  
+**\<tewinget>** I would, but I've tried and I'm shite at it \>\_\>  
+**\<tewinget>** pero: didn't you say you wouldn't be present for the meeting?  
+**\<vtnerd>** moneromooo is usually the backup bot  
+**\<pero>** yea but my plans changed  
+**\<moneromooo>** So.... ladies and gentlemen... let's start with...  
+**\<moneromooo>** tewinget  
+**\<moneromooo>** :)  
+**\<tewinget>** lol, ok  
+**\<moneromooo>** 0MQ's kinda ready now, right ?  
+**\<tewinget>** the daemon's rpc server stuff should be ready to merge, yes  
+**\<serhack>** Hello  
+**\<pero>** what's still outstanding if that's ready?  
+**\<tewinget>** it's not perfect, but "the great is the enemy of the good" and I've structured it such that it doesn't affect anything if something's wonky unless it's crashy...which I haven't seen any evidence of  
+**\<serhack>** Point 1? Greetings?  
+**\<moneromooo>** That's good. Can you put a "how to start monerod with 0MQ RPC" in the PR ?  
+**\<unknownids>** lol serhack  
+**\<tewinget>** I still need to do testing on the wallet modifications and the rpc client interface.  
+**\<tewinget>** moneromooo: if it builds, it runs the server :)  
+**\<tewinget>** the cli flags are self-explanatory  
+**\<moneromooo>** Ah, then "how to start monerod with original RPC" :)  
+**\<tewinget>** also the same  
+**\<tewinget>** hence it's fine to merge  
+**\<moneromooo>** It runs both at once ?  
+**\<tewinget>** yes.  
+**\<moneromooo>** Cool. OK.  
+**\<tewinget>** this is to avoid really really messy backwards compatibility  
+**\<tewinget>** later there may be a translation process that can receive old rpc requests and translate/forward them, but for now I think this is good.  
+**\<moneromooo>** And the missing bits and bobs are fixed (for example, random stuff in getinto) ?  
+**\<tewinget>** yeah, there's one thing I needed to get clarity on, but it's not a big deal  
+**\<moneromooo>** Shoot.  
+**\<tewinget>** that's the get peers bit, as you seemed to imply that this should be changed, but afaict I've mirrored the old/existing RPC in this and it hasn't changed.  I mean, I haven't implemented the call anyway, but the struct for the RPC message is what I'm talking about.  
+**\<tewinget>** may as well have that be what it should in case some intrepid young lad gets bored and wants to add that call.  
+**\<tewinget>** I've focused on the calls that the wallet uses for now, hence that one's been left for later.  
+**\<moneromooo>** Ah, peers used to be uint32\_t (IP) and uint16\_t (port) but they're not something (host) and uint16\_t (port).  
+**\<moneromooo>** OK, sounds good. The missing calls can be added later, that's fine.  
+**\<pero>** so wallet mods/client interface are largely done too?  
+**\<tewinget>** right, but if you look at the GET\_PEERS call in the old RPC it's still using uint32\_t IP and uint16\_t port, unchanged.  
+**\<tewinget>** pero: yeah, it's "done" but I found an issue with synching a testnet wallet around block 900k or so, so there's a bit of debugging to do  
+**\<tewinget>** but the code is in place, just needs testing.  
+**\<tewinget>** #2044 doesn't need *as* much testing before merge (just make sure it doesn't crash the daemon) because it only adds optional functionality, it doesn't change any existing functionality  
+**\<tewinget>** but #2185 needs more testing because I completely refactored how the wallet uses the RPC  
+**\<moneromooo>** OK, I will check the old GET\_PEERS.  
+**\<tewinget>** that's why I structured the PRs the way I did :)  
+**\<Jaquee>** there's some fuckery going on around 900k on testnet  
+**\<Jaquee>** lots of reorgs  
+**\<tewinget>** Jaquee: yeah, I noticed that, and one of the chunks of blocks during sync seemed to break things.  It'll take me a good bit of time to track it down because it's such a weird bug.  
+**\<tewinget>** what I really need to do is figure out how to configure gdb to actually print things...I hate it when shit's inlined so gdb can't print it.  or optimized out (I need to verify that debug builds are -O0)  
+**\<pero>** would zmq even be responsible for a sync-related bug?  
+**\<tewinget>** pero: no, the wallet on that branch bugs out in synching using the old RPC  
+**\<tewinget>** it's something related to my refactor of how it uses the rpc.  
+**\<pero>** gotcha  
+**\<sgp>** Any other questions or should we move on?  
+**\<tewinget>** oh  
+**\<pero>** yes i'd like to know what the next steps are here  
+**\<tewinget>** right  
+**\<pero>** i was alarmed to see that 10 days passed without zmq-related github activity  
+**\<tewinget>** so I think merging #2184 and then #2044 now would be good.  
+**\<tewinget>** #2185 will follow as soon as it's tested and working.  all the code is "done" just gotta test it.  
+**\<moneromooo>** Anyone wants to ask anything else about 0MQ ?  
+**\<moneromooo>** Next: Jaquee ?  
+**\<tewinget>** if anyone has questions in the future, just ask whenever  
+**\<Jaquee>** what?  
+**\<tewinget>** well, after the dev meeting.  carry on :)  
+**\<moneromooo>** Anything about the GUI or light wallet you want to talk about ?  
+**\<Jaquee>** ah =)  
+**\<pero>** does zmq have impact to the gui?  
+**\<tewinget>** pero: the refactor of how the wallet uses the rpc does  
+**\<Jaquee>** well. i've been working  on openmonero support the last days. making the wallet compatible with both mymonero and openmonero  
+**\<Jaquee>** there are a lot of new commits in the lightwallet PR  
+**\<pero>** thats outside of your scope too, i believe, tewinget  
+**\<Jaquee>** haven't squashed them yet  
+**\<moneromooo>** Yeah, all this reviewing is starting to kill me, there's a lot of stuff :D  
+**\<Jaquee>** understandable  
+**\<moneromooo>** Good stuff though.  
+**\<moneromooo>** Especially that lovely subaddress stuff...  
+**\<pero>** there will be a new gui release for september hardfork, Jaquee ?  
+**\<Jaquee>** the cli and gui releases are supposed to be aligned, so yes.  
+**\<tewinget>** remind me after the meeting, there's one other thing that we'll need to think about before merging #2044 but we can talk about it later.  
+**\<pero>** i am wondering if zmq making it into the cli codebase has been identified as work effort for the gui  
+**\<pero>** potential work effort*  
+**\<endogenic>** Hey guys, fluffy got caught by timezone difference. Think he may be slammed at the moment but he may pop in to say what's up. Just fyi  
+**\<pero>** and if some attention needs to be paid into that as the clock is ticking down  
+**\<endogenic>** Did not mean to interrupt you  
+**\<endogenic>** Pero  
+**\* tewinget** gives fluffypony some hair of the dog  
+**\<pero>** s'ok :)  
+**\<Jaquee>** i haven't really looked at tewingets new stuff, but afaik it shouldnt affect the gui that much.  
+**\<serhack>** Hey, I'm developing prestashop plugins  
+**\<Jaquee>** there are some rpc stuff in wallet api, but most of it arent used  
+**\<pero>** ok cool just putting it out there  
+**\<serhack>** I dont know if after that I will write another ffs  
+**\<tewinget>** I've refactored those bits as well :)  
+**\<Jaquee>** great =)  
+**\<moneromooo>** anything else, Jaquee ?  
+**\<Jaquee>** yes. but i guess i need fluffy to answer it  
+**\<Jaquee>** i was thinking about mobile release and testing  
+**\<moneromooo>** OK, we'll be back to you when/if he's around then ?  
+**\<Jaquee>** if someone is working on apple store and play store stuff  
+**\<Jaquee>** yes. i'll ping him  
+**\<moneromooo>** OK. Thanks.  
+**\<Jaquee>** ok. that's all  
+**\<moneromooo>** serhack: so, tell us more about what you're doing and what's your progress :)  
+**\<Jaquee>** oh. one more thing. sorry  
+**\<moneromooo>** Sure  
+**\<moneromooo>** one minute serhack please :)  
+**\<Jaquee>** vtnerd: what's the status on the openmonero/mymonero integration?  
+**\<Jaquee>** in monerod  
+**\<Jaquee>** do we have a plan for that?  
+**\<vtnerd>** not yet really  
+**\<Jaquee>** ok  
+**\<vtnerd>** other than I would like to have multiple processes for this for security purposes  
+**\<vtnerd>** which is what the backend is doing, but I need to make IPC between them easy  
+**\<Jaquee>** sounds like a good idea  
+**\<Jaquee>** iirc fluffy said in then january meetup that the backend was going to be open sourced. Any timeline for that?  
+**\<vtnerd>** not at all, that has not been my direct focus  
+**\<vtnerd>** I suppose whenever the backend is in better shape :/  
+**\<Jaquee>** all right. thanks =)  
+**\<Jaquee>** moneromooo: done  
+**\<vtnerd>** more recently I've been working on the serialization explosions  
+**\<Jaquee>** sounds fun  
+**\<Jaquee>** :P  
+**\<vtnerd>** so I'll have to make a push to start encoding a version in the archive header so we dont have this issue again  
+**\<moneromooo>** Would be nice to get them fixed, or at least ensure they're not exploitable, since cold wallet comms use that.  
+**\<vtnerd>** and try to convince the serialization author to merge something before the 1.65 release  
+**\<vtnerd>** eh, thats the issue I would to see corrected with serialization. I dont see another way to handle it  
+**\<vtnerd>** basically with better versioning in the header we get less bug defects, but crafting a file is problematic without changes within boost  
+**\<Jaquee>** i've missed this. what's the issue?  
+**\<moneromooo>** Crafting would likely not be defeated by versioning though.  
+**\<moneromooo>** Jaquee: a crash in boost loading a serialized file.  
+**\<vtnerd>** https://svn.boost.org/trac10/ticket/9370  
+**\<Jaquee>** ah. thanks  
+**\<vtnerd>** our situation is very similar, except its boost::multi\_index is doing it internally. a change by moo on 5/27 changed the serialization type  
+**\<vtnerd>** moneromooo : that sentence was worded similar. if you meant that its still possible to craft a file if we reject \_newer\_ versions, then I agree  
+**\<vtnerd>** \*worded strangely  
+**\<moneromooo>** I just meant a crafted file would claim whatever version leads to the exploit, which is likely whjayt you also meant.  
+**\<vtnerd>** right you can pretty much do whatever if you can modify the file being read  
+**\<moneromooo>** OK, we're done on this ?  
+**\<Jaquee>** yes  
+**\<moneromooo>** serhack: go ahead then, tell is about your plugins work :)  
+**\<vtnerd>** as far as mymonero goes, the focus is not yet open sourcing but since its on my mind during the refactor it shouldnt be hell  
+**\<vtnerd>** hopefully  
+**\<endogenic>** Vtnerd... a silent hero of monero...  
+**\<moneromooo>** Hmm, he seemed keen, but also seems not around now.  
+**\<moneromooo>** endogenic: do you have something you want to talk about ?  
+**\<endogenic>** Nah not as yet. Soon(tm)  
+**\<moneromooo>** Alright, thank you.  
+**\<sgp>** @serhack can always talk about it later, but I know he may want to discuss a way of covering plugin maintenance costs  
+**\<endogenic>** Really pleased about the lightwallet support  
+**\<moneromooo>** So, mooo now:  
+**\<Jaquee>** endogenic: is the mymonero backend issues holding back the mobile/desktop releases currently  
+**\<Jaquee>** that can wait. go moo  
+**\<endogenic>** Nah it's not  
+**\<Jaquee>** k  
+**\<moneromooo>** I worked on faster/leaner node sync (sync branch) as well as multisig (multisig2 branch right now)  
+**\<moneromooo>** Both welcome testing :)  
+**\<moneromooo>** multisig2 has RPC, but that's not been tested much yet, so don't really expect it to work. Wallet commands are what's ready.  
+**\<moneromooo>** Next... who could have somehting to say...  
+**\<moneromooo>** Anyone ?  
+**\<rbrunner>** I have something  
+**\<rbrunner>** Is something planned already about putting the Windows installer for the GUI wallet into service i.e. at the end offering the Setup.exe as a download on getmonero.org?  
+**\<moneromooo>** knaccc: kenshi84 ?  
+**\<Jaquee>** rbrunner: yes, most likely in next release  
+**\<rbrunner>** September then, right?  
+**\<Jaquee>** which will happen somewhere between now and hardfork  
+**\<Jaquee>** yes, around sept  
+**\<rbrunner>** Ok. I hold my breath :)  
+**\<Jaquee>** :D  
+**\<pero>** does the mooning network hash warrant any discussion  
+**\<moneromooo>** If you have something to say about it... sure.  
+**\<pero>** eh  
+**\<pero>** was hoping someone else might have some insight  
+**\<pero>** :)  
+**\<Jaquee>** i've noticed the block time has been pretty inconsistent lately  
+**\<Jaquee>** was thinking it was because the variance in hash  
+**\<Jaquee>** lot's of 5-10 mins gaps  
+**\<pero>** it seems to me that botnets could very well be pricing out 'regular' miners  
+**\<moneromooo>** As long as it's several distinct ones...  
+**\<pero>** right  
+**\<pero>** can we tell how centralized the mining is? real centralization could be obfuscated by pools  
+**\<sgp>** @pero ideally the discovered botnets can have the addresses searched in the pools to determine the hashrate  
+**\<moneromooo>** Pools might be able to tell, since they know source IPs (unless proxied). You'd have to trust the pools to tell you the truth though :)  
+**\<pero>** yea...food for thought i guess...  
+**\<tewinget>** dammit, now I have thought for food...  
+**\<moneromooo>** Though if hash is from a botnet, IPs don't really give you much.  
+**\<sgp>** One question: the release is in September. What window do you want to give everyone to upgrade?  
+**\<moneromooo>** I'd been wondering whether some non-profit oriented large miner might want to crowd out miners.  
+**\<sgp>** \*hardfork  
+**\<moneromooo>** Undecided yet. But hopefully more than a week :/  
+**\<knaccc>** not sure if this is the right time to suggest it, but in preparation for subaddresses, the GUI and CLI should probably recognize the subaddress and integrated subaddress prefixes and display a message that subaddresses are not supported yet, and that they need to upgrade to send to such addresses  
+**\<moneromooo>** There's not much that needs to go in next fork, so that should not be much trouble.  
+**\<sgp>** Did we ever agree on the new minimum ringsize?  
+**\<moneromooo>** That's not a bad idea at all.  
+**\<moneromooo>** No.  
+**\<moneromooo>** kenshi84: do you want to make a preliminary patch for this ? It'd include your existing parsing changes, plus error messages on use.  
+**\<moneromooo>** I don't think kenshi84's around now.  
+**\<moneromooo>** suraeNoether: what about you ? Tell us about your research.  
+**\<suraeNoether>** ah, well, good timing actually  
+**\<sgp>** How should we actually reach consensus on the new minimum number? Running out of time to decide.  
+**\<sgp>** @surae I don't mean to interrupt you though, carry on :)  
+**\<suraeNoether>** np, as far as minimum ring size goes, and mitigating EABE... a lot of this would be solved with efficient ring signatures and range proofs.  
+**\<suraeNoether>** today, I'm coding up some examples of O(sqrt(n)) ring sigs and some efficient range proof algorithms to compare sizes with current set-ups  
+**\<suraeNoether>** the idea is, if we can manage to fit a ring size of, say, 150, in with each transaction, I don't care how much computing power you have, you're going to be spending a lot of time analyzing monero's blockchain  
+**\<sgp>** 150? Wow  
+**\<moneromooo>** Kovri meeting starting in #kovri-dev for those who want to follow both.  
+**\<suraeNoether>** i would prefer orders of magnitude  
+**\<suraeNoether>** i would *prefer* a quarter million or more signatories per transaction  
+**\<ArticMine>** any idea on the trade off ring size, range proof efficiency  vs tx size?  
+**\<moneromooo>** All depends on the constants, doesn't it :)  
+**\<knaccc>** \o/  
+**\<suraeNoether>** that's what i'm looking into today, arcticmine and moneromooo, there's a cost to everything  
+**\<vtnerd>** lol @ that compute time  
+**\<pigeons1[m]>** Similarly I'm interested in exploring potential privacy drawbacks of not having a fixed uniform ring size  
+**\<suraeNoether>** so, I have some attack models for EABE. First order estimates suggest a min ring size of like 30 is necessary with 7 churns. Second order estimates suggest as low as 15 is good with a single churn. my third order estimate looks to be somewhere between those two? possibly with more in the ring size.  
+**\<suraeNoether>** pigeons1[m] this is absolutely something i'm also looking into  
+**\<suraeNoether>** i like the idea of a uniform ring size if the ring size is very large, say more than 10^2  
+**\<suraeNoether>** in a world where choices are allowable, a random (with minimum) ring size is preferable to any other given strategy  
+**\<Jaquee>** disrupting with a question: how do i run monerod with valgrind? i'm getting an "invalid argument" error on startup.  
+**\<sgp>** @surae do you think a ringsize of 10 is far too low? I didn't expect to consider a jump from 5 to 150/100  
+**\<Jaquee>** src/blockchain\_db/lmdb/db\_lmdb.cpp:71 Failed to open lmdb environment: Invalid argument  
+**\<Jaquee>** trying: valgrind /path/to/monerod  
+**\<Jaquee>** no args. blockchain in default location  
+**\<moneromooo>** Should work that way.  
+**\<Jaquee>** that's what i thought too  
+**\<JollyMort[m]>** in lieu of more research, enforcing some min. in the upcoming HF would be beneficial, no? 5 or 10?  
+**\<Jaquee>** moneromooo: https://paste.fedoraproject.org/paste/liZxIo25sun2z8d9YTDLbw/raw  
+**\<suraeNoether>** sgp : in terms of security alone, min ring size 10 would be "safe" for a year or two. but would have *how much* cost on the blockchain, and how much cost in terms of adoption? in lieu of more research, a larger ringsize is only preferably in terms of security, not necessarily in terms of adoptions  
+**\<pero>** we already enforce a minimum i believe  
+**\<suraeNoether>** yep, 2  
+**\<JollyMort[m]>** 3, no? "mixin of 2" iirc  
+**\<suraeNoether>** oh ringsize 3, mixin 2  
+**\<suraeNoether>** sorry, terminology  
+**\<sgp>** @surae do you have any major current concerns with 10? Do you think it is reasonable for now pending research?  
+**\<suraeNoether>** my concerns come from the cost to the size of the blockchain  
+**\<suraeNoether>** and hence adoptoin  
+**\<suraeNoether>** adoption\*  
+**\<sgp>** afaik the difference between 10 and 5 is very small  
+**\<suraeNoether>** i advocated large ring sizes years ago, but there is a cost to the blockchain, a huge cost  
+**\<suraeNoether>** we aren't discussing 10 vs. 5 we are discussing 10 vs. 2  
+**\<pigeons1[m]>** Better to wait for research instead of arbitrary change  
+**\<suraeNoether>** er. 3 i suppose  
+**\<sgp>** Ok, still between 10 and 3 is small  
+**\<JollyMort[m]>** when the whole discussion started the first idea was to increase to 5 iirc  
+**\<JollyMort[m]>** so might as well make it 5 vs 3 :)  
+**\<suraeNoether>** i think the security gain from 3 to 5 is not huge. the security gain from 3 to 10 is much more measurable  
+**\<endogenic>** I'm with pigeons in that one  
+**\<endogenic>** On  
+**\<moneromooo>** You're on pigeons in that one ?  
+**\<endogenic>** Yeah  
+**\<pigeons1[m]>** Oh baby  
+**\<endogenic>** I'm one with pigeons on that too  
+**\<endogenic>** Two\*  
+**\<unknownids>** ( ͡° ͜ʖ ͡°)  
+**\<pero>** will there be a security hit if we enforce 10 for a while and then switch to random?  
+**\<pero>** random as in potentially \<10  
+**\<suraeNoether>** i'm in agreement with pigeons1[m] and endogenic ... especially if these O(sqrt(n)) signatures end up being nice. because knaccc was talking about n=30 ringsize being relatively reasonable in terms of cost to the blockchain today, and i know the max ringsize demonstrated so far is around 10^3. for the same cost, we could get 900 to 10^6 signatories per ring signature if O(sqrt(n)) hits the shelves, and i'll  
+**\<suraeNoether>** tell you what: in that scenario, i'd absolutely advocate a minimum 150, and let users decide above and beyond that  
+**\<endogenic>** There may be a public education issue with switching all around w/o research too  
+**\<suraeNoether>** pero when i say random i mean "random above a certain minimum"  
+**\<pero>** gotcha  
+**\<knaccc>** yeah if a ring size 400 transaction is the same size as a ring size 20 transaction, that'd be incredible  
+**\<suraeNoether>** right now, the best hope for anonymity is simply more efficient ring sigs, and this set-up is extremely extremely promising  
+**\<endogenic>** Not that you didnt research it jolly  
+**\<suraeNoether>** actually we've researched the crap out of htis  
+**\<endogenic>** Btw jolly i guess that means i have to bump "ringsize" on the mm tx details page by 1 :p  
+**\<suraeNoether>** we just haven't come up with a formal model of security yet that provides a tractable answer "go with 17, child"  
+**\<endogenic>** Need more tea leaves  
+**\<gingeropolous>** well in september we'll at least get ringsize = 5  
+**\<moneromooo>** Make sure to list any extra crypto assumptions over what monero already assumes.  
+**\<sgp>** Right now I'm most concerned what we will do for September  
+**\<suraeNoether>** i'm not totally concerned. i'm... really... really excited about small ring sizes  
+**\<suraeNoether>** okay, i'll be back later, i'm really glad i could hop in with such good timing on this  
+**\<moneromooo>** thanks suraeNoether  
+**\<moneromooo>** anyone else ?  
+**\<gingeropolous>** oh is it meeting time?  
+**\<moneromooo>** kovri's  
+**\<ArticMine>** So next meeting in two weeks?  
+**\<serhack>** Moneromoo  
+**\<serhack>** Sorry  
+**\<serhack>** I was eating  
+**\<serhack>** Okay  
+**\<serhack>** Then  
+**\<moneromooo>** np, go ahead :)  
+**\<serhack>** My progress are: wordpress plugin is almost completed, I'm developing the verifying (if transaction is okay), I'm also starting the development of Prestashop plugins  
+**\<serhack>** After that, I will write another FFS (I will request like 40 xmr or less)  
+**\<serhack>** I would create some stickers based on https://m.imgur.com/QcdyyWn  
+**\<serhack>** I will publish plugins on codecanyon.com, every funds will be helpful for Monero Project  
+**\<serhack>** What do you think moneromoo?  
+**\<moneromooo>** Cool, thanks for the overview  
+**\<pero>** dEBRUYNE: was it codecanyon.com you blacklisted from the subreddit? ;p  
+**\<dEBRUYNE>** .net I think, but that probably doesn't matter haha  
+**\<serhack>** Your welcome, moneromoo  
+**\<dEBRUYNE>** I can unblacklist it   
+**\<serhack>** Everyone should know Monero Community  
+**\<serhack>** Fantastic community!  
+**\<gingeropolous>** opinions? If I could even figure out how to code into monero a "remote node" support flag, would it be merged? it would be a daemon load flag that would do the appropriate rpc stuff and also modify some p2p metadata to essentially broadcast its openness  
+**\<serhack>** Cheers!  
+**\<serhack>** Please pm me for more information on slack or mail me support@monerointegrations.com  
+**\<Jaquee>** so, "valgrind /path/to/monerod" works for everyone else except me?  
+**\<moneromooo>** Worked for me last time I tried. Try running with strace too, see what syscall barfs.  
+**\* iDunk** can't run valgrind because of TBM in his CPU.  
+**\<moneromooo>** Too Big Munchkins ?  
+**\<iDunk>** Trailing Bit Manipulation, IIRC :)  
+**\<iDunk>** One of AMD's FMA additions, I think.  
+**\<pero>** so...follow up q...will there be a period of time during which gui master will be broken because of zmq  
+**\<endogenic>** iDunk: is that similar to a FML addition?  
+**\<pero>** tewinget Jaquee ^  
+**\<tewinget>** pero: there shouldn't be.  
+**\<moneromooo>** tewinget says the daemon runs both 0MQ and JSON/HTTP server, so shouldn't be.  
+**\<pero>** thx  
+**\<tewinget>** won't merge the zmq rpc wallet stuff until it's tested working, and at that point the gui wallet will be unaffected  
+**\<Jaquee>** speaking of testing. is someone working on fixing the failed tests on buildbot builds?  
+**\<Jaquee>** pigeons1[m]: ^  
+**\<Jaquee>** and if you're around pigeons1[m]. How's the tagging bot coming along?  
+**\<pigeons1[m]>** Bot is working in meta repo. I'll talk with fluffy and we'll add it to gui repo.  
+**\<moneromooo>** What failing tests ? The DNS ones ?  
+**\<moneromooo>** pigeons1[m]: does it do closes yet ? :)  
+**\<pigeons1[m]>** I was tracking down lots of my own bugs so switched to an opensource bot i linked to in the meta issue. Seems to work well  
+**\<pigeons1[m]>** Yes +resolved on a line by itself by someone authorized closes the issue  
+**\<moneromooo>** Great, thanks :)  
+**\<pigeons1[m]>** And moo yes i think he means the dns ones  
+**\<moneromooo>** I've looked at the DNS stuff today, but I'm still flummoxed.  
+**\<moneromooo>** Redoing manually what libunbound is supposed to do seems... not right :/  
+**\<moneromooo>** Not to mention a huge amount of work.  
+**\<moneromooo>** And if libunbound's not doing it right, surely it'd be best to fix it, not do it manually.  
+**\<moneromooo>** I feel like I'm missing something here :/  
+**\<moneromooo>** We don't have a coder who knows about DNS already, do we ? :)  
+**\<tewinget>** I don't know your exact headache, but I remember when I first implemented that shit using libunbound.  Just about the only lib I could find that would serve our purposes, but...not without pain.  
+**\<moneromooo>** Mine is to first find the algorithm to verify a chain. Just that seems to be a lot of cases.  
+**\<pigeons1[m]>** Dnssec validation locally instead of trusting the server response is part of the pain i think tewinget  
+**\<moneromooo>** But libnubound claims to do validation.  
+**\<tewinget>** pigeons1[m]: yeah...I seem to remember that being one of the pain points.  
+**\<moneromooo>** (and it fails to do so if I give it a bad key, which seems to confirm)  
+**\<pigeons1[m]>** Yeah we're missing something...  
+**\<tewinget>** well I gotta afk for a bit.  The last step before merging #2044 is to make sure it builds properly on all the things where it needs to, including deciding how to deal with the zmq dependency itself.  I hesitate to make a decision there, as I'm ambivalent.  
+**\<moneromooo>** Probably a submodule.  
\ No newline at end of file