--- Day changed Sat Jun 25 2016
00:16 -!- Inaltoas1nistra [~jonathan@88-149-163-147.v4.ngi.it] has joined #bitcoin-core-dev
00:17 -!- Inaltoasinistra [~jonathan@88-149-234-94.v4.ngi.it] has quit [Ping timeout: 250 seconds]
00:21 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
00:47 -!- frankenm_ [~frankenmi@73.96.105.14] has quit [Ping timeout: 240 seconds]
00:54 <@wumpus> segwit testnet node: 213.46.222.31:18333
00:55 -!- frankenmint [~frankenmi@73.96.107.55] has joined #bitcoin-core-dev
01:06 -!- frankenmint [~frankenmi@73.96.107.55] has quit [Read error: Connection reset by peer]
01:07 -!- frankenmint [~frankenmi@73.96.107.55] has joined #bitcoin-core-dev
01:28 -!- frankenmint [~frankenmi@73.96.107.55] has quit [Ping timeout: 258 seconds]
01:30 -!- frankenmint [~frankenmi@73.96.106.160] has joined #bitcoin-core-dev
01:31 -!- frankenm_ [~frankenmi@73.96.106.160] has joined #bitcoin-core-dev
01:31 -!- frankenmint [~frankenmi@73.96.106.160] has quit [Read error: Connection reset by peer]
01:33 -!- frankenmint [~frankenmi@73.96.105.39] has joined #bitcoin-core-dev
01:36 -!- frankenm_ [~frankenmi@73.96.106.160] has quit [Ping timeout: 240 seconds]
01:39 -!- frankenmint [~frankenmi@73.96.105.39] has quit [Read error: Connection reset by peer]
01:39 -!- frankenmint [~frankenmi@73.96.105.39] has joined #bitcoin-core-dev
01:39 -!- frankenmint [~frankenmi@73.96.105.39] has quit [Remote host closed the connection]
01:40 -!- frankenmint [~frankenmi@73.96.105.39] has joined #bitcoin-core-dev
01:43 -!- frankenmint [~frankenmi@73.96.105.39] has quit [Read error: Connection reset by peer]
01:43 -!- frankenmint [~frankenmi@73.96.105.39] has joined #bitcoin-core-dev
01:56 -!- GreenParhelia_1 [~GreenParh@61.49.232.248] has joined #bitcoin-core-dev
01:59 -!- GreenParhelia [~GreenParh@61.49.232.248] has quit [Ping timeout: 240 seconds]
02:19 -!- arubi [~ese168@unaffiliated/arubi] has quit [Quit: Leaving]
02:22 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
02:22 -!- frankenmint [~frankenmi@73.96.105.39] has quit [Remote host closed the connection]
02:26 -!- frankenmint [~frankenmi@73.96.107.65] has joined #bitcoin-core-dev
02:31 -!- frankenmint [~frankenmi@73.96.107.65] has quit [Ping timeout: 272 seconds]
02:34 -!- murch [~murch@p4FE38335.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
03:02 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
03:23 < Lauda> What is the main bottleneck for reindex, storage speed or CPU processing?
03:26 -!- GreenParhelia_1 [~GreenParh@61.49.232.248] has quit [Ping timeout: 250 seconds]
03:29 < 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.
03:30 < Lauda> Hmm, seems like the last 20-30 weeks are taking forever
03:30 <@wumpus> Lauda: unless you have a very fast disk/ssd, or increase the dbcache, i/o will be your main bottleneck
03:30 < 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?
03:30 <@wumpus> Lauda: you can easily check though: is CPU maxed out? 
03:31 < Lauda> It isn't
03:31 < Lauda> DBcache 3GB
03:31 <@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)
03:32 < Lauda> Okay so even with 3GB dbcache that's still not enough
03:33 <@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
03:34 <@wumpus> but the utxo and block index is simply stored in a flat file, which is loaded at startup and written at shutdown
03:35 < Lauda> That's interesting and those times are amazing in comparison to leveldb
03:35 <@wumpus> if you can afford the memory :)
03:35 <@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
03:37 <@wumpus> I think research and experimentaitno how to best store the utxo set is in order
03:38 < Lauda> The move towards SSDs should definitely help with this, but the industry is not there yet..
03:38 < Lauda> I can afford 4 GB on this machine, but it still takes a fair amount of time.
03:39 <@wumpus> memristor would be nice
03:40 <@wumpus> but no matter what, also at some point, unrestrained growth of the utxo set needs to be addressed
03:40 < Lauda> ^
03:45 < 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
03:46 <@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
03:47 < gmaxwell> gigantic cuckoo hash table. with a update log. :P
03:47 <@wumpus> sipa: yes, that would be an interesting experiment too
03:48 <@wumpus> also the access pattern is essentially random, so the only type of caching that helps very well is keep everything
03:48 < 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) 
03:49 < sipa> gmaxwell: i think they don't have application level caching
03:49 <@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
03:49 <@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
03:50 < gmaxwell> sipa: sure, but that wouldn't change the performance of the underlying database.
03:50 <@wumpus> it's not like the other databases that we tried perfomed better
03:50 <@wumpus> leveldb still seems, all in all, the best perforing on-disk database for utxo storage
03:51 < gmaxwell> Ripple folks created their own.
03:51 < gmaxwell> (and also suggested we might be interested in using it)
03:51 <@wumpus> lmdb looked promising but it has it's own performance cliff
03:51 <@wumpus> (depending on the amount of memory in the system, it seems)
03:51 <@wumpus> what license is it under? 
03:52 <@wumpus> I could give it a try pretty easily
03:53 < GitHub74> [bitcoin] btccode opened pull request #8262: Forgetaddress 0.12 (0.12...forgetaddress-0.12) https://github.com/bitcoin/bitcoin/pull/8262
03:53 < gmaxwell> I think it's permissively licensed, looking for it now
03:53 < GitHub2> [bitcoin] btccode closed pull request #8262: Forgetaddress 0.12 (0.12...forgetaddress-0.12) https://github.com/bitcoin/bitcoin/pull/8262
03:54 < sipa> gmaxwell: well is it read performance or write performance that is bad?
03:55 <@wumpus> with leveldb it's read performance, and also latency
03:56 <@wumpus> write performance of leveldb is quite good, I suppose because it writes consecutive files
03:56 < gmaxwell> https://bitcointalk.org/index.php?topic=1004943.0
03:56 <@wumpus> but no database likes huge databases + random seek patterns for reads
03:57 <@wumpus> https://github.com/vinniefalco/nudb
03:57 < gmaxwell> (thats why I made the half serious suggestion of a gigantic hash table)
03:58 <@wumpus> lmdb read latency seems to be - on  average- better, but its writing is worse than leveldb, I think it does more random writing
03:59 < GitHub121> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5cdc54b4b62d...63fbdbc94d76
03:59 < GitHub121> bitcoin/master b0be3a0 Wladimir J. van der Laan: doc: Mention Windows XP end of support in release notes...
03:59 < GitHub121> bitcoin/master 63fbdbc Wladimir J. van der Laan: Merge #8240: doc: Mention Windows XP end of support in release notes...
03:59 < 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
04:00 < 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).
04:00 <@wumpus> going to try nudb when I have some time
04:01 <@wumpus> unfortunately we also do a lot of writing, at least during initial sync, every utxo read is updated and written back
04:01 <@wumpus> so making reading much faster at the expense of writing is going to give yo mixed results
04:02 <@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?
04:04 < gmaxwell> Spending is more freuqntly from recently created utxo. 
04:04 <@wumpus> interesting
04:06 < 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.
04:07 < 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.
04:10 < gmaxwell> (or even using non-fungibility-- a coin is likely to be spent soon if its recent ancestors were spent soon)
04:10 < 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
04:11 < sipa> s/inside the database/inside the cache/
04:11 < gmaxwell> with the cache turned way up, the whole initial sync runs without writing the chainstate until the end.
04:14 < gmaxwell> oh, seems nudb is a big hashtable (uses external storage for values)
04:14 < sipa> it keeps the entire keyset in memory?
04:15 < gmaxwell> no, the keys are an a file. sounds like it's chunked so it can independantly resize sub tables.
04:20 <@wumpus> isn't the fact that nudb is insert-only a problem? we delete and change entries a lot
04:22 <@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
04:23 < gmaxwell> hm. I thought it could delete keys but not the values in external storage.
04:24 < 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.
04:29 < gmaxwell> LOL, totally offtopic: https://lkml.org/lkml/2016/3/31/1109
04:30 < btcdrak> inb4 linus splats him
04:35 < gmaxwell> it's old, just turned up in a random google search
04:36 < btcdrak> oh it's an april fool!
04:38 < Lauda> Error reading from database, shutting down 15 weeks left :<
04:39 < Lauda> I think I can still get detect results if I test another version and break at 15 weeks left?
04:39 < Lauda> decent*
04:42 < gmaxwell> do you know why it failed?
04:42 < gmaxwell> if you're benchmarking you can just compare to a common height.
04:43 < gmaxwell> e.g. use the timestamps in the log
04:44 < Lauda> I can't be sure. It's possible that my HDD disconnected for a second (the cable seems a bit unstable if touched).
04:44 < spudowiar> Lauda: check dmesg for I/O errors?
04:45 < Lauda> Okay then, I'll compare the timestamp of the same height. Running a test on a revision before the reindex changes now
04:45 < Lauda> I'll check system error log (these tests are on Windows not Unix).
04:47 < Lauda> http://pastebin.com/Zau75AHY it doesn't tell me much.
05:36 < sipa> Lauda: you have debug.log.
05:36 < sipa> ?
05:36 < Lauda> Yes
05:38 < Lauda> The last entry is just an UpdateTip.
05:39 < 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). 
05:42 < sipa> yes, for a fair comparison you need to disable checkpoints
05:42 < sipa> before the reindex changes, signatures were always checked
05:42 < Lauda> How do I disable checkpoints?
05:43 < sipa> after thry're only checked past the last checkpoints
05:43 < sipa> -nocheckpoints i think
05:43 < Lauda> So I should delete this data (version before re-index changes) and run it again with that flag?
05:47 < MarcoFalke> no need to delete data
05:47 < Lauda> It's still re-indexing the build from 16-05.
05:48 < sipa> you can start over
05:48 < Lauda> How would I add that within the .conf file?
05:49 < sipa> checkpoints=0
05:49 < sipa> or nocheckpoints=1
05:52 < sipa> but please consult the help
05:52 < sipa> (bitcoind -help)
05:55 < Lauda> Okay thanks!
06:07 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
06:12 < Lauda> sipa is it normal that the wallet shows weird/non-existing transactions (date-wise) during reindex?
06:14 < sipa> example?
06:14 < Lauda> http://i.imgur.com/J7YeKdu.png
06:14 < Lauda> e0a871f4897af619c4e0d8ab91d6c6f81e25d23f4dea421439b60e9c9dd8cb83
06:15 < Lauda> Received Time	2015-09-09 20:57:49
06:15 < Lauda> wallet shows yesterday
06:15 < Lauda> I don't even recognize these transactions, a (big) list of microtransactions (incoming and outgoing) for 24/06
06:18 < sipa> heh
06:18 < sipa> did you import some common brainwallet
06:19 < Lauda> No. I didn't do anything. I'm running this on my wallet machine (since my other one is down)
06:19 < Lauda> I have never used anything besides QT.
06:19 < Lauda> I think it wasn't showing on 24-06 nightly build.
06:20 < sipa> that seems unlikely :)
06:21 < 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
06:21 < Lauda> Hmm..
06:23 < Lauda> My wallet.dat grew. I made a backup before I started reindex tests. It was ~400kb, now it is 4.6MB
06:32 -!- harrymm [~wayne@104.237.91.82] has quit [Remote host closed the connection]
06:34 -!- harrymm [~wayne@171.5.181.146] has joined #bitcoin-core-dev
06:38 -!- harrymm [~wayne@171.5.181.146] has quit [Ping timeout: 260 seconds]
06:45 -!- NicolasDorier_ [sid129442@gateway/web/irccloud.com/x-hlgqilaxvmoabkey] has joined #bitcoin-core-dev
06:45 -!- hsmiths2 [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has joined #bitcoin-core-dev
06:45 -!- CodeShark_ [sid126576@gateway/web/irccloud.com/x-dccyousuznwdbvay] has joined #bitcoin-core-dev
06:45 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Disconnected by services]
06:47 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev
06:48 -!- gmaxwell_ [greg@mf4-xiph.osuosl.org] has joined #bitcoin-core-dev
06:48 -!- trippysa1mon [~trippy@cyberdynesys.org] has joined #bitcoin-core-dev
06:49 -!- gmaxwell_ is now known as Guest53903
06:50 -!- lysobit_ [~musalbas@2001:bc8:30c2:ff00::] has joined #bitcoin-core-dev
06:51 -!- nsh [~lol@wikipedia/nsh] has quit [Ping timeout: 258 seconds]
06:51 -!- musalbas [~musalbas@2001:bc8:30c2:ff00::] has quit [Ping timeout: 258 seconds]
06:51 -!- ws2k3 [freenodeyc@bnc.freegamehosting.eu] has quit [Ping timeout: 258 seconds]
06:51 -!- murch [~murch@p4FE38335.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]
06:51 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-wquwuvlsxmjoyfwg] has quit [Ping timeout: 258 seconds]
06:51 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has quit [Ping timeout: 258 seconds]
06:51 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-evanvuyqmmatdbiw] has quit [Ping timeout: 258 seconds]
06:51 -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has quit [Ping timeout: 258 seconds]
06:51 -!- lesderid [~lesderid@anna.lesderid.net] has quit [Ping timeout: 258 seconds]
06:51 -!- trippysalmon [~trippy@cyberdynesys.org] has quit [Ping timeout: 258 seconds]
06:51 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 258 seconds]
06:51 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has quit [Ping timeout: 258 seconds]
06:51 -!- phantomcircuit [~phantomci@192.241.205.97] has quit [Ping timeout: 258 seconds]
06:51 -!- amiller [~socrates1@unaffiliated/socrates1024] has quit [Ping timeout: 258 seconds]
06:51 -!- ryan-c [~ryan@srv1.turboslow.net] has quit [Ping timeout: 258 seconds]
06:51 -!- mturquette [sid66043@gateway/web/irccloud.com/x-fvivsmhlblfvefbw] has quit [Ping timeout: 258 seconds]
06:51 -!- BCBot [~BCBot@46.101.246.115] has quit [Ping timeout: 258 seconds]
06:51 -!- lysobit_ is now known as musalbas
06:51 -!- ws2k3_ [freenodeyc@bnc.freegamehosting.eu] has joined #bitcoin-core-dev
06:51 -!- NicolasDorier_ is now known as NicolasDorier
06:52 -!- lesderid [~lesderid@anna.lesderid.net] has joined #bitcoin-core-dev
06:52 -!- phantomcircuit [~phantomci@192.241.205.97] has joined #bitcoin-core-dev
06:52 -!- murch [~murch@p4FE38335.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
06:52 -!- amiller_ [~socrates1@li175-104.members.linode.com] has joined #bitcoin-core-dev
06:53 -!- CodeShark_ is now known as CodeShark
06:53 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev
06:54 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev
06:54 -!- harrymm [~wayne@104.237.91.216] has joined #bitcoin-core-dev
06:54 -!- nsh [~lol@wikipedia/nsh] has joined #bitcoin-core-dev
06:55 -!- mturquette [sid66043@gateway/web/irccloud.com/x-gbtxchiauvolalgy] has joined #bitcoin-core-dev
06:57 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Ping timeout: 276 seconds]
06:58 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
07:00 -!- ryan-c [~ryan@srv1.turboslow.net] has joined #bitcoin-core-dev
07:06 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
07:10 < GitHub165> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/63fbdbc94d76...1922e5a65458
07:10 < GitHub165> bitcoin/master 27f8126 Daniel Cousens: remove unnecessary LOCK(cs_main)
07:10 < GitHub165> bitcoin/master 1922e5a Wladimir J. van der Laan: Merge #8244: remove unnecessary LOCK(cs_main) in getrawpmempool...
07:10 < GitHub97> [bitcoin] laanwj closed pull request #8244: remove unnecessary LOCK(cs_main) in getrawpmempool (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8244
07:28 -!- jtimon [~quassel@217.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
07:31 -!- arubi_ [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
07:31 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 276 seconds]
07:31 -!- arubi_ is now known as arubi
08:22 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jooohmrqpvlwsjly] has joined #bitcoin-core-dev
08:47 -!- tucenaber_ [~tucenaber@o144.231.lokis.net.pl] has quit [Ping timeout: 272 seconds]
08:51 -!- jtimon [~quassel@217.31.134.37.dynamic.jazztel.es] has quit [Quit: gone]
08:51 -!- jtimon [~quassel@217.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
09:21 -!- hsmiths2 [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has quit [Read error: Connection reset by peer]
09:23 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has joined #bitcoin-core-dev
09:41 -!- tucenaber [~tucenaber@unaffiliated/tucenaber] has joined #bitcoin-core-dev
09:44 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Ping timeout: 240 seconds]
10:20 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev
10:48 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Killed (kornbluth.freenode.net (Nickname regained by services))]
10:49 -!- bsm1175321 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev
10:51 -!- AtashiCon [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
11:08 -!- Cory [~C@unaffiliated/cory] has quit [Ping timeout: 246 seconds]
11:10 -!- Pasha [~C@unaffiliated/cory] has joined #bitcoin-core-dev
11:17 -!- Pasha is now known as Cory
11:37 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer]
11:40 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
11:53 -!- murch [~murch@p4FE38335.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
11:59 -!- raedah [~x@172.58.40.9] has quit [Remote host closed the connection]
12:19 -!- raedah [~x@172.58.40.9] has joined #bitcoin-core-dev
12:19 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
12:22 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
12:22 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
12:24 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
12:26 -!- raedah [~x@172.58.40.9] has quit [Ping timeout: 260 seconds]
12:37 < da2ce7_mobile> Well done! https://github.com/bitcoin/bitcoin 11,111 comments :)
12:39 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
12:39 -!- jtimon [~quassel@217.31.134.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]
12:40 -!- jtimon [~quassel@217.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
12:40 < sipa> *commits
12:43 -!- Inaltoasinistra [~jonathan@212.124.183.127] has joined #bitcoin-core-dev
12:44 -!- Inaltoas1nistra [~jonathan@88-149-163-147.v4.ngi.it] has quit [Ping timeout: 250 seconds]
13:08 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
13:25 < spudowiar> No one is allowed to commit
13:26 < spudowiar> You must squash commits in order to add more
13:26 < spudowiar> Huh, it says 10,000 commits
13:27 < spudowiar> Not 11,111
13:28 -!- Guest53903 [greg@mf4-xiph.osuosl.org] has quit [Changing host]
13:28 -!- Guest53903 [greg@wikimedia/KatWalsh/x-0001] has joined #bitcoin-core-dev
13:28 -!- Guest53903 is now known as gmaxwell
13:30 < da2ce7_mobile> oh spelling. oh well.
13:40 -!- adamg [~akg@50.242.93.33] has joined #bitcoin-core-dev
13:42 < spudowiar> da2ce7_mobile: you are a commit :)
13:43 < spudowiar> [da2ce7] Fix spelling mistakes
13:43 < spudowiar> Committer: spudowiar
14:38 -!- grubles [~grubles@unaffiliated/grubles] has quit [Quit: brb]
14:53 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev
15:14 -!- shesek [~shesek@bzq-84-110-108-87.cablep.bezeqint.net] has quit [Ping timeout: 272 seconds]
15:28 -!- Cory [~C@unaffiliated/cory] has quit [Ping timeout: 240 seconds]
15:31 -!- Cory [~C@unaffiliated/cory] has joined #bitcoin-core-dev
15:39 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
16:11 < 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
16:43 < 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
17:52 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []
17:52 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
17:53 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
18:10 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
18:17 -!- cryptapus_afk is now known as cryptapus
18:36 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
18:37 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
19:09 -!- jtimon [~quassel@217.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 276 seconds]
19:58 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
20:00 < luke-jr> Lightsword: care to review Eloipool's BIP 9 pR? :P
21:05 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jooohmrqpvlwsjly] has quit [Quit: Connection closed for inactivity]
21:38 -!- cryptapus is now known as cryptapus_afk
23:07 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:08 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:24 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:25 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:26 < GitHub103> [bitcoin] Cannon-Ciota opened pull request #8268: Updating default max block size (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8268
23:51 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:52 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev