12016-06-25T00:01:25 <randy-waterhouse> ok, another 'devil's advocate' tester on-board segwit test smoothly ... thnx gmaxwell, sipa wumpus, etc ... and many others, good job.
22016-06-25T00:04:54 <Lauda> Does the dbcache=N parameter only start using up additional memory during block processing?
32016-06-25T00:05:54 <gmaxwell> Lauda: I think what you're asking is if it will use it right away, no it won't-- only has there is more data read into the cache
42016-06-25T00:06:27 <Lauda> gmaxwell all that is required is "dbcache=3000" in bitcoin.conf right (since mine is practically empty) and I want to run another reindex over night?
52016-06-25T00:06:40 <Lauda> since*
62016-06-25T00:06:42 <gmaxwell> right!
72016-06-25T00:06:48 <Lauda> Okay great. Thanks!
82016-06-25T00:07:25 <Lauda> The reindex issue is indepdant of the blockchain, i.e. it doesn't matter whether one tests on testnet or mainnet (someone asked me this)?
92016-06-25T00:07:31 <Lauda> independant*
102016-06-25T00:16:07 *** Chris_Stewart_5 has quit IRC
112016-06-25T00:16:25 <midnightmagic> i can convert my testnet node(s) to segwitty. is it time?
122016-06-25T00:24:16 *** murch has quit IRC
132016-06-25T00:38:31 *** Giszmo has quit IRC
142016-06-25T02:35:05 *** molz has joined #bitcoin-core-dev
152016-06-25T02:38:03 *** moli has quit IRC
162016-06-25T02:44:08 *** justanotheruser has quit IRC
172016-06-25T02:46:13 *** justanotheruser has joined #bitcoin-core-dev
182016-06-25T03:19:55 *** raedah has quit IRC
192016-06-25T03:36:47 <jl2012> What would happen if I upgrade my node after segwit is active and there are already segwit blocks on the chain?
202016-06-25T03:45:13 *** raedah has joined #bitcoin-core-dev
212016-06-25T04:02:52 *** nickler_ has quit IRC
222016-06-25T04:05:12 *** jtimon has quit IRC
232016-06-25T04:11:16 *** randy-waterhouse has quit IRC
242016-06-25T04:15:50 *** randy-waterhouse has joined #bitcoin-core-dev
252016-06-25T04:16:16 *** nickler has joined #bitcoin-core-dev
262016-06-25T04:19:18 *** GreenParhelia has joined #bitcoin-core-dev
272016-06-25T04:21:44 *** nickler has quit IRC
282016-06-25T04:27:49 *** AndChat563604 has joined #bitcoin-core-dev
292016-06-25T04:29:29 *** AndChat563604 has joined #bitcoin-core-dev
302016-06-25T04:33:24 *** randy-waterhouse has quit IRC
312016-06-25T04:36:42 *** AndChat563604 has quit IRC
322016-06-25T04:46:13 *** nickler has joined #bitcoin-core-dev
332016-06-25T04:51:51 *** nickler has quit IRC
342016-06-25T05:04:21 *** Alopex has quit IRC
352016-06-25T05:05:27 *** Alopex has joined #bitcoin-core-dev
362016-06-25T05:16:11 *** nickler has joined #bitcoin-core-dev
372016-06-25T05:26:51 *** adamg has quit IRC
382016-06-25T05:41:15 *** frankenmint has joined #bitcoin-core-dev
392016-06-25T05:47:06 *** Alopex has quit IRC
402016-06-25T05:48:12 *** Alopex has joined #bitcoin-core-dev
412016-06-25T06:21:40 <GitHub136> [bitcoin] paveljanik opened pull request #8261: The bit field is shown only when status is "started" (master...20160625_sw_getblockchaininfo_bit) https://github.com/bitcoin/bitcoin/pull/8261
422016-06-25T06:30:51 <gmaxwell> jl2012: it reorgs back to before segwit activated.
432016-06-25T06:31:06 <gmaxwell> jl2012: then will download blocks as needed.
442016-06-25T06:32:48 <jl2012> Same for other soft forks like csv?
452016-06-25T06:33:01 <jl2012> I think it has to be
462016-06-25T06:33:53 <gmaxwell> jl2012: it arguably should be, but we haven't done that before.
472016-06-25T06:34:09 <gmaxwell> for segwit it had to go get the witness data in order to serve blocks
482016-06-25T06:34:46 <gmaxwell> we'd talked about doing it in the past for other soft forks but I think we thought it would be harder to implement than it turned out to be.
492016-06-25T06:35:40 <gmaxwell> (and unlikely to really matter that much unless the reason you were upgrading was to fight a network split, in which case the invalidateblock rpc can be used)
502016-06-25T06:36:36 <jl2012> But theoretically I may be following an invalid chain
512016-06-25T06:41:31 <gmaxwell> Potentially; though if there were a large invalid chain we would make loud announcements to recommend the use of the invalidateblock command. I think now that the code exists, we'd likely use it in the future.
522016-06-25T06:43:36 *** frankenm_ has joined #bitcoin-core-dev
532016-06-25T06:44:54 *** frankenmint has quit IRC
542016-06-25T07:16:51 *** Inaltoas1nistra has joined #bitcoin-core-dev
552016-06-25T07:17:15 *** Inaltoasinistra has quit IRC
562016-06-25T07:21:08 *** Guyver2 has joined #bitcoin-core-dev
572016-06-25T07:47:03 *** frankenm_ has quit IRC
582016-06-25T07:54:20 <wumpus> segwit testnet node: 213.46.222.31:18333
592016-06-25T07:55:49 *** frankenmint has joined #bitcoin-core-dev
602016-06-25T08:06:48 *** frankenmint has quit IRC
612016-06-25T08:07:16 *** frankenmint has joined #bitcoin-core-dev
622016-06-25T08:28:42 *** frankenmint has quit IRC
632016-06-25T08:30:14 *** frankenmint has joined #bitcoin-core-dev
642016-06-25T08:31:44 *** frankenm_ has joined #bitcoin-core-dev
652016-06-25T08:31:44 *** frankenmint has quit IRC
662016-06-25T08:33:32 *** frankenmint has joined #bitcoin-core-dev
672016-06-25T08:36:34 *** frankenm_ has quit IRC
682016-06-25T08:39:16 *** frankenmint has quit IRC
692016-06-25T08:39:22 *** frankenmint has joined #bitcoin-core-dev
702016-06-25T08:39:49 *** frankenmint has quit IRC
712016-06-25T08:40:22 *** frankenmint has joined #bitcoin-core-dev
722016-06-25T08:43:38 *** frankenmint has quit IRC
732016-06-25T08:43:56 *** frankenmint has joined #bitcoin-core-dev
742016-06-25T08:56:19 *** GreenParhelia_1 has joined #bitcoin-core-dev
752016-06-25T08:59:34 *** GreenParhelia has quit IRC
762016-06-25T09:19:38 *** arubi has quit IRC
772016-06-25T09:22:32 *** Guyver2 has quit IRC
782016-06-25T09:22:56 *** frankenmint has quit IRC
792016-06-25T09:26:40 *** frankenmint has joined #bitcoin-core-dev
802016-06-25T09:31:28 *** frankenmint has quit IRC
812016-06-25T09:34:14 *** murch has joined #bitcoin-core-dev
822016-06-25T10:02:08 *** arubi has joined #bitcoin-core-dev
832016-06-25T10:23:52 <Lauda> What is the main bottleneck for reindex, storage speed or CPU processing?
842016-06-25T10:26:59 *** GreenParhelia_1 has quit IRC
852016-06-25T10:29:25 <gmaxwell> probably depends on the hardware, on my laptop I think it's IO. on systems with faster IO, I think its cpu inside leveldb code... at least with default dbcache. with dbcache cranked, its likely cpu elsewhere in bitcoin.
862016-06-25T10:30:20 <Lauda> Hmm, seems like the last 20-30 weeks are taking forever
872016-06-25T10:30:43 <wumpus> Lauda: unless you have a very fast disk/ssd, or increase the dbcache, i/o will be your main bottleneck
882016-06-25T10:30:58 <Lauda> I've just checked in on my node, and some bans say e.g. until June 19th but the nodes are still banned. Do these get removed after a restart or something went wrong?
892016-06-25T10:30:59 <wumpus> Lauda: you can easily check though: is CPU maxed out?
902016-06-25T10:31:06 <Lauda> It isn't
912016-06-25T10:31:23 <Lauda> DBcache 3GB
922016-06-25T10:31:40 <wumpus> (unless you have changed the number of script verification threads, bitcoind will max out your CPU cores in initial sync when it's not i/o bound)
932016-06-25T10:32:47 <Lauda> Okay so even with 3GB dbcache that's still not enough
942016-06-25T10:33:05 <wumpus> I have a branch to run bitcoind db-less: https://github.com/laanwj/bitcoin/tree/2016_04_dummy_db it does mean it loses all data when e.g. bitcoind crashes
952016-06-25T10:34:48 <wumpus> but the utxo and block index is simply stored in a flat file, which is loaded at startup and written at shutdown
962016-06-25T10:35:02 <Lauda> That's interesting and those times are amazing in comparison to leveldb
972016-06-25T10:35:13 <wumpus> if you can afford the memory :)
982016-06-25T10:35:58 <wumpus> though it uses less memory than keeping everyting in the dbcache, and doesn't have the issue that the cache is not seeded at startup
992016-06-25T10:37:15 <wumpus> I think research and experimentaitno how to best store the utxo set is in order
1002016-06-25T10:38:06 <Lauda> The move towards SSDs should definitely help with this, but the industry is not there yet..
1012016-06-25T10:38:44 <Lauda> I can afford 4 GB on this machine, but it still takes a fair amount of time.
1022016-06-25T10:39:31 <wumpus> memristor would be nice
1032016-06-25T10:40:23 <wumpus> but no matter what, also at some point, unrestrained growth of the utxo set needs to be addressed
1042016-06-25T10:40:54 <Lauda> ^
1052016-06-25T10:45:23 <sipa> wumpus: we should try switching to a model where all utxos are stored as separate db entries, rather than in a vector of unspends per txid
1062016-06-25T10:46:48 <wumpus> but it may well be we're running against the limits of what databases can (with good performance) handle, which means there is no room for scaling there at all
1072016-06-25T10:47:33 <gmaxwell> gigantic cuckoo hash table. with a update log. :P
1082016-06-25T10:47:35 <wumpus> sipa: yes, that would be an interesting experiment too
1092016-06-25T10:48:26 <wumpus> also the access pattern is essentially random, so the only type of caching that helps very well is keep everything
1102016-06-25T10:48:42 <gmaxwell> sipa: the ripple people have claimed that leveldb performance falls off a cliff with more than some threshold number of entries (I believe they were storing every transaction in it)
1112016-06-25T10:49:20 <sipa> gmaxwell: i think they don't have application level caching
1122016-06-25T10:49:30 <wumpus> well I'm not actually sure how random the access pattern is, but it looks like that from a disk perspective with the current organization
1132016-06-25T10:49:57 <wumpus> it's very possible for optimizations to be possible based on sorting utxos smartly which are expected to be accessed together? I don't know
1142016-06-25T10:50:18 <gmaxwell> sipa: sure, but that wouldn't change the performance of the underlying database.
1152016-06-25T10:50:34 <wumpus> it's not like the other databases that we tried perfomed better
1162016-06-25T10:50:48 <wumpus> leveldb still seems, all in all, the best perforing on-disk database for utxo storage
1172016-06-25T10:51:03 <gmaxwell> Ripple folks created their own.
1182016-06-25T10:51:17 <gmaxwell> (and also suggested we might be interested in using it)
1192016-06-25T10:51:22 <wumpus> lmdb looked promising but it has it's own performance cliff
1202016-06-25T10:51:31 <wumpus> (depending on the amount of memory in the system, it seems)
1212016-06-25T10:51:59 <wumpus> what license is it under?
1222016-06-25T10:52:56 <wumpus> I could give it a try pretty easily
1232016-06-25T10:53:03 <GitHub74> [bitcoin] btccode opened pull request #8262: Forgetaddress 0.12 (0.12...forgetaddress-0.12) https://github.com/bitcoin/bitcoin/pull/8262
1242016-06-25T10:53:46 <gmaxwell> I think it's permissively licensed, looking for it now
1252016-06-25T10:53:55 <GitHub2> [bitcoin] btccode closed pull request #8262: Forgetaddress 0.12 (0.12...forgetaddress-0.12) https://github.com/bitcoin/bitcoin/pull/8262
1262016-06-25T10:54:42 <sipa> gmaxwell: well is it read performance or write performance that is bad?
1272016-06-25T10:55:40 <wumpus> with leveldb it's read performance, and also latency
1282016-06-25T10:56:22 <wumpus> write performance of leveldb is quite good, I suppose because it writes consecutive files
1292016-06-25T10:56:57 <gmaxwell> https://bitcointalk.org/index.php?topic=1004943.0
1302016-06-25T10:56:59 <wumpus> but no database likes huge databases + random seek patterns for reads
1312016-06-25T10:57:52 <wumpus> https://github.com/vinniefalco/nudb
1322016-06-25T10:57:55 <gmaxwell> (thats why I made the half serious suggestion of a gigantic hash table)
1332016-06-25T10:58:55 <wumpus> lmdb read latency seems to be - on average- better, but its writing is worse than leveldb, I think it does more random writing
1342016-06-25T10:59:45 <GitHub121> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5cdc54b4b62d...63fbdbc94d76
1352016-06-25T10:59:45 <GitHub121> bitcoin/master b0be3a0 Wladimir J. van der Laan: doc: Mention Windows XP end of support in release notes...
1362016-06-25T10:59:46 <GitHub121> bitcoin/master 63fbdbc Wladimir J. van der Laan: Merge #8240: doc: Mention Windows XP end of support in release notes...
1372016-06-25T10:59:50 <GitHub49> [bitcoin] laanwj closed pull request #8240: doc: Mention Windows XP end of support in release notes (master...2016_06_windows_xp) https://github.com/bitcoin/bitcoin/pull/8240
1382016-06-25T11:00:09 <gmaxwell> as every read would simply be one or two random disk accesses... and its hard to do better than that. it's just writing is awful. (e.g. end up with read-write-write to update a log, with both sequential reads and writes, and if the table needs to be resized woe is you).
1392016-06-25T11:00:40 <wumpus> going to try nudb when I have some time
1402016-06-25T11:01:16 <wumpus> unfortunately we also do a lot of writing, at least during initial sync, every utxo read is updated and written back
1412016-06-25T11:01:35 <wumpus> so making reading much faster at the expense of writing is going to give yo mixed results
1422016-06-25T11:02:52 <wumpus> has research been done on utxo access patterns? e.g. are more recent blocks more often accessed, or the other way around, or are there other regularities that could be used?
1432016-06-25T11:04:10 <gmaxwell> Spending is more freuqntly from recently created utxo.
1442016-06-25T11:04:54 <wumpus> interesting
1452016-06-25T11:06:14 <gmaxwell> I would expect naievely that the expected lifetime of a utxo is how long it's lived so far. If something had made it a year without being spent, you should expect it to last another year. But beyond knowing that an unusually large number of utxo have short lives, I've not done anything to try to verify this hypothesis.
1462016-06-25T11:07:32 <gmaxwell> we could probably construct fairly elaborate predictions using other features like how many txouts were in the creating transactions, reuse of the pubkey, and the amount of the coin.
1472016-06-25T11:10:16 <gmaxwell> (or even using non-fungibility-- a coin is likely to be spent soon if its recent ancestors were spent soon)
1482016-06-25T11:10:55 <sipa> wumpus: that's why the "fresh" optimization helps a lot... we create utxo entries indide the database, and fully spend them before they even hit disk
1492016-06-25T11:11:06 <sipa> s/inside the database/inside the cache/
1502016-06-25T11:11:41 <gmaxwell> with the cache turned way up, the whole initial sync runs without writing the chainstate until the end.
1512016-06-25T11:14:26 <gmaxwell> oh, seems nudb is a big hashtable (uses external storage for values)
1522016-06-25T11:14:42 <sipa> it keeps the entire keyset in memory?
1532016-06-25T11:15:10 <gmaxwell> no, the keys are an a file. sounds like it's chunked so it can independantly resize sub tables.
1542016-06-25T11:20:27 <wumpus> isn't the fact that nudb is insert-only a problem? we delete and change entries a lot
1552016-06-25T11:22:51 <wumpus> gmaxwell: would be a good research project to investigate that hypothesis in detail, and see if it is possible to optimize storage based on those predictions/assumptions. Maybe one huge key/value store is not the best way to handle this
1562016-06-25T11:23:00 <gmaxwell> hm. I thought it could delete keys but not the values in external storage.
1572016-06-25T11:24:28 <gmaxwell> Oh I see what you mean there... I hadn't caught that implication before.. that effect is more or less why caching smaller than the utxo set in memory is still effective, but depending on the geometry of the effect it might make sense to have two databases.. so that the high access parts are in something with low log(n) costs.
1582016-06-25T11:29:44 <gmaxwell> LOL, totally offtopic: https://lkml.org/lkml/2016/3/31/1109
1592016-06-25T11:30:57 <btcdrak> inb4 linus splats him
1602016-06-25T11:35:47 <gmaxwell> it's old, just turned up in a random google search
1612016-06-25T11:36:07 <btcdrak> oh it's an april fool!
1622016-06-25T11:38:47 <Lauda> Error reading from database, shutting down 15 weeks left :<
1632016-06-25T11:39:22 <Lauda> I think I can still get detect results if I test another version and break at 15 weeks left?
1642016-06-25T11:39:25 <Lauda> decent*
1652016-06-25T11:42:40 <gmaxwell> do you know why it failed?
1662016-06-25T11:42:57 <gmaxwell> if you're benchmarking you can just compare to a common height.
1672016-06-25T11:43:04 <gmaxwell> e.g. use the timestamps in the log
1682016-06-25T11:44:11 <Lauda> I can't be sure. It's possible that my HDD disconnected for a second (the cable seems a bit unstable if touched).
1692016-06-25T11:44:39 <spudowiar> Lauda: check dmesg for I/O errors?
1702016-06-25T11:45:18 <Lauda> Okay then, I'll compare the timestamp of the same height. Running a test on a revision before the reindex changes now
1712016-06-25T11:45:32 <Lauda> I'll check system error log (these tests are on Windows not Unix).
1722016-06-25T11:47:57 <Lauda> http://pastebin.com/Zau75AHY it doesn't tell me much.
1732016-06-25T12:36:32 <sipa> Lauda: you have debug.log.
1742016-06-25T12:36:34 <sipa> ?
1752016-06-25T12:36:40 <Lauda> Yes
1762016-06-25T12:38:47 <Lauda> The last entry is just an UpdateTip.
1772016-06-25T12:39:29 <Lauda> Comparing the partial data shows that re-index is much faster on the newer version than one before the re-index changes (at least on custom dbcache).
1782016-06-25T12:42:26 <sipa> yes, for a fair comparison you need to disable checkpoints
1792016-06-25T12:42:43 <sipa> before the reindex changes, signatures were always checked
1802016-06-25T12:42:57 <Lauda> How do I disable checkpoints?
1812016-06-25T12:43:02 <sipa> after thry're only checked past the last checkpoints
1822016-06-25T12:43:09 <sipa> -nocheckpoints i think
1832016-06-25T12:43:38 <Lauda> So I should delete this data (version before re-index changes) and run it again with that flag?
1842016-06-25T12:47:08 <MarcoFalke> no need to delete data
1852016-06-25T12:47:51 <Lauda> It's still re-indexing the build from 16-05.
1862016-06-25T12:48:18 <sipa> you can start over
1872016-06-25T12:48:50 <Lauda> How would I add that within the .conf file?
1882016-06-25T12:49:18 <sipa> checkpoints=0
1892016-06-25T12:49:28 <sipa> or nocheckpoints=1
1902016-06-25T12:52:02 <sipa> but please consult the help
1912016-06-25T12:52:06 <sipa> (bitcoind -help)
1922016-06-25T12:55:54 <Lauda> Okay thanks!
1932016-06-25T13:07:58 *** Giszmo has joined #bitcoin-core-dev
1942016-06-25T13:12:24 <Lauda> sipa is it normal that the wallet shows weird/non-existing transactions (date-wise) during reindex?
1952016-06-25T13:14:11 <sipa> example?
1962016-06-25T13:14:25 <Lauda> http://i.imgur.com/J7YeKdu.png
1972016-06-25T13:14:54 <Lauda> e0a871f4897af619c4e0d8ab91d6c6f81e25d23f4dea421439b60e9c9dd8cb83
1982016-06-25T13:15:00 <Lauda> Received Time 2015-09-09 20:57:49
1992016-06-25T13:15:04 <Lauda> wallet shows yesterday
2002016-06-25T13:15:45 <Lauda> I don't even recognize these transactions, a (big) list of microtransactions (incoming and outgoing) for 24/06
2012016-06-25T13:18:30 <sipa> heh
2022016-06-25T13:18:40 <sipa> did you import some common brainwallet
2032016-06-25T13:19:03 <Lauda> No. I didn't do anything. I'm running this on my wallet machine (since my other one is down)
2042016-06-25T13:19:10 <Lauda> I have never used anything besides QT.
2052016-06-25T13:19:34 <Lauda> I think it wasn't showing on 24-06 nightly build.
2062016-06-25T13:20:05 <sipa> that seems unlikely :)
2072016-06-25T13:21:38 <Lauda> The dates seem correct for all transactions up to this point. There are surely a few hundred TX's stamped at this date now
2082016-06-25T13:21:39 <Lauda> Hmm..
2092016-06-25T13:23:18 <Lauda> My wallet.dat grew. I made a backup before I started reindex tests. It was ~400kb, now it is 4.6MB
2102016-06-25T13:32:50 *** harrymm has quit IRC
2112016-06-25T13:34:08 *** harrymm has joined #bitcoin-core-dev
2122016-06-25T13:38:37 *** harrymm has quit IRC
2132016-06-25T13:47:51 *** lightningbot has joined #bitcoin-core-dev
2142016-06-25T13:48:53 *** gmaxwell_ has joined #bitcoin-core-dev
2152016-06-25T13:48:53 *** trippysa1mon has joined #bitcoin-core-dev
2162016-06-25T13:49:16 *** gmaxwell_ is now known as Guest53903
2172016-06-25T13:50:43 *** lysobit_ has joined #bitcoin-core-dev
2182016-06-25T13:51:12 *** nsh has quit IRC
2192016-06-25T13:51:13 *** musalbas has quit IRC
2202016-06-25T13:51:13 *** ws2k3 has quit IRC
2212016-06-25T13:51:13 *** ws2k3_ has joined #bitcoin-core-dev
2222016-06-25T13:51:13 *** murch has quit IRC
2232016-06-25T13:51:14 *** NicolasDorier has quit IRC
2242016-06-25T13:51:14 *** hsmiths has quit IRC
2252016-06-25T13:51:15 *** CodeShark has quit IRC
2262016-06-25T13:51:15 *** gmaxwell has quit IRC
2272016-06-25T13:51:16 *** lesderid has quit IRC
2282016-06-25T13:51:16 *** trippysalmon has quit IRC
2292016-06-25T13:51:17 *** lclc has quit IRC
2302016-06-25T13:51:17 *** jonasschnelli has quit IRC
2312016-06-25T13:51:17 *** phantomcircuit has quit IRC
2322016-06-25T13:51:17 *** amiller has quit IRC
2332016-06-25T13:51:17 *** ryan-c has quit IRC
2342016-06-25T13:51:17 *** mturquette has quit IRC
2352016-06-25T13:51:18 *** BCBot has quit IRC
2362016-06-25T13:51:19 *** lysobit_ is now known as musalbas
2372016-06-25T13:51:49 *** NicolasDorier_ is now known as NicolasDorier
2382016-06-25T13:52:00 *** lesderid has joined #bitcoin-core-dev
2392016-06-25T13:52:14 *** phantomcircuit has joined #bitcoin-core-dev
2402016-06-25T13:52:44 *** murch has joined #bitcoin-core-dev
2412016-06-25T13:52:53 *** amiller_ has joined #bitcoin-core-dev
2422016-06-25T13:53:19 *** CodeShark_ is now known as CodeShark
2432016-06-25T13:53:38 *** lclc has joined #bitcoin-core-dev
2442016-06-25T13:54:04 *** jonasschnelli has joined #bitcoin-core-dev
2452016-06-25T13:54:53 *** harrymm has joined #bitcoin-core-dev
2462016-06-25T13:54:59 *** nsh has joined #bitcoin-core-dev
2472016-06-25T13:55:34 *** mturquette has joined #bitcoin-core-dev
2482016-06-25T13:57:06 *** spudowiar has quit IRC
2492016-06-25T13:58:04 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2502016-06-25T14:00:30 *** ryan-c has joined #bitcoin-core-dev
2512016-06-25T14:06:16 *** spudowiar has joined #bitcoin-core-dev
2522016-06-25T14:10:39 <GitHub165> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/63fbdbc94d76...1922e5a65458
2532016-06-25T14:10:39 <GitHub165> bitcoin/master 27f8126 Daniel Cousens: remove unnecessary LOCK(cs_main)
2542016-06-25T14:10:40 <GitHub165> bitcoin/master 1922e5a Wladimir J. van der Laan: Merge #8244: remove unnecessary LOCK(cs_main) in getrawpmempool...
2552016-06-25T14:10:49 <GitHub97> [bitcoin] laanwj closed pull request #8244: remove unnecessary LOCK(cs_main) in getrawpmempool (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8244
2562016-06-25T14:28:17 *** jtimon has joined #bitcoin-core-dev
2572016-06-25T14:31:31 *** arubi_ has joined #bitcoin-core-dev
2582016-06-25T14:31:33 *** arubi has quit IRC
2592016-06-25T14:31:47 *** arubi_ is now known as arubi
2602016-06-25T15:22:02 *** Ylbam has joined #bitcoin-core-dev
2612016-06-25T15:47:40 *** tucenaber_ has quit IRC
2622016-06-25T15:51:16 *** jtimon has quit IRC
2632016-06-25T15:51:37 *** jtimon has joined #bitcoin-core-dev
2642016-06-25T16:21:30 *** hsmiths2 has quit IRC
2652016-06-25T16:23:36 *** hsmiths has joined #bitcoin-core-dev
2662016-06-25T16:41:44 *** tucenaber has joined #bitcoin-core-dev
2672016-06-25T16:44:34 *** AtashiCon has quit IRC
2682016-06-25T17:20:36 *** Sosumi has joined #bitcoin-core-dev
2692016-06-25T17:48:39 *** bsm117532 has quit IRC
2702016-06-25T17:49:14 *** bsm1175321 has joined #bitcoin-core-dev
2712016-06-25T17:51:58 *** AtashiCon has joined #bitcoin-core-dev
2722016-06-25T18:08:22 *** Cory has quit IRC
2732016-06-25T18:10:24 *** Pasha has joined #bitcoin-core-dev
2742016-06-25T18:17:18 *** Pasha is now known as Cory
2752016-06-25T18:37:35 *** justanotheruser has quit IRC
2762016-06-25T18:40:22 *** justanotheruser has joined #bitcoin-core-dev
2772016-06-25T18:53:55 *** murch has quit IRC
2782016-06-25T18:59:05 *** raedah has quit IRC
2792016-06-25T19:19:12 *** raedah has joined #bitcoin-core-dev
2802016-06-25T19:19:20 *** molly has joined #bitcoin-core-dev
2812016-06-25T19:22:17 *** molz has quit IRC
2822016-06-25T19:22:38 *** moli has joined #bitcoin-core-dev
2832016-06-25T19:24:18 *** molly has quit IRC
2842016-06-25T19:26:17 *** raedah has quit IRC
2852016-06-25T19:37:46 <da2ce7_mobile> Well done! https://github.com/bitcoin/bitcoin 11,111 comments :)
2862016-06-25T19:39:40 *** Guyver2 has joined #bitcoin-core-dev
2872016-06-25T19:39:54 *** jtimon has quit IRC
2882016-06-25T19:40:05 *** jtimon has joined #bitcoin-core-dev
2892016-06-25T19:40:12 <sipa> *commits
2902016-06-25T19:43:16 *** Inaltoasinistra has joined #bitcoin-core-dev
2912016-06-25T19:44:40 *** Inaltoas1nistra has quit IRC
2922016-06-25T20:08:08 *** Giszmo has quit IRC
2932016-06-25T20:25:52 <spudowiar> No one is allowed to commit
2942016-06-25T20:26:03 <spudowiar> You must squash commits in order to add more
2952016-06-25T20:26:56 <spudowiar> Huh, it says 10,000 commits
2962016-06-25T20:27:00 <spudowiar> Not 11,111
2972016-06-25T20:28:28 *** Guest53903 has quit IRC
2982016-06-25T20:28:29 *** Guest53903 has joined #bitcoin-core-dev
2992016-06-25T20:28:44 *** Guest53903 is now known as gmaxwell
3002016-06-25T20:30:45 <da2ce7_mobile> oh spelling. oh well.
3012016-06-25T20:40:41 *** adamg has joined #bitcoin-core-dev
3022016-06-25T20:42:59 <spudowiar> da2ce7_mobile: you are a commit :)
3032016-06-25T20:43:27 <spudowiar> [da2ce7] Fix spelling mistakes
3042016-06-25T20:43:47 <spudowiar> Committer: spudowiar
3052016-06-25T21:38:06 *** grubles has quit IRC
3062016-06-25T21:53:59 *** grubles has joined #bitcoin-core-dev
3072016-06-25T22:14:00 *** shesek has quit IRC
3082016-06-25T22:28:51 *** Cory has quit IRC
3092016-06-25T22:31:34 *** Cory has joined #bitcoin-core-dev
3102016-06-25T22:39:16 *** Guyver2 has quit IRC
3112016-06-25T23:11:02 <GitHub41> [bitcoin] bitcoiner opened pull request #8264: src: Fix typo in comment - tinyformat.h (master...bitcoiner-fix-typo-tinyformat) https://github.com/bitcoin/bitcoin/pull/8264
3122016-06-25T23:43:13 <GitHub43> [bitcoin] bitcoiner opened pull request #8265: src: Fix spelling error in comment - netbase.h (master...bitcoiner-fix-typo-netbase) https://github.com/bitcoin/bitcoin/pull/8265