--- Day changed Fri Dec 23 2016 00:10 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 00:31 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:37 -!- cannon-c [ccc23f04@gateway/web/freenode/ip.204.194.63.4] has quit [Quit: Page closed] 00:43 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 00:44 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 00:54 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #9412: build: Fix 'make deploy' for OSX (master...2016/12/fix_mac_deploy) https://github.com/bitcoin/bitcoin/pull/9412 00:55 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has joined #bitcoin-core-dev 00:56 -!- AaronvanW [~ewout@207pc74.sshunet.nl] has quit [Changing host] 00:56 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 00:57 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-dddslgyqnmwgblcw] has joined #bitcoin-core-dev 01:02 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 01:04 -!- chris200_ [~chris2000@p5DCB47D8.dip0.t-ipconnect.de] has quit [] 01:05 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 258 seconds] 01:10 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 01:10 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 01:16 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Remote host closed the connection] 01:16 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Read error: Connection reset by peer] 01:16 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 01:16 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev 01:28 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #9413: [CoinControl] Allow non-wallet owned change addresses (master...2016/12/qt_cc_change) https://github.com/bitcoin/bitcoin/pull/9413 01:35 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 01:36 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 01:45 -!- MykelSIlver [~MykelSIlv@192-228-145-85.ftth.glasoperator.nl] has quit [Quit: -a- Android IRC 2.1.17] 02:07 -!- Victor_sueca is now known as Victorsueca 03:00 -!- murchandamus [~murchghos@ghostdub.de] has quit [Remote host closed the connection] 03:02 -!- murchandamus [~murchghos@81.169.211.205] has joined #bitcoin-core-dev 03:03 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev 03:08 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/041331e1da23...0f921e6a0492 03:08 < bitcoin-git> bitcoin/master b371732 Douglas Roark: Re-enable a blank v1 Tx JSON test 03:08 < bitcoin-git> bitcoin/master 0f921e6 MarcoFalke: Merge #9406: Re-enable a blank v1 Tx JSON test... 03:08 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 03:08 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9406: Re-enable a blank v1 Tx JSON test (master...testupdate) https://github.com/bitcoin/bitcoin/pull/9406 03:17 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 03:18 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 03:35 -!- arowser [~quassel@106.120.101.38] has quit [Ping timeout: 250 seconds] 03:37 -!- fengling [~fengling@223.223.187.142] has quit [Ping timeout: 268 seconds] 03:44 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev 03:54 < bitcoin-git> [bitcoin] fanquake closed pull request #9405: Contrib: Mac: Fix mac deploy so that the dmg background works (master...macPythonTweak) https://github.com/bitcoin/bitcoin/pull/9405 04:37 -!- udiWertheimer [~udiWerthe@bzq-84-111-23-225.red.bezeqint.net] has joined #bitcoin-core-dev 04:49 < jonasschnelli> luke-jr: you wrote "If user aborts at T=5, and doesn't shut down the node, when it does finally shutdown at T=5000,".... 04:49 < jonasschnelli> The user can only abort over a shutdown, right? 04:49 < luke-jr> jonasschnelli: right, read the rest :p 04:50 < jonasschnelli> IMO a "DoNotSave" and "PleaseSave" state should not be part of LoadMempool() 04:50 < jonasschnelli> It should return what happend. 04:51 < luke-jr> ok 04:51 < jonasschnelli> the decision wether to dump or not should be part for DumpMempool 04:51 < jonasschnelli> (of the controlling code) 04:51 < luke-jr> then perhaps change user aborted to PartiallyLoaded? 04:51 < luke-jr> although that's not much different I guess 04:52 < jonasschnelli> Yes. Why not. 04:52 < jonasschnelli> Though, it can only happens if the user has aborted. :) 04:54 < luke-jr> or if the software decides to shutdown for any other reason (corrupt db after initial check?) I guess 04:54 < jonasschnelli> but: user abort = don't dump, corrupt db = dump 04:54 < jonasschnelli> otherwise you overwrite an intact dump 04:55 < jonasschnelli> or you don't overwrite an invalid/corrupted dump 04:56 < luke-jr> T=1 startup, begin loading mempool; T=2 peer requests block, it's corrupt, shutdown (but mempool isn't done loading) 04:57 < jonasschnelli> Yes. Thats indeed a problem. 04:58 < luke-jr> not necessarily a problem? just treat it same as when the user requests it 04:58 < jonasschnelli> But wait... if you example happens, the shutdown would result in userAborted which would not dump the mempool,... seems to be okay? Not? 05:02 < sipa> how about returning a boolean "loaded everything that could be loaded" 05:02 < paveljanik> sipa, +1 05:02 < sipa> a corrupted mempool.dat file is no different than an empty onr 05:03 < sipa> from the application's perspective 05:04 < jonasschnelli> true = loaded successfull or corrupted, false = user aborted? 05:04 < sipa> yes 05:04 < sipa> but does that need a return state at all? 05:04 < jonasschnelli> The true in case of a corrupted mempool seems strange. 05:04 < sipa> doesn't the caller also know that an abort happened? 05:05 < jonasschnelli> Yes. fShutdownRequested. 05:05 < sipa> so, don't dump in case of fShutdownRequested 05:05 < jonasschnelli> true 05:05 < sipa> immediately after LoadMempool 05:06 < jonasschnelli> Okay. Let me try to change this. 05:07 < jonasschnelli> sipa: but fRequestShutdown is always true during DumpMempool(), not? 05:10 < sipa> bool fDumpMempoolLater = false; { ...; LoadMempool(); fDumpMempoolLater = !fShutdownRequested; ... } 05:10 < jonasschnelli> Hmm... tried a bit, but, return true in case of "failed to open mempool" results in code hard to read. I guess I prefer my current solution. 05:11 -!- fengling [~fengling@223.223.187.142] has joined #bitcoin-core-dev 05:11 < sipa> and at shutdown { ...; if (fDumpMempoolLater) DumpMempool(); ... } 05:12 < jonasschnelli> Okay. This make sense. Let me try... 05:18 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev 05:21 < jonasschnelli> thanks sipa: it's much simpler now: https://github.com/bitcoin/bitcoin/pull/9408/files 05:34 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Remote host closed the connection] 05:37 -!- alpalp [~alpalp@cpe-24-27-58-209.austin.res.rr.com] has joined #bitcoin-core-dev 05:37 -!- alpalp [~alpalp@cpe-24-27-58-209.austin.res.rr.com] has quit [Changing host] 05:37 -!- alpalp [~alpalp@unaffiliated/alpalp] has joined #bitcoin-core-dev 05:41 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev 05:43 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Remote host closed the connection] 05:45 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev 05:52 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:11 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 06:15 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Remote host closed the connection] 06:32 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev 06:43 < timothy> uhm strange, bitcoin-qt tray icon doesn't show on KDE5 06:44 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds] 06:47 < jonasschnelli> timothy: Qt tray icon is broken. Yes. 06:47 < jonasschnelli> Tray icons in general is a questionable concept. 06:47 < timothy> oh ok, I was only testing new rc on archlinux :) 06:47 < jonasschnelli> Apple moved away from it. 06:53 -!- alpalp [~alpalp@unaffiliated/alpalp] has quit [Ping timeout: 252 seconds] 06:54 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev 06:56 < timothy> jonasschnelli: btw it works with v0.13.1 so it's a "regression" 06:57 < jonasschnelli> timothy: hmm.. 0.13.1 works but 0.13.2rc1 does not? 06:57 < timothy> jonasschnelli: yes 06:57 < jonasschnelli> okay. Can you open an issue with your system details? 06:57 < jonasschnelli> Also, mention if you have self compiled. 06:57 < jonasschnelli> Probably a Qt issue 06:58 < timothy> I built 0.13.1 with the same qt version :) 06:58 < jonasschnelli> Yes. Indeed. 07:00 < jonasschnelli> timothy: Do you have the tray icon enabled in your Bitcoin-Qt settings? 07:00 < timothy> yes 07:00 < timothy> for both the versions 07:00 < jonasschnelli> Maybe related to: https://github.com/bitcoin/bitcoin/issues/8043 07:01 < timothy> now I'm rebuilding rc version using the same "official" machine I use to build official archlinux packages 07:02 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev 07:08 < timothy> no, I confirm the bug. from 0.13.1 to 0.13.2rc1 bitcoin-qt tray icon is broken 07:08 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye] 07:08 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds] 07:08 < timothy> I'll make more tries and debugging later 07:09 < jonasschnelli> Okay. Thanks 07:09 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 07:12 -!- alpalp [~alpalp@cpe-24-27-58-209.austin.res.rr.com] has joined #bitcoin-core-dev 07:12 -!- alpalp [~alpalp@cpe-24-27-58-209.austin.res.rr.com] has quit [Changing host] 07:12 -!- alpalp [~alpalp@unaffiliated/alpalp] has joined #bitcoin-core-dev 07:21 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 07:23 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 07:35 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:6589:2a23:c894:6301] has quit [Quit: .] 07:37 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds] 07:38 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:80dd:c3b9:d3b8:8259] has joined #bitcoin-core-dev 07:42 -!- alpalp [~alpalp@unaffiliated/alpalp] has quit [Ping timeout: 246 seconds] 08:00 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 250 seconds] 08:02 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:80dd:c3b9:d3b8:8259] has quit [Quit: .] 08:04 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:80dd:c3b9:d3b8:8259] has joined #bitcoin-core-dev 08:06 -!- afk11 [~afk11@176.61.67.182] has joined #bitcoin-core-dev 08:06 -!- afk11 [~afk11@176.61.67.182] has quit [Changing host] 08:06 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev 08:12 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:80dd:c3b9:d3b8:8259] has quit [Quit: .] 08:14 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:80dd:c3b9:d3b8:8259] has joined #bitcoin-core-dev 08:21 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:80dd:c3b9:d3b8:8259] has quit [Quit: .] 08:22 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Quit: Ex-Chat] 08:24 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:8c55:8add:5903:7137] has joined #bitcoin-core-dev 08:38 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 08:54 < bitcoin-git> [bitcoin] rebroad opened pull request #9414: Skip processing of TXs that we already have. (master...DoNotProcessNewTxsMoreThanOnce) https://github.com/bitcoin/bitcoin/pull/9414 08:58 -!- alpalp [~alpalp@unaffiliated/alpalp] has joined #bitcoin-core-dev 08:58 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 09:06 < bitcoin-git> [bitcoin] rebroad closed pull request #9402: Allow per network configuration file (master...PerNetworkConfig) https://github.com/bitcoin/bitcoin/pull/9402 10:06 -!- alpalp [~alpalp@unaffiliated/alpalp] has quit [Read error: Connection reset by peer] 10:07 -!- alpalp [~alpalp@unaffiliated/alpalp] has joined #bitcoin-core-dev 10:36 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 10:52 -!- slsdhl [~srd@185.115.102.9] has joined #bitcoin-core-dev 11:06 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 11:07 -!- Elysus [~Elysus@unaffiliated/elysus] has joined #bitcoin-core-dev 11:25 -!- slsdhl [~srd@185.115.102.9] has quit [Ping timeout: 264 seconds] 11:29 -!- Elysus [~Elysus@unaffiliated/elysus] has quit [Ping timeout: 264 seconds] 11:30 -!- arowser [~quassel@106.120.101.38] has quit [Ping timeout: 250 seconds] 11:33 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev 11:34 < gmaxwell> Can someone explain to me why we did this? 11:34 < gmaxwell> - LogPrintf("Shutdown : In progress...\n"); 11:34 < gmaxwell> + LogPrintf("%s: In progress...\n", __func__); 11:36 < sipa> i assume so that debug statements don't go out of date when code is moved/renamed? 11:38 < gmaxwell> If the shutdown handling code is moved into a function twizzle-shutprep .. we still probably want the log to print "Shutdown: In progress..." and not "twizzle-shutprep: In progress..." :) 11:39 < gmaxwell> I'd buy that for debug=1 troubleshooting instrumentation. 11:41 < gmaxwell> This is the commit that did it, https://github.com/bitcoin/bitcoin/commit/00d1980b8fb8b834cb729b213834dfb38cb01bbf I really can't figure out why we merged that. 11:42 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has joined #bitcoin-core-dev 11:42 < gmaxwell> then again, many of the whitespace changes it made, made things more in line with the approved style but less in line with my personal preferences; so I suppose I'm biased. 11:42 < gmaxwell> :) 11:49 -!- Elysus [~Elysus@unaffiliated/elysus] has joined #bitcoin-core-dev 11:52 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has quit [Quit: Whatever ... bye] 12:01 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has joined #bitcoin-core-dev 12:38 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 12:43 -!- Elysus1 [~Elysus@host86-187-165-172.range86-187.btcentralplus.com] has joined #bitcoin-core-dev 12:45 -!- wolfspraul [~wolfsprau@bobbin.q-ag.de] has joined #bitcoin-core-dev 12:46 -!- Elysus [~Elysus@unaffiliated/elysus] has quit [Ping timeout: 250 seconds] 12:49 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 260 seconds] 12:56 -!- afk11 [~afk11@176.61.67.182] has joined #bitcoin-core-dev 12:56 -!- afk11 [~afk11@176.61.67.182] has quit [Changing host] 12:56 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev 12:56 -!- Elysus [~Elysus@unaffiliated/elysus] has joined #bitcoin-core-dev 12:59 -!- Elysus1 [~Elysus@host86-187-165-172.range86-187.btcentralplus.com] has quit [Ping timeout: 260 seconds] 13:08 -!- alpalp [~alpalp@unaffiliated/alpalp] has quit [Ping timeout: 260 seconds] 13:16 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 250 seconds] 13:20 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 13:20 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 13:22 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 13:44 -!- Elysus [~Elysus@unaffiliated/elysus] has quit [Ping timeout: 264 seconds] 13:47 -!- Elysus [~Elysus@unaffiliated/elysus] has joined #bitcoin-core-dev 13:50 -!- Elysus1 [~Elysus@host86-187-170-135.range86-187.btcentralplus.com] has joined #bitcoin-core-dev 13:54 -!- Elysus [~Elysus@unaffiliated/elysus] has quit [Ping timeout: 264 seconds] 13:54 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 258 seconds] 13:57 -!- Elysus [~Elysus@unaffiliated/elysus] has joined #bitcoin-core-dev 14:00 -!- afk11 [~afk11@176.61.67.182] has joined #bitcoin-core-dev 14:00 -!- afk11 [~afk11@176.61.67.182] has quit [Changing host] 14:00 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev 14:01 -!- Elysus1 [~Elysus@host86-187-170-135.range86-187.btcentralplus.com] has quit [Ping timeout: 260 seconds] 14:04 -!- Elysus [~Elysus@unaffiliated/elysus] has quit [Ping timeout: 264 seconds] 14:04 < gmaxwell> man, the backtraces that cross the signals stuff have two pages of boost goop. 14:10 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 14:11 -!- Elysus [~Elysus@unaffiliated/elysus] has joined #bitcoin-core-dev 14:12 < BlueMatt> yes, it desperately needs replacing 14:12 < BlueMatt> preferably with magic that puts things in threads, but whatever 14:17 < bitcoin-git> [bitcoin] gmaxwell opened pull request #9415: Reduce latency of ThreadMessageHandler. (master...better_sleep) https://github.com/bitcoin/bitcoin/pull/9415 14:18 -!- Elysus [~Elysus@unaffiliated/elysus] has quit [Ping timeout: 264 seconds] 14:18 < BlueMatt> gmaxwell: hum, might chat with cfields on that one...I know he was looking at replacing that loop maybe even for 0.14 14:19 < BlueMatt> i suppose that change is pretty obvious, though 14:19 -!- wvr [~wvr@215.red-83-59-62.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 14:19 -!- Elysus [~Elysus@unaffiliated/elysus] has joined #bitcoin-core-dev 14:24 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #9416: travis: make distdir before make (master...Mf1612-travisDistDirCheck) https://github.com/bitcoin/bitcoin/pull/9416 14:25 < bitcoin-git> [bitcoin] sipa opened pull request #9417: Do not evaluate hidden LogPrint arguments (master...bypass_debug) https://github.com/bitcoin/bitcoin/pull/9417 14:25 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 14:26 -!- Elysus [~Elysus@unaffiliated/elysus] has quit [Ping timeout: 264 seconds] 14:29 < gmaxwell> BlueMatt: yea, I dunno, I wrote it, then threw it out, then decided it might be worth submitting. It still doesn't skip the sleep when the cs_main check in the sideside fails. 14:29 < BlueMatt> that loop sleeps too much for like 3 separate reasons 14:29 < BlueMatt> it needs replacing 14:30 < BlueMatt> s/like 3/literally 3/ 14:30 < gmaxwell> well it doesn't really sleep, it gets interrupted by message reception. and basically any send we'd care about actually happens in the call tree of the recieve part of that loop. 14:31 < gmaxwell> so I believe the only places where it actually adds latency to processing is if it suffers lock contention. 14:31 < gmaxwell> e.g. rpc grabs cs_main, and causes none of the send processing to be successful, then it ends up sleeping for 100ms before trying again. 14:31 < BlueMatt> no, look again - it will sleep if you receive a message after processing the node for that message but prior to finishing the whole loop 14:31 < BlueMatt> also if there is lock contention 14:32 < BlueMatt> also lock contention can mean it sleeps both after a wakeup prior to doing real work or might mean it will sleep when it needed not to 14:32 < gmaxwell> yes, thats true. (that a recieve while in the middle of prcessing, won't get handled until the next time around). 14:33 < BlueMatt> yes, but not just next time around, also it might sleep prior to making it there 14:33 < gmaxwell> I thought about just introducing an atomic dontsleep bool that varrious things could set, but I expect that to get squaks. 14:33 < BlueMatt> thats nontrivial 14:33 < BlueMatt> I looked at doing that 14:34 < BlueMatt> because you need to be able to say "yes, I processed for node 0, but havent gotten to node 4" and the thread that does the message-pushing needs to read that, and figure out whether that means you need to not sleep or not 14:34 -!- slsdhl [~srd@185.115.102.7] has joined #bitcoin-core-dev 14:34 < gmaxwell> I don't think it's bad? I mean just a if dontsleep sleep=false at the bottom of the loop. And set dontsleep on message reception, and from the sendmessage csmain trylock failure. 14:34 < BlueMatt> I guess its maybe not as bad as I thought, but super ugly 14:35 < gmaxwell> I think it's perfectly fine to just immediately make another pass through the nodes. 14:35 < BlueMatt> I had a patch to set dontsleep=false at the top of the loop 14:35 < BlueMatt> but others might squack since it often means an extra loop iteration 14:35 < gmaxwell> who cares? 14:35 < BlueMatt> oh, I think we're saying the same thign? 14:35 < gmaxwell> I think it's fine to make an extra pass over all peers after doing something. 14:35 < BlueMatt> yea, I mean its probably ok, but not a real fix....cory was looking at a real fix 14:35 < BlueMatt> yes, that would be ok 14:36 < BlueMatt> just gross, and in need of a real fix 14:36 < BlueMatt> there is also the issue of wanting to not old cs_vRecv during message processing, which we do now 14:36 < BlueMatt> cfields said he thought he could get that fixed in time for 0.14 14:36 < gmaxwell> I dunno, make a second pass isn't bad.. we're not talking about millions of peers. :) 14:37 < gmaxwell> I ended up looking at this because I was surprised there was no lock inversion related to cs_vRecv and your pushmessages. but apparently not. 14:37 < BlueMatt> nono, totally, but there are better fixes 14:37 < BlueMatt> yea, its surprisingly not, but only because of TRY_LOCK, which also means it does stupid things on contention 14:42 -!- alpalp [~alpalp@unaffiliated/alpalp] has joined #bitcoin-core-dev 14:57 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Remote host closed the connection] 14:57 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev 14:58 -!- aalex [~aalex@64.187.177.58] has quit [Quit: Connection reset by beer] 15:17 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 15:24 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev [] 15:26 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving] 15:48 -!- alpalp [~alpalp@unaffiliated/alpalp] has quit [Ping timeout: 256 seconds] 15:52 -!- alpalp [~alpalp@cpe-24-27-58-209.austin.res.rr.com] has joined #bitcoin-core-dev 15:52 -!- alpalp [~alpalp@cpe-24-27-58-209.austin.res.rr.com] has quit [Changing host] 15:52 -!- alpalp [~alpalp@unaffiliated/alpalp] has joined #bitcoin-core-dev 16:15 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 264 seconds] 16:15 -!- alpalp [~alpalp@unaffiliated/alpalp] has quit [Ping timeout: 265 seconds] 16:51 -!- alpalp [~alpalp@unaffiliated/alpalp] has joined #bitcoin-core-dev 16:54 < phantomcircuit> im running master on an older slightly slower system 16:54 < phantomcircuit> it's got an ssd in it though 16:54 < phantomcircuit> and it's not running ar anywhere near 100% cu during ibd 16:54 < phantomcircuit> at block height 188k 16:54 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 16:54 < phantomcircuit> seems something is broken with ibd block downloads maybe? 16:57 < phantomcircuit> yeah i have one peer that is significantly slower than the others 16:59 < gmaxwell> it won't use much cpu before it starts verifying signatures. 16:59 < gmaxwell> early in the chain its latency bound because it only fetches 16 blocks at a time from each peer. 16:59 < gmaxwell> it doesn't make that much difference in the time for overall synchronization. 17:00 -!- PaulCape_ [~PaulCapes@vpn-london-5-10-104-59.hosts.getcloakvpn.com] has joined #bitcoin-core-dev 17:01 < phantomcircuit> gmaxwell, yeah i was only at ~3% cpu 17:01 < phantomcircuit> which is definitely not right 17:01 < phantomcircuit> i disconnected a peer and now im at 100% 17:01 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:8c55:8add:5903:7137] has quit [Ping timeout: 240 seconds] 17:01 < gmaxwell> well thats goofy. 17:01 < phantomcircuit> net thread is spinning doing deserialization 17:02 < gmaxwell> it'll disconnect a peer if they're stalling your download, and I know that works because it's a little twitchy about it. 17:02 < phantomcircuit> gmaxwell, doesn't seem to have worked here for whatever reason 17:34 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:1c67:b35:58a7:f2a3] has joined #bitcoin-core-dev 17:36 -!- PaulCape_ [~PaulCapes@vpn-london-5-10-104-59.hosts.getcloakvpn.com] has quit [Read error: Connection reset by peer] 17:43 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:1c67:b35:58a7:f2a3] has quit [Ping timeout: 258 seconds] 17:52 -!- slsdhl [~srd@185.115.102.7] has quit [Ping timeout: 250 seconds] 17:58 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:b861:70b4:79c5:b140] has joined #bitcoin-core-dev 18:23 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 258 seconds] 18:27 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-dddslgyqnmwgblcw] has quit [Quit: Connection closed for inactivity] 19:21 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 19:23 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 248 seconds] 19:57 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 20:04 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds] 20:06 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 20:14 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 260 seconds] 20:15 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.] 20:16 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 20:30 -!- alpalp [~alpalp@unaffiliated/alpalp] has quit [Ping timeout: 250 seconds] 20:51 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds] 21:11 < bitcoin-git> [bitcoin] rebroad closed pull request #9414: Skip processing of TXs that we already have. (master...DoNotProcessNewTxsMoreThanOnce) https://github.com/bitcoin/bitcoin/pull/9414 21:32 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 21:56 -!- rebroad [~rebroad@171.4.248.53] has joined #bitcoin-core-dev 21:57 < rebroad> I have a question about mapAlreadyAskedFor - it seems that entries are erased from it only when a tx is received... 21:57 < rebroad> what is the maximum size it can reach? and why aren't tx hashes erased when a block arrives? 21:58 < rebroad> and what is to stop a node inventing random tx hashes and filling the map? 21:58 < rebroad> (which will never be erased as the txs don't exist) 21:59 < gmaxwell> rebroad: it is a limitedmap. 22:00 -!- rebroad [~rebroad@171.4.248.53] has quit [Client Quit] 22:03 -!- rebroad_ [~rebroad@171.4.248.53] has joined #bitcoin-core-dev 22:08 < rebroad_> gmaxwell, ah ok. so limited to 50,000 entries which is the most invs that any node can send in one go without misbehaving 22:09 < rebroad_> so i guess a node could send 50,000 and replace the map with useless entries, but the worst that would happen is that the node would then request every tx hash received rather than queue/delay them by 2 minute increments 22:10 < rebroad_> i would have thought the threshold for misbehaviour perhaps could be a fraction of MAX_INV_SZ rather than MAX_INV_SZ itself 22:10 < rebroad_> sorry, thinking aloud 22:51 -!- cannon-c [ccc23f04@gateway/web/freenode/ip.204.194.63.4] has joined #bitcoin-core-dev 22:58 < bitcoin-git> [bitcoin] rebroad opened pull request #9418: Exit when no direct fetch (master...ExitWhenNoDirectFetch) https://github.com/bitcoin/bitcoin/pull/9418 23:02 -!- rebroad_ is now known as rebroad 23:03 < rebroad> #9418 is a very minimal PR.. just adds a return and reduces the indentation accordingly - hopefully not treading on the toes of {m,}any other PRs 23:03 < gribble> https://github.com/bitcoin/bitcoin/issues/9418 | Exit when no direct fetch by rebroad · Pull Request #9418 · bitcoin/bitcoin · GitHub 23:03 < rebroad> (although it does tread on the toes of various other commits of mine, but I shall rebase them as need be) 23:15 -!- rebroad [~rebroad@171.4.248.53] has quit [Ping timeout: 252 seconds] 23:15 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye] 23:46 < cfields> gmaxwell: heh, fixing this busted process loop has been my primary target for over a year now :) 23:48 < gmaxwell> cfields: ya. well I hope that a simple and expediant tweak isn't too distastful, I know you're working on big redesigns around it. 23:48 < cfields> no issues with quick changes if they help, but we're really close to having it fixed cleanly (imo) 23:49 < cfields> gmaxwell: my only request would be to base it on #9289, since that reworks all of that sleeping code 23:49 < gribble> https://github.com/bitcoin/bitcoin/issues/9289 | net: drop boost::thread_group by theuni · Pull Request #9289 · bitcoin/bitcoin · GitHub 23:50 < cfields> (no real logical changes there though) 23:50 < gmaxwell> I'd gladly do that. 23:51 < cfields> thanks :) 23:51 < cfields> BlueMatt and I have been squabbling over syntactic sugar on that one, but I think it's clear that it will go in in some form 23:53 -!- rebroad [~rebroad@ppp-58-8-29-68.revip2.asianet.co.th] has joined #bitcoin-core-dev