asciilifeform: astonishing that this crud ever worked at all !
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☟︎
asciilifeform: it sure as fuck isn't . which is why it has to be massaged out from the log segment known to contain 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 . )
asciilifeform: but, then , there ought to be a 0000000000000000013 getenv
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..) ,
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: or neither -- a prb-everywhere-and-not-a-drop-to-drink problem , conceivably.
asciilifeform: because this could be a 'pulling' problem , a 'pushing' one, or even both at once
asciilifeform: mircea_popescu: if not mega-seekrit, did this node peer with well-known trb nodes (e.g., mine ) ?
asciilifeform: if ben_vulpes's parser worx -- then yes
asciilifeform: (does not need to be, obviously, literally in this form, but the same effect)
asciilifeform: well yes. hence why i said 'draw tree', i.e. list the blocks in form, e.g., b1->b2->{b2a1, b2b1->b2b2->b2b3} << in this example, b2a1 is orphanlet
asciilifeform: ( i naively supposed that meaning of 'block debugger' is obvious to reader )
asciilifeform: entirely not connected with this thread, pete_dushenski
asciilifeform: pete_dushenski: block debugger would be like my 'blkcut', except for ~block~, as output by blkcut, would display header, transactions, etc.
asciilifeform: pete_dushenski: i don't see a block debugger in there
asciilifeform: what i meant is, i specifically do not have the most basic means of answering the most basic questions about the blocks, other than their bitwise identities as pictured earlier
asciilifeform: upstack: the sad thing is, i am not even equipped to answer whether 419373 was part of an orphanable forklet on mircea_popescu's node ; and if so, when orphaned at large
asciilifeform: well it keeps asking for 419374, and getting 'wrong' one.
asciilifeform: trb's block push/pull mechanism is so retarded, that it is possible for a node to go for eons in a wedge, simply from never receiving the necessary unwedge blocks.
asciilifeform: there is a much simpler, though disheartening, explanation
