Monero Dev Meeting Note Highlights – 2017-10-22

Logs

351 lines
rehrarComma use is everything here.
fluffyponyok
fluffyponyfires up meeting issue
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
suraehowdy!
fluffyponyand an additional point that I guess we can put in between 3 and 4: "Should regular hardware development reporting and discussion be part of #monero-dev (biweekly meetings), #monero-community (biweekly meetings), or something else?"
msvb-labHello.
rbrunnerGrüezi mitenand
rehrarI thought that could fall under 4., sorry
ArticMinehi
hychi
iDunkHi.
endogenicHi fluffypony!
rehrarhi endogenic
Jaqueehey
fluffyponyok
fluffyponymoneromooo / hyc / luigi1111 you guys around?
hycnope
moneromoooI'm here
endogenico/ rehrar
fluffyponyok
fluffyponyso moving on to 2. Brief review of what's been completed since the previous meeting
fluffyponyloads of merges
fluffyponythe big ones are lightweight wallet API support
fluffyponyand subaddresses
endogenicOmg
suraeat MRL, i wrote up a prototype for the spectre blockchain algorithm. i'm pushing it to my github later today. it is functional, but can be made prettier and more efficient, but it's pretty much ready for stress testing so we can really see whether it's a waste of energy or not
fluffyponywe also have a number of PRs going into the 0.11 branch, specifically: 2478, 2493, 2514, 2632, 2639, 2654
fluffyponyand then we'll tag and release 0.11.1
moneromoooyay ^_^
hyc:D
suraethe research-lab project has a PR waiting to be merged from my github on a similar note
fluffyponysurae: ok cool I'll merge it now
hycthat spectre stuff sounds great
rehrarlink to spectre stuff?
suraehyc they just roll with this idea of having 10 blocks a second, it's nutters
rehrarthanks
suraezooko mentioned it to me, btw. :P gotta give credit where credit is due
fluffyponyok moving on to 3
fluffypony3. Code + ticket discussion / Q & A
hycis the set of patches for 11.0.1 pretty well settled?
fluffyponyunless there are some others beyond that list
moneromoooI just cherry picked the OpenBSD one earlier, but it's low impact.
fluffyponyI'll add that to the list
fluffyponyok so then I'd like to bring up the latest Verge FUD for discussion
fluffyponyfor those that haven't seen it
fluffyponyit's literally just netstat
moneromoooIt'd be easier to just run print_cn or print_pl.
fluffyponyand then it excludes some nodes that he decided are "server nodes" (whatever that means)
hyclol
fluffyponymoneromooo: too sophisticated
fluffyponylol
endogenicLol
fluffyponythat said, I have received several messages from people who are quite concerned that Monero is not private
suraewell
fluffyponyoh - there's also this fun article: https://bitsonline.com/monero-exploit-threatens-privacy/
fluffyponylol
suraei haven't seen these latest criticisms at all yet
suraebut i have to ask
rbrunnerThe "fun article" is really bad
suraewhat is our policy going to be for writing responses to criticisms?
suraebecause
suraeconsider the miller and kumar papers, right? long papers. writing responses takes a long time…
pigeonsDoS by stupid claims
endogenicrbrunner: looks more like a hit piece
fluffyponythe anonymint post is even longer, and we largely ignored it
fluffyponybecause it was a massive waste of time
saddamIf you don't want to be on his "list", just leave your monerod running 24/7
moneromoooI say ignore the obvious bullshit. People gonna pump and dump anyway.
suraenot all their criticisms are false (although a lot are outdated), but my point is this: if someone writes a 1000 word article claiming something about monero's privacy, it will in general take 9000 words to "debunk" the false parts and explain why the true parts are either part of the design or already on our roadmap for improvement
endogenicArent there other cases of having published this data anyway? Like monero node maps
hyc'The amount of energy required to dispel bullshit is an order of magnitude greater than that required to propagate it'.
hyc1 reply 1 retweet 0 likes
vtnerdwow, that article is really dumb
suraehyc ha, i was close with a factor of 9
endogenicSo alternative to refutation is be like yeah get with the times
suraei liked the monero challenge thing
suraei love that idea
gingeropoloushow close is i2p?
gingeropolouser, kovri
fluffyponygingeropolous: still a little ways away - but we'd still need to refute this criticism even if it was in place
endogenicAlso want to know
endogenicgingeropolous:
fluffyponybecause aiui the way that Verge works is that it's only Tor or i2p
fluffyponywhich is open to isolation and Sybil attacks, but they don't care about that
moneromoooI'm not sure how this is complicated. If you want your IP to be hidden, use Tor. Like everyone else.
fluffyponymoneromooo: in the same way that ZCash can say "if you want your transaction to be hidden use shielded addresses"
ArticMineKovri will fix all of this anyway
pigeonsthere are people that try to connect to as many nodes as possible and record which transactions they first see relayed from those nodes, but that's not new
moneromoooWell, that is true, no ?
gingeropolousi mean, the only response is to explain how blockchains and the internet works
fluffyponyyes - but if it's not the default mode then it's not worth talking about
moneromoooOK. Then we're not anonymous, and we'll be once kovri, done.
moneromoooMuch easier than dealing with the bullshit ^_^
suraefluffypony "we'd still need to refute this criticism" <— i totally disagree. this is not only a known issue, we are building kovri around solving it
pigeonsif people were surprised by this its good they are aware of it
fluffyponyanonimal: what are your thoughts on us spending some time building out the mixnet stuff, and bundling Tor until Kovri is ready?
fluffyponysurae: their netstat bot would continue to publish node IPs and they'd continue to push that agenda
endogenicSurae: arent those two facts what makes refutation possible? :p
endogenicMake
moneromooofluffypony: is that takes time, I'm against it. It's just wasting time for something which wasn't in good faith to begin with.
suraefluffypony: what refutation would get them to stop publishing node IPs?
moneromoooOr, at least, I won't waste my own time on it.
rehrarThe only valid criticsm I think they have (but correct me if I'm wrong) is that in a country where Monero is 100% outlawed, the government could see an IP address connecting to the Monero network (can't see if/when transactions are sent though), and that person could get in trouble. But that's the only information they have, no?
YohkiiJust make a bot that does the same to verge, including where transactions come and go
Yohkiiless effort
rbrunnerWouldn't they happily go on and publish Tor IP's anyway, people would not know these
fluffyponymoneromooo: we have to build out the ipv4 / mixnet stuff anyway, we'd just be plugging Tor in instead of Kovri till Kovri is ready, so it's 95% useful work, 5% effort that will be replaced later
suraefluffypony: oh your recommended tactic here, then, is to first push tor until kovri is ready?
fluffyponysurae: none - but a published refutation would allow us to point people to it - the getmonero.org post responding to the Miller paper is my go-to when people ask about it
fluffyponysurae: yes that's what I was thinking
dEBRUYNEI can write a post fwiw
moneromoooOK, if it's shared stuff then that's good.
dEBRUYNEBut would probably need some help on the really technical stuff
rbrunnerIs it even technical? Internet 1x1: IPs!
gingeropolousim kinda confused - our proposed kovri implementation was gonna keep blocks on clearnet anyway, so this "attack" would still be able to "identify" monero users
moneromoooAIUI, it can do both.
gingeropolousare we just gonna switch too 100% kobri, all the time?
moneromoooWell, it will be able to do both :)
gingeropolousright. but the bandwidth.
dEBRUYNEgingeropolous: There was supposed to be i2p only | i2p/ip | ip only
fluffyponygingeropolous: yes that's what I was saying to surae
dEBRUYNEiirc
dEBRUYNEAlso, iirc if you push blocks over i2p you might incur latency issues, which increases the probability of an orphan
fluffyponyyes
pigeonswhich transactions came from which nodes/ips affects privacy more than knowing you run monero. if you relayed a block first, yeah it could make your pool a traget, but there are other mitigations for that
moneromoooJust post the URL in #monero
rbrunnerI have a hunch the Verge people will use the log of this meeting to show that "Monero devs are in panic"…
fluffyponyrbrunner: lol
endogenicIs this issue within sarang’s wheelhouse? I know he was looking into working on kovri
gingeropolouspigeons, yeah I get that. but this "criticism" doesn't even address that.
gingeropolousits just ermagerd ips
pigeonsgingeropolous: well that isnt interesting
fluffyponygingeropolous: great summary
fluffyponylol
fluffyponyok well we'll wait for anonimal to comment on it, and we can go from there
gingeropolousi know. but ppl have tried to explain the cost of actual sybil using the public ips and trying to track txs with this "weakness"
fluffyponylet's move on to 3. b.
fluffyponyShould regular hardware development reporting and discussion be part of #monero-dev (biweekly meetings), #monero-community (biweekly meetings), or something else?
msvb-labThere are some good reasons that hardware development progress reports and discussion should be moved from the biweekly #monero-dev schedule (where the accepted forum proposal mandates.)
msvb-labSo unless anyone strongly objects, it's gone from now on and will become part of either (1) #monero-community meetings or (2) #monero-hardware meetings.
msvb-labWhoever wants to know if it will be (1) or (2) should attend next week's #community meeting which will decide, okay?
moneromoooWhat's the difference between #monero-aparataro and #monero-hardware btw ?
moneromoooBoth seem empty.
msvb-labI created aparataro but then changed it to hardware.
moneromoooAh OK.
msvb-lab…since the IRC channel 'community' is english non esperanto.
msvb-labSo I wanted to be consistent there.
msvb-labSpeaking of esperanto, before the hardware story fades into the sunset, here's a new topic.
msvb-labWe tried and failed to give RFC-HWALLET-1 an esperanto name, so will rename our repository 'Sekura' to rfchwallet, okay?
msvb-labgithub.com/monero-project/rfchwallet
endogenicI enjoy naming. I’ll let you know later if i have some suggestions
msvb-labWe need a person to handle surveying a number of related Monero groups in order to get a good name that doesn't conflict in any way.
msvb-labNo person is able to take this role, so if it appears it will be much later after risk of failure drops.
msvb-labendogenic: Thanks
msvb-lab73.
fluffyponyok endogenic is in charge of naming
fluffyponyChief Naming Officer
msvb-labHa.
endogenic👷
hycone of the hardest problems in CS. good man
msvb-labReport on a privacy conference CCC puts on which I did a workshop at today after the meeting finishes.
msvb-labThere was Monero activity and considerable interest…
endogenicNow we just need to let them in on kovri and…
hycnext?
endogenicI think monero-hardware would be a better venue
endogenicFor hardware specific mtgs
endogenicStatus updates propagate anyway
msvb-labendogenic: I'll let the #community folks know that's your opinion. They won't agree.
endogenicAnd maybe i can figure out a way to give michael op :p
endogenicOh ok
msvb-labop? An operation?
endogenicI guess all ffs mtgs now go in community lolol
endogenicOp -> operator status
msvb-labNice.
msvb-labEven better, I want business cards like fluffypony.
fluffyponylol
fluffyponyok
fluffyponylet's move on to 4. Any additional meeting items
fluffyponyanything up for discussion?
moneromoooWhen are you releasing 0.11.0.1 ? Before tomorrowish ?
rehrarluigi is site repo maintainer now right?
fluffyponymoneromooo: it'll be tomorrow - but I'll do the merges now and start building
fluffyponyrehrar: yes
moneromoooOK, thanks.
redfishjust wanted to put in a vote for db-safe to be the default during sync as well
fluffyponyhyc: thoughts? ^^
redfish(i ended up running a node for months with a corrupt blockchain DB)
rbrunnerIs the speed difference known on a typical PC?
hycit'll beat most drives to shit. and be slow.
redfishwe can add to the readme in the "Running monerod" section, that "you have an option to speed up, if you can be confident that the node will not fail while synching"
hycI mean, most consumer storage devices will probably see premature death.
rbrunnerDeath by Monero :)
redfishhyc: why? it won't matter after sync, and sync is temporary
hyc?
redfishdidn't you say daemon is in db-safe mode after sync completes, already.
hycyes
redfishso, why would increasing the load on the disk during the hours/few days of syncing make that big of a difference on the disk lifetime?
hycduring normal operation whenyou're already sync'd, you're getting 1 new data item per 2 minutes.
redfish(btw, sidenote: with slow disks, despite there being so little new data, it spends 90% of those 2 minutes reading)
gingeropoloushrm… perhaps we should make kovri the default network interface when it is ready. The only nodes that really could be affected by delays are pools. We should be private by default. If a pool wants to get gains by running over clearnet, they can run a flag. A regular user isn't affected if they are 2-4 minutes behind the current state.
redfishmy disks right now are so slow, that the node actually can't keep up. (Disk usage is continuous, monerod in D state continously)
redfishbut this is sidetracking. I'm still not clear on hyc's point about db-safe during sync being a disk killer.
hycif you had more RAM it woukd have more cached, and less read load
redfishyeah, there's only 2GB, of which only ~1GB is free for the caching…
hycbut large number of IOs spread over 2 minutes is gentler than spit out as fast as possible
hycSSDs need time for background wear-leveling to do its thing
fluffyponylet's wind it down and continue this discussion after the meeting
redfishare you referring to operation after sync or during sync?
hycok
fluffyponyis everyone happy with Nov 5th as the next meeting date ?
hycsure
fluffyponyok cool - meeting over

Sources and notes

  • Meeting log: Overview and Logs for the Dev Meeting Held on 2017-10-22, 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.