log
408 entries in 0.408s
danielpbarron: Romans 1:18 For the wrath of God is revealed from heaven against all ungodliness and unrighteousness of men, who suppress the truth in unrighteousness, 19 because what may be known of God is manifest in them, for God has shown it to them. 20 For since the creation of the world His invisible attributes are clearly seen, being understood by the things that are made, even His eternal power and
spyked: anyway, this is no excuse for my long silence, so: I'ma bring rss bot here in the following hour (it's been under heavy testing for the last month, so it should at least be a decent replacement for current deedbot rss functionality) and keccak+manifest ircbot tree should be out by the 1st of december
mircea_popescu: is # acceptable comment inline ? should there be a manifest also ?
a111: Logged on 2018-11-19 21:44 bvt: alternatively, i could add new functions at common tree part if i don't touch any files included in later vpatches (so adding entries to manifest would be not possible). seems like some quite unnatural acrobatics to me.
bvt: alternatively, i could add new functions at common tree part if i don't touch any files included in later vpatches (so adding entries to manifest would be not possible). seems like some quite unnatural acrobatics to me.
a111: Logged on 2018-11-19 07:54 bvt: mircea_popescu: i understand that empty genesis (well, it's not precisely empty, there is a manifest file) is suboptimal, however:
bvt: mircea_popescu: i understand that empty genesis (well, it's not precisely empty, there is a manifest file) is suboptimal, however:
mircea_popescu: this now begs the questrion whether if i send my valkiries they would somehow manifest liquidity. god knows i had no problem dealing as much as i wanted in buenos aires. nor here. nor apparently anywhere (except when it comes to wiring to bb, which is becoming the lulz of all time, somehow)
a111: Logged on 2018-10-06 14:31 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 !
asciilifeform: right. but i'm regrinding ch1-11 into keccak. ought manifest only to live in ch12 ( 11 technically had one, but it was adhoc, and not conformant to current formulation ) ? or in all ch1-11
mircea_popescu: "This manifest created on x to comply with prevailing standards ; original had no such thing." fir instance ?
asciilifeform: imho also. the q is what's the most accurate , given that orig had no manifest
mircea_popescu: asciilifeform imo manifest ~should~ be historically accurate.
asciilifeform: originally i was gonna simply regrind ( by running through new vdiff ) ch1-11, and invite reader to hand-diff if he likes and see that only hashes have changed. but then noticed that the new vdiff also processes files in different order, so this won't give clean 'only hashes' diff. so thinking, may as well retrofit manifest to each of ch1-11
asciilifeform: mircea_popescu: quite unrelatedly, what's your recommended formula for 'manifest' in keccak regrinds ? ( i.e. to retrofit manifest to ancient stuff, or only to latest v cut of it ? and with current blockheight, or to somehow estimate the one at the time of original publication ? )
asciilifeform: meanwhile, in vintage lulz, http://dan.corlan.net/wish/2014_01_7forever_operating_system_support_manifest.html
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?