From 4c4942225b9dab75fb5e16b99274e8265bf24fe6 Mon Sep 17 00:00:00 2001 From: dEBRUYNE-1 Date: Mon, 20 Jun 2016 21:08:46 +0200 Subject: [PATCH] Add logs for Kovri and dev meeting --- ...he-Kovri-dev-meeting-held-on-2016-06-19.md | 294 ++++++++++++++++++ ...-for-the-dev-meeting-held-on-2016-06-19.md | 225 ++++++++++++++ 2 files changed, 519 insertions(+) create mode 100644 _posts/2016-06-19-logs-for-the-Kovri-dev-meeting-held-on-2016-06-19.md create mode 100644 _posts/2016-06-19-overview-and-logs-for-the-dev-meeting-held-on-2016-06-19.md diff --git a/_posts/2016-06-19-logs-for-the-Kovri-dev-meeting-held-on-2016-06-19.md b/_posts/2016-06-19-logs-for-the-Kovri-dev-meeting-held-on-2016-06-19.md new file mode 100644 index 00000000..203d15ed --- /dev/null +++ b/_posts/2016-06-19-logs-for-the-Kovri-dev-meeting-held-on-2016-06-19.md @@ -0,0 +1,294 @@ +--- +layout: post +title: Logs for the Kovri Dev Meeting Held on 2016-06-19 +summary: Brief review of what has been completed since last meeting, C++ specific discussion, closed and open issues +tags: [dev diaries, i2p, crypto] +author: dEBRUYNE / fluffypony +--- + +*June 19th, 2016* + +# Logs + +**\** ok I guess we move on to Kovri - anonimal, the floor is yours +**\ [anominal]** From agenda https://github.com/monero-project/kovri/issues/192 +**\ [anominal]** 17:00 (UTC) +**\ [anominal]** 1. Greetings +**\ [anominal]** 2. Brief review of what's been completed since the previous meeting +**\ [anominal]** 3. C++ specific discussion (carried over from June 5th meeting) +**\ [anominal]** 4. Review open tickets (assigned and/or unassigned): status, code ideas (if applicable), etc. +**\ [anominal]** 5. Discuss any pertinent TODO's +**\ [anominal]** 6. Any additional meeting items +**\ [anominal]** 7. Confirm next meeting date/time +**\ [anominal]** 1. Greetings +**\ [anominal]** Hi +**\ [anominal]** EinMByte: present? +**\** there's 2x greetings? +**\** best meeting ever +**\ [anominal]** lol +**\ [anominal]** Well, EinMByte is here but not present. +**\** k +**\ [anominal]** Moving on, +**\ [anominal]** 2. Brief review of what's been completed since the previous meeting +**\ [anominal]** A somewhat productive two weeks in contrasting areas. Highlights include: +**\ [anominal]** - New --log-levels runtime feature +**\ [anominal]** - Security fix in Garlic/ElGamal +**\ [anominal]** - New user-agent scrubber +**\ [anominal]** - Bump to 0.9.26 +**\ [anominal]** - Coverity coverage via travis-ci (though problematic, see #209) +**\ [anominal]** - Design refactoring, misc. refactoring, code documentation +**\ [anominal]** 6 closed issues +**\ [anominal]** 2 new standing issues +**\ [anominal]** fluffypony: have you had a chance to complete anything since previous meeting? +**\** anonimal: like 80%-ish done with the Kovri page on the site, per the info you gave me + the docs +**\** s/page/section +**\ [anominal]** Great, I'm looking forward to it. +**\ [anominal]** Do you think it will be finished before next meeting? +**\** yes definitely +**\ [anominal]** Yay, sounds exciting. +**\ [anominal]** Anything else on 2.? +**\ [anominal]** Going once... going twice... +**\ [anominal]** 3. C++ specific discussion (carried over from June 5th meeting) +**\ [anominal]** Well, I was hoping to merge this in with 4. and chat with EinMByte since he said he'd be here. +**\** is this wrt the C++ standard ? +**\** or the style guide stuff? +**\ [anominal]** Anything C++, I imagined. +**\ [anominal]** I was hoping to focus on C++ related to #187, but I haven't looked at #187 since it was opened. +**\ [anominal]** Have any bitmonero devs taken an interest in Kovri yet? +**\ [anominal]** Its quite the beast, and needs much taming. +**\** I don't think anyone has yet +**\** anonimal: passing interest at best for me +**\ [anominal]** Ok, good to know. +**\** I more or less know what it is, but I haven't looked into tinkering with it yet. +**\** I think the problem is that the time I'd spend hacking on anything, I wouldn't spend on monero anymore :) +**\** s'true +**\ [anominal]** I totally understand. +**\** there will be a bleed area between the two when integration happens +**\ [anominal]** That makes, so patience and persistence seems to be the key. +**\ [anominal]** *makes sense +**\ [anominal]** Well, anonymity has a certain taste too. Maybe I'm one of the few fanatics who enjoy working on it ;) +**\** I think most of us are here because we're pro-privacy +**\ [anominal]** Anyway, I look forward to the meeting of the minds, I like what I've seen in bitmonero dev. +**\ [anominal]** Yes, good point. +**\** which is awesome :) +**\ [anominal]** Anything else on 3.? Any questions? +**\ [anominal]** Alrighty, moving on, +**\ [anominal]** 4. Review open tickets (assigned and/or unassigned): status, code ideas (if applicable), etc. +**\ [anominal]** Let's see, +**\** anonimal, also, if EinMbyte can't make the meeting maybe we must collate stuff and raise it on his behalf ? +**\ [anominal]** How so? +**\** like if he just adds to the agenda then we can discuss it without him needing to be here +**\ [anominal]** Ok, well he's welcome to do that. +**\ [anominal]** But he and I are great at bouncing ideas off each other and getting to core issues, so I wish he would be present more often. +**\ [anominal]** I see, so we'll send him a note to add to the agenda regardless of his attending? +**\** yes I think that would help, he lacks time at the moment +**\ [anominal]** Ok. +**\ * anonimal** back to 4. +**\ [anominal]** #210 might be an easy fix, if any bitmonero devs want to take a peek. +**\** once you go Kovri you never go...uh...something that rhymes with Kovri +**\ [anominal]** lol +**\ [anominal]** That's a tough one.... +**\** https://github.com/monero-project/kovri/issues/210 <- for reference +**\ [anominal]** Remaining tickets are mostly all hard-core. I'll see what I can get into before the next meeting. Obviously the big ones would be nice if I can make the time. +**\ [anominal]** I may pick at #191 or #187 because I get irritated with severely broken things. +**\ [anominal]** Or who knows what, the world is full of mysterious and discovery. +**\** lol +**\ [anominal]** *mystery +**\ [anominal]** lol +**\** invent a time machine ! +**\ [anominal]** pffffffffff +**\ [anominal]** That would be fun. +**\** :-P +**\ [anominal]** Does anyone here work with Debian Jessie often? +**\** tewinget is an Arch user +**\** moneromooo wrote his own OS from scratch I'm sure +**\** osensei maybe +**\** but he's not around atm +**\** I use a pretty common one nowdays actually. +**\ [anominal]** Ok just curious. Arch here so #210 will probably take more than a few moments. +**\** moneromooo: Windows XP ? +**\ [anominal]** ^ Windows 98 +**\** Good point. I guess it's not that common. I forgot about windows. +**\ [anominal]** 95 was better at breaking. +**\ [anominal]** Ok, well re: 4., fluffypony have you see #209? +**\** probably +**\ [anominal]** 50% yay because we solved the coverity/travis issue! +**\** oh yes the Coverity thing +**\** ok so plz update me - Travis builds are now work +**\** *working +**\** but Coverity isn't triggering ? +**\ [anominal]** No, we are *finally* triggering, but now coverity says build is failing on their end. +**\ [anominal]** So, travis says "we're fine", coverity says "you're not fine but neither is most of my site". +**\ [anominal]** Because they really do have some issues there and support is... meh. +**\** LOL +**\** considering how long it took for their site to pick Travis up I'm not even surprised +**\** do we wait until they've fixed it, or keep pushing +**\ [anominal]** Seriously, and their "community" site is still offline despite "we'll be back in early 2016!". +**\ [anominal]** It's June already... +**\ [anominal]** Good question, +**\ [anominal]** I can review *why* they think our build failed, I could even try to do it manually. +**\ [anominal]** I may have to do it manually just to get things going *or*, it could be another travis/coverity issue (or just pure coverity). +**\** maybe we must switch to manual Coverity +**\** and just do it once every two weeks +**\ [anominal]** Sounds fair, I'll give it shot before next meeting. +**\ * anonimal** before I forget, opens https://github.com/monero-project/kovri/issues/assigned/fluffypony +**\ [anominal]** fluffypony: Any updates on #27? +**\ * anonimal** knows you've been busy, simply curious +**\** anonimal: no - also, we're switching providers +**\ [anominal]** Ok. +**\** debating Zoho vs. FastMail +**\** ProtonMail doesn't do multiple users on a domain, unfortunately +**\ [anominal]** Hmmm... +**\ [anominal]** Pros/Cons so far re: providers? +**\** well they're mostly doing forwarding and SMTP, so it's pretty open +**\** part of the decision making is cost, part is also reliability and if they feature reasonable web interfaces for those inevitable users that don't want to use a mail client +**\** will wrap that up soon, it's on my short list +**\ [anominal]** Ok, good to know. +**\ [anominal]** I don't have an opionion so far. If I do I'll be sure to chip in. +**\ [anominal]** Is xmrpromotions there? re: #105 +**\** no not online atm +**\** I'll prod them for that when I see them next +**\ [anominal]** K. +**\ * anonimal** typing +**\ [anominal]** I'll most likely take a look at bitmonero's 0MQ work too before next meeting (thinking of #53). +**\ [anominal]** Other than that, I may just grab some low hanging fruit before next meeting and work on the mingw build and other smaller tickets. +**\** anonimal, feel free to direct any 0mq questions at ~~fluffypony~~ me +**\ [anominal]** Thanks tewinget. +**\** oh yeah speaking of +**\** sad that my IRC client doesn't support strikeout...hoping someone else's does +**\** the Windows test box is borked +**\** msys2 decided to give up the ghost +**\** so doing a complete reinstall of it +**\ [anominal]** Yeah, so what happened? Any idea? +**\** no clue +**\ [anominal]** (very strange) +**\** On a scale from 1 to I hate compiling anything on Windows: I hate compiling anything on Windows. +**\** it's a binary scale. +**\ [anominal]** Oh windows, you never cease to disappoint me. +**\ [anominal]** Anything else on 4.? +**\ * anonimal** quick reviewing +**\ [EinMByte]** Hi, I'm late sorry +**\ [anominal]** EinMByte! Welcome back. +**\** wb EinMByte +**\** still 15 minutes left :) +**\ [anominal]** With 15 minutes or so to spare, any input? (much backlog) +**\ [EinMByte]** Something about #210 maybe: I'll provide some more information +**\ [anominal]** EinMByte: before I forget and while you're here: what is your preferred/most-reliable public contact method? +**\ [EinMByte]** public as in to put on a website or so, or as in where you guys can contact me +**\ [anominal]** So we can contact you. +**\ [anominal]** And would you be interested in leaving agenda TODO's/notes in meeting tickets in case you can't make a meeting that you'd hope to make? +**\ [EinMByte]** Well I'll be on IRC, or else einmbyte@mail.i2p or github +**\ [anominal]** Ok. +**\ [EinMByte]** sure +**\ [anominal]** fluffypony: did I word that correctly? +**\ [anominal]** EinMByte: we're still on point 4. "reviewing tickets", etc. +**\ [anominal]** Is there anything you wanted to add re: SSU? +**\ * anonimal** knows you just got back to working on it +**\** yes I think so +**\ [EinMByte]** Well I can give you a quick status update +**\ [anominal]** Awesome. +**\ [EinMByte]** So SSUSession.cpp is now using the new parsing code, except for the fragments +**\ [EinMByte]** (I have the code to parse data packets, just not using it yet) +**\ [EinMByte]** I am slowed down right now due to a bug, with the header I suspect +**\ [anominal]** Grrr... bugs... +**\ [EinMByte]** (Rekey options being set etc when this shouldn't happen, I think it's all related) +**\ [EinMByte]** Well, I'll try to fix it in the next days +**\ [anominal]** bitmonero devs: FYI, SSU is the ugly High School girl standing in the corner of the dance hall that no one will dance with because she is awkward and is a very mean person. +**\** lol +**\ [anominal]** In other words, SSU has needed much love and I'm glad EinMByte has tackled the challenge. +**\ [EinMByte]** Hah, nice comparison - although it does make me seem quite desperate :P +**\ [anominal]** lol, oops. Sorry EinMByte, I didn't mean it that way :( +**\ [EinMByte]** Once the parsing part is done, I'll do something similar to build the packets +**\ [anominal]** Sounds great. +**\ [anominal]** How about, EinMByte dances with her because he is a leader and willing to show great sympathy to those who need it most. +**\ [EinMByte]** I'll write some tests, but don't expect full coverage just yet. I don't think that's a priority right now. +**\ [anominal]** And turns down the more promising dancers to make SSU work well. +**\ [EinMByte]** (I want to get the API started too) +**\ * anonimal** sorry, I'm getting carried away +**\ [anominal]** Ok. +**\ [anominal]** Do you have an idea of schedule coming up? +**\ [anominal]** (as in availability) +**\ [EinMByte]** anonimal: You're making a lot of assumptions about my gender here :). But let's see how well that dance turns out +**\ [anominal]** I know, again my apologies. +**\ [EinMByte]** Yes, next week I'll be mostly available (several hours per day) +**\ [anominal]** Ok. I'll check my IRC more frequently then. +**\ [anominal]** Anything else on 4.? +**\ [EinMByte]** Well as I said I'll put up more info for #210 +**\ [anominal]** Ok. +**\ [EinMByte]** Seems like 2 tests are failing +**\ [anominal]** Since we're out of time, I don't see much on 5. except for a couple of quirky core ones that I may get to before next meeting. +**\ [anominal]** Any comments on 5.? +**\** EinMByte: well you can dance with SSUzy regardless of your gender +**\ [anominal]** SSUzy, lol. +**\ [EinMByte]** fluffypony: or my ability to dance :p +**\** everyone can dance, it's just a matter of how badly (or well) +**\ [anominal]** Paraplegics? +***\ * anonimal** doesn't do off-topic very often, quite the release. +**\ [anominal]** Ok so if no thoughts on 5., +**\** LOL +**\** nobody is going to attend the Kovri meeting in future :-P +**\ [anominal]** LMAO +**\ * anonimal** watches ship sailing away, burning in the distance +**\ [EinMByte]** See you all next time in #dancing +**\ [anominal]** Ok, last call for 5. Discuss any pertinent TODO's +**\** I think that's it from my side +**\** lol EinMByte +**\ [anominal]** lol, or #dancing-dev +**\ [EinMByte]** Well, for 5: If anyone wants to start on the API, you're welcome +**\ [EinMByte]** This also applies to all (any?) monero people reading this +**\ [anominal]** Good point, that's another big item to tackle. +**\ [EinMByte]** Since you're going to be the people using the API, making up a list of requirements would be nice +***\** kk +**\ [anominal]** 6. Any additional meeting items +**\ [anominal]** Just one from me, briefly, +**\** I think we've already discussed EinMByte's dancing enough, so nothing more from me on 6 +**\ [anominal]** Forum Funding. I plan on writing up some proposals within the next month or so. +**\** kk +**\ [anominal]** EinMByte: if you were crowdfunded on FFS, would you be able to devote any more dev time? +**\ [EinMByte]** I've already told fluffypony, not really +**\ [anominal]** Ok. +**\ [EinMByte]** If you can build me a time machine, yes +**\ * anonimal** was planning proposals to fund my work +**\ [anominal]** Funny, fluffypony mentioned that earlier (time machine). +**\** lol +**\ [anominal]** We should invest in one. The writing is on the wall. +**\ [anominal]** Last call for 6. +**\** new project for the Monero Research Lab to tackle +**\ [EinMByte]** But, as I've also told fluffypony, please do fund other programmers +**\ [anominal]** Agreed. +**\ [EinMByte]** Apparently you first need the programmer (before getting the money) so let's go find some C++ programmers +**\ [anominal]** fluffypony: ^ we should devote an entire meeting to that IMHO sometime within the next few months. +**\** yeah definitely +**\** would love to see a FFS proposal for kovri/i2p dev +**\** grimpants: we've had open-ended stuff before, the funds just sit there and no dev comes along - we need to first find someone interested that can price in their work, even if it's on a full time commitment for X long +**\ [EinMByte]** By the way, we don't need only expert C++ programmers +**\** and then we can raise funds accordingly +**\** i see +**\** been a while since ive check tbh +**\ [EinMByte]** We can use people who just write documentation / tests too +**\ [anominal]** ^ which is a great way for newcomers to learn the codebase. +**\** this may not be an honourable line of thought, but I've been wondering if there's any fall-out from the issues Tor are facing that might lead to some new contributors looking at Kovri +**\ [anominal]** Good concern, I think that's very plausible. +**\ [anominal]** But the devoted C person usually scoffs at C++ and turn their nose at Java. +**\** like hyc :-P +**\ [anominal]** I've become spoiled with STL so, I can't vouch for C devotees on more complex apps like Kovri. +**\ [anominal]** But bigger point: +**\ [anominal]** The world needs more options, so if Tor starts to burn, another ship will be ready. +**\ [anominal]** Some great minds there, so I'm not concerned about the near future. +**\ [anominal]** But that was a hefty loss on their end with the one who shall remain nameless. +**\** yeah, and the larger loss is how much emotional damage it did to people during the time it was kept hidden +**\** as a community I hope we can learn from that and call people out when they're out of line +**\ [anominal]** Yeah, everyone involved seems to have taken a loss. +**\ [anominal]** So, regarding that in relation to ship-jumpers: I think we should continue on our track of availability, professionalism, quality, code correctness and maintainability, +**\** 100% +**\ [anominal]** But, +**\ [EinMByte]** let's first get some people :) +**\ [anominal]** devs can be strong in their ways, so being malleable is also important (but that's a given). Constant ebb and flow. +**\ [anominal]** Anything else on 6.? +**\** that's it from my side +**\ [anominal]** 7. Confirm next meeting date/time +**\ [anominal]** Same time in two weeks? +**\ [EinMByte]** Nothing else from me +**\** yes same time in two weeks +**\ [anominal]** Alright. A million thanks to everyone. +**\** taking meeting-bot down \ No newline at end of file diff --git a/_posts/2016-06-19-overview-and-logs-for-the-dev-meeting-held-on-2016-06-19.md b/_posts/2016-06-19-overview-and-logs-for-the-dev-meeting-held-on-2016-06-19.md new file mode 100644 index 00000000..dda2f7bb --- /dev/null +++ b/_posts/2016-06-19-overview-and-logs-for-the-dev-meeting-held-on-2016-06-19.md @@ -0,0 +1,225 @@ +--- +layout: post +title: Overview and Logs for the Dev Meeting Held on 2016-06-19 +summary: C4, open PRs, and brief update on Ring CT and 0MQ +tags: [dev diaries, core, crypto, 0mq] +author: dEBRUYNE / fluffypony +--- + +*June 19th, 2016* + +# Overview (by Aerbax) + +An overview [can be found on Hello Monero](https://hellomonero.com/article/monero-bi-weekly-dev-meeting-note-highlights-2016-06-19) + +# Logs + +**\** ok +**\** hello and welcome +**\** ack +**\** Sup fluffypony +**\** so first things first +**\** [anonimal] EinMByte: ^ Monero meeting now, Kovri in about an hour or so (just FYI) +**\** after the last meeting, which was mostly focused on C4, we bounced some of that around +**\** I think the spirit of C4 is good, and will help keep Monero inclusionary towards new contributors +**\** but moneromooo in particular disagreed with some of the specifics +**\** or where C4 is a little vague +**\** so what we're going to do is fork C4 from Unprotocols / yrashk into the Monero repo +**\** [psi] c4? +**\** and we'll tweak it from there, keeping it in step with changes made upstream in Unprotocols +**\** psi: the Collaborative Code Construction Contract, see last meeting's minutes for an intro and discussion +**\** [anonimal] Or Kovri's contributing guide. +**\** yup +**\** I think everyone is aware that this is security software we're dealing with +**\** and we can't be crazy and accept things that may contain backdoors +**\** but we also want some structure that makes contributors feel welcome, even if their contributions need some work and aren't up to a standard we'd like +**\** somewhere inbetween being completely permissive and miring contributions in PR hell is a nice balance, and we'll figure it out +**\** We need to balance security and making contributors welcome +**\** yup exactly +**\** ok so on to more fiddly code bits, less soft skills +**\** I was hoping tewinget could update us on the 0MQ work, which is about to go up on the forum for funding +**\** ok +**\** My point was not security, it was more about the crazy wish to keep obvious crap in. +**\** https://www.github.com/tewinget/bitmonero/tree/zmq-dev **\<-- there's the branch, gimme one min to take care of something then I can brief +**\** ok +**\* fluffypony plays hold music +**\* tewinget is typing +**\* DaveyJones just watches +**\** ok, so far I've got cryptonote::classes to/from json for a majority of what will need to be serialized for RPC. I have a couple of RPC calls actually written and working via ZMQ (get_height get_transactions, and key_images_spent) +**\** that's more or less a summary of progress +**\** as far as process +**\** the idea is to try to create RPC as we want it to be, rather than trying to modify the existing structure, and then plug in backwards-compatibility later +**\** tewinget: so using the structure that is / was on the Wikia ? +**\** [psi] to rehash, you are redoing monero's wire protocol to use zmq correct? +**\** psi: no, not wire protocol, that will use ZMTP (a part of the 0MQ project) and come later +**\** psi: more or less, but a bit more than just that +**\** oh +**\** I mean, kinda wire, but not p2p yet +**\** rpc +**\** this is redoing the communication between the node and "clients" like miners / mining pool software / wallets / etc. +**\** [psi] kk +**\** [psi] zmtp is still being drafted correct? +**\** nope all done, afaik: http://zmtp.org +**\** \ tewinget: so using the structure that is / was on the Wikia ? <-- well, yes, but also I was hoping to get some input today (not necessarily now) from anyone who would like to comment on the future of RPC +**\** it's already on v3 +**\** ok so maybe one of the things we need to do now is move that design doc from the Wikia to the Github wiki +**\** wallet42: are you up to doing that, or busy travelling atm ? +**\** I can say that the few commands I've done don't necessarily conform to any spec like json-rpc, but that's easy to change -- structure is currently placeholder while functionality is implemented +**\** oh, one important detail I left out +**\** I think it's best if the RPC is straight json. This comes at a very, very minor cost in speed, but means that implementation in other languages will be far less intimidating for new contributors +**\** and I know I don't personally plan to write libMonero for every language out there... +**\** oh I agree - the idea behind 0MQ is for a language to use 0MQ bindings and just be able to talk straight to the daemon +**\** yup, and this way for any language that has json and zmq bindings, all one needs to do is give the language a cursory understanding of cryptonote structs +**\** if JSON is the way we want to do that that's fine, we can always modify it later to support Google's protobufs or something later on +**\** https://paste.fedoraproject.org/379294/14659488/ <-- there's an example of get_transactions +**\** it's also very nice to do ad-hoc testing via python :) +**\** cool +**\** any thoughts, anyone? +**\** fluffypony: In about 3 weeks im back in Berlin, right now i only have like 1 day a week. But yes the wiki will get more data as I am moving myself trough the code +**\** Especially better wiki documentation of the datatypes/protocol +**\** wiki.bitcoin.it/wiki/Protocol basically +**\** tewinget: how hard would it be to implement different schemes in future, like JSON / protobufs / ASN.1 BER ? +**\** wallet42: ok cool, thank you +**\** fluffypony: wouldn't be too bad, I'm trying to make things pretty modular. It wouldn't be too bad to make it a bit more generic than json +**\** it's already 90% ready for that as-is +**\** kk +**\** alright, tewinget anything else or can we move on to the next thing ? +**\** the ZMQ-side of things was pretty trivial tbh +**\** oh, anyone averse to having a separate listening port for publish/subscribe such as "new_block_notify" etc? +**\** you mean a separate port for pub-sub than the IPC port ? +**\** well, there will be a port for "request thing from daemon" +**\** can't use the same port for publish/subscribe, I'm pretty sure +**\** I don't see a problem with that +**\** without an unholy amount of added complexity that isn't worth at all +**\** one thing you may want to do is also look at Bitcoin's 0MQ effort +**\** I don't think wumpus is around at the moment +**\** but they've been pecking away at 0MQ for some time +**\** Isn't the point of 0MQ to abstract comms to allow things like that ? +**\** moneromooo: pub-sub is a different beast to control / request +**\** 0MQ uses different socket types like Request-Reply, or Pub/Sub +**\** normally for pub-sub you're sending a request once and then receiving "push" notifications forever +**\** and one socket can only be one type, and I don't think you can bind two sockets to the same port, as how would it route that? +**\** Bitcoin has walletnotify and blocknotify that work in that way +**\** so using the same port for req-rep and pub-sub would require...well, no, just no +**\** it would end up looking gross like the RPC stuff at the moment +**\** moreso, in fact +**\** different HTTP paths for the JSON and HTTP RPCs +**\** \ alright, tewinget anything else or can we move on to the next thing ? <-- happy to give a few minutes for any comments from anyone, but other than that I think that's about it +**\** cool if anything pops up over the rest of the meeting then we can see +**\** oh, and feel free to give feedback on the branch, I'll repaste the link in a sec. Feedback here or via github is fine +**\** https://www.github.com/tewinget/bitmonero/tree/zmq-dev +**\** ok next, moneromooo do you feel like giving an update on RingCT? looks like it's making nice headway :) +**\** It kinda works. I'm fixing bugs now. +**\** moneromooo: is it going to be a hard fork where all new transactions are v3 / ringCT, but they can spend pre-ringCT outs? +**\** They +**\** they = transactions +**\** coinbase will use non-ringct tho? +**\** othe: yes afaik +**\** They'll be v2 and can spend either pre rct outputs or rct ones. +**\** moneromooo: ooooh, so a soft fork? :-P +**\** Hmm. I haven't thought about the distinction tbh. +**\** Theoretically, coinbase might not even need to be in the clear I think. Though it'd require some shen magic. +**\** I think it'd be a hard fork, because old nodes won't understand rct outs +**\** so we'd have to bump the block version anyway +**\** But will non RingCT other than coninbase transactions be valid? +**\** Oh they'd reject new txes, yes. +**\** fluffypony: I'm thinking of an unprotocol for describing diverged unprotocols +**\** So meta +**\** moneromooo: ok then that's hard fork +**\** lol yrashk +**\** But I'm actually serious +**\** :) +**\** yrashk: what's that Unprotocol for creating protocols with consensus? +**\** ArticMine: I think post-fork that all non-coinbase tx will be ringCT, but I'm not sure. +**\** ArticMine: if you mean "will non RingCT outputs other than coninbase transactions be valid?", then I'd choose no, but it could be made either way. +**\** fluffypony: COSS? There's nothing about consensus there +**\** yrashk: yes that - but it's about creating new protocols as a group, right ? +**\** Kind of but very very lightweight +**\** kk +**\** Which is a good thing generally +**\** Greetings fellas +**\** moneromooo: I tend to agree with you - coinbase txs is fine, but after that it should be rct only +**\** Crazyflashpie stoping by to say hello +**\** fluffypony: are you interested to collaborate on the protocol divergence protocol? (PDP) +**\** hi CFP +**\** Looks like the # of nodes in China is climbing? +**\** yrashk: let's chat after the meeting, definitely interested in discussing it, as it's relevant to us +**\** I can explain my motivations behind it +**\** Today? +**\** Ping me on telegram or here when ready +**\** kk +**\** ok next I just wanted to bounce through some open PRs +**\** #818 is still open pending luigi1111w / luigi1112 coming up with those spec changes, no rush there +**\** moneromooo I would expect non RingCT outputs other than coinbase to be invalid after a given block +**\** #775 is ready to be merged - moneromooo, just to double check, you're fine with that, right ? +**\** With the 6 month upgrade cycle built in +**\** ArticMine: agreed +**\** Yes I'll try to do that this week +**\** Yes. It's a wee bit spammier now in the logs, but other than that it's good to go. +**\** ok then #810, the caching thing, I'm still confused as to whether we must merge or not +**\** Not sure. I think enough said no. +**\** ok I'll close it, we can reopen later +**\** But then nobody patched the pool code :) +**\** and pools can manually pull that in if they need +**\** then the gcc 6.1 stuff - as I understand it there are more changes than what is covered in those two PRs +**\** so do we close the PRs and just note that "gcc 6.1 not supported yet" +**\ [anonimal]** Noooooooo......... +**\** or do we merge them in preparation for supporting 6.1 ? +**\ [anonimal]** Please nooooooo.... +**\** lol anonimal +**\** If they'll be needed anyway... +**\ [anonimal]** This also re: #846? +**\** One of them is a superset of the other IIRC. +**\** anonimal: yeah, 846 and 845 +**\ [anonimal]** radfish's work builds, so is the problem more eyes/more time to review? +**\** anonimal: it was more that I was travelling, so I don't really know which is the superset of which, and which to close / merge / bail out of entirely :-P +**\ [anonimal]** Oh, well I can spend some time this week giving input if that helps. +**\** 846 seems to be the superset. +**\** PR X is a superset of PR Y seems like an odd situation to be in... +**\** especially if both are open +**\** tewinget: quite +**\** I had to merge them to get the repo to compile as GCC 6.1 is default for Arch +**\** kk +**\ [anonimal]** re: that ^, I only merged #846 and builds fine. +**\ [anonimal]** I see the issue of both PR's being open, I can comment further this week after looking at them if they are still open by then. +**\** Yep, only needed #846. @tewinget should enable testing repo too :) +**\** ok then I'll close 845 and merge 846 +**\ [anonimal]** Ok. +**\** then #856 I've reviewed and will merge +**\** #855 seems fine to me, I defer to hyc's knowledge of his own product ;) +**\** #863 seems fine too +**\** #862 - luigi1112 can I take your comment as a review? +**\** Oh. Let me change it now... +**\** tewinget, i may try and put this in a comment on the https://www.github.com/tewinget/bitmonero/tree/zmq-dev , but is this the space wherein the daemon could have multiple rpc ports with different characteristics? +**\** I think it's fine yeah +**\** pushed +**\** k +**\ [anonimal]** Has there been any definitive decisions re: C4 since previous meeting? I know there are differing arguments. +**\** anonimal - yes, my comments at the beginning of the meeting, will let you know when the log is up if you missed them +**\** gingeropolous: not entirely sure what you mean to ask there +**\ [anonimal]** "we'll figure it out" <-- was that it? +**\** i.e., port 18081 would be full access, and 18082 could be less access. +**\** anonimal: yes basically the next step is fork ->** adjust accordingly ->** decide to abandon or adopt the iteration +**\** right now if you want different permissions for remote access to the daemon, you need multiple daemons and multiple databases +**\** isnt an auth system with permissons better for this +**\** gingeropolous: I'm of a mind that we need a finer distinction than "trusted daemon" and "not trusted" +**\** we need a proper ACL +**\** what othe said +**\** so shelve it as a thing to do later on +**\** word +**\** ok I think that's it from my side - anything else before we move to the Kovri meeting? +**\** glad someone else could answer that while I was rebooting. Stupid computer crashes frequently, pretty sure it's hardware. +**\** tewinget: you should buy a Mac :-P +**\** No +**\** fluffypony: I thought we were friends... +**\** tbh if a newer Mac (not new, with that single port, but new-ish) landed on my lap I'd throw Linux on it and use it +**\** but I'd never buy one, they're way too expensive for what they are. +**\** actually the macbook pro are good value for money compared to other ultrabooks; anyway kovir next :p +**\** Pro Retina is great, although I've switched my Purism Librem 13 + Qubes for anything remotely sensitive +**\** Hackintosh user here :-) It's pretty easy to install OSX if you choose hardware carefully. +**\** works pretty much perfectly. +**\** correct, also run a hackintosh desktop +**\** I see the software not the hardware as the issue with Mac +**\ * anonimal** has 8 year old hackbook pro running Arch :/ +**\ [anonimal]** Still alive, surprisingly. +**\** nice \ No newline at end of file