asciilifeform: ben_vulpes: aite

asciilifeform: http://en.rightpedia.info/w/Ashley_Rae_Goldenberg << first-class lultron, almost certainly written, imho, by subj

asciilifeform: Slow Write: : 65218ms << yougettheidea.

asciilifeform: Slow Write: : 44619ms << lel

asciilifeform: https://archive.is/http://communismkills.tumblr.com << for the curious.

asciilifeform: iirc was hounded by clitlerists for years

asciilifeform: lol, membersonly nao

asciilifeform: ^dingdingding^

asciilifeform: !~google communismkills

asciilifeform: nfi; but i have idea how to find out !!

asciilifeform: http://btcbase.org/log/2017-02-25#1617860 << i once met a chick who stated that a major life goal of hers was to be Officially Denounced by splc. ☝︎

asciilifeform: (oops, dupe)

asciilifeform: lel, old classix! not debian!!11

asciilifeform: !$ ssh 183.246.69.24 112.16.4.21 183.246.73.7 183.246.73.7

asciilifeform: in other lelzies, https://archive.is/pwN40

asciilifeform: 2014 neh

asciilifeform: bdb Must Die.

asciilifeform consistently measuring ~90+% spent on txindex db write.

asciilifeform: oughta be 'rer', neh

asciilifeform: aaah

asciilifeform: http://btcbase.org/log/2017-02-25#1617860 << after n years i still am in the dark, re what exactly is a kek, and where to get one ☝︎☟︎

asciilifeform: why didja link to this, ben_vulpes ? looks like another 'keybase'

asciilifeform: the user during installation. This code is a 128-bit value that can recreate the key material, and can also be used to regenerate the private key on a different device.' << eww

asciilifeform: http://btcbase.org/log/2017-02-25#1617855 >> 'In this initial version, E2EMail hosts its own keyserver. During app installation, it automatically generates an OpenPGP ECC key and uploads the public half to the keyserver. The keyserver accepts it if the user-id in the key matches an OAuth mediated check against the user's email address. The private half is stored locally, but can be regenerated via a secret "recovery code" provided to ☝︎

asciilifeform: ^ to date

asciilifeform: meanwhile, http://wotpaste.cascadianhacker.com/pastes/OiRWC/?raw=true

asciilifeform: !~later tell mircea_popescu http://wotpaste.cascadianhacker.com/pastes/be73x/?raw=true

asciilifeform: http://btcbase.org/log/2017-02-24#1617687 << carport ? ☝︎☟︎

asciilifeform bbl, meat

asciilifeform: (~100-fold difference, on avg.)

asciilifeform: it also explains why the ssd box beats the living shit out of the mechanical one.

asciilifeform: this is where ~100% of block-eating time is actually spent.

asciilifeform: this is it.

asciilifeform: there are no substantial 'other large parts', detectably ☟︎

asciilifeform: looks like my original hypothesis (disk thrash) is supported.

asciilifeform: (EXPERIMENTAL) Blackhole Revealer.

asciilifeform: http://therealbitcoin.org/ml/btc-dev/2017-February/000254.html

asciilifeform: mircea_popescu, ben_vulpes , mod6 , et al:

asciilifeform: ACHTUNG, PANZERS!

asciilifeform: barfalicious.

asciilifeform: *its thing

asciilifeform: waiting for bdb to do it's thing.

asciilifeform: apparently this is what ~all 'blackhole' consists of.

asciilifeform: the db writes.

asciilifeform: i.e. http://btc.yt/lxr/satoshi/source/src/db.h?v=makefiles#0085 << .

asciilifeform: ^ ~85% of time

asciilifeform: http://btc.yt/lxr/satoshi/source/src/main.cpp?v=makefiles#1002

asciilifeform: 3, 2, 1...

asciilifeform: in all cases.

asciilifeform: mircea_popescu: ~80-90% of time spent in ConnectBlock

asciilifeform: http://btc.yt/lxr/satoshi/source/src/main.cpp?v=makefiles#1136 << the more typical delay spot; e.g., 109 sec. on block 454532.

asciilifeform: was aiming to find 'obvious culprits'

asciilifeform: eventually

asciilifeform: and times pried out of log, also by hand.

asciilifeform: this run is 100% by hand

asciilifeform: mircea_popescu: at some point, when i find out how to get gprof to run with musltronic/static binary

asciilifeform: http://btc.yt/lxr/satoshi/source/src/main.cpp?v=makefiles#1166 << 200 sec !!!

asciilifeform: but reorg on dulap on ~every restart.

asciilifeform: but interestingly 0 reorgs on zoolag in past couplea months

asciilifeform: reorg takes motherfucking forever

asciilifeform: quite likely. 1sec

asciilifeform: nope

asciilifeform: match the args.

asciilifeform: http://btc.yt/lxr/satoshi/source/src/main.cpp?v=makefiles#1121 << this is the one

asciilifeform: mircea_popescu: you're in wrong function

asciilifeform: mircea_popescu: shortly...

asciilifeform: 454523: 78 sec. (same)

asciilifeform: 454520: ~98 seconds; ditto

asciilifeform: 454520 has a reorg, and spent 219 seconds, also ~entirely in same spot

asciilifeform: mircea_popescu: here's typical example: block 454521 on dulap : AddToBlockIndex: ~90 sec: http://btc.yt/lxr/satoshi/source/src/main.cpp?v=makefiles#1212 << 99.98% of this interval

asciilifeform: shortly.

asciilifeform: http://btc.yt/lxr/satoshi/source/src/main.cpp?v=makefiles#1310 << ~95% of ProcessBlock() time spent here in all cases

asciilifeform: i got the thing profiling as we speak.

asciilifeform: in other noose, discovered that the actual contents of a block are 'red herring' re verification, and we're actually looking at idiot lock deadlock

asciilifeform: point

asciilifeform: mircea_popescu: why wait

asciilifeform: mircea_popescu: on dulap, zero instances in 84GB of log.

asciilifeform: mircea_popescu: this was on zoolag after <24 hrs.

asciilifeform: AcceptBlock ( http://btc.yt/lxr/satoshi/source/src/main.cpp?v=makefiles#1370 ) is the bottleneck

asciilifeform: and here we go, on dulap : ... SetBestChain: new best=000000000000000000d5 height=454507 work=79028340706396234909993360 ; AcceptBlock() success : 401334ms ; Tested candidate block in 401349ms

asciilifeform: [BTC-dev] (EXPERIMENTAL) Block Timer.

asciilifeform: http://therealbitcoin.org/ml/btc-dev/2017-February/000253.html

asciilifeform: mircea_popescu, ben_vulpes , mod6 , et al :

asciilifeform: ACHTUNG, PANZERS!

asciilifeform: nfi, some foot soldier.

asciilifeform: minority, rather.

asciilifeform: would seem that these are a type of pseudonode / misc. attacker, that comes in two varieties, one aimed at recent prb (majority), the other -- more trb / old-prb - flavoured.

asciilifeform: of these, 117106 report ver. 60000 ; but 1873 reported 70002 .

asciilifeform: 118979 (yes) connection attempts of this nonsense in 84GB (yes) of dulap log.

asciilifeform: in other lulz, there is a large population of nodes reporting 'version message: version 60000, blocks=350000' for all eternity (typically they auto-disconnect when discovering trb ver.) . anyone know who they belong to, and wtf ?

asciilifeform: keeping in mind also that std::bad_alloc can result from heap corruption, not only from failed allocation !

asciilifeform: mircea_popescu, ben_vulpes, mod6, shinohai , et al : anyone ever notice these : http://wotpaste.cascadianhacker.com/pastes/DfsKP/?raw=true << on a node nowhere near OOM condition, multiple GB free

asciilifeform: meanwhile, in the monkey cage, https://archive.is/l8ZYG >> a clitlerist: 'oh noez, best prepare to suppress the rebellion that will come when we depose mr.t'

asciilifeform: somebody's pissing crafted garbage into mempool, and buncha idiots happily relay it...

asciilifeform: now -- pestilential.

asciilifeform: ^ used to be ~unknown

asciilifeform: ERROR: AcceptToMemoryPool() : transaction with out-of-bounds SigOpCount

asciilifeform: in yet-other lulz:

asciilifeform: in other finds, there are today perhaps two dozen bitcoin nodes with serious 'uptime'.

asciilifeform: shinohai: what means 'open all of' ? gotta have something listening to see 'open' port