--- layout: post title: Overview and Logs for the Dev Meeting Held on 2019-06-30 summary: Development status, Code & ticket discussion, and miscellaneous tags: [dev diaries, core, crypto] author: el00ruobuob / rehrar --- # Logs **\** hey guys **\** it's time for a meeting **\** as always, we'll try not to drag and make this longer then it needs to be. **\** 1. Greetings **\** Hi **\** Hi! **\** Hi **\** shalom **\** Alright. 2. What's been completed since last meeting. **\** Anyone have an update on stuff? **\** dsc\_ selsta dEBRUYNE for GUI people? **\** moneromooo TheCharlatan CLI? **\** thecharlatan working on reproducible builds for GUI **\** fluffypony luigi1111 smooth for Core Team? **\** I'm working on better tails integration **\** GUI v0.14.1.0 is around the corner **\** Ah, that corner? **\** I've updated https://autonode.xmr.pm/ to show more remote nodes **\** I did some more work on share-rpc, seeing someone's started reviewing. **\** It would be nice if more people reviewed, and if someone did something with it **\** moneromooo: do you consider the CLSAG implementation branch suitable for PR/review (not to merge yet, just for review) **\** Yes. **\** It doens't have your latest changes though. **\** Right, and I plan to update 5707 (and its CLSAG equivalent) again soon **\** those are pretty minor overall **\** Then it might not be be ready. **\** I don't have an update **\** thanks for the update luigi1111 **\** luigi1111: you can update us on the brand of soda the core team drinks as the relax in the lounge **\** With respect to a timeline for CLSAG, is October too optimistic? We must also take into account third party wallet providers, which will have to make changes too **\** thanks everyone for the updates **\** dEBRUYNE: this is going to be unpopular to say, as it's been discussed before, but if we're "right on the edge" with CLSAG, then why not just push the fork back a month? **\** dEBRUYNE: No final word from potential reviewers yet... I reached out again **\** So I do not have a timeline for CLSAG review **\** 25% savings in ring sigs is kind of cool and nice to have. **\** rehrar: So push the October fork back to November? **\** if it'd give us the breathing room that would make enough people more comfortable with the timing, then yes **\** Why not wait until spring? **\** Ah, wait no. we want RandomX in ASAP, huh? **\** This is 25% savings just for the ring sigs portion, not the entire tx, right? I don't see the reason for the push **\** so pushing it back maybe isn't great **\** vtnerd\_\_: a 2-2 txn shrinks by 25% overall **\** not just sigs **\** (ring sigs themselves shrink by approx 50%) **\** oof **\** My gut feeling tells me that RandomX and those CLSAG thing together will be a bit too much ... **\** Hmm need to read the paper then, didn't realize it dropped that much **\** you save 320 bytes per spent input **\** and about 20% on sig verification time **\** They are separate things entirely **\** They are either ready independently or not **\** And to clarify, there's working code already that anyone is free to review **\** (verification code will be tweaked a bit still) **\** Yeah the issue was a math review though ... ? **\** Yes, and a formal code review **\** But getting early internal review would be useful **\** even though waiting on bulletproofs was a good idea, it was still painful to have that six months of big big transactions **\** Oh you wanted both for this too? Ok **\** that we forever carry **\** vtnerd\_\_: it's important enough that I think both math/code review are important **\** esp. since MLSAG never got a formal audit **\** I mean its either that or risk an entire blow up of the coin **\** In response to rehrar **\** sarang: I'd be fine with spring, that at least gives third wallet providers plenty of time to work on it **\** I think spring yes **\** for clsag **\** yes, but my suggestion was pushign back a month for audits **\** which lessens chance of coin blow up **\** Well, I can let everyone know when I hear back from our potential reviewers **\** OSTIF are also putting out feelers **\ \** yes, but my suggestion was pushign back a month for audits \<= Can you elaborate? **\** Has anyone heard from fluffy regarding GUI release? **\** Has he arrived home yet? **\** if someone could see into the future, we can both see the outcome of the audits as well as save money by not paying for them **\** If we wait with CLSAG until spring, will there be time to build something nice on top of it until then in addition? **\** Also: earlier internal code review may reveal bugs that we can fix before sending code off to the reviewers **\** rbrunner: ? **\** dEBRUYNE: it's just pushing this fall fork back one month to give some breathing room to get some CLSAG audits in **\** Like those famous atomic swaps, or whatever **\** but as I said I see reasons not to do that. It was more in response to vtnerd\_\_ **\** dsc\_: https://www.reddit.com/r/Monero/comments/c6y542/any\_news\_on\_the\_gui\_release/esc02my/ **\** DLSAG's key image issue makes it unsuitable for implementation just yet, IMO **\** CLSAG is basically ready without such (known) problems **\** rehrar: Seems like a bit of a slippery slope **\** Seems safer and more prudent to wait six months **\** In the grand scheme of things six months isn't that much anyway **\** I don't disagree, dEBRUYNE **\** proving alternative viewpoints **\** although how long six months is in tech and blockchain relatively is much bigger **\** It's pretty moot at this point anyway **\** Until we hear about audits **\** Well, I think that "blockchain relative time" has slowed considerably lately **\** true. So maybe move on. **\** It's a moo point. Like a cow's opinion **\** rbrunner: not with fireice and ryo nipping at our heels. **\** Doesn't matter **\** Lol **\** Pretty soon we'll be doing coordinated, organized attacks out of fear **\** alright, moving on **\** 3. Code/Ticket discussion **\** I have used the Go RPC bindings: https://github.com/monero-ecosystem/go-monero-rpc-client **\** My 2 PR's to improve on that were just merged today. **\** Can confirm that the bloody thing works. **\** rbrunner: Have you spent any work (or chatted with the team about it) on OB lately? **\** Yes, and the ball is definitely in their court now: https://github.com/OpenBazaar/openbazaar-go/issues/1638 **\** That sounds like a lot of nice work there. **\** much applause! **\** Is that something Revuo worthy, you think? **\** Go RPC stuffs? **\** Ah, hmmm, maybe not yet the OpenBazaar stuff, quite early yet. **\** RPC is of course ok to mention, maybe other people will use it **\** Alright, if there's nothing else we can move on **\** Nice work rbrunner **\** Thanks! **\** I'm assuming in "Old Business" we don't need to continue discussion on Payment IDs? **\** very nice rbrunner **\** Only if there are new arguments. **\** going once **\** going twicee **\** rbrunner: "and no support for moderation" \<= Is that even feasible at this point? **\** hearing none, I think we can move on from PIDs **\** Doubtful, unfortunately. **\** Ok, any other meeting items? **\** Just as kind of announcement. People going to Vegas for Defcon, some of us are going a couple days early (starting monday the 5th) to hang out and chill. All are invited and welcome. **\** rbrunner: I guess they could apply a similar process as bisq for moderation **\ \** I'm assuming in "Old Business" we don't need to continue discussion on Payment IDs? \<= I think the rough consensus was that we should start with a full software removal first **\** (please correct me if I am wrong) **\** Don't remember exactly, isn't Bisq multisig-based as well? **\** Partly (for the BTC part) **\** dEBRUYNE: every core team member that spoke up (in the issue) was very against that. Smooth, ArticMine, binaryFate **\** I'll keep the parsing code with an opt-in flag in monerod I think. **\** to hang out and chill \<- is that even allowed for Monero people? **\** rehrar: No? **\** ohhhh wait **\** never mind, I'm speaking of PID removal in general **\** not long **\** They were against parsing tx\_extra / temporary ban **\** I got confused cuz you said "software removal 'first' " **\** and thought you were hinting at the reversal later **\** my bad **\** Hmm no **\** As far as I know, no one was against a full software removal **\** cool **\** There were people opposed against (i) temporary banning the tx\_extra field, (ii) permanently banning the tx\_extra field, (iii) parsing the tx\_extra field to disallow long payment IDs **\** then we gucci **\** Define "full software removal" for clarity, plz? **\** As in, no GUI option to add one for outgoing? **\** as I understand, Isthmus says he has some very interesting research going on about "treasures" found in th tx\_extra field **\** I'd like to see that research when it happens, and we can discuss the pros and cons afterwards **\** Huh? Really? **\** In fact, I already made that code. I have shitloads of stuff that's not being PRed just because it conflicts due to merging being stalled now **\** That does not sound too good ... **\** moneromooo: Do you have a list for luigi that he can merge? **\** Yes. **\** Could you post it here too? **\** Sure. One moment... **\** sarang: removal from both CLI and GUI **\** With no option to enable via flags? **\** 5647/5666, 5650/5651, 5663/5664, 5668/5669, 5675/5676, 5678/5684 (there's more) **\** That was my idea kind of **\** and 5690/5694, 5681/5708. **\** Note that this could cause some exchanges/services to recommend specific wallets (that do continue to support) to their users **\** which could be good or bad, depending on the wallets **\** That's a potential risk, yes **\** I deem it more likely that they will simply switch though **\** I could keep the --enable-paymend-id-bad-for-privacy, and instead of enabling them, it prints "lolno". **\** moneromooo: Will send luigi the list in PM as a reminder **\** Oh I did **\** dEBRUYNE sarang this is all one big experiment. I'd say let's try it this way and see how the exchanges react **\** I just don;t want to annoy him too much. **\** if they don't do as we hope, then we learn from that next time we have to make a decision like this **\** but this is all hypothetical at this time. Let's see what happens. **\** I really doubt that the exchanges have time on their hands to work against the community, but who knows **\** well, we do have LiveCoin **\** If they recommend other wallets, I won't have any regret in breaking those in next fork ^\_^ **\** either way **\** 4. Any last meeting items? **\** 5707 speeds up MLSAG, and will be sped up a bit more **\** Does anyoine want to review share-rpc ? Or did I mention that already... **\** review will be welcome **\** rehrar: Should we perhaps discuss v0.14.1.1? **\ \** dEBRUYNE sarang this is all one big experiment. I'd say let's try it this way and see how the exchanges react \<= Yes **\** To be fair, it is mostly the big ones that are remaining that we need to get on board **\** moneromooo: I'll put it in the REvuo volunteer opportunities (for all the good that will do) **\** AFAIK it's waiting for a freebsd patch from TheCharlatan. **\** Bittrex, Bitfinex, and Binance **\** moneromooo: can you PM me a link to it **\** moneromooo: I will look at it this week **\** https://github.com/monero-project/monero/pull/5357 **\** Thanks **\** thank you **\** dEBRUYNE: what do you want to discuss regarding 0.14.1.1? **\** the floor is yours **\** Timeline kind of, what do the devs prefer? **\** We can move a bit faster now that we have deterministic builds **\** As soon as the bsd patch is in. **\** (and the patches above) **\** I may be getting confused because of the numbers, but didn't pony do builds already? **\** or this is new? what's going into it? **\** The BSD patch and the patch list above. **\** ah, k **\** moneromooo: All right. Does this need a release v0.14 equivalent? https://github.com/monero-project/monero/pull/5705 **\** rehrar: new release **\** I dunno, ask TheCharlatan about this one. **\** All right **\** ok, anything else to discuss about this release? **\** The GUI I suppose ^\_^ **\** by all means, moneromooo. Take it away. **\** I don't have anything to say about it. **\** GUI will follow CLI for v0.14.1.1 **\** First have to wait for pony to finish the v0.14.1.0 builds though **\** There are missing builds for .0 ? I didn't even realize... **\** pony is traveling again **\** he does that **\** Yes **\** Also we kind of had to retag, which has delayed the release a bit **\** Gonna run out of places to go soon. **\** he's running from the community methinks. **\** Me? Lol I'm in a car on lte so I dropped service once and hit leave once stupidly **\** rehrar: He provided an update yesterday **\** Anyway, vtnerd\_\_ I wanted to ask you if you had already started some work on dandelion++ ? **\** dEBRUYNE: link? **\** https://www.reddit.com/r/Monero/comments/c6y542/any\_news\_on\_the\_gui\_release/esc02my/ **\** alright, if there's nothign else, I think we can call it here. **\** discussion can obviously continue after the fact **\** I started to look into it. At this point my ffs pt 2 is hopefully going to make that transition easier (but it won't be a complete d++ implementation) **\** Two weeks from now is the 14th of July. Same time.