jfw: you think it's good enough? readable? works well? "close enough for government work" as the contractors said back home?
jfw: not entirely, I know you were btc-skeptical at first, and MP invited you to review his exchange
jfw: right, there was a 'gypsy chicken recipe' involved back then
jfw: insufficient magic numbers in the bdb locking system config
jfw: (to be pedantic, 'at least skimmed' does not apply to genesis, though I've started on a gradual full readthrough.)
jfw: yes, that's a challenge; otoh, I find it ~impossible to reason about what wtf those pistols currently do anyway
jfw: perhaps to make matters worse, I'm not sure there's any guarantee that original has same behavior as itself on different occasions.
jfw: the bdb locks too; I imagine it'd depend on how exactly your b-trees ended up layed out due to past history as to how many pages it needed to lock and thus what exact block it would stick on.
jfw: well for starters it needs to update an index of where txns are spent, no?
jfw: does that require changing the block format though?
jfw: how do you find where the ones being spent are, if you don't have an index by txid?
jfw: but tx index is a tree then, no? (or hash table which isn't guaranteed access time)
jfw: and in case of collision of first 32 bits?
jfw: sounds the same as any other hash table, so not sure why the objection to btree, but ok, maybe implementation ends up simpler.
jfw: anyway, mind returning upstack for now? I'll assume this scheme works fine; where does that leave TRB work?
jfw: re sync, quite; for instance I presently can't transact because I've had a node sitting on desk for >month that spending most of its time doing nothing but receiving bastard blocks until killed & restarted.
jfw: and I've nfi why trb peers send me non-current blocks for which I lack antecedents
jfw: they just guess at what block numbers I need?
jfw: perhaps it's that - they're relaying new blocks only, and problem is that the sync 'ran out of steam' after leaving 'bootup' phase.
jfw: sure, s/new/new-to-them/ then
jfw: Now - perhaps this is where I interrupted re mmap db - is it your view that efforts at this point are best spent on rewrite while problems with the ref. impl. are handled reactively?
jfw: asciilifeform: alright, thanks.
jfw: jurov, trinque: I'm curious whether you concur with the above. Gotta run now but will check log.
snsabot: (asciilifeform) 2020-05-03 asciilifeform: the ~whole calamity of trb is that the internal representations for ~everything are thoroughly braindamaged. if you fix this, you get ~0 of the orig. trb remaining, i.e. same as total rewrite. if you don't, you get 100k loc of glue.
trinque: jfw: mmmm it's hard to say; the thing's a hellish tarpit for sure.
trinque: were I taking it on, I'd probably pare the thing down a bit yet before rewriting
trinque: I have a patch on my desk that cleaves off the entire wallet and stuff only used by wallet
trinque: you're welcome to it if it's helpful
trinque: it does cut the weight a bit
trinque: probably wireshark protocol analysis is a better path forward eh?
trinque: honestly if the piece of shit relies on implicit behavior, better out with it now than later
trinque: would be neat to see an item produced that horks and sprays blocks, and doesn't worry about whether it's doing it in exactly the same way as trb.
snsabot: (asciilifeform) 2020-03-01 asciilifeform: shinohai:
this btw confirmed. i did experiment, if one sends that extra byte, prb noades do in fact send addrs. (and yes some of'em ipv6, have to be thrown out)
shinohai: asciilifeform: Do you, offhand, know the link to the thread re: bdb bug ?
shinohai: oh fuck NOW I remember that. ty asciilifeform
jurov: asciilifeform: i don't have node atm, the hdd died and waits for reinstall. no idea whose is the radiolan.sk one
jurov: will ingest the rest of log tmrw