Monero Bi-Weekly Dev Meeting Note Highlights – 2016-06-19
Logs
351 lines
fluffyponyok
fluffyponyhello and welcome
tewingetack
wallet42Sup fluffypony
fluffyponyso first things first
botanonimalEinMByte: ^ Monero meeting now, Kovri in about an hour or so (just FYI)
fluffyponyafter the last meeting, which was mostly focused on C4, we bounced some of that around
fluffyponyI think the spirit of C4 is good, and will help keep Monero inclusionary towards new contributors
fluffyponybut moneromooo in particular disagreed with some of the specifics
fluffyponyor where C4 is a little vague
fluffyponyso what we're going to do is fork C4 from Unprotocols / yrashk into the Monero repo
botpsic4?
fluffyponyand we'll tweak it from there, keeping it in step with changes made upstream in Unprotocols
fluffyponypsi: the Collaborative Code Construction Contract, see last meeting's minutes for an intro and discussion
botanonimalOr Kovri's contributing guide.
fluffyponyyup
fluffyponyI think everyone is aware that this is security software we're dealing with
fluffyponyand we can't be crazy and accept things that may contain backdoors
fluffyponybut 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
fluffyponysomewhere inbetween being completely permissive and miring contributions in PR hell is a nice balance, and we'll figure it out
ArticMineWe need to balance security and making contributors welcome
fluffyponyyup exactly
fluffyponyok so on to more fiddly code bits, less soft skills
fluffyponyI was hoping tewinget could update us on the 0MQ work, which is about to go up on the forum for funding
tewingetok
moneromoooMy point was not security, it was more about the crazy wish to keep obvious crap in.
tewingethttps://www.github.com/tewinget/bitmonero/tree/zmq-dev <– there's the branch, gimme one min to take care of something then I can brief
fluffyponyok
fluffyponyplays hold music
tewingetis typing
DaveyJonesjust watches
tewingetok, 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)
tewingetthat's more or less a summary of progress
tewingetas far as process
tewingetthe 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
fluffyponytewinget: so using the structure that is / was on the Wikia ?
botpsito rehash, you are redoing monero's wire protocol to use zmq correct?
fluffyponypsi: no, not wire protocol, that will use ZMTP (a part of the 0MQ project) and come later
tewingetpsi: more or less, but a bit more than just that
tewingetoh
tewingetI mean, kinda wire, but not p2p yet
tewingetrpc
fluffyponythis is redoing the communication between the node and "clients" like miners / mining pool software / wallets / etc.
botpsikk
botpsizmtp is still being drafted correct?
fluffyponynope 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
fluffyponyit's already on v3
fluffyponyok so maybe one of the things we need to do now is move that design doc from the Wikia to the Github wiki
fluffyponywallet42: are you up to doing that, or busy travelling atm ?
tewingetI 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
tewingetoh, one important detail I left out
tewingetI 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
tewingetand I know I don't personally plan to write libMonero for every language out there…
fluffyponyoh I agree - the idea behind 0MQ is for a language to use 0MQ bindings and just be able to talk straight to the daemon
tewingetyup, 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
fluffyponyif 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
tewingethttps://paste.fedoraproject.org/379294/14659488/ <– there's an example of get_transactions
tewingetit's also very nice to do ad-hoc testing via python :)
fluffyponycool
tewingetany thoughts, anyone?
wallet42fluffypony: 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
wallet42Especially better wiki documentation of the datatypes/protocol
wallet42wiki.bitcoin.it/wiki/Protocol basically
fluffyponytewinget: how hard would it be to implement different schemes in future, like JSON / protobufs / ASN.1 BER ?
fluffyponywallet42: ok cool, thank you
tewingetfluffypony: 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
tewingetit's already 90% ready for that as-is
fluffyponykk
fluffyponyalright, tewinget anything else or can we move on to the next thing ?
tewingetthe ZMQ-side of things was pretty trivial tbh
tewingetoh, anyone averse to having a separate listening port for publish/subscribe such as "new_block_notify" etc?
fluffyponyyou mean a separate port for pub-sub than the IPC port ?
tewingetwell, there will be a port for "request thing from daemon"
tewingetcan't use the same port for publish/subscribe, I'm pretty sure
fluffyponyI don't see a problem with that
tewingetwithout an unholy amount of added complexity that isn't worth at all
fluffyponyone thing you may want to do is also look at Bitcoin's 0MQ effort
fluffyponyI don't think wumpus is around at the moment
fluffyponybut they've been pecking away at 0MQ for some time
moneromoooIsn't the point of 0MQ to abstract comms to allow things like that ?
fluffyponymoneromooo: pub-sub is a different beast to control / request
tewinget0MQ uses different socket types like Request-Reply, or Pub/Sub
fluffyponynormally for pub-sub you're sending a request once and then receiving "push" notifications forever
tewingetand 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?
fluffyponyBitcoin has walletnotify and blocknotify that work in that way
tewingetso using the same port for req-rep and pub-sub would require…well, no, just no
fluffyponyit would end up looking gross like the RPC stuff at the moment
tewingetmoreso, in fact
fluffyponydifferent 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
fluffyponycool if anything pops up over the rest of the meeting then we can see
tewingetoh, and feel free to give feedback on the branch, I'll repaste the link in a sec. Feedback here or via github is fine
fluffyponyok next, moneromooo do you feel like giving an update on RingCT? looks like it's making nice headway :)
moneromoooIt kinda works. I'm fixing bugs now.
fluffyponymoneromooo: is it going to be a hard fork where all new transactions are v3 / ringCT, but they can spend pre-ringCT outs?
moneromoooThey
fluffyponythey = transactions
othecoinbase will use non-ringct tho?
fluffyponyothe: yes afaik
moneromoooThey'll be v2 and can spend either pre rct outputs or rct ones.
fluffyponymoneromooo: ooooh, so a soft fork? :-P
moneromoooHmm. I haven't thought about the distinction tbh.
moneromoooTheoretically, coinbase might not even need to be in the clear I think. Though it'd require some shen magic.
fluffyponyI think it'd be a hard fork, because old nodes won't understand rct outs
fluffyponyso we'd have to bump the block version anyway
ArticMineBut will non RingCT other than coninbase transactions be valid?
moneromoooOh they'd reject new txes, yes.
yrashkfluffypony: I'm thinking of an unprotocol for describing diverged unprotocols
yrashkSo meta
fluffyponymoneromooo: ok then that's hard fork
fluffyponylol yrashk
yrashkBut I'm actually serious
yrashk:)
fluffyponyyrashk: what's that Unprotocol for creating protocols with consensus?
tewingetArticMine: I think post-fork that all non-coinbase tx will be ringCT, but I'm not sure.
moneromoooArticMine: 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.
yrashkfluffypony: COSS? There's nothing about consensus there
fluffyponyyrashk: yes that - but it's about creating new protocols as a group, right ?
yrashkKind of but very very lightweight
fluffyponykk
yrashkWhich is a good thing generally
CFPGreetings fellas
fluffyponymoneromooo: I tend to agree with you - coinbase txs is fine, but after that it should be rct only
CFPCrazyflashpie stoping by to say hello
yrashkfluffypony: are you interested to collaborate on the protocol divergence protocol? (PDP)
fluffyponyhi CFP
CFPLooks like the # of nodes in China is climbing?
fluffyponyyrashk: let's chat after the meeting, definitely interested in discussing it, as it's relevant to us
yrashkI can explain my motivations behind it
yrashkToday?
yrashkPing me on telegram or here when ready
fluffyponykk
fluffyponyok 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
ArticMinemoneromooo 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 ?
ArticMineWith the 6 month upgrade cycle built in
fluffyponyArticMine: agreed
luigi1112Yes I'll try to do that this week
moneromoooYes. It's a wee bit spammier now in the logs, but other than that it's good to go.
fluffyponyok then #810, the caching thing, I'm still confused as to whether we must merge or not
moneromoooNot sure. I think enough said no.
fluffyponyok I'll close it, we can reopen later
moneromoooBut then nobody patched the pool code :)
fluffyponyand pools can manually pull that in if they need
fluffyponythen the gcc 6.1 stuff - as I understand it there are more changes than what is covered in those two PRs
fluffyponyso do we close the PRs and just note that "gcc 6.1 not supported yet"
botanonimalNoooooooo………
fluffyponyor do we merge them in preparation for supporting 6.1 ?
botanonimalPlease nooooooo….
fluffyponylol anonimal
moneromoooIf they'll be needed anyway…
botanonimalThis also re: #846?
moneromoooOne of them is a superset of the other IIRC.
fluffyponyanonimal: yeah, 846 and 845
botanonimalradfish's work builds, so is the problem more eyes/more time to review?
fluffyponyanonimal: 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
botanonimalOh, well I can spend some time this week giving input if that helps.
moneromooo846 seems to be the superset.
tewingetPR X is a superset of PR Y seems like an odd situation to be in…
tewingetespecially if both are open
fluffyponytewinget: quite
neosilky_I had to merge them to get the repo to compile as GCC 6.1 is default for Arch
fluffyponykk
botanonimalre: that ^, I only merged #846 and builds fine.
botanonimalI 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 :)
fluffyponyok then I'll close 845 and merge 846
botanonimalOk.
fluffyponythen #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?
moneromoooOh. Let me change it now…
gingeropoloustewinget, 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?
luigi1112I think it's fine yeah
moneromooopushed
fluffyponyk
botanonimalHas there been any definitive decisions re: C4 since previous meeting? I know there are differing arguments.
fluffyponyanonimal - yes, my comments at the beginning of the meeting, will let you know when the log is up if you missed them
tewingetgingeropolous: not entirely sure what you mean to ask there
botanonimal"we'll figure it out" <– was that it?
gingeropolousi.e., port 18081 would be full access, and 18082 could be less access.
fluffyponyanonimal: yes basically the next step is fork ->** adjust accordingly ->** decide to abandon or adopt the iteration
gingeropolousright now if you want different permissions for remote access to the daemon, you need multiple daemons and multiple databases
otheisnt an auth system with permissons better for this
fluffyponygingeropolous: I'm of a mind that we need a finer distinction than "trusted daemon" and "not trusted"
fluffyponywe need a proper ACL
fluffyponywhat othe said
fluffyponyso shelve it as a thing to do later on
gingeropolousword
fluffyponyok I think that's it from my side - anything else before we move to the Kovri meeting?
tewingetglad someone else could answer that while I was rebooting. Stupid computer crashes frequently, pretty sure it's hardware.
fluffyponytewinget: you should buy a Mac :-P
ArticMineNo
tewingetfluffypony: I thought we were friends…
tewingettbh 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
tewingetbut I'd never buy one, they're way too expensive for what they are.
otheactually the macbook pro are good value for money compared to other ultrabooks; anyway kovir next :p
fluffyponyPro Retina is great, although I've switched my Purism Librem 13 + Qubes for anything remotely sensitive
antanst1Hackintosh user here :-) It's pretty easy to install OSX if you choose hardware carefully.
antanst1works pretty much perfectly.
othecorrect, also run a hackintosh desktop
ArticMineI see the software not the hardware as the issue with Mac
meeting-botanonimal has 8 year old hackbook pro running Arch :/
botanonimalStill alive, surprisingly.
fluffyponynice
Sources and notes
- Meeting log: Overview and Logs for the Dev Meeting Held on 2016-06-19, getmonero.org. The official post carried the raw log and pointed readers to Hello Monero for the overview.
- Original Hello Monero URL slug recovered from the Wayback Machine index; the original page content did not survive, so this reconstruction carries the log as archived by the Monero Project.