Monero Dev Meeting Note Highlights – 2018-01-28
Logs
351 lines
hycmeeting time
rehrarye
rehraragenda: https://github.com/monero-project/meta/issues/166
rehraras always, start with 1. Greetings
sarangyo
msvb-labHi there.
hychey
rbrunnerHoi zämme
iDunkHi
pebxhi
rehrarArticMine fluffypony luigi1111 luigi1111w smooth NoodleDoodle anonimal anonimobile endogenic gingeropolous vtnerd pigeons
pigeonshi
vtnerdhi
rehrardEBRUYNE Jaquee dsc dsc2 ?
gingeropolousoh theres a meeting?
rehraranyone else?
endogenicno ginger
iDunkmoneromooo
dEBRUYNEI am her
dEBRUYNEe
rehrarmedusa moneromooo othe
smooth1
rehrarWell, welcome everyone! :)
rehrar2. Brief review of what's been completed since the previous meeting
rehrarAnyone have any exciting stuff to report for development?
medusahi
sarangMRL Goes To Stanford
sarangIt was observed that bulletproofs can have batch verification, which will be great time savings even between separate transaction
ArticMinehi
bearretinjapanhi
hycbatching is always interesting. have to balance batch size vs latency, waiting for enough txs to arrive to fill a batch
sarangThis can be useful for new nodes
smoothcurrently the code waits for all the txs before doing anythign with them anyway, although that could change
sarangInitial testing by andytoshi indicated that subsequent proofs were only ~15% of the time complexity of a separate verification
hycnice
sarangYeah, it merges all the multiexp operations into one
sarangeffectively replacing group operations with scalar operations
sarangSo the time savings really depend on the relative timing between those ops
sarangAnyway, mostly excellent talks at the conference, and good lessons learned
sarangwill be quiet now
rehrarAnyone else? :) GUI have anything?
medusathe GUI project has merged sub addresses. also we removed the ability for the user to generate payment ids and integrated addresses
medusain addition, there is a new monerod start up flag, called –boostrap daemon https://github.com/monero-project/monero/pull/3165
hyc^^ this looks very good. I wonder if the GUI should use that by default
medusathe GUi will make use of this too, so there dont exist several implementations of the same thing
gingeropolousis that supplanting Jaquee 's thing?
medusaPR is allready here hyc https://github.com/monero-project/monero-gui/pull/1091
medusagingeropolous:as far as i understand it, yes
rehrarI'll repaste xmrscott[m]'s message so people who don't want to click don't have to
rehrarDavid Mirza Ahmad, president of Subgraph OS, has put together a byte-for-byte matching Debian package and is requesting comment on some final pieces: "There some decisions to make for us, like: where does the blockchain data go? Do we start the daemon with systemd by default (feeling like no, as it can be started in GUI)? Appreciate thoughts on this." No one has provided comments on these matters so if anyone here could do so it woul
rehrard be appreciated. https://github.com/monero-project/monero/issues/2395
rehrar\^
pebxthanks for the update medusa! this looks very good. we shouldn't forget that GUI is the interface to the rest of the world…
msvb-labrehrar: Byte for byte matching, you mean as in reproducible build? Gitian?
rehrarapplauds the GUI people for their consistent quality work
pigeonsI looked at his repo and i didnt see the debian control files to reproduce
rehrarxmrscott[m] \^ msvb-lab's question
ArticMineAny idea on timeline from an update at out end to the repo?
xmrscott[m]I believe so. I'm not familliar with build terminoogy,
xmrscott[m]The sha256 sums match: d5b0295d55f9951a6995e2ecc1516898799b22686ed81ca07b05b493175f2f66
xmrscott[m](THis is shown on the comments in the GitHub issue)
rehrarAny answer for ArticMine's question?
hycunknowable
rehrarbam
hycdistro release schedules are seldom anywhere near upstream release cycles
ArticMineMy concern is stale Monero in the distro
hycyes
hycit's a frequent occurrence in distro packages
ArticMineWith a six month hard for cycle
ArticMinefork
hycwhich is why I've never put much priority on distrok packaging. reproducible builds are a good thing in and of themself though.
rehrarAlright, if nothing else, we can move on to 3. March hardfork items + code freeze
rehrarAnything to be discussed about the upcoming hard fork? Is there a code freeze date yet?
dEBRUYNEPreferably very soon. Then we don't have to rush stuff
ArticMine… and bulletproofs
sarangWhat about BPs?
hycseems they're off the table for March, since audits haven't been completed
hyc3rd party audits
sarangCorrect
rehrarmissed the meeting last week ArticMine
rbrunnerHave any been started in the meantime?
sarangI'm waiting on a formal SoW from one of the groups
sarangThen I'll present my recommendations among all groups
medusasince BP seems to be off the table, is the new wallet option the only planned change to address current high fee situation ?
sarangWe're looking at ~40K per professional audit
sarangand hopefully get benedikt to do a review of at least the Java since he wrote the damn thing
sarangfor $
rehrarmedusa: we should crash the price in the meantime
sarangShould we include batch BP verification in the audited code?
sarangOr put that aside
endogenicrehrar: was that a preannouncement? :)
endogenicsarang: perhaps as optional extra credit?
hycwe should audit whatever we hope to release in Sept.
hycotherwise we'll just need to do all this again for each incremental improvement. ??
sarangIt'll be included in an updated whitepaper in Feb
sarangby benedikt et al., not by me
rbrunnerWell, maybe plan in a way that makes pretty damn sure we will be ready in September :)
pebxwhat about the fees medusa mentioned? it's also something the average user sees first and complains about… if we don't release BPs there should be some lowering of fees beside the low to standard thing
dEBRUYNEI suppose we can discuss lowering the low priority level since it's arbitrary anyway, but we can't lower the default because we'd have to tweak the penalty as well
ferretinjapanBPs being released in March was also cited as a reason for onot loweiring fees.
smoothwe can lower the default a little i think, but no one has taken the time to study it
smoothso actually no, we can't
sarangAs to BP funding, I plan to open an FFS with "checkpoints" for an amount covering at least one pro audit and another for a review by one of the paper authors
endogenici was just going to ask about that, smooth
smooth'default' isn't really the right term though. the pending PR changes the 'default' to be dynamic
dEBRUYNEold default then? :P
smoothyeah "medium" whatever you want to call it
smooth"normal"
rbrunnerbase fee?
dEBRUYNEsmooth: any opinion about lowering the lowest level?
smoothetc.
rehrarBase fee sounds good
smoothbase fee doesn't seem like the best term to me
smoothimplies that is actually the fee you pay
smoothit is more like a 'fee reference value' or something
rehrarI think it should be more than 'medium' though, because it's the one that will increase the block size. Something a little more souped up than 'medium'?
ferretinjapanfloating reference fee?
rehrarEither way, thoughts on lowering the arbitrary 'Low Fee'?
ArticMineWe have to be careful with the low fee level relative to the 1 tx at penalty (default)
ArticMineSpam attacks becomes possible if the probability of mining becomes too low
pebxthe crypto "market" might crash in the meantime, but it also might not and what if monero's market price until september rises like within the last 8 months?
smoothArticMine: but doesn't the probability of mining just depend on how many of each there are and not the fee amount?
pebxthe minimum fee is a good protection but also a pain…
smooththe issue i see with too much of a gap between levels is the incentive to circumvent (just bump up your own fee a little so you are above all the others in the same level but not all the way to the next level)
dEBRUYNEpebx: I'd leave any price predictions out of this discussion. Tomorrow's price is most likely today's price
smooththe more gap the greater the incentive to do that
pebxdEBU
pebxis it not about price when it comes to fees?
smoothother than that the low level seems aalmost comletely arbitrary to me
dEBRUYNEPrice surely influence fees (as they are denominated in XMR). I was just saying that we should leave price prediction out of it
rehrarWell if we want a code freeze "soon", we should try to decide this "soon" too, no? Or would this not be affected really by the freeze?
dEBRUYNEprediction
ArticMineI mean how low on the min fee do people want to go?
endogeniccan we put together a study on fees and spam? having a shared model (and simulated results) we can reference and improve collectively would be great… certainly would ease the knowledge gap
pebxi didn't want to include any prediction, so i told it might continue or not
dEBRUYNEsmooth: I guess if we had 1/5th or 1/6th (current is 1/4th) the gap would be still sufficiently small? Also people would have to tweak the code and compile it themselves to make use of the gap
smoothendogenic: it has been done. we can do another one but until it is done we can't rely on it
endogenicsmooth: do you mean the recent writeup?
smoothendogenic: that one, the older one. whatever is done we can rely on. we can't rely on something that is 'can we do' especially with an imminent freeze
smoothof course we can do more studies
endogenicsmooth: i would only suggest inaction until after study/ confirmation
ArticMineand then nothing for March, after which we will have BP
rehrarWhich brings us full circle :P
moneromoooCan we finish the meeting first, and go back to the fee stuff ?
endogeniclol mooo
rehrarAlright. Moving on then! 4. Code + ticket discussion / Q & A
pebxnice to see you, mooo
dEBRUYNEpebx: Your sentence sounded like that, hence my statement. I could've misinterpreted you though.
ArticMineI sugest we leave fees aslon for March or at most introduce the wallet side adaptive fee between default and min
ArticMinealone
medusathats allready merged afaik ArticMine
smooththe adaptive should go in if at all possible from a stability perspective imo
smoothoh i didn't know it was merged. great
pebxdEBRUYNE my point is, that at some point fees can get insane like they have been / are in bitcoin
ArticMineThen if it is merged that is all
gingeropolous^^
medusathis one no ? https://github.com/monero-project/monero/pull/3123
smoothyes. lets move on: rehrar>** Alright. Moving on then! 4. Code + ticket discussion / Q & A
rbrunnerI have a little thing: The Windows installer missed the Fall releases. But surely the March release is a perfect opportunity to finally put it into service …?
hycyeah sounds like we're fine for now on fee
gingeropolousall this code and ticket discussion
iDunk3186 and 3198 need merging to fix some builds.
rbrunnerI hope it's not itself controversial that having a Windows installer would be nice
medusaabsolutely rbrunner, the worlk load regarding that is mostly on the shoulder of the binary builder (pony). we cant really do anything to speed it up i fear
rbrunnerAh well, March is early enough :)
rbrunnerJust do not forget it :)
luigi1111I personally prefer portable exe but both are fine with me
moneromooo"portable" and "exe", hmmm :)
hyclol
dEBRUYNEpebx: I surely hope the dynamic fee algo has kicked in by then. Anyway, I'll refrain from commenting on fees now.
luigi1111:)
pebxdEBRUYNE hope is good… but i'll also not comment fees in this meeting any more.
rehrarAnything else for code and ticket discussion?
rehrar5. Any additional meeting items (besides fees)?
msvb-labOr hardware questions.
rehrardid you want to share something msvb-lab?
msvb-labNothing to share. We're working on the next gen prototype.
msvb-labQuestions are welcome in any case.
rehrarAlright then.
rehrar6. Confirm next meeting date/time
rehrarFeb 11th?
hycsounds right
rehrarluigi has mentioned a couple times about switching the time
hycbtw, I'll be at FOSDEM next week. anyone else going?
medusai want to thank everyone that is working on making the build envs green. you guys are heros <3 **<rehrar> don't know if he was serious, but does anyone else agree?
hycswitch to what time?
msvb-labhyc: I'll be there too, at FOSDEM in Bruxelles.
rehrarluigi1111 luigi1111w?
rehrarI guess just as a general question, is this time inconvenient for other people?
hycseems ok to me
rehrarhyc has spoken
moneromoooIIRC ArticMine objected.
rehrarI'll probably open a meta issue and ask for opinions.
ArticMineI would prefer an hour earlier
hycgood idea
rehrarFor now we can have next dev meeting same time, and see about moving others.
endogenici'm fine with an hour earlier
rehrarSound ok for everyone?
pebxhyc can't wait for your talk to see it at least online!
rbrunnerYes, one hour earlier is ok as well
rehrarHmmm…ok, tentative next meeting time Feb 11 at 16:00 UTC
rehrarThe time will be open for discussion on the meeting issue
rehrarMeeting over. Thanks for coming everyone. You're all the best, and don't let anyone tell you otherwise.
Sources and notes
- Meeting log: Overview and Logs for the Dev Meeting Held on 2018-01-28, 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.