Monero Dev Meeting Note Highlights – 2017-06-25
Logs
351 lines
tewingetI know it's a bit out of order, but I can go ahead and share what updates I have while we wait for fluffy.
moneromoooplease do :)
tewingetI'm pretty knackered, so I'm afraid I won't have much useful input on the other topics anyway
tewingetalright, so apart from a couple minor tweaks I still plan to do (but which are by no means necessary I think), the daemon zmq rpc server should be ready to merge pending approval. There are a few things I'd do differently were I to start again from scratch, and may go back and change later, but it's in pretty decent shape overall I think. Still a good handful of unimplemented calls, but they're mostly fill-in-the-blank and low priority imo
endogenicnice
tewingetthe wallet zmq rpc client (well, not explicitly wallet-only, but for the wallet) is coming along, but not quite to that same point.
vtnerdyeah I had some comments about the design at some point, but I think it something that could be discussed later
vtnerdplus moo may have disliked my C++ suggestions (for a good reason)
tewingetas far as I can tell, I'll be able to get what I set out to finish finished by the end of the month as planned.
vtnerdso the first cut should be able to push out when a new block is received ?
tewingetvtnerd: yeah, some of your suggestions are the things I considered doing differently, but the amount of re-doing didn't seem to be worth it short term.
peroim a bit concerned that there has been no new code merged and leaves us with potential for another month or so turnaround on the next iteration
tewingetso {block,tx}notify is something I'd like to have a prototype of working by end of month, but I don't think I'll have a polished solution quite then. First week of July though.
vtnerdyou did merge my one PR, right? it cut down on some boilerplate type specifying …
tewingetpero: check again ;)
tewingethadn't pushed stuff up yet because I had to do an annoying rebase
knacccdoes zmq result in initial daemon sync speedup at all? or is it mainly for robustness
tewingetvtnerd: I believe so
vtnerdok, I will follow that closely, because it matters for the mymonero backend
vtnerdor rather it helps the mymonero backend
medusahow is that progressing vtnerd ?
medusawe talk sometimes about it, since the GUi now run on android with lightwallet support, but the mymonero node tis the only node we can connect (for now)
tewingetI'll update here again some time Tuesday, by then I think I can have the wallet client stuff in good shape, giving me the rest of the week to work on notify stuffs.
vtnerdyour question is too open-ended - what exactly on the backend did you hope to hear about?
perowell i dont really know what im looking for but i see some commits from may7 have been added
tewingetlemme look and make sure I pushed pero
dternyakyou did - github just says may 7 cause its the oldest of your new commits
medusawhats the overall state ? is it soon finish, just started
dternyakthe newest is from 1 hour ago
vtnerdI've got a written but not completely tested method for rapid tx querying via lmdb (instead of the mysql), and a re-worked algorithm that needs polishing to reduce write blocking on mysql (faster importing)
dternyakthat for mymonero vtnerd?
vtnerdthe x86 ASM (assembly wallet importing) is now live for about a month I think
perook so thats new stuff that can be reviewed?
vtnerdnone of this has been pushed to mainline
medusacool. cant wairt to run it myself
Jaqueevtnerd: i think medusa was referring to the updates in monero daemon.
vtnerdthe x86 ASM stuff is closest, but I wanted to confirm that it was public domain code
Jaqueebut afaik that work hasn't been started yet?
tewingetpero: yeah. also, weird that the commits I had to touch up for rebase didn't get new timestamps…
vtnerdright, the biggie is that I did part 2 of fireice-uk FFS for the mymonero backend
Jaqueeso openmonero will be the other option
Jaqueevtnerd: nice!
vtnerdor maybe it was part 1, I forget which. either it has been live (fluffypony would have to confirm)
vtnerdit doesn
vtnerddoesnt touch the existing crypto code, its all cmake magic (sorry hyc/moo) so its just a matter of some polish and reviewing licensing
vtnerdtheres lots more speed improvements that can be done, but it will be interesting to get feedback from people first
vtnerdric also discussed with me ways to open source the backend, but its probably a reworking that will get open sourced, not the current version
vtnerdsomehow the mysql dependency will have to be punted before merging into mainline
vtnerdsorry for hijacing this tewinget
tewingetvtnerd: no worries, I was pretty well finished anyway :)
tewingetjust hanging around to answer any questions for a bit longer before I go pass out
vtnerdI mean right now my main concerns are performance and better mempool integration on the backend (not necessarily merging into mainline)
medusamhm
vtnerdso that anyone using the newer UI stuff with the backend should have a better experience (hopefully)
moneromoooJaquee: do you want to tell us about your work ?
moneromoooWell, then. Anyone else doing interesting stuff who want to let us know ? :)
Jaqueesure. i've been working on adding lightwallet support to GUI. There are two PR's up already that will need some more work before they can be merged
moneromoooSorry.
Jaqueei've also been working on the android and ios builds simultaneously
medusaalso Jaquee fixed the nasty ominous "black screen" bug in the gui
Jaqueeyeah. that too
vtnerdlightwallet == GUI that uses openmonero/mymonero backend ?
medusayes
Jaqueeexactly
medusathats why i asked
medusaits all ready, owrks like a charm
medusasoon*
Jaquee:)
pigeonsi wonder what kind of load that puts on the remote load per user
pigeons*remote node
perotewinget: communication has been one of the fails here i believe so it would be helpful if you could add some note in the PR wrt progress and if there's anything someone can do now
tewingetpero: I can do that, sure.
vtnerdpigeons: thats what Im trying to improve
Jaqueepigeons: the lightwallet use mymonero/openmonero backend, not regular remote nodes (yet)
Jaqueeand btw. my ffs has come to an end. Thanks for all contributions!
vtnerdyeah so eventually the pie-in-the-sky approach is a kovri pubkey that your phone connects to ?
medusa<3
pigeonsyes i mean on those mymonero/openmonero nodes
Jaqueei'll probably put up another ffs soon
unknownidswooo
binaryFateJaquee dooooo it!
unknownidshope ya go
unknownidsdo*
unknownidsoh god
vtnerdpigeons: ideally people would be running these nodes only for a few people that know personally (IMO)
unknownids:(
pigeonsvtnerd: yep. if the only node that people can connect to is mymonero, they will quickly kill it
medusafor now it is, but mymoner still charges a fee. without paying, so scanning
vtnerdcome on pigeons, gotta have some "swag" … mymonero can handle the load
Jaquee:D
perothanks tewinget
endogenicvtnerd++
moneromoooWell, as for me, I added some fuzz testing. Turns out erikd had also started looking at that as well.
moneromoooIt's running on GCC, not CLANG, though.
moneromoooAnyone else ?
knaccckenshi84 has done fantastic work on implementing the subaddress scheme. There is now the concept of a wallet containing multiple "accounts", each with multiple "addresses" (a.k.a. subaddresses). It's now only a cat's whisker away from being ready for code review. https://github.com/monero-project/monero/pull/2056
moneromoooVery nice stuff ^_^
medusacool
Jaquee^^
medusahow about release ? dont we need to do a testnet fork in advance ?
medusadou you guys have a rough timeline in mind ?
knacccsubaddresses are a wallet only change
moneromoooFor subaddresses, I don't think we'd need to.
sgpJust joining now. Thanks Jaquee and kenshi84 (and others of course)
medusano i mean in general
medusaseptember fork is not far away
medusawhen do we release ?
moneromoooWell, the only thing we'd need we don't have yet is the smaller range proofs, but I think we're kinda screwed now.
moneromoooAll the rest is active on testnet I think.
knacccwhy screwed? it's too late for the range proof reduction to make it into the september fork?
moneromoooSeems so.
ArticMineThat was my question also
moneromoooAh, there was also a question of whether to bump minimum mixin higher than was planned.
moneromoooIt was supposed to go from 2 to 4.
binaryFatewho's working on range proof reduction?
knacccluigi
ArticMineSo we are looking at 2018 for the smaller range proofs?
moneromoooapologizes for having mugged luigi for multisig help
medusawhats exactly the issue ? too little time for now?
knacccto be fair, it's not the kind of thing that any mistakes can be afforded to be made with
medusahe should just stop watching charts all day ^^
moneromoooWas there anything else than smaller range proofs, 2->4 min mixin, and mandatory rct for next fork ?
knaccc something has to happen to get some consensus on the mandatory ring size change
perothere isnt consensus?
knaccci've suggested 20, surae said he doesn't have a problem with that, but not much other commentary.
moneromoooI've not seen olarks for a while. Anyone has ?
knacccthe thread went dead https://github.com/monero-project/monero/issues/1673
peromaybe we should schedule a townhall type irc meeting
peroinstead of intermittent back and forth in the ticket
knacccother people just need to make their opinions known, not that many people have done so
medusai cant judge waht the min mixing should be, but would like to see the pole that can judge it discuss it ofc
pero^
medusaso i trust the experts
moneromoooAnyone else wants to say anything ?
medusai think the miimum mixing is an important question. i cant help u guys discuss it
knaccc2017-06-23 12:54:59 surae well, if raising the ring size from 3 to 20 results in 15% larger transactions, i have no problem endorsing increased minimum mix-ins even without taking churning into account. i've advocated that since the chain reaction paper, but lacking a specific attack vector, it was hard to justify the cost…
medusabut it shouldnt be done last minute
medusanow is the time
sgpI think most people including me are ok with any reasonable number >10
moneromooo15% means ~30% once we have the smaller range proofs.
knacccmoneromooo true. it's the price to get privacy in the E->A->B->E scenario unfortunately, in my opinion.
iDunkWhy don't we just ban Eve and be done with it?
knacccbecause it's how users make purchases while avoiding XMR/local currency exchange rate risk
knacccwhich according to a particular vendor that posted on reddit was the almost exclusive pattern of behaviour of his clients
knacccwhat i posted above btw was surae's comment, not my comment to surae
iDunkWhich you probably solicited?
knacccrubber hosed.
medusaok guys, is that it ?
knacccthe premise is that my simulation shows that an EABE attack can only be mitigated if the anonymity set can reach 80,000 inputs. And that's not possible without intermediate transactions, and it'd take excessive intermediate transactions to achieve this unless the mandatory ring size is much higher than it currently is
knacccit's a long github thread, I'll leave you all to read it at your collective leisure :)
Sources and notes
- Meeting log: Overview and Logs for the Dev Meeting Held on 2017-06-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.