Monero Dev Meeting Note Highlights – 2017-07-23
Logs
351 lines
serhackOh
serhackWhere is meeting? Here?
pigeons1[m]Should be yea
Jaqueeanyone else noticed a memory leak in monerod from master?
balambalaHello there
moneromoooerikd did.
serhackJaquee: oh, is memory leak dangerous?
moneromoooIf you have hints, they're welcome.
rehrarso…
tewingettalkaboutdangedol…yo, man
Jaqueeno hints unfortunately. got an OOM crash after running for an hour or two. could've been something else
Jaqueei will find out soon enough
rehrarfluffypony ArticMine luigi1111 othe luigi1114 moneromooo hyc anonimal tewinget pigeons Jaquee
Jaqueedid i hear meeting?
Jaqueeo/
ArticMineHi
rbrunnerGrüezi mitenand
rehrarit seems fluffypony isn't here to run the meeting, or he's on his way. Anyone heard from him?
tewingetnegative
rehrarwell, I'm obviously not a dev, so I can't help with the conversation, but the agenda is here: https://github.com/monero-project/meta/issues/97 it's pretty normal
vtnerdfluffypony is in las vegas according to his tweets
rehrarright, he's at defcon
rehrarprobably gambling
vtnerdor no wait, was a few days ago have kept up with that
rehrarI'm obviously not qualified to facilitate the things in this meeting, but I can just put each item to discuss, unless someone wants to volunteer
perovolunteers moneromooo
rehrardo it!
tewingetI would, but I've tried and I'm shite at it >_>
tewingetpero: didn't you say you wouldn't be present for the meeting?
vtnerdmoneromooo is usually the backup bot
peroyea but my plans changed
moneromoooSo…. ladies and gentlemen… let's start with…
moneromoootewinget
moneromooo:)
tewingetlol, ok
moneromooo0MQ's kinda ready now, right ?
tewingetthe daemon's rpc server stuff should be ready to merge, yes
serhackHello
perowhat's still outstanding if that's ready?
tewingetit's not perfect, but "the great is the enemy of the good" and I've structured it such that it doesn't affect anything if something's wonky unless it's crashy…which I haven't seen any evidence of
serhackPoint 1? Greetings?
moneromoooThat's good. Can you put a "how to start monerod with 0MQ RPC" in the PR ?
unknownidslol serhack
tewingetI still need to do testing on the wallet modifications and the rpc client interface.
tewingetmoneromooo: if it builds, it runs the server :)
tewingetthe cli flags are self-explanatory
moneromoooAh, then "how to start monerod with original RPC" :)
tewingetalso the same
tewingethence it's fine to merge
moneromoooIt runs both at once ?
tewingetyes.
moneromoooCool. OK.
tewingetthis is to avoid really really messy backwards compatibility
tewingetlater there may be a translation process that can receive old rpc requests and translate/forward them, but for now I think this is good.
moneromoooAnd the missing bits and bobs are fixed (for example, random stuff in getinto) ?
tewingetyeah, there's one thing I needed to get clarity on, but it's not a big deal
moneromoooShoot.
tewingetthat's the get peers bit, as you seemed to imply that this should be changed, but afaict I've mirrored the old/existing RPC in this and it hasn't changed. I mean, I haven't implemented the call anyway, but the struct for the RPC message is what I'm talking about.
tewingetmay as well have that be what it should in case some intrepid young lad gets bored and wants to add that call.
tewingetI've focused on the calls that the wallet uses for now, hence that one's been left for later.
moneromoooAh, peers used to be uint32_t (IP) and uint16_t (port) but they're not something (host) and uint16_t (port).
moneromoooOK, sounds good. The missing calls can be added later, that's fine.
peroso wallet mods/client interface are largely done too?
tewingetright, but if you look at the GET_PEERS call in the old RPC it's still using uint32_t IP and uint16_t port, unchanged.
tewingetpero: yeah, it's "done" but I found an issue with synching a testnet wallet around block 900k or so, so there's a bit of debugging to do
tewingetbut the code is in place, just needs testing.
tewinget#2044 doesn't need as much testing before merge (just make sure it doesn't crash the daemon) because it only adds optional functionality, it doesn't change any existing functionality
tewingetbut #2185 needs more testing because I completely refactored how the wallet uses the RPC
moneromoooOK, I will check the old GET_PEERS.
tewingetthat's why I structured the PRs the way I did :)
Jaqueethere's some fuckery going on around 900k on testnet
Jaqueelots of reorgs
tewingetJaquee: yeah, I noticed that, and one of the chunks of blocks during sync seemed to break things. It'll take me a good bit of time to track it down because it's such a weird bug.
tewingetwhat I really need to do is figure out how to configure gdb to actually print things…I hate it when shit's inlined so gdb can't print it. or optimized out (I need to verify that debug builds are -O0)
perowould zmq even be responsible for a sync-related bug?
tewingetpero: no, the wallet on that branch bugs out in synching using the old RPC
tewingetit's something related to my refactor of how it uses the rpc.
perogotcha
sgpAny other questions or should we move on?
tewingetoh
peroyes i'd like to know what the next steps are here
tewingetright
peroi was alarmed to see that 10 days passed without zmq-related github activity
tewingetso I think merging #2184 and then #2044 now would be good.
tewinget#2185 will follow as soon as it's tested and working. all the code is "done" just gotta test it.
moneromoooAnyone wants to ask anything else about 0MQ ?
moneromoooNext: Jaquee ?
tewingetif anyone has questions in the future, just ask whenever
Jaqueewhat?
tewingetwell, after the dev meeting. carry on :)
moneromoooAnything about the GUI or light wallet you want to talk about ?
Jaqueeah =)
perodoes zmq have impact to the gui?
tewingetpero: the refactor of how the wallet uses the rpc does
Jaqueewell. i've been working on openmonero support the last days. making the wallet compatible with both mymonero and openmonero
Jaqueethere are a lot of new commits in the lightwallet PR
perothats outside of your scope too, i believe, tewinget
Jaqueehaven't squashed them yet
moneromoooYeah, all this reviewing is starting to kill me, there's a lot of stuff :D
Jaqueeunderstandable
moneromoooGood stuff though.
moneromoooEspecially that lovely subaddress stuff…
perothere will be a new gui release for september hardfork, Jaquee ?
Jaqueethe cli and gui releases are supposed to be aligned, so yes.
tewingetremind me after the meeting, there's one other thing that we'll need to think about before merging #2044 but we can talk about it later.
peroi am wondering if zmq making it into the cli codebase has been identified as work effort for the gui
peropotential work effort*
endogenicHey guys, fluffy got caught by timezone difference. Think he may be slammed at the moment but he may pop in to say what's up. Just fyi
peroand if some attention needs to be paid into that as the clock is ticking down
endogenicDid not mean to interrupt you
endogenicPero
tewingetgives fluffypony some hair of the dog
peros'ok :)
Jaqueei haven't really looked at tewingets new stuff, but afaik it shouldnt affect the gui that much.
serhackHey, I'm developing prestashop plugins
Jaqueethere are some rpc stuff in wallet api, but most of it arent used
perook cool just putting it out there
serhackI dont know if after that I will write another ffs
tewingetI've refactored those bits as well :)
Jaqueegreat =)
moneromoooanything else, Jaquee ?
Jaqueeyes. but i guess i need fluffy to answer it
Jaqueei was thinking about mobile release and testing
moneromoooOK, we'll be back to you when/if he's around then ?
Jaqueeif someone is working on apple store and play store stuff
Jaqueeyes. i'll ping him
moneromoooOK. Thanks.
Jaqueeok. that's all
moneromoooserhack: so, tell us more about what you're doing and what's your progress :)
Jaqueeoh. one more thing. sorry
moneromoooSure
moneromoooone minute serhack please :)
Jaqueevtnerd: what's the status on the openmonero/mymonero integration?
Jaqueein monerod
Jaqueedo we have a plan for that?
vtnerdnot yet really
Jaqueeok
vtnerdother than I would like to have multiple processes for this for security purposes
vtnerdwhich is what the backend is doing, but I need to make IPC between them easy
Jaqueesounds like a good idea
Jaqueeiirc fluffy said in then january meetup that the backend was going to be open sourced. Any timeline for that?
vtnerdnot at all, that has not been my direct focus
vtnerdI suppose whenever the backend is in better shape :/
Jaqueeall right. thanks =)
Jaqueemoneromooo: done
vtnerdmore recently I've been working on the serialization explosions
Jaqueesounds fun
Jaquee:P
vtnerdso I'll have to make a push to start encoding a version in the archive header so we dont have this issue again
moneromoooWould be nice to get them fixed, or at least ensure they're not exploitable, since cold wallet comms use that.
vtnerdand try to convince the serialization author to merge something before the 1.65 release
vtnerdeh, thats the issue I would to see corrected with serialization. I dont see another way to handle it
vtnerdbasically with better versioning in the header we get less bug defects, but crafting a file is problematic without changes within boost
Jaqueei've missed this. what's the issue?
moneromoooCrafting would likely not be defeated by versioning though.
moneromoooJaquee: a crash in boost loading a serialized file.
Jaqueeah. thanks
vtnerdour situation is very similar, except its boost::multi_index is doing it internally. a change by moo on 5/27 changed the serialization type
vtnerdmoneromooo : that sentence was worded similar. if you meant that its still possible to craft a file if we reject _newer_ versions, then I agree
vtnerd*worded strangely
moneromoooI just meant a crafted file would claim whatever version leads to the exploit, which is likely whjayt you also meant.
vtnerdright you can pretty much do whatever if you can modify the file being read
moneromoooOK, we're done on this ?
Jaqueeyes
moneromoooserhack: go ahead then, tell is about your plugins work :)
vtnerdas far as mymonero goes, the focus is not yet open sourcing but since its on my mind during the refactor it shouldnt be hell
vtnerdhopefully
endogenicVtnerd… a silent hero of monero…
moneromoooHmm, he seemed keen, but also seems not around now.
moneromoooendogenic: do you have something you want to talk about ?
endogenicNah not as yet. Soon(tm)
moneromoooAlright, thank you.
sgp@serhack can always talk about it later, but I know he may want to discuss a way of covering plugin maintenance costs
endogenicReally pleased about the lightwallet support
moneromoooSo, mooo now:
Jaqueeendogenic: is the mymonero backend issues holding back the mobile/desktop releases currently
Jaqueethat can wait. go moo
endogenicNah it's not
Jaqueek
moneromoooI worked on faster/leaner node sync (sync branch) as well as multisig (multisig2 branch right now)
moneromoooBoth welcome testing :)
moneromooomultisig2 has RPC, but that's not been tested much yet, so don't really expect it to work. Wallet commands are what's ready.
moneromoooNext… who could have somehting to say…
moneromoooAnyone ?
rbrunnerI have something
rbrunnerIs something planned already about putting the Windows installer for the GUI wallet into service i.e. at the end offering the Setup.exe as a download on getmonero.org?
moneromoooknaccc: kenshi84 ?
Jaqueerbrunner: yes, most likely in next release
rbrunnerSeptember then, right?
Jaqueewhich will happen somewhere between now and hardfork
Jaqueeyes, around sept
rbrunnerOk. I hold my breath :)
Jaquee:D
perodoes the mooning network hash warrant any discussion
moneromoooIf you have something to say about it… sure.
peroeh
perowas hoping someone else might have some insight
pero:)
Jaqueei've noticed the block time has been pretty inconsistent lately
Jaqueewas thinking it was because the variance in hash
Jaqueelot's of 5-10 mins gaps
peroit seems to me that botnets could very well be pricing out 'regular' miners
moneromoooAs long as it's several distinct ones…
peroright
perocan we tell how centralized the mining is? real centralization could be obfuscated by pools
sgp@pero ideally the discovered botnets can have the addresses searched in the pools to determine the hashrate
moneromoooPools might be able to tell, since they know source IPs (unless proxied). You'd have to trust the pools to tell you the truth though :)
peroyea…food for thought i guess…
tewingetdammit, now I have thought for food…
moneromoooThough if hash is from a botnet, IPs don't really give you much.
sgpOne question: the release is in September. What window do you want to give everyone to upgrade?
moneromoooI'd been wondering whether some non-profit oriented large miner might want to crowd out miners.
sgp*hardfork
moneromoooUndecided yet. But hopefully more than a week :/
knacccnot sure if this is the right time to suggest it, but in preparation for subaddresses, the GUI and CLI should probably recognize the subaddress and integrated subaddress prefixes and display a message that subaddresses are not supported yet, and that they need to upgrade to send to such addresses
moneromoooThere's not much that needs to go in next fork, so that should not be much trouble.
sgpDid we ever agree on the new minimum ringsize?
moneromoooThat's not a bad idea at all.
moneromoooNo.
moneromoookenshi84: do you want to make a preliminary patch for this ? It'd include your existing parsing changes, plus error messages on use.
moneromoooI don't think kenshi84's around now.
moneromooosuraeNoether: what about you ? Tell us about your research.
suraeNoetherah, well, good timing actually
sgpHow should we actually reach consensus on the new minimum number? Running out of time to decide.
sgp@surae I don't mean to interrupt you though, carry on :)
suraeNoethernp, as far as minimum ring size goes, and mitigating EABE… a lot of this would be solved with efficient ring signatures and range proofs.
suraeNoethertoday, I'm coding up some examples of O(sqrt(n)) ring sigs and some efficient range proof algorithms to compare sizes with current set-ups
suraeNoetherthe idea is, if we can manage to fit a ring size of, say, 150, in with each transaction, I don't care how much computing power you have, you're going to be spending a lot of time analyzing monero's blockchain
sgp150? Wow
moneromoooKovri meeting starting in #kovri-dev for those who want to follow both.
suraeNoetheri would prefer orders of magnitude
suraeNoetheri would prefer a quarter million or more signatories per transaction
ArticMineany idea on the trade off ring size, range proof efficiency vs tx size?
moneromoooAll depends on the constants, doesn't it :)
knaccc\o/
suraeNoetherthat's what i'm looking into today, arcticmine and moneromooo, there's a cost to everything
vtnerdlol @ that compute time
pigeons1[m]Similarly I'm interested in exploring potential privacy drawbacks of not having a fixed uniform ring size
suraeNoetherso, I have some attack models for EABE. First order estimates suggest a min ring size of like 30 is necessary with 7 churns. Second order estimates suggest as low as 15 is good with a single churn. my third order estimate looks to be somewhere between those two? possibly with more in the ring size.
suraeNoetherpigeons1[m] this is absolutely something i'm also looking into
suraeNoetheri like the idea of a uniform ring size if the ring size is very large, say more than 10^2
suraeNoetherin a world where choices are allowable, a random (with minimum) ring size is preferable to any other given strategy
Jaqueedisrupting with a question: how do i run monerod with valgrind? i'm getting an "invalid argument" error on startup.
sgp@surae do you think a ringsize of 10 is far too low? I didn't expect to consider a jump from 5 to 150/100
Jaqueesrc/blockchain_db/lmdb/db_lmdb.cpp:71 Failed to open lmdb environment: Invalid argument
Jaqueetrying: valgrind /path/to/monerod
Jaqueeno args. blockchain in default location
moneromoooShould work that way.
Jaqueethat's what i thought too
JollyMort[m]in lieu of more research, enforcing some min. in the upcoming HF would be beneficial, no? 5 or 10?
Jaqueemoneromooo: https://paste.fedoraproject.org/paste/liZxIo25sun2z8d9YTDLbw/raw
suraeNoethersgp : in terms of security alone, min ring size 10 would be "safe" for a year or two. but would have how much cost on the blockchain, and how much cost in terms of adoption? in lieu of more research, a larger ringsize is only preferably in terms of security, not necessarily in terms of adoptions
perowe already enforce a minimum i believe
suraeNoetheryep, 2
JollyMort[m]3, no? "mixin of 2" iirc
suraeNoetheroh ringsize 3, mixin 2
suraeNoethersorry, terminology
sgp@surae do you have any major current concerns with 10? Do you think it is reasonable for now pending research?
suraeNoethermy concerns come from the cost to the size of the blockchain
suraeNoetherand hence adoptoin
suraeNoetheradoption*
sgpafaik the difference between 10 and 5 is very small
suraeNoetheri advocated large ring sizes years ago, but there is a cost to the blockchain, a huge cost
suraeNoetherwe aren't discussing 10 vs. 5 we are discussing 10 vs. 2
pigeons1[m]Better to wait for research instead of arbitrary change
suraeNoetherer. 3 i suppose
sgpOk, still between 10 and 3 is small
JollyMort[m]when the whole discussion started the first idea was to increase to 5 iirc
JollyMort[m]so might as well make it 5 vs 3 :)
suraeNoetheri think the security gain from 3 to 5 is not huge. the security gain from 3 to 10 is much more measurable
endogenicI'm with pigeons in that one
endogenicOn
moneromoooYou're on pigeons in that one ?
endogenicYeah
pigeons1[m]Oh baby
endogenicI'm one with pigeons on that too
endogenicTwo*
unknownids( ͡° ͜ʖ ͡°)
perowill there be a security hit if we enforce 10 for a while and then switch to random?
perorandom as in potentially <10
suraeNoetheri'm in agreement with pigeons1[m] and endogenic … especially if these O(sqrt(n)) signatures end up being nice. because knaccc was talking about n=30 ringsize being relatively reasonable in terms of cost to the blockchain today, and i know the max ringsize demonstrated so far is around 10^3. for the same cost, we could get 900 to 10^6 signatories per ring signature if O(sqrt(n)) hits the shelves, and i'll
suraeNoethertell you what: in that scenario, i'd absolutely advocate a minimum 150, and let users decide above and beyond that
endogenicThere may be a public education issue with switching all around w/o research too
suraeNoetherpero when i say random i mean "random above a certain minimum"
perogotcha
knacccyeah if a ring size 400 transaction is the same size as a ring size 20 transaction, that'd be incredible
suraeNoetherright now, the best hope for anonymity is simply more efficient ring sigs, and this set-up is extremely extremely promising
endogenicNot that you didnt research it jolly
suraeNoetheractually we've researched the crap out of htis
endogenicBtw jolly i guess that means i have to bump "ringsize" on the mm tx details page by 1 :p
suraeNoetherwe just haven't come up with a formal model of security yet that provides a tractable answer "go with 17, child"
endogenicNeed more tea leaves
gingeropolouswell in september we'll at least get ringsize = 5
moneromoooMake sure to list any extra crypto assumptions over what monero already assumes.
sgpRight now I'm most concerned what we will do for September
suraeNoetheri'm not totally concerned. i'm… really… really excited about small ring sizes
suraeNoetherokay, i'll be back later, i'm really glad i could hop in with such good timing on this
moneromooothanks suraeNoether
moneromoooanyone else ?
gingeropolousoh is it meeting time?
moneromoookovri's
ArticMineSo next meeting in two weeks?
serhackMoneromoo
serhackSorry
serhackI was eating
serhackOkay
serhackThen
moneromooonp, go ahead :)
serhackMy progress are: wordpress plugin is almost completed, I'm developing the verifying (if transaction is okay), I'm also starting the development of Prestashop plugins
serhackAfter that, I will write another FFS (I will request like 40 xmr or less)
serhackI would create some stickers based on https://m.imgur.com/QcdyyWn
serhackI will publish plugins on codecanyon.com, every funds will be helpful for Monero Project
serhackWhat do you think moneromoo?
moneromoooCool, thanks for the overview
perodEBRUYNE: was it codecanyon.com you blacklisted from the subreddit? ;p
dEBRUYNE.net I think, but that probably doesn't matter haha
serhackYour welcome, moneromoo
dEBRUYNEI can unblacklist it
serhackEveryone should know Monero Community
serhackFantastic community!
gingeropolousopinions? If I could even figure out how to code into monero a "remote node" support flag, would it be merged? it would be a daemon load flag that would do the appropriate rpc stuff and also modify some p2p metadata to essentially broadcast its openness
serhackCheers!
serhackPlease pm me for more information on slack or mail me [email protected]
Jaqueeso, "valgrind /path/to/monerod" works for everyone else except me?
moneromoooWorked for me last time I tried. Try running with strace too, see what syscall barfs.
iDunkcan't run valgrind because of TBM in his CPU.
moneromoooToo Big Munchkins ?
iDunkTrailing Bit Manipulation, IIRC :)
iDunkOne of AMD's FMA additions, I think.
peroso…follow up q…will there be a period of time during which gui master will be broken because of zmq
endogeniciDunk: is that similar to a FML addition?
perotewinget Jaquee ^
tewingetpero: there shouldn't be.
moneromoootewinget says the daemon runs both 0MQ and JSON/HTTP server, so shouldn't be.
perothx
tewingetwon't merge the zmq rpc wallet stuff until it's tested working, and at that point the gui wallet will be unaffected
Jaqueespeaking of testing. is someone working on fixing the failed tests on buildbot builds?
Jaqueepigeons1[m]: ^
Jaqueeand if you're around pigeons1[m]. How's the tagging bot coming along?
pigeons1[m]Bot is working in meta repo. I'll talk with fluffy and we'll add it to gui repo.
moneromoooWhat failing tests ? The DNS ones ?
moneromooopigeons1[m]: does it do closes yet ? :)
pigeons1[m]I was tracking down lots of my own bugs so switched to an opensource bot i linked to in the meta issue. Seems to work well
pigeons1[m]Yes +resolved on a line by itself by someone authorized closes the issue
moneromoooGreat, thanks :)
pigeons1[m]And moo yes i think he means the dns ones
moneromoooI've looked at the DNS stuff today, but I'm still flummoxed.
moneromoooRedoing manually what libunbound is supposed to do seems… not right :/
moneromoooNot to mention a huge amount of work.
moneromoooAnd if libunbound's not doing it right, surely it'd be best to fix it, not do it manually.
moneromoooI feel like I'm missing something here :/
moneromoooWe don't have a coder who knows about DNS already, do we ? :)
tewingetI don't know your exact headache, but I remember when I first implemented that shit using libunbound. Just about the only lib I could find that would serve our purposes, but…not without pain.
moneromoooMine is to first find the algorithm to verify a chain. Just that seems to be a lot of cases.
pigeons1[m]Dnssec validation locally instead of trusting the server response is part of the pain i think tewinget
moneromoooBut libnubound claims to do validation.
tewingetpigeons1[m]: yeah…I seem to remember that being one of the pain points.
moneromooo(and it fails to do so if I give it a bad key, which seems to confirm)
pigeons1[m]Yeah we're missing something…
tewingetwell I gotta afk for a bit. The last step before merging #2044 is to make sure it builds properly on all the things where it needs to, including deciding how to deal with the zmq dependency itself. I hesitate to make a decision there, as I'm ambivalent.
moneromoooProbably a submodule.
Sources and notes
- Meeting log: Overview and Logs for the Dev Meeting Held on 2017-07-23, 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.