< phantomcircuit>
gmaxwell, well yes i was wondering if you had a % ?
< phantomcircuit>
(of course this changes with the hardware, but a ballpark)
< gmaxwell>
phantomcircuit: no clue, actually depends on other stuff going on. it wastes memory/tlb bandwidth.
< gmaxwell>
e.g. it's free if the next thing you're going to do is immediate run in a tight loop already in cache. :)
< gmaxwell>
obvious thing to try would be to drop the zeroizing from the code and benchmark, but I've not done that (well not recently at least).
< gmaxwell>
I don't think this has yet ever saved our bacon, but I've dealt with vulnerabilities elsewhere that would be made unexploitable due to zeroizing network buffers.
< sipa>
i'm generally in favor of saving bacon
< gmaxwell>
Bitcoin Core used to have a number of other adhoc additional security measures which have been dropped.
< gmaxwell>
E.g. there eas stack randomization via recursion for each thread.
< sipa>
which was actually optimized out by modern compilers...
< gmaxwell>
the zeroize on free could end up optimized out too (though I doubt it is currently!)
< phantomcircuit>
it would be nice if compilers supported "dont optimize this block"
< sipa>
phantomcircuit: not optimizing doesn't mean they suddenly have to respect stronger semantics
< gmaxwell>
phantomcircuit: C(++) is _not_ a fancy macro assembler.
< gmaxwell>
The language only promises to obey certian observable semantics of a particular abstract machine. The language cannot be directly mapped to your instruction set without _some_ transformation, (though not much if you're targeting a PDP-11 :) ) ... so there will always be some difference between what the code explicitly says and what the machine does.
< sipa>
PDP-11... didn't the y use braindead byte ordering?
< sipa>
Ah, wikipedia calls it "Middle-endian". Boring.
< Luke-Jr>
[01:51:02] <sipa> PDP-11… didn't the y use braindead byte ordering? <-- what are those symbols supposed to be?
< Luke-Jr>
oh, it's a unicode DELETE :x
< jgarzik>
speaking of unicode, thanks for the JSON issues wumpus
< GitHub189>
[bitcoin] pstratem opened pull request #6966: Cache CWalletDB pointer in CWallet to improve performance (master...wallet_speedup) https://github.com/bitcoin/bitcoin/pull/6966
< jgarzik>
cfields, FYI - we should be running "make $N_CPUS distcheck" in travis for bitcoin
< jgarzik>
secp256k1 already does this; just updated univalue to do so.
< cfields>
jgarzik: sounds good. At one pont we had to manually specify, because our number was using too much mem
< cfields>
i don't think it's a problem anymore, though
< jgarzik>
cfields, my basic point is s/make check/make distcheck/
< cfields>
jgarzik: oh. we have a distcheck build
< jgarzik>
cfields, in bitcoin? where?
< cfields>
jgarzik: rather, we 'make dist', cd into the result, and build from there
< cfields>
can't remember now why it's not an actual distcheck
< cfields>
s/dist/distdir
< jgarzik>
cfields, So, restarting, that's my point. We need to be doing make distcheck
< jgarzik>
cfields, Right now it bombs out in configure with DB C++ headers/libs. I haven't debugged.
< jgarzik>
cfields, 'make distcheck' has several additional validations over and above 'make dist' or 'make check'
< cfields>
jgarzik: heh, fair enough. i'm trying to remember why i did it that way
< cfields>
jgarzik: right. distcheck definitely passed somewhat recently. there are hacks in there to deal with making leveldb work
< jgarzik>
if [ "$RUN_TESTS" = "true" ]; then make $MAKEJOBS distcheck; fi
< jgarzik>
cfields, 'distcheck' verifies build attributes like builddir!=srcdir and several other useful details - it catches accidentally omitted make-clean objects as another of many examples.
< cfields>
jgarzik: need to avoid doing the double-configure, then. That would make it a third
< jgarzik>
cfields, ..and adds a build...
< jgarzik>
cfields, My guess was to distcheck on one-and-only-one build matrix build
< cfields>
jgarzik: well i think ccache would make the rebuild time close to zero. would need to experiment a bit with keeping the time down
< cfields>
but yes, i agree
< MarcoFalke>
What could be done when travis hangs?
< MarcoFalke>
thanks, running again.
< gmaxwell>
I believe there is nothing more waiting for 0.11 RC. If I'm incorrect, someone please pipe up and tell me what other PRs I should be reviewing/testing.
< gmaxwell>
wumpus: ^
< wumpus>
I don't think there's anything to be done there either (well apart from version bump and release notes)
< wumpus>
(and release notes don't necessarily have to wait before the tag)
< GitHub160>
bitcoin/0.11 984587a Wladimir J. van der Laan: bump version to 0.11.2
< wumpus>
* [new tag] v0.11.2rc1 -> v0.11.2rc1
< GitHub55>
[bitcoin] TheBlueMatt closed pull request #6964: Use Pieter's signing subkey instead of his primary key (master...verify-commits-fixes) https://github.com/bitcoin/bitcoin/pull/6964
< GitHub183>
[bitcoin] TheBlueMatt opened pull request #6967: Use Pieter's signing subkey instead of his primary key (master...verify-commits-fixes) https://github.com/bitcoin/bitcoin/pull/6967