shinohai: Bitnodes only shows 4 trb nodes nau O.o https://bitnodes.earn.com/nodes/?q=/therealbitcoin.org:0.9.99.99
shinohai: (coin.dance still shows 6)
asciilifeform: shinohai: they seem to display ~random subset of the known (i.e. people who specifically diddled the ver string to show up there) boxes
shinohai: Last time I checked, saw all of the pizarro nodes
lobbes: asciilifeform: I have a question re: the unix epoch timestamps in the phf logs. So, when I look through them, I see two numbers essentially, e.g. "1440678;1459171457;"
lobbes: Now, the second number is obv the epoch timestamp. My best guess on the first number is that it is simply some sort of a line index of sorts.
lobbes: So, my question is: do you want the znc-eater.py to produce both numbers as such, or is just the unix epoch time adequate for what you need?
asciilifeform: lobbes: see readme.txt in the genesis plox
asciilifeform: ( you guessed correctly, the smaller # is index. it is not important in the absolute what it is, but ~must~ be monotonic and ~must~ agree with the existing indices )
asciilifeform: !quptime
snsabot: asciilifeform: time since my last reconnect : 1d 0h 30m
lobbes: ah okay; reading the eat_dump.py in the genesis cleared some things up
lobbes: so, the monotonically increasing thing makes sense, but when you say agree with existing indicies, I assume you mean the existing indicies on *one particular implemented logger*, versus say "has to 'match' btcbase's indicies"
lobbes: in other words, like a 'knob' someone can set that says "eat these ZNC logs, making an index, but do NOT let index go past 10000" or somesuch?
asciilifeform: lobbes: ideally you'd count backwards from my 'bottoms' in the chans that are missing archive atm
asciilifeform: see constant 'newchan_idx'
lobbes: aha, I literally just thought "oh yeah, I could go backwards, huh?"
lobbes: sweet okay. this makes sense. ty