1 2016-12-23 01:13:19	0|dcousens|OOI, is there PR following https://gist.github.com/sipa/c65665fc360ca7a176a6?
  2 2016-12-23 03:19:12	0|bitcoin-git|[13bitcoin] 15jl2012 closed pull request #8756: Implement excessive sighashing protection policy with loose sighash estimation (06master...06sighashpolicylite) 02https://github.com/bitcoin/bitcoin/pull/8756
  3 2016-12-23 08:54:32	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #9412: build: Fix 'make deploy' for OSX (06master...062016/12/fix_mac_deploy) 02https://github.com/bitcoin/bitcoin/pull/9412
  4 2016-12-23 09:28:04	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #9413: [CoinControl] Allow non-wallet owned change addresses (06master...062016/12/qt_cc_change) 02https://github.com/bitcoin/bitcoin/pull/9413
  5 2016-12-23 11:08:18	0|bitcoin-git|13bitcoin/06master 140f921e6 15MarcoFalke: Merge #9406: Re-enable a blank v1 Tx JSON test...
  6 2016-12-23 11:08:18	0|bitcoin-git|13bitcoin/06master 14b371732 15Douglas Roark: Re-enable a blank v1 Tx JSON test
  7 2016-12-23 11:08:18	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/041331e1da23...0f921e6a0492
  8 2016-12-23 11:08:34	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9406: Re-enable a blank v1 Tx JSON test (06master...06testupdate) 02https://github.com/bitcoin/bitcoin/pull/9406
  9 2016-12-23 11:54:59	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #9405: Contrib: Mac: Fix mac deploy so that the dmg background works (06master...06macPythonTweak) 02https://github.com/bitcoin/bitcoin/pull/9405
 10 2016-12-23 12:49:09	0|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,"....
 11 2016-12-23 12:49:19	0|jonasschnelli|The user can only abort over a shutdown, right?
 12 2016-12-23 12:49:26	0|luke-jr|jonasschnelli: right, read the rest :p
 13 2016-12-23 12:50:25	0|jonasschnelli|IMO a "DoNotSave" and "PleaseSave" state should not be part of LoadMempool()
 14 2016-12-23 12:50:34	0|jonasschnelli|It should return what happend.
 15 2016-12-23 12:51:04	0|luke-jr|ok
 16 2016-12-23 12:51:10	0|jonasschnelli|the decision wether to dump or not should be part for DumpMempool
 17 2016-12-23 12:51:28	0|jonasschnelli|(of the controlling code)
 18 2016-12-23 12:51:41	0|luke-jr|then perhaps change user aborted to PartiallyLoaded?
 19 2016-12-23 12:51:59	0|luke-jr|although that's not much different I guess
 20 2016-12-23 12:52:03	0|jonasschnelli|Yes. Why not.
 21 2016-12-23 12:52:14	0|jonasschnelli|Though, it can only happens if the user has aborted. :)
 22 2016-12-23 12:54:02	0|luke-jr|or if the software decides to shutdown for any other reason (corrupt db after initial check?) I guess
 23 2016-12-23 12:54:42	0|jonasschnelli|but: user abort = don't dump,  corrupt db = dump
 24 2016-12-23 12:54:51	0|jonasschnelli|otherwise you overwrite an intact dump
 25 2016-12-23 12:55:05	0|jonasschnelli|or you don't overwrite an invalid/corrupted dump
 26 2016-12-23 12:56:19	0|luke-jr|T=1 startup, begin loading mempool; T=2 peer requests block, it's corrupt, shutdown (but mempool isn't done loading)
 27 2016-12-23 12:57:39	0|jonasschnelli|Yes. Thats indeed a problem.
 28 2016-12-23 12:58:09	0|luke-jr|not necessarily a problem? just treat it same as when the user requests it
 29 2016-12-23 12:58:24	0|jonasschnelli|But wait... if you example happens, the shutdown would result in userAborted which would not dump the mempool,... seems to be okay? Not?
 30 2016-12-23 13:02:32	0|sipa|how about returning a boolean "loaded everything that could be loaded"
 31 2016-12-23 13:02:53	0|paveljanik|sipa, +1
 32 2016-12-23 13:02:58	0|sipa|a corrupted mempool.dat file is no different than an empty onr
 33 2016-12-23 13:03:08	0|sipa|from the application's perspective
 34 2016-12-23 13:04:11	0|jonasschnelli|true = loaded successfull or corrupted, false = user aborted?
 35 2016-12-23 13:04:21	0|sipa|yes
 36 2016-12-23 13:04:33	0|sipa|but does that need a return state at all?
 37 2016-12-23 13:04:40	0|jonasschnelli|The true in case of a corrupted mempool seems strange.
 38 2016-12-23 13:04:47	0|sipa|doesn't the caller also know that an abort happened?
 39 2016-12-23 13:05:02	0|jonasschnelli|Yes. fShutdownRequested.
 40 2016-12-23 13:05:16	0|sipa|so, don't dump in case of fShutdownRequested
 41 2016-12-23 13:05:27	0|jonasschnelli|true
 42 2016-12-23 13:05:32	0|sipa|immediately after LoadMempool
 43 2016-12-23 13:06:31	0|jonasschnelli|Okay. Let me try to change this.
 44 2016-12-23 13:07:51	0|jonasschnelli|sipa: but fRequestShutdown is always true during DumpMempool(), not?
 45 2016-12-23 13:10:30	0|sipa|bool fDumpMempoolLater = false; { ...; LoadMempool(); fDumpMempoolLater = !fShutdownRequested; ... }
 46 2016-12-23 13:10:34	0|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.
 47 2016-12-23 13:11:28	0|sipa|and at shutdown { ...; if (fDumpMempoolLater) DumpMempool(); ... }
 48 2016-12-23 13:12:10	0|jonasschnelli|Okay. This make sense. Let me try...
 49 2016-12-23 13:21:53	0|jonasschnelli|thanks sipa: it's much simpler now: https://github.com/bitcoin/bitcoin/pull/9408/files
 50 2016-12-23 14:43:07	0|timothy|uhm strange, bitcoin-qt tray icon doesn't show on KDE5
 51 2016-12-23 14:47:18	0|jonasschnelli|timothy: Qt tray icon is broken. Yes.
 52 2016-12-23 14:47:35	0|jonasschnelli|Tray icons in general is a questionable concept.
 53 2016-12-23 14:47:42	0|timothy|oh ok, I was only testing new rc on archlinux :)
 54 2016-12-23 14:47:44	0|jonasschnelli|Apple moved away from it.
 55 2016-12-23 14:56:29	0|timothy|jonasschnelli: btw it works with v0.13.1 so it's a "regression"
 56 2016-12-23 14:57:13	0|jonasschnelli|timothy: hmm.. 0.13.1 works but 0.13.2rc1 does not?
 57 2016-12-23 14:57:22	0|timothy|jonasschnelli: yes
 58 2016-12-23 14:57:39	0|jonasschnelli|okay. Can you open an issue with your system details?
 59 2016-12-23 14:57:49	0|jonasschnelli|Also, mention if you have self compiled.
 60 2016-12-23 14:57:59	0|jonasschnelli|Probably a Qt issue
 61 2016-12-23 14:58:24	0|timothy|I built 0.13.1 with the same qt version :)
 62 2016-12-23 14:58:53	0|jonasschnelli|Yes. Indeed.
 63 2016-12-23 15:00:30	0|jonasschnelli|timothy: Do you have the tray icon enabled in your Bitcoin-Qt settings?
 64 2016-12-23 15:00:38	0|timothy|yes
 65 2016-12-23 15:00:48	0|timothy|for both the versions
 66 2016-12-23 15:00:58	0|jonasschnelli|Maybe related to: https://github.com/bitcoin/bitcoin/issues/8043
 67 2016-12-23 15:01:38	0|timothy|now I'm rebuilding rc version using the same "official" machine I use to build official archlinux packages
 68 2016-12-23 15:08:06	0|timothy|no, I confirm the bug. from 0.13.1 to 0.13.2rc1 bitcoin-qt tray icon is broken
 69 2016-12-23 15:08:59	0|timothy|I'll make more tries and debugging later
 70 2016-12-23 15:09:10	0|jonasschnelli|Okay. Thanks
 71 2016-12-23 16:54:45	0|bitcoin-git|[13bitcoin] 15rebroad opened pull request #9414: Skip processing of TXs that we already have. (06master...06DoNotProcessNewTxsMoreThanOnce) 02https://github.com/bitcoin/bitcoin/pull/9414
 72 2016-12-23 17:06:47	0|bitcoin-git|[13bitcoin] 15rebroad closed pull request #9402: Allow per network configuration file (06master...06PerNetworkConfig) 02https://github.com/bitcoin/bitcoin/pull/9402
 73 2016-12-23 19:34:48	0|gmaxwell|Can someone explain to me why we did this?
 74 2016-12-23 19:34:50	0|gmaxwell|-    LogPrintf("Shutdown : In progress...\n");
 75 2016-12-23 19:34:50	0|gmaxwell|+    LogPrintf("%s: In progress...\n", __func__);
 76 2016-12-23 19:36:52	0|sipa|i assume so that debug statements don't go out of date when code is moved/renamed?
 77 2016-12-23 19:38:19	0|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..." :)
 78 2016-12-23 19:39:19	0|gmaxwell|I'd buy that for debug=1 troubleshooting instrumentation.
 79 2016-12-23 19:41:46	0|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.
 80 2016-12-23 19:42:30	0|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.
 81 2016-12-23 19:42:34	0|gmaxwell|:)
 82 2016-12-23 22:04:41	0|gmaxwell|man, the backtraces that cross the signals stuff have two pages of boost goop.
 83 2016-12-23 22:12:42	0|BlueMatt|yes, it desperately needs replacing
 84 2016-12-23 22:12:48	0|BlueMatt|preferably with magic that puts things in threads, but whatever
 85 2016-12-23 22:17:26	0|bitcoin-git|[13bitcoin] 15gmaxwell opened pull request #9415: Reduce latency of ThreadMessageHandler. (06master...06better_sleep) 02https://github.com/bitcoin/bitcoin/pull/9415
 86 2016-12-23 22:18:57	0|BlueMatt|gmaxwell: hum, might chat with cfields on that one...I know he was looking at replacing that loop maybe even for 0.14
 87 2016-12-23 22:19:04	0|BlueMatt|i suppose that change is pretty obvious, though
 88 2016-12-23 22:24:53	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #9416: travis: make distdir before make (06master...06Mf1612-travisDistDirCheck) 02https://github.com/bitcoin/bitcoin/pull/9416
 89 2016-12-23 22:25:20	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #9417: Do not evaluate hidden LogPrint arguments (06master...06bypass_debug) 02https://github.com/bitcoin/bitcoin/pull/9417
 90 2016-12-23 22:29:34	0|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.
 91 2016-12-23 22:29:51	0|BlueMatt|that loop sleeps too much for like 3 separate reasons
 92 2016-12-23 22:29:54	0|BlueMatt|it needs replacing
 93 2016-12-23 22:30:02	0|BlueMatt|s/like 3/literally 3/
 94 2016-12-23 22:30:38	0|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.
 95 2016-12-23 22:31:01	0|gmaxwell|so I believe the only places where it actually adds latency to processing is if it suffers lock contention.
 96 2016-12-23 22:31:42	0|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.
 97 2016-12-23 22:31:43	0|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
 98 2016-12-23 22:31:51	0|BlueMatt|also if there is lock contention
 99 2016-12-23 22:32:49	0|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
100 2016-12-23 22:32:53	0|gmaxwell|yes, thats true. (that a recieve while in the middle of prcessing, won't get handled until the next time around).
101 2016-12-23 22:33:14	0|BlueMatt|yes, but not just next time around, also it might sleep prior to making it there
102 2016-12-23 22:33:29	0|gmaxwell|I thought about just introducing an atomic dontsleep bool that varrious things could set, but I expect that to get squaks.
103 2016-12-23 22:33:42	0|BlueMatt|thats nontrivial
104 2016-12-23 22:33:47	0|BlueMatt|I looked at doing that
105 2016-12-23 22:34:33	0|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
106 2016-12-23 22:34:46	0|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.
107 2016-12-23 22:34:49	0|BlueMatt|I guess its maybe not as bad as I thought, but super ugly
108 2016-12-23 22:35:11	0|BlueMatt|I had a patch to set dontsleep=false at the top of the loop
109 2016-12-23 22:35:11	0|gmaxwell|I think it's perfectly fine to just immediately make another pass through the nodes.
110 2016-12-23 22:35:26	0|BlueMatt|but others might squack since it often means an extra loop iteration
111 2016-12-23 22:35:32	0|gmaxwell|who cares?
112 2016-12-23 22:35:35	0|BlueMatt|oh, I think we're saying the same thign?
113 2016-12-23 22:35:46	0|gmaxwell|I think it's fine to make an extra pass over all peers after doing something.
114 2016-12-23 22:35:49	0|BlueMatt|yea, I mean its probably ok, but not a real fix....cory was looking at a real fix
115 2016-12-23 22:35:59	0|BlueMatt|yes, that would be ok
116 2016-12-23 22:36:07	0|BlueMatt|just gross, and in need of a real fix
117 2016-12-23 22:36:19	0|BlueMatt|there is also the issue of wanting to not old cs_vRecv during message processing, which we do now
118 2016-12-23 22:36:27	0|BlueMatt|cfields said he thought he could get that fixed in time for 0.14
119 2016-12-23 22:36:43	0|gmaxwell|I dunno, make a second pass isn't bad.. we're not talking about millions of peers. :)
120 2016-12-23 22:37:08	0|BlueMatt|nono, totally, but there are better fixes
121 2016-12-23 22:37:08	0|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.
122 2016-12-23 22:37:28	0|BlueMatt|yea, its surprisingly not, but only because of TRY_LOCK, which also means it does stupid things on contention