1 2016-10-06T00:19:36  *** droark has quit IRC
  2 2016-10-06T00:23:16  *** Alopex has quit IRC
  3 2016-10-06T00:24:01  *** juscamarena has quit IRC
  4 2016-10-06T00:24:21  *** Alopex has joined #bitcoin-core-dev
  5 2016-10-06T00:28:39  *** juscamarena has joined #bitcoin-core-dev
  6 2016-10-06T00:29:24  *** arubi has quit IRC
  7 2016-10-06T00:37:28  *** Ylbam has quit IRC
  8 2016-10-06T01:02:16  *** justan0theruser has joined #bitcoin-core-dev
  9 2016-10-06T01:04:50  *** justanotheruser has quit IRC
 10 2016-10-06T01:15:31  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 11 2016-10-06T01:50:09  *** baldur has quit IRC
 12 2016-10-06T01:55:32  *** Alopex has quit IRC
 13 2016-10-06T01:56:37  *** Alopex has joined #bitcoin-core-dev
 14 2016-10-06T02:03:23  *** baldur has joined #bitcoin-core-dev
 15 2016-10-06T02:06:07  <Dabs> uh. md5? isn't that "broken" ?
 16 2016-10-06T02:20:51  *** randy-waterhouse has quit IRC
 17 2016-10-06T02:24:30  *** harrymm has quit IRC
 18 2016-10-06T02:26:44  <luke-jr> Dabs: not because of its speed
 19 2016-10-06T02:41:31  *** randy-waterhouse has joined #bitcoin-core-dev
 20 2016-10-06T02:44:50  *** harrymm has joined #bitcoin-core-dev
 21 2016-10-06T02:51:01  *** Alopex has quit IRC
 22 2016-10-06T02:52:06  *** Alopex has joined #bitcoin-core-dev
 23 2016-10-06T02:58:52  <jeremyrubin> Dabs: probably not if you use a unique secret salt
 24 2016-10-06T03:04:23  *** randy-waterhouse has quit IRC
 25 2016-10-06T03:09:01  *** Alopex has quit IRC
 26 2016-10-06T03:10:06  *** Alopex has joined #bitcoin-core-dev
 27 2016-10-06T03:12:04  <Dabs> yeah, but ... you'll have to always justify using a "broken" primitive. ... anyway. I guess it depends on the purpose.. hmac md5 or something.
 28 2016-10-06T03:12:59  *** justan0theruser has quit IRC
 29 2016-10-06T03:17:52  *** Chris_Stewart_5 has quit IRC
 30 2016-10-06T03:18:19  <jeremyrubin> Dabs: I'm not seriously advocating using it... but it's really not broken in this use case.
 31 2016-10-06T03:18:31  <jeremyrubin> Dabs: For the same reason RIPEMD-160 is OK
 32 2016-10-06T03:19:49  <jeremyrubin> oops RIPEMD != RIPEMD-160
 33 2016-10-06T03:20:20  <jeremyrubin> Anyways, most of those collisions require the attacker to fully control both documents being hashed
 34 2016-10-06T03:20:26  <jeremyrubin> to collide their hashes
 35 2016-10-06T03:31:21  *** Alopex has quit IRC
 36 2016-10-06T03:32:26  *** Alopex has joined #bitcoin-core-dev
 37 2016-10-06T03:42:41  *** Alopex has quit IRC
 38 2016-10-06T03:43:47  *** Alopex has joined #bitcoin-core-dev
 39 2016-10-06T03:46:12  *** mrkent has joined #bitcoin-core-dev
 40 2016-10-06T03:48:28  <luke-jr> Dabs: MD5 is not a primitive of BLAKE2b, they just have similar speeds
 41 2016-10-06T03:55:51  *** waxwing has quit IRC
 42 2016-10-06T04:03:17  *** harrymm has left #bitcoin-core-dev
 43 2016-10-06T04:12:31  *** Alopex has quit IRC
 44 2016-10-06T04:13:36  *** Alopex has joined #bitcoin-core-dev
 45 2016-10-06T04:24:36  *** Alopex has quit IRC
 46 2016-10-06T04:25:42  *** Alopex has joined #bitcoin-core-dev
 47 2016-10-06T04:29:25  *** Giszmo has quit IRC
 48 2016-10-06T04:39:05  *** jtimon has quit IRC
 49 2016-10-06T05:00:08  *** dermoth has quit IRC
 50 2016-10-06T05:01:01  *** dermoth has joined #bitcoin-core-dev
 51 2016-10-06T05:14:19  *** justanotheruser has joined #bitcoin-core-dev
 52 2016-10-06T05:26:00  *** meowzus has quit IRC
 53 2016-10-06T05:46:22  *** arubi has joined #bitcoin-core-dev
 54 2016-10-06T05:52:01  *** Alopex has quit IRC
 55 2016-10-06T05:53:06  *** Alopex has joined #bitcoin-core-dev
 56 2016-10-06T06:07:16  *** Alopex has quit IRC
 57 2016-10-06T06:08:22  *** Alopex has joined #bitcoin-core-dev
 58 2016-10-06T06:19:13  <wumpus> please don't use md5 in new code
 59 2016-10-06T06:19:37  *** jl2012 has quit IRC
 60 2016-10-06T06:19:54  <wumpus> it's, at its current level of brokenness still fine for some continuing legacy usages, but for new designs it should be avoided
 61 2016-10-06T06:22:47  <wumpus> there are modern fast and secure hash functions (indeed as BLAKE), and if speed trumps cryptographic security there are tons of other options
 62 2016-10-06T06:23:08  <wumpus> 
 63 2016-10-06T06:23:14  *** jl2012 has joined #bitcoin-core-dev
 64 2016-10-06T06:45:17  *** jl2012 has quit IRC
 65 2016-10-06T06:50:58  *** jeremias has joined #bitcoin-core-dev
 66 2016-10-06T06:52:08  *** paveljanik has quit IRC
 67 2016-10-06T06:52:53  *** jl2012 has joined #bitcoin-core-dev
 68 2016-10-06T07:14:00  *** rubensayshi has joined #bitcoin-core-dev
 69 2016-10-06T07:18:23  *** Ylbam has joined #bitcoin-core-dev
 70 2016-10-06T07:19:51  *** MarcoFalke has joined #bitcoin-core-dev
 71 2016-10-06T07:26:15  *** laurentmt has joined #bitcoin-core-dev
 72 2016-10-06T07:28:09  <GitHub95> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/223f4c2dd5fa...61d191fbf953
 73 2016-10-06T07:28:10  <GitHub95> bitcoin/master 7d8afb4 fanquake: [Doc] Improve GitHub issue template
 74 2016-10-06T07:28:10  <GitHub95> bitcoin/master 61d191f MarcoFalke: Merge #8887: [Doc] Improve GitHub issue template...
 75 2016-10-06T07:28:24  <GitHub95> [bitcoin] MarcoFalke closed pull request #8887: [Doc] Improve GitHub issue template (master...link-stackexchange) https://github.com/bitcoin/bitcoin/pull/8887
 76 2016-10-06T07:28:33  *** laurentmt has quit IRC
 77 2016-10-06T07:28:53  *** laurentmt has joined #bitcoin-core-dev
 78 2016-10-06T07:29:24  *** laurentmt has quit IRC
 79 2016-10-06T07:31:04  *** Guyver2 has joined #bitcoin-core-dev
 80 2016-10-06T08:20:30  *** h1d has joined #bitcoin-core-dev
 81 2016-10-06T08:20:52  *** jannes has joined #bitcoin-core-dev
 82 2016-10-06T08:21:46  *** h1d has quit IRC
 83 2016-10-06T08:28:59  *** mrkent has quit IRC
 84 2016-10-06T08:29:54  *** mrkent has joined #bitcoin-core-dev
 85 2016-10-06T08:55:11  *** Alopex has quit IRC
 86 2016-10-06T08:56:17  *** Alopex has joined #bitcoin-core-dev
 87 2016-10-06T09:04:26  *** arowser has quit IRC
 88 2016-10-06T09:04:41  *** arowser has joined #bitcoin-core-dev
 89 2016-10-06T09:05:18  *** mkarrer has quit IRC
 90 2016-10-06T09:05:19  *** mkarrer_ has joined #bitcoin-core-dev
 91 2016-10-06T09:09:43  *** rexnsh has quit IRC
 92 2016-10-06T09:09:44  *** rexnsh has joined #bitcoin-core-dev
 93 2016-10-06T09:46:39  *** GAit has joined #bitcoin-core-dev
 94 2016-10-06T09:55:19  *** GAit1 has joined #bitcoin-core-dev
 95 2016-10-06T09:58:06  *** GAit has quit IRC
 96 2016-10-06T09:58:15  <NicolasDorier> roasbeef: You can now measure your size https://testnet.smartbit.com.au/block/0000000000001280a3d758cb956e565daffd5af0e6b6723f28e1cbcda0da8652 ;)
 97 2016-10-06T09:59:26  *** shesek has quit IRC
 98 2016-10-06T10:00:38  <btcdrak> ah, great it's been made segwitty
 99 2016-10-06T10:02:56  *** GAit1 has quit IRC
100 2016-10-06T10:05:07  *** shesek has joined #bitcoin-core-dev
101 2016-10-06T10:11:22  *** AaronvanW has quit IRC
102 2016-10-06T10:14:55  *** shesek has quit IRC
103 2016-10-06T10:29:53  *** AaronvanW has joined #bitcoin-core-dev
104 2016-10-06T10:30:14  *** aalex_ has quit IRC
105 2016-10-06T10:30:53  *** aalex__ has joined #bitcoin-core-dev
106 2016-10-06T10:34:39  *** DigiByteDev has quit IRC
107 2016-10-06T11:04:40  *** cdecker has joined #bitcoin-core-dev
108 2016-10-06T11:08:39  *** GAit has joined #bitcoin-core-dev
109 2016-10-06T11:19:03  *** laurentmt has joined #bitcoin-core-dev
110 2016-10-06T11:19:12  *** laurentmt has quit IRC
111 2016-10-06T11:23:15  *** DigiByteDev has joined #bitcoin-core-dev
112 2016-10-06T11:39:18  *** cryptapus has joined #bitcoin-core-dev
113 2016-10-06T11:39:18  *** cryptapus has joined #bitcoin-core-dev
114 2016-10-06T11:46:08  *** arowser has quit IRC
115 2016-10-06T11:47:43  *** arowser has joined #bitcoin-core-dev
116 2016-10-06T12:14:49  *** laurentmt has joined #bitcoin-core-dev
117 2016-10-06T12:17:06  *** laurentmt has quit IRC
118 2016-10-06T12:23:36  *** murch has joined #bitcoin-core-dev
119 2016-10-06T12:31:19  *** waxwing has joined #bitcoin-core-dev
120 2016-10-06T12:32:57  *** jnewbery has joined #bitcoin-core-dev
121 2016-10-06T12:36:20  *** meowzus has joined #bitcoin-core-dev
122 2016-10-06T12:36:43  *** Ylbam has quit IRC
123 2016-10-06T12:36:44  *** jl2012 has quit IRC
124 2016-10-06T12:39:38  *** Ylbam has joined #bitcoin-core-dev
125 2016-10-06T12:41:03  *** laurentmt has joined #bitcoin-core-dev
126 2016-10-06T12:41:36  *** jl2012 has joined #bitcoin-core-dev
127 2016-10-06T13:03:49  *** laurentmt has quit IRC
128 2016-10-06T13:28:38  *** GAit has quit IRC
129 2016-10-06T13:29:59  *** GAit has joined #bitcoin-core-dev
130 2016-10-06T13:32:42  *** jtimon has joined #bitcoin-core-dev
131 2016-10-06T13:42:02  *** Evel-Knievel has quit IRC
132 2016-10-06T13:45:53  *** Chris_Stewart_5 has joined #bitcoin-core-dev
133 2016-10-06T13:53:41  *** rubensayshi has quit IRC
134 2016-10-06T13:58:25  *** GAit has quit IRC
135 2016-10-06T14:09:29  *** instagibbs has joined #bitcoin-core-dev
136 2016-10-06T14:24:23  <morcos> gmaxwell: sorry i missed discussion yesterday on the cuckoo sigcache.  jeremyrubin and i did put a LOT of work into different designs.   but i do think this design if far better than the existing sig cache.
137 2016-10-06T14:24:41  <sipa> morcos: i don't think there is doubt that it's better :)
138 2016-10-06T14:25:05  <morcos> it might be fine to reduce the depth limit or untie it from the size of the table.  but i seriously doubt it impacts the performance of ATMP.  (once we saw how inefficient the old deleting behavior was anyway)
139 2016-10-06T14:25:57  <jeremyrubin> wumpus: it wasn't a serious suggestion ;)
140 2016-10-06T14:26:06  <morcos> one thing to keep in mind is that with a 40MB sigcache, it probably isn't going to get full except in the event of an attack.  i ran a simulation over 6 months, and i was getting very close to the maximal possible hit rate on a 40MB cache.
141 2016-10-06T14:26:10  *** Giszmo has joined #bitcoin-core-dev
142 2016-10-06T14:26:19  <morcos> the fact that we delete sigs that were in blocks makes a HUGE difference
143 2016-10-06T14:26:33  <sipa> morcos: yes... but we should know how it behaves in case of an attack as well
144 2016-10-06T14:26:46  <sipa> without attack, i expect the size of the cache to not even matter that much
145 2016-10-06T14:26:52  <sipa> as we'll only ever have live entries in it
146 2016-10-06T14:27:07  <morcos> my idea for how to make it even more fool proof from ever getting full would be to implement a Rolling version where you have 2 and insert and check in both of them and then alternately clear them after some amount of time
147 2016-10-06T14:27:33  <sipa> morcos: ha, the old rolling bloom filter design :)
148 2016-10-06T14:27:41  <morcos> sipa: in the absence of attack there are still txs that get generated but are never mined (replaced, doublespent, too low fee)
149 2016-10-06T14:27:48  <sipa> right
150 2016-10-06T14:27:54  <morcos> sipa: yeah i just didn't think it was worth the complication for the first PR
151 2016-10-06T14:28:01  <sipa> morcos: completely agreed
152 2016-10-06T14:28:26  * sipa just hopes 0.13.1 is out the door soon
153 2016-10-06T14:28:43  <jeremyrubin> generations are better than rolling I think
154 2016-10-06T14:28:53  <sipa> jeremyrubin: yes, i think so
155 2016-10-06T14:29:18  <sipa> especially given your entries are already 128-256 bits, adding a few bits for a generation number doesn't add much
156 2016-10-06T14:29:45  <sipa> using two staggered sets effectively makes your entries twice the size
157 2016-10-06T14:29:55  <sipa> or even 4 times
158 2016-10-06T14:30:13  <morcos> sure, sounds good to me too
159 2016-10-06T14:30:27  <sipa> as in the worst case time, you just emptied one, and the other one is half full, so you have 25% utilization of your entire set
160 2016-10-06T14:30:35  <jeremyrubin> Also fee is maybe even better than generations
161 2016-10-06T14:31:00  <sipa> use an ARC :)
162 2016-10-06T14:31:09  <jeremyrubin> You can also emulate generations
163 2016-10-06T14:31:34  <jeremyrubin> by createnewblocking a 10mb block or something from mempool
164 2016-10-06T14:31:40  <jeremyrubin> after deleting a bunch of things randomly
165 2016-10-06T14:31:52  <jeremyrubin> if you want 0 memory overhead
166 2016-10-06T14:31:55  <sipa> https://en.wikipedia.org/wiki/Adaptive_replacement_cache
167 2016-10-06T14:32:10  <jeremyrubin> sipa: ah, not automatic reference counting
168 2016-10-06T14:32:43  <jeremyrubin> ARC seems not to work for this use case?
169 2016-10-06T14:32:49  <jeremyrubin> Things are write once read once?
170 2016-10-06T14:33:10  <sipa> ah, i'm confusing with the coin cache
171 2016-10-06T14:53:50  *** limpkin has quit IRC
172 2016-10-06T14:54:19  *** wallet42 has quit IRC
173 2016-10-06T14:54:51  *** aalex has quit IRC
174 2016-10-06T14:55:54  *** michagogo has quit IRC
175 2016-10-06T14:59:35  *** AaronvanW has quit IRC
176 2016-10-06T15:06:20  *** Chris_Stewart_5 has quit IRC
177 2016-10-06T15:13:12  *** michagogo has joined #bitcoin-core-dev
178 2016-10-06T15:34:22  *** wallet42 has joined #bitcoin-core-dev
179 2016-10-06T15:35:10  *** aalex has joined #bitcoin-core-dev
180 2016-10-06T15:35:16  *** limpkin has joined #bitcoin-core-dev
181 2016-10-06T15:46:15  *** laurentmt has joined #bitcoin-core-dev
182 2016-10-06T15:49:20  *** mrkent has quit IRC
183 2016-10-06T15:53:26  *** laurentmt has quit IRC
184 2016-10-06T15:59:38  *** jnewbery has quit IRC
185 2016-10-06T16:00:11  *** jnewbery has joined #bitcoin-core-dev
186 2016-10-06T16:04:56  *** jnewbery has quit IRC
187 2016-10-06T16:11:41  *** droark has joined #bitcoin-core-dev
188 2016-10-06T16:15:41  *** DigiByteDev has quit IRC
189 2016-10-06T16:21:31  *** jnewbery has joined #bitcoin-core-dev
190 2016-10-06T16:38:50  *** cchadwicka1 has joined #bitcoin-core-dev
191 2016-10-06T16:40:10  *** spudowiar has joined #bitcoin-core-dev
192 2016-10-06T16:56:54  *** paveljanik has joined #bitcoin-core-dev
193 2016-10-06T16:56:54  *** paveljanik has joined #bitcoin-core-dev
194 2016-10-06T17:06:55  <gmaxwell> morcos: part of the reason I was asking questions is that I wasn't sure if we knew how it would perform once someone sent in a huge set of junk transactions. But have no doubt, I'm sure its much better than what we currently have.
195 2016-10-06T17:07:17  <gmaxwell> I'm surprised it didn't bencmark out as faster with only a single thread.
196 2016-10-06T17:08:30  <morcos> gmaxwell: it was ever so slightly faster (1%) for a single thread, but thats within noise.  i just think the amount of time taken in either case is small, it was only the lock contention that was a true problem.
197 2016-10-06T17:09:41  <morcos> but now you inspired a hopefully efficient generation keeping design that will never get full, but only delete old generations if it needs to..   :)
198 2016-10-06T17:11:43  <gmaxwell> sipa: re generation number, I had just assumed the entries would be changed to 252 bits, so you'd only lose at most 6% at a time, and would only delete things if it had to.
199 2016-10-06T17:13:08  *** Chris_Stewart_5 has joined #bitcoin-core-dev
200 2016-10-06T17:15:16  <morcos> the idea jeremyrubin and i want to try is actually a separate bit vector that just keeps track of whehter each entry is in the current generation or not.  that's only touched during insert, so its lock free.  and then use a simple heuristic to trigger an occasional testforcleanup.
201 2016-10-06T17:16:33  <morcos> when doing that you just loop that vector and the garbage collection vector and if the current generation not marked for deletion is > 25% of capacity then mark for deletion old generation and increase generation.
202 2016-10-06T17:17:13  <morcos> that has the nice property that you don't actually delete old things unless you have to, but under an attack you'll delete them often enough to stop yourself getting full.
203 2016-10-06T17:18:53  *** Chris_Stewart_5 has quit IRC
204 2016-10-06T17:22:21  *** laurentmt has joined #bitcoin-core-dev
205 2016-10-06T17:26:04  *** laurentmt has quit IRC
206 2016-10-06T17:45:13  <gmaxwell> I wish we could easily delete based on an entry being in the top of the mempool or not.
207 2016-10-06T17:45:38  <gmaxwell> hm. I suppose that when we evict something from the mempool, we could revalidate it again with the cache in delete mode.
208 2016-10-06T17:45:50  <gmaxwell> that would be kinda like that.
209 2016-10-06T17:46:32  <gmaxwell> or insert things with a lower feerate 1 or two generations behind the current generation. (assuming many generations)
210 2016-10-06T17:50:39  <michagogo> Today's lesson in my programming lessons: threading is hard
211 2016-10-06T17:51:08  <sdaftuar> gmaxwell: i was thinking about doing that (revalidate in delete mode) for things that we don't accept to our mempool, as well
212 2016-10-06T17:51:37  <morcos> gmaxwell: with a 40MB cache, it's just not necessary to make further optimizations.  someone would have to flood you with 250k excess signatures in order for you to start marking for deletion things older than when the flood started.
213 2016-10-06T17:51:41  <michagogo> (Also, each iteration of a for loop has its own scope for local variables, and those variables stick around even after the iteration is done and the name is reused for something else)
214 2016-10-06T17:52:16  <morcos> if that time frame is recent enough that its causing a problem for your cache hit rate, then i think that implies your bigger problem is the tx flood and the DoS on checking all those sigs in the first place
215 2016-10-06T17:52:19  <michagogo> (or rather, reused for the next iteration)
216 2016-10-06T17:54:46  <gmaxwell> morcos: okay, for some reason I thought sipa's measurements had shown that we still had a needlessly low hitrate.
217 2016-10-06T17:56:17  <morcos> gmaxwell: hmm, i'd be interested to see that, but i think any low hit rates we have are probably due to txs we never accepted to our mempool in the first place, not sigs that we accidentally evicted..
218 2016-10-06T17:57:17  <gmaxwell> yea, I may be conflating things. it might be that right now its from things we never accept, and when sipa tried validating everything, we found it tainted the cache.
219 2016-10-06T17:58:21  <morcos> gmaxwell: i attempted an approximation by inserting 10 random signatures for every tx my node saw and deleting those same 10 if the tx appeared in a block
220 2016-10-06T17:59:07  *** cdecker has quit IRC
221 2016-10-06T17:59:18  <morcos> i ran that for 6 months and the hit rate was 98.35% on average, whereas perfect would have been 98.38% and the existing algo was 97.99%.  with 40MB
222 2016-10-06T18:00:06  <gmaxwell> hm. why was the existing algo lower?
223 2016-10-06T18:00:07  <morcos> in reality many of those txs probably wouldn't have passed ATMP and made it into the cache, leading to a lower hit rate in practice, but not due to cache filling
224 2016-10-06T18:00:12  *** [b__b] has quit IRC
225 2016-10-06T18:00:22  *** cdecker has joined #bitcoin-core-dev
226 2016-10-06T18:00:28  <morcos> gmaxwell: primarily because you can cram more signatures in 40MB with the new design
227 2016-10-06T18:00:31  *** [b__b] has joined #bitcoin-core-dev
228 2016-10-06T18:00:46  <morcos> and partially because on a reorg the old algo doesn't have them, but the new one does with high probability
229 2016-10-06T18:00:52  <gmaxwell> Makes sense.
230 2016-10-06T18:01:30  <gmaxwell> yea, I'm really happy about the delete flag. I really didn't like the current code's behavior under reorg.
231 2016-10-06T18:01:42  <gmaxwell> not good for network convergence for reorg to be much slower.
232 2016-10-06T18:02:01  <morcos> gmaxwell: heh, probably MANY things to improve there
233 2016-10-06T18:02:18  <gmaxwell> yes. but any improvement is good. :)
234 2016-10-06T18:03:02  <gmaxwell> I'd take a wag that the validation performance limiter is now the additional sha256 used in the lookup.
235 2016-10-06T18:06:06  *** cchadwicka1 has quit IRC
236 2016-10-06T18:07:56  *** cchadwicka has joined #bitcoin-core-dev
237 2016-10-06T18:08:07  *** jnewbery has quit IRC
238 2016-10-06T18:08:08  <morcos> gmaxwell: as far as jeremyrubin and i can tell, the biggest limiter now is how much you blow out your various machine caches with different permutations of coinsviewcache size and flushing algo, sig cache lookup pattern, etc..  although this tends to affect performance AFTER validation has finished. i.e. slows down removeForBlock
239 2016-10-06T18:08:27  *** Frederic94500 has joined #bitcoin-core-dev
240 2016-10-06T18:09:32  <morcos> to really get better performance we'll need to switch data representations to eliminate so much allocating, deallocating and copying of vectors.
241 2016-10-06T18:10:09  <morcos> but sdaftuar's idea is the next lowest hanging fruit is to just speed the path from validation finished to actually relaying to new peers, which isn't optimized at all right now
242 2016-10-06T18:10:31  *** cchadwicka1 has joined #bitcoin-core-dev
243 2016-10-06T18:10:38  <gmaxwell> well BIP152 allows you to send the block before its verified.
244 2016-10-06T18:10:52  <gmaxwell> so that would be an obvious thing to actually do.
245 2016-10-06T18:11:46  <morcos> sure.  same issue still applies though.  you're just deciding to send it earlier.
246 2016-10-06T18:12:16  *** cchadwicka1 has quit IRC
247 2016-10-06T18:13:01  <sdaftuar> i think gmaxwell's point is that the way you'd do that would be in the handling of eg ProcessNewBlock, so it'd actually go out earlier (rather than in SendMessages)
248 2016-10-06T18:13:01  *** cchadwicka has quit IRC
249 2016-10-06T18:13:06  <sdaftuar> that's basically what i was planning to do
250 2016-10-06T18:13:37  <gmaxwell> well it gets the whole validation process out of that critical path.
251 2016-10-06T18:14:11  *** cchadwicka has joined #bitcoin-core-dev
252 2016-10-06T18:14:47  *** cchadwicka has quit IRC
253 2016-10-06T18:16:42  *** cchadwicka has joined #bitcoin-core-dev
254 2016-10-06T18:20:41  *** cchadwicka1 has joined #bitcoin-core-dev
255 2016-10-06T18:21:35  *** cchadwicka has quit IRC
256 2016-10-06T18:29:59  *** laurentmt has joined #bitcoin-core-dev
257 2016-10-06T18:30:50  *** laurentmt has quit IRC
258 2016-10-06T18:34:32  *** laurentmt has joined #bitcoin-core-dev
259 2016-10-06T18:40:08  *** spudowiar has quit IRC
260 2016-10-06T18:52:42  *** Frederic94500 has quit IRC
261 2016-10-06T18:55:00  *** Guyver2 has quit IRC
262 2016-10-06T18:57:36  *** Guyver2 has joined #bitcoin-core-dev
263 2016-10-06T19:01:14  *** cchadwicka1 has quit IRC
264 2016-10-06T19:01:45  <michagogo> (Go figure... After a bunch of weeks of having something else every time, this week I'm around but the meeting is cancelled)
265 2016-10-06T19:02:19  *** laurentmt has quit IRC
266 2016-10-06T19:14:42  *** Chris_Stewart_5 has joined #bitcoin-core-dev
267 2016-10-06T19:18:31  *** MarcoFalke has left #bitcoin-core-dev
268 2016-10-06T19:20:54  <jeremyrubin> gmaxwell: note you don't actually have to re-evaluate the signature, just see if it's hash is present on eviction (but you still need to eval script to extract signatures)
269 2016-10-06T19:22:42  *** Frederic94500 has joined #bitcoin-core-dev
270 2016-10-06T19:29:12  *** Frederic94500 has quit IRC
271 2016-10-06T19:36:56  *** cdecker has quit IRC
272 2016-10-06T19:54:25  *** cryptapus has quit IRC
273 2016-10-06T19:54:38  *** drnet has joined #bitcoin-core-dev
274 2016-10-06T19:57:58  *** drnet has quit IRC
275 2016-10-06T20:01:53  *** jtimon has quit IRC
276 2016-10-06T20:14:15  *** JackH has joined #bitcoin-core-dev
277 2016-10-06T20:14:35  *** e4xit has quit IRC
278 2016-10-06T20:22:08  *** JackH has quit IRC
279 2016-10-06T20:28:03  *** cjcj has quit IRC
280 2016-10-06T20:28:50  *** bsm117532 has quit IRC
281 2016-10-06T20:29:39  *** Chris_Stewart_5 has quit IRC
282 2016-10-06T20:34:02  *** GAit has joined #bitcoin-core-dev
283 2016-10-06T20:35:22  *** GAit has quit IRC
284 2016-10-06T20:39:21  *** timothy has quit IRC
285 2016-10-06T20:39:23  *** drizztbsd has joined #bitcoin-core-dev
286 2016-10-06T20:39:56  *** drizztbsd is now known as timothy
287 2016-10-06T20:44:50  *** instagibbs has quit IRC
288 2016-10-06T20:45:53  *** Chris_Stewart_5 has joined #bitcoin-core-dev
289 2016-10-06T20:47:18  *** instagibbs has joined #bitcoin-core-dev
290 2016-10-06T20:58:32  *** JackH has joined #bitcoin-core-dev
291 2016-10-06T21:01:53  *** HG has joined #bitcoin-core-dev
292 2016-10-06T21:03:06  *** Fonslls has joined #bitcoin-core-dev
293 2016-10-06T21:42:59  *** Guyver2 has quit IRC
294 2016-10-06T21:55:14  *** cdecker has joined #bitcoin-core-dev
295 2016-10-06T21:57:39  *** mrkent has joined #bitcoin-core-dev
296 2016-10-06T22:01:01  *** timothy has quit IRC
297 2016-10-06T22:01:04  *** drizztbsd has joined #bitcoin-core-dev
298 2016-10-06T22:01:37  *** drizztbsd is now known as timothy
299 2016-10-06T22:12:39  *** mrkent has quit IRC
300 2016-10-06T22:39:13  *** jannes has quit IRC
301 2016-10-06T22:48:42  *** GAit has joined #bitcoin-core-dev
302 2016-10-06T22:52:37  *** GAit1 has joined #bitcoin-core-dev
303 2016-10-06T22:55:21  *** GAit1 has quit IRC
304 2016-10-06T22:56:54  *** GAit has quit IRC
305 2016-10-06T23:05:13  *** Evel-Knievel has joined #bitcoin-core-dev
306 2016-10-06T23:15:42  *** murch has quit IRC
307 2016-10-06T23:43:16  *** PRab has quit IRC