Overview and Logs for the Dev Meeting Held on 2019-06-16
Development status, Code & ticket discussion, payment ID, CLSAG, and miscellaneous
dev diaries
core
crypto
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.