log
392 entries in 0.393s
mircea_popescu: no such fucking thing, it's exactly like genetics -- genetically present traits may or may not phenotypically manifest. but if they do not -- THEY WERE NEVER THERE.
mircea_popescu: so -- looking back to the crc32 situation, suppose that for whatever reason the consensus wasn't "yeah, should definitely have both" but "division is stupid, only tables are needed". at that juncture, ave1 could have made an alternate patch to the crc32-lookup consisting of merely a changed manifest, saying "Hey, for so and so reasons I think this should be a crc32-division, I intend to do it later."
mircea_popescu: http://btcbase.org/log/2018-10-15#1862676 << speaking of this, might as well take the time to discuss the "stub manifest" point.☝︎
ave1: with the manifest as we have now and no way to automatically merge an alternative (i.e. having more than one possible ancestor)
diana_coman: well yes, I can't quite see the point of blanking the manifest without regenesis since that's basically what it means
asciilifeform: if yer nuking the manifest, good form would be to regenesis then imho. but yes
mircea_popescu: note that it's not even illegal to blank the manifest or w/e. impolite, yes, but the spec allows.
asciilifeform: manifest is a piece of handy docs, not a straightjacket, lol
diana_coman: ah, alternative line in manifest too, I see it
asciilifeform: diana_coman: no? you can branch on manifest like on anyffing else
diana_coman: http://btcbase.org/log/2018-10-12#1860960 -> hm, doesn't the manifest impose a single line rather than a tree?☝︎
diana_coman: typo in manifest "emplementation" -> implementation ; but one can live with that
diana_coman: I'll soon do the regrind of eucrypt to move it on to keccak hashes; my plan is to keep the patches precisely as they are otherwise (i.e. including NO manifest until I actually added it at the end); the way I see it, it's just a swap-in-place of one hash for another; if anyone sees this sort of thing differently - since I'm hmmm,first to regrind a big project? - yell now !
a111: Logged on 2018-10-03 16:28 asciilifeform adds ' asciilifeform-recipe switch ' to next cargo manifest
asciilifeform adds ' asciilifeform-recipe switch ' to next cargo manifest
diana_coman: ave1, you forgot to change manifest file for your zfp_4_assert.vpatch? (i.e. it's missing from the list in manifest)
asciilifeform: trinque: manifest is done, i built on it in the experimental item linked earlier
mod6: No, the manifest was published last week, trinque.
trinque: I have patches myself which are sitting on the sideline waiting for the manifest, which I was under the impression you're working on
diana_coman: fwiw I *did* specifically state in the manifest that it's using Keccak hashes
diana_coman: I added the manifest + comments in it; otherwise *all* code is precisely what I got from pressing your patches
mircea_popescu: and you can't put "this is keccak" in manifest because it has to get into the manifest through being in the filename, rather than just in the comment line ?
hanbot: http://btcbase.org/log/2018-09-26#1854738 << why not put it in manifest?☝︎
mod6: Email to btc-dev ML went through for the excise hash trunctation + manifest.txt: http://therealbitcoin.org/ml/btc-dev/2018-September/000311.html
asciilifeform: BingoBoingo: do what remains to do to put a proper cross on the grave, and after that i'ma start taking cargo manifest calls.
mod6: In other news, I've created a new excise hash truncation regrind vpatch, which includes the manifest.txt pasted above. Am re-testing it, currently. Will post to ML upon success.
mod6: Ok, I've reversed the order of the manifest.txt file as we discussed; http://p.bvulpes.com/pastes/TMFMJ/?raw=true << mircea_popescu PeterL asciilifeform ben_vulpes trinque et. al.
asciilifeform: next item i write , will have proper trinqueian manifest .
a111: Logged on 2018-09-08 23:31 mod6: Hi all, I wanted to get some review, on this manifest file that would be introduced into trb. It would be placed inside the 'bitcoin' directory along the 'Makefile' and 'src' directories. It follows trinque's proposal here: http://trinque.org/2018/06/02/v-manifest-specification
mod6: http://btcbase.org/log/2018-09-08#1848783 << >> http://p.bvulpes.com/pastes/rjqUZ/?raw=true << Back on the 8th I posted this possible manifest.txt file for trb. It's now been zapped, but I made a new one with updated block heights for all.☝︎
asciilifeform: there is the manifest, but afaik it doesn't get machine-parsed
diana_coman: asciilifeform, not full as far as I'm aware; there is http://trinque.org/2018/06/02/v-manifest-specification/ re manifest
diana_coman: asciilifeform, since your udp genesis is using the sha hashes + a "history" file I'm not sure: do you have something against the move to keccak + standard manifest file for v-trees?
mod6: Well, s/all created/placed into the manifest/
mod6: ben_vulpes: All of the previously created vpatches are coming into the manifest at the same time. This simply denotes that it was all created at one time.
mod6: http://p.bvulpes.com/pastes/qSPwN/?raw=true << draft of the manifest.txt for TRB. mircea_popescu asciilifeform ben_vulpes trinque et. al. plz to review and let me know if any thing needs changing.
mircea_popescu: i dun see anything wrong with either approach. having them all have current block height as trinque says, correctly reflects present situation. having them have whatever other denotation you choose (some kind of reconstructed "blocks as it were") has the advantage that it reflects historical knowledge. neither of these is important : FUTURE manifest.txt versions can reflect w/e we want them to then.
trinque: mod6: I figure giving them the same block times is the right thing, since it's entirely true (and useful to denote) that they were all added to manifest.txt at that time
mod6: A while back it was argued that a full-regrind of the entire trb vtree was not necessary. Having all the manifest entries in there, even if starting now, should suffice.
mod6: Also, the name of the file would be 'manifest.txt'.
mod6: Hi all, I wanted to get some review, on this manifest file that would be introduced into trb. It would be placed inside the 'bitcoin' directory along the 'Makefile' and 'src' directories. It follows trinque's proposal here: http://trinque.org/2018/06/02/v-manifest-specification
mircea_popescu: the range wars in the very us raged in living memory as an exact manifest of this whole thing.
mod6: ben_vulpes brings up a good point about my regrind of his Excise Hash Truncation vpatch, I should put in the manifest.
asciilifeform: http://btcbase.org/patches/eucrypt_manifest/tree/eucrypt/smg_rsa/truerandom.c#L65 << incidentally this is erroneous. a correctly-inited FG will never produce interrupt ( the tty ~must not~ interpret 0x03 as control char, it must return all octets verbatim )
asciilifeform: http://btcbase.org/patches/eucrypt_manifest/tree/eucrypt/smg_rsa/truerandom.c#L84 << seems like you re-init the usb dongle every time you read. this is not recommended, i've encountered a chinese ttl plug that wedges if you init it one too many times
asciilifeform: diana_coman: is http://btcbase.org/patches/eucrypt_manifest/tree/ current ?
mod6: Hm, I wasn't taking about the manifest thing really, which is another whole question not completely answered.
asciilifeform: mod6: there's the manifest thing; what else was there
asciilifeform currently writing a manifest, goes 'down'
mod6: After looking at PeterL's blogpost, was curious if there had been any consideration into if a manifest file should grow up or down (i.e. newest change first, or newest change last in the file). This is purely a cosmetic thing, I suppose it would be up to the author too. Probably why trinque didn't touch on this in the post either http://trinque.org/2018/06/02/v-manifest-specification/
asciilifeform: i suppose there is also the other variant, where manifest.txt actually gets speshul treatment. but imho that's ugly.
mircea_popescu: http://btcbase.org/log/2018-07-10#1833125 << something the manifest should actually fix ; if it's included why doesn't it fix it ?☝︎
phf: manifest doesn't solve this problem, because manifest doesn't get any kind of priority treatment. if you hinged your press purely on a manifest descendent/antecedent chain then everything else will just work™
phf: there is a manifest in this version of vtools
phf: asciilifeform: well, i'm not sure what "spuriously bifurcated tree" means in this case, the goal was stated in the one of the posts, that i'm explicitly maintain two separate branches, that hinge on two separate manifest paths. this is the kind of stuff v is designed for neh? press to vdiff_sha_static to get one thing, press to vtools_vpatch_newline to get the other
asciilifeform: the http://btcbase.org/patches?patchset=vtools picture suggests that it's the classic mistake of spuriously bifurcated tree, the kind of thing that had trinque & mircea_popescu raging in the old days and prompted manifest.txt etc
a111: Logged on 2018-07-07 23:27 phf: i've been using vpatch/vdiff without full blown v, because i can order the patches by hand (and there's now an explicit ordering provided by manifest), and vpatch verifies the hashes for me. it would be handy if i could also press existing sha patches with `vpatch -a sha` or whatever
esthlos: wrt http://btcbase.org/log/2018-07-07#1832726 and asciilifeform 's "sad mode", the idea of using the manifest was the confusing way the fuck back in http://btcbase.org/log/2018-03-07#1787163 , where I thought "oh, mp wants me to build a vtron using manifest to resolve tree, guess I need a manifest spec!"☝︎☝︎
phf: i've been using vpatch/vdiff without full blown v, because i can order the patches by hand (and there's now an explicit ordering provided by manifest), and vpatch verifies the hashes for me. it would be handy if i could also press existing sha patches with `vpatch -a sha` or whatever
phf: well, yes, you have all the tarbas/ebuilds have a blake in manifest, but there's no equivalent for a git repo. those are just pulled
mircea_popescu: point being, "blind" v could exist that just puts in the patches as seen in manifest, checks no sigs.
a111: Logged on 2018-06-26 17:45 phf: trinque: one reason i didn't include patch name in the manifest is because patch name becomes a promise, unless you enforce it by tooling. i didn't want to go that way, but since current standard manifest does include patch name, than perhaps V ought to check the manifest against the patchset. relatedly fully manifest-based v doesn't even need graph tooling, can presumably press according to manifest's chain.
mircea_popescu: http://btcbase.org/log/2018-06-26#1829714 << this is a significant gain, in that it reduces the need for elaborate toposorting. first, check the manifest chain.☝︎
trinque: I brought up the graffiti because that'd be (and has historically been, before manifest) the way to attach the graph
trinque: wont be able to press a "makefiles" + manifest until that subsequent patch, but I don't really see a problem with that
ben_vulpes: add a new file for the manifest, create a vpatch, any subsequent vpatches that don't also edit manifest must be reground into mainline.
trinque: I was discussing how the manifest gets welded on, if welding on
trinque: anyhow, if we're talking about how to use the manifest, got it.
mircea_popescu: ircbot/manifest.txt
ben_vulpes: manifest.txt $hash_prev $hash_curr ?
ben_vulpes: reference the manifest file in a later patch.
mircea_popescu: if you find the manifest patrch is useful (as you do), YOU INCLUDE IT.
mircea_popescu: 2. you sign another new patch, later on, "fixing-bugzappers.patch". this patch references manifest patch and ircbot-multichan-etc.
mircea_popescu: 1. you sign a new patch, manifest.patch. at this juncture, phf's viewer will show it to the side, unconnected to the tree.
trinque: aha, once there's a manifest, all's fine.
asciilifeform: i think trinque's observation is re how to glue the ~old~ tree on, in the first manifest-bearing patch
mircea_popescu: ed patch is now also well ordered, "caught in the patchchain" as it were) and b) we can and very likely will re-organize the portion between genesis and the manifest patch later anyway.
mircea_popescu: it's not being proposed as a retoactive fix. the idea is, ~after~ the patch that puts in a manifest, ~subsequent~ patches will be well ordered. and the fact that the earlier ones aren't exactly well ordered is a) resolved in any practical sense by the fact that you won't have patch imports across the barrier more than 1 deep (ie, once a patch after the manifest patch references a patch before the manifest patch, THAT refernec
a111: Logged on 2018-06-26 17:26 trinque: ben_vulpes: because the manifest has no antecedent, and you're gonna have to go graffiti other files like an idiot
mircea_popescu: http://btcbase.org/log/2018-06-26#1829660 << you could just add the manifest in a patch, like diana_coman did for eucrypt.☝︎
trinque: phf: thought I had there was that if you have only a manifest in hand, perhaps the name is useful in some dht lookup for the patches later
phf: trinque: one reason i didn't include patch name in the manifest is because patch name becomes a promise, unless you enforce it by tooling. i didn't want to go that way, but since current standard manifest does include patch name, than perhaps V ought to check the manifest against the patchset. relatedly fully manifest-based v doesn't even need graph tooling, can presumably press according to manifest's chain.
trinque: what it means is that before that point, there isn't a manifest-enforced press order
trinque: mod6: what do you imagine needs to change in a vtron to support the manifest?
trinque: phf: harping on it because I don't see evidence that reason for the manifest has been internalized
a111: Logged on 2018-06-15 17:26 phf: http://btcbase.org/log/2018-06-15#1825631 << updated, but it's a novel way of using manifest though: normally it requires a regrind where manifest is built up as you go, so the press order is enforced through graph. right now your manifest gives a press order, that's not enforced by anything
phf: trinque: ftr we have the "introduce manifest now without regrind, use it moving forward" pattern already implemented once
mod6: Perhaps we need to 1: Formally adopt the manifest spec proposed by trinque, 2: build a V that supports it.
mod6: we'll cross that bridge when we come to it. but first and foremost, the manifest items seems alright to me; "$blockCount $patchTitle $patchAuthor $comment".
mod6: I can delcare the v054 release with a manifest of my own ala: To declare a "release", an author's GNS pointer for a project would point to his selected manifest.
trinque: wherever you introduce the manifest, if it is not the root, in order to involve it in the flow of the tree, that patch must also edit some other file.
mod6: i see ben's point, but i'd rather trb one whole thing, instead of a 'before manifest' and 'after manifest'.
ben_vulpes: well in theory, but in practice everything below makefiles already needs a regrind; aggression to request newblocks if none have been advertised recently; hash truncation atop that. so there's an opportunity to significantly reduce the amount of regrinding by introducing the manifest after the makefiles release and just regrinding 2 patches instead of the whole tree. unless i misread the situation.
trinque: ben_vulpes: because the manifest has no antecedent, and you're gonna have to go graffiti other files like an idiot
ben_vulpes: mod6: my original q was in re why regrinding the whole tree is necessary instead of introducing the manifest now and using it going forward
mod6: ben_vulpes: im trying to look at the big picture. the manifest spec is a part of that, ya.
trinque: the words I wrote right there gave it as an example of "this needs a manifest"
trinque: there ~are no~ manifest capabilities to be had
ben_vulpes: "manifest capabilities" are baked into all V implementations
mod6: is his lisp version of V to become the new defacto thing that has manifest capabilities?