log☇︎
233300+ entries in 0.157s
asciilifeform: how am i to ask him, lol, he disappeared.
mircea_popescu: ask the fucking fin.
asciilifeform: and i'm pretty sure it came up when the finn was here. he vanished.
mircea_popescu: asciilifeform but did you ask the fin.
trinque: davout: idea is that these querying tools could as well use reiserfs or another as the "disk data format"
asciilifeform: mircea_popescu: most folks run for the hills when i say 'yes in asm, and no you don't get to use any existing code'
davout: i'm still not convinced that the relational approach is not the correct one, as far as an arbitrary inspectable DB is required
mircea_popescu: didja ask the finn ?
asciilifeform: i wasted... dun even care to say how long. on this chore.
mircea_popescu: writing drivers is two things : a) write the fw ; or b) call nvidia faggots on a mailing list. ☟︎
mircea_popescu: the expectation ot make an os and not have to write drivers is the sweet sort of innocence usually reserved for coed sluts.
asciilifeform: the one caveat that i can think of is that it may very well turn out to be unusably slow (as in, >10min block verify), on anything but reiser. (if there even.)
mircea_popescu: trinque not only that, but anything other than all is kinda indefensible in practice.
mircea_popescu: and so we are back to the original bitcoinfs.
trinque: it's just a question of how much OS you want to eat, and all is a fine answer
trinque: this is an entirely reasonable approach and yields the same things; I would call it a db.
asciilifeform: davout: pluggable ~without bitcoin having to know about it~ is the key.
mircea_popescu: this much is true. it's also not really the part in dispute.
asciilifeform: for entirely different, and unplanned, things.
asciilifeform: so that different proggies can use same disk turds.
asciilifeform: how to arrange bytes on hdd, is why we even tolerate the misery of having an os, to begin with.
asciilifeform: it does not belong in there.
asciilifeform: having the db hardlinked in bitcoin is lunacy
mircea_popescu: but "what to index" is like "user decides when to breathe"
mircea_popescu: the problem with this is that it's not really open to his decision. see something like "user decides what checksum" is eminently user-able.
asciilifeform: by choosing a different fs to plant the thing on
davout: "want to import arbitrary keys? cost 5tb of index"
davout: a valuable advantage of relational storage is that *the user decides* what to index
asciilifeform: simplest example that ~everyone is personally familiar with.
mircea_popescu: and that's just scratching the tipsurface.
asciilifeform: the algo where you 'wallet' by keeping privkey AND index-of-last-block-where-this-addr-was-input-or-output are kept around, works until , in 'typical human' fashion, [l]user asks for 'fried ice', and wants MOAR, e.g., 'oooh i found a privkey in my underpants drawer, how much is it worth' or 'i want to keep priv on 2+ boxes' or, or.
mircea_popescu: and the differential is in fact so immense and not even linear, that restrained toolset is huge gain.
mircea_popescu: this is the very important point here - every feature in the toolchain makes programming easier but ~everything else~ (generally here referred to "fit in head" but easily expanded to writing correct tests, maintaining, even KNOWING WHAT BLEW UP when something blows up!) much much harder
davout: aok, you were referring to the 'pluggable' part, not the 'relational' part
mircea_popescu: the wallet ~is~ that, yes. problem is humanity doesn't mesh well with computability. ppl want a wallet./
mircea_popescu: trinque my comment is re a more general case, not just txn, because i am confident you'll end up stuck with a more general problem in practice.
trinque: -or- the wallet is already a catastrophically shitty implementation of this
mircea_popescu: the reason we want ~one~ is that we don't want to find we can't maintain two.
trinque: I would not create indices for every transaction
mircea_popescu: davout completely amiss. if you try to rubify this, you will end up with the kubinetes situation. "nobody knows how this works".
asciilifeform: btw, p=?=np esoterica aside, 'never say never' in re algorithmic complexities. it is possible to make a number-theoretic 'blockchain' where you check for unspentness by euclid's gcd, for instance. many things are theoretically possible. but this thread afaik is about traditional bitcoin.
a111: Logged on 2016-12-19 19:57 mircea_popescu: davout there are two different items here. a) how much first-time development work is saved (which your proposal addresses) and b) how much maintenance is required to then maintain the infreastructure that saved first-time development work. in the case of bitcoin, b) is the important factor because it scales exponentially : when a is 100 hours, b is 10k hours, substracting an hour of a at the cost of 50% less b means in fact
davout: http://btcbase.org/log/2016-12-19#1586183 <<< are you saying that relational storage is nice, but has the high indexing cost? or am i completely amiss? ☝︎
mircea_popescu: somewhere there, 12 to 25tb worth of indices for a 1tb worth of blockchain.
mircea_popescu: trinque you will have to store NlogN data ; and n is like tb
asciilifeform: trinque: if you write how to do this, i give you my word that i will read .
trinque: not if you have a reliable index that can find every reference to that address
asciilifeform: a full, canonical 'how much is this addr worth' requires O(N) chain walk.
a111: Logged on 2016-12-19 19:57 davout: asciilifeform: don't "sed, grep etc." qualify as "binary dedicated toolset" ?
asciilifeform: trinque: it remains O(N), and yes, you can reduce your N, but you traded away correctness for speed.
trinque: and then vast mountain of already researched space put together poorly
mircea_popescu: trinque if you manage to get alf to not do that, let me know what you did.
trinque: that is a trivial SQL query over transactions
asciilifeform: trinque: this is a physical impossibility
trinque: or I go cache it somewhere and that is stupid
mircea_popescu: in the case of most modern bright minds, b is "hidden" under the rug and so they don';t think correctly about their environment
trinque: asciilifeform: I cannot go calculate the current balance of a given address without walking the chain
asciilifeform: davout: not dedicated. and arguably if you're using an os 1000 yrs from now that doesn't have exact equivalents of these tools, you have serious problems
mircea_popescu: you add 50 hours of b, so you made a very bad trade-off.
mircea_popescu: davout there are two different items here. a) how much first-time development work is saved (which your proposal addresses) and b) how much maintenance is required to then maintain the infreastructure that saved first-time development work. in the case of bitcoin, b) is the important factor because it scales exponentially : when a is 100 hours, b is 10k hours, substracting an hour of a at the cost of 50% less b means in fact ☟︎
asciilifeform: trinque: i promise not to argue until you say exactly what needs doing that cannot be done with stock fs
trinque: the relational model is not impossible to implement
davout: asciilifeform: don't "sed, grep etc." qualify as "binary dedicated toolset" ? ☟︎
asciilifeform: (does anyone understand why i put, e.g., 'v', together, the way i did? or the lamportron?)
trinque: please to not argue against things I have not said.
asciilifeform: instead of relying on gigantic binary turd and dedicated toolset.
asciilifeform: the mega-win from 'use files on disk, in directories' is that i can explore the index with sed, grep, etc.
mircea_popescu: davout the objection, to be clear, is that too much maintenance. that's the true cost here.
asciilifeform: trinque: what can, e.g., reiserfs, not do, that you need done to your tx index ?
davout: if it's "the one design to rule them all" were there any objections to simply using a normalized relational design?
asciilifeform: and guess where THIS IS ALREADY IMPLEMENTED
trinque: just predicates I want to apply
trinque: because I don't always know what the fuck I want!
asciilifeform: trinque: it is not clear that any feature set aside from 'get anything by anything-else in O(NlogN)' is necessary or justified.
davout: trinque: i was thinking more along the lines of "different use case classes might warrant a couple different pluggable storage designs"
trinque: one implements a fast in memory key value store, the other transactions but no structural constraints, ...
trinque: davout: ad hoc crapping together database features as needed gets you the last round of idiot fad databases
mircea_popescu: davout it'd help if there were a good design, how's that.
davout: trinque: are you saying there should be a single design?
mircea_popescu: and i have nfi how anyone fucks these 100lb, tits smaller than mine twists. anyway.
asciilifeform: but the 'boy' comment suggests that it is finite.
asciilifeform: mircea_popescu: i have nfi what the dimensional tolerance is , in practice.
davout: asciilifeform: i'm interested in the title
mircea_popescu: asciilifeform hm i hadn't considered this. you mean the tiny girls are for tiny guys ?
mircea_popescu: kinda why the bitcoinfs discussion has been steaming on a low fire for like a year now.
trinque: there are endless abominations that can arise on that path otherwise
trinque: speaking of killing yourself, the db design for trb deserves *long* thought
asciilifeform: programming would perhaps be a similarly honourable profession as piloting, with similar calibre of people, if only it were possible to kill yourself just as easily with mistreated computer as with airplane.
davout: 'human factors' is a thing
mircea_popescu: i recently enjoyed a very credible thai whore. it was quite unsettling ; i never felt so much like i'm fucking a little boy in my life.
asciilifeform: it is the sad peculiarity of life of the programmer that a proggy 'works perfectly' -- until not
davout: asciilifeform: aha, like 'a decent thai whore' ?
trinque: worked fine; I move deedbot to trb to lean on trb
asciilifeform: davout: 'decent' in the sense of having no ~obvious~ catastrophic bomb
trinque ran the golang one for a long time
asciilifeform: there was a curated list of these at one time
asciilifeform: iirc there was even a ~decent one (as far as anyone could tell) in python, in 2012
trinque: davout: troll not the poar alf
asciilifeform: (or worse: wants me to think that it is!)
asciilifeform: why would i give half a fuck what some rando thinks bitcoin is !