Unverified Commit a7a92318 authored by dEBRUYNE-1's avatar dEBRUYNE-1
Browse files

Dev Meeting Logs (2017-08-20 & 2017-09-03) + Kovri Meeting Logs (2017-08-20) +...

Dev Meeting Logs (2017-08-20 & 2017-09-03) + Kovri Meeting Logs (2017-08-20) + Community Meeting Logs (2017-09-02)
parent 0940b123
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2017-08-20
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
---
*August 20th, 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. Code + ticket discussion / Q & A
**\<anonimal>** 5. Any additional meeting items
**\<anonimal>** 6. Confirm next meeting date/time
**\<anonimal>** Well hello
**\<MoroccanMalinois>** hi
**\<anonimal>** Just you and me, eh MoroccanMalinois?
**\<moneromooo>** I'm here too, but I'm just reading.
**\<rehrar>** I'm here
**\<ajs>** here
**\<rehrar>** bam, attendance more than doubled
**\<anonimal>** Well there you go
**\<anonimal>** 2. Brief review of what's been completed since the previous meeting
**\<anonimal>** We had the 96boards webcast this past Thursday, so that was certainly a highlight.
**\<anonimal>** It was nice to have that done since I had started coordinating it toward the beginning of this year.
**\<rehrar>** I continued work on the new Kovri logo, but that has been put on hold indefinitely. I switched gears and started working on the Reddits. Got good amounts of work done and we are fixing to release the Monero subreddit new CSS here pretty soon. Kovri isn't far behind it. Then recently I'm also working on redoing the website a bit. Just a small restructure. Putting together some new wires for the pages.
**\<anonimal>** I've finally back to NTCP work (yay). Various fixes and rewriting. Now working on a phaser implementation and separating messaging from session code.
**\<ajs>** I passed along information to Pigeons about the irc server set up. He is looking into putting it up on a vps.
**\<anonimal>** I've noticed various little issues along the way that will be fixed along the way
**\<anonimal>** rehrar ajs: awesome
**\<pigeons1[m]>** No not a vps a vm on a dedicated machine we just got
**\<anonimal>** Oh even better
**\<ajs>** cool
**\<rehrar>** pigeons1[m]: fluffypony, any update on the infrastructure? :)
**\<rehrar>** oh, maybe that was just the update :P sorry
**\<pigeons1[m]>** rehrar: we got the machines and are moving things and configuring things. You can send me config info
**\<rehrar>** I'll talk to Snipa and get them. He did the setting up and debugging.
**\<rehrar>** I'm assuming it'd be too big a breach to have him help out?
**\<anonimal>** Let's stay on track here
**\<rehrar>** k sorry
**\<anonimal>** re: brief review, I've been playing PM tag with sarang but finally have began email comms
**\<anonimal>** I had sent him/her/it (assuming him) a list of various research related issues
**\<anonimal>** but will now work him to hone in on specific areas of research.
**\<anonimal>** I'm looking forward to this very much +1
**\<anonimal>** Anything else for brief review?
**\<anonimal>** Alrighty, 3. Contributor FFS check-in / status
**\<anonimal>** I'm here. Busy as usual.
**\<MoroccanMalinois>** nothing for this time
**\<MoroccanMalinois>** (was mostly on vacation)
**\<anonimal>** A well-deserved one too, I'm sure.
**\<rehrar>** Back in full swing. Wife healed nicely.
**\<MoroccanMalinois>** :)
**\<anonimal>** MoroccanMalinois: was milestone 2 settled (payment, etc.)?
**\<MoroccanMalinois>** nope
**\<anonimal>** rehrar: good to hear
**\<anonimal>** Uh oh, why not MoroccanMalinois?
**\<MoroccanMalinois>** Not enough work :)
**\<endogenic>** anonimal: re sarang i'm pleased to hear that
**\<anonimal>** Oh, when I say milestone 2 I mean *your* milestone 1.
**\<anonimal>** Because the FFS proposal is in 3 tranches, you took up the 2nd one (though it was your first).
**\<anonimal>** \*2nd one and 3rd one (because 1st one was completed)
**\<MoroccanMalinois>** ah
**\<MoroccanMalinois>** i thought u were talking about the 3rd milestone
**\<MoroccanMalinois>** that will be done tomorrow
**\<anonimal>** re: sarang, my thanks to endogenic for coordinating our first connection
**\<endogenic>** didn't do anything :P
**\<anonimal>** MoroccanMalinois: ok so 2nd is all settled?
**\<MoroccanMalinois>** No i have not contacted luigi yet (will do it tonight)
**\<anonimal>** ok
**\<anonimal>** Anything else on FFS check-in/status?
**\<bigreddmachine>** (I'm here, nothing to report on the ff extension side, been very busy IRL)
**\<anonimal>** I haven't read sarang's FFS (I hear he put out a new prorposal?)
**\<anonimal>** Hi bigreddmachine, good to hear from you
**\<anonimal>** re: FFS topic, does anyone have any specific input on what they'd want sarang to work on/look at re: kovri?
**\<anonimal>** I had a healthy list for him but I think he'll want me to narrow down things.
**\<rehrar>** I don't see a new one.
**\* anonimal** has no idea, I probably shouldn't assume that
**\<endogenic>** he's a network + crypto dude so i figured it might be possible to collaborate with him to produce a more elegant and simple form of i2p
**\<bigreddmachine>** You talked on Thursday about simplifying the crypto smorgasbord in kovri... That might be a good place for sarang to focus at some point
**\<anonimal>** Well when I was playing tag with him, I did ask him if he wanted to work on the anonymity system aspect or crypto; and he did say crypto.
**\<anonimal>** But he's also more of a math guy, and the reduction of kovri crypto is almost entirely implementation defined (so he wouldn't need to do any work on that).
**\<anonimal>** The cryptosystems we use could be looked at though, yes, for sure.
**\<endogenic>** yeah i bet he could help vet the water tightness of existing or new schemes
**\<endogenic>** and probably suggest alternate techniques for elements
**\<endogenic>** just guessing
**\<anonimal>** We'll see. Maybe he'll work on something before the next meeting.
**\<anonimal>** I'd like him to look at our DSA prime for example. I'm sure that's something he could do.
**\<anonimal>** But since we use libraries for most of our crypto, he may end up reviewing them.
**\* anonimal** shrugs, we'll see
**\<anonimal>** Anything else on FFS check-in?
**\<anonimal>** k, 4. Code + ticket discussion / Q & A
**\<MoroccanMalinois>** i have almost finished fixing #684. Will push later today
**\<anonimal>** Cool +1
**\<anonimal>** I'll merge #690. re: #690, I asked surae to look at my algo for aes-256 expanded key size but he didn't have time to look too deeply
**\<anonimal>** The constant doesn't change, so it's not a huge deal, but things like this would be nice for sarang to review/chime-in with from time-to-time.
**\<anonimal>** (yes, I said surae for first sentence and sarang for second)
**\<anonimal>** (so confusing!)
**\<anonimal>** Anything else on point 4.? I want to get to other points that rehrar and bigreddmachine were talking about.
**\<anonimal>** MoroccanMalinois: \^
**\<MoroccanMalinois>** nope
**\<anonimal>** k
**\<anonimal>** 5. Any additional meeting items
**\<anonimal>** bigreddmachine: are you still planning on doing a podcast?
**\<bigreddmachine>** Yes. I've had a busy summer so had to tick off some low hanging fruit with episodes. But I really think a talk with you (and any other key contribs) would be super.
**\<bigreddmachine>** Maybe time it to be right around alpha release date?
**\<anonimal>** Ok sure. Do you have a link to previous episodes (I didn't know you did them regularly/semi-regularly)?
**\<bigreddmachine>** MoneroMonitor.com
**\<i2p-relay> {-pigeons}** cool I didn't know about that one.
**\<bigreddmachine>** Some probably more interesting that others to this crowd :)
**\<anonimal>** Wow cool!
**\<anonimal>** Do we have a podcast section on the monero site?
**\<bigreddmachine>** Not sure. The Monero Missives were once the pseudo-official podcast
**\<bigreddmachine>** But that's at least a year defunct now.
**\<anonimal>** It would be nice to have links to things like this so they don't get flushed down the memory hole.
**\<anonimal>** I'm not sure where they'd go though. Somewhere in the community section I imagine.
**\<anonimal>** rehrar \^
**\<bigreddmachine>** Yes I agree. But haven't been sure where either so haven't done a PR.
**\<anonimal>** bigreddmachine: what's the best way to get in contact with you?
**\<rehrar>** I'll think about it and see if we can't squeeze you into a place. :)
**\<bigreddmachine>** In the near future I was to do episodrs on Love, Mimblewimble, with Surae, and probably Zooko on Zcash. And rehrar and I had discussed one too
**\<rehrar>** Indeed.
**\<bigreddmachine>** Anonimal, Securely or no?
**\<anonimal>** Either or is fine. Secure by default? Over the months I've tried pinging you on IRC but you weren't around (I just wanted to ask about the podcast).
**\<bigreddmachine>** [email protected] is a good email
**\<bigreddmachine>** Yeah I can't log into irc at work... Got in trouble for that hah
**\<anonimal>** oops!
**\<anonimal>** Ok, will email you there when needed.
**\<bigreddmachine>** If you ping me on irc with an "@" in front then slack should notify me though on my phone.
**\<rehrar>** Imma hafta split here pretty soon. What do we need from me? :)
**\<anonimal>** @bigreddmachine alright
**\<bigreddmachine>** Yeah that worked perfect
**\<anonimal>** rehrar: meeting ends in 4 minutes. You started talking infrastructure so if you had any more comments/questions?
**\<bigreddmachine>** And then I can log into irc with encryption on that you taught me.
**\<rehrar>** Oh, no. Not unless pigeons has anything more for me.
**\<anonimal>** bigreddmachine: that fantabulous cryptos!
**\<rehrar>** Oh, my question regarding Snipa. I'm assuming you'd just rather us shoot you config thingies? :)
**\<anonimal>** (you \=\= pigeons?)
**\<rehrar>** Oh, yes. Sorry for the confusion.
**\<Snipa>** There's not much config needed for mattermost. I pretty well did a basic clean install, then setup matterbridge with the guides on the site.
**\<Snipa>** Hardest part was getting the webhooks to play nicely with each other, and seeing how they integrated.
**\<rehrar>** The man himself, ladies and gentlemen!
**\<anonimal>** Hi Snipa
**\<rehrar>** And the Taiga? And then the Taiga / MatterMost connection?
**\<anonimal>** So we're 100% doing mattermost? I saw a few comments from people questioning/complaining.
**\<Snipa>** That's the webhooks. If there's a specific question, I'll be glad to answer it of course, but a direct copy of the configs won't be useful, as I very much deployed them quick and dirty.
**\<rehrar>** As far as I know, yes. We got a second successful test and everything worked perfectly.
**\<anonimal>** k
**\<rehrar>** And we'll make a push to get people away from Slack
**\<anonimal>** +1
**\<anonimal>** Any other additional meeting items?
**\<rehrar>** Not from me for the time being.
**\<bigreddmachine>** Nope
**\<MoroccanMalinois>** nope
**\<hyc>** hey anonimal
**\<anonimal>** Hi hyc
**\<hyc>** on the 96boards mtg you suggested that only rsa4096 was needed
**\<hyc>** why that instead of one of the EC mechs?
**\<anonimal>** For reseed, yes.
**\<anonimal>** I'll need to see what the reseed servers are capable of / require.
**\<hyc>** afaik EC is smaller/faster/better
**\* anonimal** agrees
**\<hyc>** ok, just wondered and wanted to make sure
**\<anonimal>** Awesome, thanks for the question :) I'll put on my TODO list
**\<anonimal>** 6. Confirm next meeting date/time
**\<anonimal>** Same time, two weeks from now?
**\<bigreddmachine>** Sure I won't be there but thats not a big deal. I'll catch up with the minutes.
**\<anonimal>** Ok
**\<anonimal>** Thank you again everyone!
\ No newline at end of file
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2017-08-20
summary: Discussion of open PRs and issues, RuffCT, mobile wallets, upcoming release + scheduled protocol upgrade, dedicated hardware wallet, and miscellaneous
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
---
*August 20th, 2017*
# Overview
An overview can be found on [MoneroBase](https://monerobase.com/wiki/DevMeeting_2017-08-20).
# Logs
**\<fluffypony>** 1. Greetings
**\<fluffypony>** 2. Brief review of what's been completed since the previous meeting
**\<fluffypony>** 3. Code + ticket discussion / Q & A
**\<fluffypony>** 4. Any additional meeting items
**\<fluffypony>** 5. Confirm next meeting date/time
**\<fluffypony>** rehrar can do it next time :)
**\<rehrar>** I can, sorry for the confusion
**\<fluffypony>** 1. Greetings
**\<fluffypony>** can all the people who aren't here just say nay
**\<fluffypony>** :-P
**\<hyc>** neigh
**\<surae>** we never get past this part :
**\<fluffypony>** it's a fun part
**\<fluffypony>** we can move on to 2
**\<fluffypony>** 2. Brief review of what's been completed since the previous meeting
**\<fluffypony>** I guess the big thing is that we've branched
**\<surae>** well
**\<surae>** from MRL
**\<surae>** we got contacted by RingCT2.0 people, and we got contacted by a rsearcher named Tim Ruffing, each of them presenting improved set-ups for our current implementations
**\<surae>** not sure if I should just jump in or what..
**\<dEBRUYNE>** Yeah go ahead
**\<hyc>** sure, go
**\<surae>** ok so
**\<surae>** I have a .txt file describing the pseudocode of Ruffing's sublinear ring sig + CT set-up
**\<surae>** knaccc has been going through it and implementing it in Java
**\<surae>** we have a surprising amount of it debugged
**\<hyc>** \^ note, we're walking away from the RingCT2.0 stuff because it requires a trusted setup
**\<surae>** Ah, I didn't look into it because Ruffing's doesn't have a trusted set-up or any "new" crytpo. it just doubles all our key lengths
**\<iDunk>** surae: fpaste.org or pastebin.mozilla.org
**\<sn0wmonster>** has the meeting started?
**\<endogenic>** yes
**\<sn0wmonster>** where does it say it started? jesus
**\<surae>** iDunk is 0bin not good enough? :P
**\<iDunk>** It requires java.
**\<iDunk>** js actually
**\<moneromooo>** I think it needs to be encrypted due to agreement with Tim Ruffing.
**\<surae>** oh i didn't realize that
**\<DaveyJones>** surae ... the mooo wants javaless paste
**\<surae>** moneromooo no, just habit
**\<surae>** ok one sec
**\<moneromooo>** Oh, ok. I'm dying to see it then :D
**\<moneromooo>** ty
**\<surae>** we are in the midst of debugging knaccc's java code
**\<dEBRUYNE>** surae: Could you perhaps give an ELI5 (for anyone that reads the logs later) how RuffCT will improve our protocol?
**\<surae>** well, roughly, (ruffly)
**\<knaccc>** lol
**\<surae>** signature sizes are O(N) right now. So signature sizes take up "as much space" as the number of public keys implicated in the signature
**\<surae>** Ruffing's set-up, for N=n\^m, has signature sizes O(n\*m). Verification and computation *it appears* to be on the same order. so, for example, to sign a ring signature with N=10\^17 signers, which is freaking absurd, you would need "as much space" as 10*17 = 170 public keys
**\<surae>** there are constants and stuff, so it's not exact, but at the very least, Ruffing's set-up is looking at really absurdly large ring signatures
**\<hyc>** ... without taking absurdly large amount of space
**\<surae>** with a set-up like this, there should be no good reason to not simply sign every transaction with the top half of the blockchain every time
**\<surae>** or taking absurdly large amounts of time to verify or compute
**\<dEBRUYNE>** So we can easily use ring size 100k for instance?
**\<dEBRUYNE>** Or even higher
**\<hyc>** even higher
**\<fluffypony>** EVEN HIGHER
**\<surae>** assuming his set-up actually works (the math seems tight) and assuming his security proofs hold up (I am going to try to make independent security proofs and then later compare them), and after six months to a year of testing, etc etc
**\<surae>** i mean
**\<JollyMort[m]>** UNLIMITED RINGSIZE
**\<endogenic>** fluffypony: what does the scouter say about monero's ringsize level?
**\<moneromooo>** log(infinity) is infinity...
**\<surae>** in a certain sense, this is like an alien came down and gifted us faster than light travel. yeah, we can go out there and start traveling around, but we have to consider consequences for the timeline. :P haha
**\<fluffypony>** endogenic: I give up?
**\<endogenic>** it's over 9000
**\<fluffypony>** lol
**\<DaveyJones>** the puns are ruff today
**\<fluffypony>** also to add to what surae's said
**\<moneromooo>** Would be need (pretty much) all pubkeys/commitments in RAM all the time, in order to verify such sigs ?
**\<moneromooo>** Or can some precomp be done ?
**\<fluffypony>** multisig isn't baked in right now, it would need to be re-done from scratch
**\<rehrar>** the room fell silent
**\<hyc>** I'll precompute it all for ya. trust me.
**\<dEBRUYNE>** fluffypony: Are we certain it has to be re-done from scratch or would it possible to just tweak the current implementation?
**\<surae>** moneromooo the signature itself only uses the commitments from the column of the signer
**\<fluffypony>** dEBRUYNE: we're certain
**\<dEBRUYNE>** k
**\<DaveyJones>** fluffypony - can it be dual run like pre-ct and ring-ct till the fork?
**\<dEBRUYNE>** I think we shouldn't forego the current implementation, because we're already quite far in
**\<surae>** debruyne the shen-luigi multisig set-up which is a version of the schnorr multisig, might lead us to a similar set-up for RuffCT, but it's not a simple gluing like one would hope
**\<dEBRUYNE>** In addition, it may take a year before RuffCT is actually implemented
**\<DaveyJones>** so that we could keep luigi ms till ruff ms is done ?
**\<dEBRUYNE>** And even longer before we have a multisig that is compatible with ruffct
**\<JollyMort[m]>** you can always convert later
**\<fluffypony>** DaveyJones: I don't think so, at least not trivially
**\<JollyMort[m]>** i mean if we have to do RCT->RuffCT
**\<surae>** dEBRUYNE I'm actually with you on that. chances are good RuffCT is about 1 year out from being live, and I wouldn't be *shocked* if we could make a threshold scheme out of it before that year is up
**\<JollyMort[m]>** same can be done for wallets
**\<JollyMort[m]>** RCT multisig -> RuffCT multisig
**\<fluffypony>** well, basically this isn't going in to a hardfork until we have multisig
**\<msvb-lab>** JollyMort[m]: hardware or software wallets?
**\<tyrionmcmmaster>** i agree with the majority, that multisig pre-ruffct should be implemented for the time being
**\<JollyMort[m]>** and shen/luigi multisig can work regardless of consensus rules
**\<dEBRUYNE>** \<msvb-lab> JollyMort[m]: hardware or software wallets? \<= Doesn't matter
**\<JollyMort[m]>** by means of one-time multisig wallets
**\<surae>** so i'm happy finsihing up the shen-luigi multisig scheme, letting wallets use it until RuffCT goes live, they'll still be able to use it for whatever RCT outputs are still floating around if they like... and maybe users may miss out on threshold signatures for one hardfork, but probably not two.
**\<hyc>** that sounds decent
**\<fluffypony>** ok
**\<DaveyJones>** \^+1
**\<fluffypony>** guys let's move on
**\<surae>** excellente
**\<fluffypony>** 3. Code + ticket discussion / Q & A
**\<DaveyJones>** can i chime in for the AFK devs?
**\<fluffypony>** before we discuss any specific PRs / issues
**\<fluffypony>** I wanted to get a feel as to how we should handle the branch wrt PRs
**\<fluffypony>** ie. do we want people to push PRs to both branches where relevant
**\<fluffypony>** or must I just cherry-pick commits?
**\<moneromooo>** Push to both, or the GPG signature drops.
**\<fluffypony>** moneromooo: I meant cherry-pick to my fork and then PR it
**\<hyc>** ok. but tat this pre-release time, how are we deciding which PRs are eligible for the release branch?
**\<moneromooo>** fluffypony: I don't understand that.
**\<moneromooo>** If someone wants a patch to the release branch, they PR it to that branch too.
**\<vtnerd>** bug fixes should automatically be considered ... everything else is subjective
**\<fluffypony>** vtnerd: it's bug fixes only
**\<moneromooo>** I guess you can cherry-pick if the commit isn't signed in the first place.
**\<fluffypony>** nothing else goes in, we're in code freeze on the branch
**\<fluffypony>** moneromooo: if I cherry-pick and I sign it then it's still signed?
**\<vtnerd>** ok good, at least we are in agreement on that
**\<moneromooo>** Well, it's signed by you, yes...
**\<moneromooo>** But you're kinda not the author ? :)
**\<fluffypony>** moneromooo: with cherry-pick it lists both myself and the aithor iirc
**\<fluffypony>** \*author
**\<moneromooo>** I guess nobody really cares anyway.
**\<moneromooo>** Yes, but the author's signature drops AFAIK.
**\<moneromooo>** So you could modify a large patch, sign it, and nobody would notice.
**\<iDunk>** I agree with moneromooo, that's not the way to do it.
**\<hyc>** ok, so PR directly to release branch
**\<fluffypony>** moneromooo: https://i.imgur.com/PG0YmsF.png \<- like that
**\<hyc>** there's 22 open PRs at the moment. only a few seem to be current bugfixes
**\<moneromooo>** Most people will just PR to master anyway, so not much trouble.
**\<moneromooo>** I'm not sure I get the point.
**\<fluffypony>** ok this is more about the fallback if the contributor doesn't PR to the branch in a timeous fashion
**\<moneromooo>** In that case, if it's really needed for the branch, cherry-pick is OK I suppose.
**\<fluffypony>** ok cool
**\<hyc>** but re: the branch, I'd like #2313 and #2314 to go into the release. should help further reduce chance of corruption on powerfail.
**\<moneromooo>** Agreed.
**\<moneromooo>** I'll just fixup the target thing too.
**\<hyc>** cool
**\<moneromooo>** I think just removing the state check will be fine.
**\<fluffypony>** yes
**\<fluffypony>** if those can be PRd to the branch that would be great
**\<hyc>** willdo
**\<fluffypony>** ok - anything else?
**\<JollyMort[m]>** about GUI cold signing
**\<JollyMort[m]>** any plans to add import/export outputs&keyimage stuffs
**\<msvb-lab>** fluffypony: Not sure when it's appropriate to ask for consensus on (yes) increase efforts towards a hardware wallet or (no) maintain status quo.
**\<fluffypony>** what's everyone's feelings on merging 0MQ into master?
**\<DaveyJones>** so tewinget only said that he just wants further feedback
**\<dEBRUYNE>** JollyMort[m]: Jaquee isn't here afaik
**\<DaveyJones>** and jaquee asked this
**\<Jaquee>** i'm here now
**\<hyc>** I thought merging 0MQ is slated for after the release
**\<DaveyJones>** \<Jaquee> not sure if i can make it to the meeting. have two questions. 1. updates on disk space on build machines (when can we have an android apk available for download?) 2. updates on app store and transifex accounts?
**\<Jaquee>** reading backlog
**\<moneromooo>** After the release is done, yes.
**\<DaveyJones>** oh your here :D
**\<fluffypony>** we've already branched, tho, so surely we can merge to master?
**\<moneromooo>** his here.
**\<fluffypony>** msvb-lab: the dev working group don't really control external manufacturers
**\<dEBRUYNE>** fluffypony: moneromooo wants to put in an additional review afaik
**\<moneromooo>** I've not looked at the latest changes yet.
**\<dEBRUYNE>** And tewinget is waiting for further feedback
**\<fluffypony>** ok
**\<Jaquee>** but maybe lightwallets PR can be merged? (in masteR)
**\<pigeons1[m]>** Jaquee we got the build machine so early this week on the android jobs
**\<rehrar>** regarding the transifex account, I've found an open-source, self-hosted alternative in weblate.org
**\<medusa>** i dont think the fact if we branched mathers too much regradiing 0mq
**\<Jaquee>** pigeons1[m]: Great!
**\<rehrar>** just waiting on the new server infrastructure :)
**\<medusa>** we should play it safe
**\<moneromooo>** If the lightwallet stuff is the same I reviewed already, it was OK to merge IIRC.
**\<Jaquee>** it's the same
**\<fluffypony>** kk
**\<dEBRUYNE>** \^ Not sure we should put that up on SE already
**\<sn0wmonster>** i have a suggestion for future meetings, let me know when i can make it.
**\<JollyMort[m]>** yeah i thought that too dEBRUYNE
**\<JollyMort[m]>** surae what do you think?
**\<fluffypony>** yeah I think some of this is confidential-ish
**\<hyc>** are we still on ticket discussion?
**\<DaveyJones>** aye
**\<JollyMort[m]>** i mean, putting it in the meeting logs also makes it public
**\<JollyMort[m]>** the genie is out of the bottle
**\<dEBRUYNE>** I can just remove it from the logs
**\<fluffypony>** hyc: about to move on, but you can still bring stuff up
**\<hyc>** no that's fine
**\<dEBRUYNE>** JollyMort[m] \^
**\<hyc>** let's move on
**\<dEBRUYNE>** fluffypony: Jaquee wanted to know about the appstore accounts btw
**\<fluffypony>** surae should weigh in on that
**\<dEBRUYNE>** If you have any update on that
**\<Jaquee>** ^^
**\<fluffypony>** app store accounts are waiting on the D-U-N-S number to be sent to Apple, I've sent scans of docs to Google and M$
**\<fluffypony>** so Two Weeks™ ?
**\<fluffypony>** 4. Any additional meeting items \<- moving on to that
**\<fluffypony>** since it's part of it anyway
**\<sn0wmonster>** is this where i can make a suggestion?
**\<fluffypony>** sn0wmonster wanted to make a suggestion
**\<sn0wmonster>** yay
**\<sn0wmonster>** so, i noticed the meeting started only after it was obvious it was a meeting
**\<sn0wmonster>** i don't see a Meetbot (which apparently is a package in Debian),
**\<sn0wmonster>** so if you must do it this way, i was wondering if you wouldn't make it painfully obvious to everyone with a header of some kind, like this:
**\<othe>** msvb-lab asked a question but got overrun, i am willing to help sponsor his hw wallet stufdlf
**\<fluffypony>** also the time is set two weeks in advance
**\<sn0wmonster>** \/flushq
**\<pigeons1[m]>** Sn0wmonster makes a great meeting bot
**\<hyc>** it's also announced on reddit and github
**\<sn0wmonster>** beep bop boop
**\<othe>** Ffs sake, there are 2 hw wallet proposals. Feedback appreciated.
**\<msvb-lab>** othe: If anyone has advice on what to change in those FFS, the URLs are:
**\<msvb-lab>** https://forum.getmonero.org/7/open-tasks/88149/dedicated-monero-hardware-wallet/
**\<hyc>** and was announced here a few hours earlier
**\<msvb-lab>** https://forum.getmonero.org/7/open-tasks/88160/monero-firmware-for-ledger-wallet/
**\<endogenic>** sn0wmonster: https://github.com/monero-project/meta/issues
**\<fluffypony>** sn0wmonster: https://www.reddit.com/r/Monero/comments/6uvu94/dev_kovri_meetings_later_today_1700_1800_utc/
**\<DaveyJones>** shhh listen to othe and msvb-lab
**\<sn0wmonster>** i didn't say it wasn't known, i said the *chatlog* had no introduction that the meeting had started really
**\<endogenic>** sn0wmonster: it did though ?
**\<JollyMort[m]>** i'm saying it had :) first post by fluffypony with the agenda 0. .. 1. .. 2.. ...
**\<JollyMort[m]>** maybe you missed it
**\<msvb-lab>** DaveyJones: Rather than listen, please speak whoever is interested in hardware crypto and border searches.
**\<rehrar>** but it didn't have the Monero symbol
**\<endogenic>** msvb-lab: doesn't quite seem like a dev item tho
**\<hyc>** yeah, I think we can put that meeting announcement topic to rest.
**\<DaveyJones>** msvb-lab they cannot speak if they don`t listen :D
**\<moneromooo>** In other code news: I'm still debugging sync niggles with iDunk's help (who's been doing a LOT of testing, so many thanks). It'll be ready soon (both branch and master).
**\<rehrar>** msvb-lab: we can talk about it in Community meeting next week?
**\<msvb-lab>** endogenic: Okay, let's postpone. Good idea rehrar.
**\<JollyMort[m]>** about the gui cold signing
**\<iDunk>** Yw :)
**\<JollyMort[m]>** it's still missing features
**\<moneromooo>** If someone feels like syncing, please try the sync-standby3 branch :)
**\<endogenic>** msvb-lab: no need to post-pone. maybe bring it up in #Monero ?
**\<dEBRUYNE>** rehrar, endogenic: If there's room left, why not give msvb-lab the floor for a few minutes?
**\<moneromooo>** It may not be code per se, but it's tech. I think it's fine here. Still 10 minutes.
**\<othe>** I'll just sponsor it, its hilarious that there's no secure way to store xmr.
**\<endogenic>** kk
**\<fluffypony>** msvb-lab: a dedicated wallet would be cool
**\<rehrar>** well that's decided then isn't it?
**\<msvb-lab>** So the question is if we can achieve consensus on how to lower risk of another year with no wallet.
**\<hyc>** there are two proposals tho, do we have to pick one, or do both?
**\<msvb-lab>** hw wallet, i mean.
**\<fluffypony>** Ledger are already working on it, not sure if we need to double up efforts there
**\<dEBRUYNE>** Perhaps it'd be more beneficial if we have some general firmware that hw wallets could implement
**\<surae>** gosh, sorry, i got distracted. no, please don't put up a stackexchange yet. a few weeks, no problem, but right now we should maybe keep it a little quieter~
**\<surae>** if possible
**\<surae>** cat's out of the bag, but i mean
**\<msvb-lab>** hyc: One deals with dedicated hardware design, the other with porting to existing hardware.
**\<fluffypony>** msvb-lab: https://www.reddit.com/r/Monero/comments/6thv8j/ledger_hardware_wallet_monero_integration/ \<- this is from 6 days ago
**\<endogenic>** 2quick4u fyi
**\<msvb-lab>** fluffypony: That's probably Cedric's document Blue-something, quite good.
**\<dEBRUYNE>** \<msvb-lab> hyc: One deals with dedicated hardware design, the other with porting to existing hardware. \<= Even though the former would be pretty cool, the latter is probably more beneficial
**\<JollyMort[m]>** and debruyne out the link then; i feel like simply removing stuff from the logs goes against some principle on transparency
**\<hyc>** looks to me like Ledger has done the hard part of figuring out the division of labor between hw wallet and Monero libraries
**\<Jaquee>** ledger said alpha around end of september iirc.
**\<fluffypony>** I don't think there's value in doubling up on the Ledger effort
**\<hyc>** ^^ agreed
**\<dEBRUYNE>** What about porting to Trezor and Keepkey though?
**\<Jaquee>** +1
**\<msvb-lab>** There have been firmware ports (to Trezor) before that have not met Monero's feature set (RingCT) or unmaintained.
**\<dEBRUYNE>** Perhaps msvb-lab is interested in finishing noodle's code?
**\<fluffypony>** msvb-lab: Trezor was more complicated than that
**\<msvb-lab>** I just hope if Cedric completes the port, that there is maintenance after that.
**\<fluffypony>** NoodleDoodle did the Trezor firmware
**\<JollyMort[m]>** Cedric is the Ledger crypto-guy
**\<ferretinjapan>** fluffypony, choice is always a good thing WRT HWE wallets, otherwise we may get centralisation of support/development/monopoly of service, etc.
**\<hyc>** I'd say we pick up whatever changes ledger comes up with and use that as a basis for other hw projects
**\<fluffypony>** then there was a bit of a disagreement between Trezor and us
**\<JollyMort[m]>** afaik
**\<fwrttrukjwtrijdh>** sorry, noticed objections above to SE questions. Will delete for now. Does same objection apply to both Ruffling and RingCT2.0 paper?
**\<fluffypony>** and then I met up with them 33c3, and they said that it's not worth us moving forward on it till Trezor 2.0
**\<hyc>** if all the wallets use the same handshakes that saves everyone effort
**\<fluffypony>** which was Coming Soon™
**\<moneromooo>** Tim Ruffing requested keeping is internal as a courtesy. I don't think anhything like that applies to Ringct 2.0.
**\<dEBRUYNE>** The 2.0 paper was posted on reddit too :P
**\<hyc>** that's as close as we'll get to a "common firmware" - other hw wallets will be based on different chips anyway
**\<msvb-lab>** Not sure how stable (management or technically) Trezor is, hoping Cedric follows through on the Ledger work is a possibility. We then do little or nothing and wait for results.
**\<fluffypony>** msvb-lab: I'd support effort on a dedicated HW wallet
**\<JollyMort[m]>** chip design etc? that sounds good
**\<JollyMort[m]>** especially if all the schematics are published
**\<msvb-lab>** Something that interests me is adding Monero specific features to a dedicated wallet, and make it as border search proof as possible (not supported by Ledger.)
**\<JollyMort[m]>** so anyone can buy the parts and build it
**\<hyc>** lol. I'm not soldering surface-mount chips by myself.
**\<msvb-lab>** JollyMort[m]: Everything would be designed with KiCad and published in a github or similar.
**\<sn0wmonster>** what is not border-proof about ledger?
**\<msvb-lab>** hyc: I have a SMD lab, reflow and all.
**\<ferretinjapan>** hyc, what's the problem? All you do is put it in the oven ;)
**\<msvb-lab>** sn0wmonster: No ability to destroy the private key without battery.
**\<fluffypony>** avoiding the glitching attacks just demonstrated against Trezor will be fun
**\<hyc>** let's just say I've overcooked a few microcontrollers in my day...
**\<endogenic>** hyc: you need an intern or two
**\<JollyMort[m]>** hyc baking bad :)
**\<msvb-lab>** fluffypony: Yes, glitch defense is part of the design. I'm not sure it's possible at all, but there will be research.
**\<fluffypony>** cool beans
**\<dEBRUYNE>** fluffypony: Do we still have time, I wanted to suggest something more generally?
**\<msvb-lab>** fluffypony: Randomness probably plays an important role, so we have chips like ATSHA240A.
**\<DaveyJones>** so dedicated hw of the two it will be ? so we can come to a conclusion before the end of meeting
**\<JollyMort[m]>** Jaquee: would it be too much effort to add the import/export stuffs into gui
**\<msvb-lab>** dEBRUYNE: Let's close off hw wallets now, but everyone please add a post to the FFS if you have a strong opinion.
**\<msvb-lab>** Thanks for the floor folks!
**\<JollyMort[m]>** would be nice to avoid depending on the CLI to fix cold signing glitches
**\<dEBRUYNE>** All right, I'll leave a comment later msvb-lab :)
**\<JollyMort[m]>** and some use cases require import/export stuffs
**\<dEBRUYNE>** I personally wanted to raise the idea to release more often (e.g. a new release every quarter) to (i) tighten and improve the feedback loop and (ii) decrease time spend on helping out people that incur issues that are already long fixed in master
**\<Jaquee>** JollyMort[m]: not that much effort. problem is that code is frozen in monero. so wont make into this coming release
**\<dEBRUYNE>** I spoke with fluffypony about this in private and he was concerned it would put too much pressure on contributors
**\<JollyMort[m]>** :(
**\<dEBRUYNE>** So I'd like to hear their opinion about it
**\<Jaquee>** i added some improvements yesterday
**\<dEBRUYNE>** I guess I should mainly page Jaquee, moneromooo, hyc, iDunk
**\<JollyMort[m]>** i saw, haven't tested it yet
**\<dEBRUYNE>** \^ apologies if I forgot someone :P
**\<hyc>** "release early, release often"
**\<JollyMort[m]>** i'll check it out
**\<moneromooo>** I think it'd put too much pressure on the pony.
**\<dEBRUYNE>** hyc: Right, that was kind of my basis for the idea
**\<Jaquee>** i'd love to release more often
**\<hyc>** I think having another interim release would be nice
**\<moneromooo>** He barely has the time to do anything AIUI.
**\<dEBRUYNE>** moneromooo: Could this be mitigated if we had an additional maintainer?
**\<endogenic>** i think it's funny when people say "fail fast"
**\<fluffypony>** we need to bear in mind that this is security software
**\<dEBRUYNE>** I think luigi wanted to do an FFS soon for it
**\<moneromooo>** Who would you trust which can do it ?
**\<moneromooo>** hyc!
**\* moneromooo** flees
**\<hyc>** :P
**\<dEBRUYNE>** Well luigi could merge stuff and FP release?
**\<fluffypony>** I don't think we should be pushing to release unstable software :-P
**\<DaveyJones>** hyc or the luigi1115
**\<fluffypony>** an additional maintainer won't make software magically stable :-P
**\<hyc>** true
**\<dEBRUYNE>** fluffypony: No, but it would take time away that you have to spend on merging and reviewing stuff
**\<ferretinjapan>** I'd just like to say that a backup maintainer should be seriously considered, even if the release schedule stays the same, there's nothing like redundancy...
**\<fluffypony>** we need way more eyes on PRs than that
**\<fluffypony>** ferretinjapan: we already have backups
**\<dEBRUYNE>** Also, those large merging waves inhibit the momentum of the project imo
**\<ferretinjapan>** ah, goodo
**\<medusa>** the lack of follow up bugfix releases causes huuge amunt of support work
**\<fluffypony>** the Core Team have access, and luigi1115 is my direct backup
**\<fluffypony>** medusa: we've already solved that
**\<medusa>** how?
**\<rehrar>** What if one release added content, and the intermin is just bug fixes?
**\<fluffypony>** with the branch
**\<dEBRUYNE>** \<fluffypony> I don't think we should be pushing to release unstable software :-P \<= Not saying we should, but if master is deemed stable we could put out a release with a few new features right?
**\<medusa>** so this time we going to have a follow up release 100% ?
**\<medusa>** like 2 weeks later
**\<fluffypony>** medusa: it depends on if there are bug fixes
**\<dEBRUYNE>** There are always bug fixes
**\<dEBRUYNE>** :P
**\<medusa>** well depends on severity i agree
**\<medusa>** of the bug
**\<ferretinjapan>** dEBRUYNE, what about early beta releases? Say just before the freeze?
**\<JollyMort[m]>** for one thing, i would love to see cold signing stuffs added asap; feel like it's an important feature to those who don't want to use CLI for the same thing
**\<JollyMort[m]>** and be able to resolve any problem people may have by using GUI functions
**\<ferretinjapan>** or an "experimental" release?
**\<hyc>** can we just get people to use a nightly build, for bugfix verification?
**\<dEBRUYNE>** ferretinjapan: That seems suboptimal, as there would be new binaries a few weeks later
**\<bigreddmachine>** Isn't that what the nightly builds are?
**\<hyc>** and then at some point we can decide if we have something stable enough for another release
**\<medusa>** if we potentially want to keep the branch that long, we should also slow down with merging stuff in trunk (especially 0mg)
**\<medusa>** until we can estimate the quality of the branch somehow
**\<fluffypony>** just looking at the recent releases, I don't think there have been a lack of them
**\<fluffypony>** Sep 19, 2016: 0.10.0
**\<fluffypony>** Dec 13, 2016: 0.10.1
**\<fluffypony>** Feb 23, 2017: 0.10.2
**\<fluffypony>** Feb 24, 2017: 0.10.2.1
**\<fluffypony>** Mar 26, 2017: 0.10.3
**\<fluffypony>** Mar 26, 2017: 0.10.3.1
**\<medusa>** otherwise we risk, dpeending on buigs we have after release, to end up in a hairy position
**\<hyc>** so it sounds like release-as-needed is working
**\<fluffypony>** yeah, I'm not really seeing a lack of releases there
**\<moneromooo>** especially on march the 26th.
**\<hyc>** heh
**\<JollyMort[m]>** release density == nan
**\<ferretinjapan>** The last 5 months have been rather quiet, but I don't think it's all bad.
**\<medusa>** those 1d releases dont yount
**\<medusa>** they fix emergency stuff
**\<ferretinjapan>** You guys were busy with making sure ringct was solid after all...
**\<medusa>** we talk about follow up releases, with 2 weeks in between
**\<medusa>** we enever do that
**\<ferretinjapan>** and then there was that bug...
**\<hyc>** 2 weeks seems too soon for a scheduled followup
**\<bigreddmachine>** Q before meeting is over. What kinds of things need to be studied on the PoW change proposal? I'm happy to dig into that but would like some direction if possible.
**\<hyc>** and 5 months since the last release seems too long
**\<endogenic>** bidreddmachine: what problem necessitates that?
**\<dEBRUYNE>** hyc: If the release merely intends to fix bugs of the latest release, is two weeks too soon?
**\<endogenic>** the PoW change
**\<hyc>** dEBRUYNE: I presume bug fix releases go out as soon as available
**\<dEBRUYNE>** But we haven't done that in the past
**\<hyc>** e.g., for emergency fixes
**\<dEBRUYNE>** That's the issue medusa is raising
**\<hyc>** otherwise, if it's not urgent, 2 weeks seems short.
**\<msvb-lab>** has the meeting officially ended, one hour right?
**\<fluffypony>** well in the past 5 months we haven't really been able to release stable + bug fixes
**\<DaveyJones>** afaik the GUI had/has a bug that freeze's the wallet on some system thats already fixed but never got released ... thats what your talking about medusa?
**\<bigreddmachine>** endogenic: some things were raised in the thread on GitHub. I wouldn't be going into it saying "this needs to happen" but rather trying to dissect the potential issues and see if there is anything to be gained.
**\<fluffypony>** because we didn't branch
**\<fluffypony>** now we branch
**\<fluffypony>** so it seems like we're discussing something we've already fixed...?