asciilifeform: !~later tell phf https://github.com/hanshuebner/vlm << sent in by a reader. somehow this has been just sitting there since '09, without my noticing

asciilifeform: phf: https://github.com/hanshuebner/vlm/blob/master/c-emulator/emulator.c looks like enough to build that fpga ivory...

asciilifeform: same link??

asciilifeform: https://github.com/hanshuebner/vlm/blob/master/admin/Beta-test-customers.text << lenat!!!

asciilifeform: from 'beta' list -- r.v. guha, turns out, is http://www.guha.com/cv.html , also cyc

asciilifeform: (now absorbed, apparently, into google)

asciilifeform: and apparently responsible singlehandedly , or so himself claims, for one of the more infamous fake wotrons.

asciilifeform: 'epinions'

asciilifeform: and for the existence of rdf. motherfucker.

asciilifeform: https://groups.google.com/forum/#!topic/comp.lang.lisp/BebxJD27sao << ancient lulz found when trying to find what the fuck 'mcc' was

asciilifeform: apparently, long-gone 'Microelectronics and Computer Technology Corporation' in austin, tx.

asciilifeform: mircea_popescu: i know a handful ☟︎

asciilifeform: holy fuck how can something the size of mcc vanish without ANY trace

asciilifeform: not so much as a broken shard of babylonian clay pot.

asciilifeform: 'MCC was part of the Artificial Intelligence boom of the 1980s, reportedly the single largest customer of both Symbolics and Lisp Machines, Inc. (and like Symbolics, was one of the first companies to register a .com domain). ' << aaaah apparently THAT's how.

asciilifeform: apparently was a consortium of mainframe makers, serious r&d corps, etc., worked on cad. utterly thermonuked by lisp winter and the microshitization of computing.

asciilifeform: http://wotpaste.cascadianhacker.com/pastes/6zrqi/?raw=true << re mcc, of archaeological interest.

asciilifeform: 'For a long while I was doing research in software productivity. We began asking, ‘What is wrong? And why is it so difficult? Why is it so costly? What is complexity?’ It led me to interesting research, but nothing happened. We did not discover how to formulate or mathematically express the idea of program complexity. Not program complexity in the sense of algorithmic complexity—NP-complete problems and all that jazz—but the

asciilifeform: complexity of programming.'

asciilifeform: https://stallman.org/articles/texas.html << further lulz re rms guest lecture at mcc.

asciilifeform: (historical)

asciilifeform: featuring 'nasal plant sex'

asciilifeform: http://btcbase.org/log/2017-03-10#1624012 >> 'La Socité Francaise de Médecine Morphologique et Anti-Age ' << lelzz ☝︎

asciilifeform: http://btcbase.org/log/2017-03-10#1624006 >> 'Sports Memorabilia & Promotional Products' >> 'Sport It, Inc.', some nowhere, usa. spamola, and diddleddebian. ☝︎

asciilifeform: y'mean usg's 'unsinkable carrier' ?

asciilifeform: ( their actual sales pitch from the period!11 )

asciilifeform: 0

asciilifeform: mod6: anything at all might need regrinding, depending on your particular tree

asciilifeform: mod6: had something more specific in mind ?

asciilifeform: goodbye_pingers is to be shitburied

asciilifeform: imho.

asciilifeform: it achieves 0.

asciilifeform: (at most 0 !)

asciilifeform: blackhole odometer is probably of ~very~ limited interest to folx who aren't asciilifeform

asciilifeform: 'block timer' is obsoleted by blackhole odometer.

asciilifeform: so we're left with null set.

asciilifeform: mod6: you can safely consign these to 'experimental tree' or wherever.

asciilifeform: same place shiva lives.

asciilifeform: 'poorly conceived crackpotteries' or what it was mircea_popescu called'em.

asciilifeform: aha

asciilifeform: http://btcbase.org/log/2017-03-10#1624127 << the classic alpha ver you described was in one of the subdirs, aha. and a recent g5 one (that dks mentioned to me in 2010 when he delivered the long-awaited genera alpha to my rupturefarm) ☝︎

asciilifeform: http://btcbase.org/log/2017-03-10#1624127 << the c src i linked to does not appear to match this description, seems to be honest emulator ☝︎

asciilifeform: http://btcbase.org/log/2017-03-10#1624129 << mno ☝︎

asciilifeform: phf: link to yours some time ?

asciilifeform: http://btcbase.org/log/2017-03-10#1624146 << alpha was already half-dead when hp swallowed compaq, in '02. iirc compaq shitburied it in '01 and sold all rights to intel, who proclaimed the arch now known as 'itanic' as its replacement. ☝︎☟︎

asciilifeform: amd hired the designers away

asciilifeform: and turned from a sort of 'cyrix' , piss clones maker, into actual cpu house

asciilifeform: mircea_popescu: 'itanium', vliw monster for which nobody was ever able to make a useful compiler

asciilifeform: afaik only known working examples are in usg heathen pits

asciilifeform had a prof in uni who taught systems architecture (cpu design) with itanic as 'what not to do'

asciilifeform: re alphas, i am rather fond of the alpha, i have several here, possibly mentioned before

asciilifeform: not quite 'fits in head' machine, but 'fits in book'

asciilifeform: one perverse fact, is that microshit had a winblowz ecosystem for it, ready to go, it could have been he 'designated winner' in intel's place. except -- no, because gotta target the konsoomer chump junk ...

asciilifeform: ( the sane folx, who had alphas with tru64, openvms, etc, went 'wtf why would i even think of winblowz' -- which wouldn't do. whole edifice 'musted die' )

asciilifeform: http://btcbase.org/log/2017-03-10#1624188 << i built myself a 'games box' , not long ago, 'to unwind', but turned out that the part of my head that was able to enjoy this, had atrophied, found myself constantly 'if i'm this awake, oughta be running $experiment, finishing up $unfinisheds', etc. ended up giving the (princely) fuckofftron to brother to play with. ☝︎

asciilifeform: somehow, long ago internalized mircea_popescu's above point re the model airplanes.

asciilifeform: 'if not you, then who' (tm) (r)

asciilifeform: trinque: you gotta log in as shown in the recipe

asciilifeform: trinque: i.e. your login is 'tunnel', not 'deedbot'

asciilifeform: worx?

asciilifeform: that's slightly slower, looks like, than the old db.. ☟︎

asciilifeform: ok backtracking : what means 'resolution'

asciilifeform: does this include the actual read ?

asciilifeform: aah

asciilifeform: also, on what

asciilifeform: ssd ?

asciilifeform: and on top of what (ext4 ? )

asciilifeform: and connected how ? ( sata2 ? 3 ? )

asciilifeform: wtf is 'dockerfs' ☟︎

asciilifeform: to rephrase, this would tell something useful if we had with what to directly compare it with -- what operation in ye olde bdb would this measure correspond to ? ☟︎☟︎

asciilifeform: let's put down in the log, what exactly ye olde bdb does, that eats 99+% of trb's wall clock:

asciilifeform: it exists (wallet idiocy aside) in trb for 1 purpose and 1 purpose only

asciilifeform: ... so that a 256-bit turd, e.g., 3ec455a2a84e978687a3990cec73f36b324fbd28e03603c6d9fc52018b001558, can be taken and matched to a block # where said tx lives. ☟︎

asciilifeform: and likewise when a new block comes, all of the tx in it, get indexed this way.

asciilifeform: lookup+store

asciilifeform: btw i will also put down in the log, one very simple possible algorithm for a 'txidx-fs' : ☟︎☟︎☟︎

asciilifeform: picture a 16GB contiguous block of ssd. you cut it up so that it corresponds to 2^32 x 32bits.

asciilifeform: now you store the table as follows: the top 32 bits (e.g., 3ec455a2 from above) are an array index into this table ☟︎

asciilifeform: if there are no collisions (i.e. there is no other tx on the disk whose id begins with 3ec455a2) then that entry in the array IS the block index where the tx lives.

asciilifeform: after which finding the actual tx is an O(N) operation in the block, with small N (the tx in the block)

asciilifeform: lemme finish plox

asciilifeform: BUT if there are collisions, the upper bit of the 32bit entry, is set. and then we know that the lower 31, are an index into another contiguous array

asciilifeform: and there we find ~lists of block indices~, so the machine might have to try 2 or 3 blocks before it finds tx.

asciilifeform: how to ~write~ to this data structure is, i think, obvious to the reader, i do not need to describe.

asciilifeform: anyway this is the simplest physically-possible scheme.

asciilifeform: but, thing is, it won't work any better on mechanical disk than the old bdb. and imho it is quite impossible to make variable-length tx bitcoin work well on mechanical disk, with modern spamola level.

asciilifeform: however it does have the advantage of not using 10,000,001 lines of ext4 open sores crapolade for anything.

asciilifeform: this whole thing would probably fit in ~1,000 lines of c.

asciilifeform: and in-head.

asciilifeform: Framedragger: it is literally the smallest number of moving parts i can think of , that'd do the job.

asciilifeform: also on a reasonable box you can keep the l1 table in ram

asciilifeform: so then you have 1 disk seek per tx, rather than 2.

asciilifeform: ( or, in the case of ext4 or other konsoomer fs, fuck-knows-how-many ! )

asciilifeform: Framedragger: correct

asciilifeform: block where tx lives.

asciilifeform: Framedragger: it depends how many collisions per 32bit head

asciilifeform: one seek, on a standard disk, gives you at least 4kB (blocks are 512b, but no disk made in past 20 years actually ~stops at~ 512)

asciilifeform: remember, we are contemplating contiguous blocks on disk

asciilifeform: aha.

asciilifeform: if you're willing to blow another 16GB, you can have an l2 table ☟︎

asciilifeform: on same principle

asciilifeform: Framedragger: it's good for many, many times the current cumulative-tx

asciilifeform: you'll have somewhere between 0 and 2 , statistically, tx per 32bit table entry.

asciilifeform: yes, first time, i kept waiting for someone to open a schoolbook and describe this very elementary algo

asciilifeform: it has obvious minus, in that you need a kernel driver

asciilifeform: if you want to actually have the contiguous 16GB

asciilifeform: however mircea_popescu's 'let's patch ext4' has same.

asciilifeform: i dare say the tabular algo is simple enough to actually be implementable.

asciilifeform: Framedragger: if you want your own fs, and to write to contiguous disk, you do

asciilifeform: who the fuck wants trb running as root

asciilifeform: (you may as well stuff it in the kernel, then)

asciilifeform: the Right Thing would probably be to have a very simple kernel driver that takes a specially-marked disk partition and gives userland trb linear use of it, as plain array ☟︎☟︎

asciilifeform: ...rather than to have any serious number crunching in kernelspace

asciilifeform: also this is probably obvious, but you want separate disk for this

asciilifeform: physically

asciilifeform: from the one you are running from

asciilifeform: if you want serious speed.

asciilifeform: ideally you would even have separate disks for blocks and tx indices.

asciilifeform: ok, now question for ben_vulpes , trinque , mircea_popescu , et al : anybody got a quick c proggy that will eat blkcut's blocks and produce a linear list of tx ? i'd like to actually calculate the current 32bit tabular collision rate.

asciilifeform: it is statistically possible that we don't even have ONE collision yet ☟︎

asciilifeform: (and thereby a 16GB l1 table would give you wholly in-memory index for ~all tx lookups)

asciilifeform: btw Framedragger , we can do 1 better than 'block index'

asciilifeform: say we put down blocks on 1024 byte alignments.

asciilifeform: nono listne

asciilifeform: then a 31bit (remember, highest bit means 'go to l2 table') offset gives you a 2^^41 bit space in which your table entry can point to the beginning of a block.

asciilifeform: or, rather, to where-to-start-looking-for-tx

asciilifeform: ^

asciilifeform: so we dispense with the O(N) dumb search inside-block

asciilifeform: Framedragger: alignment in this case means that we can point ~inside~ blocks, supposing they are stored linearly on disk

asciilifeform: so long as we are ok with having to chug through 1023 bytes of 'not here yet!'

asciilifeform: which costs us 0 because no disk made in last 20 yrs reads any less than 4kB on 1 seek.

asciilifeform: point being, to point at a tx sitting on a multi-TB disk, you don't need to be able to address it ~bytewise~

asciilifeform: thinkaboutit.

asciilifeform: it goes to l2 table

asciilifeform: which can take 2 basic forms, depending on your storage budget

asciilifeform: if you're 'rich', it can be a table entirely like l1

asciilifeform: where if top bit of the entry is not set, you have your where-to-go-to-find-tx-on-disk result

asciilifeform: and if set, you gotta look at the next machine word (each entry has a certain amount of space for collisions)

asciilifeform: 'look at next' can also mean 'go to l3', if you're willing to budget another 16G.

asciilifeform: and so forth.

asciilifeform: the most basic setup has an l1 which immediately proceeds to the 'slow' table (where you have to look at multiple offsets in case of collision, to find your tx)

asciilifeform: this form will almost certainly suffice for another decade of trb

asciilifeform: considering that we have, what, 200 mil tx; and l1 table gives you 4billion slots.

asciilifeform: aha.

asciilifeform: Framedragger: the 1024bt thing works in all cases, it simply means that you don't have to point to beginnings of blocks, but to a place very near the tx

asciilifeform: see, we store the blocks linearly

asciilifeform: this also abolishes the cost of 'budget 1MB per block'

asciilifeform: now you can store them back-to-back

asciilifeform: because you can point inside'em in the index.

asciilifeform: fixed 1MB would give you O(1) block seek.

asciilifeform: however block index is not large -- say we have 500,000 blocks, and you want to know where on disk lives its beginning, and your disk takes 64bit lba addressor. so you need 500,000 * 8bytes == 4,000,000 bytes ! 3 floppy's worth

asciilifeform: except that you don't actually need byte-addressing !

asciilifeform: that is, you don't need 8 bytes to say which 4kB slice has the beginning ☟︎

asciilifeform: so in practice, you can have O(1) seeks ~while~ storing the blocks back-to-back in a classical trb.

asciilifeform: if you want to consider 'what would give best performance on the iron we have, with minimal moving parts, with the trb we have' this is what comes out.

asciilifeform: i was recently considering implementing a similar scheme for phuctor, and realized today that it would work entirely well in trb.

asciilifeform: btw mircea_popescu's suggestion from last night, to dispense with 'blocks' as separate class of object, and simply store sequence of tx, with 'this was in block B' field added -- would work quite well with this scheme.

asciilifeform: now store each tx on a 4096bt 'cylinder' boundary, and you're golden

asciilifeform: the table can index individual tx.

asciilifeform: aha.

asciilifeform: imho the 'hard part' is not even to implement this table, it is freshman homework, but to unravel the liquishit in trb and learn where to even put the lookup/write ! ☟︎

asciilifeform: http://btc.yt/lxr/satoshi/source/src/db.cpp?v=makefiles#0329 << starting here.

asciilifeform: the gnarly part is to dissect all of shitoshi's idiot special cases (e.g. 'ReadOwnerTxes')

asciilifeform: and reduce all of the bdbisms to calls to table ops.

asciilifeform: or, for instance, what is ReadDiskTx . ☟︎

asciilifeform: (as far as i can see, it is unused code)

asciilifeform: trinque: i've found that 'kill', which syncs the db, followed by kill -9, which nukes shitoshi's pointless wait idiocy, worx 100%. ☟︎

asciilifeform: with 0 loss.

asciilifeform: 0 reason to let it

asciilifeform: winblowz culture.

asciilifeform: (some time grep for the sleeps, it is instructive) ☟︎

asciilifeform: idiot put them ~everywhere

asciilifeform: i am nearly convinced that he was, at one time, a microshit employee.

asciilifeform: nobody else does this!11

asciilifeform: Framedragger, ben_vulpes : i predict that there will be few enough collisions that you can shunt ~all~ collision cases off to an O(N) lookup table, for next decade, with ~0 measurable loss of avg.case performance.

asciilifeform: (lookup table consisting of, literally, rows of full txid followed by where-on-disk, that you'd chug through whenever collisionbit is set)

asciilifeform: so, literally,

asciilifeform: if (table[txidtop32] & 0x80000000) return linearlookup(txidtop32);

asciilifeform: else return disklookup(table[txidtop32]) ;

asciilifeform: .

asciilifeform: 'linearlookup' is the slow-table from earlier

asciilifeform: disklookup is the 'go to nth cylinder and before you get to n+1st cylinder, THERE's yer tx' from earlier still.

asciilifeform: and you have here ~whole thing.

asciilifeform: ( i can already picture mircea_popescu spitting out his breakfast, 'modern hdd dun have cylinder, you nut' -- except, it in effect DOES, fetches massive blox , whether mechanical or ssd, by design, for ages now ) ☟︎

asciilifeform: there is not.

asciilifeform: if you get moar collisions, you simply end up in the slowtable moar often.

asciilifeform: if you start seeing them ~regularly~ (say, trb makes it to 50 yrs from nao) you put in a l2 table.

asciilifeform: then you get another century.

asciilifeform: (i would hope that l1 will last until trbi..)

asciilifeform: do the arithmetic, it isn't as if anyone can cancel the 'block per 10min' thing. ☟︎

asciilifeform: there is 1 potential nuance,

asciilifeform: enemy might start to 'mine' txids

asciilifeform: so that they collide

asciilifeform: but this'd cost'em moar than simply to mine.

asciilifeform: (you could in fact use a repurposed miner, for this, as i understand)

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: much cheaper to reindex a trb node, what, 1 night, than for enemy to bake new asics.

asciilifeform: so this scenario, imho, is out.

asciilifeform: (enemy is welcome to bash his skull to a pancake against the cement wall)

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: iirc in 2014.

asciilifeform: aha

asciilifeform: Framedragger: the other thing is that it is quite impossible to come up with meaningful cost figure

asciilifeform: because the cost, to someone who ALREADY has fab capability , is miniscule

asciilifeform: whereas to someone without (e.g. the folx here) it is ~infinite.

asciilifeform: Framedragger: http://preshing.com/20110504/hash-collision-probabilities << re earlier. quick likbez on collision probability calculation using 'birthday theorem'

asciilifeform: http://preshing.com/20160314/leapfrog-probing << from same www, also notbad.jpg illustration of schoolbook hash tables.

asciilifeform: Framedragger: just as you do not need 366 people in a room for a birthday collision.

asciilifeform: (~guaranteed at 80 or so) ☟︎

asciilifeform: ought to help those folx for whom kindergarten happened long, long ago, to picture the subj of today's thread.

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: depending on the collision rate.

asciilifeform: i like 32 (recall, 31, we need 1 bit for collision marker) because it translates cleanly to our physical machine.

asciilifeform: but can use, e.g., 30, 29...

asciilifeform: if 'poor'.

asciilifeform: the scheme 'degrades gracefully'.

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: you can use x64's page table to 'cheat' and store a sparse form ! ☟︎

asciilifeform: but THIS i will leave as an exercise for the reader.

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: why would you ever not have the nx bit set for a motherfucking table

asciilifeform: you don't need any moar kludges, the scheme described, will work.

asciilifeform: with hard guarantees, even.

asciilifeform: i meant 'cheats' that use the machine as-prescribed and save multiple GB.

asciilifeform: rather than 'let's put cock into gas tank because it fits'

asciilifeform: congrats trinque !!

asciilifeform: i very well might, shortly.

asciilifeform: (would like to test 2way 'wiring' first on a non-infrastructural set of boxen )

asciilifeform: it'd suck if dulap ~and~ deedbot choked in same day, say.

asciilifeform: 'if one synchronized swimmer drowns, must the others?' (tm) (unknown)

asciilifeform: trinque: fwiw i still know of at least 1 unsolved tickle re 'wires' -- how to avoid multiple redundant connections

asciilifeform: (right now, e.g., zoolag and dulap happily also find each other over ordinary peer table and connect plaintext)

asciilifeform: i'd like to think of an elegant solution to this ☟︎

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: and yes i could put in a '--noplaintextpeer=x,y,z...' flag, BUT

asciilifeform: BUT this would make it very easy for the enemy to determine who is 'wired' to whom

asciilifeform: by looking at who never plaintcp's to whom on 8333 !

asciilifeform: so we have dilemma.

asciilifeform: maybe mircea_popescu can cut it, with his knife.

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: at any rate this is a 'theoretical' problem, imho 'not burning'.

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: (on ordinary userland fs, which you have now.)

asciilifeform: ( i wonder if there are any traditional fs that will actually give you 16G of contiguous blocks, if asked nicely ) ☟︎

asciilifeform: Framedragger: you asked at same time as i .. lol

asciilifeform: afaik answer is 0

asciilifeform: but worth investigating imho.

asciilifeform: Framedragger: there is a udev trick, iirc, for giving particular users access to a given raw block dev

asciilifeform: but you'll need to dedicate an entire disk

asciilifeform: at any rate imho the flat-file variant oughta be tried 1st.

asciilifeform: then it can be readily mapped to physical disk.

asciilifeform: in fact it can be simply a file descriptor given on command line.

asciilifeform: trb will not even need to know whether it was given a real disk, or flat file.

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: 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: (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: to borrow from mircea_popescu et al, 'it works if you work it'

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: unlike idiot db

asciilifeform: or civilian file systems.

asciilifeform: *the readers are never reading THE

asciilifeform: lol.

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: Framedragger: all you need is to check a read candidate against the current list of active writes. ☟︎

asciilifeform: (in hardware this would be O(1) op, in our reality -- slightly slower)

asciilifeform: Framedragger: but not right tool for ~this~ job ☟︎

asciilifeform: the sha256 is balancing for us.

asciilifeform: Framedragger: i am increasingly finding that 'general purpose db' is, like the infamous 'vise-grip', The Wrong Tool For Every Job ☟︎☟︎

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: using general-purpose db where performance is a critical concern, inevitably gets you http://btcbase.org/log/2017-02-19#1615434 . ☝︎

asciilifeform: observe, gavin, hearn, et al, have specific orders for past 5 or so yrs : 'make it so that bitcoin REQUIRES oracle cluster'

asciilifeform: Framedragger: i did a good measure of tweaking, and exhausted current time budget for that chore

asciilifeform: will come back to it at some point

asciilifeform: trinque: then i'll need a cl pgp parser ☟︎

asciilifeform: which i currently don't have.

asciilifeform: and a new everything-else

asciilifeform: (right now it uses an old python lib for wwwtronics)

asciilifeform: at some point, yes, i'll rewrite it again.

asciilifeform: trinque: phuctor is not simply about gpg, recall

asciilifeform: it is a general-purpose shitrng telescope

asciilifeform: largely yet-unused in the proper way.

asciilifeform: we will be busting ssl keys, for instance, at some point

asciilifeform: and who knows, what else.

asciilifeform: maybe, who the fuck knows, collect enough data re winblows rng defects, via a future 'uci', to break satoshi's keys.

asciilifeform: ('martian' example, but typifies the yet-unknown)

asciilifeform: i did say, 'martian example', not immediate plan to action.

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 contemplate it as more of a 'demolition charge', when trbi exists.

asciilifeform: ( http://www.loper-os.org/?p=1009 << my old crackpot piece re subj )

asciilifeform: and whether d00d burned his hdd, or not, has 0 bearing on whether his keys are, on account of his idiocy, breakable.

asciilifeform: Framedragger: your figures are probably quite 'optimistic' you have not only ssd, but cache in play

asciilifeform: at this point ftr i'm quite firmly convinced that baking in massive open sores shitbucket, e.g. ext4, is The Wrong Thing

asciilifeform: and not even because of speed.

asciilifeform: i originally favoured it on account of simplicity

asciilifeform: but in table system, you don't even need to munge indices into strings to make paths with

asciilifeform: much less to fopen() !

asciilifeform: lol!!

asciilifeform: woah, fresh megatonne of mircea_popescu

asciilifeform loads it into bed machine

asciilifeform: neato Framedragger

asciilifeform: aha, i recall

asciilifeform: 'expect massive b00k later this week'

asciilifeform: all algos begin with restatement of the obvious (e.g. 'this adds two integers')

asciilifeform: btw creation of just about anything is 'pessimized for' by konsoomer fs -- because it is the rarest case on 'typical system'

asciilifeform: mircea_popescu: etoro?

asciilifeform: denominated in, i can only guess, ethertardium?

asciilifeform: or 0 relation..?

asciilifeform: iirc human names are not trademarkeable in usgdom, they can take out ads on you, me, mod6 , et al. whateverses.

asciilifeform: they can always say 'ooh we meant ~this other~ mp'

asciilifeform: lulzy

asciilifeform: i guess some bean counter decided that this gambit has higher ev ~in btc~ than , e.g., nsa mining

asciilifeform: 'let's run our own pirate'

asciilifeform: kinda disgraceful, not like there isn't a usg 15nm fab or two still standing in upstate new york

asciilifeform: could make miners, instead of whatever arse-penetrating radar controller golden toilet rubbish. for just one or two shifts.

asciilifeform: mircea_popescu: it's literally the simplest physically possible scheme, read whole thread. (it is also NOT married to the 'magic numbers.')

asciilifeform: mircea_popescu: i am not a psychiatrist, do not specialize in 'patient has arms, legs, nerves are fine, but he won't move'em'

asciilifeform: this, if it was a mystery in 2014, is plainly visible today imho

asciilifeform: ( speaking of golden toilet, factory sent me a gold-plated ruler! complete with drill guide. -- yes, made of finest pcb . for lulz. )

asciilifeform: lul

asciilifeform: http://btcbase.org/log/2017-03-10#1624149 << this is a hosting co in hk, and domain peddler. betcha ~all~ of their shithosting offerings, are debianized. ☝︎

asciilifeform: http://btcbase.org/log/2017-03-10#1624681 << fwiw i've used raw hdd for actual work. ☝︎

asciilifeform: if you just need to store linear array of blox -- nothing beats raw hdd. fuck fs.

asciilifeform: http://btcbase.org/log/2017-03-10#1624688 << if you're thinking of the iron failing -- i operate disks in raid5 (and for past couplea years -- raid5 of ssd; on this particular box in this particular room, for instance, 4 x 1tb ssd) : 0 detectable failures-with-loss of any kind. ☝︎

asciilifeform: mircea_popescu: aha! which is why i published an algo with 0 rebalance, today.

asciilifeform: (i sat down with the ext4 thing and very quickly came to the conclusion that it, and every other konsoomer fs, is 'pessimized' for our specific scenario)

asciilifeform: http://btcbase.org/log/2017-03-10#1624751 << ben_vulpes actually went off to calculate it, empirically!, earlier today, lessee what he comes back with ☝︎

asciilifeform: ( he asked 'what do' and i answered 'take all tx, from first to top of currentheight, and count how many share their senior 32bit )

asciilifeform: soon we find out 'how many shared birthdays'

asciilifeform: btw it may even be worth taking top 32 and bottom 32 and comparing (fuck knows, sha(sha(x)) could produce different ! distribution, for no entirely good reason, for each )

asciilifeform: mircea_popescu: aha, i started at one point to do it, and realized 'wtf why' ☟︎

asciilifeform: mircea_popescu: he posted the method, in the end of the thread, http://btcbase.org/log/2017-03-10#1624601 ☝︎

asciilifeform: and these outliers are always caused by a) interrupt b) cache miss

asciilifeform: aha, hats off to mod6

asciilifeform: mircea_popescu: his fopen() is smaller than a princely ssd's seek time. so thereby i could tell, his measurements had cache in play

asciilifeform: mircea_popescu: i hate to break this sad noose, but nothing on a konsoomer pc is accurate to ns

asciilifeform: ever.

asciilifeform: us -- IF you're lucky

asciilifeform has thought about installing a rubidium clock

asciilifeform: Framedragger: try rdtsc

asciilifeform: best you get on x86.

asciilifeform: literally, it dun get no better on x86, than it

asciilifeform: it's just a register that increments with every tick of the main clock.

asciilifeform: if your cpu dun have rdtsc, throw it out.

asciilifeform: srsly.

asciilifeform: if it dun run at a constant rate: a) adjust your bios b) if fails, Throw it out!! ☟︎

asciilifeform: rdtsc is the ticket, it is how profilers time, and the only timer that is really worth twopence on x86.

asciilifeform: it resets on coldboot and increments with every tick thereafter

asciilifeform: mircea_popescu: no, whole point is to copy from bucket a to b w/out using cpu

asciilifeform: mircea_popescu: (whole point of dma controller)

asciilifeform: where in this mix do we get dma tho.

asciilifeform: btw if you have a 'modern' comp, you will also have bizarre variation in wall clock timings because of smm idiocy

asciilifeform: (cpu will stop to do ??????, maybe pack key logger buffer for later monthly upload to obummer, and undetectably, but rdtsc counter still ticks, it is lowtech)

asciilifeform: this is why it is a lost cause to try to do high precision profiling on a laptop

asciilifeform: ( it is handling smm routine many times per second )

asciilifeform: more or less everything post-2011 comes with nonempty smm.

asciilifeform: (if you want to find out what's in yours, you can disasm your bios, can be quite enlightening)

asciilifeform: phf: consider publishing, it could come in quite handy at some point.

asciilifeform: (say, when we look for sha1 collisions in pgpland)

asciilifeform: Framedragger: link to who proclaimed 'invalid values' wtf

asciilifeform: thing is foolproof

asciilifeform: 'When Intel first invented the TSC it measured CPU cycles. Due to various power management features "cycles per second" is not constant; so TSC was originally good for measuring the performance of code (and bad for measuring time passed). For better or worse; back then CPUs didn't really have too much power management, often CPUs ran at a fixed "cycles per second" anyway. ...'

asciilifeform: as i said just few min ago,

asciilifeform: if this happens on your box,

asciilifeform: and cannot be turned off,

asciilifeform: !! THROW IT OUT !!

asciilifeform: my clock runs at constant rate.

asciilifeform: 24/7.

asciilifeform: within crystal's temp variation.

asciilifeform: (i measured. and you, also, oughta measure, this is the kind of thing to be aware of in a well-run household)

asciilifeform: and it bugs me that the mobo dun have a jack for a rubidium clock

asciilifeform: ( my fpga boards, the nicer ones, DO in fact !! )

asciilifeform: and incidentally FUCKGOATS also has !!

asciilifeform: you can plug in own clock !

asciilifeform: 'power management' is for the birds.

asciilifeform: the box i'm sitting in front of, draws 300w. this is not much.

asciilifeform: phf: aha. doesn't sound like a jet turbine either

asciilifeform: (my 3620 certainly does )

asciilifeform: mircea_popescu: i meant 1 particular box

asciilifeform: phf: you dun run your 1201 24/7 do you.

asciilifeform: (have pity on ye olde caps!)

asciilifeform: broke?

asciilifeform: phf: yeah i'm not sure why a xl1201 owner would even need the console

asciilifeform: (i reverse-engineered the kbd, pretty sure was the first to publicly do so and post on www, you can build converter)