12016-10-06T00:19:36  *** droark has quit IRC
  22016-10-06T00:23:16  *** Alopex has quit IRC
  32016-10-06T00:24:01  *** juscamarena has quit IRC
  42016-10-06T00:24:21  *** Alopex has joined #bitcoin-core-dev
  52016-10-06T00:28:39  *** juscamarena has joined #bitcoin-core-dev
  62016-10-06T00:29:24  *** arubi has quit IRC
  72016-10-06T00:37:28  *** Ylbam has quit IRC
  82016-10-06T01:02:16  *** justan0theruser has joined #bitcoin-core-dev
  92016-10-06T01:04:50  *** justanotheruser has quit IRC
 102016-10-06T01:15:31  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 112016-10-06T01:50:09  *** baldur has quit IRC
 122016-10-06T01:55:32  *** Alopex has quit IRC
 132016-10-06T01:56:37  *** Alopex has joined #bitcoin-core-dev
 142016-10-06T02:03:23  *** baldur has joined #bitcoin-core-dev
 152016-10-06T02:06:07  <Dabs> uh. md5? isn't that "broken" ?
 162016-10-06T02:20:51  *** randy-waterhouse has quit IRC
 172016-10-06T02:24:30  *** harrymm has quit IRC
 182016-10-06T02:26:44  <luke-jr> Dabs: not because of its speed
 192016-10-06T02:41:31  *** randy-waterhouse has joined #bitcoin-core-dev
 202016-10-06T02:44:50  *** harrymm has joined #bitcoin-core-dev
 212016-10-06T02:51:01  *** Alopex has quit IRC
 222016-10-06T02:52:06  *** Alopex has joined #bitcoin-core-dev
 232016-10-06T02:58:52  <jeremyrubin> Dabs: probably not if you use a unique secret salt
 242016-10-06T03:04:23  *** randy-waterhouse has quit IRC
 252016-10-06T03:09:01  *** Alopex has quit IRC
 262016-10-06T03:10:06  *** Alopex has joined #bitcoin-core-dev
 272016-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.
 282016-10-06T03:12:59  *** justan0theruser has quit IRC
 292016-10-06T03:17:52  *** Chris_Stewart_5 has quit IRC
 302016-10-06T03:18:19  <jeremyrubin> Dabs: I'm not seriously advocating using it... but it's really not broken in this use case.
 312016-10-06T03:18:31  <jeremyrubin> Dabs: For the same reason RIPEMD-160 is OK
 322016-10-06T03:19:49  <jeremyrubin> oops RIPEMD != RIPEMD-160
 332016-10-06T03:20:20  <jeremyrubin> Anyways, most of those collisions require the attacker to fully control both documents being hashed
 342016-10-06T03:20:26  <jeremyrubin> to collide their hashes
 352016-10-06T03:31:21  *** Alopex has quit IRC
 362016-10-06T03:32:26  *** Alopex has joined #bitcoin-core-dev
 372016-10-06T03:42:41  *** Alopex has quit IRC
 382016-10-06T03:43:47  *** Alopex has joined #bitcoin-core-dev
 392016-10-06T03:46:12  *** mrkent has joined #bitcoin-core-dev
 402016-10-06T03:48:28  <luke-jr> Dabs: MD5 is not a primitive of BLAKE2b, they just have similar speeds
 412016-10-06T03:55:51  *** waxwing has quit IRC
 422016-10-06T04:03:17  *** harrymm has left #bitcoin-core-dev
 432016-10-06T04:12:31  *** Alopex has quit IRC
 442016-10-06T04:13:36  *** Alopex has joined #bitcoin-core-dev
 452016-10-06T04:24:36  *** Alopex has quit IRC
 462016-10-06T04:25:42  *** Alopex has joined #bitcoin-core-dev
 472016-10-06T04:29:25  *** Giszmo has quit IRC
 482016-10-06T04:39:05  *** jtimon has quit IRC
 492016-10-06T05:00:08  *** dermoth has quit IRC
 502016-10-06T05:01:01  *** dermoth has joined #bitcoin-core-dev
 512016-10-06T05:14:19  *** justanotheruser has joined #bitcoin-core-dev
 522016-10-06T05:26:00  *** meowzus has quit IRC
 532016-10-06T05:46:22  *** arubi has joined #bitcoin-core-dev
 542016-10-06T05:52:01  *** Alopex has quit IRC
 552016-10-06T05:53:06  *** Alopex has joined #bitcoin-core-dev
 562016-10-06T06:07:16  *** Alopex has quit IRC
 572016-10-06T06:08:22  *** Alopex has joined #bitcoin-core-dev
 582016-10-06T06:19:13  <wumpus> please don't use md5 in new code
 592016-10-06T06:19:37  *** jl2012 has quit IRC
 602016-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
 612016-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
 622016-10-06T06:23:08  <wumpus> 
 632016-10-06T06:23:14  *** jl2012 has joined #bitcoin-core-dev
 642016-10-06T06:45:17  *** jl2012 has quit IRC
 652016-10-06T06:50:58  *** jeremias has joined #bitcoin-core-dev
 662016-10-06T06:52:08  *** paveljanik has quit IRC
 672016-10-06T06:52:53  *** jl2012 has joined #bitcoin-core-dev
 682016-10-06T07:14:00  *** rubensayshi has joined #bitcoin-core-dev
 692016-10-06T07:18:23  *** Ylbam has joined #bitcoin-core-dev
 702016-10-06T07:19:51  *** MarcoFalke has joined #bitcoin-core-dev
 712016-10-06T07:26:15  *** laurentmt has joined #bitcoin-core-dev
 722016-10-06T07:28:09  <GitHub95> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/223f4c2dd5fa...61d191fbf953
 732016-10-06T07:28:10  <GitHub95> bitcoin/master 7d8afb4 fanquake: [Doc] Improve GitHub issue template
 742016-10-06T07:28:10  <GitHub95> bitcoin/master 61d191f MarcoFalke: Merge #8887: [Doc] Improve GitHub issue template...
 752016-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
 762016-10-06T07:28:33  *** laurentmt has quit IRC
 772016-10-06T07:28:53  *** laurentmt has joined #bitcoin-core-dev
 782016-10-06T07:29:24  *** laurentmt has quit IRC
 792016-10-06T07:31:04  *** Guyver2 has joined #bitcoin-core-dev
 802016-10-06T08:20:30  *** h1d has joined #bitcoin-core-dev
 812016-10-06T08:20:52  *** jannes has joined #bitcoin-core-dev
 822016-10-06T08:21:46  *** h1d has quit IRC
 832016-10-06T08:28:59  *** mrkent has quit IRC
 842016-10-06T08:29:54  *** mrkent has joined #bitcoin-core-dev
 852016-10-06T08:55:11  *** Alopex has quit IRC
 862016-10-06T08:56:17  *** Alopex has joined #bitcoin-core-dev
 872016-10-06T09:04:26  *** arowser has quit IRC
 882016-10-06T09:04:41  *** arowser has joined #bitcoin-core-dev
 892016-10-06T09:05:18  *** mkarrer has quit IRC
 902016-10-06T09:05:19  *** mkarrer_ has joined #bitcoin-core-dev
 912016-10-06T09:09:43  *** rexnsh has quit IRC
 922016-10-06T09:09:44  *** rexnsh has joined #bitcoin-core-dev
 932016-10-06T09:46:39  *** GAit has joined #bitcoin-core-dev
 942016-10-06T09:55:19  *** GAit1 has joined #bitcoin-core-dev
 952016-10-06T09:58:06  *** GAit has quit IRC
 962016-10-06T09:58:15  <NicolasDorier> roasbeef: You can now measure your size https://testnet.smartbit.com.au/block/0000000000001280a3d758cb956e565daffd5af0e6b6723f28e1cbcda0da8652 ;)
 972016-10-06T09:59:26  *** shesek has quit IRC
 982016-10-06T10:00:38  <btcdrak> ah, great it's been made segwitty
 992016-10-06T10:02:56  *** GAit1 has quit IRC
1002016-10-06T10:05:07  *** shesek has joined #bitcoin-core-dev
1012016-10-06T10:11:22  *** AaronvanW has quit IRC
1022016-10-06T10:14:55  *** shesek has quit IRC
1032016-10-06T10:29:53  *** AaronvanW has joined #bitcoin-core-dev
1042016-10-06T10:30:14  *** aalex_ has quit IRC
1052016-10-06T10:30:53  *** aalex__ has joined #bitcoin-core-dev
1062016-10-06T10:34:39  *** DigiByteDev has quit IRC
1072016-10-06T11:04:40  *** cdecker has joined #bitcoin-core-dev
1082016-10-06T11:08:39  *** GAit has joined #bitcoin-core-dev
1092016-10-06T11:19:03  *** laurentmt has joined #bitcoin-core-dev
1102016-10-06T11:19:12  *** laurentmt has quit IRC
1112016-10-06T11:23:15  *** DigiByteDev has joined #bitcoin-core-dev
1122016-10-06T11:39:18  *** cryptapus has joined #bitcoin-core-dev
1132016-10-06T11:39:18  *** cryptapus has joined #bitcoin-core-dev
1142016-10-06T11:46:08  *** arowser has quit IRC
1152016-10-06T11:47:43  *** arowser has joined #bitcoin-core-dev
1162016-10-06T12:14:49  *** laurentmt has joined #bitcoin-core-dev
1172016-10-06T12:17:06  *** laurentmt has quit IRC
1182016-10-06T12:23:36  *** murch has joined #bitcoin-core-dev
1192016-10-06T12:31:19  *** waxwing has joined #bitcoin-core-dev
1202016-10-06T12:32:57  *** jnewbery has joined #bitcoin-core-dev
1212016-10-06T12:36:20  *** meowzus has joined #bitcoin-core-dev
1222016-10-06T12:36:43  *** Ylbam has quit IRC
1232016-10-06T12:36:44  *** jl2012 has quit IRC
1242016-10-06T12:39:38  *** Ylbam has joined #bitcoin-core-dev
1252016-10-06T12:41:03  *** laurentmt has joined #bitcoin-core-dev
1262016-10-06T12:41:36  *** jl2012 has joined #bitcoin-core-dev
1272016-10-06T13:03:49  *** laurentmt has quit IRC
1282016-10-06T13:28:38  *** GAit has quit IRC
1292016-10-06T13:29:59  *** GAit has joined #bitcoin-core-dev
1302016-10-06T13:32:42  *** jtimon has joined #bitcoin-core-dev
1312016-10-06T13:42:02  *** Evel-Knievel has quit IRC
1322016-10-06T13:45:53  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1332016-10-06T13:53:41  *** rubensayshi has quit IRC
1342016-10-06T13:58:25  *** GAit has quit IRC
1352016-10-06T14:09:29  *** instagibbs has joined #bitcoin-core-dev
1362016-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.
1372016-10-06T14:24:41  <sipa> morcos: i don't think there is doubt that it's better :)
1382016-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)
1392016-10-06T14:25:57  <jeremyrubin> wumpus: it wasn't a serious suggestion ;)
1402016-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.
1412016-10-06T14:26:10  *** Giszmo has joined #bitcoin-core-dev
1422016-10-06T14:26:19  <morcos> the fact that we delete sigs that were in blocks makes a HUGE difference
1432016-10-06T14:26:33  <sipa> morcos: yes... but we should know how it behaves in case of an attack as well
1442016-10-06T14:26:46  <sipa> without attack, i expect the size of the cache to not even matter that much
1452016-10-06T14:26:52  <sipa> as we'll only ever have live entries in it
1462016-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
1472016-10-06T14:27:33  <sipa> morcos: ha, the old rolling bloom filter design :)
1482016-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)
1492016-10-06T14:27:48  <sipa> right
1502016-10-06T14:27:54  <morcos> sipa: yeah i just didn't think it was worth the complication for the first PR
1512016-10-06T14:28:01  <sipa> morcos: completely agreed
1522016-10-06T14:28:26  * sipa just hopes 0.13.1 is out the door soon
1532016-10-06T14:28:43  <jeremyrubin> generations are better than rolling I think
1542016-10-06T14:28:53  <sipa> jeremyrubin: yes, i think so
1552016-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
1562016-10-06T14:29:45  <sipa> using two staggered sets effectively makes your entries twice the size
1572016-10-06T14:29:55  <sipa> or even 4 times
1582016-10-06T14:30:13  <morcos> sure, sounds good to me too
1592016-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
1602016-10-06T14:30:35  <jeremyrubin> Also fee is maybe even better than generations
1612016-10-06T14:31:00  <sipa> use an ARC :)
1622016-10-06T14:31:09  <jeremyrubin> You can also emulate generations
1632016-10-06T14:31:34  <jeremyrubin> by createnewblocking a 10mb block or something from mempool
1642016-10-06T14:31:40  <jeremyrubin> after deleting a bunch of things randomly
1652016-10-06T14:31:52  <jeremyrubin> if you want 0 memory overhead
1662016-10-06T14:31:55  <sipa> https://en.wikipedia.org/wiki/Adaptive_replacement_cache
1672016-10-06T14:32:10  <jeremyrubin> sipa: ah, not automatic reference counting
1682016-10-06T14:32:43  <jeremyrubin> ARC seems not to work for this use case?
1692016-10-06T14:32:49  <jeremyrubin> Things are write once read once?
1702016-10-06T14:33:10  <sipa> ah, i'm confusing with the coin cache
1712016-10-06T14:53:50  *** limpkin has quit IRC
1722016-10-06T14:54:19  *** wallet42 has quit IRC
1732016-10-06T14:54:51  *** aalex has quit IRC
1742016-10-06T14:55:54  *** michagogo has quit IRC
1752016-10-06T14:59:35  *** AaronvanW has quit IRC
1762016-10-06T15:06:20  *** Chris_Stewart_5 has quit IRC
1772016-10-06T15:13:12  *** michagogo has joined #bitcoin-core-dev
1782016-10-06T15:34:22  *** wallet42 has joined #bitcoin-core-dev
1792016-10-06T15:35:10  *** aalex has joined #bitcoin-core-dev
1802016-10-06T15:35:16  *** limpkin has joined #bitcoin-core-dev
1812016-10-06T15:46:15  *** laurentmt has joined #bitcoin-core-dev
1822016-10-06T15:49:20  *** mrkent has quit IRC
1832016-10-06T15:53:26  *** laurentmt has quit IRC
1842016-10-06T15:59:38  *** jnewbery has quit IRC
1852016-10-06T16:00:11  *** jnewbery has joined #bitcoin-core-dev
1862016-10-06T16:04:56  *** jnewbery has quit IRC
1872016-10-06T16:11:41  *** droark has joined #bitcoin-core-dev
1882016-10-06T16:15:41  *** DigiByteDev has quit IRC
1892016-10-06T16:21:31  *** jnewbery has joined #bitcoin-core-dev
1902016-10-06T16:38:50  *** cchadwicka1 has joined #bitcoin-core-dev
1912016-10-06T16:40:10  *** spudowiar has joined #bitcoin-core-dev
1922016-10-06T16:56:54  *** paveljanik has joined #bitcoin-core-dev
1932016-10-06T16:56:54  *** paveljanik has joined #bitcoin-core-dev
1942016-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.
1952016-10-06T17:07:17  <gmaxwell> I'm surprised it didn't bencmark out as faster with only a single thread.
1962016-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.
1972016-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..   :)
1982016-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.
1992016-10-06T17:13:08  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2002016-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.
2012016-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.
2022016-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.
2032016-10-06T17:18:53  *** Chris_Stewart_5 has quit IRC
2042016-10-06T17:22:21  *** laurentmt has joined #bitcoin-core-dev
2052016-10-06T17:26:04  *** laurentmt has quit IRC
2062016-10-06T17:45:13  <gmaxwell> I wish we could easily delete based on an entry being in the top of the mempool or not.
2072016-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.
2082016-10-06T17:45:50  <gmaxwell> that would be kinda like that.
2092016-10-06T17:46:32  <gmaxwell> or insert things with a lower feerate 1 or two generations behind the current generation. (assuming many generations)
2102016-10-06T17:50:39  <michagogo> Today's lesson in my programming lessons: threading is hard
2112016-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
2122016-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.
2132016-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)
2142016-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
2152016-10-06T17:52:19  <michagogo> (or rather, reused for the next iteration)
2162016-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.
2172016-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..
2182016-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.
2192016-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
2202016-10-06T17:59:07  *** cdecker has quit IRC
2212016-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
2222016-10-06T18:00:06  <gmaxwell> hm. why was the existing algo lower?
2232016-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
2242016-10-06T18:00:12  *** [b__b] has quit IRC
2252016-10-06T18:00:22  *** cdecker has joined #bitcoin-core-dev
2262016-10-06T18:00:28  <morcos> gmaxwell: primarily because you can cram more signatures in 40MB with the new design
2272016-10-06T18:00:31  *** [b__b] has joined #bitcoin-core-dev
2282016-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
2292016-10-06T18:00:52  <gmaxwell> Makes sense.
2302016-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.
2312016-10-06T18:01:42  <gmaxwell> not good for network convergence for reorg to be much slower.
2322016-10-06T18:02:01  <morcos> gmaxwell: heh, probably MANY things to improve there
2332016-10-06T18:02:18  <gmaxwell> yes. but any improvement is good. :)
2342016-10-06T18:03:02  <gmaxwell> I'd take a wag that the validation performance limiter is now the additional sha256 used in the lookup.
2352016-10-06T18:06:06  *** cchadwicka1 has quit IRC
2362016-10-06T18:07:56  *** cchadwicka has joined #bitcoin-core-dev
2372016-10-06T18:08:07  *** jnewbery has quit IRC
2382016-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
2392016-10-06T18:08:27  *** Frederic94500 has joined #bitcoin-core-dev
2402016-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.
2412016-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
2422016-10-06T18:10:31  *** cchadwicka1 has joined #bitcoin-core-dev
2432016-10-06T18:10:38  <gmaxwell> well BIP152 allows you to send the block before its verified.
2442016-10-06T18:10:52  <gmaxwell> so that would be an obvious thing to actually do.
2452016-10-06T18:11:46  <morcos> sure.  same issue still applies though.  you're just deciding to send it earlier.
2462016-10-06T18:12:16  *** cchadwicka1 has quit IRC
2472016-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)
2482016-10-06T18:13:01  *** cchadwicka has quit IRC
2492016-10-06T18:13:06  <sdaftuar> that's basically what i was planning to do
2502016-10-06T18:13:37  <gmaxwell> well it gets the whole validation process out of that critical path.
2512016-10-06T18:14:11  *** cchadwicka has joined #bitcoin-core-dev
2522016-10-06T18:14:47  *** cchadwicka has quit IRC
2532016-10-06T18:16:42  *** cchadwicka has joined #bitcoin-core-dev
2542016-10-06T18:20:41  *** cchadwicka1 has joined #bitcoin-core-dev
2552016-10-06T18:21:35  *** cchadwicka has quit IRC
2562016-10-06T18:29:59  *** laurentmt has joined #bitcoin-core-dev
2572016-10-06T18:30:50  *** laurentmt has quit IRC
2582016-10-06T18:34:32  *** laurentmt has joined #bitcoin-core-dev
2592016-10-06T18:40:08  *** spudowiar has quit IRC
2602016-10-06T18:52:42  *** Frederic94500 has quit IRC
2612016-10-06T18:55:00  *** Guyver2 has quit IRC
2622016-10-06T18:57:36  *** Guyver2 has joined #bitcoin-core-dev
2632016-10-06T19:01:14  *** cchadwicka1 has quit IRC
2642016-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)
2652016-10-06T19:02:19  *** laurentmt has quit IRC
2662016-10-06T19:14:42  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2672016-10-06T19:18:31  *** MarcoFalke has left #bitcoin-core-dev
2682016-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)
2692016-10-06T19:22:42  *** Frederic94500 has joined #bitcoin-core-dev
2702016-10-06T19:29:12  *** Frederic94500 has quit IRC
2712016-10-06T19:36:56  *** cdecker has quit IRC
2722016-10-06T19:54:25  *** cryptapus has quit IRC
2732016-10-06T19:54:38  *** drnet has joined #bitcoin-core-dev
2742016-10-06T19:57:58  *** drnet has quit IRC
2752016-10-06T20:01:53  *** jtimon has quit IRC
2762016-10-06T20:14:15  *** JackH has joined #bitcoin-core-dev
2772016-10-06T20:14:35  *** e4xit has quit IRC
2782016-10-06T20:22:08  *** JackH has quit IRC
2792016-10-06T20:28:03  *** cjcj has quit IRC
2802016-10-06T20:28:50  *** bsm117532 has quit IRC
2812016-10-06T20:29:39  *** Chris_Stewart_5 has quit IRC
2822016-10-06T20:34:02  *** GAit has joined #bitcoin-core-dev
2832016-10-06T20:35:22  *** GAit has quit IRC
2842016-10-06T20:39:21  *** timothy has quit IRC
2852016-10-06T20:39:23  *** drizztbsd has joined #bitcoin-core-dev
2862016-10-06T20:39:56  *** drizztbsd is now known as timothy
2872016-10-06T20:44:50  *** instagibbs has quit IRC
2882016-10-06T20:45:53  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2892016-10-06T20:47:18  *** instagibbs has joined #bitcoin-core-dev
2902016-10-06T20:58:32  *** JackH has joined #bitcoin-core-dev
2912016-10-06T21:01:53  *** HG has joined #bitcoin-core-dev
2922016-10-06T21:03:06  *** Fonslls has joined #bitcoin-core-dev
2932016-10-06T21:42:59  *** Guyver2 has quit IRC
2942016-10-06T21:55:14  *** cdecker has joined #bitcoin-core-dev
2952016-10-06T21:57:39  *** mrkent has joined #bitcoin-core-dev
2962016-10-06T22:01:01  *** timothy has quit IRC
2972016-10-06T22:01:04  *** drizztbsd has joined #bitcoin-core-dev
2982016-10-06T22:01:37  *** drizztbsd is now known as timothy
2992016-10-06T22:12:39  *** mrkent has quit IRC
3002016-10-06T22:39:13  *** jannes has quit IRC
3012016-10-06T22:48:42  *** GAit has joined #bitcoin-core-dev
3022016-10-06T22:52:37  *** GAit1 has joined #bitcoin-core-dev
3032016-10-06T22:55:21  *** GAit1 has quit IRC
3042016-10-06T22:56:54  *** GAit has quit IRC
3052016-10-06T23:05:13  *** Evel-Knievel has joined #bitcoin-core-dev
3062016-10-06T23:15:42  *** murch has quit IRC
3072016-10-06T23:43:16  *** PRab has quit IRC