log
52 entries in 1.758s
hanbot: right right, i mixed 'em up. and yeah, i'm planning on grabbing phf's keccak v.py in step 3, if only because i've seen diana_coman's pop up in cuntoo tests so i'd like to test the ver less traveled.
hanbot: in bootstrapping adventures, it looks like the flow for a machine that knows to v to get vtools going is like so: grab some ancient v, ie mod6's v.py, use it to press phf's vtools vpatch, then eat phf's v.py "updated for vtools", then press vtools to keccak head. anyone feel like spotting this for me?
diana_coman: trinque, iirc I used my own starter_v.zip so that's pressed to vtools_ksum (i.e. http://btcbase.org/patches/vtools_ksum ) as per http://ossasepia.com/2018/11/13/v-with-vtools-keccak-hashes-and-its-own-tree/#selection-69.219-69.332
mod6: I'm currently building out a Cuntoo (have had a minor issue with my kernel not booting correctly, but will work on that soon), and will use that + ave1's musl to build the keccak v tooling, and then TRB. Which will also go into the upcoming changes to the HOWTO Guide.
a111: Logged on 2018-12-27 21:14 diana_coman: billymg, this might help perhaps too: http://ossasepia.com/2018/11/13/v-with-vtools-keccak-hashes-and-its-own-tree/
billymg: http://btcbase.org/log/2018-12-27#1883449 < quick update: using diana_coman's keccak-compatible v.pl, the vpatch i posted before pressed without issue. will write up a blog post with details on the patch, and another post with the patch for the svg file links ☝︎
diana_coman: billymg, this might help perhaps too: http://ossasepia.com/2018/11/13/v-with-vtools-keccak-hashes-and-its-own-tree/
billymg: yeah, i think i'm using a keccak version vdiff for creating the patch, but attempting to press with a sha v.py
billymg: diana_coman: my understanding was that as long as i created the vpatch with a keccak-compatible vdiff then the hashes would be consistent with genesis and it would be ok. this assumption came from me being able to press vtools and mp-wp with my current v.py (grabbed from the link in the trb setup guide)
billymg: ok, updated and it now presses but when i inspect the resulting directory the changes aren't there (it also came with an error i saw before on genesis, about a file's hash not matching expected -- i assumed this was because my v.py is pre-keccak)
asciilifeform: afaik there are currently 3 working ( i.e. with keccak format ) vtrons , v.py ( as patched by phf ) , v.pl ( patched by diana_coman ) and esthlos
lobbes: However, if anyone wants (once I get a proper keccak v going) I can make a private patch on request (a la http://trilema.com/2018/the-v-questionarium-answerarium-2018-edition/#selection-327.0-327.204)
lobbes: this also gives me another reason to take diana_coman's V setup for a spin (http://ossasepia.com/2018/11/13/v-with-vtools-keccak-hashes-and-its-own-tree/)
diana_coman: phf, also, perhaps snarf the V.pl tree from in http://ossasepia.com/2018/11/13/v-with-vtools-keccak-hashes-and-its-own-tree/ ?
a111: Logged on 2018-11-14 10:54 diana_coman: and done: the updated .vpatch files and starter_v.zip + sigs are all up; I've checked them on my RK; genesis is the same and result is identical to V-2017; the result of 99993 .vpatch is identical to V-2018; the result of keccak_vtools vpatch is to update BOTH docs and code; re docs, I've nuked the user manual as I won't maintain it and it's becoming confusing due to being out of date; I've updated the quick_guide however, mainly for 1st t
diana_coman: ime users really; re .zip file: the v in there is precisely what one gets by pressing my v_keccak_vtools.vpatch
diana_coman: and done: the updated .vpatch files and starter_v.zip + sigs are all up; I've checked them on my RK; genesis is the same and result is identical to V-2017; the result of 99993 .vpatch is identical to V-2018; the result of keccak_vtools vpatch is to update BOTH docs and code; re docs, I've nuked the user manual as I won't maintain it and it's becoming confusing due to being out of date; I've updated the quick_guide however, mainly for 1st t
diana_coman: so to keep this fully aligned, I'll regrind the last 2 patches so that the docs changes are carried over as well; as a result: genesis = http://thebitcoin.foundation/v/V-20170317.tar.gz; 1st patch => http://thebitcoin.foundation/v/V-20180222.tar.gz; 2nd patch => using vtools & keccak instead of sha
diana_coman: fwiw the keccak-version of v (i.e. pressing the tree I published all the way to its leaf) IS the corrected one re pressing order ; later today I'll do a diff with precisely the versions mod6 has at http://thebitcoin.foundation/v/ but going by version number I really don't see what "old version" are you saying
a111: Logged on 2018-11-13 22:48 deedbot: http://ossasepia.com/2018/11/13/v-with-vtools-keccak-hashes-and-its-own-tree/ << Ossasepia - V with VTools, Keccak Hashes and Its Own Tree
deedbot: http://www.loper-os.org/?p=2743 << Loper OS - Finite Field Arithmetic Regrind into Keccak-V Format.
deedbot: http://ossasepia.com/2018/11/13/v-with-vtools-keccak-hashes-and-its-own-tree/ << Ossasepia - V with VTools, Keccak Hashes and Its Own Tree
diana_coman: http://btcbase.org/log/2018-11-13#1872069 -> http://ossasepia.com/2018/11/13/v-with-vtools-keccak-hashes-and-its-own-tree/ ☝︎
phf: i've narrated how to make v.pl work with keccak, i think i even posted an unsigned patch for mod6, butman is busy
asciilifeform: phf: fwiw my orig v.py is pretty sad in several wellknown ways -- i'm not particularly attached to it, would happily take mod6's, if there were (did i miss??) a ver of it patched to work in keccak
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 ? )
deedbot: http://blog.esthlos.com/esthlos-v-release-with-working-keccak/ << esthlos - esthlos-v: Release with Working Keccak
mircea_popescu: http://btcbase.org/log/2018-09-29#1855609 << what newbs are these ? the sort of newbs that press from v but not have keccak ? ☝︎
a111: Logged on 2018-09-27 15:36 phf: asciilifeform: but if you want a full "v replacement and i don't want to think about none of that" then just use esthlos's item. i believe he has a working keccak already
phf: when i started working on vtools there was already a handful of battle tested V implementations, that relied on vdiff.sh/gnu patch combination. vtools is a "drop in" replacement for the later. you get valid vpatch on the input, valid press on the output. the purpose is to nail down the format, and gradually replace out its parts (e.g. transparent sha->keccak transition)
phf: asciilifeform: but if you want a full "v replacement and i don't want to think about none of that" then just use esthlos's item. i believe he has a working keccak already
a111: Logged on 2018-09-26 18:48 asciilifeform: and incidentally i flatly refuse to have keccak patches on my box that are not outwardly distinguishable from old v. i'ma either use .v extension, or if mircea_popescu entirely hates, i'ma stuff e.g. asciilifeform_keccak in the names ( names currently not constrained by anybody )
asciilifeform: mod6: i've been using my orig vtron all this time. but recently diana_coman & mircea_popescu prodded, 'what's yer excuse for not moved to modern keccak-v' and i had no good counter, it's really time, so nao gotta actually uncrate phf's and make it go
asciilifeform: and incidentally i flatly refuse to have keccak patches on my box that are not outwardly distinguishable from old v. i'ma either use .v extension, or if mircea_popescu entirely hates, i'ma stuff e.g. asciilifeform_keccak in the names ( names currently not constrained by anybody )
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?
deedbot: http://blog.esthlos.com/esthlos-v-part-2-cl-keccak/ << esthlos - esthlos-v Part 2: cl-keccak
diana_coman: mircea_popescu, it's not a v.pl problem really at any rate; it wasn't directly clear keccak hashes and yest was a long day here
diana_coman: hanbot, right, it's keccak hashes so ofc v.pl barfs although it's weird that it first presses so much of it and only then randomly throws up; at any rate, on different arch, phf's vpatch pressed the mp-wp genesis so at least the genesis itself seems all right
esthlos: trinque: yes it does, I'm trying not to overcommit but could definitely add once the Keccak/V stuff is off my plate
spyked: diana_coman, I think v.pl will press either side of the http://btcbase.org/patches?patchset=vtools tree (keccak or sha), but not both. also, re. error, vtools_fixes_static_tohex should fix it. I've also encountered the linking error in e.g. http://btcbase.org/log/2018-05-21#1816314 and earlier. ☝︎
mircea_popescu: http://blog.esthlos.com/routes-to-keccak-in-esthlos-v/#footnote_5_24 << signing a patch signifies, at the common basis, a) that the signer has read the patch and that b) in his best effort determination b1) the transformation that the specified patch brings upon b2) the exact codebase specified will not b3) ~introduce~ properties that are b4) novel, unobvious and nefarious (all three).
deedbot: http://blog.esthlos.com/routes-to-keccak-in-esthlos-v/ << esthlos - Routes to Keccak in esthlos-v
a111: Logged on 2018-04-09 04:25 hanbot: phf et al: attempted to press latest vtools to the keccak head. v (mod6's) reports vtools_vpatch_newline not in flow, neither its antecedent vtools_fixes_static_tohex, despite both patches and (verified good) sigs present (they neither show up via flow command). v will press to vtools_vpatch.vpatch, but no further. see http://p.bvulpes.com/pastes/oNRhE/?raw=true .
a111: Logged on 2018-04-09 04:25 hanbot: phf et al: attempted to press latest vtools to the keccak head. v (mod6's) reports vtools_vpatch_newline not in flow, neither its antecedent vtools_fixes_static_tohex, despite both patches and (verified good) sigs present (they neither show up via flow command). v will press to vtools_vpatch.vpatch, but no further. see http://p.bvulpes.com/pastes/oNRhE/?raw=true .
a111: Logged on 2018-04-09 04:25 hanbot: phf et al: attempted to press latest vtools to the keccak head. v (mod6's) reports vtools_vpatch_newline not in flow, neither its antecedent vtools_fixes_static_tohex, despite both patches and (verified good) sigs present (they neither show up via flow command). v will press to vtools_vpatch.vpatch, but no further. see http://p.bvulpes.com/pastes/oNRhE/?raw=true .
hanbot: phf et al: attempted to press latest vtools to the keccak head. v (mod6's) reports vtools_vpatch_newline not in flow, neither its antecedent vtools_fixes_static_tohex, despite both patches and (verified good) sigs present (they neither show up via flow command). v will press to vtools_vpatch.vpatch, but no further. see http://p.bvulpes.com/pastes/oNRhE/?raw=true .
a111: Logged on 2018-03-28 21:08 spyked: my v-fu really leaves to be desired. so: http://btcbase.org/log/2018-03-28#1790147 <-- patch: http://lucian.mogosanu.ro/v/patches/vdiff_lib_xalloc_static_xnmalloc.vpatch and seal: http://lucian.mogosanu.ro/v/seals/vdiff_lib_xalloc_static_xnmalloc.vpatch.spyked.sig --> so I based those on vdiff_fixes_newline_gcc (parent of vdiff_keccak in http://btcbase.org/patches?patchset=vtools ) and while the patch verifies, it doesn't show up in my
spyked: my v-fu really leaves to be desired. so: http://btcbase.org/log/2018-03-28#1790147 <-- patch: http://lucian.mogosanu.ro/v/patches/vdiff_lib_xalloc_static_xnmalloc.vpatch and seal: http://lucian.mogosanu.ro/v/seals/vdiff_lib_xalloc_static_xnmalloc.vpatch.spyked.sig --> so I based those on vdiff_fixes_newline_gcc (parent of vdiff_keccak in http://btcbase.org/patches?patchset=vtools ) and while the patch verifies, it doesn't show up in my ☝︎
a111: Logged on 2018-01-18 20:58 mircea_popescu: consider concretely the case of eucrypt's keccak. diana_coman is writing it as a direct derivation off genesis, meaning on extant v impls if one wanted to import it they could import JUST it, without the rest of eucrypt (it'll be pulled in later through the usual procedure in eucrypt itself). superficially this may seem like it encourages phf to go "o i know, i'll just link keccak patch into my codebase rather than regring (i
mircea_popescu: consider concretely the case of eucrypt's keccak. diana_coman is writing it as a direct derivation off genesis, meaning on extant v impls if one wanted to import it they could import JUST it, without the rest of eucrypt (it'll be pulled in later through the usual procedure in eucrypt itself). superficially this may seem like it encourages phf to go "o i know, i'll just link keccak patch into my codebase rather than regring (i
a111: Logged on 2017-11-15 18:43 diana_coman: and re peterl's keccak implementation trouble is that thoroughly testing it looks atm as much work as writing a new one in the process anyway so whatever version ends up with tests and everything is the one that will make it into v too I would say
diana_coman: and re peterl's keccak implementation trouble is that thoroughly testing it looks atm as much work as writing a new one in the process anyway so whatever version ends up with tests and everything is the one that will make it into v too I would say