12016-08-24T00:01:26  *** fengling has quit IRC
  22016-08-24T00:23:45  *** belcher has quit IRC
  32016-08-24T00:24:45  *** TomMc has joined #bitcoin-core-dev
  42016-08-24T00:44:34  *** zooko has joined #bitcoin-core-dev
  52016-08-24T00:48:24  *** fengling has joined #bitcoin-core-dev
  62016-08-24T00:50:21  *** btcdrak has quit IRC
  72016-08-24T00:52:46  *** fengling has quit IRC
  82016-08-24T00:58:33  *** cryptapus has quit IRC
  92016-08-24T01:04:15  *** juscamarena has joined #bitcoin-core-dev
 102016-08-24T01:12:07  *** Chris_Stewart_5 has quit IRC
 112016-08-24T01:14:30  *** zooko has quit IRC
 122016-08-24T01:16:41  *** juscamarena has quit IRC
 132016-08-24T01:18:03  *** Megaf has quit IRC
 142016-08-24T01:18:06  *** Alopex has quit IRC
 152016-08-24T01:19:12  *** Alopex has joined #bitcoin-core-dev
 162016-08-24T01:25:24  *** spudowiar has quit IRC
 172016-08-24T01:29:25  *** murch has quit IRC
 182016-08-24T01:35:54  *** Ylbam has quit IRC
 192016-08-24T01:37:21  *** zooko has joined #bitcoin-core-dev
 202016-08-24T01:37:31  *** Alopex has quit IRC
 212016-08-24T01:38:37  *** Alopex has joined #bitcoin-core-dev
 222016-08-24T01:40:03  *** jl2012 has joined #bitcoin-core-dev
 232016-08-24T01:42:02  *** fengling has joined #bitcoin-core-dev
 242016-08-24T01:52:03  *** TomMc has quit IRC
 252016-08-24T01:55:32  *** justanotheruser has quit IRC
 262016-08-24T01:57:18  *** justanotheruser has joined #bitcoin-core-dev
 272016-08-24T02:06:44  *** Samdney has left #bitcoin-core-dev
 282016-08-24T02:17:06  *** Alopex has quit IRC
 292016-08-24T02:18:12  *** Alopex has joined #bitcoin-core-dev
 302016-08-24T02:32:27  *** Alopex has quit IRC
 312016-08-24T02:33:32  *** Alopex has joined #bitcoin-core-dev
 322016-08-24T02:35:47  *** pedrobranco has joined #bitcoin-core-dev
 332016-08-24T02:40:05  *** pedrobranco has quit IRC
 342016-08-24T03:03:01  *** Alopex has quit IRC
 352016-08-24T03:03:12  *** zooko has quit IRC
 362016-08-24T03:04:06  *** Alopex has joined #bitcoin-core-dev
 372016-08-24T03:16:24  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 382016-08-24T03:30:01  <GitHub117> [bitcoin] nomnombtc opened pull request #8568: new var DIST_CONTRIB adds useful things for packagers from contrib (master...DIST_CONTRIB) https://github.com/bitcoin/bitcoin/pull/8568
 392016-08-24T03:41:52  *** Chris_Stewart_5 has quit IRC
 402016-08-24T03:50:36  *** harrymm has quit IRC
 412016-08-24T04:06:06  *** Alopex has quit IRC
 422016-08-24T04:07:10  *** harrymm has joined #bitcoin-core-dev
 432016-08-24T04:07:11  *** Alopex has joined #bitcoin-core-dev
 442016-08-24T04:31:16  *** Alopex has quit IRC
 452016-08-24T04:32:22  *** Alopex has joined #bitcoin-core-dev
 462016-08-24T04:51:31  *** kadoban has quit IRC
 472016-08-24T05:11:59  *** btcdrak has joined #bitcoin-core-dev
 482016-08-24T05:22:26  *** fengling has quit IRC
 492016-08-24T05:26:34  *** harrymm has quit IRC
 502016-08-24T05:37:00  *** fengling has joined #bitcoin-core-dev
 512016-08-24T05:43:01  <midnightmagic> Lots of people getting into the gitian builds. Surprising number, really. A lot of people are taking action as a result of that warning.
 522016-08-24T05:44:01  *** harrymm has joined #bitcoin-core-dev
 532016-08-24T05:47:03  <luke-jr> midnightmagic: it makes me more confident Bitcoin in general can gain user awareness and security needed to succeed
 542016-08-24T05:48:16  <midnightmagic> This is one of those things: lots of people want to help but either don't know how or can't think of what *they* can do to help.
 552016-08-24T05:51:44  <gmaxwell> There are only 200 or so publically reachable nodes running 0.13. ... something else people can do. :) upgrade their nodes.
 562016-08-24T05:53:50  <luke-jr> gmaxwell: I actually moved most of my hot wallet funds out today in preparation for upgrading mine (and hopefully being able to run it 24/7 again)
 572016-08-24T05:57:54  *** laurentmt has joined #bitcoin-core-dev
 582016-08-24T05:59:34  *** laurentmt has quit IRC
 592016-08-24T06:11:12  *** Alopex has quit IRC
 602016-08-24T06:12:17  *** Alopex has joined #bitcoin-core-dev
 612016-08-24T06:12:49  *** harrymm has quit IRC
 622016-08-24T06:30:46  *** harrymm has joined #bitcoin-core-dev
 632016-08-24T06:37:52  *** morcos has quit IRC
 642016-08-24T06:38:06  *** morcos has joined #bitcoin-core-dev
 652016-08-24T06:38:18  *** zxzzt has quit IRC
 662016-08-24T06:38:36  *** zxzzt has joined #bitcoin-core-dev
 672016-08-24T06:43:02  *** BashCo has quit IRC
 682016-08-24T06:43:39  *** BashCo has joined #bitcoin-core-dev
 692016-08-24T06:45:24  *** harrymm has quit IRC
 702016-08-24T06:53:07  *** Alopex has quit IRC
 712016-08-24T06:54:12  *** Alopex has joined #bitcoin-core-dev
 722016-08-24T06:54:26  <GitHub121> [bitcoin] rebroad opened pull request #8571: Don't disconnect just because a node's services have changed. (master...UnexpectedServicesNoDisconnect) https://github.com/bitcoin/bitcoin/pull/8571
 732016-08-24T06:57:22  *** BashCo has quit IRC
 742016-08-24T07:00:07  *** harrymm has joined #bitcoin-core-dev
 752016-08-24T07:03:34  *** pedrobranco has joined #bitcoin-core-dev
 762016-08-24T07:08:12  *** pedrobranco has quit IRC
 772016-08-24T07:08:29  <GitHub21> [bitcoin] rebroad opened pull request #8572: Don't effectively blacklist pruned nodes. (master...Don'tBanPrunedNodes) https://github.com/bitcoin/bitcoin/pull/8572
 782016-08-24T07:08:47  <GitHub193> [bitcoin] jonasschnelli opened pull request #8573: Set jonasschnellis dns-seeder filter flag (master...2016/08/filter_seed) https://github.com/bitcoin/bitcoin/pull/8573
 792016-08-24T07:15:23  <wumpus> midnightmagic: yes, lots of gitian builders this time around, this is great
 802016-08-24T07:15:39  <wumpus> (although 0.12.0 had a lot too)
 812016-08-24T07:16:49  *** rubensayshi has joined #bitcoin-core-dev
 822016-08-24T07:16:54  <sipa> 14 for 0.13.0-linux
 832016-08-24T07:16:59  <sipa> i think that's a record
 842016-08-24T07:17:53  *** BashCo has joined #bitcoin-core-dev
 852016-08-24T07:17:54  <sipa> oh, no, 15 for 0.12.0-linux
 862016-08-24T07:21:37  *** sanada has quit IRC
 872016-08-24T07:39:31  *** sanada has joined #bitcoin-core-dev
 882016-08-24T07:51:01  *** Alopex has quit IRC
 892016-08-24T07:52:06  *** Alopex has joined #bitcoin-core-dev
 902016-08-24T08:00:10  *** murch has joined #bitcoin-core-dev
 912016-08-24T08:11:11  *** Alopex has quit IRC
 922016-08-24T08:12:17  *** Alopex has joined #bitcoin-core-dev
 932016-08-24T08:15:35  <GitHub21> [bitcoin] jonasschnelli opened pull request #8574: [Wallet] refactor CWallet/CWalletDB/CDB (master...2016/08/bdb_abstraction_2) https://github.com/bitcoin/bitcoin/pull/8574
 942016-08-24T08:16:03  <wumpus> sipa: though those accumulated over a longer time
 952016-08-24T08:16:13  <wumpus> sipa: very likely 0.13.0 will still be a record
 962016-08-24T08:16:25  <sipa> yeah
 972016-08-24T08:16:30  *** JackH has joined #bitcoin-core-dev
 982016-08-24T08:19:44  *** laurentmt has joined #bitcoin-core-dev
 992016-08-24T08:21:30  <jonasschnelli> The CWallet/CWalletDB/CDB interleaving is really a mess. I fear nobody will review the just opened refactoring PR. They are much larger then I had originally expected.
1002016-08-24T08:22:18  <jonasschnelli> But if we want to add support for a different wallet database format, we need better abstraction of wallet logic, wallet database logic and pure database storage logic
1012016-08-24T08:22:55  <jonasschnelli> Somehow I think we need to do this before we add Multi Wallet Support,...
1022016-08-24T08:24:10  <wumpus> agree that some refactoring of the wallet code is long due
1032016-08-24T08:24:23  <sipa> jonasschnelli: will have a look
1042016-08-24T08:24:24  <wumpus> but yes, assuring that it doesnt introduce nasty bugs or funcitonality people are relying on is hard
1052016-08-24T08:24:32  <wumpus> +break
1062016-08-24T08:24:52  <wumpus> which reminds me we still haven't add the label API to replace the accounts API
1072016-08-24T08:25:10  <jonasschnelli> Yes. I try to move the BDB code carefully and keep its behavior (even if it silly sometimes).
1082016-08-24T08:25:20  <wumpus> that makes sense for a refactor
1092016-08-24T08:25:21  <jonasschnelli> wumpus: We should have a look at your PR
1102016-08-24T08:25:58  <jonasschnelli> BTW: travis has failed on walletbackup.py randomly, the PR does not change anything there IMO: https://travis-ci.org/bitcoin/bitcoin/jobs/154141125#L1464
1112016-08-24T08:26:11  <jonasschnelli> Will re-trigger travis on that PR
1122016-08-24T08:26:11  <wumpus> yes, the code is pretty much outdated and useless at this point, but we should make sure at least the API is what we want
1132016-08-24T08:26:21  <gmaxwell> FWIW, phantomcircuit spent basically months with a bunch of wallet refactors pipelined waiting for changes to go in.
1142016-08-24T08:27:27  <gmaxwell> If people turn in broken up changes, they get randomly stuck waiting, presumably because few care to review things that don't seem important.  If people submit large all at once changes, they get stuck because no one is able to review big changes.
1152016-08-24T08:27:45  <wumpus> this is especially true for the wallet
1162016-08-24T08:28:04  <jonasschnelli> Indeed. Maybe I should split up the PR in smaller chunks..
1172016-08-24T08:28:04  <wumpus> and, perversely, the refactors would probably make it easier to review changes in the future
1182016-08-24T08:28:29  <jonasschnelli> There is a very small PR for those we care: :) https://github.com/bitcoin/bitcoin/pull/8564
1192016-08-24T08:28:43  <wumpus> but quite some people get a headache just for looking at the wallet code as it is now, which prevents them from reviewing it, and thus from those (necessary) changes from getting in
1202016-08-24T08:28:48  <gmaxwell> what I'm saying is that phantomcircuit did split up his changes into chunks, submitted the first one, then it sat for ages.
1212016-08-24T08:29:07  * jonasschnelli will have a look at phantomcircuit PRs
1222016-08-24T08:29:32  <wumpus> yes, that's how it has always gone with wallet changes, even CodeShark's multiwallet PR back in the day sat for ages, without useful review or testing
1232016-08-24T08:29:33  <gmaxwell> He had more pipelined, but I don't know if he gave up, or if its just because he's been sick that he hasn't PRed more of them since the longest standing went in just recently.
1242016-08-24T08:30:02  <gmaxwell> probably the latter, he's not prone to giving up.
1252016-08-24T08:30:03  <gmaxwell> :)
1262016-08-24T08:30:05  *** Ylbam has joined #bitcoin-core-dev
1272016-08-24T08:30:38  <wumpus> it's just difficult to do, I don't have any useful advice for anyone trying unfortunately, as you say both breaking the change up as well as doing a lot at the same time run against barreirs
1282016-08-24T08:30:57  <wumpus> changing the consensus code seems easier :)
1292016-08-24T08:31:12  <jonasschnelli> I think https://github.com/bitcoin/bitcoin/pull/8445 is ready for merge
1302016-08-24T08:31:22  <jonasschnelli> (one of Patricks)
1312016-08-24T08:31:37  <wumpus> let's merge it then
1322016-08-24T08:33:08  * wumpus is still looking for someone to stand up to be wallet maintainer
1332016-08-24T08:33:37  <wumpus> maybe Patrick?
1342016-08-24T08:33:44  <GitHub147> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/9358893518a1...f9167003d947
1352016-08-24T08:33:45  <GitHub147> bitcoin/master e86eb71 Patrick Strateman: Move CWallet::setKeyPool to private section of CWallet
1362016-08-24T08:33:45  <GitHub147> bitcoin/master 8680d3a Patrick Strateman: Move wallet initialization logic from AppInit2 to CWallet::InitLoadWallet
1372016-08-24T08:33:46  <GitHub147> bitcoin/master f916700 Wladimir J. van der Laan: Merge #8445: Move CWallet::setKeyPool to private section of CWallet....
1382016-08-24T08:33:54  <GitHub83> [bitcoin] laanwj closed pull request #8445: Move CWallet::setKeyPool to private section of CWallet. (master...2016-07-01-cwallet-api-cleanup) https://github.com/bitcoin/bitcoin/pull/8445
1392016-08-24T08:35:51  <jonasschnelli> I'm happy to co-maintain the wallet. I think I can now understand most of its code (also the silly one)
1402016-08-24T08:37:00  <wumpus> thanks, you're very welcome to participate in wallet changes, but I think it'd be good to bring someone else on board
1412016-08-24T08:37:20  <wumpus> otherwise you end up with everything on your plate
1422016-08-24T08:37:44  <jonasschnelli> Yes. Agree.
1432016-08-24T08:38:22  <murch> What responsibilities does being the wallet maintainer entail?
1442016-08-24T08:38:57  <wumpus> work on the wallet, do a lot of work on the wallet, and review other people's work on the wallet
1452016-08-24T08:39:03  <jonasschnelli> Review PRs, make sure we make progress with the wallet
1462016-08-24T08:39:22  <wumpus> and have a very strong clue about the crypto and how the parts interact
1472016-08-24T08:41:04  <wumpus> and doesn't get dizzyness and/or headaches or bouts of panic while reading the current wallet code, or changes to it
1482016-08-24T08:41:46  <sipa> i'd love to spend time on making bitcoin core function as an SPV client, and make the wallet changes that are necessary
1492016-08-24T08:41:52  <wumpus> (as I do)
1502016-08-24T08:42:02  <sipa> but i think i have a bit too many other things to do first
1512016-08-24T08:42:11  <wumpus> yes, I think you have enough on your plate too
1522016-08-24T08:42:13  <murch> Unfortunately, I'm not really familiar with the crypto used in the wallet. I mean, I know in broad strokes what it is supposed to do, but I'd be lying if I said I have a strong clue.
1532016-08-24T08:42:16  <wumpus> and you're already maintainer too
1542016-08-24T08:42:29  <jonasschnelli> gmaxwell: "cat dnsseed.dump | grep 00000005 | grep "    1   " | wc -l" = 2590
1552016-08-24T08:42:33  <GitHub15> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f9167003d947...f12d2b5a8ac3
1562016-08-24T08:42:33  <GitHub15> bitcoin/master 7bd5ff4 Christian Barcenas: Trivial: Fix two VarInt examples in serialize.h
1572016-08-24T08:42:34  <GitHub15> bitcoin/master f12d2b5 Pieter Wuille: Merge #8560: Trivial: Fix two VarInt examples in serialize.h...
1582016-08-24T08:42:37  <sipa> yes, i'm not volunteering for the wallet maintainer position... just saying i'd like to work more on it :)
1592016-08-24T08:42:42  <GitHub188> [bitcoin] sipa closed pull request #8560: Trivial: Fix two VarInt examples in serialize.h (master...fix_varint_examples) https://github.com/bitcoin/bitcoin/pull/8560
1602016-08-24T08:42:52  <jonasschnelli> I guess there are plenty of node signaling NODE_BLOOM, though not sure if they are really offering the service
1612016-08-24T08:43:10  <sipa> can i have ACK on 8451?
1622016-08-24T08:43:24  <jonasschnelli> sipa: Not sure if the SPV mode would be utterly complex.
1632016-08-24T08:43:42  <sipa> jonasschnelli: it won't be, but there are a few subtle changes to make
1642016-08-24T08:43:50  <jonasschnelli> A first step would be to allow the wallet to run in mode without mempool knownlage
1652016-08-24T08:44:37  *** MarcoFalke has joined #bitcoin-core-dev
1662016-08-24T08:44:44  <jonasschnelli> Then a way how the wallet can "ask for blocks",... main.cpp needs to download them, check headers (SPV pure PoW check) and passes the txes through the SyncWithWallet signal
1672016-08-24T08:44:44  <wumpus> I don't like #8451 very much, it seems a step the wrong way around
1682016-08-24T08:45:31  <gmaxwell> using undefined behavior isn't acceptable however.
1692016-08-24T08:45:42  <jonasschnelli> sipa: what are the benefits of 8451?
1702016-08-24T08:45:57  <wumpus> no, it's not, but that dosn't mean I have to like the solution
1712016-08-24T08:46:17  <sipa> jonasschnelli: fixing our code, which is currently undefined (as in: the compiler is allowed to make it fire all the nukes)
1722016-08-24T08:46:25  <sipa> wumpus: understood, and agree
1732016-08-24T08:46:45  <wumpus> I really like the idea of having a transaction-set-ins-stone object, as well as a transaction builder (ImmutableTransaction). We should have that for more things, such as Script
1742016-08-24T08:46:51  <sipa> but i think a better solution is too far off (modifying the serializing framework to support constructing-while-deserializing)
1752016-08-24T08:47:02  <sipa> or encapsulating all fields in CTransaction
1762016-08-24T08:47:10  <wumpus> eh s/ImmutableTransaction/MutableTransaction
1772016-08-24T08:47:32  <wumpus> it separates building and checking at aconceptual level
1782016-08-24T08:47:55  <gmaxwell> wumpus: by builder, do you imagine that a transaction would always be built in one atomic step?
1792016-08-24T08:48:13  <sipa> hmm, maybe there is a possibility to change all the places where CTransaction is deserialized to first deserialize into a CMutableTransaction, and then convert to a CTransaction?
1802016-08-24T08:48:20  <sipa> there may not be very many of those
1812016-08-24T08:48:34  <wumpus> gmaxwell: no. Not necessarily, but it is a  "MutableTransaction" scaffold until it no longer needs to be one
1822016-08-24T08:48:41  <gmaxwell> gotcha.
1832016-08-24T08:48:54  <sipa> let's try.
1842016-08-24T08:49:06  <gmaxwell> Thats really what I thought the intent was there in the past.
1852016-08-24T08:49:17  <wumpus> sipa: sounds quite sensible
1862016-08-24T08:49:29  <wumpus> the serialization framework *needs* a mutable object,so give it one
1872016-08-24T08:49:33  <gmaxwell> (in particular making CTransaction always fully immutable allows changing its representation to an efficient one)
1882016-08-24T08:49:39  <wumpus> gmaxwell: exactly!
1892016-08-24T08:49:55  <sipa> gmaxwell: it requires more than that though
1902016-08-24T08:50:01  <sipa> (also encapsulating its fields)
1912016-08-24T08:50:09  <gmaxwell> I know.
1922016-08-24T08:50:14  <wumpus> sipa: sure, it's only one step
1932016-08-24T08:50:18  <gmaxwell> (as in one malloc per CTransaction, and only one-- oh to dream)
1942016-08-24T08:50:32  <wumpus> that's what I meant with that making Transaction mutable is a step in the wrong direction
1952016-08-24T08:50:47  <wumpus> just a step, not armageddon
1962016-08-24T08:51:22  <gmaxwell> well, I think in C++ we shouldn't equat const/non-constness with immutability. They're partially orthorgonal concepts.
1972016-08-24T08:51:26  <gmaxwell> er equate*
1982016-08-24T08:51:41  <wumpus> I agree, though const helps enforce that at the compiler level
1992016-08-24T08:51:53  <sipa> ugh.
2002016-08-24T08:52:05  *** jannes has joined #bitcoin-core-dev
2012016-08-24T08:52:05  <gmaxwell> oh no, sipa found something awful, I can tell.
2022016-08-24T08:52:09  <sipa> no more CTransaction::operator= or CTransaction::swap
2032016-08-24T08:52:09  <wumpus> uh oh
2042016-08-24T08:52:33  <wumpus> hmm. atomic replacement is ungood too?
2052016-08-24T08:53:03  <wumpus> when you regard CTransaction as a reference to a transaction, those may be acceptable
2062016-08-24T08:53:25  <wumpus> otherwise, yes, it's mutating
2072016-08-24T08:55:57  <wumpus> though the future 'CTransaction needs one malloc' would imply it has one pointer, which could trivially be swapped with another one
2082016-08-24T08:56:24  <wumpus> assignment would still need copying, or a shared pointer
2092016-08-24T08:56:37  *** MarcoFalke has left #bitcoin-core-dev
2102016-08-24T08:56:51  <gmaxwell> wumpus: well no, because a single malloced chunk could have pointers internally... so you can't say it implies it alone
2112016-08-24T08:57:01  <gmaxwell> though obviously it would be better if it didn't. :)
2122016-08-24T08:57:30  <wumpus> gmaxwell: oh, sure, then you'd need to do some more accounting
2132016-08-24T08:57:53  <wumpus> I don't mean 'atomic' in the threading sense
2142016-08-24T08:58:14  <gmaxwell> I was reading 'trivially swapped' meaning not needing any deep operations.
2152016-08-24T08:58:26  <wumpus> it doesn't need any deep operations, just swap the surface pointers
2162016-08-24T08:58:39  <wumpus> if there are more, pointing inside the structure, well swap all of them
2172016-08-24T09:00:34  <wumpus> but if you have all pointers pointing inside the stucture as part of the malloc'ed structure itself you can easily keep it to one pointer
2182016-08-24T09:01:01  <wumpus> depends on how much indirection is a performance bottleneck I guess...
2192016-08-24T09:04:03  <gmaxwell> wumpus: fyi there was a thread on bitcointalk recently where someone profiled bitcoin core, and was asking why we weren't using faster sha2 because it was 35% in their benchmarks. I pointed them to your work with the SIMD sha2.  They seemed to think that there would be 10x speedups, so I was sad to have to disappoint them. :)
2202016-08-24T09:05:47  <wumpus> gmaxwell: yeah it was disappointing :( would still make some sense to integrate that, for a bit of speedup, but the overall gains were so little it demotivated me at least
2212016-08-24T09:06:10  <gmaxwell> they were clearly measurable at least.
2222016-08-24T09:06:22  *** laurentmt has quit IRC
2232016-08-24T09:06:36  <wumpus> but if anyone wants to continue that work they're welcome to, of course
2242016-08-24T09:06:40  <gmaxwell> Thats something to be proud of, even if they aren't huge. They'll become more important as everything else gets optimized.
2252016-08-24T09:07:12  <wumpus> true
2262016-08-24T09:08:10  <wumpus> which reminds me of #8524
2272016-08-24T09:08:30  <gmaxwell> he also commented on the leveldb crc
2282016-08-24T09:08:57  <wumpus> hah  :)
2292016-08-24T09:09:24  *** MarcoFalke has joined #bitcoin-core-dev
2302016-08-24T09:09:50  <MarcoFalke> jonasschnelli: Can you explain?
2312016-08-24T09:10:02  <MarcoFalke> we don't have auto stretch in master
2322016-08-24T09:10:07  <MarcoFalke> I think
2332016-08-24T09:10:55  <jonasschnelli> MarcoFalke: let me look at the code..
2342016-08-24T09:11:15  <jonasschnelli> It just looks strange (part of the row don't use full width)
2352016-08-24T09:11:24  <jonasschnelli> And I think its avoidable
2362016-08-24T09:11:33  <wumpus> did that once, too  https://github.com/laanwj/bitcoin/commit/431c1b987b34589f32f4c2d0ee0f2571ba70e349  I don't really know where that went, looks like I never did any high-level performance measurements, only benchmark of the CRC function itself
2372016-08-24T09:12:45  <MarcoFalke> ok, let me check...
2382016-08-24T09:12:47  <jonasschnelli> MarcoFalke: https://github.com/bitcoin/bitcoin/pull/8463/files#r76021780
2392016-08-24T09:13:09  *** Megaf has joined #bitcoin-core-dev
2402016-08-24T09:13:17  *** pedrobranco has joined #bitcoin-core-dev
2412016-08-24T09:13:18  <wumpus> but the CRC instruction is 7-8 times faster than leveldb's crc implementatino on Haswell: https://github.com/laanwj/crcbench
2422016-08-24T09:14:28  <jonasschnelli> MarcoFalke: 84+100+170+290+110+100+100 = 954, window width = 1000px, some padding
2432016-08-24T09:14:31  <wumpus> and it works, I verified it's the same ariant of CRC (crc32c) and has the same output
2442016-08-24T09:15:41  <wumpus> what is lacking/to be done: CPU detection at startup, replace those functions by function pointers, based on the best implementation for detected CPU
2452016-08-24T09:16:43  <wumpus> in the case of leveldb maybe trying to upstream it
2462016-08-24T09:17:03  <jonasschnelli> wumpus: nice work!
2472016-08-24T09:17:33  <wumpus> thanks :)
2482016-08-24T09:17:36  <jonasschnelli> Not sure hoe active upstream is
2492016-08-24T09:17:38  *** spudowiar has joined #bitcoin-core-dev
2502016-08-24T09:17:45  * wumpus should finish more projects instead of starting more
2512016-08-24T09:17:58  <wumpus> agreed, that's why that's a 'maybe', normally it'd be a requirement
2522016-08-24T09:18:03  <jonasschnelli> heh... yes.
2532016-08-24T09:20:06  <wumpus> https://github.com/google/leveldb: last update 13 days ago - it's less dead than univalue's upstream at least
2542016-08-24T09:20:40  <jonasschnelli> Indeed. :-) 3xpings from paveljanik
2552016-08-24T09:21:07  <jonasschnelli> But UniValue upstream is now bitcoin-core/univalue, right?
2562016-08-24T09:21:27  <wumpus> though I think all of recent leveldb changes have been OS-support changes, not so much consequential database performance changes, but I haven't looked very recently
2572016-08-24T09:21:42  <MarcoFalke> No, I think we keep bitcoin-core/stuff only for bitcoin-core related patches
2582016-08-24T09:21:43  <wumpus> (or correctness fixes for that matter)
2592016-08-24T09:22:13  <wumpus> jonasschnelli: well, effectively, for bitcoin it is. I think we're the only client for univalue anyhow.
2602016-08-24T09:22:50  <jonasschnelli> Digital Bitbox also depends on UniValue. But thats it I guess.
2612016-08-24T09:23:13  <jonasschnelli> IMO if jeff is not maintaining it, we should take care about bitcoin-core/UniValue
2622016-08-24T09:23:29  <paveljanik> first, we should ask jeff.
2632016-08-24T09:23:36  <wumpus> I tend to agree, though I can't spend much time being maintainer of yet another project
2642016-08-24T09:23:47  <MarcoFalke> pff, it is always a mess to have several repos on github and no one knows whcih one is maintained
2652016-08-24T09:24:12  <wumpus> bitcoin-core's is maintained, in the sense that it will always be the best version for our use
2662016-08-24T09:25:02  <wumpus> well I know only one thing for sure: Jeff's isn't
2672016-08-24T09:25:16  <wumpus> I'll merge patches when necessary for bitcoin or general performance/correctness
2682016-08-24T09:25:58  <wumpus> which reminds me I still need to cean up my univalue fuzzing framework some time
2692016-08-24T09:26:47  <wumpus> (and do the necessary build system changes, analogous to Patrick's https://github.com/bitcoin/bitcoin/pull/7940)
2702016-08-24T09:27:39  <gmaxwell> I don't know if andytoshi published his test harness.  He rewrote a functional equivilent to univale in rust, then wrote a test harness that compared the two against each other and found a number of bugs in univale (though I believe they were all already bugs wumpus had found).
2712016-08-24T09:27:46  * sipa tries compiling after making CTransaction deserializable-at-construct-time
2722016-08-24T09:27:52  <gmaxwell> I think thats a really really useful testing technique for a parser.
2732016-08-24T09:28:36  <wumpus> jonasschnelli: in any case univalue is a good choice when dealing with bitcoind client-side from C or C++, I don't think using it is a bad chocie, maybe it just needs very little maintenance
2742016-08-24T09:28:51  <wumpus> gmaxwell: yes having two implementations and comparing them is a good way of testing
2752016-08-24T09:34:18  *** BashCo has quit IRC
2762016-08-24T09:34:24  *** BashCo_ has joined #bitcoin-core-dev
2772016-08-24T09:38:09  <wumpus> cfields_: we should start working at replacing boost::chrono too :) https://github.com/zcash/zcash/issues/1241
2782016-08-24T09:38:39  <gmaxwell> I got cancer from just looking at that backtrace.
2792016-08-24T09:39:12  <gmaxwell> I've run core in valgrind quite a bit and not seen those errors.
2802016-08-24T09:39:51  <gmaxwell> not that I doubt them.
2812016-08-24T09:44:45  <paveljanik> Can anyone please explain to me, what is the purpose of this line? https://github.com/bitcoin/bitcoin/blob/master/src/qt/recentrequeststablemodel.h#L34?
2822016-08-24T09:55:27  <wumpus> gmaxwell: boost is so difficult to debug, with all the c++ template magic
2832016-08-24T09:55:48  <wumpus> gruesomely overdesigned, even for something like time getting/conversion
2842016-08-24T09:56:22  <wumpus> paveljanik: I think it is spurious, don't take my word for it though
2852016-08-24T09:57:29  <jonasschnelli> paveljanik: agree with wumpus
2862016-08-24T09:57:50  <jonasschnelli> How could such code end up here in the first place. :-)
2872016-08-24T09:58:29  <paveljanik> I think it was cut&pasted...
2882016-08-24T09:58:45  <paveljanik> the same line is present 6 times in our sources...
2892016-08-24T09:59:02  <wumpus> it makes sense to have (de)serialization code there, as those entries are (de)serialized
2902016-08-24T09:59:56  <wumpus> paveljanik: but the big question is, does gcc even generate code for them :D
2912016-08-24T10:00:27  <wumpus> it would only make sense if there is a local veriable nVersion
2922016-08-24T10:00:42  <GitHub158> [bitcoin] ajtowns opened pull request #8575: leveldb: generate lib independent of locale sort (master...leveldb-locale-reproducible) https://github.com/bitcoin/bitcoin/pull/8575
2932016-08-24T10:00:45  <wumpus> which there isn't, so it'sa self-assign
2942016-08-24T10:01:17  <wumpus> EH. Well there is, one of the arguments
2952016-08-24T10:01:24  <paveljanik> yes 8)
2962016-08-24T10:02:14  <wumpus> so take care that if nVersion is used after that line, you can't remove the line (without changing the use of nVersion to this->nVersion)
2972016-08-24T10:02:18  <paveljanik> and this is where I'm lost ;-)
2982016-08-24T10:02:42  <wumpus> having the structure field have the same name as a parameter is unadvisable here, as it causes confustion
2992016-08-24T10:02:48  <wumpus> confusion*
3002016-08-24T10:03:14  <wumpus> I think I get it
3012016-08-24T10:03:20  <paveljanik> nVersion is not used at all after this line in all 6 cases.
3022016-08-24T10:03:22  <wumpus> the same function is used for reading and writing
3032016-08-24T10:03:46  <wumpus> on writing, this->nVersion is written to the serialization
3042016-08-24T10:03:57  <wumpus> on reading, this->nVersion is read from the serialization, then assigned to nVersion
3052016-08-24T10:04:33  <wumpus> but why? nVersion argument to Serialization is of a different sort than nVersion used internally
3062016-08-24T10:04:43  <wumpus> .?!?!?? core dump
3072016-08-24T10:05:05  <wumpus> I know I just copied that code, I can't have written it :)
3082016-08-24T10:05:28  <MarcoFalke> The code is copied from the initial git commit
3092016-08-24T10:05:31  <paveljanik> we have to ask the "TwoSpaces" man ;-)
3102016-08-24T10:05:35  <MarcoFalke> ask satoshi or something
3112016-08-24T10:05:43  <wumpus> I'd be very careful with touching it though or the whole pyramid may come down
3122016-08-24T10:05:46  <wumpus> hah yes
3132016-08-24T10:05:55  <paveljanik> yes, definitely
3142016-08-24T10:07:08  <wumpus> this is why I wondered whether gcc generates code for it in the first place
3152016-08-24T10:07:44  <wumpus> "-*- sipa tries compiling after making CTransaction deserializable-at-construct-time", that was his last comment and then he went silent, ominous
3162016-08-24T10:07:53  <gmaxwell> haha
3172016-08-24T10:09:07  <phantomcircuit> gmaxwell: im waiting on 8450 before making more changes
3182016-08-24T10:10:06  <phantomcircuit> the next one is to change the accounting tests, but that needs to actually change the tests themselves
3192016-08-24T10:10:10  <wumpus> are you waiting on that one? let's merge it, it's a test change and two acks already
3202016-08-24T10:10:12  <phantomcircuit> so it's a bit more involved
3212016-08-24T10:10:25  <phantomcircuit> (basically im going to be removing like 50% of the tests since they're nonsensical)
3222016-08-24T10:11:03  <GitHub65> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/f12d2b5a8ac3...21857d2bf746
3232016-08-24T10:11:04  <GitHub65> bitcoin/master 25400c4 Patrick Strateman: Account wallet feature RPC tests.
3242016-08-24T10:11:04  <GitHub65> bitcoin/master 9578333 Patrick Strateman: Remove rpc_wallet_tests.cpp
3252016-08-24T10:11:05  <GitHub65> bitcoin/master 21857d2 Wladimir J. van der Laan: Merge #8450: [Test] Replace rpc_wallet_tests.cpp with python RPC unit tests...
3262016-08-24T10:11:07  <phantomcircuit> wumpus: yeah i was waiting
3272016-08-24T10:11:08  <GitHub112> [bitcoin] laanwj closed pull request #8450: [Test] Replace rpc_wallet_tests.cpp with python RPC unit tests (master...2016-08-03-remove-rpc-wallet-tests) https://github.com/bitcoin/bitcoin/pull/8450
3282016-08-24T10:11:33  <phantomcircuit> great there's now only a single thing external to CWallet using CWalletDB which is the accounting_tests.cpp
3292016-08-24T10:11:38  <phantomcircuit> which mostly make no sense
3302016-08-24T10:11:51  <wumpus> why does it use CWalletDB?
3312016-08-24T10:11:56  <wumpus> or maybe better not to ask, sorry
3322016-08-24T10:12:07  <wumpus> I'm sure accounting tests can be done with just a CWallet object
3332016-08-24T10:12:33  <phantomcircuit> indeed better not to ask (it's adding the accounting entries directly...)
3342016-08-24T10:14:26  <phantomcircuit> walletdb.ListAccountCreditDebit is the culprit really
3352016-08-24T10:15:06  <wumpus> oh, crap related to the account sytem
3362016-08-24T10:15:52  <sipa> accounting details are the only thing from wallet db we don't load into memory
3372016-08-24T10:17:01  <wumpus> if we only removed that functionality already, we could have effortlessly gotten rid of this
3382016-08-24T10:24:35  <paveljanik> wumpus, qt_libbitcoinqt_a-recentrequeststablemodel.o is different when this line is commented, so it is used...
3392016-08-24T10:25:52  <gmaxwell> wumpus: https://bitcoin.org/laanwj-releases.asc should probably come with the signature of that key by your personal key. Keyserver retention of keys that are leafs isn't always all that good.
3402016-08-24T10:25:57  <paveljanik> but I think this line has no meaning in the read case as the value is assigned to the shadowed nVersion, argument one, and discarded at the end...
3412016-08-24T10:34:13  <wumpus> gmaxwell: yes, good idea
3422016-08-24T10:36:52  *** JZA has quit IRC
3432016-08-24T10:39:53  <wumpus> gmaxwell: do I need to do anything special for that? I just did gpg --export --armor 0x90C8019E36C2E964 > ../websites/bitcoin.org/laanwj-releases.asc  and git sees no difference
3442016-08-24T10:41:25  <gmaxwell> hm. maybe I'm wrong and it has it already, let me check.
3452016-08-24T10:42:05  <gmaxwell> it does, I'm sorry to have wasted your time.
3462016-08-24T10:42:42  <wumpus> ok, well good to know
3472016-08-24T10:43:00  <gmaxwell> someone in #bitcoin said it didn't, which primed me to conclude it didn't when I looked. :)
3482016-08-24T10:45:27  *** spudowiar has quit IRC
3492016-08-24T10:55:40  *** harrymm has quit IRC
3502016-08-24T10:56:22  *** BashCo_ has quit IRC
3512016-08-24T10:56:53  *** BashCo has joined #bitcoin-core-dev
3522016-08-24T11:04:20  *** JZA has joined #bitcoin-core-dev
3532016-08-24T11:06:44  *** BashCo_ has joined #bitcoin-core-dev
3542016-08-24T11:09:27  <wumpus> should probably update my key at bitcoin.org with all the new signatures though
3552016-08-24T11:09:29  *** BashCo has quit IRC
3562016-08-24T11:12:33  *** harrymm has joined #bitcoin-core-dev
3572016-08-24T11:40:58  *** cryptapus has joined #bitcoin-core-dev
3582016-08-24T11:40:58  *** cryptapus has joined #bitcoin-core-dev
3592016-08-24T11:55:26  *** JZA has quit IRC
3602016-08-24T11:56:50  <GitHub145> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/21857d2bf746...85d4e21a6178
3612016-08-24T11:56:50  <GitHub145> bitcoin/master c911035 djpnewton: Add default port numbers to REST doc
3622016-08-24T11:56:51  <GitHub145> bitcoin/master 85d4e21 Wladimir J. van der Laan: Merge #8567: Add default port numbers to REST doc...
3632016-08-24T11:57:04  <GitHub2> [bitcoin] laanwj closed pull request #8567: Add default port numbers to REST doc (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8567
3642016-08-24T12:00:31  <GitHub112> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/85d4e21a6178...62a5a8a01866
3652016-08-24T12:00:31  <GitHub112> bitcoin/master fa8dd78 MarcoFalke: [qt] Remove Priority from coincontrol dialog
3662016-08-24T12:00:32  <GitHub112> bitcoin/master 62a5a8a Jonas Schnelli: Merge #8463: [qt] Remove Priority from coincontrol dialog...
3672016-08-24T12:00:41  <GitHub94> [bitcoin] jonasschnelli closed pull request #8463: [qt] Remove Priority from coincontrol dialog (master...Mf1608-qtPrio) https://github.com/bitcoin/bitcoin/pull/8463
3682016-08-24T12:12:56  <jonasschnelli> MarcoFalke, paveljanik: interested in testing an ACK/NACK https://github.com/bitcoin/bitcoin/pull/7826?
3692016-08-24T12:16:45  <paveljanik> jonasschnelli, well, Marco's suggestion to add "how to test" would be great ;-) I'll test compilation now at least.
3702016-08-24T12:16:54  <paveljanik> I do not use GUI much...
3712016-08-24T12:18:00  <jonasschnelli> Ah. Right. Also, I overlooked his point with non-std transactions.. will try to fix
3722016-08-24T12:27:44  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3732016-08-24T12:32:42  *** aalex has quit IRC
3742016-08-24T12:33:12  *** aalex has joined #bitcoin-core-dev
3752016-08-24T12:36:50  *** JZA has joined #bitcoin-core-dev
3762016-08-24T12:41:57  <sipa> making CTransaction actually immutable is a huge rathole...
3772016-08-24T12:42:19  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3782016-08-24T12:44:31  <sipa> 3 hours straight of fixing compile errors, and now the tests don't run :)
3792016-08-24T12:44:53  <sipa> notably, almost all the compile errors were in the compact blocks code and in wallet tests
3802016-08-24T12:47:20  *** mkarrer has quit IRC
3812016-08-24T12:49:59  *** mkarrer has joined #bitcoin-core-dev
3822016-08-24T12:55:53  *** Ylbam has quit IRC
3832016-08-24T12:57:58  *** kadoban has joined #bitcoin-core-dev
3842016-08-24T13:02:05  *** mkarrer has quit IRC
3852016-08-24T13:02:29  *** cryptapus_ has joined #bitcoin-core-dev
3862016-08-24T13:05:12  *** cryptapus has quit IRC
3872016-08-24T13:23:23  *** TomMc has joined #bitcoin-core-dev
3882016-08-24T13:29:34  *** Ylbam has joined #bitcoin-core-dev
3892016-08-24T13:31:38  *** interseption has joined #bitcoin-core-dev
3902016-08-24T13:32:38  <paveljanik> FWIW, Jeff just merged one univalue PR...
3912016-08-24T13:37:32  *** interseption has quit IRC
3922016-08-24T13:49:52  *** BashCo_ has quit IRC
3932016-08-24T13:50:02  *** BashCo has joined #bitcoin-core-dev
3942016-08-24T13:50:23  *** BashCo has quit IRC
3952016-08-24T13:52:18  *** BashCo has joined #bitcoin-core-dev
3962016-08-24T13:52:29  *** TomMc has quit IRC
3972016-08-24T13:54:27  *** jannes has quit IRC
3982016-08-24T13:57:50  *** jannes has joined #bitcoin-core-dev
3992016-08-24T13:59:51  *** BashCo has quit IRC
4002016-08-24T14:00:06  <jonasschnelli> Oh. Bitcoin-Core 0.13.0 does not run on OSX 10.7, sanity check issue
4012016-08-24T14:01:04  <jonasschnelli> which means ECC or glibc sanity check are firing...
4022016-08-24T14:06:35  *** BashCo has joined #bitcoin-core-dev
4032016-08-24T14:16:35  *** Cheeseo has quit IRC
4042016-08-24T14:16:58  *** Cheeseo has joined #bitcoin-core-dev
4052016-08-24T14:19:39  *** harrymm has quit IRC
4062016-08-24T14:23:31  *** spudowiar has joined #bitcoin-core-dev
4072016-08-24T14:24:46  *** BashCo_ has joined #bitcoin-core-dev
4082016-08-24T14:24:54  *** cryptapus_ has quit IRC
4092016-08-24T14:25:10  *** cryptapus_ has joined #bitcoin-core-dev
4102016-08-24T14:26:18  *** Chris_Stewart_5 has quit IRC
4112016-08-24T14:27:18  *** cryptapus_ is now known as cryptapus
4122016-08-24T14:28:40  *** BashCo has quit IRC
4132016-08-24T14:34:54  *** harrymm has joined #bitcoin-core-dev
4142016-08-24T14:45:41  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4152016-08-24T14:47:15  *** Chris_Stewart_5 has quit IRC
4162016-08-24T15:01:28  *** skyraider has joined #bitcoin-core-dev
4172016-08-24T15:02:46  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4182016-08-24T15:08:47  *** Samdney has joined #bitcoin-core-dev
4192016-08-24T15:10:24  *** Megaf has quit IRC
4202016-08-24T15:21:46  <GitHub13> [bitcoin] MarcoFalke opened pull request #8578: [test] Remove unused code (master...Mf1608-qaUnused) https://github.com/bitcoin/bitcoin/pull/8578
4212016-08-24T15:51:17  *** Giszmo has joined #bitcoin-core-dev
4222016-08-24T15:52:22  <sipa> wumpus: ok, tests run; ~400 lines changed
4232016-08-24T15:53:44  *** laurentmt has joined #bitcoin-core-dev
4242016-08-24T15:54:04  <sipa> i'm not sure if i dare trying to sync
4252016-08-24T15:54:14  *** spudowiar has quit IRC
4262016-08-24T15:54:15  *** laurentmt has quit IRC
4272016-08-24T15:56:59  *** paveljanik has quit IRC
4282016-08-24T15:57:20  *** paveljanik has joined #bitcoin-core-dev
4292016-08-24T16:01:56  *** BashCo_ has quit IRC
4302016-08-24T16:32:08  *** BashCo has joined #bitcoin-core-dev
4312016-08-24T16:34:39  *** Giszmo has quit IRC
4322016-08-24T16:35:08  <sipa> wumpus, gmaxwell: so, i think it works, but there is one giant uglyness
4332016-08-24T16:35:08  *** rubensayshi has quit IRC
4342016-08-24T16:35:30  <sipa> you can't modify the first transaction in a std::vector<CTransaction> without destroying the entire bector
4352016-08-24T16:35:40  <sipa> which is needed in some of the mining code
4362016-08-24T16:36:00  <sipa> two possible solutions: copy the entire transaction set of a block (that's a deep copy, even...)
4372016-08-24T16:36:18  <sipa> or deconstruct and reconstruct the coinbase in-place using placement new
4382016-08-24T16:36:29  <sipa> (which is incredibly ugly, but i think well-defined)
4392016-08-24T16:37:23  <GitHub185> [bitcoin] MarcoFalke opened pull request #8579: Performance: Prefer prefix operator for non-primitive types (master...Mf1608-perfIter) https://github.com/bitcoin/bitcoin/pull/8579
4402016-08-24T16:39:54  *** Giszmo has joined #bitcoin-core-dev
4412016-08-24T16:40:53  *** Chris_Stewart_5 has quit IRC
4422016-08-24T16:41:58  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4432016-08-24T16:47:17  <GitHub18> [bitcoin] sipa opened pull request #8580: Make CTransaction actually immutable (master...pain) https://github.com/bitcoin/bitcoin/pull/8580
4442016-08-24T16:58:29  *** mkarrer has joined #bitcoin-core-dev
4452016-08-24T17:02:30  *** skyraider has quit IRC
4462016-08-24T17:12:01  *** mkarrer has joined #bitcoin-core-dev
4472016-08-24T17:17:52  <MarcoFalke> (master...pain)
4482016-08-24T17:17:54  <MarcoFalke> lol
4492016-08-24T17:28:42  *** jannes has quit IRC
4502016-08-24T17:30:16  <GitHub45> [bitcoin] MarcoFalke opened pull request #8581: [wallet] rpc: Drop misleading option (master...Mf1608-walletDropRpc) https://github.com/bitcoin/bitcoin/pull/8581
4512016-08-24T17:34:54  *** zooko has joined #bitcoin-core-dev
4522016-08-24T17:35:08  <arubi> MarcoFalke, <3 "swinging the (block)chain.."
4532016-08-24T17:36:03  <sipa> MarcoFalke: it was painful!
4542016-08-24T17:36:21  <MarcoFalke> There is more pain to come
4552016-08-24T17:36:40  <MarcoFalke> I suggest you don't look at the travi result
4562016-08-24T17:37:04  <sipa> already on it
4572016-08-24T17:37:36  *** pedrobranco has quit IRC
4582016-08-24T17:38:03  *** pedrobranco has joined #bitcoin-core-dev
4592016-08-24T17:42:09  *** pedrobranco has quit IRC
4602016-08-24T17:42:10  *** harrymm has quit IRC
4612016-08-24T17:56:00  *** zooko has quit IRC
4622016-08-24T17:56:32  *** harrymm has joined #bitcoin-core-dev
4632016-08-24T17:59:56  *** BashCo has quit IRC
4642016-08-24T18:00:19  *** BashCo has joined #bitcoin-core-dev
4652016-08-24T18:07:25  *** mkarrer has quit IRC
4662016-08-24T18:30:57  *** JZA has quit IRC
4672016-08-24T18:36:58  *** Chris_Stewart_5 has quit IRC
4682016-08-24T18:39:04  *** Cheeseo has quit IRC
4692016-08-24T18:46:35  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4702016-08-24T18:47:39  *** Cheeseo has joined #bitcoin-core-dev
4712016-08-24T18:50:26  *** Cheeseo has quit IRC
4722016-08-24T18:50:47  *** Cheeseo has joined #bitcoin-core-dev
4732016-08-24T18:50:47  *** Cheeseo has joined #bitcoin-core-dev
4742016-08-24T18:55:21  *** Cheeseo has quit IRC
4752016-08-24T19:29:15  *** Megaf has joined #bitcoin-core-dev
4762016-08-24T19:31:41  *** Cheeseo has joined #bitcoin-core-dev
4772016-08-24T19:31:41  *** Cheeseo has joined #bitcoin-core-dev
4782016-08-24T19:32:52  *** Chris_Stewart_5 has quit IRC
4792016-08-24T19:48:48  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4802016-08-24T19:52:45  <cfields_> wumpus: yes, boost::chrono is very much in my sights. Got to dump boost::condition_variable first, though.
4812016-08-24T19:53:31  <cfields_> wumpus: I'm making headway on killing off the interruptible threads. I slashed a bunch of them last week, but got distracted with something else.
4822016-08-24T19:58:02  *** Chris_Stewart_5 has quit IRC
4832016-08-24T19:58:32  *** cryptapus has quit IRC
4842016-08-24T20:00:41  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4852016-08-24T20:08:09  *** pedrobranco has joined #bitcoin-core-dev
4862016-08-24T20:13:04  *** pedrobranco has quit IRC
4872016-08-24T20:20:18  *** nibor has joined #bitcoin-core-dev
4882016-08-24T20:43:10  *** Chris_Stewart_5 has quit IRC
4892016-08-24T20:45:40  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4902016-08-24T21:01:18  *** Chris_Stewart_5 has quit IRC
4912016-08-24T21:02:49  *** belcher has joined #bitcoin-core-dev
4922016-08-24T21:27:14  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4932016-08-24T21:31:44  *** Megaf has quit IRC
4942016-08-24T21:40:59  *** spudowiar has joined #bitcoin-core-dev
4952016-08-24T21:50:31  *** cryptapus_afk is now known as cryptapus
4962016-08-24T21:51:04  *** whphhg has quit IRC
4972016-08-24T21:51:17  *** whphhg has joined #bitcoin-core-dev
4982016-08-24T21:51:38  *** whphhg has quit IRC
4992016-08-24T21:51:53  *** whphhg has joined #bitcoin-core-dev
5002016-08-24T21:52:53  *** cryptapus is now known as cryptapus_afk
5012016-08-24T21:53:20  *** JZA has joined #bitcoin-core-dev
5022016-08-24T22:05:16  *** spudowiar has quit IRC
5032016-08-24T22:06:51  *** pedrobranco has joined #bitcoin-core-dev
5042016-08-24T22:22:38  *** murch has quit IRC
5052016-08-24T22:27:45  *** pedrobranco has quit IRC
5062016-08-24T22:28:19  *** pedrobranco has joined #bitcoin-core-dev
5072016-08-24T22:42:52  *** tom3 has joined #bitcoin-core-dev
5082016-08-24T22:55:13  *** pedrobranco has quit IRC
5092016-08-24T22:55:26  *** pedrobranco has joined #bitcoin-core-dev
5102016-08-24T22:55:59  *** pedrobranco has joined #bitcoin-core-dev
5112016-08-24T23:00:34  *** pedrobranco has quit IRC
5122016-08-24T23:21:54  *** tom3 has quit IRC
5132016-08-24T23:26:39  <kanzure> wumpus: is there an issue or pull request for http/2 things?
5142016-08-24T23:26:41  *** JZA has quit IRC
5152016-08-24T23:27:48  <kanzure> wumpus: specifically i am wondering what you meant by "http streaming"
5162016-08-24T23:28:46  *** pedrobranco has joined #bitcoin-core-dev
5172016-08-24T23:42:42  *** harrymm has quit IRC
5182016-08-24T23:43:54  *** belcher has quit IRC
5192016-08-24T23:59:59  *** justanotheruser has quit IRC