log
42 entries in 1.717s
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