2018-06-17 - Monero Dev Meeting summary and logs:

<rehrarthebrearar> k, made a new channel #monero-world-cup
<rehrarthebrearar> dev is now focused
<m2049r[m]> and monerujo doesnt have subaddresses (yet) 😆
<rehrarthebrearar> pre pings
<endogenic> rehrarthebrearar: better to have pinged the people
<rehrarthebrearar> ArticMine binaryFate fluffypony luigi1111 luigi1111w smooth hyc moneromooo vtnerd iDunk anonimal
<endogenic> pinged -> PMd
<rehrarthebrearar> DaveyJones dEBRUYNE Jaquee dsc_ medusa_ gingeropolous suraeNoether sarang stoffu
<rehrarthebrearar> pigeons serhack tficharmers and all others
<serhack> thanks rehrarthebrearar
<rehrarthebrearar> https://github.com/monero-project/meta/issues/244
<rehrarthebrearar> 1. Greetings
<endogenic> hi rehrar
<rehrarthebrearar> Who all is out there?
<rbrunner> Hoi zäme
<serhack> Hello
<ErCiccione> Hi!
<+moneromooo> here
<rehrarthebrearar> 2. Brief review of what's been completed since the previous meeting
<+hyc> I'm definitely out there
<rehrarthebrearar> Anyone have anything to report for the past couple weeks?
<endogenic> rehrarthebrearar: anything to report?
<rehrarthebrearar> I had a good vacation. That's my report.
<@ArticMine> hi
<endogenic> dev related
<vtnerd> present
<+hyc> nothing to report here
<ErCiccione> the bastard unofficial release: https://www.reddit.com/r/Monero/comments/8rkwyt/unofficial_release_of_gui_wallet_version_0122/
<vtnerd> got some patches for ZMQ JSON RPC stuff (missing data, etc). apparently no one using a few of the calls
<endogenic> ^-- we're making progress on the lightwallet server, which is using lmdb and zmq
<endogenic> or hosted wallet
<vtnerd> the ZMQ is between daemon <--> mymonero-api-compatible-server
<vtnerd> otherwise its still using http REST+JSON for better/worse
<serhack> I'll take a look vtnerd and endogenic, any links?
<endogenic> soon
<vtnerd> although supporting ZMQ on that shouldn't be terrible should someone want it
<vtnerd> good point, haven't published that yet will get on that
<@ArticMine> I am working on the fee / scaling formula for Bulletproofs
<el00ruobuob_[m]> how are the audits going?
<serhack> Personally I am working on Mastering Monero. I know that isn't dev related but that will help new developers that would like to understand about Monero.
<@ArticMine> Mainly to address the difference in scaling for size and verification time
<rehrarthebrearar> any update on that ArticMine? How's it going?
<@ArticMine> I am not dealing with the audits directly
<rehrarthebrearar> I meant on the fee/scaling formula
<@ArticMine> The concept is done it is mainly the details
<rehrarthebrearar> sarang needs to report on the audits, but it doesn't seem he's around atm
<suraeNoether> el00ruobuob_[m]: Quarkslab apparently says they will be done very soon
<suraeNoether> end of next week
<@ArticMine> replacement of blocksize with block weight
<suraeNoether> sorry, hi, i'm here :D and helpful
<+hyc> sarang left a note in -research-lab yesterday or so
<sarang> Quarkslab will finish in about a week
<+hyc> Quarkslab said they found a few opportunities to flag invalid stuff earlier, but no vulns.
<sarang> Kudelski around end of month
<suraeNoether> i'm literally emailing a musig author right now about a question koe and i both had about their set-up and replay protection
<sarang> Benedikt begins now
<+hyc> oh there he is
<sarang> Yeah just for a minute tho
<el00ruobuob_[m]> good to hear!
<rehrarthebrearar> yup, sounds promising. Anyone else?
<rehrarthebrearar> alright, let's move on
<rehrarthebrearar> 3. Point release items (GUI)
<rehrarthebrearar> I expect this to be short because all that's being waited on is fp, no?
<dEBRUYNE> Yes
<rehrarthebrearar> Ok. :P 4. Code + ticket discussion / Q & A
<dEBRUYNE> Oh for the GUI I suppose we could discuss this -> https://github.com/monero-project/monero-gui/issues/1465
<dEBRUYNE> ^ If anyone has remarks, throw them out :p
<rbrunner> I thought that this "bootstrap mode" (remote daemon until local one is synced) is already worked on. Misunderstanding?
<rehrarthebrearar> reading
<+hyc> as I commented on reddit, I believe this will lead to local nodes never catching up
<+hyc> users will fire up wallet, do a few things, then shut it all down
<+moneromooo> Ugh. Good point.
<el00ruobuob_[m]> are casual users supposed to run a full node? If gui is too heavy for them they'll use monerujo or cake wallet...
<ErCiccione> yeah that's probably a deal breaker hyc didn't think about that
<@ArticMine> Can we wait for bullet proofs? There are a lot of optimization that will impact this
<dEBRUYNE> Bulletproofs doesn't reduce the sync time retrospectively
<dEBRUYNE> rbrunner: The functionality is there, it just isn't default
<@ArticMine> But has a major impact on the verification time
<+moneromooo> They kinda do. Range proofs covered by hoh aren't checked.
<dEBRUYNE> moneromooo: could you elaborate?
<iDunk> The mysterious hoh :)
* dEBRUYNE heads to github
<+moneromooo> case 1: quick sync from 0 to 1.5e6, slow range proof sync from 1.5e6 to 1.6e6.
<+moneromooo> case 2: quick sync from 0 to 1.6e6, medium speed bp sync from 1.6e6 to 1.7e6.
<+moneromooo> You traded 100k slow for 100k quick + 100k medium, which is very likely faster.
<+moneromooo> Won't last super long as the chain grows though.
<dEBRUYNE> hyc: Good point. I'll have to put some thought into that. More full nodes is only one aspect of a greater user base though. Another would arguably be more transactions
<+moneromooo> (100k is a placeholder, I don't know the actual number)
<dEBRUYNE> I see, thanks for clarifying. Do you have an idea how much it saves relatively though?
<@ArticMine> Another issue that we want to encourage more nodes to improve the new user performance
<iDunk> Hours.
<@ArticMine> Try syncing MoneroV and one see the impact of very few nodes
<+moneromooo> They actually released somthing ?
<@ArticMine> It took like 4 day on hard ware that would sync Monero in 5 hours
<dEBRUYNE> ArticMine: I posit that eventually you end up with more full nodes though
<+hyc> using bootstrap nodes is better than no local nodes at all
<+hyc> but I think overall, not a lot better
<@ArticMine> I am not disagreeing just saying that are changes in the pipeline that will impact this
* Keniyal (~Keniyal@unaffiliated/keniyal) has joined #monero-dev
<+hyc> either way, you need to get in the user's face and make them read and click.
<+hyc> don't leave it hidden/automatic/transparent.
<rehrarthebrearar> do we stick then to the ideals, or do we make concessions for reality?
<endogenic> *rolls his eyes*
<dEBRUYNE> hyc: Yes, we'd rather have a user use a bootstrap node than a remote node indefinitely
<rbrunner> I think most new users lack completely the conceptual understanding of the whole architecture to judge what to do
<+hyc> and it might be as futile as expecting people to read EULAs before clicking OK
<@ArticMine> Sometimes the ideal actually make the reality work
<endogenic> <3 ArticMine
<@smooth> the reality really doesn't work if everyone is just trying o use free remote nodes
<+hyc> but I think we should still put it in front of their face and force them to click.
<dEBRUYNE> hyc: Are you proposing some kind of disclaimer page?
<dEBRUYNE> Like ToS :-P
<rbrunner> Maybe put nice animations in front of their face that help understanding of daemons and the network?
<endogenic> how about an incentive system?
<rbrunner> And the importance of all
<ErCiccione> what kind of incentive endogenic?
<rbrunner> A lottery among all the new full nodes of the current week? :)
<endogenic> well to smooth's comment if people are just using free stuff..
<dEBRUYNE> rbrunner: I think it would be more important to warn them about the trade-offs of (temporarily) using a remote node
<@smooth> rbrunner: we can hire Kurzgesagt to do a nice animation for us
<dEBRUYNE> and give them an option to opt-out and just start the blockchain sync from scratch without a bootstrap node
<+hyc> dEBRUYNE: yes. explain "we're uding a remote node to get you started quickly" blah blah blah
<rbrunner> Yeah, but first you have to get enough understanding to even see what is a remote node :)
<rbrunner> Or a "node" at all
<rbrunner> I think hiding all this exactly the wrong way
<rehrarthebrearar> I think that the wallet stewarded by the core team should indeed stick to the ideals. If somebody else wants to make a GUI that goes remote node first or by default, then nobody is stopping them
<ErCiccione> don't we have some PR people right now? they could help with is
<ErCiccione> *this
<dEBRUYNE> rehrarthebrearar: I'd agree for the CLI, but we should be a bit more lenient on the GUI
<endogenic> rehrarthebrearar: i don't think we need to use the word ideals. there are principles of how things work
<@smooth> actually the 'ideal' is maybe there is no core GUI at all
<@smooth> obviously it serves a purpose now
<dEBRUYNE> hyc: Yeah I envisioned something similar. Just a full page w/ trade-offs and an option to opt-out
<rehrarthebrearar> dEBRUYNE: meh,, the GUI isn't exactly a stellar example of UX period.
<endogenic> nor is the code itself
<dEBRUYNE> How is that related?
<+hyc> dEBRUYNE: sure. put a timer on the OK button, don't enable it for 10-20 seconds.
<rehrarthebrearar> well, I mean that the concessions for the increased UX don't matter a huge amount imo.
<rehrarthebrearar> It's still for power users.
<dEBRUYNE> The GUI is fairly easy to use as long as you have a fully synced daemon and wallet
<dEBRUYNE> Most issues are stemming from the daemon not being fully synced or the GUI lagging
<dEBRUYNE> My proposal addresses both of those
<rbrunner> The GUI is fairly easy to use as long as you understand what you do
<rehrarthebrearar> ^
<rbrunner> If you don't even a magic GUI and UX won't help you
<rehrarthebrearar> it's not necessarily intuitive, which is not the fault of the GUI per se, but a fault of cryptocurrencies in general, and Monero has added complexity.
<rbrunner> Exactly my opinion
<+hyc> lagging sounds like improper division of labor btween graphics threads and worker threads
<rbrunner> But we are not helpless against this fact, are we?
<rehrarthebrearar> If someone has done the research to get into Monero at all right now, they might as well do the research to run a full node or not? :D
<rehrarthebrearar> rbrunner, of course not
<endogenic> yes hyc
<dEBRUYNE> rehrarthebrearar: you're significantly diverging from the original discussion now though
<@smooth> what does 'GUI lagging' mean exactly
<rbrunner> See that people still completely freak out about change, for example
<+hyc> OK then - who is the target audience of the GUI?
<endogenic> hyc: that is the problem
<dEBRUYNE> smooth: I should've clarified that I meant that the system "lags", i.e., users are unable to use other processes properly
<rehrarthebrearar> with only one real desktop GUI in existence, doesn't the answer default to 'everyone'?
<@smooth> dEBRUYNE: okay, that is a matter of resource usage i guess
<dEBRUYNE> it mostly happens on Windows fwiw
<+hyc> rehrarthebrearar: maybe but I think that's unrealistic at this stage
<rehrarthebrearar> hyc exactly
<dEBRUYNE> smooth: It's probably related to hyc's observation, i.e., the GUI and monerod running concurrently
<@ArticMine> For many if not most people running a full node makes sense; however there are cases where it is not appropriate and this has nothing to do with how tech savvy the person is
<@smooth> dEBRUYNE: have you confirmed that reduced max-concurrency actually helps. maybe propose to change that default on windows?
<endogenic> how about a core GUI that actually mirrors simplewallet functionality
<endogenic> in its UI. then you can build it in a modular pluggable way so others can expand it in different ways
<endogenic> users are already familiar with spreadsheets for example
<endogenic> keep it simple
<endogenic> try not to abstract
<@ArticMine> I really like this idea. A GUI for power users
<+hyc> not sure this is a good time to design a brand new GUI
<dEBRUYNE> smooth: Yes, anecdotally though
<endogenic> it's not about designing a new GUI
<endogenic> it's about using the existing simplewallet design
<endogenic> and just plopping the same access into a GUI kit
<@smooth> dEBRUYNE: it seems like a reasonable change that could help things independent of the remote node issue
<endogenic> the whole point is, anytime something is added to simplewallet, even a dev should be able to design how to add it to the GUI
<dEBRUYNE> smooth: It also occurs on mac os x, but I've seen it happen less often
<+hyc> lowering max-concurrency to something like cores/2 is not a bad idea
<dEBRUYNE> Of course this could be explained by there simply being less mac os x GUI users
<+hyc> unfortunately, "max-concurrency" is a lie. monerod spawns tons of threads completely independent of this setting
<endogenic> yup..
<rbrunner> Hmm, that may be more difficult than you anticipate. I was thinking about how to add my own MMS to the GUI and really did not get very far
<dEBRUYNE> smooth: Yeah I'd agree
<dEBRUYNE> hyc: Only for the GUI or?
<dEBRUYNE> Because running monerod separately usually doesn't produce any issues
<+hyc> dEBRUYNE: in that case I have no idea what's up
<+moneromooo> It's *worker* threads. Other threads are typically mostly idle.
<dEBRUYNE> hyc: With monerod separately I meant monerod with the GUI closed
<+hyc> right
<dEBRUYNE> So this probably still applies -> <hyc> lagging sounds like improper division of labor btween graphics threads and worker threads
<rehrarthebrearar> Alright, any further discussion on what dEBRUYNE has brought up?
<endogenic> apparently not :P
<dEBRUYNE> hyc: Btw, the GUI allows the user to run the daemon in the background upon closing the GUI
<dEBRUYNE> Perhaps we could add some more information there on how it would benefit the network etc.
<+hyc> that's helpful. as long as it also makes users aware of that
<+hyc> right
<rehrarthebrearar> 4. Code + ticket discussion / Q & A
<rehrarthebrearar> anything for this? moneromooo around to field questions?
<iDunk> < rehrarthebrearar> Ok. :P 4. Code + ticket discussion / Q & A
<+hyc> is there going to be a 0.12.3?
<+hyc> I mean, we've merged quite a few bug fixes into master recently
<endogenic> lol dEBRUYNE
<+moneromooo> That depends on whether the pony can find the strength.
<rehrarthebrearar> right iDunk, but then we peddled backward a bit I thought
<dEBRUYNE> endogenic: ?
<endogenic> oops sorry that was iDunk
<dEBRUYNE> :-P
<rehrarthebrearar> but ok, if we feel that's been done we can move on
<rehrarthebrearar> 5. Any additional meeting items
<+moneromooo> I have one thing about 4011: if anyone doesn't mind switching their db to v3 (that is, not being able to use a master/v2 branch after that), testing all of 4011's SSL cases would be nice ^_^
<+moneromooo> Also, I don't know alot about SSL, so someone who does feel free to tell me what config problems need fixing.
<+hyc> that PR has a ton of other commits in it.
<+hyc> no way to trim that down?
<+moneromooo> Yes, because it doesn't apply to master until the previous ones are merged.
<+hyc> ok
<@ArticMine> I have to leave now.
<+moneromooo> But luigi's working on that (thanks)
<selsta> I got a suggestion: changing the db-sync-mode once a node is fully synced up so people don’t corrupt their db when they do something bad
<endogenic> ttyl ArticMine
<+moneromooo> It is done.
<+hyc> selsta: current code already does that
<selsta> oh okay lol seen people still complaining about this, maybe they are talking about past experiences
* TheoStorm (~dnaleor@host-lzquwqj.cbn1.zeelandnet.nl) Quit (Quit: Leaving)
<+moneromooo> It was buggy till recently. And not yet merged either I think.
<endogenic> does anyone ever think about how cool it would be if we had library builds of monero that we could link to?
<endogenic> or that we could transpile or bind to from other languages?
<endogenic> anyone else..
<+hyc> if everything were in C, you could already bind to it from any other language
<+hyc> ... my usual anti-C++ rant ...
<endogenic> yeah well for that we need an actual C dev to do some work on it
* rbrunner (~rbrunner@dyn-cable-customer.158.38.138.91.yetnet.ch) Quit (Read error: Connection reset by peer)
<endogenic> i'm just trying to figure out if anyone actually thinks it's important
* rbrunner (~rbrunner@dyn-cable-customer.158.38.138.91.yetnet.ch) has joined #monero-dev
<oneiric_> think it's important, not enough C experience to do it right
<endogenic> well we don't need C++
<endogenic> we can just start with what we have now if it's teased apart
<endogenic> people don't build it in a teased-apart way right now
<endogenic> so they must not think it's important
<endogenic> GUI dev shouldn't require another API layer on top of wallet2 for ex
<+hyc> GUI should have just been built on top of wallet-rpc
<endogenic> lots of things go into making GUI dev complicated
<endogenic> it's not that complicated for me though
<+hyc> but that's already a lost cause
<+hyc> are we wrapping up?
<rehrarthebrearar> alright, winding down now
<rehrarthebrearar> yes
<rehrarthebrearar> 6. Confirm next meeting date/time
<rehrarthebrearar> July 1st, 17:00 UTC
<endogenic> phew that hurts
<rehrarthebrearar> And I think we done here if there are no objections. Please feel free to continue conversations that have been brought up in the meeting in the appropriate channels
<rehrarthebrearar> thanks everyone!