Monero Dev Meeting Note Highlights – 2017-02-19
Logs
351 lines
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
hychola
fluffyponyso greetings
fluffyponyhi!
ArticMinehi
tewinget(here)
vtnerdalso present
moneromooohi
tewingetI'll be sorta afk for the next 5ish minutes, but I'm around.
fluffyponyok
fluffypony2. Brief review of what's been completed since the previous meeting
fluffyponyso
fluffyponysecond meeting of the year
fluffyponyand we've been pushing ahead solidly
fluffyponywe've had a bunch of PRs by newcomers
jollymortonce you go solid state you never go back
fluffyponyincluding tpltnt, and IPGlider has also pushed a few PRs
fluffyponywe switched to EasyLogging++, which is a pretty big change
fluffyponyand MoroccanMalinois made Android builds happen
fluffyponytdprime also pushed their first PR
fluffyponyand then the usual rash of PRs from moneromooo, vtnerd, hyc, NanoAkron, and Jaquee
fluffypony(I've probably missed someone)
pigeonsreveler with the background mining
hycrevler
fluffyponyyes thanks pigeons
fluffyponyoh and pigeons had a PR too
jollymortkenshi84 disposable addresses
fluffyponyand kenshi84
fluffyponyok - anything else major I missed that happened in the last two weeks before we move on to 3?
moneromoooAll the new one time address stuff from knaccc, randomrun, kenshi, jollymort.
knacccyes subaddresses are back!
moneromoooAnd luigi.
fluffyponymoneromooo: I was going to get to that in 3
hycok, sounds like we move on to 3
fluffyponysince it's in the MRL repo
fluffypony3. Code + ticket discussion / Q & A
jollymortI wasn't following that discussion, focused on study on fees atm
fluffyponyok so there have been a few long-form discussions going on in various issues
jollymortalso the one for ring size
fluffyponyyeah the ring size one is one I wanted to bring up
fluffyponyI think the discussion has mostly been positive, nobody's gotten crazy out-of-hand or anything
fluffyponyit is a complex topic
fluffyponyand I think that we have enough time to figure out a good route forward
fluffyponydoes anyone have an objection to it continuing in the GitHub issue?
hycseems like all the context is there
hycso it should continue there
jollymortI feel like it's more suitable for an issue under MRL, any thoughts of moving it there (if possible)?
jwintermI haven't been following the issue too closely, but is there still some sentiment building around fixing ring size for all txs?
fluffyponyjollymort: I think the GH issue is fine, it can kinda be anywhere, but if we're going to turn that into a publication that explores the various options and reasons for recommendations then it would develop as PRs to the research-lab repo
jwintermgoes to github
jollymortI meant, keep it as a GH issue, but under another repo so it doesn't get buried under all code/bug related issues
jwintermas someone not following the issue, it does kind of get lost in the noise with 164 open issues
jwinterm#1673?
fluffyponyyeah it would be nice if GH let you subscribe to just a single issue
fluffyponyI'm not opposed to moving it to the research-lab repo
fluffyponyhow would we do that tho
hycno idea
perosomeone creates a synopsis of where the discussion is at currently in the new ticket and links back to older ticket
hycyeah, new text
hycwith @mentions of original participants
fluffyponyok I'll suggest it in the thread
fluffyponythen on the topic of discussion
fluffyponyI'd like to encourage us to also take some Q&A / discussion items to StackExchange where we can
fluffyponyand to redirect people who open issues to just ask a question to StackExchange
hychm, I would expect that SE is for "settled" questions
fluffyponySE is a great place for canonical information that is updated over years
jollymortI'd just like to add that SE is not really a format for discussions, more for things with an actual answer existing
fluffyponyhyc: nope, anyone can edit an accepted answer with new information
jollymortlike hyc said
jollymortthere's SE chat, though - which nobody uses
fluffyponyjollymort: some of the questions on GitHub issues are perfect for SE
jollymortsure
fluffyponyhttps://github.com/monero-project/monero/issues/1751 as an example
hycmonero clone?
fluffyponyhyc: probably, I thought that too
fluffyponybut that's a good question for SE
fluffyponywhich also has a larger group of answer-ers than the GH repo
taushetit is already answered though, sort of http://monero.stackexchange.com/questions/2886/how-can-i-create-a-new-monero-genesis-block
fluffyponytaushet: yes but SE has tools to close as a duplicate and redirect them to the answer
fluffyponyand moderators can do that without us needing to
taushetfluffypony - agreed. also the 'issue' was not so much an issue with the code as much as it was a question but a user/tinkerer who could not get something to work
taushetanyway
fluffyponyyeah exactly
slacknanoakronWhat if someone went through and opened parallel SE questions for all those types of question, redirected the original asker, then we shut the issue?
hycsounds good
fluffypony@NanoAkron yes that's exactly my recommendation
slacknanoakronOk I might see what I can do if I get any free time tonight
fluffyponythen you even get SE karma or points or rep or whatever it's called
slacknanoakronWoo!
fluffyponygamification ftw!
fluffyponyok anything else under Q&A ?
hycspecific tickets?
hyclike 0MQ PR?
fluffyponyyep I believe tewinget said he had to check if it was working with RingCT
fluffyponytewinget: ^^
slacknanoakronAny thoughts about 0.10.2?
fluffypony@NanoAkron yes
fluffyponywe've been discussing it
fluffyponybecause it will coincide with beta 2 of the GUI
slacknanoakronOh nice
fluffyponyas we're marrying daemon / GUI versions
slacknanoakronMakes good sense. Will #1746 be addressed too?
jollymortdo you intend to code in stuff for the next HF in 0.10.2?
slacknanoakronI.e. Auto starting daemon
fluffyponythere are a few things that need to be done in the daemon / GUI before the next release
tewingetsry
fluffyponyjollymort: no
fluffyponywe only have to finalise that by like July
tewingetjust got my second monitor back from a friend, was setting it up real quick.
jollymortok, thanks
fluffypony@NanoAkron I don't see why we can't make sure 1746 is sorted, Jaquee any thoughts ?
tewingetso Snipa was kind enough to chuck a battery of tests at my zmq branch, which is great. It seems there are a couple things I need to look at, which is expected, but his tests seem rather comprehensive, so once those are passing it should be good to go.
moneromoooDoes this keep a backward compat layr for the current JSON API ?
tewingetmoneromooo: currently it neither replaces nor modifies any current RPCs
slacknanoakronEsp since the number of rpc commands has increased
fluffyponymoneromooo: long term yes - the current JSON API will be in its own binary, like monero-rpc-server, and that will use 0MQ to communicate with the daemon
tewingetbut also short-term yes because I haven't done anything to the existing RPCs
slacknanoakronI heard it would be passing plaintext commands/JSON and not binary. Or am I mistaken?
tewingetnanoakron: that is correct, everything is marshalled via json
tewingetthis is so that higher-level languages have no problem using the RPC
pigeonsor jaxx :P
tewingetas the (de)serialization takes no time at all compared to the computations/fetching
tewingetpigeons: hope springs eternal
hycthis is for wallet-style client RPCs only then
slacknanoakronDoesn't that mean that there are now two sets of commands to maintain in sync - JSON-RPC (won't be deprecated) and JSON-over-ZMQ?
fluffyponyJSON-RPC will be deprecated for the daemon
fluffyponywe won't add new RPC commands to it
fluffyponyJSON RPC for the wallet will continue to evolve and exist
fluffyponybecause web apps rely on it
fluffyponycommunication with the daemon will be relegated to 0MQ only
moneromooo!bookie no-json-rpc-added-ever-again yes no
slacknanoakronBut in JSON format
moneromoooaw…
fluffypony(eventually)
fluffypony@NanoAkron yes
fluffyponyso existing apps that interact with the daemon, eg. pool software, can continue by adding a 0MQ library
fluffyponyand modifying any calls that have changed
tewinget(which won't be many, there were just a few that seemed silly in some ways, and changed accordingly, but none of that is set in stone)
fluffyponyanything else?
fluffyponyor I guess we can include that in the next item on the agenda
fluffypony4. Any additional meeting items
slacknanoakronNeigh
fluffyponylol
fluffyponywe should use HAY and NEIGH instead of ACK and NACK
slacknanoakronLol
tewingetI'll keep updating over the next couple days, fwiw. Gotta get with Snipa to see if he can make a couple of modifications to the tests for me to make issues track-down-able, but he's afk until tomorrow.
moneromoooHmm, range sig reduction… multisig… fee formula change…
slacknanoakronYes
pigeonsSnipa: are these tests in your github?
fluffyponyoh I have an item for brief discussion
jollymortit's not just the fee, penalty needs tweaking
fluffyponyas everyone knows, the dynamic block adjuster isn't adjusting very well since the txs became larger
perosnipa is afk until tmrw iirc
jollymorteither by increasing the min. blocksize, or having a transition formula
fluffyponydoes everyone think we should leave it as-is until September, with the occasional backlog
fluffyponyor should we have some intermediary hard fork ?
ArticMineWe may need one
hycIf we have a fix now, would be nice to deplot it sooner
hycdeploy
slacknanoakronBut it has to be smart enough to account for potential future changes in range proof and therefore Tx size
jollymortit accounts :)
peroseptember is a long time away
slacknanoakronAs well as ring size. Txes will become much more standardised in size and non-parametrically distributed
fluffyponyok I think that's reasonable consensus, as soon as we have something workable we'll put it out to the community as a hard fork and see how they feel
slacknanoakronSo medians etc may not make statistical sense
DaveyJonesyou could HF at around the time when originally the ringct hf was supposed to happen
ArticMinenanoakron We are looking at a fall in tx size?
slacknanoakronHopefully. Size would fall will range proof improvements, but distribution of sizes would flatten with ring size standardisation. Parametric statistics would no longer apply.
fluffyponyDaveyJones: that's in March, too soon for a planned fork
slacknanoakronSo adjusting based on moving medians would be meaningless. We'd need to deploy alternate statistical tests.
moneromoooCan you explain that ?
fluffyponyok
fluffyponyanything else before we close the meeting ?
fluffypony(we can discuss specifics after the meeting)
slacknanoakronEven now with a mix of rct and non-rct transactions the median is meaningless because the size distribution is non parametric
jollymortit's some typical size which is most important, currently at 13kB
hyccalculate two separate medians. one for rct and one for non-rct.
jollymortdoesn't matter if it's +/- 1kB
slacknanoakronIt's instead bimodal
hycsounds like we're done with the meeting side of things then
jollymortI mean, if you roll out some change to TX format, you already know the next typical size it will cause
fluffyponylast item is the next meeting time
jollymortand you will need to HF anyway, so all you'd need to do is adjust one parameter for the dynamic blocksize/fee
fluffypony2 weeks from now
fluffyponyMarch 5th
hyccool
fluffyponyI will be on a plane to London, but should have wifi and should be able to attend the meeting
fluffyponythanks guys
Sources and notes
- Meeting log: Overview and Logs for the Dev Meeting Held on 2017-02-19, 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.