Monero Dev Meeting Note Highlights – 2019-06-16
Logs
351 lines
rehrarMeeting time! Who all is here?
rbrunnerHi all
hychey
fullmetalScienceHi
dEBRUYNEHere
rehrar2. Brief review of what's been completed since the previous meeting
hycv0.14.1.0 is out in the world
rbrunnerCLI so far, yes …
rehrarso I hear. And I even hear deterministic builds are doing their thing ok
jtgrassiehi
hycthey are being deterministic now, yes
dEBRUYNESome small improvements still for deterministic builds, but I'd argue it was a excellent first round :P
rehrarnothing left to be done on the CLI front then for this little release?
rehrarbut then also, looking to the next release, what's going on, do we know?
rehrarfor 0.15
rbrunnerlittle release is actually a pretty big release
rbrunnerfeature-wise
hycthere may be a few small bug reports for v0.14.1. might want a v0.14.1.1
dEBRUYNEI think the intention was to release it way earlier this time, because we can already add all the consensus changes early on
dEBRUYNEUnless CLSAG is also going to go in I guess
moneromoooIt'll depend on whether it gets a review I think.
hycIs 0.15 the October release?
moneromooo(in time)
rehrarsarang suraeNoether, can you speak to the potential timeline of review for CLSAG?
dEBRUYNEhyc: Yeah
rehrardsc_ selsta dEBRUYNE anything from GUI?
dEBRUYNEhyc: So we have about four months left I guess
dEBRUYNEGUI v0.14.1.0 has been tagged and fluffypony is working on the builds
hycso when are we expecting to freeze 0.15 ?
dEBRUYNErehrar: 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
dEBRUYNEAlso an update checker + Hindi translation
dEBRUYNEAnd xiphon did a lot of work on improving the communication between the (integrated) daemon and the GUI
rehraroooooh. Looks juicy. thanks dEBRUYNE
rehrarso it'll be faster?
dEBRUYNEhyc: 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)
dEBRUYNEAnd then another point release a month before the fork
dEBRUYNErehrar: Yes and less 'laggy'
moneromoooDoes someone want to review the share-rpc (pay for RPC service) branch ? :)
moneromoooIt goes well with a CPU friendly PoW…
hycI may take a look after I get back from konferenco
rehrarI assume we don't have any core team here?
moneromooo\o/
rehrarbut if not, we can still kind of talk about Payment ID stuff
dEBRUYNEBtw moneromooo, you already coded up a rough implementation of CLSAG right?
rehrarwhich is number 4.
moneromoooYes.
moneromoooWell, sarang did, and I plugged it in.
dEBRUYNErehrar: That's kind of my fault, I forgot to ping them in advance (I did earlier today, but probably too late :/)
dEBRUYNEAnyway, we can still discuss it, as there is plenty of opinions on the meta ticket
hycrough? is it something you'd deploy for real, and what we'd submit to auditors to review?
moneromoooBoth, assuming the review passes.
hycok
dEBRUYNEhyc: With 'rough' I kind of meant that, as far as I could see, it wasn't fully finished yet
moneromoooIf you have suggestions for changes, go for it.
dEBRUYNEmoneromooo: I just thought it wasn't fully finished yet, if it is I stand corrected :-P
moneromoooWell, I don't know what you've seen before, but AFAIK it is finished now, unless comments.
rehraralright, let's discuss the whole PID thing then, if we can, with the people represented here giving their opinions as well.
dEBRUYNEI see, thanks for clarifying
rehrardEBRUYNE: is correct that actually many of core had made their opinions known on the meta discussion
rehrarcan you link that real fast dEBRUYNE ?
moneromoooDid any exchange/merchant switch from long payment ids since… half a year ago, say ?
dEBRUYNEI think some smaller ones did, but the big ones (Bittrex, Bitfinex, Binance) did not
dEBRUYNErehrar: sure
dEBRUYNEsmooth: https://github.com/monero-project/meta/issues/356#issuecomment-500187077 & https://github.com/monero-project/meta/issues/356#issuecomment-501168062
dEBRUYNEbinaryFate: https://github.com/monero-project/meta/issues/356#issuecomment-499968785
rehrarat the end of the thread in particular, ArticMine brings up his revised opinion about potentially looking at removing tx_extra
dEBRUYNEArticMine: 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
dEBRUYNEhttps://github.com/monero-project/meta/issues/356#issuecomment-499936642 & https://github.com/monero-project/meta/issues/356#issuecomment-499948904
rbrunnerYeah, but it would be interesting to see whether somebody *switched*
ErCiccione[m]maybe sgp_?
dEBRUYNErehrar: As far as I can see, people don't like temporary banning payment IDs by parsing tx_extra
dEBRUYNEAs it is essentially a slippery slope
dEBRUYNESo that leaves us with (i) Phase them out by removing all support from the official software or (ii) banning the tx_extra field entirely
rehrardEBRUYNE: agreed. I see that reflected as well.
rehraryes ^
sgp_I had a list in January, not sure if it is up-to-date anymore
rehrarcan I ask people to give opinions on the above two options presented by dEBRUYNE?
dEBRUYNErbrunner: The announcement has only been up for 10 days though
rehrarI particularly want to hear arguments for or against removing tx_extra
rbrunnerdEBRUYNE: 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
dEBRUYNEThe 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
rehrardEBRUYNE: I think (ii) is kind of massive, given that's our shtick
dEBRUYNEmoneromooo: 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
moneromoooI 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.
rbrunnerLikewise. Erasing tx_extra completey is going overboard somehow for me
rehrarsgp_ rbrunner are there any other reasons for keeping it around?
sgp_rehrar: mostly flexibility
dEBRUYNEsgp_: How is that field used exactly in that context?
rehrarand 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?
rbrunnerUp 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/
dEBRUYNEOn the other hand, do we want to give people the ability to potentially hurt privacy of other participants on the network?
rbrunnerAnd 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
rehrarlet me look at the dollar. Does the dollar have this field?
rbrunnerMarking one's own txs is quite a small privacy risks for others, if you ask me
rehraror are memos and stuff kept and integrated in dollar management software?
rbrunnerYes, 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
rehrarrbrunner: sure, but that isn't built into the dollar bill itself
rehrarwhich is my point
rehraris this necessary as a part of Monero itself? Or can monero management software be built to have these memos?
rehrarMy initial thoughts are the latter
rbrunnerHmm, 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
rbrunnerUh, no, several incompatible memo transfer systems will crop up for sure
rbrunnerWhy not fill *every* tx_extra with fake data, if that's such a problem?
rehrarhyc, dEBRUYNE, moneromooo? care to chime in at all?
moneromoooNot really.
sgp_rbrunner: that's basically what zcash does with the encrypted memo field
moneromoooWe've gone over that enough for me.
rbrunnerYes, and we now with the short payment ids, right?
hycas a protocol guy I tend to favor having extensiblity
hycthere's certainly a risk of dumping tons of spam into the chain with a totally open-ended extention field
hycmight want to constrain it to "any individual tx_extra can't be greater than N bytes" etc
moneromoooThat could be made to weigh extra for the fee fwiw.
hycN=512, 1024, dunno
rehrarisn't that what minergate does when they find a block or is that somethign different?
rehrarI recall somebody saying they add a bunch of weird data
moneromoooThey did.
dEBRUYNEsgp_: Lots of people are opposed to parsing though, I don't think that is going to find consensus
rehraralright well, anything else to say on this topic?
rehrarwe can continue in the issue
dEBRUYNErehrar: 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
dEBRUYNECurrently, we removed it, but it is easily to reenable
sgp_*full tx_extra removal
luigi1111instead of command line, move to compile time
dEBRUYNENext step could be that they need to add code theirselves for payment ID support
hycVARIANT_TAG(binary_archive, cryptonote::tx_extra_merge_mining_tag, TX_EXTRA_MERGE_MINING_TAG);
rbrunnerBut the code would be missing at the people's systems, where the exchanges could not get it in again
hycif tx_extra is needed to support merge mining then removing it is kinda out of the question, no?
dEBRUYNErbrunner: Yes, that as well
dEBRUYNEBut there may be some third party wallets that retain support
rbrunnerAs long as they don't threaten to fork and come up with MoneroLPID (long payment id variant) …
rehraralright, let's go ahead and move along
rehrarthere is also discussion blocked out for this meeting
rehrarbut we talked about it a bit, and I don't see any MRL people here
hycseems like there are a lot of current valid uses for tx_extra, so you can't remove it outright
rehrarstill want to discuss, or table?
hycCLSAG can wait for next meeting I think
rehrarok
rehrarany additional items?
hycsurae is busy taking care of konferenco now anyway
rehrarcode/ticket discussion?
moneromoooAnyone else than hyc wants to review share-rpc ? :)
moneromoooOr even use it as backend to add pay-for-downloading-torrents or whatever.
rehrarI lack the skills :)
rehrar*:(
rehraralright everyone, I think we can call it here
rehrartwo weeks from now?
rehrarthanks for coming! have a good couple weeks.
Sources and notes
- Meeting log: Overview and Logs for the Dev Meeting Held on 2019-06-16, 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.