Overview (by Aerbax)

An overview can be found on Hello Monero

Logs

<fluffypony> ok <fluffypony> hello and welcome <tewinget> ack <wallet42> Sup fluffypony <fluffypony> so first things first <meeting-bot> [anonimal] EinMByte: ^ Monero meeting now, Kovri in about an hour or so (just FYI) <fluffypony> after the last meeting, which was mostly focused on C4, we bounced some of that around <fluffypony> I think the spirit of C4 is good, and will help keep Monero inclusionary towards new contributors <fluffypony> but moneromooo in particular disagreed with some of the specifics <fluffypony> or where C4 is a little vague <fluffypony> so what we're going to do is fork C4 from Unprotocols / yrashk into the Monero repo <meeting-bot> [psi] c4? <fluffypony> and we'll tweak it from there, keeping it in step with changes made upstream in Unprotocols <fluffypony> psi: the Collaborative Code Construction Contract, see last meeting's minutes for an intro and discussion <meeting-bot> [anonimal] Or Kovri's contributing guide. <fluffypony> yup <fluffypony> I think everyone is aware that this is security software we're dealing with <fluffypony> and we can't be crazy and accept things that may contain backdoors <fluffypony> 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 <fluffypony> somewhere inbetween being completely permissive and miring contributions in PR hell is a nice balance, and we'll figure it out <ArticMine> We need to balance security and making contributors welcome <fluffypony> yup exactly <fluffypony> ok so on to more fiddly code bits, less soft skills <fluffypony> I was hoping tewinget could update us on the 0MQ work, which is about to go up on the forum for funding <tewinget> ok <moneromooo> My point was not security, it was more about the crazy wish to keep obvious crap in. <tewinget> 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 <fluffypony> ok *** fluffypony plays hold music * tewinget is typing * DaveyJones just watches <tewinget> 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) <tewinget> that's more or less a summary of progress <tewinget> as far as process <tewinget> 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 <fluffypony> tewinget: so using the structure that is / was on the Wikia ? <meeting-bot> [psi] to rehash, you are redoing monero's wire protocol to use zmq correct? <fluffypony> psi: no, not wire protocol, that will use ZMTP (a part of the 0MQ project) and come later <tewinget> psi: more or less, but a bit more than just that <tewinget> oh <tewinget> I mean, kinda wire, but not p2p yet <tewinget> rpc <fluffypony> this is redoing the communication between the node and "clients" like miners / mining pool software / wallets / etc. <meeting-bot> [psi] kk <meeting-bot> [psi] zmtp is still being drafted correct? <fluffypony> nope all done, afaik: http://zmtp.org <tewinget> <fluffypony> 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 <fluffypony> it's already on v3 <fluffypony> ok so maybe one of the things we need to do now is move that design doc from the Wikia to the Github wiki <fluffypony> wallet42: are you up to doing that, or busy travelling atm ? <tewinget> 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 <tewinget> oh, one important detail I left out <tewinget> 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 <tewinget> and I know I don't personally plan to write libMonero for every language out there... <fluffypony> 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 <tewinget> 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 <fluffypony> 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 <tewinget> https://paste.fedoraproject.org/379294/14659488/ <-- there's an example of get_transactions <tewinget> it's also very nice to do ad-hoc testing via python :) <fluffypony> cool <tewinget> any thoughts, anyone? <wallet42> 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 <wallet42> Especially better wiki documentation of the datatypes/protocol <wallet42> wiki.bitcoin.it/wiki/Protocol basically <fluffypony> tewinget: how hard would it be to implement different schemes in future, like JSON / protobufs / ASN.1 BER ? <fluffypony> wallet42: ok cool, thank you <tewinget> 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 <tewinget> it's already 90% ready for that as-is <fluffypony> kk <fluffypony> alright, tewinget anything else or can we move on to the next thing ? <tewinget> the ZMQ-side of things was pretty trivial tbh <tewinget> oh, anyone averse to having a separate listening port for publish/subscribe such as "new_block_notify" etc? <fluffypony> you mean a separate port for pub-sub than the IPC port ? <tewinget> well, there will be a port for "request thing from daemon" <tewinget> can't use the same port for publish/subscribe, I'm pretty sure <fluffypony> I don't see a problem with that <tewinget> without an unholy amount of added complexity that isn't worth at all <fluffypony> one thing you may want to do is also look at Bitcoin's 0MQ effort <fluffypony> I don't think wumpus is around at the moment <fluffypony> but they've been pecking away at 0MQ for some time <moneromooo> Isn't the point of 0MQ to abstract comms to allow things like that ? <fluffypony> moneromooo: pub-sub is a different beast to control / request <tewinget> 0MQ uses different socket types like Request-Reply, or Pub/Sub <fluffypony> normally for pub-sub you're sending a request once and then receiving "push" notifications forever <tewinget> 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? <fluffypony> Bitcoin has walletnotify and blocknotify that work in that way <tewinget> so using the same port for req-rep and pub-sub would require...well, no, just no <fluffypony> it would end up looking gross like the RPC stuff at the moment <tewinget> moreso, in fact <fluffypony> different HTTP paths for the JSON and HTTP RPCs <tewinget> <fluffypony> 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 <fluffypony> cool if anything pops up over the rest of the meeting then we can see <tewinget> 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 <tewinget> https://www.github.com/tewinget/bitmonero/tree/zmq-dev <fluffypony> ok next, moneromooo do you feel like giving an update on RingCT? looks like it's making nice headway :) <moneromooo> It kinda works. I'm fixing bugs now. <fluffypony> moneromooo: is it going to be a hard fork where all new transactions are v3 / ringCT, but they can spend pre-ringCT outs? <moneromooo> They <fluffypony> they = transactions <othe> coinbase will use non-ringct tho? <fluffypony> othe: yes afaik <moneromooo> They'll be v2 and can spend either pre rct outputs or rct ones. <fluffypony> moneromooo: ooooh, so a soft fork? :-P <moneromooo> Hmm. I haven't thought about the distinction tbh. <moneromooo> Theoretically, coinbase might not even need to be in the clear I think. Though it'd require some shen magic. <fluffypony> I think it'd be a hard fork, because old nodes won't understand rct outs <fluffypony> so we'd have to bump the block version anyway <ArticMine> But will non RingCT other than coninbase transactions be valid? <moneromooo> Oh they'd reject new txes, yes. <yrashk> fluffypony: I'm thinking of an unprotocol for describing diverged unprotocols <yrashk> So meta <fluffypony> moneromooo: ok then that's hard fork <fluffypony> lol yrashk <yrashk> But I'm actually serious <yrashk> :) <fluffypony> yrashk: what's that Unprotocol for creating protocols with consensus? <tewinget> ArticMine: I think post-fork that all non-coinbase tx will be ringCT, but I'm not sure. <moneromooo> 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. <yrashk> fluffypony: COSS? There's nothing about consensus there <fluffypony> yrashk: yes that - but it's about creating new protocols as a group, right ? <yrashk> Kind of but very very lightweight <fluffypony> kk <yrashk> Which is a good thing generally <CFP> Greetings fellas <fluffypony> moneromooo: I tend to agree with you - coinbase txs is fine, but after that it should be rct only <CFP> Crazyflashpie stoping by to say hello <yrashk> fluffypony: are you interested to collaborate on the protocol divergence protocol? (PDP) <fluffypony> hi CFP <CFP> Looks like the # of nodes in China is climbing? <fluffypony> yrashk: let's chat after the meeting, definitely interested in discussing it, as it's relevant to us <yrashk> I can explain my motivations behind it <yrashk> Today? <yrashk> Ping me on telegram or here when ready <fluffypony> kk <fluffypony> ok next I just wanted to bounce through some open PRs <fluffypony> #818 is still open pending luigi1111w / luigi1112 coming up with those spec changes, no rush there <ArticMine> moneromooo I would expect non RingCT outputs other than coinbase to be invalid after a given block <fluffypony> #775 is ready to be merged - moneromooo, just to double check, you're fine with that, right ? <ArticMine> With the 6 month upgrade cycle built in <fluffypony> ArticMine: agreed <luigi1112> Yes I'll try to do that this week <moneromooo> Yes. It's a wee bit spammier now in the logs, but other than that it's good to go. <fluffypony> ok then #810, the caching thing, I'm still confused as to whether we must merge or not <moneromooo> Not sure. I think enough said no. <fluffypony> ok I'll close it, we can reopen later <moneromooo> But then nobody patched the pool code :) <fluffypony> and pools can manually pull that in if they need <fluffypony> then the gcc 6.1 stuff - as I understand it there are more changes than what is covered in those two PRs <fluffypony> so do we close the PRs and just note that "gcc 6.1 not supported yet" <meeting-bot> [anonimal] Noooooooo......... <fluffypony> or do we merge them in preparation for supporting 6.1 ? <meeting-bot> [anonimal] Please nooooooo.... <fluffypony> lol anonimal <moneromooo> If they'll be needed anyway... <meeting-bot> [anonimal] This also re: #846? <moneromooo> One of them is a superset of the other IIRC. <fluffypony> anonimal: yeah, 846 and 845 <meeting-bot> [anonimal] radfish's work builds, so is the problem more eyes/more time to review? <fluffypony> 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 <meeting-bot> [anonimal] Oh, well I can spend some time this week giving input if that helps. <moneromooo> 846 seems to be the superset. <tewinget> PR X is a superset of PR Y seems like an odd situation to be in... <tewinget> especially if both are open <fluffypony> tewinget: quite <neosilky_> I had to merge them to get the repo to compile as GCC 6.1 is default for Arch <fluffypony> kk <meeting-bot> [anonimal] re: that ^, I only merged #846 and builds fine. <meeting-bot> [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. <neosilky_> Yep, only needed #846. @tewinget should enable testing repo too :) <fluffypony> ok then I'll close 845 and merge 846 <meeting-bot> [anonimal] Ok. <fluffypony> then #856 I've reviewed and will merge <fluffypony> #855 seems fine to me, I defer to hyc's knowledge of his own product ;) <fluffypony> #863 seems fine too <fluffypony> #862 - luigi1112 can I take your comment as a review? <moneromooo> Oh. Let me change it now... <gingeropolous> 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? <luigi1112> I think it's fine yeah <moneromooo> pushed <fluffypony> k <meeting-bot> [anonimal] Has there been any definitive decisions re: C4 since previous meeting? I know there are differing arguments. <fluffypony> anonimal - yes, my comments at the beginning of the meeting, will let you know when the log is up if you missed them <tewinget> gingeropolous: not entirely sure what you mean to ask there <meeting-bot> [anonimal] "we'll figure it out" <-- was that it? <gingeropolous> i.e., port 18081 would be full access, and 18082 could be less access. <fluffypony> anonimal: yes basically the next step is fork -> adjust accordingly -> decide to abandon or adopt the iteration <gingeropolous> right now if you want different permissions for remote access to the daemon, you need multiple daemons and multiple databases <othe> isnt an auth system with permissons better for this <fluffypony> gingeropolous: I'm of a mind that we need a finer distinction than "trusted daemon" and "not trusted" <fluffypony> we need a proper ACL <fluffypony> what othe said <fluffypony> so shelve it as a thing to do later on <gingeropolous> word <fluffypony> ok I think that's it from my side - anything else before we move to the Kovri meeting? <tewinget> glad someone else could answer that while I was rebooting. Stupid computer crashes frequently, pretty sure it's hardware. <fluffypony> tewinget: you should buy a Mac :-P <ArticMine> No <tewinget> fluffypony: I thought we were friends... <tewinget> 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 <tewinget> but I'd never buy one, they're way too expensive for what they are. <othe> actually the macbook pro are good value for money compared to other ultrabooks; anyway kovir next :p <fluffypony> Pro Retina is great, although I've switched my Purism Librem 13 + Qubes for anything remotely sensitive <antanst1> Hackintosh user here :-) It's pretty easy to install OSX if you choose hardware carefully. <antanst1> works pretty much perfectly. <othe> correct, also run a hackintosh desktop <ArticMine> I see the software not the hardware as the issue with Mac <meeting-bot> * anonimal has 8 year old hackbook pro running Arch :/ <meeting-bot> [anonimal] Still alive, surprisingly. <fluffypony> nice

16 KiB Raw Blame History

Overview (by Aerbax)

Logs

16 KiB

Raw Blame History