tmsr - Search: blackhole

ossabot: Logged on 2019-10-07 11:59:32 asciilifeform: unsurprising tho, ddostron likely switched to the remaining working ips, and the latech derps added them also to blackhole.

ossabot: Logged on 2019-10-07 11:41:27 asciilifeform: and holyfuq, just 8 ?!!! and the fucking orcs put ~destination~ in blackhole, and not the 8 sources?!!!

asciilifeform: unsurprising tho, ddostron likely switched to the remaining working ips, and the latech derps added them also to blackhole.

asciilifeform: and holyfuq, just 8 ?!!! and the fucking orcs put ~destination~ in blackhole, and not the 8 sources?!!!

brazilish: problem: downloaded asciilifeform_blackhole_reads.vpatch and placed in patches folder, same for the sig file in .seals, then running ./v.pl p v trb054 makefiles.vpatch, but i don't get the patch in the src files

asciilifeform: and yes if it isn't stuck in verification blackhole, it'll be churning tx crapola

a111: 117 results for "blackhole", http://btcbase.org/log-search?q=blackhole

a111: Logged on 2017-04-24 06:12 pete_dushenski: "WARNING: asciilifeform_blackhole_reads.vpatch.asciilifeform.sig is an INVALID seal for asciilifeform_blackhole_reads.vpatch!" << anyone else seen this error ? my vtron is barfing this up even though my gpgtron says it's a good sig.

pete_dushenski: "WARNING: asciilifeform_blackhole_reads.vpatch.asciilifeform.sig is an INVALID seal for asciilifeform_blackhole_reads.vpatch!" << anyone else seen this error ? my vtron is barfing this up even though my gpgtron says it's a good sig. ☟︎☟︎

asciilifeform: blackhole odometer is probably of ~very~ limited interest to folx who aren't asciilifeform

mod6: asciilifeform_blackhole_odometer.vpatch, asciilifeform_blocktimer.vpatch, and asciilifeform_goodbye_pingers_fixed.vpatch all have the same input hash.

asciilifeform: let's picture that whole deedbot l1 subscribes. the folx who run public/exposed node, so as to soak up blocks from heathen miners -- will be the ones to blackhole.

a111: Logged on 2017-02-26 19:14 asciilifeform: the 'type 2' (non-verification) blackhole goes right back to the fundamental question of 'something to all comers', how much disk thrashing does a derp get to invoke simply by coming up with a not-yet-banned ip and a pseudonode.

a111: Logged on 2017-02-26 19:26 mircea_popescu: now then : a fix for the db would significantly improve a few classes of block verification delays ; and it would alleviate blackhole-like behaviour due to that, node's frozen checking a new block. there's at least 3 different dos vectors for other nodes, and a) the foregoing wouldn't help ; b) if it helped the enemy could easily upregulate the crapflood to compensate.

mircea_popescu: now then : a fix for the db would significantly improve a few classes of block verification delays ; and it would alleviate blackhole-like behaviour due to that, node's frozen checking a new block. there's at least 3 different dos vectors for other nodes, and a) the foregoing wouldn't help ; b) if it helped the enemy could easily upregulate the crapflood to compensate. ☟︎

mircea_popescu: which can be briefly summarized as "alf : omg all blackhole is disk wait for db ; mp : thatr's a factor, there's more" repeated a dozen times.

asciilifeform: mircea_popescu: if you, using my patch or similar, determined that type1 (verification) blackhole consists of any substantial portion of something other than db wait -- i'm all ears

asciilifeform: mircea_popescu: that was in re the verification blackhole (the most common type observed on dulap)

asciilifeform: the 'type 2' (non-verification) blackhole goes right back to the fundamental question of 'something to all comers', how much disk thrashing does a derp get to invoke simply by coming up with a not-yet-banned ip and a pseudonode. ☟︎

asciilifeform: this is the mega-prize, folx, the blackhole that can carry on unabated for hours, days, weeks.

asciilifeform: unrelatedly, system of two 'wired' trb nodes appears to have marked resistance to 'blackhole'.

asciilifeform: mircea_popescu: block verification is ~an~ issue, world stops for 3-8 minutes when block candidate is being eaten. but is demonstrably not the cause of multi-hour blackhole.

asciilifeform: 1. 'blackhole.' 2. tcpdump on two blackholed trb nodes. multitude of peers emitting 'ping, ping, ping...' and soaking up sockets. 3. hypothesis: killing socket hoggers will dissolve blackhole. 4. 'socket-hogging prb is responsible for blackhole condition'

asciilifeform: mircea_popescu: i'd like to leave dulap as it is , to see how this change affects blackhole, but it does carry some of the 'trucks of britain' problem (as described by mircea_popescu article -- 'trucks over 5 tonnes will experimentally drive on left side of road first!11')

asciilifeform: ben_vulpes: this is a slow-burning project of mine in its own right -- to determine what the fuck EXACTLY these things are doing, when they go 'blackhole'

mircea_popescu: if you recall during the original blackhole debate, this was the argument in favour of "at fault is the broken node code"

asciilifeform: the other interesting tidbit is that a blackhole node is often spoken to (by would-be peers) but never once speaks

asciilifeform: box falls behind, loses peers, begins to sink into classical blackhole behaviour (as it gets dropped by everybody, including fellow trb nodes)

asciilifeform: one theoretical solution to every type of blackhole other than the (theoretical) 'nsa sprays shit directly into the pipe on the backbone' is to make trb actually multiprocess

asciilifeform: mircea_popescu: ultimately for so long as peers are unauthenticated and speak unauthenticated plaintext , there will be type4 blackhole.

asciilifeform: mircea_popescu: blackhole, in my current understanding, is at least 4 distinct things

mircea_popescu: anyway - properly indexing txn so that we deliver the full data set ; properly handling the blackhole thing will actually ruin prb because nobody's fuycking migrating to their new protocol.

asciilifeform: pete_dushenski: be so kind as to post plox some logs from your node during and immediately prior to and after the blackhole

pete_dushenski: http://btcbase.org/log/2015-07-02#1184469 << canonical 'getdata' lulz, never afaik rectified, and an evident blackhole vector. ☝︎

asciilifeform: (check your own collection of blackhole logs, how many are preceded by a 'received block 0000000....' )

asciilifeform: initially idea was that it would be a kind of load balance arrangement, if one were in blackhole state, connections would rout to other. but in the end i did not bother with this, and simply let one hang behind the other, and used the setup simply to observe how 'blackholing' propagates.

tb0t: Project: trb, ID: 35, Type: I, Subject: Investigate blackhole, Antecedents: , Notes: Investigate what might be occuring with the so-called black-hole, described here: btcbase.org/log/2016-12-20#1586635

mod6: !%a trb I "Investigate blackhole" "Investigate what might be occuring with the so-called black-hole, described here: btcbase.org/log/2016-12-20#1586635"

asciilifeform: so we get a snapshot of the, say, 20 minutes of tcpdump prior to node entering blackhole state.

a111: 53 results for "blackhole", http://btcbase.org/log-search?q=blackhole

mircea_popescu: ben_vulpes so listen, the important thing here is, have you managed to reproduce the "blackhole" in an isolated system ?

ben_vulpes: http://btcbase.org/log/2016-12-19#1586383 << http://wotpaste.cascadianhacker.com/pastes/XDTr8/?raw=true ; note that i use the wrong command `getmempool' (line 8587), and that my rpc command of `getmemorypool' doesn't show up at all in the log, but some thirty seconds after the bogus `getmempool' the blackhole symptoms kick in ☝︎

asciilifeform: iirc they do exactly as you might expect, port scan, and if it's your box's turn and you're in, e.g., blackhole, it'll delist

asciilifeform: it is a sucking blackhole of idiocy, so strong that anyone who has dealt with it in any serious capacity is contaminated

a111: Logged on 2016-11-08 18:43 asciilifeform: http://wotpaste.cascadianhacker.com/pastes/l8hg0/?raw=true << THIS type of blackhole is 'false blackhole', it comes from the idiot engine not knowing how to answer ANY message if a block is being verified

asciilifeform: http://wotpaste.cascadianhacker.com/pastes/l8hg0/?raw=true << THIS type of blackhole is 'false blackhole', it comes from the idiot engine not knowing how to answer ANY message if a block is being verified ☟︎

asciilifeform: trinque: the only one i know of that runs continuously without blackhole or other hiccup.

asciilifeform: trinque: quite a bit of blackhole on my nodez, since more or less the beginning

jurov: like, my IP got banned by incapsula (some cloudflare ilk) for no discernible reason and all sites that use it just blackhole me. even "pay here" screen would be better than this.

assbot: Logged on 01-03-2016 08:52:51; ben_vulpes: http://log.bitcoin-assets.com/?date=03-02-2016#1395250 << asciilifeform what was the actual trigger for the blackhole? requesting a specific transaction?

assbot: Logged on 03-02-2016 16:52:56; ascii_butugychag: blackhole results when the worker thread (the one that handles nearly everything) is wedged

ben_vulpes: http://log.bitcoin-assets.com/?date=03-02-2016#1395250 << asciilifeform what was the actual trigger for the blackhole? requesting a specific transaction? ☝︎☟︎

asciilifeform: 'Another curious pattern that emerged during the later stage of the sync process were long delays (4-5 min) during which data was still coming in through the network at a high rate but both disk and CPU were relatively idle and little or no chain updating was occurring. ' << blackhole.