17 KiB
| layout | title | summary | tags | author | ||||
|---|---|---|---|---|---|---|---|---|
| post | Overview and Logs for the Dev Meeting Held on 2016-06-19 | C4, open PRs, and brief update on Ring CT and 0MQ |
|
dEBRUYNE / fluffypony |
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