log
39 entries in 0.415s
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 ? )
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
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: 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: 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/
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
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
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
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.
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.
mod6: Perhaps we need to 1: Formally adopt the manifest spec proposed by trinque, 2: build a V that supports it.
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?
ben_vulpes: mod6: focus on the manifest design, not the v implementation linked in trinque 's post
trinque: mod6: http://trinque.org/2018/06/02/v-manifest-specification/ << can have the thread here if you like
mod6: that said, everything must be pretty much "firmly" in place with V rules, manifest, naming conventions, what have you, before I wanna move on that.
esthlos: trinque: I added a manifest to my v_genesis vpatch. I'm curious, though, how these items (vtron, manifest) become declared "standard", if ever
mircea_popescu: esthlos, every link that goes in chan is also found at https://archive.is/http://trinque.org/2018/06/02/v-manifest-specification/
a111: Logged on 2018-06-02 21:47 trinque: bugger, it's actually http://trinque.org/2018/06/02/v-manifest-specification/
deedbot: http://trinque.org/2018/06/02/v-manifest-specification/ << trinque - V Manifest Specification Draft
trinque: bugger, it's actually http://trinque.org/2018/06/02/v-manifest-specification/
deedbot: http://trinque.org/2018/06/02/v-manifest-specification-draft/ << trinque - V Manifest Specification Draft
mircea_popescu: alright, plox trinque write a v manifest specification, so it can be linked to for the future.
a111: Logged on 2018-05-01 16:26 mircea_popescu: trinque, what's your stance here, do you particularly want to implement a grapher / manifest / generally fix a v ? not really ?
esthlos: hey guys, should I have included a manifest file in my genesis? see http://blog.esthlos.com/esthlos-v-genesis-or-who-presses-the-pressor/comment-page-1/#comment-17
mircea_popescu: trinque, what's your stance here, do you particularly want to implement a grapher / manifest / generally fix a v ? not really ?
a111: Logged on 2018-05-01 06:55 mircea_popescu: is the manifest issue fixed ? is the graphing done ? am i what, going to lose v now because i'm too polite to yell, and left to your own devices you're just going to break it, permanently, obscurely, and forget about it ? or what's the fucking logic here.
mircea_popescu: is the manifest issue fixed ? is the graphing done ? am i what, going to lose v now because i'm too polite to yell, and left to your own devices you're just going to break it, permanently, obscurely, and forget about it ? or what's the fucking logic here.
asciilifeform: hey the schem hashes are in 1) the v genesis + 2) the signed manifest
assbot: Logged on 22-12-2015 22:43:02; mod6: so i think jurov has a good question; if we don't drop the turdballs into V, which we're not, and the MANIFEST is the only thing in the 'shit' directory that is pressed out by 'V', where do the tarballs come from?
mod6: so i think jurov has a good question; if we don't drop the turdballs into V, which we're not, and the MANIFEST is the only thing in the 'shit' directory that is pressed out by 'V', where do the tarballs come from?
mod6: <+mircea_popescu> the manifest should live wherever the rotor.sh lives neh ? << I would argue that all of these scripts would live outside of bitcoin source V tree.
mod6: this Manifest we're talking about creating would need to fit somewhere in the directory structure of bitcoin itself, if it is to be 'v'-ified.
mod6: ascii_field: http://log.bitcoin-assets.com/?date=20-12-2015#1348988 << So I'm gonna be putting just the sha512 hashes of BDB/Boost/OpenSSL .tar.gz files in a manifest that will be added into 'V'. ☝︎
assbot: Logged on 25-09-2015 01:27:12; mod6: one possibility to publish releases in the future now that we have V is to create a manifest of V patches and have the co-chairs sign the manifest, as well as the patches.
mod6: so for instance, I've made http://thebitcoin.foundation/v/TEST2.manifest, so far unsigned as its just for testing my code for a minute here..
mod6: one possibility to publish releases in the future now that we have V is to create a manifest of V patches and have the co-chairs sign the manifest, as well as the patches.