104200+ entries in 0.016s
mircea_popescu: intuitively though i think blocks should be stored by height.
mircea_popescu: unless you want to store them by hash, in which case of course it's at most 65 chars, though because of difficulty i expect it should be made 40 or less
mircea_popescu: jurov in principle the address of a block is something like /44/4600 for the latest, so 2char dir + 4 char name
mircea_popescu: "¿Sabes algo sobre Bitcoin?" "Se que es una especie de almacenamiento de dinero virtual , que por un dólar te dan 2 o 3 bitcoins o algo así , que básicamente se usa para comprar online y conseguir descuentos creo"
mircea_popescu: moreover if you say press kimkardassian and it says "failed - parishilton not found" then it is somewhat likely you forgot to sign blondy.
mircea_popescu: "i ended up with a woman in my bed i don't know." "how ?"
mircea_popescu: should it also show you the contents of your catpics folder, in case maybe you wanted to do some clicking ?
mircea_popescu:
http://btcbase.org/log/2016-12-22#1587972 << it's altogether unclear where did you get this "celebrated is its ability to support a scientific dialog" ; got a link or something ? seems more the case what was celebrated was its ability to put a wrench through imperial-style "scientific dialog" where "we dindu nuttin wrong".
☝︎ mircea_popescu: barely-compiling c isn't good enough for us. oh, no, mommy i need my special asm skirt for THIS sql stuff!
mircea_popescu: ben_vulpes oh im sorry, and your sql is written in what, malbolge ? my my aren't we speshul.
mircea_popescu: in practice i'm in two waters about it, wouldn't be surprised if the whole thing catches fire.
mircea_popescu: in theory the above should be uberefficient sqling of a blockchain
mircea_popescu: profile seek times, whatevs reasonable testage once the artefact's prepared.
mircea_popescu: aaaanyway. mimi's in a fine position to try this out, attach old drive, write script to spit them out as per schema, see what occurs.
mircea_popescu: obv you can't store infinite data in finite hard drive, i came to terms with that
mircea_popescu: more importantly, why is this not ~exactly~ like saying "doh, of course you can't fill a drive with text files". dude what.
mircea_popescu: afaik this is entirely unwalked ground, for all the foss bs about million eyes.
mircea_popescu: and b) wtf happens once you load a drive with this nuttery.
mircea_popescu: ok so a) gotta see if ext2 / ext4 CAN EVEN HOLD this many symlinks. like, at all.
☟︎ mircea_popescu: this way you don't actually have to ~index~ anything, if you wish to see where txn 1234567890 was included in a block, you go to /12/34/56/7890 which points to block x
☟︎☟︎ mircea_popescu: you'd end up with (as proposed there) a directory tree like 20 layers deep, with thousands of symlinks in each.
mircea_popescu: it's funny, you know, after ~2500 years, steel went back home to pradesh
mircea_popescu: BingoBoingo there's absolutely no way in hell anything in the us can compete with mittal.
mircea_popescu: (not that this consideration has much practical value - outside of #trilema the community to do such thing doesn't exist, and so wasn't at the time an option)
mircea_popescu: bitcoin'd certainly be infinitely stronger were it the result of a concurrent development effort in this style.
mircea_popescu: so there's no real strong categorical difference from theory. but in practice it sure as fuck exists.
mircea_popescu: and on the other hand, i suppose it's entirely possible that if a years-made-wiser satoshi tried to release bitcoin, it'd have been done in the manner of how we did vtrons not in the manner of how he did bitcoin, ie, "here's what should happen - anyone who wants to participate make one"
mircea_popescu: i suppose it's possible that as technology matures it goes from this stage to "yawn, whatever, just use the cannonical version". so there's possibly that path there.
mircea_popescu: this opposition may be less categorical than it seems here, and may evolve in time, but i suspect even if a continuous function it'll never be convex.
mircea_popescu: i perceive no benefit to, eg, getting everyone to use mod6's or alf's or anyone else's v implementation, as opposed to the present situation ; just as i perceive no advantage to getting everyone to make "his own" trb.
mircea_popescu:
http://btcbase.org/log/2016-12-22#1587923 << i am fwiw satisfied that it's qutie mroe than this : vs aren't on btcbase because they don't fundamentally belong on btcbase, because unlike public trb "we all use this" they're private "my girl will dance the way ~i~ want her to dance and stfu". there's a much more limited set of rules re what vtrons should do ; than re what trbs should do.
☝︎ mircea_popescu: more or less loud recalibrations as practice crystallizes to be expected in such circumstance.
mircea_popescu: i was saying "this is working correctly", did it end up reading the opposite ?
mircea_popescu: that's ok, i'm just waiting for phf to say something so i unrate him
mircea_popescu: ben_vulpes> so long as there is at least one signature for a patch, for which signature v can import a corresponding key, on the basis of the wot, that patch should press. << ftfy.
mircea_popescu: i agree with the notion .wot is supposed to be a filter over .seals
mircea_popescu: ben_vulpes i don't even want to open that discussion, it's fucking obvious they're equivalent but whatevers.
mircea_popescu: mod6 in practice you'd just keep .seals_mp .seals_all .seals_alfmod6 etc and move them around
mircea_popescu: mod6 the idea is that you should be able to alter the end product by altering .wot rather than by altering .wot AND .patch or .seal
mircea_popescu: whereas if you allow dieing in arbitrary condition, then whatever, you get a more restrictive v than other people.
mircea_popescu: the key being, that if you allow pressing without signatures, then git qualifies as a v implementation.
☟︎ mircea_popescu: that it eschews key checks is one thing ; that it dies on which condition is apparently a different thing.
mircea_popescu: such as in "what classes of objections can or can't be brought to a v implementation"
mircea_popescu: mod6 no, the discussion is actually very productive in that it actually helps specify exactly what v is.
mircea_popescu: asciilifeform yes ; methodological objections are really of those three pillars. like "use ascii" or "the signatures are given TO BE USED" etc.
mircea_popescu: well he can run his v any way he pleases ; but yes it should prolly just drop the bad patch and move on
mircea_popescu: it should probably stop if it finds valid patch that can't be applied (mismatched hashes) - because by then your state is broken.
mircea_popescu: mod6 if it simply skips over the patches it can't find acceptable sigs for, it delivers asciilifeform 's thing above where you don't have to keep fucking around with the patch set.
mircea_popescu: well when we finally have better-pg, we may do different things, but really...
mircea_popescu: the disadvantage of being clever is that one will be surprised.
mircea_popescu: for every patch, check if patch sig by approved names is present. this isn't any sort of N^2 ; it's O(N*M) where N is the count of patches and M the count of approved signers.
mircea_popescu: no they won't ; partly because we won't be doing anything idiotic like "giving random names to seals".
mircea_popescu: and patches are checked against seals ; not seals against patches.
mircea_popescu: im not sure it has to die when it encounters malformed patch (be it not signed or whatever), but anyway.