--- Day changed Wed Nov 09 2016 00:10 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:18 -!- DigiByteDev [~JT2@101.78.224.202] has joined #bitcoin-core-dev 00:18 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 240 seconds] 00:20 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev 00:25 -!- rubensayshi [~ruben@82.201.92.138] has joined #bitcoin-core-dev 00:32 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer] 00:34 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev 01:04 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has joined #bitcoin-core-dev 01:04 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has quit [Changing host] 01:04 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 01:10 -!- ChillazZ [~ChillazZ@194.97.152.20] has joined #bitcoin-core-dev 01:10 -!- ChillazZ is now known as Guest82720 01:13 -!- laurentmt [~Thunderbi@80.215.210.47] has joined #bitcoin-core-dev 01:16 -!- rebroad [~rebroad@cm-110-171-153-130.revip7.asianet.co.th] has joined #bitcoin-core-dev 01:16 < rebroad> gmaxwell, wumpus, sipa, I think I may have found a bug that can crash bitcoin nodes 01:17 < rebroad> potential DoS 01:17 < Victorsueca> rebroad: in latest version? 01:17 < rebroad> yes 01:18 < rebroad> or at least, someone else found it and used it against my node 01:18 < rebroad> but it's easy to fix 01:18 < jonasschnelli> rebroad: Does it crash or do you just get an exception? 01:18 < rebroad> crashes 01:18 < rebroad> well, both 01:19 < jonasschnelli> I guess we are talking about 9110 01:19 < jonasschnelli> PR #9110 01:19 < gribble> https://github.com/bitcoin/bitcoin/issues/9110 | CInv::GetCommand(): type=1373179482 unknown type · Issue #9110 · bitcoin/bitcoin · GitHub 01:19 < rebroad> yes 01:19 < rebroad> only if debug=net though 01:19 < rebroad> the "got inv" debug messsage 01:20 < jonasschnelli> Okay... 01:20 < Victorsueca> sounds like bitcoin core fails some assertion in there 01:20 < paveljanik> please add the info about debug=net to the PR... 01:21 -!- laurentmt [~Thunderbi@80.215.210.47] has quit [Quit: laurentmt] 01:21 < Victorsueca> rebroad: it crashes only with debug=net enabled? or it still crashes anyway but without log exception when disabled? 01:21 < rebroad> I have changed the code to simply strprintf an unknown and I think this should be an ok fix.. not tested sufficiently yet (as I don't have code to generate invalid inv messages yet) 01:21 < rebroad> Victorsueca, I suspect it'll only crash if debug=net but not tested with it not set yet 01:22 < rebroad> but someone out there is already sending these invalid invs... the address it came from was 50.254.73.145 01:23 < Victorsueca> if that's the case then it would be a bug at generating the exception warning message or writing it to the log 01:23 < jonasschnelli> I though ProcessMessages() executes always in a try/catch... 01:23 -!- montau is now known as whphhg 01:23 -!- whphhg [whphhg@gateway/vpn/mullvad/x-ekalgpqenpfpspgz] has quit [Quit: Leaving] 01:23 < rebroad> it's is possible that I have made a change that is making it vulnerable 01:24 < jonasschnelli> I think so... 01:24 < jonasschnelli> Going to test this now... 01:24 < rebroad> I don't think I have, but it's not beyond belief 01:24 -!- DigiByteDev [~JT2@101.78.224.202] has quit [Quit: DigiByteDev] 01:24 -!- fengling [~fengling@123.117.40.160] has quit [Ping timeout: 268 seconds] 01:24 < Victorsueca> maybe somebody should make a honeypot and wireshark it to see what message is causing this 01:25 < jonasschnelli> rebroad: you could try to reproduce the issue on master with a simple new RPC test (maybe called invalidinv.py) 01:25 < jonasschnelli> Victorsueca: it's simple to test... no need for a honeypot 01:25 < paveljanik> rebroad, and in every case: responsible disclosure next time, please... 01:26 < Victorsueca> ^ yeah, this things should be PGPed to the team 01:26 < jonasschnelli> Indeed (if you think your right) 01:27 <@wumpus> I'm fairly sure tI've tried to do this before, though probably not with debug=net 01:28 -!- rebroad [~rebroad@cm-110-171-153-130.revip7.asianet.co.th] has quit [Ping timeout: 250 seconds] 01:32 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Ping timeout: 265 seconds] 01:33 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 01:33 -!- DigiByteDev [~JT2@101.78.224.202] has joined #bitcoin-core-dev 01:33 <@wumpus> it'd need to call CInv::ToString or CInv::GetCommand to get this exception, indeed something that only happens with debugging on 01:33 <@wumpus> I think it's somewhat unexpected for a ToString call to raise an exception 01:34 <@wumpus> however the exception should not crash the program 01:39 < Victorsueca> the log says something about St12out_of_range, that sounds like something that was asserted to be within certain range is not 01:40 < Victorsueca> maybe the type number? 01:41 < fanquake> wumpus Yes you have. See #1625 01:41 < gribble> https://github.com/bitcoin/bitcoin/issues/1625 | Bitcoin-Qt: exception in CInv::GetCommand() when using -onlynet="IPv6" · Issue #1625 · bitcoin/bitcoin · GitHub 01:41 < fanquake> So we've seen this/a similar issue before. 01:41 <@wumpus> managed to get the message in the log, however no crash 01:51 -!- fengling [~fengling@123.117.40.160] has joined #bitcoin-core-dev 01:54 < bitcoin-git> [bitcoin] fanquake opened pull request #9111: Remove unused variable UNLIKELY_PCT from fees.h (master...remove-unused-unlikely-pct) https://github.com/bitcoin/bitcoin/pull/9111 01:54 -!- ratoder [~ratoder@static.111.19.201.138.clients.your-server.de] has quit [Remote host closed the connection] 02:05 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/924de0bd75a7...e9847303e708 02:05 < bitcoin-git> bitcoin/master addfdeb Andrew Chow: Multiple Selection for peer and ban tables... 02:05 < bitcoin-git> bitcoin/master 1077577 Andrew Chow: Fix auto-deselection of peers 02:05 < bitcoin-git> bitcoin/master e984730 Wladimir J. van der Laan: Merge #8874: Multiple Selection for peer and ban tables... 02:11 -!- rebroad [~rebroad@ppp-58-8-29-68.revip2.asianet.co.th] has joined #bitcoin-core-dev 02:13 < rebroad> apologies for the less than ideal disclosure... I purposefully did not mention the issue I'd raised on here for that reason (bad internet here, otherwise I'd already have wiped the issue the moment it got mentioned) 02:16 < bitcoin-git> [bitcoin] laanwj opened pull request #9112: Avoid ugly exception in log on unknown inv type (master...2016_11_invtype_debugging) https://github.com/bitcoin/bitcoin/pull/9112 02:27 < bitcoin-git> [bitcoin] rebroad opened pull request #9113: Return the type when it's unknown instead of throwing an exception (master...ReturnNotThrow) https://github.com/bitcoin/bitcoin/pull/9113 02:47 -!- DigiByteDev [~JT2@101.78.224.202] has quit [Quit: DigiByteDev] 03:01 < bitcoin-git> [bitcoin] fanquake opened pull request #9114: [depends] Set OSX_MIN_VERSION to 10.8 (master...depends-min-osx-10-8) https://github.com/bitcoin/bitcoin/pull/9114 03:10 -!- LeMiner2 [~LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev 03:12 -!- LeMiner [~LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has quit [Ping timeout: 260 seconds] 03:12 -!- LeMiner2 is now known as LeMiner 03:15 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev 03:23 -!- cdecker [~quassel@2a02:aa16:1105:4a80:6540:bcad:48df:1694] has joined #bitcoin-core-dev 03:23 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 03:25 -!- rebroad [~rebroad@ppp-58-8-29-68.revip2.asianet.co.th] has quit [Ping timeout: 260 seconds] 03:28 < jonasschnelli> I have started with the BIP151 implementation and are trying to split it into different PRs, though, not sure how easy that is. 03:34 <@wumpus> indeed, for next time: if you suspect a remote-triggerable crash bug, even if you're not sure, please don't immediately throw it in here, but use private ways of contacting 03:36 <@wumpus> 03:37 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev 03:37 <@wumpus> jonasschnelli: at least coordinate with cfields on the network level changes 03:54 < bitcoin-git> [bitcoin] paveljanik opened pull request #9115: Mention reporting security issues responsibly (master...20161109_secissues) https://github.com/bitcoin/bitcoin/pull/9115 04:01 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Read error: Connection reset by peer] 04:03 -!- fengling [~fengling@123.117.40.160] has quit [Ping timeout: 268 seconds] 04:07 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 256 seconds] 04:10 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 258 seconds] 04:21 < bitcoin-git> [bitcoin] ondrejsika opened pull request #9116: Allow getblocktemlate for not connected regtest node (master...master) https://github.com/bitcoin/bitcoin/pull/9116 04:31 -!- murch [~murch@79.219.101.213] has joined #bitcoin-core-dev 04:37 < jonasschnelli> wumpus: Yes. Good idea. Not sure if a PR with the implementation of the new message format without the actual encryption itself could make sense. 04:48 -!- rebroad [~rebroad@cm-110-171-153-130.revip7.asianet.co.th] has joined #bitcoin-core-dev 04:52 < bitcoin-git> [bitcoin] laanwj pushed 10 new commits to master: https://github.com/bitcoin/bitcoin/compare/e9847303e708...e81df49644c2 04:52 < bitcoin-git> bitcoin/master 50e8a9c Pieter Wuille: Remove unused ReadVersion and WriteVersion... 04:52 < bitcoin-git> bitcoin/master c2c5d42 Pieter Wuille: Make streams' read and write return void... 04:52 < bitcoin-git> bitcoin/master fad9b66 Pieter Wuille: Make nType and nVersion private and sometimes const... 04:52 < bitcoin-git> [bitcoin] laanwj closed pull request #9039: Various serialization simplifcations and optimizations (master...simpleserial) https://github.com/bitcoin/bitcoin/pull/9039 04:56 -!- rebroad [~rebroad@cm-110-171-153-130.revip7.asianet.co.th] has quit [Ping timeout: 265 seconds] 05:03 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 05:11 -!- rebroad [~rebroad@cm-110-171-153-130.revip7.asianet.co.th] has joined #bitcoin-core-dev 05:12 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/e81df49644c2...e0477f6d2072 05:12 < bitcoin-git> bitcoin/master fd5654c Pavel Janík: Check and enable -Wshadow by default. 05:12 < bitcoin-git> bitcoin/master 359bac7 Pavel Janík: Add notes about variable names and shadowing 05:12 < bitcoin-git> bitcoin/master e0477f6 Wladimir J. van der Laan: Merge #8794: Enable -Wshadow by default... 05:12 < bitcoin-git> [bitcoin] laanwj closed pull request #8794: Enable -Wshadow by default (master...20160922_Wshadow_enable) https://github.com/bitcoin/bitcoin/pull/8794 05:43 < jonasschnelli> cfields: net.h what's the advantage of using a Callable (ForEachNodeContinueIf(Callable&& func)) instead of just passing in a std::function? 05:51 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 05:51 < cfields> jonasschnelli: so that lambdas are overhead-free 05:55 < jonasschnelli> cfields: can you explain me what kind of overhead? (Sorry to bother you with basic c++) 05:57 < cfields> jonasschnelli: np. std::function necessarily does an allocation, is copyable, etc. But lambdas can essentially create inline code. 05:58 < cfields> by using a callable, you can pass in a lambda for "free", or pass in a std::function for flexibility. It gives the flexibility of both. 05:59 < cfields> (maybe I should've mentioned that earlier. You can pass a std::function into it if you'd like, it'll work as you'd want it to) 06:00 < jonasschnelli> cfields: here I pass in Lambda https://github.com/bitcoin/bitcoin/pull/9076/files#diff-b2bb174788c7409b671c46ccc86034bdR3824 ... the function structure defines the parameter as std::function, does this always result in a copy for the lambda? 06:00 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-htfasinlggxyyxxs] has joined #bitcoin-core-dev 06:01 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 06:01 < cfields> jonasschnelli: yes. a std::function is constructed there. 06:02 < jonasschnelli> Okay. So changing it to a callable would be more efficient.. right? 06:02 < jonasschnelli> (reducing a copy) 06:03 < cfields> jonasschnelli: yep, assuming you can neatly use a template in the definition 06:05 -!- murch [~murch@79.219.101.213] has quit [Read error: Connection reset by peer] 06:06 < cfields> jonasschnelli: think of it like something "printable". You could pass the constant "foo" into a "Print(std::string s) { printf("string" %s, s); }, which will construct a std::string just to throw it away 06:07 < jonasschnelli> cfields: Thanks. I think I see you point now. 06:07 < cfields> but if you used "template Print(T&& s) { std::cout << s; }, you can pass in a raw string for free 06:18 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev 06:19 < fanquake> paveljanik I'm probably wrong, but the hex/line numbers was the first thing that jumped out at me. 06:20 < paveljanik> fanquake, sure. But this is probably some issue on the builder side as it does not touch leveldb at all... 06:20 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:24 < MarcoFalke> I think I was hitting the assert in net.h https://github.com/bitcoin/bitcoin/blob/e9847303e708ab71b4d2c22ceb7d65c89615e18a/src/net.h#L772 ... I couldn't reproduce and debug.log only says ProcessMessages(version, 102 bytes) FAILED peer=10 http://pastebin.ubuntu.com/23451144/ 06:25 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has quit [Ping timeout: 244 seconds] 06:26 -!- ryanofsky [~russ@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 265 seconds] 06:27 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev 06:35 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has quit [Ping timeout: 244 seconds] 06:37 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev 06:39 -!- ryanofsky [~russ@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 06:46 < cfields> MarcoFalke: yes, i assumed that would cause a few crashes for the first few days 06:47 < cfields> MarcoFalke: can you run with -debug for a while? 06:48 < MarcoFalke> sure 06:49 < cfields> MarcoFalke: the issue is: we continue to send messages, even after the handshake has failed and we've decided to disconnect. I think it's a good thing to find out what those cases are. 06:53 -!- rebroad [~rebroad@cm-110-171-153-130.revip7.asianet.co.th] has quit [Ping timeout: 250 seconds] 06:55 -!- shesek [~shesek@bzq-84-110-53-48.cablep.bezeqint.net] has joined #bitcoin-core-dev 06:57 -!- fanquake [~fanquake@unaffiliated/fanquake] has left #bitcoin-core-dev [] 07:06 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 07:18 -!- abpa [~abpa@199.87.86.217] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 07:28 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 07:54 -!- laurentmt [~Thunderbi@80.215.210.146] has joined #bitcoin-core-dev 08:00 -!- laurentmt [~Thunderbi@80.215.210.146] has quit [Quit: laurentmt] 08:01 -!- whphhg [whphhg@gateway/vpn/mullvad/x-nlfnuubopulaydfr] has joined #bitcoin-core-dev 08:17 -!- ryanofsky [~russ@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 250 seconds] 08:17 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has quit [Ping timeout: 265 seconds] 08:19 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev 08:21 -!- Guyver2__ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 08:23 < MarcoFalke> cfields: Prob when expected != offered. See debug.log: https://paste.fedoraproject.org/476493/87085851/ 08:23 < MarcoFalke> or bt https://paste.fedoraproject.org/476491/08356147/ 08:23 < cfields> MarcoFalke: perfect, thanks 08:24 < cfields> MarcoFalke: hmm, seems to be in sending the reject... 08:24 -!- cysm [cysm@unaffiliated/paracyst] has quit [Ping timeout: 258 seconds] 08:25 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 264 seconds] 08:25 < MarcoFalke> And what is the feefilter in the bt? 08:25 -!- Guyver2__ is now known as Guyver2 08:26 < cfields> MarcoFalke: aha! I didn't see the bt 08:27 < cfields> MarcoFalke: yep, that's the problem. 08:28 < cfields> MarcoFalke: I'll pr a quick/dirty fix in a few min, and I'm working on a more robust solution 08:29 < cfields> MarcoFalke: quick fix: http://pastebin.com/raw/E8ZXsKYa 08:29 < MarcoFalke> that was quick :) 08:30 -!- ryanofsky [~russ@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 08:30 < cfields> MarcoFalke: well like i said, I expected it to point out a few issues. They should all be very easy to fix individually. 08:31 < cfields> (as long as there's a nice log/backtrace, that is :) 08:49 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 09:06 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 09:19 -!- testnet [~testnet@gateway/tor-sasl/testnet] has quit [Quit: Leaving] 09:25 -!- rubensayshi [~ruben@82.201.92.138] has quit [Remote host closed the connection] 09:28 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 09:30 -!- igno_peverell [~testnet@gateway/tor-sasl/ignopeverell/x-86067662] has joined #bitcoin-core-dev 09:30 -!- igno_peverell [~testnet@gateway/tor-sasl/ignopeverell/x-86067662] has left #bitcoin-core-dev [] 09:40 -!- ryanofsky [~russ@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds] 09:40 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has quit [Ping timeout: 260 seconds] 09:41 -!- testnet [~testnet@gateway/tor-sasl/testnet] has joined #bitcoin-core-dev 09:42 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev 09:50 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 09:53 -!- ryanofsky [~russ@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev 10:00 -!- cysm [cysm@unaffiliated/paracyst] has joined #bitcoin-core-dev 10:16 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds] 10:19 < bitcoin-git> [bitcoin] theuni opened pull request #9117: net: don't send feefilter messages before the version handshake is complete (master...feefilter-assert) https://github.com/bitcoin/bitcoin/pull/9117 10:20 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 10:23 < sipa> jonasschnelli: i was planning to work on bip151, but i'm not going to touch anything before the ongoing net refactors are done :) 10:26 < gmaxwell> cfields: if the issue in 9117 is feefilter before handshake, should it not be checking fSuccessfullyConnected? 10:27 < cfields> jonasschnelli and i just discussed a bit, i'm making sure that the current refactors at least make bip151 not harder, but hopefully easier too 10:30 < cfields> gmaxwell: i suppose that would work too in this case. just that fDisconnected happens to also catch the case when we've just decided to disconnect after a successful handshake 10:31 < MarcoFalke> gmaxwell: I think the handshake was done in the case I saw above: https://paste.fedoraproject.org/476493/87085851/raw/ 10:31 < cfields> er, at any time in the session after the handshake is done 10:31 < cfields> MarcoFalke: no, it's halfway done. We got their version and set it, but didn't like it, so didn't set a sendVersion 10:32 < gmaxwell> but it wouldn't catch cases where we weren't done but also weren't planning on disconnecting them? 10:34 < cfields> gmaxwell: i don't think that's a possibility 10:36 < cfields> gmaxwell: i'm cleaning up the disconnect logic atm so that it's hopefully more clear. I believe the only case where we'd want to send a message after we've set fDisconnect is for reject messages, no? 10:36 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer] 10:37 < gmaxwell> I don't really think we should be sending any messages after flipping that flag. 10:40 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev 10:43 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds] 10:43 < cfields> hmm, may be able to make that work 10:49 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 10:49 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer] 10:53 < morcos> sipa: Did you intend for fImporting to be set during LoadMempool? It is now, but I thought that was a bug, indeed it causes pruning.py to fail b/c sync isn't happening during the potentially long process of loading the mempool. (fImporting causes IBD to be true) 10:54 < morcos> I was going to PR a fix, but I realize now that fee estimation conveniently ignores the LoadMempool txs due to this, so now it requires a lot more thinking about what the correct behavior is 10:55 < sipa> morcos: hmm, IBD should probably not be true during LoadMempool 10:59 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev 11:16 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 252 seconds] 11:18 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev 11:22 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 11:26 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 11:32 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds] 11:35 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 11:37 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-giniuspiverieohf] has quit [Quit: Connection closed for inactivity] 11:44 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 260 seconds] 11:45 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 264 seconds] 11:48 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 11:53 < gmaxwell> the build is now a _flood_ ofr shadowing warnings for me. 11:53 < gmaxwell> thousands of them. 11:53 < paveljanik> gmaxwell, what compiler? Can you upload the log please? 11:54 < gmaxwell> gcc version 6.1.1 20160802 (Debian 6.1.1-11) 11:54 < paveljanik> old gcc? 11:54 < sipa> that's a very new gcc 11:54 < sipa> i also get those warning 11:55 -!- davec [~davec@cpe-24-243-230-253.hot.res.rr.com] has joined #bitcoin-core-dev 11:55 < Chris_Stewart_5> Is the CHECKSIG operation missing in BIP141 for P2WPKH & P2WPKH nested inside of P2SH? https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#p2wpkh 11:56 < paveljanik> can you please upload the log somewhere? 11:57 < paveljanik> There is #8808 but maybe we need even more for new gcc 11:57 < gribble> https://github.com/bitcoin/bitcoin/issues/8808 | Do not shadow variables (gcc set) by paveljanik · Pull Request #8808 · bitcoin/bitcoin · GitHub 11:58 < gmaxwell> paveljanik: http://0bin.net/paste/C-XT2Ww24Gb0-oSk#gTvVzT2VMvRmjuKhVgAP25zWIpGHhJUbOKamb4KKFi- 12:00 < paveljanik> fFlushOnClose is fixed there 12:01 < paveljanik> gmaxwell, looks like you are good candidate for ACK on #8808 8) 12:01 < gribble> https://github.com/bitcoin/bitcoin/issues/8808 | Do not shadow variables (gcc set) by paveljanik · Pull Request #8808 · bitcoin/bitcoin · GitHub 12:01 < jonasschnelli> sipa: Okay. That's great news. I can re-focus then on the SPV mode. 12:03 < gmaxwell> Where did we turn on these Wshadow warnings? 12:06 < gmaxwell> oh, I'd already pulled it off while bisecting. 8794 12:10 -!- davec [~davec@cpe-24-243-230-253.hot.res.rr.com] has quit [Ping timeout: 250 seconds] 12:11 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds] 12:15 < paveljanik> yes, but 8808 is missing. 12:15 < paveljanik> and I'm now testing with a bit older gcc than yours... 12:16 < sipa> i can test with 6.2.0 12:16 < paveljanik> great! I will install the VM with some newer one later 12:19 -!- davec [~davec@cpe-24-243-230-253.hot.res.rr.com] has joined #bitcoin-core-dev 12:20 < phantomcircuit> gmaxwell: yeah we shadow things all over the place 12:21 < sipa> let's fix it 12:25 <@wumpus> strange, I had no shadow warnings at all before I merged that 12:26 <@wumpus> or maybe one in leveldb or so, but certainly no flood 12:26 <@wumpus> I don't get it 12:26 <@wumpus> going to revert 12:27 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 12:27 <@wumpus> maybe we shouldn't do it at all, it's too compiler-dependent 12:28 < sipa> i think all the difficulty we have in figuring out how to resolve the -Wshadow warning exactly shows what problems actual unintentional shadowing could have 12:28 < sipa> and there is a clear upper bound on what -Wshadow can mean... i'm a bit surprised there even is compiler dependence here 12:28 < gmaxwell> In C it's utterly unambigious and fine, I'm less sure about C++ but I expect it's good to enable. But we should eliminate all the warnings first. Very weird that you weren't seeing them! 12:29 < MarcoFalke> I could check #8808 with 6.2.1 12:29 < gribble> https://github.com/bitcoin/bitcoin/issues/8808 | Do not shadow variables (gcc set) by paveljanik · Pull Request #8808 · bitcoin/bitcoin · GitHub 12:29 < gmaxwell> (by all I mean almost all, of course, obviously I don't care about one in leveldb) 12:29 <@wumpus> I'm not going to bother with it anymore, at least 12:29 <@wumpus> not just me *multiple people* tested it here: https://github.com/bitcoin/bitcoin/pull/8794 12:29 < bitcoin-git> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/f445d886126c00814c71b855fc2f36fdd7e11098 12:29 < bitcoin-git> bitcoin/master f445d88 Wladimir J. van der Laan: Revert "Check and enable -Wshadow by default."... 12:30 <@wumpus> seems just needless busywork, how many 'prevent shadowing' commits have we had and it's still a problem 12:31 < gmaxwell> Coding convention wise, I notice that 8808 adds _ to many local variables. I think there moderately common convention for using _ on function parameters. 12:33 < gmaxwell> Many other things are wshadow with no issues, but we have classes with many flag generic top level names. like "bits", "flags", "nversion"... and a codebase that hasn't had the warning for a long time. 12:33 <@wumpus> but those were supposed to be fixed already 12:33 <@wumpus> where are you getting all these warnings? 12:34 <@wumpus> can you maybe pastebin and post in that issue? 12:34 < gmaxwell> I pastebinned the warnings above: http://0bin.net/paste/C-XT2Ww24Gb0-oSk#gTvVzT2VMvRmjuKhVgAP25zWIpGHhJUbOKamb4KKFi- 12:34 <@wumpus> maybe paveljanik would like to know 12:34 < gmaxwell> Glad to help squash them all. 12:34 <@wumpus> jdid't we get rid of nVersion? 12:35 < sipa> of the serialize.h-based nVersion 12:35 < sipa> but there are still some nVersion variables scattered 12:35 <@wumpus> nah, I think there's more important things 12:35 <@wumpus> I thought this was done, but if there's another load of that bullshit 12:36 < gmaxwell> I really would like to understand how compliler differences came into play. 12:37 <@wumpus> probably they consider slightly different scopes 12:41 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds] 12:42 * paveljanik back 12:42 < paveljanik> I first done Wshadow clean build on OS X/clang 12:42 < paveljanik> then tested on newer clang 12:42 < paveljanik> than newer clang on Linux 12:42 < paveljanik> then old gcc on Linux. 12:43 < paveljanik> I'm now Wshadow clean on all clangs available to me and one gcc version (after 8808). 12:43 < paveljanik> There are millions of differences in them emitting warnings. 12:44 <@wumpus> I tried with the gcc that comes with Ubuntu 16.04 (5.4.0) as well as clang 4.0 master git on Linux 12:44 < MarcoFalke> I think gcc is more aggressive and also complains if a local var shadows a function name (such as size() or one of our own functions) 12:44 < paveljanik> exactly! 12:45 <@wumpus> haven't tested gcc 6.x, maybe that is uselessly agressive 12:47 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-btidavtkyosjetfi] has quit [Ping timeout: 245 seconds] 12:47 <@wumpus> http://stackoverflow.com/questions/2958457/gcc-wshadow-is-too-strict hah 12:47 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-ygljnoaihgmpvuvp] has joined #bitcoin-core-dev 12:51 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-sbopxxnizveswzjj] has joined #bitcoin-core-dev 12:55 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f445d886126c...fb156100f9b4 12:55 < bitcoin-git> bitcoin/master d8edf03 fanquake: Remove unused var UNLIKELY_PCT from fees.h 12:55 < bitcoin-git> bitcoin/master fb15610 Wladimir J. van der Laan: Merge #9111: Remove unused variable UNLIKELY_PCT from fees.h... 12:55 < bitcoin-git> [bitcoin] laanwj closed pull request #9111: Remove unused variable UNLIKELY_PCT from fees.h (master...remove-unused-unlikely-pct) https://github.com/bitcoin/bitcoin/pull/9111 13:06 -!- LeMiner [~LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has quit [Read error: Connection reset by peer] 13:07 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fb156100f9b4...faec09bc7f03 13:07 < bitcoin-git> bitcoin/master e5d682f jnewbery: Fix mininode version message format 13:07 < bitcoin-git> bitcoin/master faec09b Wladimir J. van der Laan: Merge #8894: [Testing] Include fRelay in mininode version messages... 13:07 < bitcoin-git> [bitcoin] dooglus opened pull request #9118: Remove requireGreater argment from TxConfirmStats::EstimateMedianVal() (master...remove-dead-code) https://github.com/bitcoin/bitcoin/pull/9118 13:11 -!- crescendo [~mozart@unaffiliated/crescendo] has joined #bitcoin-core-dev 13:12 < bitcoin-git> [bitcoin] laanwj closed pull request #9048: [0.13 backport] Fix handling of invalid compact blocks (0.13...fix-invalid-cb-ban-0.13) https://github.com/bitcoin/bitcoin/pull/9048 13:12 < morcos> wumpus: is it critical to be doing all this clean up on fee estimation right now? 13:12 < morcos> i'd at least like a chance to think about it before you merge all these changes 13:12 < morcos> i understand those variables are unused now 13:13 < morcos> but they may still be useful functionality for further extension of the fee estimation code 13:14 <@wumpus> morcos: no, imo it's not necessary, but I haven't heared you complain about it before 13:14 <@wumpus> you could just NACK those pulls 13:15 <@wumpus> if no one complains then dead code cleanups seems like a no-brainer 13:15 < morcos> i guess i just panicked b/c i saw one of them got merged before i even saw it 13:15 < morcos> within a 12 hours 13:15 < morcos> but that one actually was trivial 13:15 <@wumpus> that was just a one-liner 13:15 < morcos> i will comment on the other 13:15 < morcos> i hadn't actually looked at the changes on either of them yet 13:15 <@wumpus> also our usual policy is to remove dead code, we're using git to make it easy to bring back things if necessary 13:15 < morcos> but yes i'm in favor of the priority removal that was done of course, but the require greater logic was tricky to get right the first time 13:16 < morcos> i'd rather leave it until we're sure we won't want it again 13:16 <@wumpus> I'll just stop merging things now, only caused problems today I feel :/ 13:18 <@wumpus> just too many pulls... 13:22 < morcos> wumpus: i'm impressed you keep up as well as you do.. my head is spinning... i started today trying to doing a posthumous ACK to the serialization cleanups, and i still haven't gotten around to looking at the 2nd commit. 13:25 <@wumpus> I also have a harder and harder time keeping up 13:26 < morcos> i suppose its a good problem to have 13:26 < gmaxwell> wumpus: re the Wshadow warning, is it possible that the files aren't dirty when you change the flag so make isn't rebuilding them? 13:27 < gmaxwell> I was rebasing a branch from a distant version when I noticed the warngings, so my tree had been effectively make cleaned. 13:27 < bitcoin-git> [bitcoin] laanwj closed pull request #9118: Remove requireGreater argment from TxConfirmStats::EstimateMedianVal() (master...remove-dead-code) https://github.com/bitcoin/bitcoin/pull/9118 13:27 <@wumpus> gmaxwell: no, I cleaned both the tree and the ccache, for both compilers 13:28 <@wumpus> but I don't want to bother with the Wshadow warnings anymore, let's focus the rare time we have on more important things 13:31 < paveljanik> gmaxwell, can you please try http://tmp.janik.cz/q.diff? 13:31 < paveljanik> it should clear the nVersion from chain.h and others. 13:33 < gmaxwell> paveljanik: the only ones remaining with that are leveldb and bench/lockedpool.cpp 13:33 < paveljanik> gmaxwell, great! 13:33 < paveljanik> bench/lockedpool is clear IIRC. 13:33 < paveljanik> and leveldb is upstream 8) 13:33 < paveljanik> so fixed? ;-) 13:34 < gmaxwell> paveljanik: I see you're renaming local's to _local. That is a violation of the common convention in other codebases that function paramters get _prefixes. 13:34 < paveljanik> but I'll first retest on some rolling upstream Linux distro 13:34 < paveljanik> we used that even before and people agreed on it. 13:34 < paveljanik> some parts of the code use _, some _in, some In postfix.. 13:35 < gmaxwell> Were we really using it for _local_ variables before, not just function parameters? 13:35 < paveljanik> yes 13:35 < paveljanik> I was inspired by it. 13:36 < paveljanik> but sometimes, it was better to rename the variables... 13:36 < paveljanik> and thus I did so 13:36 < paveljanik> e.g. data -> vData to follow the typeName conventions used 13:37 < paveljanik> I understand it is not sexy to read all those diffs though 8) 13:38 < paveljanik> but please be patient 13:38 < gmaxwell> paveljanik: for example, in 8808 src/streams.h 13:39 < paveljanik> yes, read -> _read. 13:39 < gmaxwell> you change read to _read it would be more ideomatic to change it to someghing like nBytes or bread or nread or something like that. 13:40 < paveljanik> no problem, just comment there and I will change it ;-) 13:41 < gmaxwell> When you make these updates are you checking to make sure the existing code wasn't buggy? 13:41 < paveljanik> sometimes. I even found some bugs, yes. 13:42 < gmaxwell> paveljanik: Good. I'll gladly leave some comments. 13:50 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev [] 14:04 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 14:04 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 14:05 < bitcoin-git> [bitcoin] UdjinM6 opened pull request #9120: bug: Missed one "return false" in recent refactoring in #9067 (master...fixExitCodesBitcoinTx) https://github.com/bitcoin/bitcoin/pull/9120 14:07 < paveljanik> gmaxwell, thank you! 14:12 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 14:26 < jtimon> morcos: no, I'm still getting my weird error on walletbackup even with #9058, really killall bitcoind ; rm -rf ./qa/cache ; doesn't seem enough 14:26 < gribble> https://github.com/bitcoin/bitcoin/issues/9058 | Fixes for p2p-compactblocks.py test timeouts on travis (#8842) by ryanofsky · Pull Request #9058 · bitcoin/bitcoin · GitHub 14:27 < morcos> jtimon: not for me right? 14:37 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 14:43 < jtimon> reminder: I only get it by running all rpc tests, not running walletbackupt individually 14:43 < jtimon> you told me 9058 may help the other day, but it seems is unrelated :( 14:46 < jtimon> I'm locally getting errors on your branch, but I was getting them already and at this point I'm just doing something wrong with rpc tests somehow, so yeah, sorry for the too long explanation 14:51 < jtimon> btw, general thoughts on moving some fast extended tests to the common ones and maybe also some slow ones from the common ones to the extended ones? 14:56 < jtimon> re warnings you can still fix some shadowing even if you don't put the new flag yet 15:00 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 15:37 -!- davec [~davec@cpe-24-243-230-253.hot.res.rr.com] has quit [Ping timeout: 256 seconds] 15:42 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 15:43 -!- davec [~davec@cpe-24-243-230-253.hot.res.rr.com] has joined #bitcoin-core-dev 15:45 < jtimon> I'm starting to think it may not be just be but actually something between 1adf82ac and faec09bc 15:46 -!- cdecker [~quassel@2a02:aa16:1105:4a80:6540:bcad:48df:1694] has quit [Ping timeout: 246 seconds] 15:47 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 260 seconds] 15:53 < jtimon> s/just be/just me/ 15:57 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-sbopxxnizveswzjj] has quit [Quit: Connection closed for inactivity] 16:00 < jtimon> between 10775775 and d59a5184 my computer says, but I've risen false alarms before 16:07 < jtimon> but if people want to try to reproduce...again it's walletbackup that fails, with "python3 ./qa/pull-tester/rpc-tests.py" (with or without -parallel=N), but not python3 "./qa/pull-tester/rpc-tests.py backupwallet" 16:09 < jtimon> this happens in d59a5184 but not in 10775775 (to me) 16:10 < gmaxwell> cfields: you've been helping people with segwit mining updates: does this all sound good to you? https://bitcointalk.org/index.php?topic=1674590.0 16:11 -!- JackH [~laptop@79-73-184-38.dynamic.dsl.as9105.com] has quit [Remote host closed the connection] 16:13 < cfields> gmaxwell: sounds about right. Excluding the obvious possible serialization pitfalls 16:13 < BlueMatt> cfields: wanna respond to him there? :p 16:14 < sipa> gmaxwell: either he uses default_witness_commitmnt, and he does not need to care about txid or hash or anything 16:14 < BlueMatt> cfields: have anything that needs review? happy to trade for an ack on #9075 :p 16:14 < gribble> https://github.com/bitcoin/bitcoin/issues/9075 | Decouple peer-processing-logic from block-connection-logic (#3) by TheBlueMatt · Pull Request #9075 · bitcoin/bitcoin · GitHub 16:14 < sipa> or he does care about it, and then he needs to compute the witness root himself 16:15 < cfields> BlueMatt: heh, i'd have to find/dust off my bitcointalk credentials 16:16 < cfields> BlueMatt: not yet, I'm rethinking some of mine to take encryption into account. Happy to finish up with 9075 and ack though, I think you already addressed my concerns 16:16 < BlueMatt> cool, I'll move on and look at #8895, then 16:16 < gribble> https://github.com/bitcoin/bitcoin/issues/8895 | Better SigCache Implementation by JeremyRubin · Pull Request #8895 · bitcoin/bitcoin · GitHub 16:17 < BlueMatt> splitting main.cpp is so close I can taste it :p 16:17 < cfields> hehe 16:18 < sipa> woot 16:19 < cfields> gmaxwell: oh, default_witness_commitment contains the OP_RETURN + magic already. so as written, it's not clear if he'll dupe it 16:19 < sipa> cfields: yeah, see what i said abpve 16:23 -!- davec [~davec@cpe-24-243-230-253.hot.res.rr.com] has quit [Remote host closed the connection] 16:24 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds] 16:25 -!- davec [~davec@cpe-24-243-230-253.hot.res.rr.com] has joined #bitcoin-core-dev 16:42 -!- harrymm [~wayne@104.222.140.19] has quit [Ping timeout: 250 seconds] 16:58 < jtimon> it seem to magically happen in 50e8a9cc ... 16:58 < jtimon> e9847303 works for me 16:58 < morcos> jtimon: i really think you mean someone else.. i have no idea what you are talking about 16:59 < gmaxwell> sipa: he still needs the txid to compute the normal hashroot. 16:59 < gmaxwell> cfields: good spotting. 17:00 < jtimon> morcos: no, once we established your pr was not related, I was talking in general: these pr_ids are before your pr 17:00 < jtimon> s/pr_ids/commit ids/ 17:01 < jtimon> if anyone can confirm that does or doesn't have any problems with 50e8a9cc running the rpc tests, please tell me 17:06 < jtimon> morcos: yep, sorry, my fault, I confused you with sdaftuar 17:07 < sipa> gmaxwell: right! 17:08 < jtimon> morcos: whose pr is unrelated to my comments as well, I just tried his pr to fix my problem and it didn't work (but it's not his pr's fault) 17:12 < jtimon> and talking in general, if anyone besides travis can confirm that he run the rpc tests after 50e8a9cc that would be helpful 17:36 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev 17:57 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 17:59 < kanzure> sipa: have segwit bugfxies been backported(? forward-ported?) to elements? 18:02 < sipa> kanzure: elements alpha has not been touched in a long time 18:03 < sipa> we're working on a successor which will be based on segwit in core 18:05 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection] 18:06 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-core-dev 18:08 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:4905:1d60:ac9d:bd76] has quit [Quit: .] 18:09 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:a1c2:2fd4:419c:fcf5] has joined #bitcoin-core-dev 18:10 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:a1c2:2fd4:419c:fcf5] has quit [Client Quit] 18:11 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:a1c2:2fd4:419c:fcf5] has joined #bitcoin-core-dev 19:02 -!- baldur [~baldur@pool-100-2-154-133.nycmny.btas.verizon.net] has quit [Remote host closed the connection] 19:05 -!- harrymm [~wayne@104.222.140.86] has joined #bitcoin-core-dev 19:21 < cfields> gmaxwell: thanks for relaying 19:28 -!- baldur [~baldur@pool-100-2-154-133.nycmny.btas.verizon.net] has joined #bitcoin-core-dev 19:31 -!- jtimon [~quassel@186.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 246 seconds] 19:32 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-sinvertgurrypfyo] has joined #bitcoin-core-dev 19:50 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds] 20:05 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 20:25 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds] 20:29 -!- abpa [~abpa@2604:5500:16:6:2c68:e018:be3d:5d83] has joined #bitcoin-core-dev 20:34 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye] 21:04 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.] 21:08 -!- PaulCape_ [~PaulCapes@2604:5500:17:2ea:a1c2:2fd4:419c:fcf5] has joined #bitcoin-core-dev 21:11 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:a1c2:2fd4:419c:fcf5] has quit [Ping timeout: 256 seconds] 22:11 -!- DigiByteDev [~JT2@209.160.126.163] has joined #bitcoin-core-dev 22:20 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-htfasinlggxyyxxs] has quit [Quit: Connection closed for inactivity] 22:20 -!- baldur [~baldur@pool-100-2-154-133.nycmny.btas.verizon.net] has quit [Read error: Connection reset by peer] 22:22 -!- baldur [~baldur@pool-100-2-154-133.nycmny.btas.verizon.net] has joined #bitcoin-core-dev 22:22 -!- asoltys_ is now known as asoltys 22:25 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 22:26 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 22:27 <@wumpus> oops, the harddisk of one of my nodes just broke down 22:29 <@wumpus> Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error 22:29 <@wumpus> # 1 Extended offline Completed: read failure 40% 14648 1999472904 22:29 -!- face [~face@mail.hmel.org] has quit [Read error: Connection reset by peer] 22:31 <@wumpus> I've had harddisks die on me before, but never in this way, there's a huge range where reading just fails. Usually they just stop spinning up at all. 22:41 < sipa> i don't think my SSD ever spinned at all :( 22:44 <@wumpus> the user needs to provide the momentum 22:45 < sipa> :D 22:45 < sipa> that's very SMART 22:46 < paveljanik> and more fitness :-) 22:47 -!- LeMiner [~LeMiner@unaffiliated/leminer] has joined #bitcoin-core-dev 23:02 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-inicnahqycfyiwex] has joined #bitcoin-core-dev 23:15 < bitcoin-git> [bitcoin] paveljanik opened pull request #9121: Initialize variable to prevent compiler warning (master...20161110_rpcdump_uninitialized) https://github.com/bitcoin/bitcoin/pull/9121 23:17 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-sinvertgurrypfyo] has quit [Quit: Connection closed for inactivity]