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

fixed merchants, fixed meeting logs

Browse source
This commit is contained in:
Riccardo Spagni 2016-08-29 22:52:29 +02:00
parent 9ffaa2361f
commit 8d7e797b33
No known key found for this signature in database
GPG key ID: 55432DF31CCD4FCD
4 changed files with 960 additions and 960 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
_data/merchants.yml
View file

@ -80,8 +80,8 @@
url: https://mymonero.com
- name: Pradeep Atluri, Psychiatrist, New York
url: http://dr.mindsci.com/
+ - name: Web Developer - Stefanos
+ url: http://www.stefanosioannou.com/web-development-monero-accepted
- name: Web Developer - Stefanos
url: http://www.stefanosioannou.com/web-development-monero-accepted
- name: XMR.link OpenAlias Registry
url: https://www.xmr.link/
- name: XMR.to Monero to Bitcoin Payment Service

810
_posts/2016-08-14-overview-and-logs-for-the-dev-meeting-held-on-2016-08-14.md
View file

@ -14,408 +14,408 @@ An overview [can be found on Hello Monero](https://hellomonero.com/article/moner
# Logs
**\<wallet42>** moneromoo: rewview guidelines?
**\<moneromooo>** wallet42: well, whatever you feel comfortable with. Do you have anything in mind ?
**\<i2p-relay> {-anonimal}** Is there a meeting in a few minutes?
**\<moneromooo>** The most important is potential for exploits.
**\<moneromooo>** Yes.
**\<hyc>** awesome
**\<moneromooo>** Well, assuming the pony isn't too busy with mymonero.
**\<darkcoinspy>** get your notepads out everyone. time to take notes on the competition
**\<i2p-relay> {-anonimal}** Which competition?
**\<moneromooo>** I think he just meant dash is still around. It's another crypto (ex darkcoin).
**\<dEBRUYNE>** \<moneromooo> Well, assuming the pony isn't too busy with mymonero. <= he was online 20 min ago, fwiw :p
**\<hyc>** fixing mymonero...
**\<dEBRUYNE>** :-P
**\<alex___>** what happened to mymonero?
**\<hyc>** its blockchain got stuck
**\<alex___>** ah ok
**\<dEBRUYNE>** alex___: \<_Telegram> \<fluffypony> there were like 6 imports running which deadlocked the database
**\<hyc>** I thought we fixed db_open to disallow more than 1 process on the DB at a time
**\<moneromooo>** Might be talking about his sql db I think.
**\<hyc>** ah
**\<hyc>** too bad. we've been working on an LMDB backend for mysql/mariadb but not much progress in a long time
**\<DaveyJones>** isnt there supposed to be a meeting? xD
**\<JjegrUseinob>** yes
**\<JjegrUseinob>** waiting on poniex
**\<JjegrUseinob>** ponies
**\<hyc>** fluffypony fluffypony fluffypony ?
**\<JjegrUseinob>** fluffypony may be drinking wine right now
**\<JjegrUseinob>** have you seen his wine rack?
**\<i2p-relay> {-anonimal}** Yes, epic.
**\<JjegrUseinob>** im about to go get a drink myself
**\<JjegrUseinob>** brb
**\<hyc>** good idea
**\<dEBRUYNE>** moneromooo, hyc: perhaps someone else can take the lead until he returns?
**\<hyc>** if we had an agenda in advance that'd work. I've got no idea what needs to be covered today
**\<moneromooo>** Well, I have just one thing to say, really: reviewers wanted (even for part of the stuff).
**\<hyc>** OK, that's a good topic. So there's now a PR for the RingCT code
**\<hyc>** which means it's presumably functionally complete and ready for heavy testing
**\<dEBRUYNE>** \<hyc> if we had an agenda in advance that'd work. I've got no idea what needs to be covered today <= let's just discuss Ring CT first and the additional open PRs
**\<DaveyJones>** paging othe, luigi1111w, luigi1112, othe, tewinget too
**\<i2p-relay> {-anonimal}** Congratulations to everyone involved on that. Its a big one.
**\<moneromooo>** Yes. I don't think I've got anything else to add, until luigi finds something else he wants to change.
**\<DaveyJones>** maybe smooth too
**\<moneromooo>** But reviewing this isn't going to be wasted anyway, even if he finds something.
**\<dEBRUYNE>** ^ NoodleDoodle, ArticMine
**\<DaveyJones>** but the agenda thing would be nice for such incidents
**\<dEBRUYNE>** moneromooo: Is there a way people can help with testing?
**\<i2p-relay> {-anonimal}** moneromooo: is there anything in particular that needs attention in terms of review?
**\<ArticMine>** RingCT is going to need heavy testing and a public testnet would be a great asset for this
**\<moneromooo>** Well, the private fork branch is out of date now, there'll be a public testnet once there's a modicum of review I expect.
**\<wallet42>** I would love to setup and pay for a public testnet with a couple nodes
**\<dEBRUYNE>** Fwiw, there's a guide to setup a private tesnet -> https://moneroexamples.github.io/private-testnet/
**\<fluffypony>** sorry just got in
**\<luigi1112>** Sounds good :-)
**\<fluffypony>** was eating
**\<moneromooo>** Hay.
**\<moneromooo>** er, I mean... hey.
**\<hyc>** LOL
**\<DaveyJones>** LOL
**\<dEBRUYNE>** People could apply the RCT PR to the code and test it on their own private testnet
**\<fluffypony>** ok so
**\<moneromooo>** It's already based on latest master. I did removed the forking setup though.
**\<fluffypony>** moneromooo: you mean the PR?
**\<moneromooo>** Yes.
**\<moneromooo>** I kinda expect (1) reviews, (2) merge, (3) testnet, (4) any fixes PR'd separately.
**\<fluffypony>** does the PR have a fork date?
**\<moneromooo>** No.
**\<wallet42>** how to activate it?
**\<dEBRUYNE>** moneromooo: I meant apply as in manually add it because it hasn't been merged yet :-P
**\<i2p-relay> {-anonimal}** Thanks for the link dEBRUYNE
**\<moneromooo>** wallet42: it will activate at the right height, once it is cchosen.
**\<i2p-relay> {-anonimal}** I have to run folks, I'll read the backlog tomorrow.
**\<moneromooo>** see ya
**\<fluffypony>** cheers anonimal
**\<luigi1112>** Yeah it shouldn't have a date
**\<fluffypony>** moneromooo: I don't understand the "right height" thing, plz explain
**\<moneromooo>** Entries in the hard fork table in src/blockchain.cpp.
**\<moneromooo>** (which do not exist yet)
**\<dEBRUYNE>** I think we should set a height that adds 1-2 months to the height after this process has completed -> **\<moneromooo>** I kinda expect (1) reviews, (2) merge, (3) testnet, (4) any fixes PR'd separately.
**\<fluffypony>** so as this stands
**\<fluffypony>** it understands v3 transactions
**\<dEBRUYNE>** Ring CT is such a big change that I think we could deviate once from the HF schedule
**\<moneromooo>** Let me explain versions and stuff about this:
**\<fluffypony>** k
**\<moneromooo>** Currently, we are on HF 2, and tx version 1 is the only one that exists.
**\<moneromooo>** At HF 3 (september on mainnet), pretty much nothing changes.
**\<moneromooo>** At HF 4 (march), rct txes (v2 txes) are allowed. At HF 5 (september in a year), v1 txes are disallowed, except for sweep_unmixable.
**\<moneromooo>** Though the last bit (sweep_unmixable) might be unnecessary, I'm unsure.
**\<fluffypony>** ok
**\<hyc>** sounds fine
**\<moneromooo>** Oh, and at HF 4 (when rct txes are allowed), the coinbase gets in a single out, and is stored as rct, despite not being rct.
**\<moneromooo>** So they can be spent along with rct fake outs.
**\<fluffypony>** oh neat
**\<hyc>** so that also means no quantization then?
**\<moneromooo>** Yes.
**\<dEBRUYNE>** "v1 txes are disallowed" -> does that mean everyone needs to move their coins or will a one time transaction be allowed after that?
**\<moneromooo>** An rct tx may spend pre-rct outputs.
**\<fluffypony>** dEBRUYNE: nobody needs to move anything yet
**\<fluffypony>** or ever, really
**\<hyc>** right, this doesn't affect existing outputs. only newly generated txs
**\<luigi1112>** The block reward thing is neat if it works :-)
**\<JjegrUseinob>** so what will september HF do then?
**\<dEBRUYNE>** fluffypony, hyc: thanks, was asking for clarification
**\<moneromooo>** It does. Was a pita due to breaking the tests, but it all works now :D
**\<fluffypony>** JjegrUseinob: roll over to stick to the schedule, include the next HF date so that nodes notify
**\<fluffypony>** and also include all the fixes to-date
**\<luigi1112>** Quantize the reward afaik
**\<moneromooo>** September fork just enforces the coinbase to be split into denominations.
**\<luigi1112>** (Does someone know the state of pools?)
**\<fluffypony>** moneromooo: are we going to point release with the rct PR merged or before then?
**\<ArticMine>** Does the September HF force min 4 mixin?
**\<hyc>** and that's not a significant brhavior change, right? it was always supposed to be split
**\<moneromooo>** It was suppose dto, but not enforced.
**\<luigi1112>** Rct doesn't really make a difference..it's just dead code until activated
**\<luigi1112>** So the question is are there still offending pools that need to update
**\<moneromooo>** I'm mostly bothered about having this huge chunk of stuff that creats conflicts with evreything now.
**\<fluffypony>** luigi1112: guaranteed that MinerGate is still using their custom stuff and just fudging the version
**\<hyc>** you're talking source code merge conflicts?
**\<hyc>** or something else moneromooo?
**\<moneromooo>** Like, my cold wallet tx patch is now based on rct code.
**\<moneromooo>** Yes, git conflicts.
**\<fluffypony>** I don't have a problem with RCT being merged before the point release
**\<luigi1112>** fluffypony: that's fine :-) anyone else
**\<dEBRUYNE>** \<luigi1112> (Does someone know the state of pools?) <= I can check headers
**\<fluffypony>** tewinget: what's the status on 0MQ?
**\<luigi1112>** I guess minor version and the block reward are good things to check
**\<fluffypony>** maybe we should push for that in the point release if it's nearly done
**\<luigi1112>** (Being denominated)
**\<dEBRUYNE>** Btw fluffypony, in case tewinget isn't here
**\<luigi1112>** Th at can probably be done in the interim between Sept and march?
**\<dEBRUYNE>** This is from the logs:
**\<dEBRUYNE>** **\<tewinget>** I'm a few hours of work (I hope) away from having the wallet using zmq to talk to the daemon
**\<moneromooo>** He said he was starting work on getting the wallet to talk 0MQ yesterday (he'd been using python client with the daemon).
**\<fluffypony>** ok
**\<dEBRUYNE>** luigi1112: minor_version should be 3 right?
**\<hyc>** yes, tewinget was asking for reviews of his branch too
**\<moneromooo>** I guess I should go look ^_^
**\<dEBRUYNE>** anyway, minergate is on "major_version":2,"minor_version":3
**\<dEBRUYNE>** For anyone interested, the 0MQ branch can be found here -> https://github.com/tewinget/bitmonero/tree/zmq-dev
**\<dEBRUYNE>** moneromooo, fluffypony, luigi1112: This is Minergate's coinbase transaction -> http://moneroblocks.info/tx/8a6f45c079da5e400632c29e6b8145fda593a44657881d6d91b232769511c8fc
**\<fluffypony>** ok
**\<dEBRUYNE>** Are there any additional meeting items?
**\<hyc>** quick update on 32-bit support - my blockchain_import is still running :P
**\<fluffypony>** lol
**\<luigi1112>** dEBRUYNE: what about other pools?
**\<dEBRUYNE>** lemme check
**\<fluffypony>** re: the RCT PR, I think we should aim to finish up review and merge by next weekend - any objection, moneromooo ?
**\<moneromooo>** That'd be pretty fast.
**\<moneromooo>** If you can find enough reviewers by then :)
**\<fluffypony>** there will be more review post that
**\<fluffypony>** oh btw moneromooo
**\<fluffypony>** what are your thoughts on the testnet fork dates?
**\<moneromooo>** I should add: along with the rct stuff, that branch has random fixes that would otherwise conflict: better output selection, no signatures stored in wallet, fixes to avoid having to run rescan_spent (I think I got them all).
**\<moneromooo>** I think a few days after all preliminary review + fixes are done. Then 1 day between 3 and 4, and a few days between 4 and 5 (where both tx versions are allowed).
**\<hyc>** moneromooo: as long as those are each in their own commits, we can still tick them off 1 by 1
**\<moneromooo>** They are, yes.
**\<fluffypony>** moneromooo: so then once merged, say next weekend, we can PR testnet fork points
**\<moneromooo>** Yes.
**\<JjegrUseinob>** i never saw clear answer to artic mine question about when min mixin of 4 will be enforced
**\<moneromooo>** No change there for now, but there should be.
**\<hyc>** can we do it this Sept HF?
**\<JjegrUseinob>** thank you moo and hyc. your hard work is appreciated
**\<dEBRUYNE>** luigi1112: All pools listed here -> https://monerohash.com/#network have "major_version":2,"minor_version":3
**\<fluffypony>** ok
**\<fluffypony>** I think that's about it then - code review time
**\<moneromooo>** \<hyc> can we do it this Sept HF?
**\<moneromooo>** (about bumping the network minimum mixin)
**\<hyc>** right
**\<DaveyJones>** so is there a way some chosen folks can put items into an agenda for dev-meeting... just in case fluffy or anyone else dont have time to lead the meeting
**\<moneromooo>** You can always ask something dev related if you wish.
**\<DaveyJones>** so people like debruyne could atleast try to take the host
**\<moneromooo>** It doesn't need to be made known in advance (unless it requires research)
**\<hyc>** mebbe propose agenda items on forum.getmonero.org or something
**\<ArticMine>** Having an agenda ahead of time can be helpful. It does not need to be cast in stone.
**\<JjegrUseinob>** anonimal usually has kovri meeting agenda in advance. i like that system
**\<DaveyJones>** i mean this was the first real dev meeting for a month or sth and even today we had a eating hiccup :p
**\<JjegrUseinob>** when will log from last meeting be on the website?
**\<fluffypony>** lol DaveyJones
**\<fluffypony>** JjegrUseinob: sometime next week, once dEBRUYNE has a chance
**\<JjegrUseinob>** https://getmonero.org/blog/tags/dev%20diaries
**\<JjegrUseinob>** i said last meeting
**\<JjegrUseinob>** pr was merged already
**\<JjegrUseinob>** https://github.com/monero-project/monero-site/pull/135
* hellocccc has quit (Ping timeout: 264 seconds)
**\<fluffypony>** JjegrUseinob: there are issues that have to be fixed
**\<fluffypony>** eg.
* fluffypony Missing key: menu.stackexchange
* fluffypony Liquid Exception: exit in _layouts/default.html
**\<fluffypony>** so I've got to fix those first
**\<dEBRUYNE>** \<fluffypony> JjegrUseinob: sometime next week, once dEBRUYNE has a chance <= I'll PR the logs tomorrow
**\<fluffypony>** planning on doing it tonight
**\<dEBRUYNE>** (today's)
**\<JjegrUseinob>** ok ty
**\<dEBRUYNE>** Anyway, perhaps we should put a bit of thought into whether we want to activate Ring CT in march (and thus on a scheduled date) or activate earlier on a "random" date
**\<hyc>** not sure there's a reason to break the schedule
**\<hyc>** ?
**\<JjegrUseinob>** competition from zcash seems like a good reason IF rct is ready to activate and tested enough
**\<moneromooo>** I just realized it reads like Z(ooko)Cash.
**\<DaveyJones>** that was intented i guess :p
**\<ArticMine>** I am with staying on schedule with RingCT in March.
**\<luigi1112>** I think rushing because "competition" is I'll advised here
**\<luigi1112>** Ill
**\<grimpants>** yes
**\<hyc>** agreed
**\<ArticMine>** Very ill advised
**\<moneromooo>** The thing I'd move if we could is the september one, to a bit later, but that might break non-updaters...
**\<moneromooo>** As we need to have a binary a couple weeks before, in order for most to update in time.
**\<luigi1112>** I don't think we should enforce mix 4 here since it's not in existing code
**\<dEBRUYNE>** It's good to hear thoughts from everyone on this subject
**\<luigi1112>** It'd be a rush release
**\<ArticMine>** Then min mix 4 is scheduled for March?
**\<DaveyJones>** question is ... are non updaters an issue atm? i mean we are still small and in a small community people should be able to update once in 6 months ?
**\<luigi1112>** Mix 4 goes well with rct
**\<luigi1112>** I'm not sure it needs to be enforced until v1 is disallowed
**\<ArticMine>** So let us make it for march
**\<luigi1112>** That's not till 1 year from now by current rhoughts
**\<moneromooo>** That'd be september, for v1 to be disallowed.
**\<gingeropolous>** someone mentioned that moving the HF date up would, in general, be good for those that need truly private currency. But I also see the benefit of sticking to schedule
**\<moneromooo>** Well, stuff like the new coin selection will be active as soon as it's merged, since it's wallet behavior. So there'll be some betterment already.
**\<moneromooo>** And transfer maps to transfer_new, too. So no more shitty dust for multi-tx.
**\<gingeropolous>** i wanted to try and get into that code for the "find set that matches" behavior... someday.
**\<JjegrUseinob>** why cant we point release those improvements soon then and have ringct fork late oct or nov?
**\<JjegrUseinob>** for march enforcement
**\<moneromooo>** It's a difficult problem to find the best set.
**\<nioc>** It had been mentioned previously that in the early stages the HF schedule could be adjusted considering the important changes that need to be implemented.
**\<moneromooo>** I don't think it's particularly important to keep to the march date, since I doubt many people will bang on testnet once a new release is out, so it'd just wait there.
**\<moneromooo>** I mean, more time would not mean more testing.
**\<gingeropolous>** \<JjegrUseinob> why cant we point release those improvements soon then and have ringct fork late oct or nov? - well, the arguments against this is that we're setting precedent for non-scheduled, at-whim, as-needed forking, and if we're trying to create a culture of "forking is ok", then the schedule has a particular... weight to it, perhaps
**\<hyc>** hardforks good, more is better :P
**\<JjegrUseinob>** i thought that monero had a social contract that largely supported flexibility this year for rct fork
**\<gingeropolous>** but im on the fence as well... I still think we're small enough of a thing that we could pull it off
**\<dEBRUYNE>** It was discussed before that if we would deviate from the schedule, we would only deviate once for RCT
**\<fluffypony>** Monero Classic is going to have weekly hard forks
**\<moneromooo>** Yes. Hardforks every two months, maybe many of them not actiually changing anything... would allow easy scheduling of changes without havinhg to wait forecer.
**\<fluffypony>** :-P
**\<fluffypony>** JjegrUseinob is right though
**\<gingeropolous>** autoupdate all the things. moo's favorite
**\<fluffypony>** we did say that we might adjust them at the beginning, and that we'd taper down to annual hard forks (or further apart) later on
**\<DaveyJones>** can we have replay attacks too? for classic
**\<fluffypony>** so if testnet is successful and everything is fine we can consider moving itup
**\<fluffypony>** *it up
**\<JjegrUseinob>** :
**\<JjegrUseinob>** :)
**\<hyc>** ok, that sounds fine. when we're happy with the code integrity and test phase
**\<gingeropolous>** im down with that. Fork early, fork often
**\<moneromooo>** And bump mixin at this one ? Or the one after it ?
**\<DaveyJones>** monero is a flexible adolescent... we will stiffen by time :p
**\<dEBRUYNE>** \<fluffypony> so if testnet is successful and everything is fine we can consider moving itup <= I'd be fine with that too
**\<dEBRUYNE>** let's make sure miners have enough time to update and receive notification
**\<fluffypony>** moneromooo: bump mixin at Sept hardfork
**\<dEBRUYNE>** so 1-2 months after the full "process"
**\<fluffypony>** mixin will bump anyway for rct right
**\<moneromooo>** So HF 5 ? Which might not be september if we being march forward.
**\<moneromooo>** Min mixin was not touched in the rct banch.
**\<fluffypony>** oh
**\<fluffypony>** we're going to have to bump it for definite
**\<luigi1112>** Don't bumb for September imo
**\<luigi1112>** Bump
**\<luigi1112>** It's too soon
**\<hyc>** I suppose it ought to run on testnet first
**\<moneromooo>** So 4, in HF 4 (with rct enable) ?
**\<luigi1112>** This september
**\<luigi1112>** I vote for next September but I'm somewhat ambivalent vs march
**\<ArticMine>** Is there a reason for Sept 2017 vs March 2017 for enforcing mixin 4?
**\<luigi1112>** Yes, it is better with ringct
**\<luigi1112>** Which will be enforced then
**\<moneromooo>** Oh, and the size increase as a function of mixin is rather shallow. So we can go wild.
**\<hyc>** it seems to me min mixin 4 is a good thing regardless of rct. why wait
**\<luigi1112>** It adds forced "junk data" for 6 months...but not a large deal most likely
**\<moneromooo>** It's not junk, it's lovely privacy preserving data :P
**\<moneromooo>** Or we can do 3 in march, 4 in september :)
**\<ArticMine>** So an additional TX size issue for six months that is solved with RingCT
**\<moneromooo>** rct txes will be larger.
**\<moneromooo>** About 13 kB I think. A lot more constant than current.
**\<ArticMine>** But there is a tradeoff in the need to mix the inputs broken down in powers of 10
**\<moneromooo>** Ah, you mean to get a "privacy equivalence" ?
**\<ArticMine>** Yes
**\<moneromooo>** The new coin selection should help there too I think.
**\<hyc>** we should be winding up and letting the kovri mtg start
**\<hyc>** do we have any decisions on bumping mixin?
**\<moneromooo>** anonimal left, no kovri meeting.
**\<hyc>** ok
**\<moneromooo>** I guess I'll do mixin 4 for HF 5 then, unless new stuff gets said.
**\<ArticMine>** Sounds fine to me
**\<hyc>** ok
**\<moneromooo>** As an incentive for reviewers to review, my cold wallet signing patch is now based on the ringct branch, so it can't be merged without rct being merged first ^_^
**\<JjegrUseinob>** cold wallet signing patch will be a great feature. thanks mooooo
**\<fluffypony>** ok I fixed the stuff that was breaking on the site
**\<tewinget>** fluffypony: what dEBRUYNE said.
**\<tewinget>** I totally forgot there was a dev meeting and slept right through it, woops.
**\<moneromooo>** You can still tell us how far you are, most people are still in the channel :)
**\<othe>** better than me, i thought i am in this channel...but i wasn´t
**\<tewinget>** Well, there's 5-10 daemon RPC commands yet to implement, but I'm leaving them for now because they're mining/miner related. Next thing to do (hopefully yet today) is some first pass at "libdaemonrpc" and making the wallet use it.
**\<othe>** does ur todo list include authentication too? the current way is kinda bah
**\<tewinget>** othe: yes, but that will be something to look at after the rest is sorted, I think.
**\<othe>** good
**\<moneromooo>** Oh, that reminds me.
**\<moneromooo>** The previous 0mq branch had something called net_skeleton, which was doing some middle layer ntworking stuff, but was GPL so needed replacing.
**\<moneromooo>** Have you found a replacement ? Kovri uses cpp-netlib, and I was thinking using the same would be good if it fits, since more people would know, etc.
**\<tewinget>** I'm just using zmq...
**\<tewinget>** idk what he (oranjuice, I think?) was using net_skeleton for.
**\<moneromooo>** Yes, that was him/her. And I dunno either :)
**\<othe>** i only know that theirs a license issue with that anyway
**\<othe>** nvm...
**\<othe>** didnt we want to replace epee with net skeleton?
**\<tewinget>** othe: good question, to which I haven't an answer.
**\<gingeropolous>** be sweet to get a graphical version of whatever was decided re: HF and rule versions today
**\<gingeropolous>** i.e., timeline
**\<gingeropolous>** cause again, the lack of harmony with all these version numbers is confusing
**\<fluffypony>** oh
**\<fluffypony>** tewinget / moneromooo
**\<fluffypony>** net_skeleton had nothing to do with 0MQ
**\<fluffypony>** once 0MQ is in we still have to offer a JSON RPC API, right
**\<fluffypony>** and that has to be able to provide TLS and simple auth
**\<tewinget>** \<fluffypony> once 0MQ is in we still have to offer a JSON RPC API, right <-- err...about that
**\<fluffypony>** so we'd have a new helper app for JSON RPC API
**\<fluffypony>** tewinget: it's in the spec
**\<tewinget>** the zmq implementation thus far *is* a json rpc
**\<fluffypony>** no
**\<fluffypony>** JSON RPC API is a standard
**\<tewinget>** oh, right, that
**\<fluffypony>** http://json-rpc.org
**\<tewinget>** I mean, I've got it nearly identical to that standard, so it wouldn't take much doing to change it to exactly that
**\<fluffypony>** you're just serialising data in JSON
**\<tewinget>** test_str = {
**\<tewinget>** "request": "get_blocks_fast",
**\<tewinget>** "version": 1,
**\<tewinget>** "message": {
**\<tewinget>** "block_ids": ["418015bb9ae982a1975da7d79277c2705727a56894ba0fb246adaabb1f4632e3"],
**\<tewinget>** "start_height": 10
**\<fluffypony>** the HTTP-based JSON RPC API is familiar to integrators
**\<tewinget>** }
**\<tewinget>** }
**\<tewinget>** that's pretty close to the standard
**\<fluffypony>** so we have to provide that layer
**\<tewinget>** I'll just have to change it a little
**\<tewinget>** oh, you mean http-based
**\<fluffypony>** yes
**\<fluffypony>** that's what net_skeleton was doing
**\<tewinget>** which spec do you mean, 1.0 or 2.0?
**\<tewinget>** because 1.0 mentions HTTP, but doesn't specify that it's necessary as part of the spec, if I'm reading it correctly. :P
**\<tewinget>** that said, HTTP makes sense I suppose, just will take a bit of doing.
**\<fluffypony>** it's transport agnostic, but every single client library supports HTTP and no other transports, lol
**\<fluffypony>** ok but back up a second
**\<fluffypony>** don't go running ahead and changing things just yet
**\<tewinget>** wasn't planning to
**\<fluffypony>** if I'm a client application talking 0MQ to the daemon I need to have some optional authentication, which 0MQ provides support for
**\<fluffypony>** I'd only use that if I'm talking remotely to the daemon
**\<tewinget>** with you so far
**\<fluffypony>** same goes for encryption - not necessary on localhost
**\<fluffypony>** so then we have this little stub applications, let's call them monero-rpc-daemon and monero-rpc-wallet
**\<fluffypony>** they have an HTTP server
**\<fluffypony>** and they talk 0MQ to the daemon
**\<tewinget>** even that's slightly overcomplicated I think
**\<tewinget>** just monero-rpc-http as one binary
**\<fluffypony>** yeah that's fine too - as long as wallet-ing is optional
**\<tewinget>** launch it with the correct bind ports and forward ports and it doesn't have to know which type of rpc daemon it's talking to
**\<tewinget>** same binary would work for both wallet rpc and daemon rpc (and others if ever there are any)
**\<fluffypony>** it can't be a dumb client though
**\<tewinget>** right, it'll have to have auth parameters as well
**\<fluffypony>** otherwise you're going dumb client -> rpc-wallet -> daemon
**\<fluffypony>** three binaries
**\<fluffypony>** ie. it has to have local wallet functionality
**\<fluffypony>** that talks to a daemon over 0MQ
**\<fluffypony>** ie. simplewallet gets separated out into cli-wallet and rpc-wallet
**\<fluffypony>** both of which use 0MQ to communicate with the daemon
**\<fluffypony>** and rpc-wallet can provide both HTTP and 0MQ interfaces, at a later stage, but definitely HTTP initially
**\<tewinget>** so you're saying you want to wrap http-speaking into the rpc-wallet binary?
**\<fluffypony>** simplewallet already talks HTTP
**\<fluffypony>** when you put it in RPC mode, I mean
**\<tewinget>** doesn't the daemon already do so as well with the current RPC?
**\<fluffypony>** yes - and we have to support that also to be backwards compatible, but that's another story
**\<tewinget>** you might hate this idea, but bear with me. I was thinking for backwards-compatibility to just leave the old RPC in place until it's completely deprecated, probably with a compile flag that disables compiling it in by default.
**\<tewinget>** not the cleanest solution, granted, but seems pragmatic imo
**\<fluffypony>** I do hate that idea, purely because I want to rip that code out :-P
**\<tewinget>** so what I was thinking is to have the zmq rpc for whatever binary needs it (wallet, daemon, etc) and then have an optional transparent bridge for http (possibly less transparent if using SSL over http is desired)
**\<tewinget>** but having said bridge layer live inside the {daemon,wallet,etc} binary is okay too, I suppose.
**\<fluffypony>** so what happens if I'm a well-designed exchange, and I have the daemon on a different machine to the wallet
**\<fluffypony>** and I want to talk HTTPS to the wallet
**\<tewinget>** HTTPS request -> wallet -> daemon? I'm not sure I understand why you ask.
**\<fluffypony>** yes precisely
**\<tewinget>** or with the bridge as a separate binary, HTTPS request -> bridge -> wallet -> daemon
**\<fluffypony>** the daemon is exposed to the Internet
**\<fluffypony>** it can be attacked
**\<fluffypony>** the wallet is sensitive, so it lives behind the DMZ
**\<tewinget>** okay...
**\<fluffypony>** your second one solves the case as long as I'm happy starting up a bunch of things
**\<fluffypony>** also you'd need rpc-wallet to provide a 0MQ interface
**\<fluffypony>** and then bridge -> wallet talks 0MQ
**\<tewinget>** I intend for it to.
**\<tewinget>** why would the wallet libs *not* have a 0mq interface? Need that anyway for GUIs and shit, right?
**\<tewinget>** err...nvm, dumb question
**\<fluffypony>** 0MQ client != 0MQ interface
**\<tewinget>** yea, I was thinking the wallet would run and a GUI would connect to it via 0mq, but the GUI can just use libwallet directly.
**\<fluffypony>** yes
**\<tewinget>** that having been said, at some point off in the future I might look into using 0mq's intra-process stuff for message passing.
**\<tewinget>** but that's a long time in the future
**\<fluffypony>** yeah
**\<tewinget>** so from a code reuse standpoint, to me it makes more sense to have a bridge binary that speaks HTTP(S) and 0mq, and to have both wallet and daemon speak 0mq.
**\<fluffypony>** yeah agreed
**\<tewinget>** hmm...even that's not necessarily true, it wouldn't be too bad to have both speak both.
**\<tewinget>** or rather have the wallet *just* speak http(s) to the wild, and use libdaemonrpc or w/e to speak 0mq to the daemon
**\<tewinget>** all of the message system I've written for the 0mq so far is transport-agnostic, so that's the good news :)
**\<tewinget>** (as it should be, but I'm just pointing it out for the sake of...well, having pointed it out, I guess)
**\<tewinget>** fluffypony: for what it's worth, libwallet will need to have the same type of messaging system as I've implemented in the daemon, and the zmq-specific stuff is tiny, so if we do decide we do want the wallet to speak 0mq it should be a (relatively) trivial change in the end.
**\<fluffypony>** kk
**\<wallet42>** moneromoo: rewview guidelines?
**\<moneromooo>** wallet42: well, whatever you feel comfortable with. Do you have anything in mind ?
**\<i2p-relay> {-anonimal}** Is there a meeting in a few minutes?
**\<moneromooo>** The most important is potential for exploits.
**\<moneromooo>** Yes.
**\<hyc>** awesome
**\<moneromooo>** Well, assuming the pony isn't too busy with mymonero.
**\<darkcoinspy>** get your notepads out everyone. time to take notes on the competition
**\<i2p-relay> {-anonimal}** Which competition?
**\<moneromooo>** I think he just meant dash is still around. It's another crypto (ex darkcoin).
**\<dEBRUYNE>** \<moneromooo> Well, assuming the pony isn't too busy with mymonero. <= he was online 20 min ago, fwiw :p
**\<hyc>** fixing mymonero...
**\<dEBRUYNE>** :-P
**\<alex\_\_\_>** what happened to mymonero?
**\<hyc>** its blockchain got stuck
**\<alex\_\_\_>** ah ok
**\<dEBRUYNE>** alex\_\_\_: \<\_Telegram> \<fluffypony> there were like 6 imports running which deadlocked the database
**\<hyc>** I thought we fixed db\_open to disallow more than 1 process on the DB at a time
**\<moneromooo>** Might be talking about his sql db I think.
**\<hyc>** ah
**\<hyc>** too bad. we've been working on an LMDB backend for mysql/mariadb but not much progress in a long time
**\<DaveyJones>** isnt there supposed to be a meeting? xD
**\<JjegrUseinob>** yes
**\<JjegrUseinob>** waiting on poniex
**\<JjegrUseinob>** ponies
**\<hyc>** fluffypony fluffypony fluffypony ?
**\<JjegrUseinob>** fluffypony may be drinking wine right now
**\<JjegrUseinob>** have you seen his wine rack?
**\<i2p-relay> {-anonimal}** Yes, epic.
**\<JjegrUseinob>** im about to go get a drink myself
**\<JjegrUseinob>** brb
**\<hyc>** good idea
**\<dEBRUYNE>** moneromooo, hyc: perhaps someone else can take the lead until he returns?
**\<hyc>** if we had an agenda in advance that'd work. I've got no idea what needs to be covered today
**\<moneromooo>** Well, I have just one thing to say, really: reviewers wanted (even for part of the stuff).
**\<hyc>** OK, that's a good topic. So there's now a PR for the RingCT code
**\<hyc>** which means it's presumably functionally complete and ready for heavy testing
**\<dEBRUYNE>** \<hyc> if we had an agenda in advance that'd work. I've got no idea what needs to be covered today <= let's just discuss Ring CT first and the additional open PRs
**\<DaveyJones>** paging othe, luigi1111w, luigi1112, othe, tewinget too
**\<i2p-relay> {-anonimal}** Congratulations to everyone involved on that. Its a big one.
**\<moneromooo>** Yes. I don't think I've got anything else to add, until luigi finds something else he wants to change.
**\<DaveyJones>** maybe smooth too
**\<moneromooo>** But reviewing this isn't going to be wasted anyway, even if he finds something.
**\<dEBRUYNE>** ^ NoodleDoodle, ArticMine
**\<DaveyJones>** but the agenda thing would be nice for such incidents
**\<dEBRUYNE>** moneromooo: Is there a way people can help with testing?
**\<i2p-relay> {-anonimal}** moneromooo: is there anything in particular that needs attention in terms of review?
**\<ArticMine>** RingCT is going to need heavy testing and a public testnet would be a great asset for this
**\<moneromooo>** Well, the private fork branch is out of date now, there'll be a public testnet once there's a modicum of review I expect.
**\<wallet42>** I would love to setup and pay for a public testnet with a couple nodes
**\<dEBRUYNE>** Fwiw, there's a guide to setup a private tesnet -> https://moneroexamples.github.io/private-testnet/
**\<fluffypony>** sorry just got in
**\<luigi1112>** Sounds good :-)
**\<fluffypony>** was eating
**\<moneromooo>** Hay.
**\<moneromooo>** er, I mean... hey.
**\<hyc>** LOL
**\<DaveyJones>** LOL
**\<dEBRUYNE>** People could apply the RCT PR to the code and test it on their own private testnet
**\<fluffypony>** ok so
**\<moneromooo>** It's already based on latest master. I did removed the forking setup though.
**\<fluffypony>** moneromooo: you mean the PR?
**\<moneromooo>** Yes.
**\<moneromooo>** I kinda expect (1) reviews, (2) merge, (3) testnet, (4) any fixes PR'd separately.
**\<fluffypony>** does the PR have a fork date?
**\<moneromooo>** No.
**\<wallet42>** how to activate it?
**\<dEBRUYNE>** moneromooo: I meant apply as in manually add it because it hasn't been merged yet :-P
**\<i2p-relay> {-anonimal}** Thanks for the link dEBRUYNE
**\<moneromooo>** wallet42: it will activate at the right height, once it is cchosen.
**\<i2p-relay> {-anonimal}** I have to run folks, I'll read the backlog tomorrow.
**\<moneromooo>** see ya
**\<fluffypony>** cheers anonimal
**\<luigi1112>** Yeah it shouldn't have a date
**\<fluffypony>** moneromooo: I don't understand the "right height" thing, plz explain
**\<moneromooo>** Entries in the hard fork table in src/blockchain.cpp.
**\<moneromooo>** (which do not exist yet)
**\<dEBRUYNE>** I think we should set a height that adds 1-2 months to the height after this process has completed -> **\<moneromooo>** I kinda expect (1) reviews, (2) merge, (3) testnet, (4) any fixes PR'd separately.
**\<fluffypony>** so as this stands
**\<fluffypony>** it understands v3 transactions
**\<dEBRUYNE>** Ring CT is such a big change that I think we could deviate once from the HF schedule
**\<moneromooo>** Let me explain versions and stuff about this:
**\<fluffypony>** k
**\<moneromooo>** Currently, we are on HF 2, and tx version 1 is the only one that exists.
**\<moneromooo>** At HF 3 (september on mainnet), pretty much nothing changes.
**\<moneromooo>** At HF 4 (march), rct txes (v2 txes) are allowed. At HF 5 (september in a year), v1 txes are disallowed, except for sweep\_unmixable.
**\<moneromooo>** Though the last bit (sweep\_unmixable) might be unnecessary, I'm unsure.
**\<fluffypony>** ok
**\<hyc>** sounds fine
**\<moneromooo>** Oh, and at HF 4 (when rct txes are allowed), the coinbase gets in a single out, and is stored as rct, despite not being rct.
**\<moneromooo>** So they can be spent along with rct fake outs.
**\<fluffypony>** oh neat
**\<hyc>** so that also means no quantization then?
**\<moneromooo>** Yes.
**\<dEBRUYNE>** "v1 txes are disallowed" -> does that mean everyone needs to move their coins or will a one time transaction be allowed after that?
**\<moneromooo>** An rct tx may spend pre-rct outputs.
**\<fluffypony>** dEBRUYNE: nobody needs to move anything yet
**\<fluffypony>** or ever, really
**\<hyc>** right, this doesn't affect existing outputs. only newly generated txs
**\<luigi1112>** The block reward thing is neat if it works :-)
**\<JjegrUseinob>** so what will september HF do then?
**\<dEBRUYNE>** fluffypony, hyc: thanks, was asking for clarification
**\<moneromooo>** It does. Was a pita due to breaking the tests, but it all works now :D
**\<fluffypony>** JjegrUseinob: roll over to stick to the schedule, include the next HF date so that nodes notify
**\<fluffypony>** and also include all the fixes to-date
**\<luigi1112>** Quantize the reward afaik
**\<moneromooo>** September fork just enforces the coinbase to be split into denominations.
**\<luigi1112>** (Does someone know the state of pools?)
**\<fluffypony>** moneromooo: are we going to point release with the rct PR merged or before then?
**\<ArticMine>** Does the September HF force min 4 mixin?
**\<hyc>** and that's not a significant brhavior change, right? it was always supposed to be split
**\<moneromooo>** It was suppose dto, but not enforced.
**\<luigi1112>** Rct doesn't really make a difference..it's just dead code until activated
**\<luigi1112>** So the question is are there still offending pools that need to update
**\<moneromooo>** I'm mostly bothered about having this huge chunk of stuff that creats conflicts with evreything now.
**\<fluffypony>** luigi1112: guaranteed that MinerGate is still using their custom stuff and just fudging the version
**\<hyc>** you're talking source code merge conflicts?
**\<hyc>** or something else moneromooo?
**\<moneromooo>** Like, my cold wallet tx patch is now based on rct code.
**\<moneromooo>** Yes, git conflicts.
**\<fluffypony>** I don't have a problem with RCT being merged before the point release
**\<luigi1112>** fluffypony: that's fine :-) anyone else
**\<dEBRUYNE>** \<luigi1112> (Does someone know the state of pools?) <= I can check headers
**\<fluffypony>** tewinget: what's the status on 0MQ?
**\<luigi1112>** I guess minor version and the block reward are good things to check
**\<fluffypony>** maybe we should push for that in the point release if it's nearly done
**\<luigi1112>** (Being denominated)
**\<dEBRUYNE>** Btw fluffypony, in case tewinget isn't here
**\<luigi1112>** Th at can probably be done in the interim between Sept and march?
**\<dEBRUYNE>** This is from the logs:
**\<dEBRUYNE>** **\<tewinget>** I'm a few hours of work (I hope) away from having the wallet using zmq to talk to the daemon
**\<moneromooo>** He said he was starting work on getting the wallet to talk 0MQ yesterday (he'd been using python client with the daemon).
**\<fluffypony>** ok
**\<dEBRUYNE>** luigi1112: minor\_version should be 3 right?
**\<hyc>** yes, tewinget was asking for reviews of his branch too
**\<moneromooo>** I guess I should go look ^\_^
**\<dEBRUYNE>** anyway, minergate is on "major\_version":2,"minor\_version":3
**\<dEBRUYNE>** For anyone interested, the 0MQ branch can be found here -> https://github.com/tewinget/bitmonero/tree/zmq-dev
**\<dEBRUYNE>** moneromooo, fluffypony, luigi1112: This is Minergate's coinbase transaction -> http://moneroblocks.info/tx/8a6f45c079da5e400632c29e6b8145fda593a44657881d6d91b232769511c8fc
**\<fluffypony>** ok
**\<dEBRUYNE>** Are there any additional meeting items?
**\<hyc>** quick update on 32-bit support - my blockchain\_import is still running :P
**\<fluffypony>** lol
**\<luigi1112>** dEBRUYNE: what about other pools?
**\<dEBRUYNE>** lemme check
**\<fluffypony>** re: the RCT PR, I think we should aim to finish up review and merge by next weekend - any objection, moneromooo ?
**\<moneromooo>** That'd be pretty fast.
**\<moneromooo>** If you can find enough reviewers by then :)
**\<fluffypony>** there will be more review post that
**\<fluffypony>** oh btw moneromooo
**\<fluffypony>** what are your thoughts on the testnet fork dates?
**\<moneromooo>** I should add: along with the rct stuff, that branch has random fixes that would otherwise conflict: better output selection, no signatures stored in wallet, fixes to avoid having to run rescan\_spent (I think I got them all).
**\<moneromooo>** I think a few days after all preliminary review + fixes are done. Then 1 day between 3 and 4, and a few days between 4 and 5 (where both tx versions are allowed).
**\<hyc>** moneromooo: as long as those are each in their own commits, we can still tick them off 1 by 1
**\<moneromooo>** They are, yes.
**\<fluffypony>** moneromooo: so then once merged, say next weekend, we can PR testnet fork points
**\<moneromooo>** Yes.
**\<JjegrUseinob>** i never saw clear answer to artic mine question about when min mixin of 4 will be enforced
**\<moneromooo>** No change there for now, but there should be.
**\<hyc>** can we do it this Sept HF?
**\<JjegrUseinob>** thank you moo and hyc. your hard work is appreciated
**\<dEBRUYNE>** luigi1112: All pools listed here -> https://monerohash.com/#network have "major\_version":2,"minor\_version":3
**\<fluffypony>** ok
**\<fluffypony>** I think that's about it then - code review time
**\<moneromooo>** \<hyc> can we do it this Sept HF?
**\<moneromooo>** (about bumping the network minimum mixin)
**\<hyc>** right
**\<DaveyJones>** so is there a way some chosen folks can put items into an agenda for dev-meeting... just in case fluffy or anyone else dont have time to lead the meeting
**\<moneromooo>** You can always ask something dev related if you wish.
**\<DaveyJones>** so people like debruyne could atleast try to take the host
**\<moneromooo>** It doesn't need to be made known in advance (unless it requires research)
**\<hyc>** mebbe propose agenda items on forum.getmonero.org or something
**\<ArticMine>** Having an agenda ahead of time can be helpful. It does not need to be cast in stone.
**\<JjegrUseinob>** anonimal usually has kovri meeting agenda in advance. i like that system
**\<DaveyJones>** i mean this was the first real dev meeting for a month or sth and even today we had a eating hiccup :p
**\<JjegrUseinob>** when will log from last meeting be on the website?
**\<fluffypony>** lol DaveyJones
**\<fluffypony>** JjegrUseinob: sometime next week, once dEBRUYNE has a chance
**\<JjegrUseinob>** https://getmonero.org/blog/tags/dev%20diaries
**\<JjegrUseinob>** i said last meeting
**\<JjegrUseinob>** pr was merged already
**\<JjegrUseinob>** https://github.com/monero-project/monero-site/pull/135
* hellocccc has quit (Ping timeout: 264 seconds)
**\<fluffypony>** JjegrUseinob: there are issues that have to be fixed
**\<fluffypony>** eg.
* fluffypony Missing key: menu.stackexchange
* fluffypony Liquid Exception: exit in \_layouts/default.html
**\<fluffypony>** so I've got to fix those first
**\<dEBRUYNE>** \<fluffypony> JjegrUseinob: sometime next week, once dEBRUYNE has a chance <= I'll PR the logs tomorrow
**\<fluffypony>** planning on doing it tonight
**\<dEBRUYNE>** (today's)
**\<JjegrUseinob>** ok ty
**\<dEBRUYNE>** Anyway, perhaps we should put a bit of thought into whether we want to activate Ring CT in march (and thus on a scheduled date) or activate earlier on a "random" date
**\<hyc>** not sure there's a reason to break the schedule
**\<hyc>** ?
**\<JjegrUseinob>** competition from zcash seems like a good reason IF rct is ready to activate and tested enough
**\<moneromooo>** I just realized it reads like Z(ooko)Cash.
**\<DaveyJones>** that was intented i guess :p
**\<ArticMine>** I am with staying on schedule with RingCT in March.
**\<luigi1112>** I think rushing because "competition" is I'll advised here
**\<luigi1112>** Ill
**\<grimpants>** yes
**\<hyc>** agreed
**\<ArticMine>** Very ill advised
**\<moneromooo>** The thing I'd move if we could is the september one, to a bit later, but that might break non-updaters...
**\<moneromooo>** As we need to have a binary a couple weeks before, in order for most to update in time.
**\<luigi1112>** I don't think we should enforce mix 4 here since it's not in existing code
**\<dEBRUYNE>** It's good to hear thoughts from everyone on this subject
**\<luigi1112>** It'd be a rush release
**\<ArticMine>** Then min mix 4 is scheduled for March?
**\<DaveyJones>** question is ... are non updaters an issue atm? i mean we are still small and in a small community people should be able to update once in 6 months ?
**\<luigi1112>** Mix 4 goes well with rct
**\<luigi1112>** I'm not sure it needs to be enforced until v1 is disallowed
**\<ArticMine>** So let us make it for march
**\<luigi1112>** That's not till 1 year from now by current rhoughts
**\<moneromooo>** That'd be september, for v1 to be disallowed.
**\<gingeropolous>** someone mentioned that moving the HF date up would, in general, be good for those that need truly private currency. But I also see the benefit of sticking to schedule
**\<moneromooo>** Well, stuff like the new coin selection will be active as soon as it's merged, since it's wallet behavior. So there'll be some betterment already.
**\<moneromooo>** And transfer maps to transfer\_new, too. So no more shitty dust for multi-tx.
**\<gingeropolous>** i wanted to try and get into that code for the "find set that matches" behavior... someday.
**\<JjegrUseinob>** why cant we point release those improvements soon then and have ringct fork late oct or nov?
**\<JjegrUseinob>** for march enforcement
**\<moneromooo>** It's a difficult problem to find the best set.
**\<nioc>** It had been mentioned previously that in the early stages the HF schedule could be adjusted considering the important changes that need to be implemented.
**\<moneromooo>** I don't think it's particularly important to keep to the march date, since I doubt many people will bang on testnet once a new release is out, so it'd just wait there.
**\<moneromooo>** I mean, more time would not mean more testing.
**\<gingeropolous>** \<JjegrUseinob> why cant we point release those improvements soon then and have ringct fork late oct or nov? - well, the arguments against this is that we're setting precedent for non-scheduled, at-whim, as-needed forking, and if we're trying to create a culture of "forking is ok", then the schedule has a particular... weight to it, perhaps
**\<hyc>** hardforks good, more is better :P
**\<JjegrUseinob>** i thought that monero had a social contract that largely supported flexibility this year for rct fork
**\<gingeropolous>** but im on the fence as well... I still think we're small enough of a thing that we could pull it off
**\<dEBRUYNE>** It was discussed before that if we would deviate from the schedule, we would only deviate once for RCT
**\<fluffypony>** Monero Classic is going to have weekly hard forks
**\<moneromooo>** Yes. Hardforks every two months, maybe many of them not actiually changing anything... would allow easy scheduling of changes without havinhg to wait forecer.
**\<fluffypony>** :-P
**\<fluffypony>** JjegrUseinob is right though
**\<gingeropolous>** autoupdate all the things. moo's favorite
**\<fluffypony>** we did say that we might adjust them at the beginning, and that we'd taper down to annual hard forks (or further apart) later on
**\<DaveyJones>** can we have replay attacks too? for classic
**\<fluffypony>** so if testnet is successful and everything is fine we can consider moving itup
**\<fluffypony>** \*it up
**\<JjegrUseinob>** :
**\<JjegrUseinob>** :)
**\<hyc>** ok, that sounds fine. when we're happy with the code integrity and test phase
**\<gingeropolous>** im down with that. Fork early, fork often
**\<moneromooo>** And bump mixin at this one ? Or the one after it ?
**\<DaveyJones>** monero is a flexible adolescent... we will stiffen by time :p
**\<dEBRUYNE>** \<fluffypony> so if testnet is successful and everything is fine we can consider moving itup <= I'd be fine with that too
**\<dEBRUYNE>** let's make sure miners have enough time to update and receive notification
**\<fluffypony>** moneromooo: bump mixin at Sept hardfork
**\<dEBRUYNE>** so 1-2 months after the full "process"
**\<fluffypony>** mixin will bump anyway for rct right
**\<moneromooo>** So HF 5 ? Which might not be september if we being march forward.
**\<moneromooo>** Min mixin was not touched in the rct banch.
**\<fluffypony>** oh
**\<fluffypony>** we're going to have to bump it for definite
**\<luigi1112>** Don't bumb for September imo
**\<luigi1112>** Bump
**\<luigi1112>** It's too soon
**\<hyc>** I suppose it ought to run on testnet first
**\<moneromooo>** So 4, in HF 4 (with rct enable) ?
**\<luigi1112>** This september
**\<luigi1112>** I vote for next September but I'm somewhat ambivalent vs march
**\<ArticMine>** Is there a reason for Sept 2017 vs March 2017 for enforcing mixin 4?
**\<luigi1112>** Yes, it is better with ringct
**\<luigi1112>** Which will be enforced then
**\<moneromooo>** Oh, and the size increase as a function of mixin is rather shallow. So we can go wild.
**\<hyc>** it seems to me min mixin 4 is a good thing regardless of rct. why wait
**\<luigi1112>** It adds forced "junk data" for 6 months...but not a large deal most likely
**\<moneromooo>** It's not junk, it's lovely privacy preserving data :P
**\<moneromooo>** Or we can do 3 in march, 4 in september :)
**\<ArticMine>** So an additional TX size issue for six months that is solved with RingCT
**\<moneromooo>** rct txes will be larger.
**\<moneromooo>** About 13 kB I think. A lot more constant than current.
**\<ArticMine>** But there is a tradeoff in the need to mix the inputs broken down in powers of 10
**\<moneromooo>** Ah, you mean to get a "privacy equivalence" ?
**\<ArticMine>** Yes
**\<moneromooo>** The new coin selection should help there too I think.
**\<hyc>** we should be winding up and letting the kovri mtg start
**\<hyc>** do we have any decisions on bumping mixin?
**\<moneromooo>** anonimal left, no kovri meeting.
**\<hyc>** ok
**\<moneromooo>** I guess I'll do mixin 4 for HF 5 then, unless new stuff gets said.
**\<ArticMine>** Sounds fine to me
**\<hyc>** ok
**\<moneromooo>** As an incentive for reviewers to review, my cold wallet signing patch is now based on the ringct branch, so it can't be merged without rct being merged first ^\_^
**\<JjegrUseinob>** cold wallet signing patch will be a great feature. thanks mooooo
**\<fluffypony>** ok I fixed the stuff that was breaking on the site
**\<tewinget>** fluffypony: what dEBRUYNE said.
**\<tewinget>** I totally forgot there was a dev meeting and slept right through it, woops.
**\<moneromooo>** You can still tell us how far you are, most people are still in the channel :)
**\<othe>** better than me, i thought i am in this channel...but i wasn´t
**\<tewinget>** Well, there's 5-10 daemon RPC commands yet to implement, but I'm leaving them for now because they're mining/miner related. Next thing to do (hopefully yet today) is some first pass at "libdaemonrpc" and making the wallet use it.
**\<othe>** does ur todo list include authentication too? the current way is kinda bah
**\<tewinget>** othe: yes, but that will be something to look at after the rest is sorted, I think.
**\<othe>** good
**\<moneromooo>** Oh, that reminds me.
**\<moneromooo>** The previous 0mq branch had something called net\_skeleton, which was doing some middle layer ntworking stuff, but was GPL so needed replacing.
**\<moneromooo>** Have you found a replacement ? Kovri uses cpp-netlib, and I was thinking using the same would be good if it fits, since more people would know, etc.
**\<tewinget>** I'm just using zmq...
**\<tewinget>** idk what he (oranjuice, I think?) was using net\_skeleton for.
**\<moneromooo>** Yes, that was him/her. And I dunno either :)
**\<othe>** i only know that theirs a license issue with that anyway
**\<othe>** nvm...
**\<othe>** didnt we want to replace epee with net skeleton?
**\<tewinget>** othe: good question, to which I haven't an answer.
**\<gingeropolous>** be sweet to get a graphical version of whatever was decided re: HF and rule versions today
**\<gingeropolous>** i.e., timeline
**\<gingeropolous>** cause again, the lack of harmony with all these version numbers is confusing
**\<fluffypony>** oh
**\<fluffypony>** tewinget / moneromooo
**\<fluffypony>** net\_skeleton had nothing to do with 0MQ
**\<fluffypony>** once 0MQ is in we still have to offer a JSON RPC API, right
**\<fluffypony>** and that has to be able to provide TLS and simple auth
**\<tewinget>** \<fluffypony> once 0MQ is in we still have to offer a JSON RPC API, right <-- err...about that
**\<fluffypony>** so we'd have a new helper app for JSON RPC API
**\<fluffypony>** tewinget: it's in the spec
**\<tewinget>** the zmq implementation thus far \*is* a json rpc
**\<fluffypony>** no
**\<fluffypony>** JSON RPC API is a standard
**\<tewinget>** oh, right, that
**\<fluffypony>** http://json-rpc.org
**\<tewinget>** I mean, I've got it nearly identical to that standard, so it wouldn't take much doing to change it to exactly that
**\<fluffypony>** you're just serialising data in JSON
**\<tewinget>** test\_str = {
**\<tewinget>** "request": "get\_blocks\_fast",
**\<tewinget>** "version": 1,
**\<tewinget>** "message": {
**\<tewinget>** "block\_ids": ["418015bb9ae982a1975da7d79277c2705727a56894ba0fb246adaabb1f4632e3"],
**\<tewinget>** "start\_height": 10
**\<fluffypony>** the HTTP-based JSON RPC API is familiar to integrators
**\<tewinget>** }
**\<tewinget>** }
**\<tewinget>** that's pretty close to the standard
**\<fluffypony>** so we have to provide that layer
**\<tewinget>** I'll just have to change it a little
**\<tewinget>** oh, you mean http-based
**\<fluffypony>** yes
**\<fluffypony>** that's what net\_skeleton was doing
**\<tewinget>** which spec do you mean, 1.0 or 2.0?
**\<tewinget>** because 1.0 mentions HTTP, but doesn't specify that it's necessary as part of the spec, if I'm reading it correctly. :P
**\<tewinget>** that said, HTTP makes sense I suppose, just will take a bit of doing.
**\<fluffypony>** it's transport agnostic, but every single client library supports HTTP and no other transports, lol
**\<fluffypony>** ok but back up a second
**\<fluffypony>** don't go running ahead and changing things just yet
**\<tewinget>** wasn't planning to
**\<fluffypony>** if I'm a client application talking 0MQ to the daemon I need to have some optional authentication, which 0MQ provides support for
**\<fluffypony>** I'd only use that if I'm talking remotely to the daemon
**\<tewinget>** with you so far
**\<fluffypony>** same goes for encryption - not necessary on localhost
**\<fluffypony>** so then we have this little stub applications, let's call them monero-rpc-daemon and monero-rpc-wallet
**\<fluffypony>** they have an HTTP server
**\<fluffypony>** and they talk 0MQ to the daemon
**\<tewinget>** even that's slightly overcomplicated I think
**\<tewinget>** just monero-rpc-http as one binary
**\<fluffypony>** yeah that's fine too - as long as wallet-ing is optional
**\<tewinget>** launch it with the correct bind ports and forward ports and it doesn't have to know which type of rpc daemon it's talking to
**\<tewinget>** same binary would work for both wallet rpc and daemon rpc (and others if ever there are any)
**\<fluffypony>** it can't be a dumb client though
**\<tewinget>** right, it'll have to have auth parameters as well
**\<fluffypony>** otherwise you're going dumb client -> rpc-wallet -> daemon
**\<fluffypony>** three binaries
**\<fluffypony>** ie. it has to have local wallet functionality
**\<fluffypony>** that talks to a daemon over 0MQ
**\<fluffypony>** ie. simplewallet gets separated out into cli-wallet and rpc-wallet
**\<fluffypony>** both of which use 0MQ to communicate with the daemon
**\<fluffypony>** and rpc-wallet can provide both HTTP and 0MQ interfaces, at a later stage, but definitely HTTP initially
**\<tewinget>** so you're saying you want to wrap http-speaking into the rpc-wallet binary?
**\<fluffypony>** simplewallet already talks HTTP
**\<fluffypony>** when you put it in RPC mode, I mean
**\<tewinget>** doesn't the daemon already do so as well with the current RPC?
**\<fluffypony>** yes - and we have to support that also to be backwards compatible, but that's another story
**\<tewinget>** you might hate this idea, but bear with me. I was thinking for backwards-compatibility to just leave the old RPC in place until it's completely deprecated, probably with a compile flag that disables compiling it in by default.
**\<tewinget>** not the cleanest solution, granted, but seems pragmatic imo
**\<fluffypony>** I do hate that idea, purely because I want to rip that code out :-P
**\<tewinget>** so what I was thinking is to have the zmq rpc for whatever binary needs it (wallet, daemon, etc) and then have an optional transparent bridge for http (possibly less transparent if using SSL over http is desired)
**\<tewinget>** but having said bridge layer live inside the {daemon,wallet,etc} binary is okay too, I suppose.
**\<fluffypony>** so what happens if I'm a well-designed exchange, and I have the daemon on a different machine to the wallet
**\<fluffypony>** and I want to talk HTTPS to the wallet
**\<tewinget>** HTTPS request -> wallet -> daemon? I'm not sure I understand why you ask.
**\<fluffypony>** yes precisely
**\<tewinget>** or with the bridge as a separate binary, HTTPS request -> bridge -> wallet -> daemon
**\<fluffypony>** the daemon is exposed to the Internet
**\<fluffypony>** it can be attacked
**\<fluffypony>** the wallet is sensitive, so it lives behind the DMZ
**\<tewinget>** okay...
**\<fluffypony>** your second one solves the case as long as I'm happy starting up a bunch of things
**\<fluffypony>** also you'd need rpc-wallet to provide a 0MQ interface
**\<fluffypony>** and then bridge -> wallet talks 0MQ
**\<tewinget>** I intend for it to.
**\<tewinget>** why would the wallet libs *not* have a 0mq interface? Need that anyway for GUIs and shit, right?
**\<tewinget>** err...nvm, dumb question
**\<fluffypony>** 0MQ client != 0MQ interface
**\<tewinget>** yea, I was thinking the wallet would run and a GUI would connect to it via 0mq, but the GUI can just use libwallet directly.
**\<fluffypony>** yes
**\<tewinget>** that having been said, at some point off in the future I might look into using 0mq's intra-process stuff for message passing.
**\<tewinget>** but that's a long time in the future
**\<fluffypony>** yeah
**\<tewinget>** so from a code reuse standpoint, to me it makes more sense to have a bridge binary that speaks HTTP(S) and 0mq, and to have both wallet and daemon speak 0mq.
**\<fluffypony>** yeah agreed
**\<tewinget>** hmm...even that's not necessarily true, it wouldn't be too bad to have both speak both.
**\<tewinget>** or rather have the wallet *just* speak http(s) to the wild, and use libdaemonrpc or w/e to speak 0mq to the daemon
**\<tewinget>** all of the message system I've written for the 0mq so far is transport-agnostic, so that's the good news :)
**\<tewinget>** (as it should be, but I'm just pointing it out for the sake of...well, having pointed it out, I guess)
**\<tewinget>** fluffypony: for what it's worth, libwallet will need to have the same type of messaging system as I've implemented in the daemon, and the zmq-specific stuff is tiny, so if we do decide we do want the wallet to speak 0mq it should be a (relatively) trivial change in the end.
**\<fluffypony>** kk

654
_posts/2016-08-28-logs-for-the-Kovri-dev-meeting-held-on-2016-08-28.md
View file

@ -2,7 +2,7 @@
layout: post
title: Logs for the Kovri Dev Meeting Held on 2016-08-28
summary: Brief review of what has been completed since last meeting, Kovri Logo, code & open tickets discussion
tags: [dev diaries, i2p, crypto]**
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
@ -10,329 +10,329 @@ author: dEBRUYNE / fluffypony
# Logs
**\<fluffypony>** anonimal: all yours
**\<tewinget>** in the meantime, for those not interested (or relevant to) the kovri meeting, anyone wanna help me test the zmq wallet<->daemon interactions?
**\<meeting-bot> [anonimal]** Proposed meeting items:
**\<tewinget>** oh
**\<tewinget>** shit
**\<meeting-bot> [anonimal]** 1. Greetings
**\<meeting-bot> [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<meeting-bot> [anonimal]** 3. Code + ticket discussion / Q & A
**\<meeting-bot> [anonimal]** 4. Discuss #282
**\<meeting-bot> [anonimal]** 5. Closing #226
**\<meeting-bot> [anonimal]** 6. Closing #105
**\<meeting-bot> [anonimal]** 7. Closing #46
**\<meeting-bot> [anonimal]** 8. Closing #27
**\<meeting-bot> [anonimal]** 9. Any additional meeting items
**\<meeting-bot> [anonimal]** 10. Confirm next meeting date/time
**\<meeting-bot> [anonimal]** btw, twinget, you are *all* relevant to the meeting and you *ALL* should be interested.
**\<meeting-bot> [anonimal]** Its that kind of attitude that is preventable advancing kovri development within monero.
**\<fluffypony>>** +100
**\<meeting-bot> [anonimal]** 1. Greetings
**\<meeting-bot> [anonimal]** Hi, I'm here.
**\<meeting-bot> [fluffypony]** me three
**\<tewinget>>** anonimal (I'm not relevant in the sense that I have no context, need to learn more about it :))
**\<i2p-relay> {-solmar}>** we need all the help we can get
**\<meeting-bot> [fluffypony]** EinMByte ?
**\<ArticMine>>** I will stay for another 20 min then I have to leave.
**\<meeting-bot> [fluffypony]** tks ArticMine
**\<meeting-bot> [anonimal]** Hi ArticMine.
**\<ArticMine>>** Hi
**\<meeting-bot> [anonimal]** Hi solmar, EinMByte, fluffypony.
**\<meeting-bot> [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<meeting-bot> [anonimal]** $ git checkout master && git log --pretty=oneline --no-merges --since=2016-07-31 | wc -l
**\<meeting-bot> [anonimal]** 55
**\<meeting-bot> [anonimal]** - Lots of build work
**\<meeting-bot> [anonimal]** - Reinstate FreeBSD build
**\<meeting-bot> [anonimal]** - Reinstate Clang support
**\<meeting-bot> [anonimal]** - New config features
**\<meeting-bot> [anonimal]** - New logging features
**\<meeting-bot> [anonimal]** - Implemented SNI (part of cpp-netlib)
**\<meeting-bot> [anonimal]** I'm doing work in branch fix-305, not detailed here.
**\<meeting-bot> [anonimal]** We have a new member onbard, 'solmar'. guzzi is back with us too.
**\<meeting-bot> [anonimal]** rakhimov is becoming more active, all great.
**\<meeting-bot> [anonimal]** I hope EinMByte's travels have been well and has returned.
**\<meeting-bot> [solmar] hey all ;)
**\<meeting-bot> [anonimal]** Did I miss anything for point 2.?
**\<fluffypony>** well
**\<fluffypony>** is it worth discussing #325 now?
**\<meeting-bot> [solmar]** the quality assurance document is note worthy but i think you got everything
**\<meeting-bot> [anonimal]** fluffypony: no not yet.
**\<fluffypony>** ok
**\<meeting-bot> [anonimal]** solmar: thanks, good point. Yes solmar and I reworked #58 and introduced it into a tangible guide.
**\<meeting-bot> [anonimal]** Anything on 2. before moving onto 3.?
**\<fluffypony>** nothing more on 2
**\<meeting-bot> [anonimal]** Before 3., did solmar want to formally introduce themself?
**\<meeting-bot> [solmar]** sure i can quickly introduce
**\<meeting-bot> [solmar]** you guys may have seen me kicking around the various monero-related channels in the past few weeks. monero has peaked great interest in me and moving forward will be quite powerful
**\<meeting-bot> [i2p-relay] {-moneromooo}** Welcome :)
**\<meeting-bot> [solmar]** i am switching focus to kovri because of how unmanned the team is but in the next week i would gladly help test ringct code on the testnet
**\<meeting-bot> [fluffypony]** +1
**\<tewinget>** s/peaked/piqued/ <-- fuck English sometimes
**\<meeting-bot> [solmar]** in the meantime i will continue to learn the kovri code to hopefully in the near future begin to make tangible contributions to the code
**\<meeting-bot> [fluffypony]** awesome, everyone should dabble in both
**\<meeting-bot> [solmar]** any interest and help with kovri is greatly appreciated
**\<meeting-bot> [solmar]** i think we can move along to 3. now thanks anominal ;)
**\<meeting-bot> [anonimal]** Alright, thanks solmar.
**\<meeting-bot> [anonimal]** 3. Code + ticket discussion / Q & A
**\<meeting-bot> [anonimal]** I'll open
**\<meeting-bot> [fluffypony]** some of the design decisions in Kovri were influenced by Monero, so no getting away from it, Monero devs ;)
**\<meeting-bot> [anonimal]** Question: WHEN WILL MONERO DEVS START TAKING KOVRI SERIOUSLY?
**\<meeting-bot> [anonimal]** 10 months in now since our november 1st meeting,
**\<meeting-bot> [i2p-relay] {-moneromooo}** Define "taking seriously" ? Send patches ?
**\<tewinget>** anonimal: I take it just as seriously as, say, RingCT, I just haven't had/taken the time to dig into either yet :)
**\<meeting-bot> [anonimal]** As a whole, if I could quantify contributions, I'd say kovri is getting ~5% attention to what bitmonero and ecosystem is getting.
**\<meeting-bot> [anonimal]** moneromooo: anything.
**\<meeting-bot> [i2p-relay] {-moneromooo}** OK, fair enough. A new codebase appearing like that is going to be not so easy to jump back and forth for coders. But I hear your point.
**\<meeting-bot> [i2p-relay] {-moneromooo}** I will try to get into kovri a bit once rct is all done.
**\<meeting-bot> [anonimal]** I understand all the arguments, and I know what sacrifices would need to be made, so I question when and if they will be made.
**\<meeting-bot> [anonimal]** Thanks moneromooo.
**\<meeting-bot> [fluffypony]** the easiest way to get hyc involved it for us to use LMDB for storage of something :-P
**\<meeting-bot> [i2p-relay] {-moneromooo}** (and feel free to remind me of it if I don't :P)
**\<meeting-bot> [i2p-relay] {-moneromooo}** Nah, use liblber for network.
**\<meeting-bot> [anonimal]** fluffypony: this goes for you too, as we'll see with the remaining agenda items.
**\<meeting-bot> [i2p-relay] {-moneromooo}** Make us fast and secure comms!
**\<tewinget>** fluffypony: in the same way as with hyc, the easiest way to get me involved is something needing refactored >_>
**\<meeting-bot> [anonimal]** Anyone else over there have a response beside moneromooo and tewinget?
**\<meeting-bot> [anonimal]** If not, we should move onto other Q & A.
**\<meeting-bot> [fluffypony]** is this still the ticket discussion part?
**\<meeting-bot> [anonimal]** Point 3.
**\<meeting-bot> [fluffypony]** yes - but I mean ticket discussion is part of Q&A or can I bring up a ticket now?
**\<meeting-bot> [anonimal]** I have library questions I would want to debate with EinMByte but I don't think he's around.
**\<meeting-bot> [anonimal]** Sure but that's least priority at the moment.
**\<meeting-bot> [anonimal]** And should be 9.
**\<meeting-bot> [anonimal]** I'd rather move onto 4. if no one has any questions.
**\<meeting-bot> [fluffypony]** kk
**\<meeting-bot> [anonimal]** 4. Discuss #282
**\<meeting-bot> [fluffypony]** ok so
**\<meeting-bot> [i2p-relay] {-moneromooo}** There was a designer guy asking whether help was wanted. He seemed to be after paid work though.
**\<meeting-bot> [fluffypony]** with the Monero logo we used 99designs
**\<meeting-bot> [i2p-relay] {-moneromooo}** eherdesign in #monero
**\<meeting-bot> [fluffypony]** moneromooo: I looked at his stuff, it wasn't mind-blowing
**\<meeting-bot> [fluffypony]** I'd like to move to use 99designs again
**\<meeting-bot> [fluffypony]** ref: https://99designs.com/logo-design/contests/monero-mro-cryptocurrency-logo-design-contest-382486
**\<meeting-bot> [fluffypony]** I'm happy to put the $500 up for that, and then use the FFS to get it back
**\<meeting-bot> [fluffypony]** unless anyone feel we must go for a higher 99designs reward
**\<othe>** i would also sponsor that
**\<meeting-bot> [i2p-relay] {-moneromooo}** * hopes it won't be some shady looking concept
**\<meeting-bot> [i2p-relay] {-ArticMine}** It worked very well for Monero so I say yeas with the same package
**\<meeting-bot> [i2p-relay] {-ArticMine}** yes
**\<meeting-bot> [solmar]** maidsafe also appears to be having success with 99designs so i think it is a good idea
**\<meeting-bot> [fluffypony]** ok - I'll set that up now - do we have any ideas as to what we want to convey?
**\<meeting-bot> [i2p-relay] {-ArticMine}** Well I have to leave now
**\<meeting-bot> [fluffypony]** do we want it to be inspired by the Monero logo, like the MRL logo is?
**\<meeting-bot> [i2p-relay] {-moneromooo}** The essential qualities of garlic.
**\<meeting-bot> [fluffypony]** (ref: https://lab.getmonero.org/logo.png)
**\<meeting-bot> [i2p-relay] {-moneromooo}** ^ great logo
**\<groeg>** (noob here ...) A podcast I follow have a promo code för 99designs. Interesting?
**\<meeting-bot> [fluffypony]** groeg: yes plz, can you PM it to me?
**\<cjd>** you'll want to pm it to fluffypony, not to the bot
**\<cjd>** he's in this irc
**\<meeting-bot> [i2p-relay] {-moneromooo}** Actually... you could rotate the Monero logo 90% clockwise and arrange colors a bit so it looks like a K. With kind of a hidden M.
**\<groeg>** newbie using IRC, looking up how to pm ...
**\<meeting-bot> [i2p-relay] {-moneromooo}** groeg: /query NICKHERE
**\<meeting-bot> [fluffypony]** thanks groeg, got it
**\<meeting-bot> [solmar]** conveying a "veil"-ish esque style to it could be interesting, since kovri means veil in esperanto afaik
**\<meeting-bot> [i2p-relay] {-moneromooo}** 90 degrees, not %, of course -_-
**\<meeting-bot> [fluffypony]** solmar that's pretty much what I was thinking, something along the lines of a network, but it's private
**\<meeting-bot> [fluffypony]** or something
**\<meeting-bot> [fluffypony]** doesn't have to be a "veil" in the literal sense
**\<meeting-bot> [solmar]** ya
**\<meeting-bot> [solmar]** i agree
**\<meeting-bot> [solmar]** ya exactly
**\<meeting-bot> [anonimal]** Sorry, unexpected AFK emergency, unavoidable.
**\<meeting-bot> * anonimal** reading
**\<meeting-bot> [anonimal]** moneromooo: cool idea, maybe someone can run with that.
**\<meeting-bot> [fluffypony]** anonimal: the rotated K thing?
**\<meeting-bot> [fluffypony]** I can suggest that in the 99designs description
**\<meeting-bot> [anonimal]** Yeah, but maybe not literally, just an artistic motive I guess.
**\<meeting-bot> [fluffypony]** yeah
**\<meeting-bot> [anonimal]** But also garlic is a good point as solmar pointed out.
**\<meeting-bot> [fluffypony]** isn't garlic very Tor?
**\<meeting-bot> [anonimal]** So a rotated K inside a garlic clove
**\<meeting-bot> [anonimal]** No, they're onion.
**\<meeting-bot> [fluffypony]** oh yes
**\<meeting-bot> [fluffypony]** my bad
**\<meeting-bot> [anonimal]** onion router similar to garlic routing.
**\<meeting-bot> [anonimal]** Meh, its practically the same vegetable.
**\<meeting-bot> [fluffypony]** lo
**\<meeting-bot> [fluffypony]** lol
**\<meeting-bot> [fluffypony]** we should go wild and create spinach routing
**\<meeting-bot> [anonimal]** lol
**\<meeting-bot> [anonimal]** "Kovri provides essential iron and vitamins"
**\<meeting-bot> [fluffypony]** http://paulkieschedesign.com/blog/wp-content/uploads/2011/12/shandong-logo.jpg <- perfect
**\<meeting-bot> [anonimal]** "Eat kovri today"
**\<meeting-bot> [fluffypony]** the name, not the logo
**\<meeting-bot> [fluffypony]** so for a previous April 1 we renamed Monero to DarkFlarb, so I move that for next year April 1 we rename Kovri to Shandong
**\<meeting-bot> [fluffypony]** ShanDong
**\<meeting-bot> [anonimal]** The ShanDong I2P Router project... hmm...
**\<meeting-bot> [anonimal]** fluffypony: how do we keep track of #282?
**\<meeting-bot> [fluffypony]** lol
**\<meeting-bot> [fluffypony]** anonimal: othe and I will set it up and update in-ticket
**\<meeting-bot> [anonimal]** fluffypony: thanks.
**\<meeting-bot> [anonimal]** Anything else on #282?
**\<meeting-bot> [fluffypony]** nada
**\<meeting-bot> [anonimal]** If we use a dog somewhere in there, and Shandong, we should go with a pug.
**\<groeg>** shandong = 山东 = mountain east
**\<meeting-bot> [fluffypony]** TIL
**\<meeting-bot> [anonimal]** The eastside rugged pug.
**\<groeg>** (literal meaning of the characters)
**\<meeting-bot> [fluffypony]** east mountain pugs unite
**\<meeting-bot> * anonimal** see dog flip gang symbol with fingers
**\<meeting-bot> [fluffypony]** DogeI2P
**\<meeting-bot> [anonimal]** Here we go, lol
**\<meeting-bot> [anonimal]** Ok, 5. Closing #226
**\<meeting-bot> [anonimal]** This is useful when: 1) i2p-relay is down 2) slack is not available or people aren't signed up nor want to sign up
**\<meeting-bot> [anonimal]** I've registered the channels and am idling.
**\<meeting-bot> [fluffypony]** ok so
**\<meeting-bot> [fluffypony]** are we happy running this under the core relay and not the community relay?
**\<meeting-bot> [anonimal]** By community you mean the one in #monero/#monero-dev?
**\<meeting-bot> [fluffypony]** the community one is the one that needmoney90 runs, to Slack / Telegram etc.
**\<meeting-bot> [fluffypony]** the core one is i2p-relay
**\<meeting-bot> [fluffypony]** anonimal: is there a #tahoe-lafs on OFTC?
**\<meeting-bot> [fluffypony]** because I don't want to take tahoe-lafs out the relay list, necessarily
**\<meeting-bot> [anonimal]** fluffypony: yes, with 4 people, no channel topic. Doesn't look official.
**\<meeting-bot> [fluffypony]** ok then I'll just relay it, tough for them
**\<meeting-bot> [anonimal]** They will probably enjoy it.
**\<meeting-bot> [fluffypony]** indeed
**\<meeting-bot> [fluffypony]** ok I'll do that right now
**\<meeting-bot> [anonimal]** So this would be for i2p-relay?
**\<meeting-bot> * anonimal** so many relays, so confused
**\<meeting-bot> [fluffypony]** lol
**\<meeting-bot> [i2p-relay] {-moneromooo}** What's #tahoe-lafs relation with kovri btw ?
**\<meeting-bot> [anonimal]** moneromooo: Nothing really aside from an i2p plugin available to use with tahoe-lafs, AFAIK
**\<meeting-bot> [anonimal]** fluffypony: if you're doing it right now, I'll wait.
**\<meeting-bot> [fluffypony]** moneromooo: they asked me to run a relay, as their relay has disappeared
**\<meeting-bot> [anonimal]** Damn, it's been an hour. Do we continue?
**\<meeting-bot> [fluffypony]** yes - we started late
**\<meeting-bot> [i2p-relay] {-moneromooo}** I think it's mostly up to you, the main kovri person.
**\<meeting-bot> * anonimal** didn't want to stop on necessary bitmonero business
**\<meeting-bot> [anonimal]** fluffypony: do you have to restart the relay? Is #226 resolved?
**\<meeting-bot> [fluffypony]** the bouncer is connected
**\<meeting-bot> [fluffypony]** sec
**\<theRelay__> \<fluffypony@OFTC>** testing
**\<fluffypony>** testing back
**\<meeting-bot> [fluffypony]** and from here
**\<meeting-bot> [fluffypony]** meeting-bot might be interfering with it a little, so I'll fiddle with it after I've killed meeting-bot
**\<meeting-bot> [anonimal]** It's only me and the bot on OFTC
**\<meeting-bot> [anonimal]** Is fluffypony@OFTC actually fluffypony@Freenode ?
**\<meeting-bot> [fluffypony]** no I don't know - I need to check if it's relaying between all 3, and can't do that with meeting-bot online
**\<meeting-bot> [fluffypony]** coz meeting bot is also relaying
**\<meeting-bot> [anonimal]** Ok, can we quickly review the remaining items?
**\<meeting-bot> [fluffypony]** sure
**\<meeting-bot> [anonimal]** 6. Closing #105
**\<meeting-bot> [anonimal]** Hmm, tricky.
**\<meeting-bot> [fluffypony]** sorry internet is slow
**\<meeting-bot> [fluffypony]** ok so
**\<meeting-bot> [fluffypony]** the moneroworld instance is up
**\<meeting-bot> [anonimal]** https://social.moneroworld.com went online but admin has not responded to anything in a month
**\<meeting-bot> [fluffypony]** hmmm
**\<meeting-bot> [anonimal]** There were multiple issues, probably still are, that would need to be resolved before we go officially public.
**\<meeting-bot> [fluffypony]** ok then I think leave it open
**\<meeting-bot> [anonimal]** But it's not kovri-related.
**\<meeting-bot> [anonimal]** That's what annoys me. We have a forum post open for it.
**\<meeting-bot> [anonimal]** And there's also that /bitmonero ticket open
**\<meeting-bot> * anonimal** fetches
**\<meeting-bot> [anonimal]** #903
**\<DaveyJones>** gingeropolous aint that your site?
**\<meeting-bot> [fluffypony]** anonimal: do we want a common gnu-social for the two?
**\<meeting-bot> [fluffypony]** or separate?
**\<gingeropolous>** wut?
**\<meeting-bot> [anonimal]** I thought it would be an umbrella instance, more of a 'pro-decentralization' initiative not specific to kovri or bitmonero.
**\<meeting-bot> [i2p-relay] {-moneromooo}** https://social.moneroworld.com <- your site ?
**\<gingeropolous>** oh, DaveyJones , no... i just pay for the domain name and put it on afraid.org so anyone can create subdomains for free
**\<meeting-bot> [anonimal]** I've already signed up for @kovri and @anonimal at quitter.se in case this issue was never resolved.
**\<meeting-bot> [i2p-relay] {-moneromooo}** Oh, that's nice idea.
**\<meeting-bot> [fluffypony]** ok
**\<meeting-bot> [fluffypony]** let's leave it open and prod the guy again
**\<meeting-bot> [fluffypony]** if we hear nothing by next dev meeting we re-host from scratch
**\<meeting-bot> [anonimal]** quitter.se is nice aside from the psychopath/bot with the sickle and hammer avatar that spams the feed like there is no tomorrow.
**\<meeting-bot> [anonimal]** Ok, I'll make a note.
**\<meeting-bot> [anonimal]** 7. Closing #46
**\<meeting-bot> [fluffypony]** I'm moving registrars for all critical domains, including getkovri.org
**\<meeting-bot> [fluffypony]** which is affecting that and the other one
**\<meeting-bot> [fluffypony]** (the increased attention means an increase of people poking at our infrastructure, hence the move)
**\<meeting-bot> [anonimal]** Ah, ok. How is content coming along? Did you get that rough draft finished?
**\<meeting-bot> [fluffypony]** should be done by next meeting, and I'll push the Kovri page to the Monero website in the next week so that we can open it up to the community to work on it
**\<meeting-bot> [fluffypony]** it's in a sub-section of its own
**\<meeting-bot> [fluffypony]** so it can have as much content as required
**\<meeting-bot> [EinMByte]** nice, didn't know we were getting a website
**\<meeting-bot> [anonimal]** Alright, I'll make a note.
**\<meeting-bot> [fluffypony]** EinMByte: I was going to do it in Geocities, but anonimal convinced me not to
**\<meeting-bot> [EinMByte]** (then again, I probably missed a lot)
**\<meeting-bot> [fluffypony]** snow flake mouse cursors are the bomb
**\<meeting-bot> [anonimal]** Yeah, fluffypony has yet to learn the finer points of 90's webdev.
**\<meeting-bot> [fluffypony]** fo sho
**\<meeting-bot> [anonimal]** We're working on that.
**\<meeting-bot> [fluffypony]** Backstreet Boys backgrounds everywhere
**\<meeting-bot> [anonimal]** Once we get a logo, the site should look snazzy.
**\<meeting-bot> [anonimal]** 'Kovri's back, alright!'
**\<meeting-bot> [fluffypony]** hah hah
**\<meeting-bot> [anonimal]** Ok, 8. Closing #27
**\<meeting-bot> [anonimal]** Ah, looks like we've had some activity there lately.
**\<meeting-bot> [anonimal]** Looks like two issues now. So, 1) updates on zoho? 2) should we ever have a mailing list?
**\<meeting-bot> [fluffypony]** can't proceed with Zoho till the domain move is done, but that's basically setup
**\<meeting-bot> [fluffypony]** I don't think mailing lists are necessary
**\<meeting-bot> [fluffypony]** we already have stuff scattered everywhere, another avenue will just make dissipate it more
**\<meeting-bot> [anonimal]** Agreed.
**\<meeting-bot> [EinMByte]** ever ? maybe, now ? no
**\<meeting-bot> [anonimal]** fluffypony: ETA on domain move completion (or did you already say?... /me reads)?
**\<meeting-bot> [fluffypony]** anonimal: by next meeting
**\<meeting-bot> [fluffypony]** if it's done sooner then great
**\<meeting-bot> [anonimal]** Ok, great. Once that's resolved we can resolve the HackerOne issue.
**\<meeting-bot> [anonimal]** Which will be another avenue for more attention.
**\<meeting-bot> [anonimal]** I'll make a note in #27.
**\<meeting-bot> [anonimal]** Anything else on #27?
**\<meeting-bot> [fluffypony]** nope that's it for now
**\<meeting-bot> [anonimal]** 9. Any additional meeting items
**\<meeting-bot> [anonimal]** EinMByte, how goes it?
**\<guzzi>** present fgi
**\<meeting-bot> [anonimal]** Hi guzzi.
**\<meeting-bot> [anonimal]** guzzi: anything you wanted to add to the meeting?
**\<guzzi>** glad to be a back. learning a lot.
**\<meeting-bot> [EinMByte]** anonimal: Hopefully some work on SSU soon
**\<meeting-bot> [anonimal]** EinMByte: I had thoughts and questions on library design if you're around after the meeting
**\<meeting-bot> [EinMByte]** Sure
**\<guzzi>** looking to focus more on kovri since it has the least devs and is more easy to peneatrate into development.
**\<guzzi>** still getting up to speed.
**\<meeting-bot> [anonimal]** EinMByte: nice, I look forward to the day we merge that branch.
**\<meeting-bot> [EinMByte]** guzzi: If you're looking for easy stuff to get used to the code, tests and documentation are very much needed so that might be a good idea
**\<meeting-bot> [anonimal]** guzzi: ok, if you have any questions, feel free to shout out.
**\<meeting-bot> [anonimal]** solmar: ^ what EinMByte said too if interested.
**\<guzzi>** EinMByte, thanks on it.
**\<guzzi>** i will look for todos.
**\<guzzi>** an prs on that
**\<meeting-bot> [anonimal]** fluffypony: you wanted to talk about #325?
**\<meeting-bot> [fluffypony]** oh - not necessarily, it was more to find out if it needed discussion
**\<meeting-bot> [solmar]** i'll check it out thanks ;)
**\<meeting-bot> [anonimal]** fluffypony: I think #325 is more of a 'po-tey-to' 'po-tah-to' kind of issue
**\<meeting-bot> [anonimal]** and a possible solution is 'let's call the whole thing off'.
**\<meeting-bot> [anonimal]** I'll figure itself out.
**\<meeting-bot> [anonimal]** Anything else on 9.? Any more meeting items?
**\<meeting-bot> [anonimal]** With organizational things out of the way, the next meeting can be far more codebase-orieted.
**\<meeting-bot> [anonimal]** *oriented
**\<meeting-bot> [fluffypony]** kk
**\<meeting-bot> [anonimal]** 10. Confirm next meeting date/time
**\<meeting-bot> [fluffypony]** https://99designs.com/logo-design/contests/create-beautiful-logo-kovri-privacy-enhancing-open-source-652257/entries
**\<meeting-bot> [fluffypony]** https://99designs.com/logo-design/contests/create-beautiful-logo-kovri-privacy-enhancing-open-source-652257/brief that thing
**\<meeting-bot> [anonimal]** fluffypony: nice
**\<meeting-bot> [fluffypony]** k next meeting, same time, same place, 2 weeks
**\<meeting-bot> [anonimal]** Where's the 'optional dog' button?
**\<meeting-bot> [fluffypony]** Two Weeks (tm)
**\<meeting-bot> [anonimal]** Do we have to do 2 weeks?
**\<meeting-bot> [fluffypony]** you want to do longer?
**\<meeting-bot> [fluffypony]** or shorter?
**\<meeting-bot> [anonimal]** I mean, I guess it depends on who is involved. If it's the usual, then I'd say 1 month.
**\<meeting-bot> [fluffypony]** guzzi / solmar / EinMByte - thoughts ?
**\<meeting-bot> [EinMByte]** We can discuss some of the more technical things separately
**\<guzzi>** 1 mo fine. i will be on irc for technical things. still playing catch up.
**\<meeting-bot> [fluffypony]** ok
**\<meeting-bot> [fluffypony]** then we do it in 4 weeks, same time as the meeting after next Monero dev meeting?
**\<meeting-bot> [solmar]** 1 month is fine
**\<meeting-bot> [solmar]** i'll be around as often as i can
**\<meeting-bot> [anonimal]** Same time is fine with me.
**\<meeting-bot> [fluffypony]** thankyouverymuch!
**\<meeting-bot> [anonimal]** Ok, thanks everyone.
**\<meeting-bot> [fluffypony]** can I kill meeting-bot?
**\<meeting-bot> [anonimal]** fluffypony: swift and painless if possible.
**\<meeting-bot> [anonimal]** She need not suffer.
**\<fluffypony>** anonimal: all yours
**\<tewinget>** in the meantime, for those not interested (or relevant to) the kovri meeting, anyone wanna help me test the zmq wallet<->daemon interactions?
**\<meeting-bot> [anonimal]** Proposed meeting items:
**\<tewinget>** oh
**\<tewinget>** shit
**\<meeting-bot> [anonimal]** 1. Greetings
**\<meeting-bot> [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<meeting-bot> [anonimal]** 3. Code + ticket discussion / Q & A
**\<meeting-bot> [anonimal]** 4. Discuss #282
**\<meeting-bot> [anonimal]** 5. Closing #226
**\<meeting-bot> [anonimal]** 6. Closing #105
**\<meeting-bot> [anonimal]** 7. Closing #46
**\<meeting-bot> [anonimal]** 8. Closing #27
**\<meeting-bot> [anonimal]** 9. Any additional meeting items
**\<meeting-bot> [anonimal]** 10. Confirm next meeting date/time
**\<meeting-bot> [anonimal]** btw, twinget, you are \*all\* relevant to the meeting and you \*ALL\* should be interested.
**\<meeting-bot> [anonimal]** Its that kind of attitude that is preventable advancing kovri development within monero.
**\<fluffypony>>** +100
**\<meeting-bot> [anonimal]** 1. Greetings
**\<meeting-bot> [anonimal]** Hi, I'm here.
**\<meeting-bot> [fluffypony]** me three
**\<tewinget>>** anonimal (I'm not relevant in the sense that I have no context, need to learn more about it :))
**\<i2p-relay> {-solmar}>** we need all the help we can get
**\<meeting-bot> [fluffypony]** EinMByte ?
**\<ArticMine>>** I will stay for another 20 min then I have to leave.
**\<meeting-bot> [fluffypony]** tks ArticMine
**\<meeting-bot> [anonimal]** Hi ArticMine.
**\<ArticMine>>** Hi
**\<meeting-bot> [anonimal]** Hi solmar, EinMByte, fluffypony.
**\<meeting-bot> [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<meeting-bot> [anonimal]** $ git checkout master && git log --pretty=oneline --no-merges --since=2016-07-31 | wc -l
**\<meeting-bot> [anonimal]** 55
**\<meeting-bot> [anonimal]** - Lots of build work
**\<meeting-bot> [anonimal]** - Reinstate FreeBSD build
**\<meeting-bot> [anonimal]** - Reinstate Clang support
**\<meeting-bot> [anonimal]** - New config features
**\<meeting-bot> [anonimal]** - New logging features
**\<meeting-bot> [anonimal]** - Implemented SNI (part of cpp-netlib)
**\<meeting-bot> [anonimal]** I'm doing work in branch fix-305, not detailed here.
**\<meeting-bot> [anonimal]** We have a new member onbard, 'solmar'. guzzi is back with us too.
**\<meeting-bot> [anonimal]** rakhimov is becoming more active, all great.
**\<meeting-bot> [anonimal]** I hope EinMByte's travels have been well and has returned.
**\<meeting-bot> [solmar]** hey all ;)
**\<meeting-bot> [anonimal]** Did I miss anything for point 2.?
**\<fluffypony>** well
**\<fluffypony>** is it worth discussing #325 now?
**\<meeting-bot> [solmar]** the quality assurance document is note worthy but i think you got everything
**\<meeting-bot> [anonimal]** fluffypony: no not yet.
**\<fluffypony>** ok
**\<meeting-bot> [anonimal]** solmar: thanks, good point. Yes solmar and I reworked #58 and introduced it into a tangible guide.
**\<meeting-bot> [anonimal]** Anything on 2. before moving onto 3.?
**\<fluffypony>** nothing more on 2
**\<meeting-bot> [anonimal]** Before 3., did solmar want to formally introduce themself?
**\<meeting-bot> [solmar]** sure i can quickly introduce
**\<meeting-bot> [solmar]** you guys may have seen me kicking around the various monero-related channels in the past few weeks. monero has peaked great interest in me and moving forward will be quite powerful
**\<meeting-bot> [i2p-relay] {-moneromooo}** Welcome :)
**\<meeting-bot> [solmar]** i am switching focus to kovri because of how unmanned the team is but in the next week i would gladly help test ringct code on the testnet
**\<meeting-bot> [fluffypony]** +1
**\<tewinget>** s/peaked/piqued/ <-- fuck English sometimes
**\<meeting-bot> [solmar]** in the meantime i will continue to learn the kovri code to hopefully in the near future begin to make tangible contributions to the code
**\<meeting-bot> [fluffypony]** awesome, everyone should dabble in both
**\<meeting-bot> [solmar]** any interest and help with kovri is greatly appreciated
**\<meeting-bot> [solmar]** i think we can move along to 3. now thanks anominal ;)
**\<meeting-bot> [anonimal]** Alright, thanks solmar.
**\<meeting-bot> [anonimal]** 3. Code + ticket discussion / Q & A
**\<meeting-bot> [anonimal]** I'll open
**\<meeting-bot> [fluffypony]** some of the design decisions in Kovri were influenced by Monero, so no getting away from it, Monero devs ;)
**\<meeting-bot> [anonimal]** Question: WHEN WILL MONERO DEVS START TAKING KOVRI SERIOUSLY?
**\<meeting-bot> [anonimal]** 10 months in now since our november 1st meeting,
**\<meeting-bot> [i2p-relay] {-moneromooo}** Define "taking seriously" ? Send patches ?
**\<tewinget>** anonimal: I take it just as seriously as, say, RingCT, I just haven't had/taken the time to dig into either yet :)
**\<meeting-bot> [anonimal]** As a whole, if I could quantify contributions, I'd say kovri is getting ~5% attention to what bitmonero and ecosystem is getting.
**\<meeting-bot> [anonimal]** moneromooo: anything.
**\<meeting-bot> [i2p-relay] {-moneromooo}** OK, fair enough. A new codebase appearing like that is going to be not so easy to jump back and forth for coders. But I hear your point.
**\<meeting-bot> [i2p-relay] {-moneromooo}** I will try to get into kovri a bit once rct is all done.
**\<meeting-bot> [anonimal]** I understand all the arguments, and I know what sacrifices would need to be made, so I question when and if they will be made.
**\<meeting-bot> [anonimal]** Thanks moneromooo.
**\<meeting-bot> [fluffypony]** the easiest way to get hyc involved it for us to use LMDB for storage of something :-P
**\<meeting-bot> [i2p-relay] {-moneromooo}** (and feel free to remind me of it if I don't :P)
**\<meeting-bot> [i2p-relay] {-moneromooo}** Nah, use liblber for network.
**\<meeting-bot> [anonimal]** fluffypony: this goes for you too, as we'll see with the remaining agenda items.
**\<meeting-bot> [i2p-relay] {-moneromooo}** Make us fast and secure comms!
**\<tewinget>** fluffypony: in the same way as with hyc, the easiest way to get me involved is something needing refactored >\_>
**\<meeting-bot> [anonimal]** Anyone else over there have a response beside moneromooo and tewinget?
**\<meeting-bot> [anonimal]** If not, we should move onto other Q & A.
**\<meeting-bot> [fluffypony]** is this still the ticket discussion part?
**\<meeting-bot> [anonimal]** Point 3.
**\<meeting-bot> [fluffypony]** yes - but I mean ticket discussion is part of Q&A or can I bring up a ticket now?
**\<meeting-bot> [anonimal]** I have library questions I would want to debate with EinMByte but I don't think he's around.
**\<meeting-bot> [anonimal]** Sure but that's least priority at the moment.
**\<meeting-bot> [anonimal]** And should be 9.
**\<meeting-bot> [anonimal]** I'd rather move onto 4. if no one has any questions.
**\<meeting-bot> [fluffypony]** kk
**\<meeting-bot> [anonimal]** 4. Discuss #282
**\<meeting-bot> [fluffypony]** ok so
**\<meeting-bot> [i2p-relay] {-moneromooo}** There was a designer guy asking whether help was wanted. He seemed to be after paid work though.
**\<meeting-bot> [fluffypony]** with the Monero logo we used 99designs
**\<meeting-bot> [i2p-relay] {-moneromooo}** eherdesign in #monero
**\<meeting-bot> [fluffypony]** moneromooo: I looked at his stuff, it wasn't mind-blowing
**\<meeting-bot> [fluffypony]** I'd like to move to use 99designs again
**\<meeting-bot> [fluffypony]** ref: https://99designs.com/logo-design/contests/monero-mro-cryptocurrency-logo-design-contest-382486
**\<meeting-bot> [fluffypony]** I'm happy to put the $500 up for that, and then use the FFS to get it back
**\<meeting-bot> [fluffypony]** unless anyone feel we must go for a higher 99designs reward
**\<othe>** i would also sponsor that
**\<meeting-bot> [i2p-relay] {-moneromooo}** * hopes it won't be some shady looking concept
**\<meeting-bot> [i2p-relay] {-ArticMine}** It worked very well for Monero so I say yeas with the same package
**\<meeting-bot> [i2p-relay] {-ArticMine}** yes
**\<meeting-bot> [solmar]** maidsafe also appears to be having success with 99designs so i think it is a good idea
**\<meeting-bot> [fluffypony]** ok - I'll set that up now - do we have any ideas as to what we want to convey?
**\<meeting-bot> [i2p-relay] {-ArticMine}** Well I have to leave now
**\<meeting-bot> [fluffypony]** do we want it to be inspired by the Monero logo, like the MRL logo is?
**\<meeting-bot> [i2p-relay] {-moneromooo}** The essential qualities of garlic.
**\<meeting-bot> [fluffypony]** (ref: https://lab.getmonero.org/logo.png)
**\<meeting-bot> [i2p-relay] {-moneromooo}** ^ great logo
**\<groeg>** (noob here ...) A podcast I follow have a promo code för 99designs. Interesting?
**\<meeting-bot> [fluffypony]** groeg: yes plz, can you PM it to me?
**\<cjd>** you'll want to pm it to fluffypony, not to the bot
**\<cjd>** he's in this irc
**\<meeting-bot> [i2p-relay] {-moneromooo}** Actually... you could rotate the Monero logo 90% clockwise and arrange colors a bit so it looks like a K. With kind of a hidden M.
**\<groeg>** newbie using IRC, looking up how to pm ...
**\<meeting-bot> [i2p-relay] {-moneromooo}** groeg: /query NICKHERE
**\<meeting-bot> [fluffypony]** thanks groeg, got it
**\<meeting-bot> [solmar]** conveying a "veil"-ish esque style to it could be interesting, since kovri means veil in esperanto afaik
**\<meeting-bot> [i2p-relay] {-moneromooo}** 90 degrees, not %, of course -\_-
**\<meeting-bot> [fluffypony]** solmar that's pretty much what I was thinking, something along the lines of a network, but it's private
**\<meeting-bot> [fluffypony]** or something
**\<meeting-bot> [fluffypony]** doesn't have to be a "veil" in the literal sense
**\<meeting-bot> [solmar]** ya
**\<meeting-bot> [solmar]** i agree
**\<meeting-bot> [solmar]** ya exactly
**\<meeting-bot> [anonimal]** Sorry, unexpected AFK emergency, unavoidable.
**\<meeting-bot> * anonimal** reading
**\<meeting-bot> [anonimal]** moneromooo: cool idea, maybe someone can run with that.
**\<meeting-bot> [fluffypony]** anonimal: the rotated K thing?
**\<meeting-bot> [fluffypony]** I can suggest that in the 99designs description
**\<meeting-bot> [anonimal]** Yeah, but maybe not literally, just an artistic motive I guess.
**\<meeting-bot> [fluffypony]** yeah
**\<meeting-bot> [anonimal]** But also garlic is a good point as solmar pointed out.
**\<meeting-bot> [fluffypony]** isn't garlic very Tor?
**\<meeting-bot> [anonimal]** So a rotated K inside a garlic clove
**\<meeting-bot> [anonimal]** No, they're onion.
**\<meeting-bot> [fluffypony]** oh yes
**\<meeting-bot> [fluffypony]** my bad
**\<meeting-bot> [anonimal]** onion router similar to garlic routing.
**\<meeting-bot> [anonimal]** Meh, its practically the same vegetable.
**\<meeting-bot> [fluffypony]** lo
**\<meeting-bot> [fluffypony]** lol
**\<meeting-bot> [fluffypony]** we should go wild and create spinach routing
**\<meeting-bot> [anonimal]** lol
**\<meeting-bot> [anonimal]** "Kovri provides essential iron and vitamins"
**\<meeting-bot> [fluffypony]** http://paulkieschedesign.com/blog/wp-content/uploads/2011/12/shandong-logo.jpg <- perfect
**\<meeting-bot> [anonimal]** "Eat kovri today"
**\<meeting-bot> [fluffypony]** the name, not the logo
**\<meeting-bot> [fluffypony]** so for a previous April 1 we renamed Monero to DarkFlarb, so I move that for next year April 1 we rename Kovri to Shandong
**\<meeting-bot> [fluffypony]** ShanDong
**\<meeting-bot> [anonimal]** The ShanDong I2P Router project... hmm...
**\<meeting-bot> [anonimal]** fluffypony: how do we keep track of #282?
**\<meeting-bot> [fluffypony]** lol
**\<meeting-bot> [fluffypony]** anonimal: othe and I will set it up and update in-ticket
**\<meeting-bot> [anonimal]** fluffypony: thanks.
**\<meeting-bot> [anonimal]** Anything else on #282?
**\<meeting-bot> [fluffypony]** nada
**\<meeting-bot> [anonimal]** If we use a dog somewhere in there, and Shandong, we should go with a pug.
**\<groeg>** shandong = 山东 = mountain east
**\<meeting-bot> [fluffypony]** TIL
**\<meeting-bot> [anonimal]** The eastside rugged pug.
**\<groeg>** (literal meaning of the characters)
**\<meeting-bot> [fluffypony]** east mountain pugs unite
**\<meeting-bot> * anonimal** see dog flip gang symbol with fingers
**\<meeting-bot> [fluffypony]** DogeI2P
**\<meeting-bot> [anonimal]** Here we go, lol
**\<meeting-bot> [anonimal]** Ok, 5. Closing #226
**\<meeting-bot> [anonimal]** This is useful when: 1) i2p-relay is down 2) slack is not available or people aren't signed up nor want to sign up
**\<meeting-bot> [anonimal]** I've registered the channels and am idling.
**\<meeting-bot> [fluffypony]** ok so
**\<meeting-bot> [fluffypony]** are we happy running this under the core relay and not the community relay?
**\<meeting-bot> [anonimal]** By community you mean the one in #monero/#monero-dev?
**\<meeting-bot> [fluffypony]** the community one is the one that needmoney90 runs, to Slack / Telegram etc.
**\<meeting-bot> [fluffypony]** the core one is i2p-relay
**\<meeting-bot> [fluffypony]** anonimal: is there a #tahoe-lafs on OFTC?
**\<meeting-bot> [fluffypony]** because I don't want to take tahoe-lafs out the relay list, necessarily
**\<meeting-bot> [anonimal]** fluffypony: yes, with 4 people, no channel topic. Doesn't look official.
**\<meeting-bot> [fluffypony]** ok then I'll just relay it, tough for them
**\<meeting-bot> [anonimal]** They will probably enjoy it.
**\<meeting-bot> [fluffypony]** indeed
**\<meeting-bot> [fluffypony]** ok I'll do that right now
**\<meeting-bot> [anonimal]** So this would be for i2p-relay?
**\<meeting-bot> * anonimal** so many relays, so confused
**\<meeting-bot> [fluffypony]** lol
**\<meeting-bot> [i2p-relay] {-moneromooo}** What's #tahoe-lafs relation with kovri btw ?
**\<meeting-bot> [anonimal]** moneromooo: Nothing really aside from an i2p plugin available to use with tahoe-lafs, AFAIK
**\<meeting-bot> [anonimal]** fluffypony: if you're doing it right now, I'll wait.
**\<meeting-bot> [fluffypony]** moneromooo: they asked me to run a relay, as their relay has disappeared
**\<meeting-bot> [anonimal]** Damn, it's been an hour. Do we continue?
**\<meeting-bot> [fluffypony]** yes - we started late
**\<meeting-bot> [i2p-relay] {-moneromooo}** I think it's mostly up to you, the main kovri person.
**\<meeting-bot> * anonimal** didn't want to stop on necessary bitmonero business
**\<meeting-bot> [anonimal]** fluffypony: do you have to restart the relay? Is #226 resolved?
**\<meeting-bot> [fluffypony]** the bouncer is connected
**\<meeting-bot> [fluffypony]** sec
**\<theRelay__> \<fluffypony@OFTC>** testing
**\<fluffypony>** testing back
**\<meeting-bot> [fluffypony]** and from here
**\<meeting-bot> [fluffypony]** meeting-bot might be interfering with it a little, so I'll fiddle with it after I've killed meeting-bot
**\<meeting-bot> [anonimal]** It's only me and the bot on OFTC
**\<meeting-bot> [anonimal]** Is fluffypony@OFTC actually fluffypony@Freenode ?
**\<meeting-bot> [fluffypony]** no I don't know - I need to check if it's relaying between all 3, and can't do that with meeting-bot online
**\<meeting-bot> [fluffypony]** coz meeting bot is also relaying
**\<meeting-bot> [anonimal]** Ok, can we quickly review the remaining items?
**\<meeting-bot> [fluffypony]** sure
**\<meeting-bot> [anonimal]** 6. Closing #105
**\<meeting-bot> [anonimal]** Hmm, tricky.
**\<meeting-bot> [fluffypony]** sorry internet is slow
**\<meeting-bot> [fluffypony]** ok so
**\<meeting-bot> [fluffypony]** the moneroworld instance is up
**\<meeting-bot> [anonimal]** https://social.moneroworld.com went online but admin has not responded to anything in a month
**\<meeting-bot> [fluffypony]** hmmm
**\<meeting-bot> [anonimal]** There were multiple issues, probably still are, that would need to be resolved before we go officially public.
**\<meeting-bot> [fluffypony]** ok then I think leave it open
**\<meeting-bot> [anonimal]** But it's not kovri-related.
**\<meeting-bot> [anonimal]** That's what annoys me. We have a forum post open for it.
**\<meeting-bot> [anonimal]** And there's also that /bitmonero ticket open
**\<meeting-bot> * anonimal** fetches
**\<meeting-bot> [anonimal]** #903
**\<DaveyJones>** gingeropolous aint that your site?
**\<meeting-bot> [fluffypony]** anonimal: do we want a common gnu-social for the two?
**\<meeting-bot> [fluffypony]** or separate?
**\<gingeropolous>** wut?
**\<meeting-bot> [anonimal]** I thought it would be an umbrella instance, more of a 'pro-decentralization' initiative not specific to kovri or bitmonero.
**\<meeting-bot> [i2p-relay] {-moneromooo}** https://social.moneroworld.com <- your site ?
**\<gingeropolous>** oh, DaveyJones , no... i just pay for the domain name and put it on afraid.org so anyone can create subdomains for free
**\<meeting-bot> [anonimal]** I've already signed up for @kovri and @anonimal at quitter.se in case this issue was never resolved.
**\<meeting-bot> [i2p-relay] {-moneromooo}** Oh, that's nice idea.
**\<meeting-bot> [fluffypony]** ok
**\<meeting-bot> [fluffypony]** let's leave it open and prod the guy again
**\<meeting-bot> [fluffypony]** if we hear nothing by next dev meeting we re-host from scratch
**\<meeting-bot> [anonimal]** quitter.se is nice aside from the psychopath/bot with the sickle and hammer avatar that spams the feed like there is no tomorrow.
**\<meeting-bot> [anonimal]** Ok, I'll make a note.
**\<meeting-bot> [anonimal]** 7. Closing #46
**\<meeting-bot> [fluffypony]** I'm moving registrars for all critical domains, including getkovri.org
**\<meeting-bot> [fluffypony]** which is affecting that and the other one
**\<meeting-bot> [fluffypony]** (the increased attention means an increase of people poking at our infrastructure, hence the move)
**\<meeting-bot> [anonimal]** Ah, ok. How is content coming along? Did you get that rough draft finished?
**\<meeting-bot> [fluffypony]** should be done by next meeting, and I'll push the Kovri page to the Monero website in the next week so that we can open it up to the community to work on it
**\<meeting-bot> [fluffypony]** it's in a sub-section of its own
**\<meeting-bot> [fluffypony]** so it can have as much content as required
**\<meeting-bot> [EinMByte]** nice, didn't know we were getting a website
**\<meeting-bot> [anonimal]** Alright, I'll make a note.
**\<meeting-bot> [fluffypony]** EinMByte: I was going to do it in Geocities, but anonimal convinced me not to
**\<meeting-bot> [EinMByte]** (then again, I probably missed a lot)
**\<meeting-bot> [fluffypony]** snow flake mouse cursors are the bomb
**\<meeting-bot> [anonimal]** Yeah, fluffypony has yet to learn the finer points of 90's webdev.
**\<meeting-bot> [fluffypony]** fo sho
**\<meeting-bot> [anonimal]** We're working on that.
**\<meeting-bot> [fluffypony]** Backstreet Boys backgrounds everywhere
**\<meeting-bot> [anonimal]** Once we get a logo, the site should look snazzy.
**\<meeting-bot> [anonimal]** 'Kovri's back, alright!'
**\<meeting-bot> [fluffypony]** hah hah
**\<meeting-bot> [anonimal]** Ok, 8. Closing #27
**\<meeting-bot> [anonimal]** Ah, looks like we've had some activity there lately.
**\<meeting-bot> [anonimal]** Looks like two issues now. So, 1) updates on zoho? 2) should we ever have a mailing list?
**\<meeting-bot> [fluffypony]** can't proceed with Zoho till the domain move is done, but that's basically setup
**\<meeting-bot> [fluffypony]** I don't think mailing lists are necessary
**\<meeting-bot> [fluffypony]** we already have stuff scattered everywhere, another avenue will just make dissipate it more
**\<meeting-bot> [anonimal]** Agreed.
**\<meeting-bot> [EinMByte]** ever ? maybe, now ? no
**\<meeting-bot> [anonimal]** fluffypony: ETA on domain move completion (or did you already say?... /me reads)?
**\<meeting-bot> [fluffypony]** anonimal: by next meeting
**\<meeting-bot> [fluffypony]** if it's done sooner then great
**\<meeting-bot> [anonimal]** Ok, great. Once that's resolved we can resolve the HackerOne issue.
**\<meeting-bot> [anonimal]** Which will be another avenue for more attention.
**\<meeting-bot> [anonimal]** I'll make a note in #27.
**\<meeting-bot> [anonimal]** Anything else on #27?
**\<meeting-bot> [fluffypony]** nope that's it for now
**\<meeting-bot> [anonimal]** 9. Any additional meeting items
**\<meeting-bot> [anonimal]** EinMByte, how goes it?
**\<guzzi>** present fgi
**\<meeting-bot> [anonimal]** Hi guzzi.
**\<meeting-bot> [anonimal]** guzzi: anything you wanted to add to the meeting?
**\<guzzi>** glad to be a back. learning a lot.
**\<meeting-bot> [EinMByte]** anonimal: Hopefully some work on SSU soon
**\<meeting-bot> [anonimal]** EinMByte: I had thoughts and questions on library design if you're around after the meeting
**\<meeting-bot> [EinMByte]** Sure
**\<guzzi>** looking to focus more on kovri since it has the least devs and is more easy to peneatrate into development.
**\<guzzi>** still getting up to speed.
**\<meeting-bot> [anonimal]** EinMByte: nice, I look forward to the day we merge that branch.
**\<meeting-bot> [EinMByte]** guzzi: If you're looking for easy stuff to get used to the code, tests and documentation are very much needed so that might be a good idea
**\<meeting-bot> [anonimal]** guzzi: ok, if you have any questions, feel free to shout out.
**\<meeting-bot> [anonimal]** solmar: ^ what EinMByte said too if interested.
**\<guzzi>** EinMByte, thanks on it.
**\<guzzi>** i will look for todos.
**\<guzzi>** an prs on that
**\<meeting-bot> [anonimal]** fluffypony: you wanted to talk about #325?
**\<meeting-bot> [fluffypony]** oh - not necessarily, it was more to find out if it needed discussion
**\<meeting-bot> [solmar]** i'll check it out thanks ;)
**\<meeting-bot> [anonimal]** fluffypony: I think #325 is more of a 'po-tey-to' 'po-tah-to' kind of issue
**\<meeting-bot> [anonimal]** and a possible solution is 'let's call the whole thing off'.
**\<meeting-bot> [anonimal]** I'll figure itself out.
**\<meeting-bot> [anonimal]** Anything else on 9.? Any more meeting items?
**\<meeting-bot> [anonimal]** With organizational things out of the way, the next meeting can be far more codebase-orieted.
**\<meeting-bot> [anonimal]** *oriented
**\<meeting-bot> [fluffypony]** kk
**\<meeting-bot> [anonimal]** 10. Confirm next meeting date/time
**\<meeting-bot> [fluffypony]** https://99designs.com/logo-design/contests/create-beautiful-logo-kovri-privacy-enhancing-open-source-652257/entries
**\<meeting-bot> [fluffypony]** https://99designs.com/logo-design/contests/create-beautiful-logo-kovri-privacy-enhancing-open-source-652257/brief that thing
**\<meeting-bot> [anonimal]** fluffypony: nice
**\<meeting-bot> [fluffypony]** k next meeting, same time, same place, 2 weeks
**\<meeting-bot> [anonimal]** Where's the 'optional dog' button?
**\<meeting-bot> [fluffypony]** Two Weeks (tm)
**\<meeting-bot> [anonimal]** Do we have to do 2 weeks?
**\<meeting-bot> [fluffypony]** you want to do longer?
**\<meeting-bot> [fluffypony]** or shorter?
**\<meeting-bot> [anonimal]** I mean, I guess it depends on who is involved. If it's the usual, then I'd say 1 month.
**\<meeting-bot> [fluffypony]** guzzi / solmar / EinMByte - thoughts ?
**\<meeting-bot> [EinMByte]** We can discuss some of the more technical things separately
**\<guzzi>** 1 mo fine. i will be on irc for technical things. still playing catch up.
**\<meeting-bot> [fluffypony]** ok
**\<meeting-bot> [fluffypony]** then we do it in 4 weeks, same time as the meeting after next Monero dev meeting?
**\<meeting-bot> [solmar]** 1 month is fine
**\<meeting-bot> [solmar]** i'll be around as often as i can
**\<meeting-bot> [anonimal]** Same time is fine with me.
**\<meeting-bot> [fluffypony]** thankyouverymuch!
**\<meeting-bot> [anonimal]** Ok, thanks everyone.
**\<meeting-bot> [fluffypony]** can I kill meeting-bot?
**\<meeting-bot> [anonimal]** fluffypony: swift and painless if possible.
**\<meeting-bot> [anonimal]** She need not suffer.

452
_posts/2016-08-28-overview-and-logs-for-the-dev-meeting-held-on-2016-08-28.md
View file

@ -14,230 +14,230 @@ An overview [can be found on Hello Monero](https://hellomonero.com/article/moner
# Logs
**\<hyc>** ding ding ding
**\<fluffypony>** hello meeting-bot!
**\<meeting-bot> [fluffypony]** hello from the other side!
**\<fluffypony>** ok we're on
**\<fluffypony>** ArticMine / luigi1111w / othe / smooth / hyc / moneromooo / tewinget / redfish / NoodleDoodle / anyoen I forgot
**\<moneromooo>** There's an article about fraud in crypto on the bytecoin blog. Chutzpah, got to admit.
**\<fluffypony>** welcome to the annual "Devs who Drink whilst Developing" meeting
**\<fluffypony>** moneromooo: brave of them
**\<hyc>** lol. I'm on cider today
**\<fluffypony>** ok so
**\<fluffypony>** in today's news
**\<fluffypony>** nothing happened with the Monero price
**\<fluffypony>** and so we focus on dev
**\<hyc>** lol
**\<fluffypony>** let's start with a quick check of open PRs
**\<fluffypony>** except for RingCT which we'll get to
**\<fluffypony>** redfish: how goes the CMake stuff?
**\<NoodleDoodle>** I alive today.
**\<moneromooo>** hey :)
**\<fluffypony>** and a warm welcome to our special guest, NoodleDoodle
**\<fluffypony>** :-P
**\<fluffypony>** whilst we wait for the redfishes
**\<fluffypony>** NoodleDoodle: do you want to talk about Trezor at all?
**\<fluffypony>** ok good chat
**\<hyc>** heh
**\<fluffypony>** :-P
**\<NoodleDoodle>** Sure :P
**\<fluffypony>** yay, take it away
**\<hyc>** redfish doesn't appear to be answering either
**\<NoodleDoodle>** I'm about 1296 behind in commits. Rebasing is pretty much out of the question. Have to manually merge then release.
**\<fluffypony>** NoodleDoodle: do you want any help with that?
**\<NoodleDoodle>** The trezor firmware itself should be easier, except it's split into 5 or 6 repos
**\<fluffypony>** ok cool
**\<NoodleDoodle>** I should be able to do it.
**\<fluffypony>** NoodleDoodle: do you want us to host it on the monero-project Github in its own repo, obvs giving you collab access, to make it more "formal" and part of the core project?
**\<tewinget>** late, but here
**\<NoodleDoodle>** Sure, anything. I actually started on keepkey awhile back as well, although it's not as complete as trezor.
**\<fluffypony>** ok cool
**\<fluffypony>** I've been fiddling with Ledger Blue, as I have the Blue and the Nano S
**\<fluffypony>** I have a feeling they'll be a cinch after Trezor / Keepkey
**\<fluffypony>** and, hopefully, we can PR it in to be part of the default firmware on these devices
**\<fluffypony>** if they'll have us
**\<fluffypony>** ok so next up
**\<fluffypony>** hyc has a small PR to ease up our LMDB speed after you're caught up with the network
**\<fluffypony>** which should lead to an even more robust blockchain DB, not that I've had anything resembling a corruption in ages
**\<fluffypony>** and I kill daemons like I'm playing Doom
**\<fluffypony>** tewinget, would you like to update us on 0MQ plx?
**\<tewinget>** sure
**\<tewinget>** so far, all of the daemon RPC calls pertaining to the wallet are good to go, as well as several others
**\<tewinget>** the wallet is good to go for using the new daemon rpc library
**\<tewinget>** oh, the new daemon rpc has a library, rather than just calling out to networking things directly. >**_>**
**\<tewinget>** (I only got ~1 hr sleep, minor rambling will happen)
**\<fluffypony>** tewinget: do you think it's PR-able now, and then subsequent updates to follow, or is it still too fast-and-loose to be used in "production"?
**\<tewinget>** let's see...next things I need to do are basically polish: make command line flags / parametrize port bind options, and so on. Documentation (both code and RPC spec)
**\<tewinget>** well, as of right now because of how cryptocurrencies work, if it cocks up it'll just...fail? As in, not in a destructive, send all coins to the void way, but in a boring "the tx failed to go to the daemon" or w/e way
**\<tewinget>** that said, I should probably put a bit more time into polish with command line flags and such first, as it currently has hard-coded binding and so on, and I need to doc the API
**\<fluffypony>** ok because that brings us on to the next topic
**\<hyc>** the PR I've submitted actually only changes the default db mode at startup. we didn't quite figure out how to adjust it after sync finished
**\<tewinget>** afaik (as in, if I've done it right) it's JSON-RPC compliant as well, apart from the http layer
**\<fluffypony>** and tewinget maybe you can think about it in this context
**\<fluffypony>** the RingCT PR is now post-review, at least by me, with multiple others having reviewed parts of it
**\<fluffypony>** so it's merge time
**\<fluffypony>** we haven't set fork heights yet
**\<moneromooo>** Wait till I signed commits first.
**\<fluffypony>** moneromooo: yes
**\<fluffypony>** but basically the idea is to run through the testnet forks next week
**\<fluffypony>** which means testnet will do the equivalent of September *and* March 2017 forks
**\<fluffypony>** in one week
**\<fluffypony>** testnet will then have RingCT live
**\<fluffypony>** and we'll be able to focus on efficiency improvements, further testing, and so on
**\<fluffypony>** in the meantime, it will let us code freeze sometime into September
**\<fluffypony>** a little later than we'd have liked, but a necessity to get RingCT in to this freeze instead of only in March
**\<fluffypony>** now here's the nice thing
**\<fluffypony>** old daemons only know about the fork in September, and will only start nagging about that one
**\<fluffypony>** so we can set the subsequent fork to something earlier than March
**\<fluffypony>** but we'd have to make that decision by the next dev meeting pretty much at the latest
**\<fluffypony>** which means
**\<fluffypony>** next week Tue / Wed or so we'll push out binaries for 0.10-beta
**\<fluffypony>** 0.10 will be called Wolfram Warptangent, in honour of the Monero contributor that passed away
**\<tewinget>** well the 6-month window is a "no earlier than", but at the same time since it's basically just miners doing the voting, idk how doing it earlier pans out.
**\* tewinget** approves the name.
**\<ArticMine>** Does that include the GUI?
**\<fluffypony>** ArticMine: no, this is core only
**\<tewinget>** ArticMine: We can tag a release with GUI at any time, no forking and such
**\<tewinget>** same with ZMQ
**\<fluffypony>** but it includes the GUI lib changes that are needed
**\<fluffypony>** so anyone compiling the GUI will have working beta bins to play with
**\<fluffypony>** so I'd please like commitments from as many people as possible to participate in testnet next week
**\* moneromooo** commits fluffypony
**\<fluffypony>** lol
**\* tewinget** rejects the unsigned commit
**\* iDunk** sees travis ci build fail
**\<fluffypony>** git commit -S -am "loony bin"
**\<moneromooo>** OK. I'll put in a Pedersen commitment to... something.
**\<moneromooo>** When do we set the forks then ?
**\<tewinget>** at dinner?
**\* fluffypony** giggles
**\<moneromooo>** For v3, ok. v4 (rct) on monday lunchtime.
**\<fluffypony>** moneromooo: for testnet?
**\<moneromooo>** Obviously :P
**\<moneromooo>** And v5 (rct only) on tuesday.
**\<fluffypony>** you mean Monday tomorrow, or Monday next week?
**\<moneromooo>** Fine ?
**\<moneromooo>** Tomorrow.
**\<fluffypony>** hmmm
**\<moneromooo>** Too fast ?
**\<fluffypony>** yes actually good idea - the actual fork process has been tested on private testnet, and in the previous fork
**\<fluffypony>** so we push bins out after the fork
**\<fluffypony>** then people can play without needing to fiddle
**\<gingeropolous>** and this is still a no-vote fork?
**\<moneromooo>** Yes. Screw votes, they were coded by an idiot.
**\<fluffypony>** LOL!
**\<fluffypony>** gingeropolous: yeah - we can re-address that in the next 6-12 months, but at the moment it's move-it-or-lose-it
**\<gingeropolous>** yeah absolutely
**\<fluffypony>** also the schedule is pretty widely known, except for ShapeShift who we'll email and then they'll claim they have no knowledge of the update
**\<tewinget>** gingeropolous: plus it's technically never a no-vote fork, as if the miners get pissed off and don't want it, well, they just won't. >**_>**
**\<gingeropolous>** lol fluffypony
**\<fluffypony>** ok so moneromooo, your fork points are fine
**\<moneromooo>** So will you merge the PR then build off that, or build off my branch ?
**\<moneromooo>** (for the test builds)
**\<fluffypony>** no, merge
**\<moneromooo>** OK
**\<fluffypony>** people must be able to build head on their boxes if they want
**\<moneromooo>** (oh, the supreme importance of punctuation)
**\* gingeropolous** hides
**\<fluffypony>** lol
**\<fluffypony>** ok
**\<fluffypony>** I think that's it from my side
**\<fluffypony>** does anyone have any questions or thoughts or anything?
**\<gingeropolous>** im still not super clear on the fork schedule.... but it could be sleep dep
**\<gingeropolous>** for mainnet
**\<fluffypony>** for mainnet it's still the September v3 fork, as expected
**\<fluffypony>** if we want we can have the v4 and v5 forks at any point after that, even though March would be the "expected" date
**\<hyc>** iDunk: build log shows no errors, just too slow to build
**\<tewinget>** I have a few questions, but I'll wait for others' for a few minutes first.
**\<hyc>** testnet sched sounds good
**\<hyc>** 0.10-beta sounds fine
**\<iDunk>** hyc: was a joke
**\<hyc>** iDunk: but it's unfortunately true :P
**\<fluffypony>** so even though we wouldn't normally push a fork forward, we have to consider the influx of new users, and maybe we feel that the added privacy is essential enough to do v4 end of Oct, v5 in Dec
**\<fluffypony>** something like that
**\<gingeropolous>** gotcha.
**\<fluffypony>** so we start 2017 with RingCT as the only way to transact
**\<gingeropolous>** is there a place where the fork plan /etc is laid out?
**\<gingeropolous>** maybe the readme of the github is a good home
**\<fluffypony>** gingeropolous: this one, or generally?
**\<gingeropolous>** generally
**\<gingeropolous>** and this one
**\<fluffypony>** generally, the Monero Forum post + all other posts that talk about the mandatory hard forks
**\<tewinget>** gingeropolous: plans are probably in /usr/share/doc, not in /etc
**\<fluffypony>** I agree that the Readme shoudl include it
**\<hyc>** seems to me like we have a lot of profiling and tuning to do before ringCT will play for real
**\<hyc>** october might be too soon
**\<gingeropolous>** its gonna be a helluva fall
**\<fluffypony>** this one is dev meeting specific, we'll have a summary post after that and solicit feedback from the non-dev community
**\<fluffypony>** hyc: we do have new contributors, so we might be able to get through the tuning stuff faster
**\<hyc>** cool
**\<fluffypony>** I'm no fan of pushing it too hard, because it means I have to get MyMonero working with RingCT, but it's doable
**\<gingeropolous>** yeah, I know there's the forum posts.. but considering fork early, fork often is kind of our thing, it should / could be ... more prominent
**\<gingeropolous>** ah screw it. time to by moneroforks.whatever
**\<fluffypony>** gingeropolous: do you want to PR a change to the readme?
**\<fluffypony>** it'll take you from troll-dev status to readme-dev
**\<fluffypony>** :-P
**\<gingeropolous>** :)
**\<fluffypony>** ok tewinget
**\<fluffypony>** before we run out of time
**\<fluffypony>** ask away
**\<tewinget>** ok
**\<tewinget>** so for one thing, I haven't seen a GUI progress update today, figured I'd ask if we have a tentative timeline?
**\<fluffypony>** othe: any thoughts?
**\<fluffypony>** ^^
**\<othe>** sorry was busy drinking
**\<othe>** yeah so ilya is traveling but back next week, we hope to fix all small reamaining issues till the week after
**\<fluffypony>** ok
**\<othe>** and then we can release a beta
**\<tewinget>** awesome
**\<othe>** together with a new tagged rls
**\<fluffypony>** othe is there any way he can stop submitting huge PRs
**\<othe>** and then whats following is mostly advanced settings and stuff like that
**\<fluffypony>** it's killing it for other potential contributors
**\<othe>** yeah i can tell him
**\<tewinget>** if there's desire for it and nobody else takes up the task, I may sign up to do a plugin system (unless that's already in place?)
**\<fluffypony>** he needs to PR on a feature / fix by feature basis
**\<othe>** oh thats not in the place but something that would be cool to have tewinget
**\<hyc>** yeah, narrow scope PRs
**\<fluffypony>** yeah definitely, hyc
**\<moneromooo>** And move the twitter stuff in there, just to be sure.
**\<fluffypony>** OH!
**\<fluffypony>** before I forget
**\<fluffypony>** the big thing I wanted to discuss
**\<fluffypony>** https://github.com/monero-project/bitmonero/issues/80
**\<fluffypony>** that's going to happen before the bins are pushed
**\<fluffypony>** so if anyone has any final thoughts on that, you'd best comment on the issue, else suck it up later :-P
**\<fluffypony>** I'd also like us to start refactoring the parts that have CryptoNote in the name to be Monero instead
**\<tewinget>** something something `sed`
**\<fluffypony>** as RingCT + several thousand commits puts us quite far beyond the reference protocol
**\<moneromooo>** Renaming things for the fun of it ? I'd rather not.
**\<moneromooo>** (in the code, I mean. I'm ok with the binaries thing)
**\<tewinget>** btw fluffypony, I *think* that the zmq-dev branch is PR-ready, but I'm not comfortable making that call without some testing, so if anyone would like to give it a go (testnet and mainnet are affected identically, so testnet is 100% fine for, well, testing)
**\<ArticMine>** It simple reflects the reality of how much the code has changed from the original Cryptonote implementation
**\<tewinget>** as I said before, I'd like to polish it up a bit first, but that's not a blocking issue for PR-ing
**\<fluffypony>** tewinget: if you're of the opinion it can go into a mid-Sept code freeze / release then sure, else leave it till after the release because it's not HF worthy
**\<fluffypony>** your call
**\<tewinget>** I'm reluctantly okay with doing merges on my end before a PR, so it can wait, just figured I'd give the option. Testing would still be great though...I need to sync the testnet chain on my VPS but then I'll badger you for some testnet moneyz
**\<tewinget>** I'll need to discuss with someone(s) how "blocknotify" should work, and perhaps about doing something similar for miners (call it templatenotify if you like)
**\<fluffypony>** oh that could be interesting
**\<fluffypony>** the templatenotify I mean
**\<hyc>** yeah templatenotify would make an immediate difference for miners
**\<tewinget>** yea, I'm thinking a configurable parameter that is like "if there is 20% more value to be had via tx fees by changing the block template, notify the miner to update its block template with the new transactions included"
**\<tewinget>** plus the obvious implications of changing when a new block is learned about
**\<hyc>** right
**\<tewinget>** but that can be done with the blocknotify that the wallet wants anyway
**\<gingeropolous>** ooh we talkin dynamic fees?
**\<tewinget>** at any rate, that's a design discussion for another time.
**\<fluffypony>** tewinget: I'd prefer earlier PRs
**\<fluffypony>** I mean
**\<tewinget>** fluffypony: yes, yes, I meant for after that PR
**\<fluffypony>** if it's properly borked by mid-September we can revert 0MQ for release
**\<meeting-bot> [anonimal]** 17:06
**\<fluffypony>** tewinget: so what I'm saying is PR soon, plx
**\<fluffypony>** anonimal apologies
**\<fluffypony>** is there anything else or can we call it?
**\<hyc>** think that's good for today
**\<tewinget>** I'd say go nuts for your kovri meeting, we're not going anywhere
**\<fluffypony>** yay, nuts
**\<tewinget>** so if something else comes up, address it after that meeting
**\<hyc>** ding ding ding
**\<fluffypony>** hello meeting-bot!
**\<meeting-bot> [fluffypony]** hello from the other side!
**\<fluffypony>** ok we're on
**\<fluffypony>** ArticMine / luigi1111w / othe / smooth / hyc / moneromooo / tewinget / redfish / NoodleDoodle / anyoen I forgot
**\<moneromooo>** There's an article about fraud in crypto on the bytecoin blog. Chutzpah, got to admit.
**\<fluffypony>** welcome to the annual "Devs who Drink whilst Developing" meeting
**\<fluffypony>** moneromooo: brave of them
**\<hyc>** lol. I'm on cider today
**\<fluffypony>** ok so
**\<fluffypony>** in today's news
**\<fluffypony>** nothing happened with the Monero price
**\<fluffypony>** and so we focus on dev
**\<hyc>** lol
**\<fluffypony>** let's start with a quick check of open PRs
**\<fluffypony>** except for RingCT which we'll get to
**\<fluffypony>** redfish: how goes the CMake stuff?
**\<NoodleDoodle>** I alive today.
**\<moneromooo>** hey :)
**\<fluffypony>** and a warm welcome to our special guest, NoodleDoodle
**\<fluffypony>** :-P
**\<fluffypony>** whilst we wait for the redfishes
**\<fluffypony>** NoodleDoodle: do you want to talk about Trezor at all?
**\<fluffypony>** ok good chat
**\<hyc>** heh
**\<fluffypony>** :-P
**\<NoodleDoodle>** Sure :P
**\<fluffypony>** yay, take it away
**\<hyc>** redfish doesn't appear to be answering either
**\<NoodleDoodle>** I'm about 1296 behind in commits. Rebasing is pretty much out of the question. Have to manually merge then release.
**\<fluffypony>** NoodleDoodle: do you want any help with that?
**\<NoodleDoodle>** The trezor firmware itself should be easier, except it's split into 5 or 6 repos
**\<fluffypony>** ok cool
**\<NoodleDoodle>** I should be able to do it.
**\<fluffypony>** NoodleDoodle: do you want us to host it on the monero-project Github in its own repo, obvs giving you collab access, to make it more "formal" and part of the core project?
**\<tewinget>** late, but here
**\<NoodleDoodle>** Sure, anything. I actually started on keepkey awhile back as well, although it's not as complete as trezor.
**\<fluffypony>** ok cool
**\<fluffypony>** I've been fiddling with Ledger Blue, as I have the Blue and the Nano S
**\<fluffypony>** I have a feeling they'll be a cinch after Trezor / Keepkey
**\<fluffypony>** and, hopefully, we can PR it in to be part of the default firmware on these devices
**\<fluffypony>** if they'll have us
**\<fluffypony>** ok so next up
**\<fluffypony>** hyc has a small PR to ease up our LMDB speed after you're caught up with the network
**\<fluffypony>** which should lead to an even more robust blockchain DB, not that I've had anything resembling a corruption in ages
**\<fluffypony>** and I kill daemons like I'm playing Doom
**\<fluffypony>** tewinget, would you like to update us on 0MQ plx?
**\<tewinget>** sure
**\<tewinget>** so far, all of the daemon RPC calls pertaining to the wallet are good to go, as well as several others
**\<tewinget>** the wallet is good to go for using the new daemon rpc library
**\<tewinget>** oh, the new daemon rpc has a library, rather than just calling out to networking things directly. >\*\*\_>\*\*
**\<tewinget>** (I only got ~1 hr sleep, minor rambling will happen)
**\<fluffypony>** tewinget: do you think it's PR-able now, and then subsequent updates to follow, or is it still too fast-and-loose to be used in "production"?
**\<tewinget>** let's see...next things I need to do are basically polish: make command line flags / parametrize port bind options, and so on. Documentation (both code and RPC spec)
**\<tewinget>** well, as of right now because of how cryptocurrencies work, if it cocks up it'll just...fail? As in, not in a destructive, send all coins to the void way, but in a boring "the tx failed to go to the daemon" or w/e way
**\<tewinget>** that said, I should probably put a bit more time into polish with command line flags and such first, as it currently has hard-coded binding and so on, and I need to doc the API
**\<fluffypony>** ok because that brings us on to the next topic
**\<hyc>** the PR I've submitted actually only changes the default db mode at startup. we didn't quite figure out how to adjust it after sync finished
**\<tewinget>** afaik (as in, if I've done it right) it's JSON-RPC compliant as well, apart from the http layer
**\<fluffypony>** and tewinget maybe you can think about it in this context
**\<fluffypony>** the RingCT PR is now post-review, at least by me, with multiple others having reviewed parts of it
**\<fluffypony>** so it's merge time
**\<fluffypony>** we haven't set fork heights yet
**\<moneromooo>** Wait till I signed commits first.
**\<fluffypony>** moneromooo: yes
**\<fluffypony>** but basically the idea is to run through the testnet forks next week
**\<fluffypony>** which means testnet will do the equivalent of September *and* March 2017 forks
**\<fluffypony>** in one week
**\<fluffypony>** testnet will then have RingCT live
**\<fluffypony>** and we'll be able to focus on efficiency improvements, further testing, and so on
**\<fluffypony>** in the meantime, it will let us code freeze sometime into September
**\<fluffypony>** a little later than we'd have liked, but a necessity to get RingCT in to this freeze instead of only in March
**\<fluffypony>** now here's the nice thing
**\<fluffypony>** old daemons only know about the fork in September, and will only start nagging about that one
**\<fluffypony>** so we can set the subsequent fork to something earlier than March
**\<fluffypony>** but we'd have to make that decision by the next dev meeting pretty much at the latest
**\<fluffypony>** which means
**\<fluffypony>** next week Tue / Wed or so we'll push out binaries for 0.10-beta
**\<fluffypony>** 0.10 will be called Wolfram Warptangent, in honour of the Monero contributor that passed away
**\<tewinget>** well the 6-month window is a "no earlier than", but at the same time since it's basically just miners doing the voting, idk how doing it earlier pans out.
**\* tewinget** approves the name.
**\<ArticMine>** Does that include the GUI?
**\<fluffypony>** ArticMine: no, this is core only
**\<tewinget>** ArticMine: We can tag a release with GUI at any time, no forking and such
**\<tewinget>** same with ZMQ
**\<fluffypony>** but it includes the GUI lib changes that are needed
**\<fluffypony>** so anyone compiling the GUI will have working beta bins to play with
**\<fluffypony>** so I'd please like commitments from as many people as possible to participate in testnet next week
**\* moneromooo** commits fluffypony
**\<fluffypony>** lol
**\* tewinget** rejects the unsigned commit
**\* iDunk** sees travis ci build fail
**\<fluffypony>** git commit -S -am "loony bin"
**\<moneromooo>** OK. I'll put in a Pedersen commitment to... something.
**\<moneromooo>** When do we set the forks then ?
**\<tewinget>** at dinner?
**\* fluffypony** giggles
**\<moneromooo>** For v3, ok. v4 (rct) on monday lunchtime.
**\<fluffypony>** moneromooo: for testnet?
**\<moneromooo>** Obviously :P
**\<moneromooo>** And v5 (rct only) on tuesday.
**\<fluffypony>** you mean Monday tomorrow, or Monday next week?
**\<moneromooo>** Fine ?
**\<moneromooo>** Tomorrow.
**\<fluffypony>** hmmm
**\<moneromooo>** Too fast ?
**\<fluffypony>** yes actually good idea - the actual fork process has been tested on private testnet, and in the previous fork
**\<fluffypony>** so we push bins out after the fork
**\<fluffypony>** then people can play without needing to fiddle
**\<gingeropolous>** and this is still a no-vote fork?
**\<moneromooo>** Yes. Screw votes, they were coded by an idiot.
**\<fluffypony>** LOL!
**\<fluffypony>** gingeropolous: yeah - we can re-address that in the next 6-12 months, but at the moment it's move-it-or-lose-it
**\<gingeropolous>** yeah absolutely
**\<fluffypony>** also the schedule is pretty widely known, except for ShapeShift who we'll email and then they'll claim they have no knowledge of the update
**\<tewinget>** gingeropolous: plus it's technically never a no-vote fork, as if the miners get pissed off and don't want it, well, they just won't. >\*\*\_>\*\*
**\<gingeropolous>** lol fluffypony
**\<fluffypony>** ok so moneromooo, your fork points are fine
**\<moneromooo>** So will you merge the PR then build off that, or build off my branch ?
**\<moneromooo>** (for the test builds)
**\<fluffypony>** no, merge
**\<moneromooo>** OK
**\<fluffypony>** people must be able to build head on their boxes if they want
**\<moneromooo>** (oh, the supreme importance of punctuation)
**\* gingeropolous** hides
**\<fluffypony>** lol
**\<fluffypony>** ok
**\<fluffypony>** I think that's it from my side
**\<fluffypony>** does anyone have any questions or thoughts or anything?
**\<gingeropolous>** im still not super clear on the fork schedule.... but it could be sleep dep
**\<gingeropolous>** for mainnet
**\<fluffypony>** for mainnet it's still the September v3 fork, as expected
**\<fluffypony>** if we want we can have the v4 and v5 forks at any point after that, even though March would be the "expected" date
**\<hyc>** iDunk: build log shows no errors, just too slow to build
**\<tewinget>** I have a few questions, but I'll wait for others' for a few minutes first.
**\<hyc>** testnet sched sounds good
**\<hyc>** 0.10-beta sounds fine
**\<iDunk>** hyc: was a joke
**\<hyc>** iDunk: but it's unfortunately true :P
**\<fluffypony>** so even though we wouldn't normally push a fork forward, we have to consider the influx of new users, and maybe we feel that the added privacy is essential enough to do v4 end of Oct, v5 in Dec
**\<fluffypony>** something like that
**\<gingeropolous>** gotcha.
**\<fluffypony>** so we start 2017 with RingCT as the only way to transact
**\<gingeropolous>** is there a place where the fork plan /etc is laid out?
**\<gingeropolous>** maybe the readme of the github is a good home
**\<fluffypony>** gingeropolous: this one, or generally?
**\<gingeropolous>** generally
**\<gingeropolous>** and this one
**\<fluffypony>** generally, the Monero Forum post + all other posts that talk about the mandatory hard forks
**\<tewinget>** gingeropolous: plans are probably in /usr/share/doc, not in /etc
**\<fluffypony>** I agree that the Readme shoudl include it
**\<hyc>** seems to me like we have a lot of profiling and tuning to do before ringCT will play for real
**\<hyc>** october might be too soon
**\<gingeropolous>** its gonna be a helluva fall
**\<fluffypony>** this one is dev meeting specific, we'll have a summary post after that and solicit feedback from the non-dev community
**\<fluffypony>** hyc: we do have new contributors, so we might be able to get through the tuning stuff faster
**\<hyc>** cool
**\<fluffypony>** I'm no fan of pushing it too hard, because it means I have to get MyMonero working with RingCT, but it's doable
**\<gingeropolous>** yeah, I know there's the forum posts.. but considering fork early, fork often is kind of our thing, it should / could be ... more prominent
**\<gingeropolous>** ah screw it. time to by moneroforks.whatever
**\<fluffypony>** gingeropolous: do you want to PR a change to the readme?
**\<fluffypony>** it'll take you from troll-dev status to readme-dev
**\<fluffypony>** :-P
**\<gingeropolous>** :)
**\<fluffypony>** ok tewinget
**\<fluffypony>** before we run out of time
**\<fluffypony>** ask away
**\<tewinget>** ok
**\<tewinget>** so for one thing, I haven't seen a GUI progress update today, figured I'd ask if we have a tentative timeline?
**\<fluffypony>** othe: any thoughts?
**\<fluffypony>** ^^
**\<othe>** sorry was busy drinking
**\<othe>** yeah so ilya is traveling but back next week, we hope to fix all small reamaining issues till the week after
**\<fluffypony>** ok
**\<othe>** and then we can release a beta
**\<tewinget>** awesome
**\<othe>** together with a new tagged rls
**\<fluffypony>** othe is there any way he can stop submitting huge PRs
**\<othe>** and then whats following is mostly advanced settings and stuff like that
**\<fluffypony>** it's killing it for other potential contributors
**\<othe>** yeah i can tell him
**\<tewinget>** if there's desire for it and nobody else takes up the task, I may sign up to do a plugin system (unless that's already in place?)
**\<fluffypony>** he needs to PR on a feature / fix by feature basis
**\<othe>** oh thats not in the place but something that would be cool to have tewinget
**\<hyc>** yeah, narrow scope PRs
**\<fluffypony>** yeah definitely, hyc
**\<moneromooo>** And move the twitter stuff in there, just to be sure.
**\<fluffypony>** OH!
**\<fluffypony>** before I forget
**\<fluffypony>** the big thing I wanted to discuss
**\<fluffypony>** https://github.com/monero-project/bitmonero/issues/80
**\<fluffypony>** that's going to happen before the bins are pushed
**\<fluffypony>** so if anyone has any final thoughts on that, you'd best comment on the issue, else suck it up later :-P
**\<fluffypony>** I'd also like us to start refactoring the parts that have CryptoNote in the name to be Monero instead
**\<tewinget>** something something \`sed\`
**\<fluffypony>** as RingCT + several thousand commits puts us quite far beyond the reference protocol
**\<moneromooo>** Renaming things for the fun of it ? I'd rather not.
**\<moneromooo>** (in the code, I mean. I'm ok with the binaries thing)
**\<tewinget>** btw fluffypony, I \*think\* that the zmq-dev branch is PR-ready, but I'm not comfortable making that call without some testing, so if anyone would like to give it a go (testnet and mainnet are affected identically, so testnet is 100% fine for, well, testing)
**\<ArticMine>** It simple reflects the reality of how much the code has changed from the original Cryptonote implementation
**\<tewinget>** as I said before, I'd like to polish it up a bit first, but that's not a blocking issue for PR-ing
**\<fluffypony>** tewinget: if you're of the opinion it can go into a mid-Sept code freeze / release then sure, else leave it till after the release because it's not HF worthy
**\<fluffypony>** your call
**\<tewinget>** I'm reluctantly okay with doing merges on my end before a PR, so it can wait, just figured I'd give the option. Testing would still be great though...I need to sync the testnet chain on my VPS but then I'll badger you for some testnet moneyz
**\<tewinget>** I'll need to discuss with someone(s) how "blocknotify" should work, and perhaps about doing something similar for miners (call it templatenotify if you like)
**\<fluffypony>** oh that could be interesting
**\<fluffypony>** the templatenotify I mean
**\<hyc>** yeah templatenotify would make an immediate difference for miners
**\<tewinget>** yea, I'm thinking a configurable parameter that is like "if there is 20% more value to be had via tx fees by changing the block template, notify the miner to update its block template with the new transactions included"
**\<tewinget>** plus the obvious implications of changing when a new block is learned about
**\<hyc>** right
**\<tewinget>** but that can be done with the blocknotify that the wallet wants anyway
**\<gingeropolous>** ooh we talkin dynamic fees?
**\<tewinget>** at any rate, that's a design discussion for another time.
**\<fluffypony>** tewinget: I'd prefer earlier PRs
**\<fluffypony>** I mean
**\<tewinget>** fluffypony: yes, yes, I meant for after that PR
**\<fluffypony>** if it's properly borked by mid-September we can revert 0MQ for release
**\<meeting-bot> [anonimal]** 17:06
**\<fluffypony>** tewinget: so what I'm saying is PR soon, plx
**\<fluffypony>** anonimal apologies
**\<fluffypony>** is there anything else or can we call it?
**\<hyc>** think that's good for today
**\<tewinget>** I'd say go nuts for your kovri meeting, we're not going anywhere
**\<fluffypony>** yay, nuts
**\<tewinget>** so if something else comes up, address it after that meeting
**\<fluffypony>** kk