17500+ entries in 0.032s
mod6: mircea_popescu: excellent point.
mod6: this is perhaps were a seperate branch of V for bsd only comes in. or maybe i misunderstand.
mod6: yeah, for now. seems the most viable approach.
mod6: yah yah, watch it ;)
mod6: right. exactly similar to this.
mod6: its a thing, it gets flashed on to some firmware, and it basically just is, you can talk to it and use it, but it is its own thing.
mod6: <+mircea_popescu> mod6 here's the problem with "Bitcoinos" : you will want it adapted for bitcoin needs, which necessarily means it won't be your tool of choice for doing almost anything else, which necessarily means maintaining it will be a pain in the ass. << agree. I think that what I'm getting at is maybe it ends up being like cisco ios.
mod6: so we may think of a different way of doing something like this, maybe it's not a full OS of sorts, maybe its a embedded deal.
mod6: i guess my thought is, if we wanna make bitcoinos - we will end up forking either SVR4 or BSD, and then getting married.
mod6: yeah, very much so. a good conversation to have though, as our future roadmap depends on some early-on food for thought.
mod6: for sure. our best bet, is bitcoinos.
mod6: because they can not use buildroot... at least, I don't *think* they can, easily at lesat. they could turn on Linux Binary Comapt mode and perhaps some other kernel tweeks. would need to be looked a.t.
mod6: <+mircea_popescu> mod6 so basically we can't use our convenient makefiles to build the pressed source ; openbsd people gotta finagle their own build chain to get the same source to compile and link ? << and further more, they'll never have the same build process like we want.
mod6: so a minor annoyance there. but alas.
mod6: SHA256 (blah.txt) = 827aa4d3ea7c8b7177abe0e2d1d87f45857755df32956fbc54e7a1c10981e6b4
mod6: 827aa4d3ea7c8b7177abe0e2d1d87f45857755df32956fbc54e7a1c10981e6b4 blah.txt
mod6: # sha256sum blah.txt
mod6: this is because BSD's sha/md commands spit out the digests in different way than on linux.
mod6: and further, the changes that we wanted to make with V (where we mechanically check to see the patch was applied correctly by checking the hashes) also will not work on bsd unless a bunch more alterations are made, but this is a side issue.
mod6: however, if he and I work together, we could possibly get some patches in place that would check to see what the local environment is and if __BSD__, then apply, otherwise, do not.
mod6: <+mircea_popescu>
http://log.bitcoin-assets.com/?date=24-01-2016#1383446 << wait, explain this to me ? << the idea is that our makefiles, or whatever build scripts will utilize V to build inside of the rotor (a linux thing) - the source must be compatable with that. phf's openbsd scripts are not compatible with this.
☝︎☟︎ mod6: you're just using it as a storage bin for the time being?
mod6: does that bring us to 8 nodes now
mod6: <+shinohai> mod6: i am fully synced nau ^^ << ^6
mod6: anyway, getting a buildable openbsd is a priority of mine. there are just bigger things in front of that for the moment.
mod6: having an alternate to linux is important to me. and i was able to build a static binary, but obviously this doesn't work with the rotor (linux only buildroot). i did build it with the stator.
mod6: yeah, i think i need to walk you through the exact steps. i did get it to build, and fully sync a chain even. was very happy about that.
mod6: <+ben_vulpes> mod6: i do believe that i understand now. << cool!
mod6: so either, we need a separate repository for openbsd patches (not a bad idea), or we should just put the new openbsd vpatch in the mailing list for those who need it -- let them just add it to their V 'patches' directoriy by hand
mod6: The hang up here is that, it basically can't be mirrored in the same place as the rest of the patches; simply because when one sync's up against a mirror your changes will break the rest of the tree.
☟︎☟︎ mod6: phf: your patch(s) did work for me on openbsd. i think, once we have all of trinque's makefiles ready to go with the new (forthcoming) version of V, you and I should work together to get a new vpatch of your openbsd changes submitted.
mod6: danielpbarron: thx for the heads up
mod6: '-has a couple songs in the rear bumper' wat?
mod6: <+mircea_popescu> like it or not this is the level of scrutiny that patches have to face, even if it makes develoipment slow. << i very much agree with this methodology.
mod6: I think it's vital that we all gain a good grasp of what the intricacies are in this code - myself included.
mod6: And 'you' in the sense of all of us. Not just Mr. P.
mod6: <+mircea_popescu> my one question, and not to mod6 in particular, is : can unsigned int nSize = ECDSA_size(pkey); be trusted to not fuck up the size ? << Just to touch back on this again - I'd like to see more of this. If you happen to be reading through the code, and there is a question, ask - let's discuss.
mod6: !up ascii_butugychag
mod6: <+mircea_popescu> my one question, and not to mod6 in particular, is : can unsigned int nSize = ECDSA_size(pkey); be trusted to not fuck up the size ? << Not very "warm and fuzzy" on the openssl trust factor either. Would some tests or debugging help around this part?
mod6: sig->s == 60000 (or "high")
mod6: so we have: sig->s = 100000 - 40000.
mod6: again [ which is defined as : int BN_sub(BIGNUM *r, const BIGNUM *a, const BIGNUM *b); BN_sub() subtracts b from a and places the result in r ("r=a-b"). ]
mod6: BN_sub(sig->s, order, sig->s);
mod6: then we jump into the if block and execu:
mod6: then this part: (BN_cmp(sig->s, halforder) < 0) will return -1 since 40000 < 50000
mod6: fHighS = true, order = 100000, halforder = 50000 (hence rshift1), and sig->s = 40000
mod6: and we do nothing, sig->s is already high
mod6: then this part: (BN_cmp(sig->s, halforder) < 0) will return 1 since 60000 > 50000
mod6: fHighS = true, order = 100000, halforder = 50000 (hence rshift1), and sig->s = 60000
mod6: so now on to fHighS
mod6: i'll type this out anyway.
mod6: ok, so did the first and second case for fLowS make sense then?
mod6: etc, there are man pages for each.
mod6: i'll note the code is not *identical* it does have different greater than, less than signs.
mod6: so we have: sig->s is assigned to 10000 - 60000 ; sig->s now = 40000
mod6: [ which is defined as : int BN_sub(BIGNUM *r, const BIGNUM *a, const BIGNUM *b); BN_sub() subtracts b from a and places the result in r ("r=a-b"). ]
mod6: BN_sub(sig->s, order, sig->s);
mod6: then we do this line:
mod6: (BN_cmp(sig->s, halforder) > 0) evaluates to 1 since 60000 > 50000
mod6: fLowS = true, order = 100000, halforder = 50000 (hence rshift1), and sig->s = 60000
mod6: and we do nothing, sig->s is already low.
mod6: then this line: (BN_cmp(sig->s, halforder) > 0) will return -1 since 40000 < 50000
mod6: fLowS = true, order = 100000, halforder = 50000 (hence rshift1), and sig->s = 40000
mod6: let's do fLowS first.
mod6: i apprecaite you all trying to help me.
mod6: i guess we can pick this up tomorrow, or whenever.
mod6: if you do a pull of that patch (be sure to obviously run dos2unix on it to get rid of CRLF), you should see that all of the lines in key.h:Sign() have tabs in front of them.
mod6: and we'll go from there.
mod6: then im gonna add tabs infront of all the non-empty lines in Sign()
mod6: im gonna add the code to key.h by hand.
mod6: so this is what i'm gonna do
mod6: yah, second one has no tabs at all.
mod6: lemme see on that one.