log☇︎
17900+ entries in 0.031s
mod6: so what are we trying to achieve here?
mod6: any way the real sig name is currently "bitcoin-asciilifeform.1.vpatch.mod6.sig" not <+jurov> only the question what is the '1' in bitcoin-asciilifeform.1.mod6.vpatch.sig doing there
mod6: and now its written in stone.
mod6: a long time ago. we had a different convention.
mod6: !up ascii_butugychag
mod6: and then v can differentiate them easily
mod6: which, i think is fine because then i can sign that patch and call it: asciilifeform-kills-integer-retardation.vpatch.mod6.sig
mod6: alf
mod6: that's how they need to be.
mod6: take a look at these: http://thebitcoin.foundation/v/seals/
mod6: so i was wrong above, not just .sig, but <vpatch_name>.vpatch.<wot_id>.sig
mod6: that's how they need to be
mod6: i.e.: asciilifeform-kills-integer-retardation.vpatch && asciilifeform-kills-integer-retardation.vpatch.asciilifeform.sig
mod6: <+jurov> oh when i see it: trinque and everyone, pls send detached signatures as <name>.sig << for V to work properly the sigfiles (seals) need to be named the same as the vpatch filename with a .sig on the end. is that what you're saying?
mod6: Attention TRB Testers: If you want to help test, please take the time to build trb via trinque's makefiles here; http://therealbitcoin.org/ml/btc-dev/2016-January/000190.html (Should be basically getting & verifing the tar ball; plus setting up a ~/.wot dir with keys for V to use) -- then a `make` in the directory. Please report your findings. Thanks. ☟︎☟︎
mod6: o7
mod6: i appreciate it.
mod6: or, whomever did that.
mod6: mircea_popescu: hey thanks for putting up your steps in the wiki
mod6: <+guruvan> mod6: that image I made last night isn't working - there's a fork at block 168000 that it's not liking << yeah this is the original v0.5.3 right?
mod6: yeah, this seems to be the case on ubuntu & deb (iirc), only works on gentoo for me. you fixed this once iirc. but i've since lost the changes :/
mod6: i should also point out this: http://dpaste.com/01R3NFN.txt
mod6: here's what it is asciilifeform: http://dpaste.com/3QGYPPK.txt
mod6: asciilifeform: no i don't think so.
mod6: :D
mod6: bitte
mod6: !up hanbot
mod6: and don't nuke your entire world.
mod6: so make sure you have your keys backed up!
mod6: and blew away their pgp keys too.
mod6: <+asciilifeform> ben_vulpes: if you try hard, and violate instructions sufficiently liberally, you can probably rm -rf your ENTIRE HOUSE << yes someone did do this.
mod6: so if you have yours somewhere it'd be awesome to get that and place it somewhere so I don't lose it again.
mod6: <+mod6> asciilifeform: hey, for a long time now I've been searching for the fix you provided to vdiff for debian/ubuntu; for some reason it barfs saying that there is an unmatched quote or something. ☟︎
mod6: asciilifeform: punindented was trying to help out a bit -- he hit that weird bug with vdiff on ubuntu or debian or something, when then reminded me that I lost your fix for that. I've searched through logs many times, can't seem to find it. I did actually ask yesterday too:
mod6: neat
mod6: that way i can actually debug my bitcoind with musl symbols etc.
mod6: instead, just pulled the source and built inside the rotor so it would be built with the gcc/musl that comes with buildroot ☟︎
mod6: <+jurov> mod6 why gdb? systemwide gdb works fine << my gentoo didn't have gdb built via portage, so when I went to build that, it blew up (re: yesterday).
mod6: was able to build v7.10
mod6: just needed to build gdb inside of the rotor, that i think was my problemo.
mod6: thanks in advance
mod6: asciilifeform: hey, for a long time now I've been searching for the fix you provided to vdiff for debian/ubuntu; for some reason it barfs saying that there is an unmatched quote or something.
mod6: or suggested lang?
mod6: <+asciilifeform> if i can't read it in (max) half hour and say WHAT EACH MOTHERFUCKING LINE DOES it is not a correct implementation !! << any ideas on a correct implementation?
mod6: thank /you/!
mod6: when you get there, if you hit any snags, just let me know.
mod6: well, that's pretty much it. the 'init' command should take care of the rest.
mod6: 1]: with version 99997 create (by hand) a ~/.wot directory and populate it with keys named as their irc-nick and .asc, like: mod6.asc or asciilifeform.asc
mod6: some pro-tips:
mod6: yeah perl 5, and that should be it. if you want it to be able to utilize the graphing utility, you need to install Graph::Easy, but that is not a requirement or prereq to it running.
mod6: ahh. ok, gotcha.
mod6: <+guruvan> mod6: bitcoin docker image is up - just testing now - patch wasn't working for me, so it's manually applied << ah, you had it build from V?
mod6: yup, me too -- code is done, pretty much tested thus far. but the changes to having .wot in the pwd instead of ~/ by default; i want to ensure that it works ok with trinque' makefiles before i publish.
mod6: the new, yet unreleased v99996 will check the resultant hashes of the files touched by a vpatch -- to add another layer to this.
mod6: i'm not really talkinga bout the pressing. as i was saying to ben, i checked all of my pressings by final output hash & have automated tests that check & ensure this outcome is correct.
mod6: right.
mod6: from those discussions, I'm under the impression that the ordering of the flow doesn't exactly have to be the exact same, as long as the pressing is the exact same.
mod6: <+asciilifeform> http://log.bitcoin-assets.com/?date=16-01-2016#1373510 << this, if true, is a serious condition and you ought post how/what << sure we can talk about this. we've actually discussed it a few times at least. ☝︎
mod6: mathematically even.
mod6: <+mircea_popescu> http://log.bitcoin-assets.com/?date=16-01-2016#1373499 >> yes it should. << yup. the topological flow might be ever so slightly different when listed, but the resulting pressed tree must be exactly the same. ☝︎
mod6: that being said, i have TONS of work to do if anyone wants to do something different thats directly useful.
mod6: i mean, we might never give a 'js' implementation the /blessing/ but if someone wants to work on that for themselves or whatever, cool with me.
mod6: my 0.00000002 was: hey, whatever floats your boat.
mod6: in that v_steps.pl file, you'll see the sha256 hashes are kept in a here-doc so they can be repeatedly tested.
mod6 runs
mod6: which to guruvan's delight, is also written in perl
mod6: in the package that includes the cucumber tests, you'll find a scenario with tags '@27' and '@pressFlag' called "User executes V with the press flag" -- it then will press out a tree, then do exactly what I saying above ^
mod6: i think i can say that i have automated tests now that even check this.
mod6: actually...
mod6: basically checking the mechanics to ensure that the resulting output was the same. this gave me confidence that my toposort was functioning as it should.
mod6: you know, one thing that I did to ensure that my pressing of the tree was happening correctly was to press out a tree, then do a full `find . -xtype f -print0 | xargs -0 sha512sum > manifest` to see what the final hash of the source file was, then compare it to what we had before -- what we were patching by hand.
mod6: for instance, in the flow ordering it doesn't really matter which comes first: maxint_locks_corrected or add_verifyall as long as they both come after their respective antecedents.
mod6: <+ben_vulpes> what do you mean "precedence levels" << as long as this is met. meaning that certain things come before other things.
mod6: we discussed it in here, a bit of varience is fine.
mod6: <+ben_vulpes> mod6: press of a given head should result in the *exact same* tree under all V's, as i understand it << mine was ever so slightly varient from alfs ☟︎☟︎
mod6: it doesn't have to be the ~exact~ tree mind you, just has to have the correct precedence levels
mod6: ben_vulpes's version in CL looks neat, but i can't even figure out how to run it since im a lisptard.
mod6: guruvan: yah, maybe someone will create a nice implementation in something more sane and maintain it.
mod6: well, theres a bunch of things that are bad.. like a lot of the cpan modules aren't maintained any more, etc. but if one stays away from the libs... *shrug*
mod6: i never thought perl 5 was bad, just v6.
mod6: but separately, the current version of v.pl is v99997, and i have a v99996 ready to go, just wanna accomplish a few other tasks first before i send it to the ML.
mod6: guruvan: oh you mean a new version of perl? i see that 5.22 is going to come out.
mod6: ^
mod6: http://thebitcoin.foundation/misc/vpatch-nodes.html
mod6: this way we could generate the topoligical graphs of vpatches like this:
mod6: <+guruvan> lol perl << im not so great with python, which alfs initial version was written in -- but the one thing that stuck out there for us to use was Graph::Easy
mod6: it's coming.
mod6: i gotta get that new version published. but im thinking that before I do so, i wanna have a few other things done too.
mod6: feel free to elaborate on this if you wish, punindented. he brought it up to me, i said, "hey, go nuts!"
mod6: !up punindented
mod6: punindented
mod6: there's a guy actually writing a js one too lol
mod6: And ben_vulpes wrote one in CL
mod6: well, to BingoBoingo's point... Alf provided the first implementation and POC, i just took it a few steps further in mine.
mod6: the idea of V is a versioning system based upon patches that include SHA512 hashes of the file before and after the given patch is applied -- and checks the given signatures of the wot entities who have signed off on the patch. ☟︎
mod6: that would be the bees knees.
mod6: yeah.
mod6: on my list of things to work on is also a high-level document for V -- sort of an RFC. that'd probably be better to start with, but sadly doesn't exist yet.
mod6: ya, there is a quick-start guide, and a full run down of functionallity provided. might be worth a read through before you dig in.
mod6: thx BingoBoingo