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.

13 KiB Raw Blame History

Logs

13 KiB

Raw Blame History