< BlueMatt>
cfields: lets please get simple-to-review shit so we can (finally) get 0.14 out the door
< cfields>
BlueMatt: see the PR. I really have no preference
< BlueMatt>
wait, which pr?
< BlueMatt>
oh, comment
< BlueMatt>
cfields: I guess my (weak) preference is atomics
< BlueMatt>
because it doesnt change the compiled code for x86 (well, ok, only if we use release/acquire, but close enough) and is more obviously correct (tm)
< cfields>
BlueMatt: works for me.
< BlueMatt>
cfields: want me to pull it into that pr or a new one? it already has acks....
< cfields>
heh
< BlueMatt>
hmm?
< cfields>
BlueMatt: well, technically commit is buggy because it doesn't fix the race as advertised. So i'd call that a fix to the PR as opposed to something new
< cfields>
so I think it makes sense to just stick on top and poke for quick re-acks
< BlueMatt>
I'll change the pr title, then :p
< BlueMatt>
wait, no pr title was valid when opened
< BlueMatt>
"Clean up all known races/platform-specific UB at the time PR was opened #9708
< BlueMatt>
"
< BlueMatt>
happy now?
< gribble>
https://github.com/bitcoin/bitcoin/issues/9708 | Clean up all known races/platform-specific UB at the time PR was opened by TheBlueMatt · Pull Request #9708 · bitcoin/bitcoin · GitHub
< BlueMatt>
:p
< cfields>
heh, I was just making the point that it's a fix. I really don't care :)
< cfields>
lol
< cfields>
ok, i'm definitely closing mine now though, since 9708 is tagged for 0.14
< BlueMatt>
ok, sounds good, open another one :)
< cfields>
tell you what, I'll open another one based on master if it happens to not conflict with yours
< BlueMatt>
great! :)
< cfields>
without looking, i'd call it 50/50 :)
< BlueMatt>
conflict on git's within-3-lines shit? probably....actually conflict? no
< cfields>
actually, I think I'll pass on it either way. I think fatigue of these race commits is starting to set in. And since it's two 1-bit comparisons that have existed in prior releases, it's just not worth holding things up
< BlueMatt>
cfields: ok, I have no objections to that, either...when its std::string copies I'm not very happy, when its just pointer == NULL comparisons I suppose I dont care much
< cfields>
BlueMatt: sure. The only reason I'd push for it is if it was the lone thing keeping valgrind/helgrind/tsan/etc. from running cleanly.
< BlueMatt>
fair
< cfields>
and I don't think that's the case?
< BlueMatt>
my helgrind is still running cleanly :)
< bitcoin-git>
bitcoin/master ca9955e Jonas Schnelli: Remove bitseed.xf2.org form the dns seed list
< bitcoin-git>
bitcoin/master 33f3b21 Jonas Schnelli: Merge #9730: Remove bitseed.xf2.org form the dns seed list...
< bitcoin-git>
[bitcoin] jonasschnelli closed pull request #9730: Remove bitseed.xf2.org form the dns seed list (master...2017/02/seeds) https://github.com/bitcoin/bitcoin/pull/9730
< bitcoin-git>
[bitcoin] laanwj opened pull request #9735: devtools: Handle Qt formatting characters edge-case in update-translations.py (master...2017_02_qt_translations) https://github.com/bitcoin/bitcoin/pull/9735
< gmaxwell>
jl2012: we have block proposals, use getblocktemplate with the mode "proposal" and it will check a block while ignoring the pow.
< bitcoin-git>
[bitcoin] jnewbery opened pull request #9738: gettxoutproof() should return consistent result (master...fixgettxoutproof) https://github.com/bitcoin/bitcoin/pull/9738
< Chris_Stewart_5>
Is there a reason there isn't more functionality exposed for the java secp256k1 api? Or is it a matter of some one just needs to write it?
< Chris_Stewart_5>
I think you had mentioned there is a CPubKey::IsValid function inside of secp256k1 which is the consensus check if the pubkey is valid?
< sipa>
look at what bitcoin core does
< sipa>
CPubKey::IsFullyValid
< Chris_Stewart_5>
ahh, that makes much more sense.
< jnewbery>
Thanks! I've uncovered some gnarly stuff in the course of my archaeology :)
< cfields>
jnewbery: heh, i see that. Seems many of the tests have been accidentally working for a while
< jnewbery>
yup. Hopefully once these PRs have gone through we'll be in a better place and the tests will actually be testing things!
< cfields>
heh
< cfields>
jnewbery: i ran into something similar to 9707 (i think) when writing a test recently. I suck at python, and the exception model in mininode is not clear to me. Mind taking look when you have a min and seeing if my approach is reasonable or i'm just piling on more brokenness?
< jnewbery>
Absolutely. Very happy to look at it
< cfields>
jnewbery: thanks! It's the test added in #9720
< gribble>
https://github.com/bitcoin/bitcoin/issues/9720 | net: fix banning and disallow sending messages before receiving verack by theuni · Pull Request #9720 · bitcoin/bitcoin · GitHub
< cfields>
jnewbery: ping me when you have a min to look at it and i'll explain the problem?