Monero Dev Meeting Note Highlights – 2019-08-25
Logs
351 lines
rbrunnerMeeting time, but it seems Rehrar has problems getting through to here from Mattermost …
dEBRUYNErehrar can't join IRC directly?
rehrar-mobok, let's do this then
rbrunnerSo you all don't see him either, right?
rehrar-mobI'm on the move atm, unfortunately.
dEBRUYNENope
rbrunnerTechnology, pfft
rehrar-mobIn fact, I may be called away in about twenty minute's time.
rehrar-mobI can lead until then, but maybe dEBRUYNE or moneromooo can afterwards?
rehrar-mobnormal stuff today.
dEBRUYNESure
rehrar-mob1. Greetings, 2. What's done since last meeting? 3. Code/ticket discussion 4. Other meeting items 5. next meeting time
dEBRUYNEpings luigi1111 sarang fluffypony moneromooo vtnerd suraeNoether___ hyc jtgrassie selsta xiphon
rehrar-mob1. Greetings
rehrar-mobsay hi
vtnerd__hi
rbrunnerHi
rehrar-mobdsc_ medusa_ also
xiphonhi
TurtleCoin<VISSER THREE> hi
rehrar-mob2. What's been completed since last meeting?
sarangHi
rehrar-mobDid you guys have a meeting a couple weeks ago? I was at defcon, so didn't attend.
hychi
dEBRUYNEYes, there was a meeting two weeks ago
hycthere was a meeting 2 weeks ago, not much happened
rehrar-mobcool, so completed since then then
rehrar-mobbeen a slow past couple of weeks?
dEBRUYNEI've worked with luigi and mooo to get some stuff merged
dEBRUYNEWe're at about 60 open PRs now (quite a few of those are relatively new)
rehrar-mobon CLI? or between both CLI and GUI?
dEBRUYNECLI yes, but luigi also merged some stuff for the GUI
rehrar-mobany idea on what those things are? summary.
rehrar-mobvtnerd how's your stuff coming along? Everyone awaits with bated breath.
dEBRUYNEYou mean what kind of PRs were merged?
rehrar-mobdEBRUYNE yes. What'd they do.
rehrar-mobJust for anyone reading the logs.
dEBRUYNEAs far as I can see, mostly optmizations, bug fixes, readme additions
dEBRUYNEIPv6 support got merged
rehrar-mobCool deal.
dEBRUYNEAlso a few improvements to the deterministic build process
sarangI'd like additional review on a slightly older MLSAG PR: https://github.com/monero-project/monero/pull/5707
dEBRUYNEBunch of new tests got added too
sarang(recently updated)
dEBRUYNE^ Perhaps luigi1111 can have another look at that?
vtnerd__Im working on handling the mempool separation, which is a bit tough to separate the components cleanly
rbrunnerYou mean code separation?
vtnerd__the first PR for white noise appears to not be hated at least - I rebased and tested against the ipv6 merge
xiphonregarding the broken Travis builds - they were broken due to ncurses configuration, sent a PR that fixes the issue.
xiphonThough now some builds are halt on libunwind build error. Did we change anythign related to libunwind recently?
vtnerd__ideally dandelion++ and this covert sending technique have different mempools
vtnerd__but its determining how to handle it thats the tricky part - whether the txes are stored in the lmdb file like normally, kept only in memory, or separately altogether
vtnerd__its a very subtle leak of information if your tx is in the mempool stored on disk before appearing anywhere else, but this is monero so …
vtnerd__dandelion++ flat out suggests separate mempools because the information can be leaked externally through p2p or rpc calls
vtnerd__so for both dandelion++ and my CCS I proposed a separate mempool that didn't return the tx until it was "spread"
rehrar-mobyou don't foresee any of this being live in October, yeah?
rehrar-mobOr perhaps none of this necessitates a hard fork?
vtnerd__none of these needs a fork
vtnerd__*this
rehrar-mobaight, so it can go live whenever. Would any of this need to be audited, you think?
rehrar-mobor is it not that simple?
rehrar-mobI'm guessing that's the answer.
vtnerd__uh, its not the typical thing that gets audited, theres no cryptography involved really, but its wrong of me to push against it probably
hycvtnerd: explanation makes sense, thanks
rehrar-mobdEBRUYNE now I have to step away. I should be back in a while, but I don't expect the meeting to last that long. Can you take over?
dEBRUYNESure
rehrar-mobthanks
hycvtnerd but it sounds like this could just be a flag on records in the single txpool
vtnerd__yes, that is something that I thought about
hycand you only need to control disclosure when a remote client is asking
hycnot e.g. the local CLI
xiphon^ you still need to do this even with separate mempools
vtnerd__the only negative is that its recorded on disk to what is generally believed (or at least by me, perhaps not all) to not contain "sensitive" information. that flag would be recording that the tx origin was that machine
vtnerd__and its mixed with what is otherwise public information
hyc… no, that flag's meaning is not necessarily that.
vtnerd__it might be something I end up doing - since its less work - and document that it can be updated as needed
hycthe flag is "broadcasted yet" - it would be false on intermediate nodes in the dandelion stem too
vtnerd__yes
vtnerd__my only concern about mixing was the small data leak to disk and making sure it wasn't easy to accidentally undo.
vtnerd__I think its just going to use an existing flag or a new one, because its the easiest to get the bulk of the concern - the externally visible network traffic - up and running
hycusing a separate memory-only pool has the same dangers as why we switched to LMDB in the first place
hycit can grow to ubnounded size
hycand unless you use locked memory, it could just get swapped to disk anyway
vtnerd__yeah I had been considering a separate lmdb file for this. No code was written for that, but I was going through it in my head to track how much work it was
hycand if you use locked memory, you'll just run out
vtnerd__its not terrible, but cleaning up the tx inspection process should probably be done first
vtnerd__I was thinking of storing it to disk using lmdb, but letting the user specify a separate entry point for an encrypted volume, but its going to be too much work (as you are likely hinting at)
rbrunnerThis all is only relevant if you have a local attacker, right?
hycI would think so, yes
vtnerd__for the most part. I primarily wanted to do it because I still think its easier conceptually to have two separate pieces in code handling this, but its not trivial
hycand a local attacker that can examine the disk can probably also examine monerod's memory
rbrunnerYes, and if your starting point is "no dandelion++ whatsoever", maybe implement that quick and worry about local attackers afterwards
vtnerd__if the person is storing the blockchain to an unencrypted portion thinking its all public information
vtnerd__arguably everyone is running monerod on a machine using disk encryption, but perhaps not always
xiphonalso storing txes in lmdb will help in case of casedandelion++ stem phase fail
xiphonone could safely restart the daemon and don't bother that any outgoing tx will be lost
vtnerd__theres also a small concern about getting information remotely via timing, but thats another advanced attack that I was merely going to document rather than code around (it aint easy)
rbrunnerGood argument
vtnerd__and Im not even sure how realistic that timing attack is, its going to vary from machine to machine a lot
vtnerd__xiphon: thats probably pointless
hycfwiw, a patch for page-level encryption in LMDB is available, works fine. I haven't released it yet because I wanted to add authenticated encryption
vtnerd__because the embargo is almost certainly going to fire, and everyone in the chain is broadcasting at that point
hycwhich requires eating up extra space for the encryption signature
hycbut we could go with the current patch immediatelym if it helps
xiphondvtnerd__: oens't seem so to me
xiphonif you restart the daemon right after sending a tx and choosen stem node fails, you tx will be lost
vtnerd__its no worse than the current code, so I don't see a reason to rush
xiphonand that won't happen with lmdb-stored txes
vtnerd__and likely the timer from the origin node goes off by then anyway, its probably close
vtnerd__although we could have it retry on connection loss to a backup node before doing the embargo timer thing
vtnerd__with dandelion++ theres always the possibility of an intentional blackhole, so storing the stem txes to disk is not an obvious benefit
vtnerd__the origin needs counter-measures either way
xiphonsomething is wrong then, this sounds like we don't guarantee that tx will be broadcasted to the network
vtnerd__you can't with dandelion++, thats how the protoocl works
vtnerd__and to be fair, you cannot really guarantee it with the gossip protocol either
vtnerd__theres no acking on this, its a fire and forget in monero
sarangD++ is intended to fail to the existing broadcast scheme, essentially
vtnerd__yes, its one of the consequences of having a single outbound path
hyc… we really should be using IP multicast
hycbtw, for those who aren't following this -dev channel all the time, I have a randomx testnet node on 206.127.12.163:28080
hycseems there are only 5 peers active at the moment
rbrunnerYeah, that was one of my questions, how that's going
rbrunnerThere were plans anyway to switch testnet soon, right?
hycrunning uneventfully so far. mining, sending coins around
hycofficial switch is waiting on fluffypony's availability
rbrunner
rbrunnerBut your well-running private testnet is a pro argument, then
rbrunnerFor such a switch
dEBRUYNEWith respect to binaries, what would the devs prefer?
dEBRUYNEWould a first 0.15 release within a few weeks be a proper timeline?
rbrunnerNobody seems to push a release, funny
xiphonthere will be anissue with Ledger
xiphonThey hardcoded accepted Monero version in the ledger monero app - the firmware the is installed on ledger device
xiphonit only accepts "0.14.1.0" string right now
rbrunnerSo they must plan to follow-up any Monero release quite closely, otherwise that does not make sense
xiphonand (if i'm correct) it usually takes some time for them to push an app update
hycall the better to get a 0.15RC out sooner then
hycand get them to use a saner version check. like >= 0.14.1
rbrunnerExactly
selstaThey added the strict version check because of the change bug.
xiphonas a fallback plan, i thoguh about doing a workaround on the monero side
xiphondisabling this check by always supplying "0.14.1.0" version to the device
hycyeesh…
rbrunnerOh, that's a straight road to hell
rbrunnerSee all the lying Windows does about the version numbers … yikes
selstaThey added the version check on purpose so we shouldn’t disable it like this.
xiphonright, i'm not saying it is good
xiphonbut, we will loose ledger support with the new version if they won't manage to patch their code
selstaThey managed to do it in time with the v0.14.1.2 release.
rbrunnerThat's why hyc's argument of early 15.x release is good
hycyes, give them more advance warning, more time to respond
rbrunnerThe earlier before the hardfork itself that is out, the better
moneromoooThe white noise stuff will most likely be in the october release.
moneromoooBefore a 0.15 release, the v12 changes should be reviewed and merged.
dEBRUYNExiphon: I presume they will release a new version in conjunction with our v0.15 release
moneromoooThat's 5823.
dEBRUYNESo 5823 and the RandomX PR are the consensus changes that need to go in before we do an RC right?
hycsounds right
hycrandomx is 5549
ErCiccione[m]so we are doing an RC release this time?
ErCiccione[m]because i remember many were against last hard fork
xiphondEBRUYNE: hopefully they will implement version >= check, so the user won't need to update the ledger app with every monero release
selstaPlan was to add >= for minor point releases.
dEBRUYNEErCiccione[m]: I guess we could also do a straight 0.15 and then work out any bugs via point releases
dEBRUYNEmoneromooo, hyc, vtnerd__: thoughts?
dEBRUYNEalso xiphon
vtnerd__well thats how its been done the last few releases
ErCiccione[m]i mean, i would totally go for an RC release
rbrunnerIsn't that mostly only an issue with labels?
moneromoooIf you're asking about version numbers, my preference is to have increasing version numbers. It mkaes things so much easier. IIRC pony prefers to have "rc" labels instead.
moneromoooI'm not gonna fight that, just moan from time to time and say "told you so" if it bites us later.
dEBRUYNEvtnerd__: Right
rbrunnerYeah, but also, how would an RC be effectively different from a release?
rbrunnerAnd not just called any other way
dEBRUYNEI guess we can release earlier now though because randomx and the other consensus changes are already ready
moneromoooAs long as it contains all the needed consensus changes.
rbrunnerYou are not moaning, you are moooing
moneromoooThat's randomx and 5823 AFAIK. If there's something else, say so.
moneromooorbrunner: indeed!
xiphonrbrunner: "but also, how would an RC be effectively different from a release?" - i think the difference is in the official press release statement
xiphonwe won't do one for -RC
xiphonso it will be for testing purposes
sech1randomx has 1 PR pending: https://github.com/tevador/RandomX/pull/118
rbrunnerHmmm, ok, but with the risk that less people test then
xiphonrbrunner: if that's is not how it is supposed to be, i'm lost
rbrunnerI see what you mean, yes, it's a trade-off of course
rbrunnersech1: An audit result, then, this RandomX PR
hycthat PR appears (so far) to have no downside
ErCiccione[m]about the RC thing. Since there are many contrasting opinions, maybe better keep the old system.
moneromooo"Everybody builds their own" ?
rbrunnerThe old system does not really look broken, either, so why fix
ErCiccione[m]well, would be nice to have more testing before a proper release, but at this point i think it doesn't worth it.
hycI suppose, if we don't do that last-minute advance-by-1-month release, it should work out fine
selstaReadline is still broken with reproducible builds.
selstathat has to get fixed with v0.15
hycisn't there already a PR for that?
selstaI haven’t seen one.
dEBRUYNEWe could reverse the commit that broke it I guess?
selstaReversing it would mean no readline at all But that’s better than broken readline I guess.
hychm, can't find one, must be misremembering
hycI think the original problem is linking readline without its curses dependencies. the next problem is that curses has different dependencies on different OSs
dEBRUYNESo I guess that is added to the list of things that need to go in before we tag
dEBRUYNEWould a target of tagging in 2 weeks be reasonable?
hycterminfo vs termcap vs … something else
moneromoooAny vote against the pay-for-rpc going in ?
moneromooo(I have a wip patch to make it use randomx, not pushed yet)
hycI have nothing oposing
rbrunnerIt's reviewed well, after all
xiphonwould be nice to have it in the 0.15
dEBRUYNEI guess we can conclude the meeting then
Sources and notes
- Meeting log: Overview and Logs for the Dev Meeting Held on 2019-08-25, 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.