Forum logs for 23 Jun 2018
mod6: | i broke my trb blockchain. | [00: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. | [00:30] |
mod6: | anyway, now the db is corrupt. | [00:31] |
mod6: | will need to probably resync the whole thing. | [00:31] |
mod6: | this ip from the nodes list: 208.94.240.42 | [00:31] |
lobbes: | ouch... I could see myself doing the same thing | [00:36] |
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. | [00:38] |
mod6: | i think i'm just gonna cutblock all the blk*.dat files, and eatblock 'em. | [00:38] |
mod6: | should take 10 days. | [00:38] |
* lobbes | makes a literal note | [00:39] |
mod6: | i'll probably just turn all of this into a blog post. | [00:42] |
mircea_popescu: | mod6 nah, listen, do you have an index saved ? | [00:44] |
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. | [00:45] |
mod6: | i have a backed up index, but its from long ago. | [00:54] |
mircea_popescu: | meanwhile in the basement, https://78.media.tumblr.com/df0b4f8fa317c5110325b4496d0a7dee/tumblr_o6gtpxaWH61rhup7qo1_540.gif | [00:54] |
mircea_popescu: | mod6 backups are your friend! this whole trb stuff is a little friable. | [00:55] |
mod6: | anyway, will try it. (it's from january) | [00:55] |
mircea_popescu: | then maybe not worth it, likely will take more than 10 days to sync | [00:56] |
mod6: | ah. perhaps ya. | [00:56] |
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. | [00:57] |
mircea_popescu: | ah. yeah, i mean weekly rotation, monthly, something. | [00:58] |
mod6: | *nod*, lesson learned. | [01:03] |
lobbes: | http://trilema.com/forum-logs-for-22-jun-2018#2453325 << 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 | [01:10] |
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.) | [01:10] |
lobbes: | snippet of access log for additional wtf >> http://p.bvulpes.com/pastes/DtslR/?raw=true | [01:11] |
mircea_popescu: | lobbes that's not overmuch by web standards. same one or diff ones ? | [01:12] |
mircea_popescu: | ah, crapolade trying to spam. shouldn't really bring mp-wp down afaik. | [01:12] |
mircea_popescu: | of course... this is the rockchip ? | [01:14] |
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 | [01:15] |
lobbes: | yeah, rockchip | [01:15] |
lobbes: | and to boot, I tried setting up some rules in iptables, but it barfs claiming it is missing 'insmod' module or somesuch | [01:15] |
lobbes: | in other words, iptables currently unavailable until I figure out more of arm64 peculiarities | [01:16] |
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. | [01:16] |
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. | [01:17] |
lobbes: | hm, yeah, looks like there is mod_limitipconn but the arm64 support looks dismal >> https://packages.gentoo.org/packages/www-apache/mod_limitipconn | [01:22] |
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. | [01:23] |
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. | [01:25] |
mircea_popescu: | meanwhile poolside, https://78.media.tumblr.com/3f6248c3f0a886611472762ba6bf4bbb/tumblr_inline_p1onsoyrKB1vpaf4h_500.gif | [01:41] |
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 ? | [08:42] |
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. | [08:42] |
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 ) | [08:44] |
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. | [08:44] |
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 | [08:45] |
asciilifeform: | unless dying hdd, etc, all bets off then. | [08:46] |
asciilifeform: | http://btcbase.org/log/2018-06-23#1829051 << lobbes didja determine what proggy (e.g. apache?) it was that actually fell down ? | [08:46] |
a111: | Logged on 2018-06-23 05:10 lobbes: http://trilema.com/forum-logs-for-22-jun-2018#2453325 << 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 | [08:46] |
asciilifeform: | meanwhile, for fyootoor ref, http://btcbase.org/log/2018-06-23#1829003 >>>> http://phuctor.nosuchlabs.com/gpgkey/2F5EC26698365939D499561F385A39A4217604DEB38913D71AFD135B28009DAF | [10:46] |
a111: | Logged on 2018-06-23 02:09 asciilifeform: http://p.bvulpes.com/pastes/t16fl/?raw=true << dump of RW key | [10:46] |
mircea_popescu: | asciilifeform same here, lotta problems in 2012ish but meanwhile fuzzed out the weird, learned like ox, by trying. | [11:57] |
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 | [12:01] |
mircea_popescu: | aha | [12:01] |
asciilifeform: | thing has roughly same uptime as its upstream isp. | [12:01] |
mircea_popescu: | meanwhile in true romance, https://78.media.tumblr.com/026a35dd07d2f0e4b08676f607ad9f52/tumblr_nconfxDv7X1rzv0kmo1_400.gif | [12:33] |
asciilifeform: | !Q later tell phf http://btcbase.org/log/2018-06-22#1828933 >> http://btcbase.org/log/2018-06-23#1829007 >> https://github.com/coreboot/chrome-ec/blob/master/chip/g/signed_header.h >>>>> http://www.loper-os.org/pub/c101pa/ro_signature.txt ( not the only 1, but illustrative ) | [12:57] |
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 | [12:57] |
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. | [12:57] |
lobbesbot: | asciilifeform: The operation succeeded. | [12:57] |
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. | [12:57] |
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. | [12:57] |
* asciilifeform | takes break, lets the red hot barrels cool... | [12:57] |
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' | [13:00] |
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 . | [13:09] |
lobbesbot: | asciilifeform: The operation succeeded. | [13:09] |
asciilifeform: | summary : google set up what is likely a deliberate bullshit dangle re the loader src for reasons that are yet unclear | [13:10] |
asciilifeform: | not a terribly high quality dangle, took roughly a day to uncover. | [13:11] |
mircea_popescu: | google would lie ?! | [13:13] |
asciilifeform: | never!111 | [13:13] |
mircea_popescu: | this comes as such a shock to absolutely nobody. | [13:13] |
asciilifeform: | the only even mild surprise is the sheer pile of echafaudage | [13:14] |
mircea_popescu: | well, the cloud of oricsh morons a la amstan are an expensive luxury. | [13:15] |
mircea_popescu: | useless, it is true. but expensive nevertheleess. | [13:15] |
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 | [13:16] |
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. | [13:18] |
mircea_popescu: | eh. from a statistical perspective, it can't be said we don't get enough tards talking, so... | [13:18] |
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 | [13:34] |
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 ... | [13:34] |
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 | [13:36] |
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 | [13:36] |
asciilifeform: | possibly the 2nd dumbest thing shitoshi did, after the mining algo -- the coin fragging nonsense. | [13:37] |
ben_vulpes: | would it be sensible for the send* commands to eat a changeaddress argument? | [13:59] |
asciilifeform: | ben_vulpes: absolutely, this has been a sore spot of asciilifeform's since day1 | [14:01] |
mircea_popescu: | yes. | [14:06] |
asciilifeform: | http://btcbase.org/log/2016-03-16#1434267 << see also oldthread | [14:58] |
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" | [14:58] |
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 | [15:27] |
BingoBoingo: | ian flag." << Apparently the whole swiss team is Albanian or Bosnian | [15:27] |
deedbot: | http://qntra.net/2018/06/austria-threatens-border-controls-against-increasingly-isolated-germany/ << Qntra - Austria Threatens Border Controls Against Increasingly Isolated Germany | [15:33] |
phf: | asciilifeform: https://www.youtube.com/watch?v=SPu8iRwZBZU | [16:03] |
lobbesbot: | phf: Sent 3 hours and 6 minutes ago: <asciilifeform> http://btcbase.org/log/2018-06-22#1828933 >> http://btcbase.org/log/2018-06-23#1829007 >> https://github.com/coreboot/chrome-ec/blob/master/chip/g/signed_header.h >>>>> http://www.loper-os.org/pub/c101pa/ro_signature.txt ( not the only 1, but illustrative ) | [16:03] |
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 . | [16:03] |
mircea_popescu: | you dare speak in #trilema ?! here's eight lines of stuff from the logs! | [16:09] |
asciilifeform: | lol! | [16:10] |
phf: | "have you been reading your log? but in case you haven't here's some more log in your log" | [16:16] |
mircea_popescu: | exactly! | [16:25] |
* asciilifeform | was aiming to nail down from what derives what, rather than flooding phf, lel | [16:28] |
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) | [16:33] |
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. | [16:35] |
phf: | "beware of dog"? seems unlikely though.. | [16:39] |
BingoBoingo: | I have become utterly unaccustomed to dogs being beasts to fear | [16:40] |
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 | [17:05] |
a111: | Logged on 2018-06-23 17:59 ben_vulpes: would it be sensible for the send* commands to eat a changeaddress argument? | [17:05] |
asciilifeform: | ben_vulpes: if changing the semantics, i recommend new names ( new commands ) | [17:12] |
asciilifeform: | eliminate possibility of confusion with old , or reactor meltdown if new trb is plugged into a scriptolade harness meant for old, etc | [17:12] |
asciilifeform: | e.g. 'sendbtc to=<destaddr> change=<chgaddr> [from=<optionalfromaddr_0,optionalfromaddr_1,...,optionalfromaddr_n>]' | [17:14] |
ben_vulpes: | it would be much easier to make a sendmanywithchangeaddr than to rework both sendfrom and sendmany | [17:14] |
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 | [17:14] |
ben_vulpes: | yeah that fucking horror of ordered args | [17:14] |
asciilifeform: | srsly we have enuff pistols that fire from 2 ends. time for a normal one. | [17:15] |
mircea_popescu: | hehehe | [17:15] |
asciilifeform: | ben_vulpes: dun forget fee=<...> | [17:16] |
ben_vulpes: | aha | [17:16] |
ben_vulpes: | ty | [17:16] |
asciilifeform: | and not optionally, but errytime. | [17:16] |
asciilifeform: | upstack : http://btcbase.org/log/2018-06-23#1829075 << for the record , it withstood (not much surprise) phuctoring (incl. fermat etc) | [17:19] |
a111: | Logged on 2018-06-23 14:46 asciilifeform: meanwhile, for fyootoor ref, http://btcbase.org/log/2018-06-23#1829003 >>>> http://phuctor.nosuchlabs.com/gpgkey/2F5EC26698365939D499561F385A39A4217604DEB38913D71AFD135B28009DAF | [17:19] |
ben_vulpes: | am i thick or does nothing in the rpc take named args already? | [17:20] |
asciilifeform: | not thick, this is so | [17:21] |
ben_vulpes: | how cool | [17:21] |
asciilifeform: | ben_vulpes: funnily enuff, ~this very item~ is how asciilifeform got mired in attempt to bolt a lisp onto trb | [17:24] |
asciilifeform: | 'this arg parser, with all of the eggog handlings/safeties already weighs 85% of lisp interpreter...' | [17:24] |
ben_vulpes: | noooooshit | [17:28] |
asciilifeform: | writing parsers in overflowsanddanglingpointers-lang is braindamaged. | [17:29] |
ben_vulpes: | sarcasm fails me in the face of cpp | [17:30] |
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 ) | [17:30] |
mircea_popescu: | heh | [17:34] |
ben_vulpes: | !!up epony do you plan to register a key or what | [17:56] |
deedbot: | epony voiced for 30 minutes. | [17:56] |
epony: | don't know, I'll read on for now.. | [17:57] |
epony: | devoice if you please, nothing to say on my end | [17:57] |
ben_vulpes: | epony: what do you perceive the cost of registering a key to be? | [17:59] |
ben_vulpes: | put another way, why *not* do it? | [17:59] |
epony: | because, why would I want to say anything before getting a feel of the tone of the conversation.. | [18:00] |
epony: | put another way, ephemeral is nice | [18:01] |
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?" | [18:01] |
ben_vulpes: | chance favors the prepared keyring or what was it. | [18:02] |
epony: | I'll then say "just nobody" :-) | [18:02] |
epony: | It's fun playing mental experiments anyway | [18:03] |
ben_vulpes: | epony: still haven't digested the epsilon appetite for nobodies? not obvious in your 11 days reading? | [18:03] |
epony: | I cherry pick 1 line at a view. | [18:03] |
epony: | I think it's 9 days since I pop back in. | [18:10] |
epony: | Don't know where these 11 days come from... | [18:10] |
ben_vulpes: | http://btcbase.org/log/2018-06-12#1823667 | [18:11] |
a111: | Logged on 2018-06-12 06:20 mircea_popescu: !!up epony | [18:11] |
epony: | :) | [18:11] |
ben_vulpes: | assuming that epony is this epony | [18:11] |
epony: | same | [18:11] |
epony: | so, idling 12-15 and out... back in 9 days... | [18:12] |
ben_vulpes: | dun dun dun | [18:12] |
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 | [18:21] |
asciilifeform: | , still waking along, mostly torso-less and wingless... | [18:21] |
asciilifeform: | *walking | [18:22] |
asciilifeform: | mm pretty satisfying, swinging that thing through cloud of mosquito | [19:47] |
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. | [21:12] |
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. | [21:13] |
Category: Logs