Monero Dev Meeting Note Highlights – 2019-08-11
Logs
351 lines
dEBRUYNEso dev meeting? :P
jtgrassiehi!
dEBRUYNEWho's here? hyc, vtnerd, sarang, suraeNoether, moneromooo, jtgrassie, luigi1111, fluffypony
rbrunnerCertainly!
dEBRUYNEProbably forgetting a lot of people
dEBRUYNEGuess it's vacation time for a lot of people :-P
Guest16177here more or less
dEBRUYNESo what should we discuss?
kinghato/
jtgrassietestnet->rx ?
jtgrassieas in when can we fork testnet to RandomX
rbrunnerMaybe that would be good with moneromooo back from "frolocking amoung cows" or so
sarangHere, live from def con
rbrunnerDef con party then? :)
sarangVery good attendance at the def con village this weekend, for sure
kinghateven being off the beaten path?
rbrunnerAnyway, concerning RandomX: The reviews are all through, right?
sarangYes, for sure
sarangHaving free badges was a huge help
vtnerd__… present (too busy too lock at clock) …
dEBRUYNEI think what is left is to merge the RandomX PR from hyc and set a testnet fork date
hychey sorry, was afk. but yes
rbrunnerYes, nice to see all those "fixed" and "solved"
dEBRUYNEAs a side note, thoughts on releasing 0.15 binaries in early september already?
dEBRUYNEOr would that be too short
hycwould probably need mooo's opinion there
hycwhat's our outstanding PR count look like anyway?
dEBRUYNEI am thinking that we have freedom to release early as we do not have any last minute consensus changes
dEBRUYNEQuite a lot, but I am working with luigi to get the queue down :P
dEBRUYNEluigi & mooo*
hyccool
hyca mid-Sept release date sounds plausible. basically 1 month from now?
dEBRUYNESounds like a decent target
dEBRUYNEIt also gives services, users etc. a larger time frame to prepare
dEBRUYNEThe forks with binaries 1 week in advance were admittedly quite hectic :-P
hycso we would expect testnet to switch to randomx on that mid-Sept date
hycon or around…
jtgrassieit would be nice to have testnet fork a little earlier to randomx imo
sarangThere was some issue with another project's switch to RandomX, right?
sarangWas that an issue with a miner implementation?
hycLoki. xmrig bug
hycthere are no issues with the monerod integration
dEBRUYNEWhat was the effect of the bug?
dEBRUYNE(in the miner that is)
hycjtgrassie: so, switch over testnet earlier, but on self-compiled binaries maybe?
hycdEBRUYNE: the miner didn't reinitialize the dataset when seed epoch changed
jtgrassieyes
hycall blocks mined after that point were invalid, rejected by daemons
hycrestarting the miner would get it working until the next epoch
hycbut it was patched pretty quickly
dEBRUYNEAh I see, so part of the network hashrate basically disappeared because they were mining invalid blocks
hycyes
rbrunnerSo will those mid-September binaries now be the ones that do not support *long* payment id's anymore? I lost a little the overview
hycno idea, haven't followed payment ID discussion
dEBRUYNEneedmonero90: did Binance provide you with a timeline?
needmonero90https://usercontent.irccloud-cdn.com/file/IA4ai9LF/Screenshot_20190811-102559_Telegram.jpg
needmonero90https://usercontent.irccloud-cdn.com/file/eo22z2BE/Screenshot_20190811-102608_Telegram.jpg
needmonero90https://usercontent.irccloud-cdn.com/file/YcXsymNo/Screenshot_20190811-102612_Telegram.jpg
needmonero90There was the latest.
needmonero90I can upload the full convo to pastebin if you want it
sarangneat
rbrunnerYeah, sounds good
tatmoneromooo: are there any infos on which exchanges would be able to receive/send to subaddresses after the mid September fork?
tatsorry i meant needmonero90
dEBRUYNEAnyone got contacts at bittrex or bitfinex? I tried reaching out to them on reddit, but did not get a response
needmonero90Bittrex can be contacted over their slack iirc
needmonero90At least a year and a half ago that was the case.
rbrunnerWell, they also could contact *us*, at least in theory :)
tatwould be good to create a list, i guess some exchanges will be concerned if removing the ability to use payment ids cribles them to get transactions from other exchanges
needmonero90Tat: I just took up the discussion with binance because someone had to do it, I don't have the list of other exchanges.
tatneedmonero90: thx
needmonero90I will happily talk to whoever if we get a contact
needmonero90Just ping me their details
bibbleKraken important
needmonero90Kraken will be fine
bibbleoh, great :)
needmonero90Least of our concerns on the exchange front
tati think if at least 3-5 big exchanges would move to subaddresses, that would put some pressure on the rest and they probably follow within a reasonable timeframe
rbrunnerWell, "reasonable timeframe" is almost over, with hardfork in mid-October, wouldn't you say?
rbrunnerMaybe they are pretty quiet because they don't want let people look into their cards …
tatrbrunner: we are talking of not using long payment id's anymore, integrated addresses would still work i guess, so most of the exchanges will still be able to work with that as is
rbrunnerAh, ok, right, misunderstood you
dEBRUYNEThe most important thing is to get them off long payment IDs imo
rbrunnerCertainly, if we don't support them anymore in 2 months
hycso these exchanges aren't supporting integrated addrs yet?
tathyc: it depends, i think poloniex uses integrated addresses, bitfinex uses 64 char payent id's
hycyes, polo uses integrated
tatdEBRUYNE: do you think receiving of transactions with long payment id's will be still supported by the wallet
rbrunnerWho would send those, and how?
tati mean in theory you need to be able to resync, so to prevent that, the wallet would have to ignore all long payment id's from block height X
rbrunnerYes, the code is full of such switches "Starting from height x stop to do X and start do to Y"
rbrunnerDaily business, so to say
tatrbrunner: is there really only one source for code of the monero wallet, is there any wallet implementation that isn't using monero c++ wallet core?
rbrunnerI would guess that starting with the fork height the long payment just does not get decoded / delivered to the wallet anymore
rbrunnertat: Not sure about MyMonero's code
moneromoooI'm happy with testnet switching to randomx as soon as a patch is made fwiw.
rbrunnerOtherwise I think it's pretty much a monoculture
moneromoooPony's the one to get on board since seed nodes and his mining node will need to be updated then.
tati mean if there is any wallet that will still send with long payment id's, it wont be too bad, since funds will still arrive but if you rely on that id to track incoming setlements you are screwed
moneromoooThe wallet will ignore the payment id IIRC. It'll still get the money of course.
dEBRUYNEhyc: The big ones are binance, bittrex, bitfinex
dEBRUYNEneedmonero90 is currently working with binance, I will try to get ahold of the other two somehow
hycmoneromooo: all that's needed before merging the existing randomX integration patch, then, is setting the block height for the testnet fork
moneromoooIIRC I put a command line switch somehwere to enable something there.
moneromooo(about payment id decoding)
tati would say if an exchange is still using long payment id's and he switches within one month, and he is not able to process long payment id's anymore he will have two years of still receiving to those long payment'id since not all users get that change immediately
hycthey should've switched to integrated addrs 2 years ago …
tati think a command line switch would be pretty fair, with the emphasis on this feature will be deprecated, that would send the right signal
rbrunnerWhat do you mean with "not all users get that change immediately"? Your software will stop to work after the hardfork, no?
hycand it's their own obligation to notify their users if deposit addresses change
rbrunnerMaybe I misunderstand, but this is not Bitcoin where the move to SegWit takes 5 years or so …
moneromoooThe wallet has been warning it's deprecated for a while.
tathyc: so you are full positive that sending out with long payment ids will be impossible after the next hard fork
moneromoooIt will likely be still possible.
jtgrassiefwiw, we have been stating long payment ids are deprcated for ages now. they are a problem for privacy and IMO removed asap.
moneromoooBut if several large exchanges still use long payment ids close to the fork, I might be convinced to consensus ban them.
rbrunner"Close to the fork" … being … about today :)
moneromoooOh.
needmonero90To elaborate, using them has required going to advanced settings and toggling a box saying "don't do this" before you could send for ages.
moneromoooIs there fork soon ? I missed the talk.
hycmid-OCtober presumably
moneromoooWe're liky july, no ?
rbrunnerNo, I mean, as far as big projects are concerned, 2 months pass in a blink of an eye
moneromoooAugust. Close enough.
moneromoooOK, true.
needmonero90I did give binance until October, so it would be nice not to go faster than that
moneromoooSo "binance, bittrex, bitfinex" sounds like a lot indeed.
needmonero90Or I'll have to backpedal and apologize and politick
tati totally support that point, but for the poor souls that use still long payment ids and continue to receive payments, after the fork with long payment ids, since some users/exchanges will still do so it will be case for customer suport every single time
rbrunner"Possible" does not mean "easy to do". Maybe would need your own doctored self-compiled software
jtgrassieexchanges and users won't ever stop using payment ids while they are still possible.
rbrunnerWhich would work because *consensus* would still allow the long id's
vtnerd__to the above: mymonero is indeed not using the monero core wallet - it simply cannot actually
vtnerd__the light wallet server and openmonero implementations are using parts but not the whole as well for the same reason
vtnerd__but the payment id stuff is client side which has already moved away from long ids
tati think making it impossible to send long payment ids, but have a switch that still allows to decode them would be a good move, possible fading that switch out over time
endogenicyeah our pure fns for long payment ids were actually deleted in mymonero core iirc
endogenicfwiw monero core can adopt that code
rbrunnerI think long payment id's still floating around after the work is much less probable than some poor exchange not being able to receive payments at all
rbrunners/work/fork
tatrbrunner: could be true, there is only a few wallets, if they all disallow that, and there is no hand woven code that push transactions to the network
hycwe have certainly seen oddball txns on the network before, which probably came from custom wallet code
hycbut I don't see that as our problem to manage
jtgrassieexcept it potentially weakens other users privacy
jtgrassie(e.g. if those odd tx outputs get used as decoys)
jtgrassiewhich is why i favor banning long payent ids at protocol level
hycI'm a bit reluctant to do that since we still are keeping extradata itself
dEBRUYNEBanning in october seems a bit optimistic imo
hycbut if the official wallets have already disabled generating them by default, seems OK to me
rbrunnerYou do mean the long payment id's? Well, backing down now could set a bad precedent
moneromoooFWIW, to see what I've done: https://github.com/moneromooo-monero/bitmonero/commits/crash
hycyes
moneromoooI don't remember exactly so can't give a tl;dr :)
moneromooo(grep for "payment" in the commit title)
hycthis? https://github.com/moneromooo-monero/bitmonero/commit/0951c3a9ad0c8376b8abd8908603166d7ffc174d
jtgrassiethat one looks good to me
moneromoooYes. There's at least another one a few commits earlier.
hycI also see ignoring receivedo nes https://github.com/moneromooo-monero/bitmonero/commit/6aad370708c0c06c1091912fcc97dceaa09d5b75
rbrunnerSo standalone *short* id's are gone also, at least over RPC, if I read that code correctly.
rbrunnerOnly integrated over RPC
hycyeah that all looks good to me
moneromoooYes. They were never supposed to be supported. I added them because I'm an idiot. luigi was right.
rbrunnerNow we just wait what bittrex, bitfinex say :)
rbrunnerI still count on them not being stupid, just not noisy - working on it for quite some time already
hycback to randomx - any suggestions for testnet fork date? 1 week from today? sooner? later?
moneromoooWhenever pony can be certain to have his nodes updated.
moneromoooSo… mid november ?
hycsigh…
rbrunner2 weeks, for the next meeting?
moneromoooOh. I did have some minor stuff I wanted to add for v12.
Sources and notes
- Meeting log: Overview and Logs for the Dev Meeting Held on 2019-08-11, 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.