Show Idle (>14 d.) Chans


← 2018-06-22 | 2018-06-24 →
mod6: i broke my trb blockchain.
mod6: thing was stuck, flooded with connections, not keeping up, wouldn't respond to any rpc calls. this going on for hours and hours. finally i just killed it. i probably instead should have just firewalled off 8333 instead.
mod6: anyway, now the db is corrupt.
mod6: will need to probably resync the whole thing.
mod6: this ip from the nodes list: 208.94.240.42
lobbes: ouch... I could see myself doing the same thing
mod6: yeah, ensure that if something like this happens to you, you do not kill it -- instead firewall it off. wait until all connections drop.
mod6: i think i'm just gonna cutblock all the blk*.dat files, and eatblock 'em.
mod6: should take 10 days.
lobbes makes a literal note
mod6: i'll probably just turn all of this into a blog post.
mircea_popescu: mod6 nah, listen, do you have an index saved ?
mircea_popescu: just reinstate the old index, have it check the chain. odds are it'll be able to recover, because it doesn't so much care about data ~past~ its index point.
mod6: i have a backed up index, but its from long ago.
mircea_popescu: mod6 backups are your friend! this whole trb stuff is a little friable.
mod6: anyway, will try it. (it's from january)
mircea_popescu: then maybe not worth it, likely will take more than 10 days to sync
mod6: ah. perhaps ya.
mod6: but backing up the chain is a good idea. i actually have backups more recent than that, but from other trbs, not this specific one.
mircea_popescu: ah. yeah, i mean weekly rotation, monthly, something.
mod6: *nod*, lesson learned.
lobbes: http://btcbase.org/log/2018-06-22#1828740 << so I figured it out: cause of downtime ended up being a flood of tor exit nodes >> http://p.bvulpes.com/pastes/VYVGW/?raw=true
a111: Logged on 2018-06-22 16:14 lobbes: http://btcbase.org/log/2018-06-21#1828477 << ack, ty for letting me know. I'll try sshing in tonight to rule out webserver failure before I flag down BB to check out the situation manually. (I must say, it is a good feeling knowing that nowhere in this troubleshooting cycle will I need to interface with orcs.)
lobbes: snippet of access log for additional wtf >> http://p.bvulpes.com/pastes/DtslR/?raw=true
mircea_popescu: lobbes that's not overmuch by web standards. same one or diff ones ?
mircea_popescu: ah, crapolade trying to spam. shouldn't really bring mp-wp down afaik.
mircea_popescu: of course... this is the rockchip ?
lobbes: word, well that is good to know at least.I tried to deny a shitload of em via virtualhosts.conf. Blog is back up for now, but I half-expect it to be down again by morning
lobbes: yeah, rockchip
lobbes: and to boot, I tried setting up some rules in iptables, but it barfs claiming it is missing 'insmod' module or somesuch
lobbes: in other words, iptables currently unavailable until I figure out more of arm64 peculiarities
mircea_popescu: the thing is very stringently optimized to waste as little as possible on the spammer wanna-bes, but then again i never tried it on an arm.
mircea_popescu: i could say "trilema runs like that ~70% of the time", but then again trilema's got a larger box. pretty sure you can set it up though so it rejects multiple conns like that. there's a setting somewhere to limit inbound.
lobbes: hm, yeah, looks like there is mod_limitipconn but the arm64 support looks dismal >> https://packages.gentoo.org/packages/www-apache/mod_limitipconn
mircea_popescu: mod_whateverthefuck the common one also can do it for you. and also csf or w/e you use to manage the firewall.
mircea_popescu: in principle saying something like "no more than x connection from a given ip will be entertained" is perfectly reasonable ; though careful how low you set the x, some browsers (especially the mobile versions dedicated to fucking as much battery as possible) can turn a pageload into 10-20 simultaneous requests.
asciilifeform: http://btcbase.org/log/2018-06-23#1829030 << hey mod6 is this the same box as in the last coupla similar threads, with the questionable hdd ?
a111: Logged on 2018-06-23 04:30 mod6: thing was stuck, flooded with connections, not keeping up, wouldn't respond to any rpc calls. this going on for hours and hours. finally i just killed it. i probably instead should have just firewalled off 8333 instead.
asciilifeform: http://btcbase.org/log/2018-06-23#1829041 << mircea_popescu has it , index is the only piece that actually bitrots ( bdb was written by the maliciously retarded )
a111: Logged on 2018-06-23 04:45 mircea_popescu: just reinstate the old index, have it check the chain. odds are it'll be able to recover, because it doesn't so much care about data ~past~ its index point.
asciilifeform: fwiw asciilifeform has not suffered this problem in many yrs, for box on uninterruptible power ( and resist the temptation to fiddle! no it ain't 'stuck', it stands up again by itself in coupla hrs ) -- no bitrot
asciilifeform: unless dying hdd, etc, all bets off then.
asciilifeform: http://btcbase.org/log/2018-06-23#1829051 << lobbes didja determine what proggy (e.g. apache?) it was that actually fell down ?
a111: Logged on 2018-06-23 05:10 lobbes: http://btcbase.org/log/2018-06-22#1828740 << so I figured it out: cause of downtime ended up being a flood of tor exit nodes >> http://p.bvulpes.com/pastes/VYVGW/?raw=true
a111: Logged on 2018-06-23 02:09 asciilifeform: http://p.bvulpes.com/pastes/t16fl/?raw=true << dump of RW key
mircea_popescu: asciilifeform same here, lotta problems in 2012ish but meanwhile fuzzed out the weird, learned like ox, by trying.
asciilifeform: mircea_popescu: for comparison : the last time i reset 'zoolag' was to change ps. and the time before that -- to swap in the 'aggression' build
asciilifeform: thing has roughly same uptime as its upstream isp.
a111: Logged on 2018-06-22 22:35 asciilifeform: if nobody finds obvious mistake, i guess i'ma have to pull an actual enemy signature out of the binariola, and see wtf
a111: Logged on 2018-06-23 02:18 asciilifeform: http://p.bvulpes.com/pastes/corod/?raw=true << the RO pubkey. (labels mine, offsets original). does not appear to be posted publicly anywhere.
lobbesbot: asciilifeform: The operation succeeded.
mod6: <+asciilifeform> http://btcbase.org/log/2018-06-23#1829030 << hey mod6 is this the same box as in the last coupla similar threads, with the questionable hdd ? << yup, same item. will post more about it later for sure.
a111: Logged on 2018-06-23 04:30 mod6: thing was stuck, flooded with connections, not keeping up, wouldn't respond to any rpc calls. this going on for hours and hours. finally i just killed it. i probably instead should have just firewalled off 8333 instead.
asciilifeform takes break, lets the red hot barrels cool...
asciilifeform: mod6: by all indications you have a box with iron problem. in your place i'd get a fresh set of iron, rather than sinking sweat into interpreting randomly flipped bits as 'bug'
asciilifeform: !Q later tell phf other interesting observations: 1) loader is not the same as what appears in the src, in either 3.3 or 3.4 fw bin; not only key differs, but eggog strings, and possibly the rsa per se. 2) seems like : nowhere else in the fw is there any other routine which checksums/rsaverifies the cr50 fw , or references the rsa keyz at all other than to print keyid .
lobbesbot: asciilifeform: The operation succeeded.
asciilifeform: summary : google set up what is likely a deliberate bullshit dangle re the loader src; for reasons that are yet unclear
asciilifeform: not a terribly high quality dangle, took roughly a day to uncover.
mircea_popescu: google would lie ?!
asciilifeform: never!111
mircea_popescu: this comes as such a shock to absolutely nobody.
asciilifeform: the only even mild surprise is the sheer pile of echafaudage
mircea_popescu: well, the cloud of oricsh morons a la amstan are an expensive luxury.
mircea_popescu: useless, it is true. but expensive nevertheleess.
asciilifeform: pretty great lolcow, btw, that d00d. spilled what he thought was a carefully incomplete pile of beans to 'get asciilifeform to waste months making debug cable', i suspect, didn't quite expect us to get a working one in 1wk
asciilifeform: since his monumental 'nobody has the keys!' gem, all i saw of him was that 1 time he popped in here and drooled for coupla min.
mircea_popescu: eh. from a statistical perspective, it can't be said we don't get enough tards talking, so...
asciilifeform: btw i did figure out the http://btcbase.org/log/2018-06-22#1828757 matter -- their key format reserves 1st 4bytes for 'keyid' . but the lulzimplementation pictured in the (useless, doesn't seem to occur in the bin) published 'loader', treats the key as starting there . as i currently understand, couldn't actually work as written, barring some mathematical curio
a111: Logged on 2018-06-22 18:17 asciilifeform: static const uint32_t LOADERKEY_A[RSA_NUM_WORDS + 1] = { ...blah... } where #define RSA_NUM_WORDS 96 ...
asciilifeform: http://btcbase.org/log/2018-06-22#1828901 << this kind of thing was a multi-week headache for asciilifeform the last time he had to actually uncork the launch codes and move coin; and i expect that it will only ever get worse
a111: Logged on 2018-06-22 21:55 ben_vulpes: next thing i'm going to try is manually walk the spend-to-self down by 100 satoshis until this trb shits a tx out and then look at what it produces
asciilifeform: possibly the 2nd dumbest thing shitoshi did, after the mining algo -- the coin fragging nonsense.
ben_vulpes: would it be sensible for the send* commands to eat a changeaddress argument?
asciilifeform: ben_vulpes: absolutely, this has been a sore spot of asciilifeform's since day1
a111: Logged on 2016-03-16 15:42 mircea_popescu: both the "shittier than historical" and "new addr for change" bits are satoshi's dubious kludges to protect "anonimity"
BingoBoingo: In miscellani-lulz: "The Serbian football association says it will demand that FIFA take action against Granit Xhaka and Xherdan Shaqiri for their eagle salute goal celebrations in Switzerland’s 2-1 World Cup win in Kaliningrad on Friday. Shaqiri and Xhaka, both of whom were born in Kosovo and are of Albanian descent, celebrated their goals in Switzerland’s comeback win by making an eagle salute in apparent reference to the Alban
BingoBoingo: ian flag." << Apparently the whole swiss team is Albanian or Bosnian
deedbot: http://qntra.net/2018/06/austria-threatens-border-controls-against-increasingly-isolated-germany/ << Qntra - Austria Threatens Border Controls Against Increasingly Isolated Germany
lobbesbot: phf: Sent 2 hours and 54 minutes ago: <asciilifeform> other interesting observations: 1) loader is not the same as what appears in the src, in either 3.3 or 3.4 fw bin; not only key differs, but eggog strings, and possibly the rsa per se. 2) seems like : nowhere else in the fw is there any other routine which checksums/rsaverifies the cr50 fw , or references the rsa keyz at all other than to print keyid .
mircea_popescu: you dare speak in #trilema ?! here's eight lines of stuff from the logs!
phf: "have you been reading your log? but in case you haven't here's some more log in your log"
mircea_popescu: exactly!
asciilifeform was aiming to nail down from what derives what, rather than flooding phf, lel
asciilifeform: the other interesting bit ( from asciilifeform's disasm of the 3.4 fw) is that there doesn't seem to be any pinning of the keys! ( i.e. i can't currently find any reason why it wouldn't eat a rw-fw update signed with a variant key, so long as said key is stuffed in where expected)
asciilifeform: nao this is imho hard to swallow ('submarine with screen door') and so currently i'm assuming that i simply missed something. will have to test, at any rate.
phf: "beware of dog"? seems unlikely though..
BingoBoingo: I have become utterly unaccustomed to dogs being beasts to fear
ben_vulpes: http://btcbase.org/log/2018-06-23#1829108 << the alternative, which would be a smaller patch, is a "setchangeaddr" RPC function. i'm leery of changing the call signatures of sendfrom and sendmany, but doing so might be The Right Thing nevertheless
a111: Logged on 2018-06-23 17:59 ben_vulpes: would it be sensible for the send* commands to eat a changeaddress argument?
asciilifeform: ben_vulpes: if changing the semantics, i recommend new names ( new commands )
asciilifeform: eliminate possibility of confusion with old , or reactor meltdown if new trb is plugged into a scriptolade harness meant for old, etc
asciilifeform: e.g. 'sendbtc to=<destaddr> change=<chgaddr> [from=<optionalfromaddr_0,optionalfromaddr_1,...,optionalfromaddr_n>]'
ben_vulpes: it would be much easier to make a sendmanywithchangeaddr than to rework both sendfrom and sendmany
asciilifeform: or some other name, but idea being that it must be 1) impossible to confuse it with old 2) keywords ~named~, no order dependency plox
ben_vulpes: yeah that fucking horror of ordered args
asciilifeform: srsly we have enuff pistols that fire from 2 ends. time for a normal one.
asciilifeform: ben_vulpes: dun forget fee=<...>
asciilifeform: and not optionally, but errytime.
asciilifeform: upstack : http://btcbase.org/log/2018-06-23#1829075 << for the record , it withstood (not much surprise) phuctoring (incl. fermat etc)
ben_vulpes: am i thick or does nothing in the rpc take named args already?
asciilifeform: not thick, this is so
ben_vulpes: how cool
asciilifeform: ben_vulpes: funnily enuff, ~this very item~ is how asciilifeform got mired in attempt to bolt a lisp onto trb
asciilifeform: 'this arg parser, with all of the eggog handlings/safeties already weighs 85% of lisp interpreter...'
ben_vulpes: noooooshit
asciilifeform: writing parsers in overflowsanddanglingpointers-lang is braindamaged.
ben_vulpes: sarcasm fails me in the face of cpp
asciilifeform: ( btw, this does not appear to be in the l0gz as-such, so asciilifeform will note : c was an evil thing from ~birth~. on machines so impoverished that 'c is necessary', oughta be writing in asm; on machines where not necessary -- well, obvious )
ben_vulpes: !!up epony do you plan to register a key or what
deedbot: epony voiced for 30 minutes.
epony: don't know, I'll read on for now..
epony: devoice if you please, nothing to say on my end
ben_vulpes: epony: what do you perceive the cost of registering a key to be?
ben_vulpes: put another way, why *not* do it?
epony: because, why would I want to say anything before getting a feel of the tone of the conversation..
epony: put another way, ephemeral is nice
ben_vulpes: consider, one day, you find yourself inspired to say something, you then go to register a key first? and then conversation gets derailed with "oh ho, look who finally registered a key" or alternatively "oh ho, who are you now?"
ben_vulpes: chance favors the prepared keyring or what was it.
epony: I'll then say "just nobody" :-)
epony: It's fun playing mental experiments anyway
ben_vulpes: epony: still haven't digested the epsilon appetite for nobodies? not obvious in your 11 days reading?
epony: I cherry pick 1 line at a view.
epony: I think it's 9 days since I pop back in.
epony: Don't know where these 11 days come from...
a111: Logged on 2018-06-12 06:20 mircea_popescu: !!up epony
epony: :)
ben_vulpes: assuming that epony is this epony
epony: same
epony: so, idling 12-15 and out... back in 9 days...
ben_vulpes: dun dun dun
asciilifeform: this reminds me, not long ago asciilifeform picked up a little chinese toy, item shaped like tennis raquet but the wires are charged to 4000v and connect to (small) cap; a sort of mechanized fly swatter, they pop, little blue plasma burst, vapour. nominally. so then , having used it, later i see a most peculiar insect, did not immediately realize what it is, never having seen before. looked closely, turns out -- fly head + front legs
asciilifeform: , still waking along, mostly torso-less and wingless...
asciilifeform: *walking
asciilifeform: mm pretty satisfying, swinging that thing through cloud of mosquito
mod6: <+asciilifeform> mod6: by all indications you have a box with iron problem. in your place i'd get a fresh set of iron, rather than sinking sweat into interpreting randomly flipped bits as 'bug' << yeah for sure, it certainly could be related to the disk issue. I don't really think it's a 'bug' or anything.
mod6: I'll call these guys and get them to throw in a ~new~ SSD for me this time. Or will just pay out, and find new service.
← 2018-06-22 | 2018-06-24 →