--- layout: post title: Overview and Logs for the Dev Meeting Held on 2019-06-16 summary: Development status, Code & ticket discussion, payment ID, CLSAG, and miscellaneous tags: [dev diaries, core, crypto] author: el00ruobuob / rehrar --- # Logs **\<rehrar>** Meeting time! Who all is here? **\<rbrunner>** Hi all **\<hyc>** hey **\<fullmetalScience>** Hi **\<dEBRUYNE>** Here **\<rehrar>** 2. Brief review of what's been completed since the previous meeting **\<hyc>** v0.14.1.0 is out in the world **\<rbrunner>** CLI so far, yes ... **\<rehrar>** so I hear. And I even hear deterministic builds are doing their thing ok **\<jtgrassie>** hi **\<hyc>** they are being deterministic now, yes **\<dEBRUYNE>** Some small improvements still for deterministic builds, but I'd argue it was a excellent first round :P **\<rehrar>** nothing left to be done on the CLI front then for this little release? **\<rehrar>** but then also, looking to the next release, what's going on, do we know? **\<rehrar>** for 0.15 **\<rbrunner>** little release is actually a pretty big release **\<rbrunner>** feature-wise **\<hyc>** there may be a few small bug reports for v0.14.1. might want a v0.14.1.1 **\<dEBRUYNE>** I think the intention was to release it way earlier this time, because we can already add all the consensus changes early on **\<dEBRUYNE>** Unless CLSAG is also going to go in I guess **\<moneromooo>** It'll depend on whether it gets a review I think. **\<hyc>** Is 0.15 the October release? **\<moneromooo>** (in time) **\<rehrar>** sarang suraeNoether, can you speak to the potential timeline of review for CLSAG? **\<dEBRUYNE>** hyc: Yeah **\<rehrar>** dsc\_ selsta dEBRUYNE anything from GUI? **\<dEBRUYNE>** hyc: So we have about four months left I guess **\<dEBRUYNE>** GUI v0.14.1.0 has been tagged and fluffypony is working on the builds **\<hyc>** so when are we expecting to freeze 0.15 ? **\<dEBRUYNE>** rehrar: Some new stuff for the GUI: **\<dEBRUYNE>** - White theme **\<dEBRUYNE>** - Addressbook redesign **\<dEBRUYNE>** - History redesign **\<dEBRUYNE>** - Trezor and Ledger Nano X support **\<dEBRUYNE>** - Fiat price conversion **\<dEBRUYNE>** - macOS fullscreen support **\<dEBRUYNE>** Also an update checker + Hindi translation **\<dEBRUYNE>** And xiphon did a lot of work on improving the communication between the (integrated) daemon and the GUI **\<rehrar>** oooooh. Looks juicy. thanks dEBRUYNE **\<rehrar>** so it'll be faster? **\<dEBRUYNE>** hyc: I guess that is going to depend on whether we want to add CLSAG. If not, we could do a first 0.15 release after RandomX has been merged (e.g. in August) **\<dEBRUYNE>** And then another point release a month before the fork **\<dEBRUYNE>** rehrar: Yes and less 'laggy' **\<moneromooo>** Does someone want to review the share-rpc (pay for RPC service) branch ? :) **\<moneromooo>** It goes well with a CPU friendly PoW... **\<hyc>** I may take a look after I get back from konferenco **\<rehrar>** I assume we don't have any core team here? **\<moneromooo>** \\o/ **\<rehrar>** but if not, we can still kind of talk about Payment ID stuff **\<dEBRUYNE>** Btw moneromooo, you already coded up a rough implementation of CLSAG right? **\<rehrar>** which is number 4. **\<moneromooo>** Yes. **\<moneromooo>** Well, sarang did, and I plugged it in. **\<dEBRUYNE>** rehrar: That's kind of my fault, I forgot to ping them in advance (I did earlier today, but probably too late :/) **\<dEBRUYNE>** Anyway, we can still discuss it, as there is plenty of opinions on the meta ticket **\<hyc>** rough? is it something you'd deploy for real, and what we'd submit to auditors to review? **\<moneromooo>** Both, assuming the review passes. **\<hyc>** ok **\<dEBRUYNE>** hyc: With 'rough' I kind of meant that, as far as I could see, it wasn't fully finished yet **\<moneromooo>** If you have suggestions for changes, go for it. **\<dEBRUYNE>** moneromooo: I just thought it wasn't fully finished yet, if it is I stand corrected :-P **\<moneromooo>** Well, I don't know what you've seen before, but AFAIK it is finished now, unless comments. **\<rehrar>** alright, let's discuss the whole PID thing then, if we can, with the people represented here giving their opinions as well. **\<dEBRUYNE>** I see, thanks for clarifying **\<rehrar>** dEBRUYNE: is correct that actually many of core had made their opinions known on the meta discussion **\<rehrar>** can you link that real fast dEBRUYNE ? **\<moneromooo>** Did any exchange/merchant switch from long payment ids since... half a year ago, say ? **\<dEBRUYNE>** I think some smaller ones did, but the big ones (Bittrex, Bitfinex, Binance) did not **\<dEBRUYNE>** rehrar: sure **\<dEBRUYNE>** smooth: https://github.com/monero-project/meta/issues/356#issuecomment-500187077 & https://github.com/monero-project/meta/issues/356#issuecomment-501168062 **\<dEBRUYNE>** binaryFate: https://github.com/monero-project/meta/issues/356#issuecomment-499968785 **\<rehrar>** at the end of the thread in particular, ArticMine brings up his revised opinion about potentially looking at removing tx\_extra **\<dEBRUYNE>** ArticMine: https://github.com/monero-project/meta/issues/356#issuecomment-501347185 **\<ErCiccione[m]>** some big ones like kraken already use subadresses moneromooo, iirc somebody as a list of the status of some exhanges and services **\<dEBRUYNE>** https://github.com/monero-project/meta/issues/356#issuecomment-499936642 & https://github.com/monero-project/meta/issues/356#issuecomment-499948904 **\<rbrunner>** Yeah, but it would be interesting to see whether somebody \*switched\* **\<ErCiccione[m]>** maybe sgp\_? **\<dEBRUYNE>** rehrar: As far as I can see, people don't like temporary banning payment IDs by parsing tx\_extra **\<dEBRUYNE>** As it is essentially a slippery slope **\<dEBRUYNE>** So that leaves us with (i) Phase them out by removing all support from the official software or (ii) banning the tx\_extra field entirely **\<rehrar>** dEBRUYNE: agreed. I see that reflected as well. **\<rehrar>** yes ^ **\<sgp\_>** I had a list in January, not sure if it is up-to-date anymore **\<rehrar>** can I ask people to give opinions on the above two options presented by dEBRUYNE? **\<dEBRUYNE>** rbrunner: The announcement has only been up for 10 days though **\<rehrar>** I particularly want to hear arguments for or against removing tx\_extra **\<rbrunner>** dEBRUYNE: Yes, saw it, but we make noises a lot longer :) **\<sgp\_>** rehrar: I have personally head some arguments against removing tx\_extra from legacy financial services **\<dEBRUYNE>** The arguments for are, for example, (i) a clean and definitive way to phase out long payment IDs and (ii) improves fungibility **\<sgp\_>** Zcash has an encrypted memo field that they use to claim support for many traditional remittance services **\<rehrar>** dEBRUYNE: I think (ii) is kind of massive, given that's our shtick **\<dEBRUYNE>** moneromooo: I vaguely remember you working on some kind of encrypted memo field too, is that correct? **\<sgp\_>** ftr I only support parsing for current payment ID behavior to force services to switch. I am not for the removal of tx\_extra in its entirety **\<dsc\_>** \< rehrar> dsc\_ selsta dEBRUYNE anything from GUI? \<== Past 4 days been working on development related tooling to support QML development, this is unrelated to my CCS **\<moneromooo>** I have a partial patch for this somewhere. I stopped because it's a bit chicken and egg since you need tx tx key to decrypt the rest and I was not sure what to do yet. **\<rbrunner>** Likewise. Erasing tx\_extra completey is going overboard somehow for me **\<rehrar>** sgp\_ rbrunner are there any other reasons for keeping it around? **\<sgp\_>** rehrar: mostly flexibility **\<dEBRUYNE>** sgp\_: How is that field used exactly in that context? **\<rehrar>** and is there a good reason why something like it can't be kept track of externally via third party, and why it needs to be on the base currency? **\<rbrunner>** Up to a point, it should be possible for the users of the currency to do like they want ... to a certain degree, with a single field **\<sgp\_>** See "what people will do with this" https://electriccoin.co/blog/encrypted-memo-field/ **\<dEBRUYNE>** On the other hand, do we want to give people the ability to potentially hurt privacy of other participants on the network? **\<rbrunner>** And who knows, maybe one day we will have some emergency and want to put something in there ourselves. A currency with exactly zero flexibility ... I don't know **\<sgp\_>** When I was doing payment ID research back in January, someone specifically asked that tx\_extra remained for this flexibility **\<rehrar>** let me look at the dollar. Does the dollar have this field? **\<rbrunner>** Marking one's own txs is quite a small privacy risks for others, if you ask me **\<rehrar>** or are memos and stuff kept and integrated in dollar management software? **\<rbrunner>** Yes, bank transfers have something like a short memo, right? **\<sgp\_>** rehrar: I'm not an expert here, I'm just relaying some information to say the flexibility could be useful **\<rehrar>** rbrunner: sure, but that isn't built into the dollar bill itself **\<rehrar>** which is my point **\<rehrar>** is this necessary as a part of Monero itself? Or can monero management software be built to have these memos? **\<rehrar>** My initial thoughts are the latter **\<rbrunner>** Hmm, I think that comparison limps a little .. **\<sgp\_>** my personal opinion is that the flexibility shouldn't be removed unless there's a problem, and we should try to address that more head-on. If we already tried to kill payment IDs and they used a different format in tx\_extra, that would be one thing. But we're in a situation now where we are trying it for the first time and I think a simple parsing would be successful at making people switch over **\<rbrunner>** Uh, no, several incompatible memo transfer systems will crop up for sure **\<rbrunner>** Why not fill \*every\* tx\_extra with fake data, if that's such a problem? **\<rehrar>** hyc, dEBRUYNE, moneromooo? care to chime in at all? **\<moneromooo>** Not really. **\<sgp\_>** rbrunner: that's basically what zcash does with the encrypted memo field **\<moneromooo>** We've gone over that enough for me. **\<rbrunner>** Yes, and we now with the short payment ids, right? **\<hyc>** as a protocol guy I tend to favor having extensiblity **\<hyc>** there's certainly a risk of dumping tons of spam into the chain with a totally open-ended extention field **\<hyc>** might want to constrain it to "any individual tx\_extra can't be greater than N bytes" etc **\<moneromooo>** That could be made to weigh extra for the fee fwiw. **\<hyc>** N=512, 1024, dunno **\<rehrar>** isn't that what minergate does when they find a block or is that somethign different? **\<rehrar>** I recall somebody saying they add a bunch of weird data **\<moneromooo>** They did. **\<dEBRUYNE>** sgp\_: Lots of people are opposed to parsing though, I don't think that is going to find consensus **\<rehrar>** alright well, anything else to say on this topic? **\<rehrar>** we can continue in the issue **\<dEBRUYNE>** rehrar: In general I am kind of ambivalent, I think we can achieve a lot by removing all functionality from the software **\<sgp\_>** dEBRUYNE: I understand, I just personally think there is some middle ground that doesn't need to include full tx\_extra. I think we've exhausted this topic for now **\<dEBRUYNE>** Currently, we removed it, but it is easily to reenable **\<sgp\_>** \*full tx\_extra removal **\<luigi1111>** instead of command line, move to compile time **\<dEBRUYNE>** Next step could be that they need to add code theirselves for payment ID support **\<hyc>** VARIANT\_TAG(binary\_archive, cryptonote::tx\_extra\_merge\_mining\_tag, TX\_EXTRA\_MERGE\_MINING\_TAG); **\<rbrunner>** But the code would be missing at the people's systems, where the exchanges could not get it in again **\<hyc>** if tx\_extra is needed to support merge mining then removing it is kinda out of the question, no? **\<dEBRUYNE>** rbrunner: Yes, that as well **\<dEBRUYNE>** But there may be some third party wallets that retain support **\<rbrunner>** As long as they don't threaten to fork and come up with MoneroLPID (long payment id variant) ... **\<rehrar>** alright, let's go ahead and move along **\<rehrar>** there is also discussion blocked out for this meeting **\<rehrar>** but we talked about it a bit, and I don't see any MRL people here **\<hyc>** seems like there are a lot of current valid uses for tx\_extra, so you can't remove it outright **\<rehrar>** still want to discuss, or table? **\<hyc>** CLSAG can wait for next meeting I think **\<rehrar>** ok **\<rehrar>** any additional items? **\<hyc>** surae is busy taking care of konferenco now anyway **\<rehrar>** code/ticket discussion? **\<moneromooo>** Anyone else than hyc wants to review share-rpc ? :) **\<moneromooo>** Or even use it as backend to add pay-for-downloading-torrents or whatever. **\<rehrar>** I lack the skills :) **\<rehrar>** \*:( **\<rehrar>** alright everyone, I think we can call it here **\<rehrar>** two weeks from now? **\<rehrar>** thanks for coming! have a good couple weeks.