1 2017-03-30T00:06:36  *** alpalp has joined #bitcoin-core-dev
  2 2017-03-30T00:06:36  *** alpalp has joined #bitcoin-core-dev
  3 2017-03-30T00:09:58  *** QBcrusher has quit IRC
  4 2017-03-30T00:11:29  *** dodomojo has joined #bitcoin-core-dev
  5 2017-03-30T00:22:28  *** droark has quit IRC
  6 2017-03-30T00:32:32  *** bityogi has quit IRC
  7 2017-03-30T00:43:42  *** Giszmo has quit IRC
  8 2017-03-30T00:54:08  *** Ylbam has quit IRC
  9 2017-03-30T00:59:38  *** trippysalmon has quit IRC
 10 2017-03-30T01:01:17  *** trippysalmon has joined #bitcoin-core-dev
 11 2017-03-30T01:24:53  *** To7 has joined #bitcoin-core-dev
 12 2017-03-30T01:40:51  *** Apocalyptic has joined #bitcoin-core-dev
 13 2017-03-30T02:22:13  <luke-jr> I wonder if it would be better to prune debug.log with fallocate/FALLOC_FL_PUNCH_HOLE
 14 2017-03-30T02:24:18  *** str4d has quit IRC
 15 2017-03-30T02:24:54  *** Rspigler has joined #bitcoin-core-dev
 16 2017-03-30T02:35:42  *** Rspigler has quit IRC
 17 2017-03-30T02:47:01  *** alpalp has quit IRC
 18 2017-03-30T03:20:25  *** sydc has joined #bitcoin-core-dev
 19 2017-03-30T03:54:54  *** dodomojo has quit IRC
 20 2017-03-30T03:58:38  *** dodomojo has joined #bitcoin-core-dev
 21 2017-03-30T03:58:47  *** justan0theruser has joined #bitcoin-core-dev
 22 2017-03-30T03:59:49  *** justanotheruser has quit IRC
 23 2017-03-30T04:11:18  *** dodomojo has quit IRC
 24 2017-03-30T04:13:19  *** goksinen has joined #bitcoin-core-dev
 25 2017-03-30T04:14:11  *** goksinen has quit IRC
 26 2017-03-30T04:20:44  *** goksinen has joined #bitcoin-core-dev
 27 2017-03-30T04:31:26  *** goksinen has quit IRC
 28 2017-03-30T04:36:58  *** niska has quit IRC
 29 2017-03-30T04:43:13  *** niska has joined #bitcoin-core-dev
 30 2017-03-30T05:01:23  <bitcoin-git> [bitcoin] tjps closed pull request #10059: [trivial] Removed one Boost usage and headers in util.cpp (master...tjps_boost) https://github.com/bitcoin/bitcoin/pull/10059
 31 2017-03-30T05:08:24  *** BlueMatt has quit IRC
 32 2017-03-30T05:08:39  *** BlueMatt has joined #bitcoin-core-dev
 33 2017-03-30T05:11:29  *** squidicuz has quit IRC
 34 2017-03-30T05:11:55  *** squidicuz has joined #bitcoin-core-dev
 35 2017-03-30T05:33:00  *** BlueMatt has quit IRC
 36 2017-03-30T05:37:08  *** BlueMatt has joined #bitcoin-core-dev
 37 2017-03-30T06:06:29  <wumpus> achow101: there's been discussion of having a signal to prune the debug log on command, none exists though. SIGHUP does reopen it, so you could rotate it using a stock log rotator
 38 2017-03-30T06:07:56  <wumpus> with default settings the debug log grows only very slowly so this is not an issue for most users
 39 2017-03-30T06:08:17  <wumpus> and developers that enable extra debug options tend to not want to automatically lose information
 40 2017-03-30T06:08:24  <wumpus> e.g. to collect info over a complete sync cycle
 41 2017-03-30T06:10:26  <gmaxwell> the way the prune thing works kinda stinks in any case. when I get log data from users it very frequently has omitted the interesting part, because they restart before asking for help.
 42 2017-03-30T06:10:37  <gmaxwell> and so I can't see why their node has rejected a valid block.
 43 2017-03-30T06:30:48  *** helo has quit IRC
 44 2017-03-30T06:32:33  *** helo has joined #bitcoin-core-dev
 45 2017-03-30T06:48:37  *** Ylbam has joined #bitcoin-core-dev
 46 2017-03-30T06:56:49  *** BashCo has quit IRC
 47 2017-03-30T06:57:29  *** BashCo has joined #bitcoin-core-dev
 48 2017-03-30T07:02:11  *** BashCo has quit IRC
 49 2017-03-30T07:03:49  *** dcousens has quit IRC
 50 2017-03-30T07:18:30  *** BashCo has joined #bitcoin-core-dev
 51 2017-03-30T07:19:11  <jonasschnelli> BlueMatt: I can't follow your comment: https://github.com/bitcoin/bitcoin/pull/9681/files#r108679775 ... can you elaborate?
 52 2017-03-30T07:23:16  <bitcoin-git> [bitcoin] jtimon opened pull request #10119: Util: Remove ArgsManager wrappers: (master...0.14-args-wrappers) https://github.com/bitcoin/bitcoin/pull/10119
 53 2017-03-30T07:25:23  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f34cdcbd806d...8ac804128671
 54 2017-03-30T07:25:23  <bitcoin-git> bitcoin/master 159fe88 John Newbery: Remove SingleNodeConnCB...
 55 2017-03-30T07:25:24  <bitcoin-git> bitcoin/master 8ac8041 MarcoFalke: Merge #10109: Remove SingleNodeConnCB...
 56 2017-03-30T07:25:47  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #10109: Remove SingleNodeConnCB (master...remove_single_node_conn_cb) https://github.com/bitcoin/bitcoin/pull/10109
 57 2017-03-30T07:49:34  *** harrymm has quit IRC
 58 2017-03-30T07:50:47  *** fanquake has joined #bitcoin-core-dev
 59 2017-03-30T07:51:25  <wumpus> FALLOC_FL_PUNCH_HOLE wouldn't improve that; though maybe the aggressive name gives some outlet when there's yet another issue with useless debug logs
 60 2017-03-30T07:52:12  <fanquake> heh https://imgur.com/a/Q5Dsq
 61 2017-03-30T07:53:02  *** vicenteH has joined #bitcoin-core-dev
 62 2017-03-30T07:53:09  <wumpus> fanquake: it's eating blocks instead of syncing them!
 63 2017-03-30T07:54:10  <wumpus> (yes yes '100% progress' is a moving target, so staying in the same place moves you backwards, relatively, you have to run to stay in the same place)
 64 2017-03-30T07:54:35  <wumpus> I guess we should add a max(0, progress)
 65 2017-03-30T07:59:33  *** CubicEarthh has joined #bitcoin-core-dev
 66 2017-03-30T08:00:07  <fanquake> wumpus any schedule for 0.14.1 ? I'm going to remove 9464, not important enough to be fixed.
 67 2017-03-30T08:01:28  <wumpus> fanquake: no precise shedule, though agreement seems to be that there should be a 0.14.1 'soon'
 68 2017-03-30T08:02:15  <fanquake> Only two issues tagged now, are there any more sitting around that should be making it in?
 69 2017-03-30T08:02:22  <wumpus> it's still blocked on the out of memory problems, we're going to PR some workarounds for 0.14
 70 2017-03-30T08:02:41  <wumpus> yep I'm working on one and sipa should have one
 71 2017-03-30T08:02:47  <fanquake> ok
 72 2017-03-30T08:03:33  *** harrymm has joined #bitcoin-core-dev
 73 2017-03-30T08:04:17  <wumpus> agree about #9464, as a display problem it's fairly low priority and should at least not block 0.14.1
 74 2017-03-30T08:04:18  <gribble> https://github.com/bitcoin/bitcoin/issues/9464 | [GUI] No GUI updates when running with --reindex or --reindex-chainstate · Issue #9464 · bitcoin/bitcoin · GitHub
 75 2017-03-30T08:04:29  *** talmai has joined #bitcoin-core-dev
 76 2017-03-30T08:04:32  <wumpus> but if someone fixes it it and the solution is not too invasive should be backported
 77 2017-03-30T08:05:51  <bitcoin-git> [bitcoin] fanquake closed pull request #10089: Fix shadowing of 'what' as described in #10080. (master...fix-what-shadowing) https://github.com/bitcoin/bitcoin/pull/10089
 78 2017-03-30T08:06:50  <wumpus> hrm some RPCs such as getmemoryinfo could be available from the point the RPC server is launched, not just after iniitalization finishes
 79 2017-03-30T08:07:40  <wumpus> also 'stop'
 80 2017-03-30T08:10:34  *** talmai has quit IRC
 81 2017-03-30T08:16:21  <bitcoin-git> [bitcoin] laanwj opened pull request #10120: util: Work around (virtual) memory exhaustion on 32-bit w/ glibc (master...2017_03_address_space_exhaustion_workaround) https://github.com/bitcoin/bitcoin/pull/10120
 82 2017-03-30T08:38:41  *** chjj has joined #bitcoin-core-dev
 83 2017-03-30T08:57:48  *** owowo has quit IRC
 84 2017-03-30T08:58:32  *** chjj has quit IRC
 85 2017-03-30T09:00:42  *** chjj has joined #bitcoin-core-dev
 86 2017-03-30T09:01:49  *** chjj has joined #bitcoin-core-dev
 87 2017-03-30T09:03:50  *** riemann has joined #bitcoin-core-dev
 88 2017-03-30T09:05:46  *** jtimon has quit IRC
 89 2017-03-30T09:06:47  *** CubicEarthh has quit IRC
 90 2017-03-30T09:17:48  *** BashCo_ has joined #bitcoin-core-dev
 91 2017-03-30T09:19:07  *** BashCo has quit IRC
 92 2017-03-30T09:21:59  <luke-jr> wumpus: maybe debug.log should only be pruned when the node considers itself synced + some time has passed?
 93 2017-03-30T09:22:20  <luke-jr> (FALLOC_FL_PUNCH_HOLE possible improvement is that it can do it without rewriting the kept data)
 94 2017-03-30T09:23:15  <jonasschnelli> fanquake: does #9464 fixes the negative progress (https://imgur.com/a/Q5Dsq)?
 95 2017-03-30T09:23:16  <gribble> https://github.com/bitcoin/bitcoin/issues/9464 | [GUI] No GUI updates when running with --reindex or --reindex-chainstate · Issue #9464 · bitcoin/bitcoin · GitHub
 96 2017-03-30T09:24:34  *** herzmeister[m] has quit IRC
 97 2017-03-30T09:24:34  *** frabrunelle has quit IRC
 98 2017-03-30T09:24:34  *** kewde[m] has quit IRC
 99 2017-03-30T09:25:13  <fanquake> jonasschnelli no, 9464 is just an issue I created that cover a few different GUI issues/quirks, I should add the negative progress output there as well.
100 2017-03-30T09:25:48  *** paveljanik has quit IRC
101 2017-03-30T09:26:24  *** herzmeister[m] has joined #bitcoin-core-dev
102 2017-03-30T09:34:41  *** chjj has quit IRC
103 2017-03-30T09:35:26  *** chjj has joined #bitcoin-core-dev
104 2017-03-30T09:37:26  <wumpus> btw travis is being flaky on master
105 2017-03-30T09:37:42  <wumpus> not sure if this is caused by #9294
106 2017-03-30T09:37:46  <gribble> https://github.com/bitcoin/bitcoin/issues/9294 | Use internal HD chain for change outputs (hd split) by jonasschnelli · Pull Request #9294 · bitcoin/bitcoin · GitHub
107 2017-03-30T09:38:14  <jonasschnelli> oh... i'll check
108 2017-03-30T09:39:52  <jonasschnelli> assumevalid.py failed...
109 2017-03-30T09:39:58  <jonasschnelli> maybe a rebase/merge issue.
110 2017-03-30T09:42:37  <wumpus> travis is failing on #10120 as well, but on wallet-hd.py
111 2017-03-30T09:42:38  <gribble> https://github.com/bitcoin/bitcoin/issues/10120 | util: Work around (virtual) memory exhaustion on 32-bit w/ glibc by laanwj · Pull Request #10120 · bitcoin/bitcoin · GitHub
112 2017-03-30T09:42:42  <wumpus> could also be a test framework related issue
113 2017-03-30T09:43:38  <fanquake> jonasschnelli what are your thoughts on the OSX Growl notification code? I'm not sure that it's even being developed/supported anymore. They moved to selling it through the mac app store, and last update was in October 2013.
114 2017-03-30T09:44:47  <wumpus> test_framework.authproxy.JSONRPCException: non-JSON HTTP response with '503 Service Unavailable' from server (-342)
115 2017-03-30T09:45:06  <wumpus> while waiting for the node to come up... I think you'll get that if no handler is installed
116 2017-03-30T09:45:29  <wumpus> there is a small window before handlers are registered
117 2017-03-30T09:45:35  <wumpus> so not completely unexpected
118 2017-03-30T09:46:16  <fanquake> wumpus did you just restart the build? I was in the middle on reading the log heh
119 2017-03-30T09:46:24  *** kewde[m] has joined #bitcoin-core-dev
120 2017-03-30T09:46:24  *** frabrunelle has joined #bitcoin-core-dev
121 2017-03-30T09:46:28  <wumpus> yes I restarted the build, sorry :)
122 2017-03-30T09:52:46  <wumpus> may well be that travis is just being slow and brings this issue to the surface
123 2017-03-30T10:10:10  *** To7 has quit IRC
124 2017-03-30T11:23:03  *** AaronvanW has joined #bitcoin-core-dev
125 2017-03-30T11:23:03  *** AaronvanW has joined #bitcoin-core-dev
126 2017-03-30T11:28:07  *** jl2012 has quit IRC
127 2017-03-30T11:42:46  <jonasschnelli> wumpus: hmmm.. assumevalid.py failed/failes on master (CRON travis): https://travis-ci.org/bitcoin/bitcoin/jobs/216360061#L5396
128 2017-03-30T11:42:50  <jonasschnelli> Can't reproduce locally
129 2017-03-30T11:42:59  <jonasschnelli> (I try now on Ubuntu 14.04
130 2017-03-30T11:50:41  <wumpus> I couldn't reproduce it locally either
131 2017-03-30T12:10:12  *** To7 has joined #bitcoin-core-dev
132 2017-03-30T12:18:00  *** alpalp has joined #bitcoin-core-dev
133 2017-03-30T12:18:00  *** alpalp has joined #bitcoin-core-dev
134 2017-03-30T12:21:58  *** makriath has joined #bitcoin-core-dev
135 2017-03-30T12:27:29  *** makriath has quit IRC
136 2017-03-30T12:30:58  <jnewbery> #10114 should fix assumevalid.py (and make assumptions in test cases more robust in general)
137 2017-03-30T12:30:59  <gribble> https://github.com/bitcoin/bitcoin/issues/10114 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
138 2017-03-30T12:31:18  <wumpus> jnewbery: great!
139 2017-03-30T12:31:59  <jnewbery> Travis is good (too good!) at uncovering sync and timing issues
140 2017-03-30T12:32:09  <wumpus> yes
141 2017-03-30T12:37:25  *** AaronvanW has quit IRC
142 2017-03-30T12:40:24  *** jl2012 has joined #bitcoin-core-dev
143 2017-03-30T12:43:25  *** alpalp has quit IRC
144 2017-03-30T13:00:29  *** alpalp has joined #bitcoin-core-dev
145 2017-03-30T13:00:29  *** alpalp has joined #bitcoin-core-dev
146 2017-03-30T13:06:10  *** alpalp has quit IRC
147 2017-03-30T13:14:01  *** bityogi has joined #bitcoin-core-dev
148 2017-03-30T13:20:06  *** riemann has quit IRC
149 2017-03-30T13:22:34  *** kexkey has joined #bitcoin-core-dev
150 2017-03-30T13:25:42  *** Guyver2 has joined #bitcoin-core-dev
151 2017-03-30T13:29:05  *** fanquake has quit IRC
152 2017-03-30T13:29:30  <BlueMatt> jonasschnelli: ie the user might call bumpfee, get an error saying they need to pay more, then call bumpfee again with a higher number, and get another error saying they need to pay /even/ more
153 2017-03-30T13:29:35  <BlueMatt> which is ok, but kinda annoying
154 2017-03-30T13:29:47  <BlueMatt> if they're already checked back-to-back, might as well merge them into one error
155 2017-03-30T13:29:51  <BlueMatt> so that that cant happen
156 2017-03-30T13:42:57  *** kexkey has quit IRC
157 2017-03-30T13:52:14  *** harrymm has quit IRC
158 2017-03-30T13:53:17  <bitcoin-git> [bitcoin] shitakee opened pull request #10121: Add missing header file (master...patch-1) https://github.com/bitcoin/bitcoin/pull/10121
159 2017-03-30T13:56:56  *** paveljanik has joined #bitcoin-core-dev
160 2017-03-30T13:56:56  *** paveljanik has joined #bitcoin-core-dev
161 2017-03-30T14:04:46  *** owowo has joined #bitcoin-core-dev
162 2017-03-30T14:10:55  *** harrymm has joined #bitcoin-core-dev
163 2017-03-30T14:21:02  *** Giszmo has joined #bitcoin-core-dev
164 2017-03-30T14:27:57  *** compumatrix has joined #bitcoin-core-dev
165 2017-03-30T14:32:15  <compumatrix> Is it really this silent in here?
166 2017-03-30T14:36:41  *** magicwund has joined #bitcoin-core-dev
167 2017-03-30T14:37:00  <compumatrix> hi magicwund...
168 2017-03-30T14:38:01  *** d9b4bef9 has quit IRC
169 2017-03-30T14:38:03  <magicwund> hey
170 2017-03-30T14:39:08  *** d9b4bef9 has joined #bitcoin-core-dev
171 2017-03-30T14:39:15  *** AaronvanW has joined #bitcoin-core-dev
172 2017-03-30T14:54:05  *** schnerchi has left #bitcoin-core-dev
173 2017-03-30T14:54:18  *** talmai has joined #bitcoin-core-dev
174 2017-03-30T14:54:29  *** schnerchi has joined #bitcoin-core-dev
175 2017-03-30T15:17:14  *** thermoman has joined #bitcoin-core-dev
176 2017-03-30T15:17:53  *** talmai has quit IRC
177 2017-03-30T15:27:00  *** compumatrix has quit IRC
178 2017-03-30T15:32:57  <bitcoin-git> [bitcoin] jnewbery opened pull request #10123: Allow debug logs to be excluded from specified component (master...debugexclude) https://github.com/bitcoin/bitcoin/pull/10123
179 2017-03-30T15:37:21  *** magicwund has quit IRC
180 2017-03-30T15:43:09  *** abpa has joined #bitcoin-core-dev
181 2017-03-30T15:45:56  *** magicwund has joined #bitcoin-core-dev
182 2017-03-30T16:02:43  <bitcoin-git> [bitcoin] jnewbery opened pull request #10124: [test] Suppress test logging spam (master...suppress_test_logging_spam) https://github.com/bitcoin/bitcoin/pull/10124
183 2017-03-30T16:11:39  *** BashCo_ has quit IRC
184 2017-03-30T16:12:13  *** BashCo has joined #bitcoin-core-dev
185 2017-03-30T16:16:35  *** BashCo has quit IRC
186 2017-03-30T16:19:46  *** Guyver2_ has joined #bitcoin-core-dev
187 2017-03-30T16:22:48  *** Guyver2 has quit IRC
188 2017-03-30T16:22:57  *** Guyver2_ is now known as Guyver2
189 2017-03-30T16:31:17  *** jtimon has joined #bitcoin-core-dev
190 2017-03-30T16:35:20  *** BashCo has joined #bitcoin-core-dev
191 2017-03-30T16:51:00  <jonasschnelli> Reminder for the european CEST people. Meeting will be in 2h 10' (summer time now!).
192 2017-03-30T17:20:27  <kanzure> i thought we had consensus to eliminate time zones?
193 2017-03-30T17:21:08  <gmaxwell> kanzure: we did, but the rest of the world hasn't yet.
194 2017-03-30T17:41:40  *** afk11 has joined #bitcoin-core-dev
195 2017-03-30T17:43:52  *** JackH has quit IRC
196 2017-03-30T17:44:17  *** rcd has joined #bitcoin-core-dev
197 2017-03-30T17:48:10  *** CubicEarthh has joined #bitcoin-core-dev
198 2017-03-30T17:54:41  *** brg444_ has joined #bitcoin-core-dev
199 2017-03-30T17:54:42  *** wbnns_ has joined #bitcoin-core-dev
200 2017-03-30T17:54:46  *** mappum_ has joined #bitcoin-core-dev
201 2017-03-30T17:59:34  *** wbnns has quit IRC
202 2017-03-30T17:59:34  *** brg444 has quit IRC
203 2017-03-30T17:59:34  *** jonasschnelli has quit IRC
204 2017-03-30T17:59:35  *** mappum has quit IRC
205 2017-03-30T17:59:36  *** Soligor has quit IRC
206 2017-03-30T17:59:43  *** wbnns_ is now known as wbnns
207 2017-03-30T17:59:53  *** jonasschnelli has joined #bitcoin-core-dev
208 2017-03-30T18:00:03  *** brg444_ is now known as brg444
209 2017-03-30T18:00:58  *** Soligor has joined #bitcoin-core-dev
210 2017-03-30T18:01:38  *** mappum_ is now known as mappum
211 2017-03-30T18:05:53  <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10125: Exit bitcoind immediately on shutdown instead of 200ms later (master...2017-03-faster-shutdown) https://github.com/bitcoin/bitcoin/pull/10125
212 2017-03-30T18:12:23  *** jonasschnelli has quit IRC
213 2017-03-30T18:12:23  *** jonasschnelli has joined #bitcoin-core-dev
214 2017-03-30T18:34:34  <bitcoin-git> [bitcoin] jnewbery closed pull request #9630: Add logging to GetAncestor if pindex->pprev == NULL (master...crashlogging) https://github.com/bitcoin/bitcoin/pull/9630
215 2017-03-30T18:40:34  <sdaftuar> wumpus: i think #9959 is ready for merge
216 2017-03-30T18:40:36  <gribble> https://github.com/bitcoin/bitcoin/issues/9959 | Mining: Prevent slowdown in CreateNewBlock on large mempools by sdaftuar · Pull Request #9959 · bitcoin/bitcoin · GitHub
217 2017-03-30T18:43:36  *** bsm117532 has quit IRC
218 2017-03-30T18:48:34  <wumpus> sdaftuar: ok!
219 2017-03-30T18:56:05  <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/8ac804128671...cde9b1a864c1
220 2017-03-30T18:56:06  <bitcoin-git> bitcoin/master eed816a Suhas Daftuar: Mining: return early when block is almost full
221 2017-03-30T18:56:06  <bitcoin-git> bitcoin/master 42cd8c8 Suhas Daftuar: Add benchmarking for CreateNewBlock
222 2017-03-30T18:56:07  <bitcoin-git> bitcoin/master 011124a Suhas Daftuar: Update benchmarking with package statistics
223 2017-03-30T18:56:30  <bitcoin-git> [bitcoin] laanwj closed pull request #9959: Mining: Prevent slowdown in CreateNewBlock on large mempools (master...2017-03-cnb-optimizations) https://github.com/bitcoin/bitcoin/pull/9959
224 2017-03-30T18:57:19  <sdaftuar> thanks!
225 2017-03-30T18:57:48  <BlueMatt> wumpus: what restictions are there on what code you can call from signal handlers?
226 2017-03-30T18:58:26  <sipa> BlueMatt: as far as I know, only modify simple variables
227 2017-03-30T18:58:35  <wumpus> BlueMatt: almost nothing can be invoked from signal handlers because signals arrive synchronously, so can be called in any context from any thread
228 2017-03-30T18:59:00  <BlueMatt> mmm
229 2017-03-30T18:59:03  <wumpus> everything that has the slightest risk of crashing when called reentrantly can't be used
230 2017-03-30T18:59:13  <wumpus> so yes, in practice most programs restrict to setting variables
231 2017-03-30T18:59:14  <BlueMatt> hmm, alright
232 2017-03-30T18:59:22  <wumpus> another used technique is a pipe
233 2017-03-30T19:00:27  <jonasschnelli> *dong*
234 2017-03-30T19:00:28  <gmaxwell> sdaftuar: plz backport #9959
235 2017-03-30T19:00:29  <gribble> https://github.com/bitcoin/bitcoin/issues/9959 | Mining: Prevent slowdown in CreateNewBlock on large mempools by sdaftuar · Pull Request #9959 · bitcoin/bitcoin · GitHub
236 2017-03-30T19:00:32  <gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
237 2017-03-30T19:00:39  <kanzure> hi.
238 2017-03-30T19:00:45  <sdaftuar> gmaxwell: will do (and here!)
239 2017-03-30T19:00:45  <paveljanik> Hi!
240 2017-03-30T19:00:48  <wumpus> *reading* from a pipe that has one byte in it, or something like that
241 2017-03-30T19:00:59  <michagogo> Oh, right, these are back to 10 PM now that DST is back
242 2017-03-30T19:01:00  <jtimon> hi
243 2017-03-30T19:01:00  <BlueMatt> wumpus: yea, I get it, but man that sucks
244 2017-03-30T19:01:05  <cfields> hi
245 2017-03-30T19:01:10  <wumpus> yes, UNIX signals suck
246 2017-03-30T19:01:14  <wumpus> #meetingstart
247 2017-03-30T19:01:18  <wumpus> #startmeeting
248 2017-03-30T19:01:18  <lightningbot> Meeting started Thu Mar 30 19:01:18 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
249 2017-03-30T19:01:18  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
250 2017-03-30T19:01:41  <instagibbs> hi
251 2017-03-30T19:01:46  <jeremyrubin> here
252 2017-03-30T19:01:56  <wumpus> BlueMatt: it shouldn't matter for the AbortNode() case though. Just make the conditional wait 200 milliseconds or so
253 2017-03-30T19:02:03  <jtimon> topics?
254 2017-03-30T19:02:24  <wumpus> doesn't matter if signals are slightly delayed
255 2017-03-30T19:02:30  <BlueMatt> wumpus: the wait is already 200ms
256 2017-03-30T19:02:30  <wumpus> yes, topics?
257 2017-03-30T19:02:34  <BlueMatt> talk about abortnode
258 2017-03-30T19:02:36  <BlueMatt> thats a reasonable topic
259 2017-03-30T19:02:38  <wumpus> BlueMatt: yes, but make it a wait on a conditional
260 2017-03-30T19:02:44  <BlueMatt> mmm, fair
261 2017-03-30T19:02:56  <BlueMatt> yes, for sigterm its reasonable to wait a few 100 ms
262 2017-03-30T19:03:03  <BlueMatt> for AbortNode it'll wake it immediately
263 2017-03-30T19:03:06  <wumpus> right.
264 2017-03-30T19:04:15  <BlueMatt> in other news, so we got 1/6 "Review Priority" PRs merged this week, that's ok, but we can do better :)
265 2017-03-30T19:04:45  <BlueMatt> oh, nvm, got 2/6
266 2017-03-30T19:04:49  <wumpus> FYI: https://github.com/bitcoin/bitcoin/projects/8
267 2017-03-30T19:05:26  <gmaxwell> BlueMatt: 2/6.
268 2017-03-30T19:05:28  <wumpus> removed the two that have been merged
269 2017-03-30T19:05:28  <jtimon> I don't think anyone commented in mine, at least I got review in others
270 2017-03-30T19:05:49  <gmaxwell> I forgot about the project tracker thing, but reviewed some of them anyways.
271 2017-03-30T19:06:32  <wumpus> doesn't matter, we'll only add pulls that were mentioned to have priority in the meeting to that project tracker, so if you pay attention at the meeting you don't need it :)
272 2017-03-30T19:07:31  <wumpus> anyhow, everyone go review them
273 2017-03-30T19:08:00  *** laurentmt has joined #bitcoin-core-dev
274 2017-03-30T19:08:21  <wumpus> topic: 0.14.1?
275 2017-03-30T19:08:29  <bitcoin-git> [bitcoin] sipa opened pull request #10126: Compensate for memory peak at flush time (master...peak_compensation) https://github.com/bitcoin/bitcoin/pull/10126
276 2017-03-30T19:08:29  <gmaxwell> Yes, please.
277 2017-03-30T19:08:33  <jeremyrubin> topic: slow tests?
278 2017-03-30T19:08:37  <wumpus> #topic 0.14.1
279 2017-03-30T19:09:02  <achow101> already?
280 2017-03-30T19:09:25  <gmaxwell> yes. lots of nice fixes to ship. Minor releases are minor.
281 2017-03-30T19:09:39  <sipa> we have 11 merged PRs marked 0.14.1
282 2017-03-30T19:09:59  <wumpus> and three open pulls https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.14.1
283 2017-03-30T19:10:32  <wumpus> sipa: only one still has the "needs backport" tag, I think MarcoFalke ported the rest
284 2017-03-30T19:10:44  <gmaxwell> I think when we get those three in and those and the recent ones backported, we should be goof for a 0.14.1.
285 2017-03-30T19:11:11  <gmaxwell> good too.
286 2017-03-30T19:11:41  <wumpus> agreed
287 2017-03-30T19:12:45  <wumpus> ok, next topic I guess
288 2017-03-30T19:12:48  <wumpus> #topic slow tests
289 2017-03-30T19:13:11  <wumpus> I made an overview here: https://github.com/bitcoin/bitcoin/issues/10026  of the slowest unit tests
290 2017-03-30T19:13:15  <jeremyrubin> A lot of it is my fault it seems. https://github.com/bitcoin/bitcoin/pull/10099 is ready to go
291 2017-03-30T19:13:27  <wumpus> some of those have already been worked on or even PRs open to make them faster
292 2017-03-30T19:13:36  <gmaxwell> jnewbery: if you're around, if 10106 doesn't move forward in a few hours, I recommend you create a new pr, cherry picking that one fix, with your new tests and the fix for the other function.  (just because the PR wasn't opened by a regular so they may not be responsive or may not know how to use github well enough to pull your changes.)
293 2017-03-30T19:14:12  <jnewbery> gmaxwell: I'll do that this afternoon
294 2017-03-30T19:14:22  *** MarcoFalke_lab has joined #bitcoin-core-dev
295 2017-03-30T19:14:43  <wumpus> yes, tend to agree, they may not know how to cherry-pick them. I could cherry-pick them into his branch but meh
296 2017-03-30T19:14:53  <MarcoFalke_lab> wumpus: Yes, dropping GetRand() gave a 4* speedup.
297 2017-03-30T19:15:02  <gmaxwell> jnewbery: and thanks for the awesome response.
298 2017-03-30T19:15:08  <jnewbery> np
299 2017-03-30T19:15:37  <wumpus> MarcoFalke_lab: that'll at least move it down a bit in the top 20
300 2017-03-30T19:15:42  <jeremyrubin> The cuckoocache tests require a bit more discussion to decrease the parameters; I can pick something arbitrary
301 2017-03-30T19:16:27  <jeremyrubin> The checkqueue tests should also speed up a lot with #9938, but I'm preparing some tweaks to those
302 2017-03-30T19:16:28  <gribble> https://github.com/bitcoin/bitcoin/issues/9938 | Lock-Free CheckQueue by JeremyRubin · Pull Request #9938 · bitcoin/bitcoin · GitHub
303 2017-03-30T19:16:46  <Chris_Stewart_5> re tests: Has anyone given any thought to #8469 , obviously this pull request sacrafices speed for exhaustiveness
304 2017-03-30T19:16:48  <gribble> https://github.com/bitcoin/bitcoin/issues/8469 | [POC] Introducing property based testing to Core by Christewart · Pull Request #8469 · bitcoin/bitcoin · GitHub
305 2017-03-30T19:17:02  <jeremyrubin> If anyone has high-core machines, they should try benching how that works
306 2017-03-30T19:17:02  <wumpus> jeremyrubin: alternatively we could have an -extended mode for the unit tests, like we have for the functional tests, to do extra-thorough tests that shouldn't run every time
307 2017-03-30T19:17:13  <MarcoFalke_lab> jeremyrubin: If the parameters matter, you could provide a switch to test against quick_run and an expensive one
308 2017-03-30T19:17:20  <wumpus> yes ^^
309 2017-03-30T19:17:27  <gmaxwell> I think we should have an extended test, and make running it part of the release process.
310 2017-03-30T19:17:42  <jeremyrubin> Agree
311 2017-03-30T19:17:45  <wumpus> but for the standard 'make check' there should be a guideline of max ~1 second per test case
312 2017-03-30T19:17:59  <MarcoFalke_lab> Everyone agrees! :)
313 2017-03-30T19:18:07  <gmaxwell> I don't care if the tests take an hour to run if it's only a mandatory once in release thing.
314 2017-03-30T19:18:09  <cfields> sgtm
315 2017-03-30T19:18:11  <jeremyrubin> no, 2 seconds!
316 2017-03-30T19:18:18  <wumpus> gmaxwell: yes or once per day or so on master
317 2017-03-30T19:18:35  <jonasschnelli> (which is failing currently)
318 2017-03-30T19:18:49  <gmaxwell> jonasschnelli: what is failing?
319 2017-03-30T19:18:49  <wumpus> yes, travis is broken again, but there's a pull to fix that
320 2017-03-30T19:18:52  <cfields> note to self: gitian should run whatever extended tests it can
321 2017-03-30T19:18:55  <gmaxwell> oh travis
322 2017-03-30T19:18:58  <jonasschnelli> gmaxwell: https://travis-ci.org/bitcoin/bitcoin/builds
323 2017-03-30T19:19:13  <MarcoFalke_lab> Jup, will merge the travis fix tonight when I have access to my keys. (If no one beats me to it)
324 2017-03-30T19:19:31  <wumpus> does anyone have the # perhaps?
325 2017-03-30T19:19:58  <sdaftuar> i think #10114?
326 2017-03-30T19:19:59  <MarcoFalke_lab> Though, we should be cautious with putting too much into the cron jobs. The extended test rely on the cache being up to date
327 2017-03-30T19:19:59  <gribble> https://github.com/bitcoin/bitcoin/issues/10114 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
328 2017-03-30T19:20:10  <MarcoFalke_lab> Otherwise they would break the 49 minute limit on traivs
329 2017-03-30T19:20:11  <wumpus> there's also #10072
330 2017-03-30T19:20:12  <gribble> https://github.com/bitcoin/bitcoin/issues/10072 | Remove sources of unreliablility in extended functional tests by jnewbery · Pull Request #10072 · bitcoin/bitcoin · GitHub
331 2017-03-30T19:20:39  <wumpus> but yes 114 was the one I meant
332 2017-03-30T19:20:40  <gmaxwell> We should probably contemplate having some seperate process against master that does continual gitian builds or something.
333 2017-03-30T19:21:10  <MarcoFalke_lab> jonasschnelli: Is doing that, gmaxwell
334 2017-03-30T19:21:22  <gmaxwell> oh good.
335 2017-03-30T19:21:25  <gmaxwell> ignore me.
336 2017-03-30T19:21:29  <jonasschnelli> gmaxwell: https://bitcoin.jonasschnelli.ch
337 2017-03-30T19:21:32  <wumpus> yes, jonasschnelli has a build server with a very nice web UI
338 2017-03-30T19:21:43  <MarcoFalke_lab> jonasschnelli: Are you running the tests?
339 2017-03-30T19:21:44  <jonasschnelli> (it's currently by manual trigger)
340 2017-03-30T19:21:50  <jonasschnelli> no.. just gitian
341 2017-03-30T19:21:55  <gmaxwell> somehow I missed this. cool.
342 2017-03-30T19:22:08  <wumpus> travis already runs the tests, this is to get executables for testing
343 2017-03-30T19:23:31  <jnewbery> travis is only broken now because we've set it to run the extended tests once per day, so we're currently flushing out all the extended tests that have always failed on travis. I think once #10114 and #10072 are merged the daily runs should succeed reliably
344 2017-03-30T19:23:32  <gribble> https://github.com/bitcoin/bitcoin/issues/10114 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
345 2017-03-30T19:23:33  <gribble> https://github.com/bitcoin/bitcoin/issues/10072 | Remove sources of unreliablility in extended functional tests by jnewbery · Pull Request #10072 · bitcoin/bitcoin · GitHub
346 2017-03-30T19:24:08  <jonasschnelli> thanks jnewbery for the info (and the fixes)
347 2017-03-30T19:24:10  *** PaulCapestany has quit IRC
348 2017-03-30T19:25:56  <bitcoin-git> [bitcoin] sdaftuar opened pull request #10127: [0.14 backport] Mining: Prevent slowdown in CreateNewBlock on large mempools  (0.14...2017-03-backport-cnb-optimizations) https://github.com/bitcoin/bitcoin/pull/10127
349 2017-03-30T19:26:48  <wumpus> ok, any other topics?
350 2017-03-30T19:27:41  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/cde9b1a864c1...edc62c959ab3
351 2017-03-30T19:27:42  <bitcoin-git> bitcoin/master 6426716 John Newbery: Add send_await_disconnect() method to p2p-compactblocks.py...
352 2017-03-30T19:27:42  <bitcoin-git> bitcoin/master 6a18bb9 John Newbery: [tests] sync_with_ping should assert that ping hasn't timed out...
353 2017-03-30T19:27:43  <bitcoin-git> bitcoin/master edc62c9 Wladimir J. van der Laan: Merge #10114: [tests] sync_with_ping should assert that ping hasn't timed out...
354 2017-03-30T19:27:49  <gmaxwell> I should make notes for topics...
355 2017-03-30T19:27:57  <BlueMatt> oh, new prs
356 2017-03-30T19:28:02  <BlueMatt> for review priority
357 2017-03-30T19:28:12  <BlueMatt> looks like jonasschnelli already added his
358 2017-03-30T19:28:16  <bitcoin-git> [bitcoin] laanwj closed pull request #10114: [tests] sync_with_ping should assert that ping hasn't timed out (master...improve_sync_with_ping) https://github.com/bitcoin/bitcoin/pull/10114
359 2017-03-30T19:28:21  <BlueMatt> anyone else have something to add (aside from 0.14.1-tagged things)
360 2017-03-30T19:28:22  <wumpus> fine with me, but don't forget the current bunch :p
361 2017-03-30T19:28:32  <wumpus> yes please review 0.14.1 tagged things
362 2017-03-30T19:28:35  <wumpus> although those should be easy
363 2017-03-30T19:28:36  <jonasschnelli> BlueMatt: Yes. The bumpfee refactor (to get a QT fee bump function)
364 2017-03-30T19:28:53  <sipa> 0.14.1 has priority, but i'd like to see #9792 in at some point to further the get-rid-of-openssl thing :)
365 2017-03-30T19:29:01  <BlueMatt> wumpus: there is a "For backport" column there...
366 2017-03-30T19:29:02  <gribble> https://github.com/bitcoin/bitcoin/issues/9792 | FastRandomContext improvements and switch to ChaCha20 by sipa · Pull Request #9792 · bitcoin/bitcoin · GitHub
367 2017-03-30T19:29:08  <wumpus> but I think we should be able to do 0.14.1 tomorrow so to have something to review for the rest of the week :D
368 2017-03-30T19:29:22  <wumpus> BlueMatt: yes good point
369 2017-03-30T19:29:53  <BlueMatt> ok, so morcos and sdaftuar get to propose new ones since they dont have ones up, anyone else want to propose ones?
370 2017-03-30T19:29:55  <gmaxwell> oh someone opened a PR to do something with debug log excludes, and it adds more insane string processing in the debugging critical path. Would anyone mind if I brought back the PR I shelved to make debug categories use an enum?
371 2017-03-30T19:30:17  <BlueMatt> gmaxwell: wfm, the pr was jnewbery's
372 2017-03-30T19:30:20  <sipa> gmaxwell: ack enum debug categories
373 2017-03-30T19:30:40  <wumpus> gmaxwell: not sure
374 2017-03-30T19:30:43  <jnewbery> #10123
375 2017-03-30T19:30:44  <gribble> https://github.com/bitcoin/bitcoin/issues/10123 | Allow debug logs to be excluded from specified component by jnewbery · Pull Request #10123 · bitcoin/bitcoin · GitHub
376 2017-03-30T19:30:48  <gmaxwell> (the PR was just shelved because I opened it right before a release, and it is a conflict-the-universe PR)
377 2017-03-30T19:30:57  *** JackH has joined #bitcoin-core-dev
378 2017-03-30T19:30:59  <wumpus> gmaxwell: well no I guess it makes sense
379 2017-03-30T19:31:00  <BlueMatt> gmaxwell: go for it now, I'd say
380 2017-03-30T19:31:05  <wumpus> yes, do it
381 2017-03-30T19:31:07  <sdaftuar> i'd like to get this DisconnectTip improvement wrapped up (#9208) but i need some help on resolving this annoying issue BlueMatt raised
382 2017-03-30T19:31:08  <gribble> https://github.com/bitcoin/bitcoin/issues/9208 | Improve DisconnectTip performance by sdaftuar · Pull Request #9208 · bitcoin/bitcoin · GitHub
383 2017-03-30T19:31:08  <cfields> gmaxwell: +1.
384 2017-03-30T19:31:14  <jonasschnelli> Yes. ACK
385 2017-03-30T19:31:23  <cfields> along the same lines, I'd like to do something similar for net messages
386 2017-03-30T19:31:23  <wumpus> then you can also map the enum values to strings and automate the help message generation
387 2017-03-30T19:31:26  <gmaxwell> #9424
388 2017-03-30T19:31:27  <gribble> https://github.com/bitcoin/bitcoin/issues/9424 | Change LogAcceptCategory to use uint32_t rather than sets of strings. by gmaxwell · Pull Request #9424 · bitcoin/bitcoin · GitHub
389 2017-03-30T19:31:30  <BlueMatt> sdaftuar: want to bring it up now/
390 2017-03-30T19:31:38  <jnewbery> gmaxwell: +1. I'll happily review that one
391 2017-03-30T19:31:38  <BlueMatt> ?
392 2017-03-30T19:31:48  <wumpus> cfields: yes, should be fairly easy to do, I already changed the syntax for net messages to be enum-like at some point
393 2017-03-30T19:31:49  <jtimon> since #8855 didn't got new review nor re-review I think just leave that (just remind to potential reviewers that #8994 continues it, in case you "don't see the point")
394 2017-03-30T19:31:51  <gribble> https://github.com/bitcoin/bitcoin/issues/8855 | Use a proper factory for creating chainparams by jtimon · Pull Request #8855 · bitcoin/bitcoin · GitHub
395 2017-03-30T19:31:51  <gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
396 2017-03-30T19:32:15  <wumpus> cfields: went as far as I could without making it an actual enum :)
397 2017-03-30T19:32:17  <gmaxwell> cfields: I looked at adding a perfect hash for net messages... but didn't know if that would be a way you'd want to go. :)
398 2017-03-30T19:32:29  <BlueMatt> new for review this week is 9792 and 9208
399 2017-03-30T19:32:35  <cfields> wumpus: yes, it sure looks like an enum :)
400 2017-03-30T19:32:37  <sipa> gmaxwell: just make sure all debug category names have different length
401 2017-03-30T19:33:12  <gmaxwell> sipa: well we don't need to do any runtime lookup of category names at all.. so no need to do anything performant there.
402 2017-03-30T19:33:27  <wumpus> at least give them consecutive values so a bit field can be used to represent the set
403 2017-03-30T19:33:33  <wumpus> intead of a per-thread map :-(
404 2017-03-30T19:33:40  <cfields> gmaxwell: i had considered making it an array<char, 12>. But I really don't care, as long as it's switchable and a compile-time constant
405 2017-03-30T19:33:41  <gmaxwell> wumpus: that is what PR 9424 does.
406 2017-03-30T19:33:52  <wumpus> gmaxwell: ok, great
407 2017-03-30T19:33:53  <gmaxwell> wumpus: it assigns them each to a bit.
408 2017-03-30T19:34:22  <wumpus> the current code that assigns it a thread-local variable is really strange
409 2017-03-30T19:34:27  *** PaulCapestany has joined #bitcoin-core-dev
410 2017-03-30T19:34:27  <bitcoin-git> [bitcoin] JeremyRubin opened pull request #10128: Speed Up CuckooCache tests (master...cuckoo-tests-faster) https://github.com/bitcoin/bitcoin/pull/10128
411 2017-03-30T19:34:30  <cfields> (and now that I think about it, std::array probably isn't switchable anyway)
412 2017-03-30T19:34:39  <gmaxwell> yes. horrors from beyond time.
413 2017-03-30T19:34:54  <sdaftuar> topic suggestion: dealing with abortnode / ConnectTip / DisconnectTip failures
414 2017-03-30T19:35:05  <gmaxwell> in any case, if people support-- 9424 is hard to rebase because it touches the whole codebase.
415 2017-03-30T19:35:30  <wumpus> cfields: in some modern languages it's possible to switch on compound types and arrays and strings, but no, not c++XX before XX=50 or so :)
416 2017-03-30T19:35:33  <gmaxwell> but I think it also makes jnewbery's exclude trivial. (in fact: no runtime impact...)
417 2017-03-30T19:35:50  <wumpus> gmaxwell: yes, it's how it should be done
418 2017-03-30T19:36:09  <sipa> in haskell it's pretty much the only way you can inspect a compound type at all :p
419 2017-03-30T19:36:14  <jnewbery> gmaxwell: agree
420 2017-03-30T19:36:22  <wumpus> sipa: indeed
421 2017-03-30T19:36:41  <sipa> ok, sdaftuar's topic?
422 2017-03-30T19:36:46  <gmaxwell> cfields: my intution for that would be using gperf to map the messages to integers. then switching on them... but perhaps overkill.
423 2017-03-30T19:36:53  <wumpus> #topic dealing with abortnode / ConnectTip / DisconnectTip failures
424 2017-03-30T19:37:05  <BlueMatt> context: #9208
425 2017-03-30T19:37:06  <gribble> https://github.com/bitcoin/bitcoin/issues/9208 | Improve DisconnectTip performance by sdaftuar · Pull Request #9208 · bitcoin/bitcoin · GitHub
426 2017-03-30T19:37:09  <sipa> sdaftuar: i saw i was pinged in the PR, but haven't read it
427 2017-03-30T19:37:13  <sdaftuar> so this issue might be hard to grasp without reviewing #9208
428 2017-03-30T19:37:15  <gribble> https://github.com/bitcoin/bitcoin/issues/9208 | Improve DisconnectTip performance by sdaftuar · Pull Request #9208 · bitcoin/bitcoin · GitHub
429 2017-03-30T19:37:29  <wumpus> gmaxwell: will that work for unknown messages too?
430 2017-03-30T19:37:40  <sdaftuar> but basically matt brought up that we have some edge cases in our code if ConnectTip or DisconnectTip return false
431 2017-03-30T19:37:54  <wumpus> gmaxwell: does a perfect hash handle collisions? I don't remember
432 2017-03-30T19:38:07  <cfields> wumpus: perfect hash means no collisions :)
433 2017-03-30T19:38:13  <wumpus> cfields: for known values
434 2017-03-30T19:38:34  <jeremyrubin> wouldn't that not be backwards compatible?
435 2017-03-30T19:38:36  <gmaxwell> wumpus: gperf can check, it's an option.
436 2017-03-30T19:38:44  <wumpus> cfields: but what if 'moo' maps to the same 32-bit value as 'block'
437 2017-03-30T19:38:50  <jeremyrubin> someone sends you a new type of message that hashes to something else
438 2017-03-30T19:39:05  <wumpus> scary
439 2017-03-30T19:39:06  <sipa> sdaftuar: hmm, i'll review the PR
440 2017-03-30T19:39:10  <sdaftuar> the last issue i'm trying to resolve is if ConnectTip fails (but the block is not invalid), then we should be in an AbortNode() state.  what consistency are we aiming for in this situation?
441 2017-03-30T19:39:14  <cfields> wumpus: ah, true
442 2017-03-30T19:39:16  <gmaxwell> wumpus: making it never have collisions for unknows is just an extra comparison with the correct value.
443 2017-03-30T19:39:35  <gmaxwell> wumpus: which IIRC the gperf emitted code will do, if enabled.
444 2017-03-30T19:39:47  <gmaxwell> (actually, looks like it's the default)
445 2017-03-30T19:39:47  <BlueMatt> lol, ok, so lets pick a topic instead of two
446 2017-03-30T19:39:55  *** PaulCapestany has quit IRC
447 2017-03-30T19:40:16  <gmaxwell> sdaftuar: we should be able to shut down and come back up with the underlying issue resolved and continue.
448 2017-03-30T19:40:26  <wumpus> yes, sorry, I was just curous about gperf
449 2017-03-30T19:40:30  <gmaxwell> sdaftuar: I don't care if we lose a bunch of recent blocks.
450 2017-03-30T19:40:32  <sipa> sdaftuar: it's fine if we lose progress in that case, but if at all avoidable, the on disk state should not be corrupted
451 2017-03-30T19:40:44  <BlueMatt> anyway, so I further observed that shutdown upon AbortNode can take up to 200ms (see recent PR), which is somewhat frightening, given that mempool and chainstate may not be consistent which we assume in many places :/
452 2017-03-30T19:40:46  <sdaftuar> gmaxwell: sipa: what should we do with the mempool?
453 2017-03-30T19:41:03  <sipa> sdaftuar: who cares?
454 2017-03-30T19:41:08  <BlueMatt> so we keep running for a while normally and possibly have incorrect assumptions
455 2017-03-30T19:41:11  <gmaxwell> I don't care.
456 2017-03-30T19:41:16  <wumpus> just drop it
457 2017-03-30T19:41:29  <sipa> sdaftuar: at restart we'll try to reimport what is on disk
458 2017-03-30T19:41:36  <sipa> and re-run all necessary consistency checks
459 2017-03-30T19:41:51  <sipa> so mempool.dat doesn't need to be consistent with the chainstate
460 2017-03-30T19:41:59  <BlueMatt> and wallet?
461 2017-03-30T19:42:01  <sdaftuar> i think the concern matt was raising was if before shutdown, it's possible for eg an RPC call to get incorrect results
462 2017-03-30T19:42:04  <sdaftuar> or the wallet
463 2017-03-30T19:42:08  <wumpus> yes, no tight coupling, good design
464 2017-03-30T19:42:19  <BlueMatt> wumpus: point is we *have* tight coupling
465 2017-03-30T19:42:22  <wumpus> wallet doesn't need to be in sync either, though it should not be ahead
466 2017-03-30T19:42:24  <sipa> sdaftuar: ugh
467 2017-03-30T19:42:28  <BlueMatt> and continue running after realizing something is corrupted
468 2017-03-30T19:42:35  <gmaxwell> well abortnode should be instant-ish.
469 2017-03-30T19:42:36  *** molz_ has joined #bitcoin-core-dev
470 2017-03-30T19:42:42  <gmaxwell> BlueMatt: so you're fixing that, what is there to discuss?
471 2017-03-30T19:42:46  <wumpus> a bit behind (as long as it's not further than the prune distance) is ok, it will catch up in next start
472 2017-03-30T19:42:49  <BlueMatt> gmaxwell: i mean the new pr is an improvement, but its not a fix
473 2017-03-30T19:43:02  <BlueMatt> its not like you cant have something pending cs_main when coming out of Disconnect/ConnectTip
474 2017-03-30T19:43:06  <wumpus> but if the wallet is ahead of the chain it will trigger a rescan IIRC
475 2017-03-30T19:43:10  <gmaxwell> so perhaps abortnode needs to Abort()?
476 2017-03-30T19:43:18  <BlueMatt> gmaxwell: thats pretty much the question
477 2017-03-30T19:43:21  <BlueMatt> thats super shit, though, of course
478 2017-03-30T19:43:24  <gmaxwell> and not faffabout witht politely shutting off threads.
479 2017-03-30T19:43:24  <wumpus> I don't think so
480 2017-03-30T19:43:39  <sdaftuar> i inadvertently introduced an assert failure in one of these situations.  maybe that's a feature not a flaw! :)
481 2017-03-30T19:43:44  <gmaxwell> Why is it shit? we should be durable across a power off, which is worse than aborting.
482 2017-03-30T19:43:45  <wumpus> the point of abortnode is to be able to show a GUI dialog to the user
483 2017-03-30T19:43:55  <gmaxwell> ah
484 2017-03-30T19:43:57  <wumpus> if you abort() the user will never know to check the debug.log
485 2017-03-30T19:44:07  <BlueMatt> wumpus: well we can show a gui dialog and abort() prior to unlocking cs_main
486 2017-03-30T19:44:09  <BlueMatt> :P
487 2017-03-30T19:44:15  <jeremyrubin> have a graceful shutdown falg
488 2017-03-30T19:44:19  <jeremyrubin> *flag
489 2017-03-30T19:44:24  <gmaxwell> wumpus: but it's not unlikely that we can't show a gui... if we can't allocate (likely cause).
490 2017-03-30T19:44:27  <BlueMatt> which would effectively be sufficient
491 2017-03-30T19:44:29  <wumpus> I always thought that AbortNode was for errors that could tolerate a graceful shutdown
492 2017-03-30T19:44:35  <wumpus> the really terrible errors we already assert() or abort() on
493 2017-03-30T19:44:36  <jeremyrubin> and if we're shutting down gracefully, write to a file "was graceful"
494 2017-03-30T19:44:41  <BlueMatt> gmaxwell: AbortNode() is usually disk corruption
495 2017-03-30T19:44:45  <jeremyrubin> On next start, show dialogue first thing?
496 2017-03-30T19:44:46  <wumpus> please don't make it routine to abort() for everything
497 2017-03-30T19:44:53  <wumpus> only for things that really warrant it
498 2017-03-30T19:45:00  <wumpus> not crash on every single error
499 2017-03-30T19:45:02  <BlueMatt> or too little disk space
500 2017-03-30T19:45:02  <sdaftuar> or too little disk space, not quite teh same as corruption
501 2017-03-30T19:45:03  <wumpus> that's just a mess
502 2017-03-30T19:45:13  *** PaulCapestany has joined #bitcoin-core-dev
503 2017-03-30T19:45:21  <gmaxwell> okay, sure.
504 2017-03-30T19:45:24  <wumpus> for some problems it's fine to try to clean up normally
505 2017-03-30T19:45:31  <wumpus> but we still need to exit with a message
506 2017-03-30T19:45:34  <wumpus> that's what abortnode is for
507 2017-03-30T19:45:50  *** mol has quit IRC
508 2017-03-30T19:45:56  <wumpus> if BlueMatt can make it work faster that's great, but don't silently kill the program on every error
509 2017-03-30T19:46:08  *** CubicEarthh has quit IRC
510 2017-03-30T19:46:18  <gmaxwell> wumpus: how about every other error?
511 2017-03-30T19:46:26  <gmaxwell> :P
512 2017-03-30T19:46:33  <wumpus> gmaxwell: hehe
513 2017-03-30T19:46:59  <sipa> do #9208 and #9725 interact?
514 2017-03-30T19:47:01  <gribble> https://github.com/bitcoin/bitcoin/issues/9208 | Improve DisconnectTip performance by sdaftuar · Pull Request #9208 · bitcoin/bitcoin · GitHub
515 2017-03-30T19:47:03  <gribble> https://github.com/bitcoin/bitcoin/issues/9725 | CValidationInterface Cleanups by TheBlueMatt · Pull Request #9725 · bitcoin/bitcoin · GitHub
516 2017-03-30T19:47:07  <gmaxwell> Y'all so worried about the dressings on the coffin.  "It's already dead!"  But sure. Sorry I was only thinking of OOM, it's just a recent subject.
517 2017-03-30T19:47:19  <BlueMatt> sipa: they dont, afaik, aside from there now being two structs that can be merged
518 2017-03-30T19:47:22  <jeremyrubin> I think deleting a file on graceful shutdown should work
519 2017-03-30T19:47:42  <jeremyrubin> And then starting when that file is present shows the dialouge rather than starting
520 2017-03-30T19:47:46  <BlueMatt> gmaxwell: yea, AbortNode isnt used for thigns like OOM and total death
521 2017-03-30T19:47:49  <BlueMatt> disk space also does it
522 2017-03-30T19:47:55  <BlueMatt> but it can also be db corruption
523 2017-03-30T19:48:13  <jeremyrubin> This means you don't do anything at all on the Abort, but requires the user to restart their node to see the message
524 2017-03-30T19:48:15  <BlueMatt> so maybe the solution is AbortNode gets renamed to ShutdownSoon() and use make sure disk corruption is something different?
525 2017-03-30T19:48:31  <wumpus> BlueMatt: yes, makes sense to me
526 2017-03-30T19:48:33  <wumpus> BlueMatt: or add a flag
527 2017-03-30T19:48:38  <morcos> I haven't really thought this all the way through, but doesn't it seem that as we move more and more towards things happening in other threads, that you'd rather let those threads finish what they are doing
528 2017-03-30T19:48:45  <gmaxwell> BlueMatt: you could also harden things up against your current concer by having the rpc stuff always check the shutdown flag right after taking cs_main (whenever it does)?
529 2017-03-30T19:48:47  <morcos> If you're committing wallet changes for instance
530 2017-03-30T19:48:59  <gmaxwell> BlueMatt: and if it finds out that its on its way down, just returning at that point.
531 2017-03-30T19:49:06  <wumpus> in the long run morcos we should move toward looser coupling of things
532 2017-03-30T19:49:09  <wumpus> I agree
533 2017-03-30T19:49:13  <BlueMatt> gmaxwell: yea, I'm worried that if we start down that path we have to check it everywhere
534 2017-03-30T19:49:22  <BlueMatt> eg wallet may make decisions based on some corrupted mempool state
535 2017-03-30T19:49:27  <morcos> Let's say you just got some new address from the wallet, and the wallet hasn't committed that state yet and then you Abort()
536 2017-03-30T19:49:31  <BlueMatt> (I havent thought all the way through all the potential issues here, just a potential concern)
537 2017-03-30T19:50:19  <wumpus> morcos: luckily we have the keypool to handle that specific contingency
538 2017-03-30T19:50:24  <jeremyrubin> Every thread could have their own unique ungraceful-close file that it should delete (via RAII) on clean exit. Starting with any present would show error. Uncoupled!
539 2017-03-30T19:50:40  <gmaxwell> morcos: well at least the worst you get there is replay (due to keypool/hdwallets).. though replay can be pretty bad.
540 2017-03-30T19:51:11  <wumpus> pretty bad but well at least they will never lose live keys
541 2017-03-30T19:51:47  <BlueMatt> jeremyrubin: I have a feeling we can be more agressive on the super-strange issues, afaiu this stuff is pretty much hit just with out-of-disk everything else is rare enough.....
542 2017-03-30T19:52:36  <sipa> maybe we should just have some std::atomic<bool> shits_on_fire_yo; which when set prevents RPCs etc
543 2017-03-30T19:52:46  <wumpus> jeremyrubin: that's not what I mean with uncoupling, what I mean is that if one thread messes up it doesn't need to take the others with it because it can operate more-or-less independently
544 2017-03-30T19:52:58  <gmaxwell> sipa: well shutdown can be more or less that.
545 2017-03-30T19:53:14  <sipa> that can even be set from a signal handler
546 2017-03-30T19:53:34  <BlueMatt> <BlueMatt> so maybe the solution is AbortNode gets renamed to ShutdownSoon() and use make sure disk corruption is something different?
547 2017-03-30T19:53:53  <jeremyrubin> sipa: what do you do with an in progress RPC?
548 2017-03-30T19:54:04  <BlueMatt> in ShutdownSoon cases (eg out of disk) we're ok to continue and just shut down, i think
549 2017-03-30T19:54:08  <sipa> jeremyrubin: we can only do so much
550 2017-03-30T19:54:08  <wumpus> you can't generally break off an in-progress RPC
551 2017-03-30T19:54:11  <BlueMatt> in other cases, we can just assert(false)
552 2017-03-30T19:54:13  <wumpus> although some will pay attention to fShutdown
553 2017-03-30T19:54:15  <BlueMatt> because they're super rare anyway
554 2017-03-30T19:54:21  <jeremyrubin> wumpus: ^ yes, O
555 2017-03-30T19:54:21  <gmaxwell> but really, what probably should be done is having the rpcs being able to handle being told "No, you can't have access to [whatever chain state you wanted] right now."  then these error conditions that could leave them unstable... could set them.
556 2017-03-30T19:54:26  <BlueMatt> and if your disk is corrupted we probably shouldnt be flushing wallet and chainstate as a part of shutdown anyway
557 2017-03-30T19:54:47  <BlueMatt> gmaxwell: yea, but thats a huge rewrite for cases that should be super rare
558 2017-03-30T19:55:11  <gmaxwell> Or we take a whole different approach to failure messages, .e.g. wrap bitcoin-qt in another program that when qt exists it can go through the logs and give you a useful error. (though this doesn't answer morcos' wallet flush, but really that should be in another process.)
559 2017-03-30T19:55:26  <wumpus> BlueMatt: I think there should be a clear separation between (A) I/O issues such as out of disk spae, which just happen regularly (B) rare implementation issues such as internal consistency errors
560 2017-03-30T19:55:27  <cfields> iirc rpc has a IsRPCShuttingDown() or so, but only a few things (gbt only, maybe?) checks it
561 2017-03-30T19:55:28  <jeremyrubin> wumpus: * yes, I'm aware that isn't quite what you meant, just making noise about having a graceful shutdown file because I think it's a reasonable way to mark if a node shut down dirty
562 2017-03-30T19:55:44  <wumpus> (A) normal errors should just give the user an error as AbortNode does now and shut down properly
563 2017-03-30T19:56:02  <wumpus> (B) internal state corruption errors could break off the process immediately
564 2017-03-30T19:56:02  <gmaxwell> It's obnoxious that we can't preallocate resources such that we can guarentee that we never take a failure at an inoppturtune time.
565 2017-03-30T19:56:14  <gmaxwell> having to slather the code in error handling to deal with that is not ideal.
566 2017-03-30T19:56:41  <jeremyrubin> gmaxwell: you can preallocate lots of things?
567 2017-03-30T19:56:44  <gmaxwell> wumpus: "I had to abort processing a block" is a weak kind of internal state corruption. It leaves assumed invariants violated.
568 2017-03-30T19:56:57  <gmaxwell> jeremyrubin: in particular we can't make leveldb's disk usage constant.
569 2017-03-30T19:56:58  <BlueMatt> wumpus: yes, thats my proposal
570 2017-03-30T19:57:12  <BlueMatt> wumpus: but, specifically, B would include things like chainstate-on-disk-corruption
571 2017-03-30T19:57:17  <BlueMatt> which it already partially does, just not completely
572 2017-03-30T19:57:26  <wumpus> having code to handle normal errors is perfectly normal and all code has that, I agree that paranoid memory/disk corruption errors tend not to be possible to handle in a sane way
573 2017-03-30T19:57:33  <wumpus> BlueMatt: yes
574 2017-03-30T19:57:48  <BlueMatt> ok, soooo, acks on:<BlueMatt> <BlueMatt> so maybe the solution is AbortNode gets renamed to ShutdownSoon() and use make sure disk corruption is something different?
575 2017-03-30T19:58:07  <wumpus> BlueMatt: as I said beforer, yes, that or add a flag/criticality level
576 2017-03-30T19:58:11  <BlueMatt> s/use make sure/make sure/
577 2017-03-30T19:58:15  <jeremyrubin> BlueMatt: maybe if you paste it again
578 2017-03-30T19:58:15  <BlueMatt> sure, that too
579 2017-03-30T19:58:23  <BlueMatt> jeremyrubin: ok, <BlueMatt> ok, soooo, acks on:<BlueMatt> <BlueMatt> so maybe the solution is AbortNode gets renamed to ShutdownSoon() and use make sure disk corruption is something different?
580 2017-03-30T19:58:39  <gmaxwell> wumpus: for example, if we run out of space while flushing our view of the blockchain will be corrupt, and information about the blockchain from rpcs will be wrong.  In a world where error handling is free, every code path that gets access to the blockchain data would be able to gracefully handle being told it's just not available.  But I think that would be an unreasonable and dangerous amount
581 2017-03-30T19:58:45  <gmaxwell> of complexity. :(
582 2017-03-30T19:58:50  <BlueMatt> wumpus: I missed that statement, but, yes
583 2017-03-30T19:59:00  <gmaxwell> BlueMatt: that sounds okay to me. but I don't know that diskfull is really a shutdown soon though we really do need to give it a nice message. :(
584 2017-03-30T19:59:03  <wumpus> gmaxwell: note that the out-of-disk error happens *before* the disk is entirely full
585 2017-03-30T19:59:04  <jeremyrubin> BlueMatt: sgtm
586 2017-03-30T19:59:12  <wumpus> gmaxwell: there's a threshold
587 2017-03-30T19:59:22  <wumpus> gmaxwell: so that should already be mitigated
588 2017-03-30T19:59:26  <gmaxwell> wumpus: yes, but it's not atomic. you can't check and then successfully allocate space.
589 2017-03-30T19:59:38  <wumpus> no, it's not perfect, but it works pretty well
590 2017-03-30T19:59:43  <wumpus> I've never had corruption on full disk
591 2017-03-30T20:00:33  <wumpus> also leveldb write failing shouldn't generally be fatal
592 2017-03-30T20:00:39  <gmaxwell> on my desktop, which runs with debug=1 it almost always gets checked at the start of the flush. It doesn't corrupt things on disk, but as matt points out the rpc would return somewhat incorrect results during that time.
593 2017-03-30T20:00:39  <wumpus> it just means the last transaction is not committed
594 2017-03-30T20:01:00  <jtimon> it seems it's time to abort the meeting
595 2017-03-30T20:01:06  <wumpus> #endmeeting
596 2017-03-30T20:01:06  <lightningbot> Meeting ended Thu Mar 30 20:01:06 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
597 2017-03-30T20:01:06  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-30-19.01.html
598 2017-03-30T20:01:06  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-30-19.01.txt
599 2017-03-30T20:01:06  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-30-19.01.log.html
600 2017-03-30T20:01:17  <BlueMatt> wumpus: we need to change that to #abort()
601 2017-03-30T20:01:20  <gmaxwell> But I wanted to cleanly flush!
602 2017-03-30T20:02:01  <bitcoin-git> [bitcoin] theuni opened pull request #10129: scheduler: fix sub-second precision with boost < 1.50 (master...fix-scheduler-millisecs) https://github.com/bitcoin/bitcoin/pull/10129
603 2017-03-30T20:02:26  <cfields> BlueMatt: ^^ fixes the ramped-up cpu issue
604 2017-03-30T20:03:00  <wumpus> cfields: 10129 needs backport I suppose?
605 2017-03-30T20:03:01  <BlueMatt> cfields: ahh, lol, I dont have old boost
606 2017-03-30T20:03:12  <BlueMatt> wumpus: only if we also backport the wallet-flush-in-cscheduler, probably?
607 2017-03-30T20:03:18  <BlueMatt> (which i think we should, but....)
608 2017-03-30T20:03:26  <BlueMatt> questionable given boost issues
609 2017-03-30T20:03:28  <wumpus> eh no, let's not do that, sorry
610 2017-03-30T20:03:31  <cfields> wumpus: won't hurt, but doesn't currently matter
611 2017-03-30T20:04:09  <BlueMatt> wumpus: fair, yea
612 2017-03-30T20:04:12  <cfields> wumpus: probably best to go ahead and backport, just in case any other stuff is backported in the future that relies on the correct behavior
613 2017-03-30T20:04:26  <BlueMatt> yea, i mean if it turns out there are complications and its not dead simple, not backporting seems like the best idea
614 2017-03-30T20:04:34  <gmaxwell> wallet-flush-in-cscheduler removes a thread?
615 2017-03-30T20:04:38  <wumpus> cfields: I assued that was the point because one of your other pulls changes the times to std::chrono instead
616 2017-03-30T20:04:47  <wumpus> this one is backportable at least
617 2017-03-30T20:05:24  <cfields> wumpus: yes, and BlueMatt was discussing possibly backporting other scheduler changes. Was just being proactive :)
618 2017-03-30T20:05:27  <gmaxwell> if wallet-flush-in-cscheduler reduces the thread count, then it's also perhaps interesting in a backport. (less memory / address space!)
619 2017-03-30T20:05:30  <wumpus> gmaxwell: it does, but imo it's too risky to backport, we're not entirely sure of it yet this might be only the first issue with it
620 2017-03-30T20:05:34  <gmaxwell> aww
621 2017-03-30T20:05:35  <gmaxwell> :P
622 2017-03-30T20:05:44  <gmaxwell> K
623 2017-03-30T20:06:04  <BlueMatt> gmaxwell: yea, thats why i was proposing backport....but its not simple, apparently, because boost :(
624 2017-03-30T20:06:21  <wumpus> I've always been kind of wary of cscheduler
625 2017-03-30T20:06:32  <BlueMatt> wumpus: yea.....
626 2017-03-30T20:06:34  <gmaxwell> yea... well we've had a lot of problems with it in the past.
627 2017-03-30T20:06:35  <wumpus> there's been lots of issues with it historically at least in the tests
628 2017-03-30T20:06:36  <wumpus> yes
629 2017-03-30T20:06:39  <cfields> wumpus: same. even moreso after diving in to debug that one.
630 2017-03-30T20:07:06  <cfields> in fairness though, i think many issues have been boost-related
631 2017-03-30T20:07:19  <gmaxwell> the general idea of having all the rare periodic stuff in a thread that handles them, is perfectly reasonsble.
632 2017-03-30T20:07:25  <wumpus> yes, and most bugs don't show up in our actual single-threaded usage
633 2017-03-30T20:07:54  <cfields> wumpus: right. I'd be very wary of adding a second thread. I'd expect to uncover a bug or two for sure.
634 2017-03-30T20:08:13  <wumpus> yes, the idea is reasonable
635 2017-03-30T20:08:14  <gmaxwell> oh we were thinking about adding another thread to service the schedueler?
636 2017-03-30T20:08:47  <cfields> gmaxwell: that's how it's designed, anyway
637 2017-03-30T20:08:54  <wumpus> gmaxwell: nonono, please not, it's just that it was designed to be able to work with multiple threads, but that functionality has never been properly verified
638 2017-03-30T20:08:58  *** BCBot has quit IRC
639 2017-03-30T20:09:04  <gmaxwell> yea, well I think thats a bad idea.
640 2017-03-30T20:09:21  <wumpus> there used to be a test that tested it with multiple threads, but that failed randomly and we never found out why
641 2017-03-30T20:09:34  *** echonaut has quit IRC
642 2017-03-30T20:09:36  <gmaxwell> At least it always seemed to be that the whole utility for such a thing is periodic things that don't have strong realtime requirements.
643 2017-03-30T20:09:51  <BlueMatt> wumpus: sounds like its time to just rewrite the thing from scratch just because....
644 2017-03-30T20:10:02  <wumpus> BlueMatt: or just drop the mult-thread functionality
645 2017-03-30T20:10:26  <BlueMatt> well, ok, that too
646 2017-03-30T20:10:37  <wumpus> I think it could be shortened a lot with c++11 functionality like lambdas and tasks etc
647 2017-03-30T20:10:44  *** nemgun has joined #bitcoin-core-dev
648 2017-03-30T20:10:48  <BlueMatt> i mean whatever, leave it there, I plan on moving lots of things to cscheduler, just will have to make it sane before turning it on
649 2017-03-30T20:10:52  <BlueMatt> ie c++11 stuff, probably
650 2017-03-30T20:11:15  *** MarcoFalke_lab has quit IRC
651 2017-03-30T20:11:35  <gmaxwell> the periodic wallet flush is seperate from the realtime wallet flush that happens after issuing a key or whatever, right?
652 2017-03-30T20:11:37  <cfields> std::map<std::chrono::time_point, std::packaged_task> done :)
653 2017-03-30T20:12:27  <wumpus> same for the closure stuff and worker queue in http_server
654 2017-03-30T20:12:27  <gmaxwell> well it should be a min-heap, :P I'm sure there is one of those in stl no?
655 2017-03-30T20:13:09  <BlueMatt> gmaxwell: by "wallet flush", I mean "wallet compaction"
656 2017-03-30T20:13:11  <wumpus> no, stl does not have heap types afaik
657 2017-03-30T20:13:18  <BlueMatt> wallet flush, indeed, is the thing that happens when you write something directly
658 2017-03-30T20:13:23  <wumpus> boost does *ducks*
659 2017-03-30T20:13:31  <wumpus> yes please call it compaction not flush
660 2017-03-30T20:13:47  *** BCBot has joined #bitcoin-core-dev
661 2017-03-30T20:14:00  <gmaxwell> BlueMatt: okay sounds fine then... not the stuff that we need a critical realtime response on.
662 2017-03-30T20:14:40  <wumpus> yes
663 2017-03-30T20:15:19  <BlueMatt> indeed, the function name changed to compaction from flush when it moved into cscheduler
664 2017-03-30T20:15:24  <BlueMatt> because thats a more accurate description
665 2017-03-30T20:15:36  <bitcoin-git> [bitcoin] gmaxwell reopened pull request #9424: Change LogAcceptCategory to use uint32_t rather than sets of strings. (master...log_category_simplify) https://github.com/bitcoin/bitcoin/pull/9424
666 2017-03-30T20:21:04  *** echonaut has joined #bitcoin-core-dev
667 2017-03-30T20:22:43  <wumpus> I don't think I remember ever seeing that pull before. Then again, so many pulls get openened, it's easy to lose track :/
668 2017-03-30T20:24:08  <wumpus> oh end of dec 2016, yea, wasn't too active at that time
669 2017-03-30T20:24:10  *** molz_ has quit IRC
670 2017-03-30T20:24:38  *** molz_ has joined #bitcoin-core-dev
671 2017-03-30T20:27:23  *** nemgun has quit IRC
672 2017-03-30T20:32:08  *** PaulCape_ has joined #bitcoin-core-dev
673 2017-03-30T20:33:28  *** PaulCapestany has quit IRC
674 2017-03-30T20:38:43  *** cdecker has quit IRC
675 2017-03-30T20:42:14  <bitcoin-git> [bitcoin] jnewbery opened pull request #10130: bitcoin-tx input verification (master...bitcoin_tx_input_sanitiser) https://github.com/bitcoin/bitcoin/pull/10130
676 2017-03-30T20:45:01  *** cdecker has joined #bitcoin-core-dev
677 2017-03-30T20:48:03  <phantomcircuit> wait there's an issue with flush in csceduler?
678 2017-03-30T20:49:46  <cfields> phantomcircuit: only with old boost
679 2017-03-30T20:51:52  <phantomcircuit> oh
680 2017-03-30T20:56:27  *** laurentmt has quit IRC
681 2017-03-30T21:01:47  *** jannes has quit IRC
682 2017-03-30T21:15:03  *** nabu has joined #bitcoin-core-dev
683 2017-03-30T21:31:05  <achow101> if a ping message is sent, but a pong is not received, will other messages still be sent to the pinged node until the ping timeout?
684 2017-03-30T21:38:01  <sipa> yes
685 2017-03-30T21:38:40  <achow101> interesting, I'm not seeing that on wireshark..
686 2017-03-30T21:39:33  <achow101> for that matter, I don't see the ping in question being sent, I just see it in the debug.log
687 2017-03-30T21:52:05  *** magicwund has quit IRC
688 2017-03-30T22:08:19  *** Guyver2 has quit IRC
689 2017-03-30T22:27:34  *** Cory has quit IRC
690 2017-03-30T22:41:24  *** vicenteH has quit IRC
691 2017-03-30T22:50:06  *** Cory has joined #bitcoin-core-dev
692 2017-03-30T23:08:04  *** alpalp has joined #bitcoin-core-dev
693 2017-03-30T23:08:04  *** alpalp has joined #bitcoin-core-dev
694 2017-03-30T23:09:42  <bitcoin-git> [bitcoin] fanquake closed pull request #10106: bitcoin-tx: Fix missing range check (master...bitcointx-addoutaddr) https://github.com/bitcoin/bitcoin/pull/10106
695 2017-03-30T23:23:19  *** goksinen has joined #bitcoin-core-dev
696 2017-03-30T23:51:33  *** bityogi has quit IRC
697 2017-03-30T23:54:36  *** abpa has quit IRC