1 2016-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.
  2 2016-06-25T00:04:54  <Lauda> Does the dbcache=N parameter only start using up additional memory during block processing?
  3 2016-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
  4 2016-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?
  5 2016-06-25T00:06:40  <Lauda> since*
  6 2016-06-25T00:06:42  <gmaxwell> right!
  7 2016-06-25T00:06:48  <Lauda> Okay great. Thanks!
  8 2016-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)?
  9 2016-06-25T00:07:31  <Lauda> independant*
 10 2016-06-25T00:16:07  *** Chris_Stewart_5 has quit IRC
 11 2016-06-25T00:16:25  <midnightmagic> i can convert my testnet node(s) to segwitty. is it time?
 12 2016-06-25T00:24:16  *** murch has quit IRC
 13 2016-06-25T00:38:31  *** Giszmo has quit IRC
 14 2016-06-25T02:35:05  *** molz has joined #bitcoin-core-dev
 15 2016-06-25T02:38:03  *** moli has quit IRC
 16 2016-06-25T02:44:08  *** justanotheruser has quit IRC
 17 2016-06-25T02:46:13  *** justanotheruser has joined #bitcoin-core-dev
 18 2016-06-25T03:19:55  *** raedah has quit IRC
 19 2016-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?
 20 2016-06-25T03:45:13  *** raedah has joined #bitcoin-core-dev
 21 2016-06-25T04:02:52  *** nickler_ has quit IRC
 22 2016-06-25T04:05:12  *** jtimon has quit IRC
 23 2016-06-25T04:11:16  *** randy-waterhouse has quit IRC
 24 2016-06-25T04:15:50  *** randy-waterhouse has joined #bitcoin-core-dev
 25 2016-06-25T04:16:16  *** nickler has joined #bitcoin-core-dev
 26 2016-06-25T04:19:18  *** GreenParhelia has joined #bitcoin-core-dev
 27 2016-06-25T04:21:44  *** nickler has quit IRC
 28 2016-06-25T04:27:49  *** AndChat563604 has joined #bitcoin-core-dev
 29 2016-06-25T04:29:29  *** AndChat563604 has joined #bitcoin-core-dev
 30 2016-06-25T04:33:24  *** randy-waterhouse has quit IRC
 31 2016-06-25T04:36:42  *** AndChat563604 has quit IRC
 32 2016-06-25T04:46:13  *** nickler has joined #bitcoin-core-dev
 33 2016-06-25T04:51:51  *** nickler has quit IRC
 34 2016-06-25T05:04:21  *** Alopex has quit IRC
 35 2016-06-25T05:05:27  *** Alopex has joined #bitcoin-core-dev
 36 2016-06-25T05:16:11  *** nickler has joined #bitcoin-core-dev
 37 2016-06-25T05:26:51  *** adamg has quit IRC
 38 2016-06-25T05:41:15  *** frankenmint has joined #bitcoin-core-dev
 39 2016-06-25T05:47:06  *** Alopex has quit IRC
 40 2016-06-25T05:48:12  *** Alopex has joined #bitcoin-core-dev
 41 2016-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
 42 2016-06-25T06:30:51  <gmaxwell> jl2012: it reorgs back to before segwit activated.
 43 2016-06-25T06:31:06  <gmaxwell> jl2012: then will download blocks as needed.
 44 2016-06-25T06:32:48  <jl2012> Same for other soft forks like csv?
 45 2016-06-25T06:33:01  <jl2012> I think it has to be
 46 2016-06-25T06:33:53  <gmaxwell> jl2012: it arguably should be, but we haven't done that before.
 47 2016-06-25T06:34:09  <gmaxwell> for segwit it had to go get the witness data in order to serve blocks
 48 2016-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.
 49 2016-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)
 50 2016-06-25T06:36:36  <jl2012> But theoretically I may be following an invalid chain
 51 2016-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.
 52 2016-06-25T06:43:36  *** frankenm_ has joined #bitcoin-core-dev
 53 2016-06-25T06:44:54  *** frankenmint has quit IRC
 54 2016-06-25T07:16:51  *** Inaltoas1nistra has joined #bitcoin-core-dev
 55 2016-06-25T07:17:15  *** Inaltoasinistra has quit IRC
 56 2016-06-25T07:21:08  *** Guyver2 has joined #bitcoin-core-dev
 57 2016-06-25T07:47:03  *** frankenm_ has quit IRC
 58 2016-06-25T07:54:20  <wumpus> segwit testnet node: 213.46.222.31:18333
 59 2016-06-25T07:55:49  *** frankenmint has joined #bitcoin-core-dev
 60 2016-06-25T08:06:48  *** frankenmint has quit IRC
 61 2016-06-25T08:07:16  *** frankenmint has joined #bitcoin-core-dev
 62 2016-06-25T08:28:42  *** frankenmint has quit IRC
 63 2016-06-25T08:30:14  *** frankenmint has joined #bitcoin-core-dev
 64 2016-06-25T08:31:44  *** frankenm_ has joined #bitcoin-core-dev
 65 2016-06-25T08:31:44  *** frankenmint has quit IRC
 66 2016-06-25T08:33:32  *** frankenmint has joined #bitcoin-core-dev
 67 2016-06-25T08:36:34  *** frankenm_ has quit IRC
 68 2016-06-25T08:39:16  *** frankenmint has quit IRC
 69 2016-06-25T08:39:22  *** frankenmint has joined #bitcoin-core-dev
 70 2016-06-25T08:39:49  *** frankenmint has quit IRC
 71 2016-06-25T08:40:22  *** frankenmint has joined #bitcoin-core-dev
 72 2016-06-25T08:43:38  *** frankenmint has quit IRC
 73 2016-06-25T08:43:56  *** frankenmint has joined #bitcoin-core-dev
 74 2016-06-25T08:56:19  *** GreenParhelia_1 has joined #bitcoin-core-dev
 75 2016-06-25T08:59:34  *** GreenParhelia has quit IRC
 76 2016-06-25T09:19:38  *** arubi has quit IRC
 77 2016-06-25T09:22:32  *** Guyver2 has quit IRC
 78 2016-06-25T09:22:56  *** frankenmint has quit IRC
 79 2016-06-25T09:26:40  *** frankenmint has joined #bitcoin-core-dev
 80 2016-06-25T09:31:28  *** frankenmint has quit IRC
 81 2016-06-25T09:34:14  *** murch has joined #bitcoin-core-dev
 82 2016-06-25T10:02:08  *** arubi has joined #bitcoin-core-dev
 83 2016-06-25T10:23:52  <Lauda> What is the main bottleneck for reindex, storage speed or CPU processing?
 84 2016-06-25T10:26:59  *** GreenParhelia_1 has quit IRC
 85 2016-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.
 86 2016-06-25T10:30:20  <Lauda> Hmm, seems like the last 20-30 weeks are taking forever
 87 2016-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
 88 2016-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?
 89 2016-06-25T10:30:59  <wumpus> Lauda: you can easily check though: is CPU maxed out?
 90 2016-06-25T10:31:06  <Lauda> It isn't
 91 2016-06-25T10:31:23  <Lauda> DBcache 3GB
 92 2016-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)
 93 2016-06-25T10:32:47  <Lauda> Okay so even with 3GB dbcache that's still not enough
 94 2016-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
 95 2016-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
 96 2016-06-25T10:35:02  <Lauda> That's interesting and those times are amazing in comparison to leveldb
 97 2016-06-25T10:35:13  <wumpus> if you can afford the memory :)
 98 2016-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
 99 2016-06-25T10:37:15  <wumpus> I think research and experimentaitno how to best store the utxo set is in order
100 2016-06-25T10:38:06  <Lauda> The move towards SSDs should definitely help with this, but the industry is not there yet..
101 2016-06-25T10:38:44  <Lauda> I can afford 4 GB on this machine, but it still takes a fair amount of time.
102 2016-06-25T10:39:31  <wumpus> memristor would be nice
103 2016-06-25T10:40:23  <wumpus> but no matter what, also at some point, unrestrained growth of the utxo set needs to be addressed
104 2016-06-25T10:40:54  <Lauda> ^
105 2016-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
106 2016-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
107 2016-06-25T10:47:33  <gmaxwell> gigantic cuckoo hash table. with a update log. :P
108 2016-06-25T10:47:35  <wumpus> sipa: yes, that would be an interesting experiment too
109 2016-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
110 2016-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)
111 2016-06-25T10:49:20  <sipa> gmaxwell: i think they don't have application level caching
112 2016-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
113 2016-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
114 2016-06-25T10:50:18  <gmaxwell> sipa: sure, but that wouldn't change the performance of the underlying database.
115 2016-06-25T10:50:34  <wumpus> it's not like the other databases that we tried perfomed better
116 2016-06-25T10:50:48  <wumpus> leveldb still seems, all in all, the best perforing on-disk database for utxo storage
117 2016-06-25T10:51:03  <gmaxwell> Ripple folks created their own.
118 2016-06-25T10:51:17  <gmaxwell> (and also suggested we might be interested in using it)
119 2016-06-25T10:51:22  <wumpus> lmdb looked promising but it has it's own performance cliff
120 2016-06-25T10:51:31  <wumpus> (depending on the amount of memory in the system, it seems)
121 2016-06-25T10:51:59  <wumpus> what license is it under?
122 2016-06-25T10:52:56  <wumpus> I could give it a try pretty easily
123 2016-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
124 2016-06-25T10:53:46  <gmaxwell> I think it's permissively licensed, looking for it now
125 2016-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
126 2016-06-25T10:54:42  <sipa> gmaxwell: well is it read performance or write performance that is bad?
127 2016-06-25T10:55:40  <wumpus> with leveldb it's read performance, and also latency
128 2016-06-25T10:56:22  <wumpus> write performance of leveldb is quite good, I suppose because it writes consecutive files
129 2016-06-25T10:56:57  <gmaxwell> https://bitcointalk.org/index.php?topic=1004943.0
130 2016-06-25T10:56:59  <wumpus> but no database likes huge databases + random seek patterns for reads
131 2016-06-25T10:57:52  <wumpus> https://github.com/vinniefalco/nudb
132 2016-06-25T10:57:55  <gmaxwell> (thats why I made the half serious suggestion of a gigantic hash table)
133 2016-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
134 2016-06-25T10:59:45  <GitHub121> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5cdc54b4b62d...63fbdbc94d76
135 2016-06-25T10:59:45  <GitHub121> bitcoin/master b0be3a0 Wladimir J. van der Laan: doc: Mention Windows XP end of support in release notes...
136 2016-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...
137 2016-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
138 2016-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).
139 2016-06-25T11:00:40  <wumpus> going to try nudb when I have some time
140 2016-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
141 2016-06-25T11:01:35  <wumpus> so making reading much faster at the expense of writing is going to give yo mixed results
142 2016-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?
143 2016-06-25T11:04:10  <gmaxwell> Spending is more freuqntly from recently created utxo.
144 2016-06-25T11:04:54  <wumpus> interesting
145 2016-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.
146 2016-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.
147 2016-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)
148 2016-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
149 2016-06-25T11:11:06  <sipa> s/inside the database/inside the cache/
150 2016-06-25T11:11:41  <gmaxwell> with the cache turned way up, the whole initial sync runs without writing the chainstate until the end.
151 2016-06-25T11:14:26  <gmaxwell> oh, seems nudb is a big hashtable (uses external storage for values)
152 2016-06-25T11:14:42  <sipa> it keeps the entire keyset in memory?
153 2016-06-25T11:15:10  <gmaxwell> no, the keys are an a file. sounds like it's chunked so it can independantly resize sub tables.
154 2016-06-25T11:20:27  <wumpus> isn't the fact that nudb is insert-only a problem? we delete and change entries a lot
155 2016-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
156 2016-06-25T11:23:00  <gmaxwell> hm. I thought it could delete keys but not the values in external storage.
157 2016-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.
158 2016-06-25T11:29:44  <gmaxwell> LOL, totally offtopic: https://lkml.org/lkml/2016/3/31/1109
159 2016-06-25T11:30:57  <btcdrak> inb4 linus splats him
160 2016-06-25T11:35:47  <gmaxwell> it's old, just turned up in a random google search
161 2016-06-25T11:36:07  <btcdrak> oh it's an april fool!
162 2016-06-25T11:38:47  <Lauda> Error reading from database, shutting down 15 weeks left :<
163 2016-06-25T11:39:22  <Lauda> I think I can still get detect results if I test another version and break at 15 weeks left?
164 2016-06-25T11:39:25  <Lauda> decent*
165 2016-06-25T11:42:40  <gmaxwell> do you know why it failed?
166 2016-06-25T11:42:57  <gmaxwell> if you're benchmarking you can just compare to a common height.
167 2016-06-25T11:43:04  <gmaxwell> e.g. use the timestamps in the log
168 2016-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).
169 2016-06-25T11:44:39  <spudowiar> Lauda: check dmesg for I/O errors?
170 2016-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
171 2016-06-25T11:45:32  <Lauda> I'll check system error log (these tests are on Windows not Unix).
172 2016-06-25T11:47:57  <Lauda> http://pastebin.com/Zau75AHY it doesn't tell me much.
173 2016-06-25T12:36:32  <sipa> Lauda: you have debug.log.
174 2016-06-25T12:36:34  <sipa> ?
175 2016-06-25T12:36:40  <Lauda> Yes
176 2016-06-25T12:38:47  <Lauda> The last entry is just an UpdateTip.
177 2016-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).
178 2016-06-25T12:42:26  <sipa> yes, for a fair comparison you need to disable checkpoints
179 2016-06-25T12:42:43  <sipa> before the reindex changes, signatures were always checked
180 2016-06-25T12:42:57  <Lauda> How do I disable checkpoints?
181 2016-06-25T12:43:02  <sipa> after thry're only checked past the last checkpoints
182 2016-06-25T12:43:09  <sipa> -nocheckpoints i think
183 2016-06-25T12:43:38  <Lauda> So I should delete this data (version before re-index changes) and run it again with that flag?
184 2016-06-25T12:47:08  <MarcoFalke> no need to delete data
185 2016-06-25T12:47:51  <Lauda> It's still re-indexing the build from 16-05.
186 2016-06-25T12:48:18  <sipa> you can start over
187 2016-06-25T12:48:50  <Lauda> How would I add that within the .conf file?
188 2016-06-25T12:49:18  <sipa> checkpoints=0
189 2016-06-25T12:49:28  <sipa> or nocheckpoints=1
190 2016-06-25T12:52:02  <sipa> but please consult the help
191 2016-06-25T12:52:06  <sipa> (bitcoind -help)
192 2016-06-25T12:55:54  <Lauda> Okay thanks!
193 2016-06-25T13:07:58  *** Giszmo has joined #bitcoin-core-dev
194 2016-06-25T13:12:24  <Lauda> sipa is it normal that the wallet shows weird/non-existing transactions (date-wise) during reindex?
195 2016-06-25T13:14:11  <sipa> example?
196 2016-06-25T13:14:25  <Lauda> http://i.imgur.com/J7YeKdu.png
197 2016-06-25T13:14:54  <Lauda> e0a871f4897af619c4e0d8ab91d6c6f81e25d23f4dea421439b60e9c9dd8cb83
198 2016-06-25T13:15:00  <Lauda> Received Time	2015-09-09 20:57:49
199 2016-06-25T13:15:04  <Lauda> wallet shows yesterday
200 2016-06-25T13:15:45  <Lauda> I don't even recognize these transactions, a (big) list of microtransactions (incoming and outgoing) for 24/06
201 2016-06-25T13:18:30  <sipa> heh
202 2016-06-25T13:18:40  <sipa> did you import some common brainwallet
203 2016-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)
204 2016-06-25T13:19:10  <Lauda> I have never used anything besides QT.
205 2016-06-25T13:19:34  <Lauda> I think it wasn't showing on 24-06 nightly build.
206 2016-06-25T13:20:05  <sipa> that seems unlikely :)
207 2016-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
208 2016-06-25T13:21:39  <Lauda> Hmm..
209 2016-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
210 2016-06-25T13:32:50  *** harrymm has quit IRC
211 2016-06-25T13:34:08  *** harrymm has joined #bitcoin-core-dev
212 2016-06-25T13:38:37  *** harrymm has quit IRC
213 2016-06-25T13:47:51  *** lightningbot has joined #bitcoin-core-dev
214 2016-06-25T13:48:53  *** gmaxwell_ has joined #bitcoin-core-dev
215 2016-06-25T13:48:53  *** trippysa1mon has joined #bitcoin-core-dev
216 2016-06-25T13:49:16  *** gmaxwell_ is now known as Guest53903
217 2016-06-25T13:50:43  *** lysobit_ has joined #bitcoin-core-dev
218 2016-06-25T13:51:12  *** nsh has quit IRC
219 2016-06-25T13:51:13  *** musalbas has quit IRC
220 2016-06-25T13:51:13  *** ws2k3 has quit IRC
221 2016-06-25T13:51:13  *** ws2k3_ has joined #bitcoin-core-dev
222 2016-06-25T13:51:13  *** murch has quit IRC
223 2016-06-25T13:51:14  *** NicolasDorier has quit IRC
224 2016-06-25T13:51:14  *** hsmiths has quit IRC
225 2016-06-25T13:51:15  *** CodeShark has quit IRC
226 2016-06-25T13:51:15  *** gmaxwell has quit IRC
227 2016-06-25T13:51:16  *** lesderid has quit IRC
228 2016-06-25T13:51:16  *** trippysalmon has quit IRC
229 2016-06-25T13:51:17  *** lclc has quit IRC
230 2016-06-25T13:51:17  *** jonasschnelli has quit IRC
231 2016-06-25T13:51:17  *** phantomcircuit has quit IRC
232 2016-06-25T13:51:17  *** amiller has quit IRC
233 2016-06-25T13:51:17  *** ryan-c has quit IRC
234 2016-06-25T13:51:17  *** mturquette has quit IRC
235 2016-06-25T13:51:18  *** BCBot has quit IRC
236 2016-06-25T13:51:19  *** lysobit_ is now known as musalbas
237 2016-06-25T13:51:49  *** NicolasDorier_ is now known as NicolasDorier
238 2016-06-25T13:52:00  *** lesderid has joined #bitcoin-core-dev
239 2016-06-25T13:52:14  *** phantomcircuit has joined #bitcoin-core-dev
240 2016-06-25T13:52:44  *** murch has joined #bitcoin-core-dev
241 2016-06-25T13:52:53  *** amiller_ has joined #bitcoin-core-dev
242 2016-06-25T13:53:19  *** CodeShark_ is now known as CodeShark
243 2016-06-25T13:53:38  *** lclc has joined #bitcoin-core-dev
244 2016-06-25T13:54:04  *** jonasschnelli has joined #bitcoin-core-dev
245 2016-06-25T13:54:53  *** harrymm has joined #bitcoin-core-dev
246 2016-06-25T13:54:59  *** nsh has joined #bitcoin-core-dev
247 2016-06-25T13:55:34  *** mturquette has joined #bitcoin-core-dev
248 2016-06-25T13:57:06  *** spudowiar has quit IRC
249 2016-06-25T13:58:04  *** Chris_Stewart_5 has joined #bitcoin-core-dev
250 2016-06-25T14:00:30  *** ryan-c has joined #bitcoin-core-dev
251 2016-06-25T14:06:16  *** spudowiar has joined #bitcoin-core-dev
252 2016-06-25T14:10:39  <GitHub165> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/63fbdbc94d76...1922e5a65458
253 2016-06-25T14:10:39  <GitHub165> bitcoin/master 27f8126 Daniel Cousens: remove unnecessary LOCK(cs_main)
254 2016-06-25T14:10:40  <GitHub165> bitcoin/master 1922e5a Wladimir J. van der Laan: Merge #8244: remove unnecessary LOCK(cs_main) in getrawpmempool...
255 2016-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
256 2016-06-25T14:28:17  *** jtimon has joined #bitcoin-core-dev
257 2016-06-25T14:31:31  *** arubi_ has joined #bitcoin-core-dev
258 2016-06-25T14:31:33  *** arubi has quit IRC
259 2016-06-25T14:31:47  *** arubi_ is now known as arubi
260 2016-06-25T15:22:02  *** Ylbam has joined #bitcoin-core-dev
261 2016-06-25T15:47:40  *** tucenaber_ has quit IRC
262 2016-06-25T15:51:16  *** jtimon has quit IRC
263 2016-06-25T15:51:37  *** jtimon has joined #bitcoin-core-dev
264 2016-06-25T16:21:30  *** hsmiths2 has quit IRC
265 2016-06-25T16:23:36  *** hsmiths has joined #bitcoin-core-dev
266 2016-06-25T16:41:44  *** tucenaber has joined #bitcoin-core-dev
267 2016-06-25T16:44:34  *** AtashiCon has quit IRC
268 2016-06-25T17:20:36  *** Sosumi has joined #bitcoin-core-dev
269 2016-06-25T17:48:39  *** bsm117532 has quit IRC
270 2016-06-25T17:49:14  *** bsm1175321 has joined #bitcoin-core-dev
271 2016-06-25T17:51:58  *** AtashiCon has joined #bitcoin-core-dev
272 2016-06-25T18:08:22  *** Cory has quit IRC
273 2016-06-25T18:10:24  *** Pasha has joined #bitcoin-core-dev
274 2016-06-25T18:17:18  *** Pasha is now known as Cory
275 2016-06-25T18:37:35  *** justanotheruser has quit IRC
276 2016-06-25T18:40:22  *** justanotheruser has joined #bitcoin-core-dev
277 2016-06-25T18:53:55  *** murch has quit IRC
278 2016-06-25T18:59:05  *** raedah has quit IRC
279 2016-06-25T19:19:12  *** raedah has joined #bitcoin-core-dev
280 2016-06-25T19:19:20  *** molly has joined #bitcoin-core-dev
281 2016-06-25T19:22:17  *** molz has quit IRC
282 2016-06-25T19:22:38  *** moli has joined #bitcoin-core-dev
283 2016-06-25T19:24:18  *** molly has quit IRC
284 2016-06-25T19:26:17  *** raedah has quit IRC
285 2016-06-25T19:37:46  <da2ce7_mobile> Well done! https://github.com/bitcoin/bitcoin 11,111 comments :)
286 2016-06-25T19:39:40  *** Guyver2 has joined #bitcoin-core-dev
287 2016-06-25T19:39:54  *** jtimon has quit IRC
288 2016-06-25T19:40:05  *** jtimon has joined #bitcoin-core-dev
289 2016-06-25T19:40:12  <sipa> *commits
290 2016-06-25T19:43:16  *** Inaltoasinistra has joined #bitcoin-core-dev
291 2016-06-25T19:44:40  *** Inaltoas1nistra has quit IRC
292 2016-06-25T20:08:08  *** Giszmo has quit IRC
293 2016-06-25T20:25:52  <spudowiar> No one is allowed to commit
294 2016-06-25T20:26:03  <spudowiar> You must squash commits in order to add more
295 2016-06-25T20:26:56  <spudowiar> Huh, it says 10,000 commits
296 2016-06-25T20:27:00  <spudowiar> Not 11,111
297 2016-06-25T20:28:28  *** Guest53903 has quit IRC
298 2016-06-25T20:28:29  *** Guest53903 has joined #bitcoin-core-dev
299 2016-06-25T20:28:44  *** Guest53903 is now known as gmaxwell
300 2016-06-25T20:30:45  <da2ce7_mobile> oh spelling. oh well.
301 2016-06-25T20:40:41  *** adamg has joined #bitcoin-core-dev
302 2016-06-25T20:42:59  <spudowiar> da2ce7_mobile: you are a commit :)
303 2016-06-25T20:43:27  <spudowiar> [da2ce7] Fix spelling mistakes
304 2016-06-25T20:43:47  <spudowiar> Committer: spudowiar
305 2016-06-25T21:38:06  *** grubles has quit IRC
306 2016-06-25T21:53:59  *** grubles has joined #bitcoin-core-dev
307 2016-06-25T22:14:00  *** shesek has quit IRC
308 2016-06-25T22:28:51  *** Cory has quit IRC
309 2016-06-25T22:31:34  *** Cory has joined #bitcoin-core-dev
310 2016-06-25T22:39:16  *** Guyver2 has quit IRC
311 2016-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
312 2016-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