asciilifeform: i contemplate it as more of a 'demolition charge', when trbi exists.
asciilifeform: trinque: incidentally it is not clear, imho, that satoshi's keys are 'edible', they may not be good in practice for getting 'spendable' coin, the popularity of bitcoin per se may well drop catastrophically if you were to move satoshi's coinz
asciilifeform: i did say, 'martian example', not immediate plan to action.
asciilifeform: ('martian' example, but typifies the yet-unknown)
asciilifeform: maybe, who the fuck knows, collect enough data re winblows rng defects, via a future 'uci', to break satoshi's keys.
asciilifeform: ('visegrip' was/is an american gadget, looks rather like cross between pliers, locking forceps, and plumber's wrench, that was pitches as 'The Right Tool For Every Job' when introduced, some time mid-lastcentury)
asciilifeform: Framedragger: i am increasingly finding that 'general purpose db' is, like the infamous 'vise-grip', The Wrong Tool For Every Job☟︎☟︎
asciilifeform: Framedragger: but not right tool for ~this~ job☟︎
asciilifeform: (in hardware this would be O(1) op, in our reality -- slightly slower)
asciilifeform: Framedragger: all you need is to check a read candidate against the current list of active writes.☟︎
asciilifeform: the reason for this ability, is that you never have 'tree rebalances' or whatever other crapolade general-purpose db, and konsoomer file systems , occupy themselves with !
asciilifeform: now, 1 more observation, the table scheme described here, can be safely parallelized, for so long as you ensure that the readers are never writing THE same place being elsewhere written.
asciilifeform: to borrow from mircea_popescu et al, 'it works if you work it'
asciilifeform: (i can make a 400GB file on my disk, right now, and it will cost me a ~constant factor vs 'raw disk' i/o)
asciilifeform: for completeness, i will note that you can model any 'whole disk' variant with an enormous flat file, in userland, at some speed penalty.☟︎
asciilifeform: for the ultimate variant, where we don't even store 'blocks' as such, but merely sequence of specially-marked tx, you ~will~ need whole disk.
asciilifeform: trb will not even need to know whether it was given a real disk, or flat file.
asciilifeform: in fact it can be simply a file descriptor given on command line.
asciilifeform: then it can be readily mapped to physical disk.
asciilifeform: at any rate imho the flat-file variant oughta be tried 1st.
asciilifeform: but you'll need to dedicate an entire disk
asciilifeform: Framedragger: there is a udev trick, iirc, for giving particular users access to a given raw block dev
asciilifeform: Framedragger: you asked at same time as i .. lol
asciilifeform: ( i wonder if there are any traditional fs that will actually give you 16G of contiguous blocks, if asked nicely )☟︎
asciilifeform: (on ordinary userland fs, which you have now.)
asciilifeform: !~later tell Framedragger the table system can be easily prototyped , without writing any kernel code, by using 16G file on ordinary disk. (at the obvious speed penalty.)
asciilifeform: at any rate this is a 'theoretical' problem, imho 'not burning'.
asciilifeform: ( and ~yes~ right now it is very easy to see 'who wired to whom' by looking at ssh, but in the future we will presumably route multi-hop, via a gossiptron, and it will be less obvious )
asciilifeform: maybe mircea_popescu can cut it, with his knife.
asciilifeform: by looking at who never plaintcp's to whom on 8333 !
asciilifeform: BUT this would make it very easy for the enemy to determine who is 'wired' to whom
asciilifeform: and yes i could put in a '--noplaintextpeer=x,y,z...' flag, BUT
asciilifeform: (can, say, ban them from talking on 8333 to each other in iptables, but this is stupid because then they will not share the perfectly-good ip with OTHER peers)
asciilifeform: i'd like to think of an elegant solution to this☟︎
asciilifeform: (right now, e.g., zoolag and dulap happily also find each other over ordinary peer table and connect plaintext)
asciilifeform: trinque: fwiw i still know of at least 1 unsolved tickle re 'wires' -- how to avoid multiple redundant connections
asciilifeform: 'if one synchronized swimmer drowns, must the others?' (tm) (unknown)
asciilifeform: it'd suck if dulap ~and~ deedbot choked in same day, say.
asciilifeform: (would like to test 2way 'wiring' first on a non-infrastructural set of boxen )
asciilifeform: you don't need any moar kludges, the scheme described, will work.
asciilifeform: why would you ever not have the nx bit set for a motherfucking table
asciilifeform: ( however it will be intuitively obvious, to anyone familiar with x86/x64 and similar archs, that this is physically possible. i.e. you never actually need to store a contiguous empty GB in memory, if you can manipulate the page table )
asciilifeform: but THIS i will leave as an exercise for the reader.
asciilifeform: you can use x64's page table to 'cheat' and store a sparse form !☟︎
asciilifeform: the ~other~ thing i'll point out, is that you do not in fact need 16GB of ram, to implement that table , if you can do it in the kernel
asciilifeform: i'll round this out by observing that potentially you might be able to get away with less than 32bits of table (i.e. less than 16GB of space)
asciilifeform: ought to help those folx for whom kindergarten happened long, long ago, to picture the subj of today's thread.
asciilifeform: Framedragger: there was old thread with mircea_popescu , where he stated that usg and china attempted it at same time, and perma-deadlocked☟︎
asciilifeform: (enemy is welcome to bash his skull to a pancake against the cement wall)
asciilifeform: much cheaper to reindex a trb node, what, 1 night, than for enemy to bake new asics.
asciilifeform: at any rate, working around this idiocy would be very cheap -- say we index by top32 of keccak(txid) instead of plain txid. in the event of.☟︎
asciilifeform: (you could in fact use a repurposed miner, for this, as i understand)
asciilifeform: but this'd cost'em moar than simply to mine.
