< bitcoin-git>
[bitcoin] fanquake opened pull request #10270: Remove Clang workaround for Boost 1.46 (master...remove-boost-clang-workaround) https://github.com/bitcoin/bitcoin/pull/10270
< bitcoin-git>
[bitcoin] fanquake opened pull request #10271: Use std::thread::hardware_concurrency, instead of Boost, to determine available cores (master...replace-boost-getnumcores) https://github.com/bitcoin/bitcoin/pull/10271
< bitcoin-git>
[bitcoin] paveljanik opened pull request #10272: [Tests] Prevent warning: variable 'x' is uninitialized (master...20170425_FastRandomContext_test_warnings) https://github.com/bitcoin/bitcoin/pull/10272
< bitcoin-git>
[bitcoin] practicalswift closed pull request #10212: Make sure parameter names in .cpp and .h files are in sync (master...make-doxygen-happy-by-using-consistent-parameter-names) https://github.com/bitcoin/bitcoin/pull/10212
< jl2012>
are all 127.0.0.1 peers (incoming and outgoing) whitelisted by default?
<@wumpus>
no, absolutely not
<@wumpus>
remember, that's where tor onion connections come from
< gmaxwell>
jl2012: localhost does not get banned however.
< gmaxwell>
but it will happily be kicked.
< gmaxwell>
(also whitelisting implies a bunch of other stuff)
< gmaxwell>
I wonder if we define a FORCETX message that is only accepted from WL peers if we could get rid of that forced relay behavior...
<@wumpus>
unless someone implements https://github.com/bitcoin/bitcoin/issues/8973 to make onion connections come in on either an alternative port or a unix socket, it's unsafe to whitelist 127.0.0.1 [by default]
<@wumpus>
of course if you're not using tor, yuu can do that
< jl2012>
i see. I start with --whitelist=127.0.0.1 --addnode=127.0.0.1:9333 , but in getpeerinfo it says "whitelisted": false,
<@wumpus>
outgoing connections are not whitelisted ever
< bitcoin-git>
bitcoin/master c36ea69 Karl-Johan Alm: [wallet] Make sure pindex is non-null before possibly referencing in LogPrintf call.
< bitcoin-git>
bitcoin/master c29a0d4 Wladimir J. van der Laan: Merge #10265: [wallet] [moveonly] Check non-null pindex before potentially referencing...
< BlueMatt>
well you can already do that, but now we support FIBREoAC directly, no need for the pesky overhead of IP
< sipa>
well with P2P over IP over avian carrier you'd get ping timeouts
< BlueMatt>
ah, suppose you would via native FIBRE as well, indeed, i guess you need the local device support either way
< cfields>
sipa: probably more efficient for the avian carriers to tweet.
< sipa>
benchmarking libsecp256k1 signature validation, there is hardly any advantage for using hyperthreading cores
< sipa>
that doesn't mean there is no advantage for HT cores in bitcoin block validation, as ECDSA verification isn't the only thing involved
< gmaxwell>
sipa: what are you benchmarking on? because I saw non-trivial advantages before.
< sipa>
laptop, which is thermally throttled
< sipa>
though the effect is immediate
< gmaxwell>
wait you said hardly, how little is hardly. I would call 3% a lot.
< sipa>
oh, i would call 50% a lot
< sipa>
it's more like 5% benefit
< gmaxwell>
I'm doubtful 50% is really possible even with memory latency bound workloads, you'll bottleneck the instruction decoder.
< BlueMatt>
gmaxwell: lol, fucking x86 and its instruction decompressor
< gmaxwell>
BlueMatt: you mean icache expander. :P
< gmaxwell>
Cache doubler technology.
< BlueMatt>
lol
< BlueMatt>
yea
< BlueMatt>
I'm surprised their marketing material doesnt refer to x86 as "effecient instruction stream compression to double cache performance"
< gmaxwell>
IIRC one of the extensions for riscv is an explicit instruction stream compression.
< BlueMatt>
lol
< ryan-c>
I told bitcoind 0.14.0 to shutdown via bitcoin-cli over four hours ago, and it's still running. strace shows it waiting on a futex call. Is there anything I should do before sending it a kill -9? The system is not low on memory.
< BlueMatt>
ryan-c: a gdb "thread apply all bt" would be nice
< ryan-c>
BlueMatt: Can you walk me through that?
< ryan-c>
installing gdb one sec
< BlueMatt>
ryan-c: do you have a copy of the binary you are running (and does it have debug symbols)?
< BlueMatt>
if not, just kill -9, not much to be had
< ryan-c>
BlueMatt: It's the binary release from bitcoin.org, sha256sum 860a046514961aeead8b640f1a321da8eb575d727fd8c37de5a4cee5908bbd9d
< ryan-c>
`file` says the binary is stripped
< ryan-c>
waiting to for you to confirm there's nothing useful to dump before killing it
< gmaxwell>
ryan-c: 0.14.0? are you using addnode?
< BlueMatt>
ohoh, .1, duh
< ryan-c>
gmaxwell: yes, i am using addnode
< BlueMatt>
yea, kill -9
< BlueMatt>
known issue, fixed in .1
< gmaxwell>
ryan-c: known issue, run 0.14.1
< gmaxwell>
If you have more than 8 addnode peers it can get stuck in shutdowin in 0.14.0
< ryan-c>
gmaxwell: okay, cool thanks - I was shutting it down to replace with 0.14.1
< gmaxwell>
it's harmless to kill it.
< gmaxwell>
Sorry about that.
< BlueMatt>
can we close #10209 now that we fixed the "regenerate bitcoin-config.h" issue and #10210 now that #10215 is merged?