Monero Dev Meeting Note Highlights and Transcript – 2017-02-05

Posted by: aerbax February 05, 2017
Logs

Dim instead of hide Show relay 351 lines
fluffyponyok
fluffyponywelcome to the 77th annual hunger games
hycoof
fluffypony1. greetings
fluffypony2. Brief review of what's been completed since the previous meeting
fluffypony3. Code + ticket discussion / Q & A
fluffypony4. Any additional meeting items
fluffypony5. Confirm next meeting date/time
1. Greetings
fluffyponyso let's start with 1
fluffyponyhi
peroHOLA
hychi. I'm hyc, and I'm a monerophile
SnipaMorning.
DaveyJonesArcticMine, luigi1111, luigi1114, luigi1112,  othe, hyc, smooth, jaquee, m5M400, medusa, tewinget, zone117x, dEBRUYNE, moneromooo
i2polarkgreetings
slackxmr-erichullo
Jaqueehey
DaveyJonesone question… is there free margeritas?
anonimalPresent in Q state.
slackendogenichands DaveyJones a margarita
fluffyponyDaveyJones: of course, dev meetings are 100% serious business and you need margaritas for that
ArticMinegreetings
2. Review of work since last meeting
fluffyponyok let's move on to 2
hycwhen was the last meeting?
DaveyJones2 weeks before christmas?
fluffyponyit's been nearly 2 months since the last dev meeting because of end-of-year and me travelling etc.
fluffyponydoes anyone want to mention stuff that's been done
botEinMByteHi
fluffypony(brb hopping out of taxi)
i2panonimal^ FYI, monero meeting, kovri in 55 minutes.
hycmany many commits have been merged
dEBRUYNEI am here
hycI will mention my own, using batched txns for node syncing, to reduce I/O demand
botEinMByteanonimal: Oh right, should be keeping an eye on the meta repository too
hycthis seems to speed up syncing on HDD by 2-3x while improving stability
Jaqueegreat stuff hyc!
anonimalhyc: sounds tasty
hyc(the actual goal was to eliminate the few corruptions we've see non Windows)
hycseen on
anonimalSo the corruptions were fixed too?
hycso far it appears so.
hycI examined 3 corrupted Windows data.mdb files. they all had zero pages at the tail of the file
hycdue to not being sync'd before OS crashed
hycthe new code syncs more frequently, but in a background thread
hycso throughput is still high because foreground doesn't have to wait for it
hycbut syncs are more often, to reduce the chance of unsync'd pages during a crash
hyc  but there's no 100% guarantee there.
anonimalIIRC, this fix/addition was after latest point release? Was point release before or after the previous meeting?
hycthis is for the default "fast" mode. you can still use "safe" mode for 100% guarantee, but super-slow.
hycand this is recent, merge was only a week or so ago
anonimalok
fluffyponyok back, just got to sXpher's house
hyccool. I think that's it for me.
fluffyponyhyc: tons of commits
hycyeah
fluffyponywas fluffy blocks already merged in by the last meeting?
anonimalI think so?… That was before point release right?
hycI thought fluffyblocks was in 0.10.1
Jaqueeyes, pretty sure it was
iDunkIt was
moneromoooI think it could be enabled on mainnet now, since testnet's not shown anything wrong with it.
fluffyponyanonimal: I can't remember
fluffyponymoneromooo: agreed
Jaquee+1
anonimalmoneromooo's new logging implementation, this is new.
moneromoooSnipa: you did test it with a private testnet with only such nodes, right ?
gingeropolousthe crazy reorgs on testnet are due to old nodes on testnet?
fluffyponyyeah the new logging colours threw me for a loop :-P
medusayes logging is new, GUi scope for next release is like this:
medusaextended x64 x86 linux support / cold signing / view only wallets / restore from private keys / integrated mining  / better logging / daemon status button /
medusa+display unlock time and confirmation
Snipamoneromooo - No, I didn't test on a private testnet, but my personal nodes all have patches enabling it on mainnet between them, and I'm not seeing any issues with it yet.
SnipaAll of my testnet nodes of course, have been running it as well without issues.
moneromoooOK, I guess my point was lost. I don't have the disk space for many blockchains to test though…
SnipaIf I need to go setup another one, I've got enough disk space to do so.  IIRC we thought it wasn't needed because all of the active testnet nodes were using it.
fluffyponymedusa: ok great
fluffyponyI think for future we should have a separate line item for GUI stuff
moneromoooMy point was that I wanted to see if it worked on a network with ONLY fluffy blocks being sent.
fluffypony(if there is GUI stuff I mean)
moneromoooBut it seems everyone just mentally removes the "only" word :D
SnipaAh, sorry, I must of missed that.  I can set that up still if it's wanted.  I've got more than enough nodes to do so.
moneromoooThat'd be great, yes.
moneromoooI thought you'd already done that actually.
moneromoooWhat I want to know is whether there is a failure mode when a node can't sync from a fluffy block, but gets the block anyway from another peer.
fluffyponycan't we just make testnet fluffy blocks only?
fluffyponyand then we test it there
Snipakk, I'll go figure out how to isolate a bunch of nodes this afternoon, and setup a small network to mine on.
moneromoooWe could.
fluffyponytestnet seems pretty robust given the amount of stuff we've done on it
fluffyponylol
medusaSnipa: https://github.com/moneroexamples/private-testnet
SnipaI mean, I leave a couple hundred h/s there on my test pool.  And have ~10-ish nodes up on it.
SnipaOh, so I can add multiple exclusive nodes?  I think that was one of the questionmarks I was running into.
fluffyponyokyes
fluffyponyyes
SnipaGood stuff, I'll go fight with that here in a bit.
fluffyponyok
fluffyponylet's move on
3. Code + ticket discussion
fluffypony3. Code + ticket discussion / Q & A
fluffyponyissues on Github are starting to pile up, and I think we should get on top of that
fluffyponyas discussed before, the lack of granularity in Github's permissions is a bit of an irritation
fluffyponywe've discussed having a second repo with more collaborators, but I think that's going to create more confusion than anything else
fluffyponyso my suggestion would be that we set up an issue closing bot that has collab status
fluffyponyand then that has a list of people that can ping it to close issues
hycthat sounds cool
fluffyponyI haven't had a chance to see if such a thing exists, but if not it isn't hard to write
perohttps://github.com/foosel/GitIssueBot
medusathat sounds great
fluffyponyand if we set it up to do re-labelling too
i2panonimalHow to protect from troll abuse?
Jaqueecool. could it handle labeling too?
perocant close yet but perhaps can be extended
moneromoooby "list of people"
fluffyponyanonimal: only specific people can ping it
i2panonimalk
medusaa good start would be if everyone also takes care of their own issues in the meantime ( i know me included)
fluffyponymedusa: agreed
4. Q & A / additional items
fluffyponyok any Q&A items?
moneromoooAbout what ? Anything ?
fluffyponymoneromooo: yes
fluffyponyhi, I'm fluffypony, AMA
peroi'm actually curious about the status of paybee
pero;p
fluffyponypero: paybee is fine. what I'm actually excited about is Wonero
DaveyJones…wonero?
fluffyponyDaveyJones: you take the monero logo and turn it upside down. the M becomes a W. that's the name, that's the logo, that's the entire design doc
fluffyponyhang on, I have it in notepad
fluffypony         .-~~~~~~~~~-.
fluffypony      .-'  \       /  '-.
fluffypony    .'      \  ^  /      '.
fluffypony   /         \/ \/         \
fluffypony  |                         |
fluffypony  |  #####################  |
fluffypony  |  #####################  |
fluffypony   \  ###################  /
fluffypony    '.  ###############  .'
fluffypony      '-.  #########  .-'
fluffypony         '-._______.-'
hycthat is the most effort anyone has put into a logo in this channel
DaveyJonesit's a W in a circle
fluffyponyDaveyJones: it's the monero logo upside down. show some respect
hycwhat does it do
fluffyponyhyc: everything monero does, upside down. tagline is "insecure, public, traceable". ringsize 1, and every tx gets posted to reddit automatically
fluffyponymerchant adoption is strong. you can currently spend it on exactly two things: margaritas for DaveyJones, and a refund from whoever sold you wonero
hycso fluffy blocks are heavy blocks
fluffyponyhyc: 2-3x slower on HDD, yes
anonimalIs this a real thing or
fluffyponyanonimal: no. it's a joke coin. there is no repo, no coin, and the logo is literally a picture of the monero logo rotated 180 degrees. putting that in the log now for the inevitable bitcointalk thread
luigi1112too late, already forked it
fluffyponyok moving on
moneromoooThen I'm annoyed at the merge commits, which can embed some arbitrary amount of dross, making things easy for an external attacker with access to github to slip pwnage.
moneromoooDoes anyone know a good way to prevent those (with manual exceptions since tewinget already said he wouldn't rebase the massive 0MQ branch) ?
fluffyponypero: we can talk about it later
DaveyJonesany word from tewinget? did not read a thing from him recently, regarding 0mq
moneromoooA git hook looks like the obvious option, though it's still vulnerable to github.
peroi asked him last night - sec
fluffyponymoneromooo: you mean to merge without the merge commit?
Jaqueethat would require a rebase by the merger?
pero<tewinget> <pero> very little movement on that front - the pr hasnt been touched in 2 months <— I haven't commented on it in as much time, but I've worked on it.  Not as much as I could/should have, of course, but…
moneromoooI'm not sure about that. AIUI, it's needed for the signatures. I'm not super knowledgeable about what that entails wrt amount of dross.
i2panonimalfluffypony: you very recently finished your extended 1 month+ tour, can you fill us in with details of any notable experiences?
fluffyponymoneromooo: it is needed for the signature, not everyone is signing their commits
moneromoooYes, rebase would fix, but that'd need a LOT of rebases, so isn't practical.
hycand cherry-picking would lose signature?
moneromooocherry-pick -S resigns.
fluffyponyit re-signs
fluffyponyand we want to maintain author sigs where they exist
hycbut with picker's key, not original key?
anonimalbelieves so
moneromoooYes, if someone else cherry-picks, then you can't preserve sig.
moneromoooThis massive hole just annoys me, but I'm not sure how to fix it.
fluffyponymoneromooo: me neither
luigi1112are you talking about the merge commits into master or like merging instead of rebasing
fluffyponyI don't think it's a solvable problem
moneromoooMy automated sig checking on make thing is also vulnerable to that, since it trusts anyuthing the pony signs.
fluffyponyluigi1112: merge commits into master
moneromoooWell, we can ask him to rebase, that's not hard.
moneromoooIt is for tewinget due to the amount of stuff, but that's a special case.
fluffyponymoneromooo: rebasing will also make it hard to use Github to track PRs, surely?
fluffyponyrebase-only I mean
luigi1112so you want the maintainers merge commits to go away?
moneromoooI meant rebasing before PR. The merger would still do a merge commit, unfortunately.
moneromoooNo, just yours, if you PR any. I understood fluffypony's line to mean this, maybe I misunderdtood.
hycwell,we can solve this but the procedure gets more awkward:
hycPR author rebases before merge
hycwhich mean merger has to contact PR author immediately before each merge
moneromoooOh, I hadn't seem luigi1112's first line. Ignore my last 2 then.
moneromoooYes, that's what I ment by not practical :/
fluffyponyyeah that won't work
fluffypony:(
anonimalQuestion:
fluffyponyanonimal: answer
fluffypony:-P
moneromoooI guess the best we can do it some kind of subjective "rebased not too long ago so any extra dross diff is small enough".
DaveyJonesi know … i know … 42
anonimalOk, two questions: is PR author out of the picture? Poof/gone?
moneromoooBut it requires the merge to check it.
moneromoooanonimal: usually not, but maybe a couple days' latency. Which means the merger has all the latencies in series.
anonimalnot 100% following the problem
anonimalOh, ok.
i2polarkWhat about hosting code on something that is under our control and not github? This would involve not using github though.
fluffyponymoneromooo: but this is all in an effort to make sure that maintainers can't introduce extra bits in, right?
moneromoooI guess most of the problem is fixed by refusing any patch with irrelevant crap, with merge commits, and when they also cause more than trivial diffs in the final merge commit.
fluffyponyolark: that's not the problem, my merge commits are GPG signed, so I'm the failure mode, not Github
i2polarkright
anonimalSo, why not close their PR and reopen a new one with their branch merged (not rebased) to maintain original sigs?
moneromoooWell, maintainers and anyone who could fool the maintainer into signing a large merge.
anonimalIf they can't keep up, then do the work for them?
moneromoooanonimal: I do not understand "why not close their PR and reopen a new one with their branch merged (not rebased) to maintain original sigs?"
hycneither do I
hycsounds to me like it would create exactly the problem we're trying to address
hycPRs with irrelevant changes sliding in
anonimalI think I don't understand the problem, so my question doesn't make sense.
anonimalis 25% here, preparing for kovri meeting
fluffyponymoneromooo: otoh it's not like we have so many eyes on PRs that nothing at all could be snuck past us, so maybe we're trying to solve a problem that is ultimately a non-issue
hycI think we should continue this after the meeting, probably won't solve it here.
moneromoooSo… we're screwed alrady, might as well not care ?
luigi1112:-)
fluffyponymoneromooo: yes :-P
moneromoooI guess it is a practical solution for now.
moneromoooThough, an easy win is to automatically reject any PR with a merge commit in it.
i2polarkhmm
moneromoooIf github could be set up to reject those, that'd remove a good chunk of dross already.
fluffyponymoneromooo: I'm happy with that - could the requester fix it by rebase + force-push ?
moneromooo(though still vulberable to github itself, but we said we don't care for now)
hycdo you have a recent example of a problematic PR?
moneromoooYes. That's what I do when I fix a trivial thing in a PR of mine.
slacknanoakronThat’s what I do with mine
hycand yes, I usually rebase my PRs on latest master
fluffyponyon the topic of Github, pigeons has a Gitlab mirror running on our (Monero's) hardware, so we're reasonably resilient to weirdness
moneromoooNot a recent one. I found one, but it's a very odd behavior on a single VM.
moneromoooA mirror isn't really a good protection against this I think.
fluffyponyok so new rule is that people submitting PRs should be asked to rebase + force-push if a merge commit exists in their PR
moneromoooYes, please. I do when I see them, but I often look just at the diffs and forget commits.
hycyeah that sounds reasonable
Jaqueeyep
moneromoooBut it could be automated I think.
fluffyponyI'll look to see if there's a hook
fluffyponywould be nice to automate things like notices on buildbot failures
moneromoooI just saw a java jar one. Which seemed… meh.
fluffyponyor on first-buildbot-failure
slackjollymorti have one q: what if the price explodes again and does 10x - what to do with fees? make F0 in the dynamic fee calc 10x smaller? somehow i feel it would call for a one time 10x blocksize bump as well to keep the proportions same, otherwise we'd need huge multipliers to get to the point where increasing fee gives incentive to bump the blocks
fluffyponyArticMine: ^^
ArticMineA price increase without a corresponding increase in blocksize?
slackjollymortyeah
pigeonsthe ircbot for buildbot can notify when a job goes success->fail
slacknanoakron@jollymort it’s not really reasonable to ask the blockchain to care about the fiat price because that requires gameable oracles
fluffyponypigeons: can it notify on the PR tho?
pigeonsyes
fluffyponypigeons: ok cool - let's chat about it later / tomorrow and figure out which platforms we want to target with that
slackjollymortnanoakron i get it, but with the current set-up we decided on an arbitrary starting point
slacknanoakronYou mean 60k blocks?
DaveyJonesalso jollymort … what is a reasonable time-frame to call sth a higher price to even justify changing F0 ?
moneromooofwiw, there's so much constant failures that I ignore the buildot pings now (sorry)
ArticMineOver time the assumption is that price follows transaction demand. Over the short term ther may well be a delay.
slackjollymortgood point Davey… but i can imagine a scenario where we have 3$ fees for some period
slacknanoakron@jollymort What is a $3 fee? How does the system determine that in a zero-trust manner?
slackjollymortit doesn't
slackjollymortmaybe difficulty is a loose peg
slacknanoakronFees are an economic negotiation between miners and users
ArticMineIf the price rises very fast it could happen. There is another complication factor here namely one time changes in transaction size
slackjollymortyeah, was RCT size bump considered?
DaveyJonesmaybe if sth like the average tx over a given time period sink TOO low some kind of mechanism would detect such a behaviour and see it as too expensive TX
ArticMineUltimately fees are set by the blocksize penalty / demand / base reward
slackjollymortnanoakron i know that, but the minimum fee could become problematic in case of price bump
slacknanoakronThe sudden increase to RCT sizes should have perhaps been considered in advance. The problem is people who panicked and refused to use RCT Tx, thereby keeping an odd mix of large and small Tx in each block, preventing proper upwards adjustment in size and downwards adjustment in fee
DaveyJonesbuth my math is way to bad to give a better example :D
slackjollymortso just changing F0 would probably be ok
ArticMineYes the minimuim fee could need to be adjusted
slacknanoakron@jollymort can you please model what you want to happen first and submit it as a post or code somewhere so it can be considered formally? A bit of academic rigour would be nice here
ArticMineWe just had an effective increase in TX size ~10x +
DaveyJoneswithout changing F0
ArticMineF0 was changed just before in anticipation
DaveyJonesah okay
slackjollymortcool
slackjollymortanyway, i'll do some study
slackjollymortbut just wanted to see your thoughts
ArticMineThe relevant question is the change in RingCT Tx size and further optimizations
slacknanoakronI’m not averse to the idea, so long as it can be justified with a nice model of the expected behaviour and consideration of the potential attack surface
slackxmr-ericI have a question. When should the GUI come out of beta status? Because things are feeling pretty stable and the featureset seems complete to me.
ArticMineSince this influences blocksize and consequently fee paid
hycIt should be perpetually beta. It gets lonely around here without the reassuring lull of "where's the GUI" in the background
slackjollymorti was thinking of: increase baseline block size x5 and reduce F0 with x0.2
slackjollymortbut block size is consensus so..
moneromoooWhere's the LMDB wallet file ?
slackjollymortneeds some justifications
DaveyJonesnanoakron like i said… maybe sth like the average tx numbers decrease drastically for a given time frame could be a trust-less way too do it… but i have no clue how to get a decent formula
slacknanoakronHrm…
DaveyJonesas actual example… the price pumps and suddenly it is WAY to expensive to do any tx for the people
slackjollymorttx numbers can be gamed
ArticMinejollymort there is merit to this
slacknanoakron@hyc is it possible to auto-scan the database file if the system wants to crash? e.g. “Database corrupt after block 120842…rewinding…"
slackjollymortx5 due to RCT size increase
slackjollymortwhen the original 60kb was set, probably RCT was not in the works
slackjollymortso it was based on TXes of 1kb
luigi1112yes
ArticMinethe issue is the relative size of the tx to minim blocksize
slackjollymortor whatever was the pre-RCT size
luigi1112is dev meeting over
hycnanoakron: not in general. since we only keep 2 persistent versions of the DB.
slackjollymortArcticMine yes, that's how i see it
hycnanoakron: if the OS failed to sync the previous two txns, then the corruption is uncrecoverable.
slacknanoakron@hyc :( How about these pages of zeroes - if that’s a consistent failure mode can they be unwound?
slacknanoakronOh
fluffyponyok guys
slackjollymortanyways, just wanted to know if anyone else thought about this; won't take any more of your time
5. Wrap-up — handing over to Kovri
fluffyponylet's wrap it up
slacknanoakronThat’s all it takes?
slacknanoakron2 Tx
fluffyponyKovri meeting starting in 5 minutes
hycnanoakron: yes. we could change this.
DaveyJonesfluffypony … AMA after the kovri meeting? :D about your journey and paybee?
hycnanoakron: use a longer delay before reusing old pages.
DaveyJonesif you got something to tell ^^
slacknanoakron@hyc Ok. At least there’s a potential way through it.
i2polarkI opened an issue to start discussing alternatives to the ringsize increase in September 2017 that negates a lot of possible attack vectors on ring signatures and still ensure a 'true' strength of ringsize 4 at minimum for all transactions. It is here https://github.com/monero-project/monero/issues/1673 I think it requires serious consideration moving forward. I won't go too much into it and
i2polarkjust let everyone read the writeup :p
slacknanoakron@olark I’d like knaccc to contribute too with his modelling of churn
slackxmr-ericI like the idea of a static ringsize
slackjollymorti like the "static" proposal
slackxmr-eric^^
slackjollymortand yes, also churn
fluffyponyDaveyJones: sounds good - I've got to step out for a little bit
slackxmr-ericNo thoughts on getting GUI out of beta status, everybody
i2polarkbecause the current situation is… undesirable to say the least
moneromoooWhat is beta status ?
hycxmr-eric: sounds like not yet.
Jaqueexmr-eric: i think we need one more beta release at least.
knacccnanoakron kenshi84 blew some big holes in my churn suggestion btw, so my model isn't good yet.
slacknanoakron@knaccc Ah…well, all discussion is good
slackxmr-ericCool
hycknaccc: cool, is that written anywhere?
slacknanoakron@xmr-eric and if you see bugs, please bring them up on github
fluffyponyok anonimal the floor is yours
slackjollymortalso, opened discussion on multiple PID / TX : ) https://github.com/monero-project/monero/issues/1659
knaccchyc only in my IRC logs. Summary is that the churn only works if you're churning with pure ringct trees, doesn't work if there are non-ringCT transactions mixed in
hycthx
i2panonimalI have 2 minutes to prepare
slackjollymorti thought you can't mix rct+non-rct outputs anyway
i2panonimal17:59 1 minute!
Jaquee+1 lmdb wallet
slacknanoakronwaits with bated breath
moneromooocongratulates nanoakron for correct spelling.
slacknanoakron:grimacing:
anonimalAny objections to me typing in #monero-dev?
knacccjollymort it's when you mix with an output that is a ringct output but whose inputs are non ring-ct. that breaks churn
botfluffyponynone from fluffy-on-this-side either
fluffyponynone
hycno objection
moneromoooThat wasn't sarcasm actually :D
i2pArticMineFine with me
Sources and notes

Meeting log: Overview and Logs for the Dev Meeting Held on 2017-02-05, getmonero.org (posted by dEBRUYNE / fluffypony). The official post carried only the raw log and pointed readers to HelloMonero for the overview: "An overview can be found on Hello Monero."
Original HelloMonero article announced on r/Monero by u/aerbax (5 Feb 2017, 48 points) and shared by @monero on Twitter (8 Feb 2017).
Original URL: https://hellomonero.com/article/monero-dev-meeting-note-highlights-and-transcript-2017-02-05 — no longer online; the Wayback Machine holds no capture of the page from when the site was live. The highlights above were therefore written fresh from the log rather than copied from the lost original.
The short "Wonero" exchange in the Q&A (lines marked with an orange dot) is an addition of this reconstruction and does not appear in the archived getmonero.org log.
Meeting time is inferred from the log (the Kovri meeting was "in 55 minutes" shortly after the start, and anonimal's countdown puts it at 18:00 UTC). Next-meeting date confirmed against the getmonero.org archive.
Post tags: Dev Meetings, Monero Core, IRC