log☇︎
211700+ entries in 0.131s
mircea_popescu: very technically ; i don't think it too likely.
asciilifeform: 'lost connectivity' can mean blackhole, for this purpose.
mircea_popescu: i do not believe node lost connectivity for as long as five total minutes, let alone straight minutes ; this however is a very iffy point to prove because hey, ~connectivity~.
mircea_popescu: asciilifeform no it's clear how it should work ; whether it ends up working that way is open, but hey.
mircea_popescu: i didn't know males could do that.
asciilifeform: mircea_popescu: meanwhile i solved it with anal telekinesis !!111
asciilifeform: whipping to death, and throwing to dogs, is all things considered a merciful reward for someone who designs a system like this.
asciilifeform: which you are expected to do (because he was dropped as a child) using either a bastard's header, recursively as discussed earlier, or 'getheaders'
asciilifeform: to request a block from a peer, you have to somehow find out its header hash
asciilifeform: and i'll repeat, tardoshi offered NO way to request blocks BY HEIGHT !!
asciilifeform: the network has rotten to the point, where it probably is.
asciilifeform: and yeah this ought not to be necessary. but i suspect that it -- is.
asciilifeform: at this point i will recommend that -- when everyone has satisfied himself that 'wires' work -- every trb node oughta be wired to at least 1 known trb node
asciilifeform: i'll add that 'week' is merely a guess, from my arse; perhaps a couple of hours is enough, under the right circumstances ( idiot peers + sufficiently many blocks made in interval )
asciilifeform: though mircea_popescu's wedge is preventable, what trb really ought to do is start sending http://btc.yt/lxr/satoshi/source/src/main.cpp?v=makefiles#1735 to all peers, starting with any 'wires' if present, whenever it goes for >1hr without a new block
asciilifeform: (whether succeeds will depend 100% on who the thing ends up connecting to on boot )
asciilifeform: : the idiot specialcase -- will trigger.
asciilifeform: this is also why mircea_popescu rebooting the node, will almost guarantee to bring it to life
asciilifeform: and, notice, it asks first-chance-strangerfuck for the blocks-from-genesis.
asciilifeform: trinque: like this, http://btc.yt/lxr/satoshi/source/src/main.cpp?v=makefiles#1735
asciilifeform: note that ProcessBlock() only ever asks ~the bastard-supplying peer~ for the bastard's prevblock. ☟︎
asciilifeform: ( and with each new block mined, this depth is 1 deeper ! )
asciilifeform: dollars to doughnuts, it lost connectivity for a week or two. at which point the necessary bastardry-recursion depth became longer than any of his node's peer's typical uptime.
asciilifeform: btw i am now nearly certain re what happened to mircea_popescu's box
asciilifeform: this routine is inherited from tardoshi btw, i did not invent it.
asciilifeform: (it's effectively recursive. when bastard comes in, we ask for its predecessor. which, if it is also a bastard to us, triggers same process. ad infinitum, until we get the thing we actually want, which is our next block )
asciilifeform: btw mircea_popescu et al , is it obvious how http://btc.yt/lxr/satoshi/source/src/main.cpp?v=makefiles#1364 works ? or do i need to explain
asciilifeform: laters then
mircea_popescu: aite, ima go examine beauty in the flesh. will push the thing to web when it's done.
asciilifeform: let's see if anyone answered . gotta see the log.
asciilifeform: trb's response to an orphan is 'tell me mybestheight+1th block DAMNIT'
mircea_popescu: what's this refusal supposed to be ?
asciilifeform: and every time, it was refused.
mircea_popescu: yeah. then i can't conceive. it did complain thousands of times of orphans, which implicitly resulted in block being sought.
asciilifeform: it still happens, see the quoted src
mircea_popescu: is this no longer happening in trb ?
asciilifeform: aaaaaha. not a typo.
mircea_popescu: did the orphanage burner ruin trb 's chances of unwedging in this situation ?
asciilifeform: astonishing that this crud ever worked at all !
mircea_popescu: yes ; and that one should have activated EVERY TIME.
asciilifeform: the other is the idiocy where it asks, but only ~the first node it talked to when booting~ !
asciilifeform: one is to ask bringers of orphan blocks for our currentheight+1.
asciilifeform: so mircea_popescu , as you can probably tell, if node misses the window when $block was being actively thrown at it, then it has only these two knobs for attempting to get it ☟︎
mod6: ok, np.. thanks for pointing it out. :]
mod6: <+mircea_popescu> ill complain to mod6 also. << im about 18 hours behind on the log, will catch up and will revisit tomorrow.
mircea_popescu: yeah. and since you mention it, trb-i definitely needs a clarified push-or-pull model because the current system is the soul of unconsidered adhocery
asciilifeform: (and grunting through the mempool)
asciilifeform: at all other times, it passively sits with open mouth, waiting for blox to fall from the heavens
asciilifeform: http://btc.yt/lxr/satoshi/source/src/main.cpp?v=makefiles#1364 and http://btc.yt/lxr/satoshi/source/src/main.cpp?v=makefiles#1735 are the only times a trb node asks for blocks explicitly from peer ☟︎
asciilifeform: really all of the procrustean truncations gotta go.
asciilifeform: it sure as fuck isn't . which is why it has to be massaged out from the log segment known to contain it.
mircea_popescu: how much would you trust eleven bits ?
mircea_popescu: asciilifeform part of the problem is that "00000000000000000136" is not much of a unique id in thefirst place.
mircea_popescu: all of these'd have also made me notice it.
asciilifeform: remains -- to see the log (was it ever offered 00000000000000000136 in an inv vector ? and, did it ever request it from anybody ; and lastly, did it ever receive . )
mircea_popescu: but before that it returned the plainest normalcy, 37 connected nodes etc.
mircea_popescu: i did turn off the node to be able to push out meaningful bdb item think about it.
asciilifeform: ( if at any point an exception was shat , it'll be cached there )
asciilifeform: mircea_popescu: if you have not yet switched the box off -- what does getinfo return ?
asciilifeform: the behaviour is inherited from tardoshi
mircea_popescu: no argument there ; you however may in turn recall that trb is by inheritance an utterly chtonian horror of heap allocation etc.
asciilifeform: (this was a major brain-melter during the prbisms thread)
asciilifeform: mircea_popescu: you might recall that trb does not attempt to decode tx scripts (yes) when verifying block
mircea_popescu: shinohai but it's in teh logz!!
shinohai: Whatever the outcome of the node wedge fix is, I need to write all this down as it may be a powerful tool to fuck with enemy in the future.
mircea_popescu: 91.8 0.0 11:57.45 gzip << fancy this wonder.
mircea_popescu: ie, you ~could~, theoretically, write such shit into a block that it wedges nodes.
mircea_popescu: loads of all that "unable to decode address" things, which is my only vague "there could be something here".
ben_vulpes: slow to the show, but http://mimisbrunnr.cascadianhacker.com/blocks/419373
mircea_popescu: this seems an easy enough to fix item.
asciilifeform: but, then , there ought to be a 0000000000000000013 getenv
mircea_popescu: ill complain to mod6 also.
mircea_popescu: asciilifeform no, i'll complain to you, because really there's no need trb logging be THIS RETARDED
asciilifeform: sooo somewhere in mircea_popescu's log, there'll be a getinv for 0000000000000000036, the prev block, then for this final one, 0000000000000000038 (complain to tardoshi re the procrusted hashes, not to me..) ,
mircea_popescu: "if they can do it to this guy they can do it to most any guy" is the idea here.
asciilifeform: i don't keep any boxes on mars, that i can only check every 9 mo
asciilifeform: ( i lean to the latter hypothesis , it is a thing that regularly happened - admittedly not to the extent seen in mircea_popescu's specimen -- among my nodes, and was why i could no longer put off the 'wires' thing )
asciilifeform: because this could be a 'pulling' problem , a 'pushing' one, or even both at once
mircea_popescu: not really ; unless yours randomly came to it.
asciilifeform: mircea_popescu: if not mega-seekrit, did this node peer with well-known trb nodes (e.g., mine ) ?
mircea_popescu: let's do that then
mircea_popescu: i guess i'm just going to publish the log altogehter ?
asciilifeform: or, say, 100,000 ln. of it, ought to suffice.
asciilifeform: mircea_popescu: can you get the log inclusive of the last ACCEPT (case-sensitive) and all lines after ?
asciilifeform: mircea_popescu: 1 more thing
mircea_popescu: (all those and many others would have popped it for review you realise)
asciilifeform: ever reset dirtily ? corrupt tx index ?
ben_vulpes: previous block hash claims to be 0000000000000000036D2AFA6270C3A58C9A2093C706F0EACA4018E54BF2879C
asciilifeform: mircea_popescu: anything peculiar re that box, say, disk full ?
mircea_popescu: anyway, i plan to restart it sometime tomorrow, if anyone wants further datas it's a fine time to say.
mircea_popescu: ah in that sense. yes.
asciilifeform: it was never orphaned, and never had to get reorged out
asciilifeform: because the last block in mircea_popescu's blk0036 is a main-chain block
mircea_popescu: ie the node appeared fine.
mircea_popescu: it's not exactly a common condition, this ; which is both why i said something and why it wasn't noticed. simply no test for ~this~ never seen before nonsense
asciilifeform: fwiw the heathens seem to have this same 419373 , https://blockchain.info/block-index/1242663
asciilifeform: it sat there wedged ever since ?!
ben_vulpes: doubtful that i would find it in the web interface, but possible in the blocks.
asciilifeform: ben_vulpes: can you find this block in mimisbrunnr ?
ben_vulpes: oh and this doesn't actually render the header in a digestible form. okay, disregard.