12017-04-19T00:02:56  *** AaronvanW has quit IRC
  22017-04-19T00:03:46  *** AaronvanW has joined #bitcoin-core-dev
  32017-04-19T00:09:35  *** AaronvanW has quit IRC
  42017-04-19T00:11:08  *** AaronvanW has joined #bitcoin-core-dev
  52017-04-19T00:11:37  *** d_t has quit IRC
  62017-04-19T00:11:58  *** d_t has joined #bitcoin-core-dev
  72017-04-19T00:14:10  *** NewLiberty has quit IRC
  82017-04-19T00:14:43  *** juscamarena has quit IRC
  92017-04-19T00:16:28  *** juscamarena has joined #bitcoin-core-dev
 102017-04-19T00:16:53  *** juscamarena is now known as Guest36442
 112017-04-19T00:21:40  *** AaronvanW has quit IRC
 122017-04-19T00:23:35  *** NewLiberty has joined #bitcoin-core-dev
 132017-04-19T00:25:26  *** d_t has quit IRC
 142017-04-19T00:40:57  *** Ylbam has quit IRC
 152017-04-19T00:47:26  *** Giszmo has quit IRC
 162017-04-19T00:47:59  *** talmai has joined #bitcoin-core-dev
 172017-04-19T00:54:28  *** jeremyrubin has quit IRC
 182017-04-19T00:55:24  *** jeremyrubin has joined #bitcoin-core-dev
 192017-04-19T00:56:54  *** jtimon has quit IRC
 202017-04-19T00:58:10  *** talmai has quit IRC
 212017-04-19T00:59:13  *** tw2006 has joined #bitcoin-core-dev
 222017-04-19T01:04:02  *** tw2006 has quit IRC
 232017-04-19T01:05:37  *** Giszmo has joined #bitcoin-core-dev
 242017-04-19T01:12:20  *** goksinen has joined #bitcoin-core-dev
 252017-04-19T01:13:11  *** goksinen has joined #bitcoin-core-dev
 262017-04-19T01:14:45  *** goksinen has quit IRC
 272017-04-19T01:15:30  *** goksinen has joined #bitcoin-core-dev
 282017-04-19T01:16:43  *** dodomojo has joined #bitcoin-core-dev
 292017-04-19T01:19:19  *** AaronvanW has joined #bitcoin-core-dev
 302017-04-19T01:20:42  *** goksinen has quit IRC
 312017-04-19T01:24:15  *** AaronvanW has quit IRC
 322017-04-19T01:32:41  *** jl2012 has joined #bitcoin-core-dev
 332017-04-19T01:49:26  *** dodomojo has quit IRC
 342017-04-19T01:50:03  *** goksinen has joined #bitcoin-core-dev
 352017-04-19T02:06:33  *** d_t has joined #bitcoin-core-dev
 362017-04-19T02:11:53  *** belcher has quit IRC
 372017-04-19T02:16:55  *** dodomojo has joined #bitcoin-core-dev
 382017-04-19T02:19:36  *** pepe__ has joined #bitcoin-core-dev
 392017-04-19T02:19:57  *** goksinen has quit IRC
 402017-04-19T02:31:20  *** AaronvanW has joined #bitcoin-core-dev
 412017-04-19T02:35:42  *** AaronvanW has quit IRC
 422017-04-19T02:38:00  *** AaronvanW has joined #bitcoin-core-dev
 432017-04-19T02:39:50  *** d_t has quit IRC
 442017-04-19T02:42:49  *** pepe__ has quit IRC
 452017-04-19T02:43:10  *** pepe__ has joined #bitcoin-core-dev
 462017-04-19T02:44:23  *** AaronvanW has quit IRC
 472017-04-19T02:45:47  *** AaronvanW has joined #bitcoin-core-dev
 482017-04-19T02:45:59  *** pepe__ has quit IRC
 492017-04-19T02:46:20  *** pepe__ has joined #bitcoin-core-dev
 502017-04-19T02:47:17  *** pepe__ has joined #bitcoin-core-dev
 512017-04-19T02:48:11  *** tw2006 has joined #bitcoin-core-dev
 522017-04-19T02:52:56  *** tw2006 has quit IRC
 532017-04-19T02:58:25  <bitcoin-git> [bitcoin] jimmysong opened pull request #10229: Tests: Add test for getdifficulty (master...test_getdifficulty) https://github.com/bitcoin/bitcoin/pull/10229
 542017-04-19T03:00:40  *** AaronvanW has quit IRC
 552017-04-19T03:03:26  *** AaronvanW has joined #bitcoin-core-dev
 562017-04-19T03:17:35  *** AaronvanW has quit IRC
 572017-04-19T03:23:23  *** AaronvanW has joined #bitcoin-core-dev
 582017-04-19T03:41:20  *** AaronvanW has quit IRC
 592017-04-19T03:48:41  *** AaronvanW has joined #bitcoin-core-dev
 602017-04-19T04:14:12  *** AaronvanW has quit IRC
 612017-04-19T04:15:18  *** mol has joined #bitcoin-core-dev
 622017-04-19T04:18:32  *** molz_ has quit IRC
 632017-04-19T04:18:54  *** mol has quit IRC
 642017-04-19T04:19:12  *** mol has joined #bitcoin-core-dev
 652017-04-19T04:22:50  *** AaronvanW has joined #bitcoin-core-dev
 662017-04-19T04:23:38  *** moli_ has joined #bitcoin-core-dev
 672017-04-19T04:24:30  *** mol has quit IRC
 682017-04-19T04:25:43  *** dodomojo has quit IRC
 692017-04-19T04:31:44  *** fao has quit IRC
 702017-04-19T04:32:01  *** arowser has quit IRC
 712017-04-19T04:37:14  *** tw2006 has joined #bitcoin-core-dev
 722017-04-19T04:37:25  *** arowser has joined #bitcoin-core-dev
 732017-04-19T04:38:30  *** AaronvanW has quit IRC
 742017-04-19T04:39:03  *** fao has joined #bitcoin-core-dev
 752017-04-19T04:41:50  *** tw2006 has quit IRC
 762017-04-19T04:45:04  *** AaronvanW has joined #bitcoin-core-dev
 772017-04-19T04:57:05  *** AaronvanW has quit IRC
 782017-04-19T04:59:59  *** AaronvanW has joined #bitcoin-core-dev
 792017-04-19T05:11:40  *** goksinen has joined #bitcoin-core-dev
 802017-04-19T05:13:57  *** pepe__ has quit IRC
 812017-04-19T05:16:29  *** goksinen has quit IRC
 822017-04-19T05:20:32  *** Chris_Stewart_5 has quit IRC
 832017-04-19T05:22:38  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 842017-04-19T05:22:50  *** d9b4bef9 has quit IRC
 852017-04-19T05:23:57  *** d9b4bef9 has joined #bitcoin-core-dev
 862017-04-19T05:28:05  *** AaronvanW has quit IRC
 872017-04-19T05:33:03  *** AaronvanW has joined #bitcoin-core-dev
 882017-04-19T05:43:17  *** RubenSomsen has joined #bitcoin-core-dev
 892017-04-19T05:48:40  *** AaronvanW has quit IRC
 902017-04-19T05:52:30  *** Chris_Stewart_5 has quit IRC
 912017-04-19T05:52:51  *** Giszmo has quit IRC
 922017-04-19T05:53:00  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 932017-04-19T06:00:08  *** dermoth has quit IRC
 942017-04-19T06:00:48  *** dermoth has joined #bitcoin-core-dev
 952017-04-19T06:06:17  *** goksinen has joined #bitcoin-core-dev
 962017-04-19T06:10:41  *** goksinen has quit IRC
 972017-04-19T06:13:07  *** AaronvanW has joined #bitcoin-core-dev
 982017-04-19T06:17:05  *** NewLiberty has quit IRC
 992017-04-19T06:21:12  *** fao has quit IRC
1002017-04-19T06:22:45  *** fao has joined #bitcoin-core-dev
1012017-04-19T06:25:42  *** AaronvanW has quit IRC
1022017-04-19T06:26:04  *** tw2006 has joined #bitcoin-core-dev
1032017-04-19T06:30:38  *** tw2006 has quit IRC
1042017-04-19T06:34:00  *** AaronvanW has joined #bitcoin-core-dev
1052017-04-19T06:39:50  *** AaronvanW has quit IRC
1062017-04-19T06:42:35  *** AaronvanW has joined #bitcoin-core-dev
1072017-04-19T06:47:24  *** AaronvanW has quit IRC
1082017-04-19T06:49:37  *** AaronvanW has joined #bitcoin-core-dev
1092017-04-19T07:03:44  *** kexkey has quit IRC
1102017-04-19T07:04:35  *** AaronvanW has quit IRC
1112017-04-19T07:05:34  *** AaronvanW has joined #bitcoin-core-dev
1122017-04-19T07:18:42  *** AaronvanW has quit IRC
1132017-04-19T07:22:59  *** AaronvanW has joined #bitcoin-core-dev
1142017-04-19T07:34:04  *** AaronvanW has quit IRC
1152017-04-19T07:36:39  *** AaronvanW has joined #bitcoin-core-dev
1162017-04-19T07:38:13  <wumpus> git add --patch is so useful
1172017-04-19T07:40:05  <wumpus> it's essential if you want to add just some changes in a file to a commit but not all. Only discovered this recently, don't ask what hacks I was doing to accomplish that before...
1182017-04-19T07:41:02  <sipa> you can also use it split existing commits
1192017-04-19T07:41:24  <sipa> during a rebase, while editing a commit, use git reset HEAD~
1202017-04-19T07:41:39  <sipa> then git add -p to select the changes to be in the first half
1212017-04-19T07:41:54  <sipa> git commit -m first; git commit -am second
1222017-04-19T07:42:18  <wumpus> 'git gui' can also be used for this (you can stage and unstage individual lines, even), but usually work in the console so that was kind of annoying
1232017-04-19T07:42:27  <wumpus> ah great
1242017-04-19T07:42:53  <sipa> and then git rebase --continue
1252017-04-19T07:43:05  *** AaronvanW has quit IRC
1262017-04-19T07:43:48  *** AaronvanW has joined #bitcoin-core-dev
1272017-04-19T07:48:08  *** AaronvanW has quit IRC
1282017-04-19T07:56:54  *** AaronvanW has joined #bitcoin-core-dev
1292017-04-19T07:59:12  <wumpus> is there anything (almost) ready for merging?
1302017-04-19T07:59:39  *** Novella has joined #bitcoin-core-dev
1312017-04-19T08:01:42  *** AaronvanW has quit IRC
1322017-04-19T08:04:12  *** Novella has quit IRC
1332017-04-19T08:04:30  *** AaronvanW has joined #bitcoin-core-dev
1342017-04-19T08:05:10  *** Dahlia2 has joined #bitcoin-core-dev
1352017-04-19T08:10:49  *** AaronvanW has quit IRC
1362017-04-19T08:14:58  *** tw2006 has joined #bitcoin-core-dev
1372017-04-19T08:19:37  *** tw2006 has quit IRC
1382017-04-19T08:23:58  *** AaronvanW has joined #bitcoin-core-dev
1392017-04-19T08:26:02  <wumpus> thought #10143 was, but needs some minor changes still
1402017-04-19T08:26:04  <gribble> https://github.com/bitcoin/bitcoin/issues/10143 | [net] Allow disconnectnode RPC to be called with node id by jnewbery · Pull Request #10143 · bitcoin/bitcoin · GitHub
1412017-04-19T08:33:06  <bitcoin-git> [bitcoin] laanwj closed pull request #9524: rpc: Don't FlushStateToDisk when pruneblockchain(0) (master...Mf1701-qaPruning) https://github.com/bitcoin/bitcoin/pull/9524
1422017-04-19T08:41:35  *** AaronvanW has quit IRC
1432017-04-19T08:42:26  <paveljanik> wumpus, #10226?
1442017-04-19T08:42:27  <gribble> https://github.com/bitcoin/bitcoin/issues/10226 | wallet: Use boost to more portably ensure -wallet specifies only a filename by luke-jr · Pull Request #10226 · bitcoin/bitcoin · GitHub
1452017-04-19T08:44:21  *** nOgAnOo has joined #bitcoin-core-dev
1462017-04-19T08:44:56  <wumpus> yes, that one is very straightforward
1472017-04-19T08:51:44  *** AaronvanW has joined #bitcoin-core-dev
1482017-04-19T08:55:40  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9111df9673be...64c45aada702
1492017-04-19T08:55:40  <bitcoin-git> bitcoin/master a4186dd Luke Dashjr: wallet: Use boost to more portably ensure -wallet specifies only a filename
1502017-04-19T08:55:41  <bitcoin-git> bitcoin/master 64c45aa Wladimir J. van der Laan: Merge #10226: wallet: Use boost to more portably ensure -wallet specifies only a filename...
1512017-04-19T08:56:04  <bitcoin-git> [bitcoin] laanwj closed pull request #10226: wallet: Use boost to more portably ensure -wallet specifies only a filename (master...refactor_wallet_pathsep) https://github.com/bitcoin/bitcoin/pull/10226
1522017-04-19T08:57:18  *** AaronvanW has quit IRC
1532017-04-19T09:03:44  *** AaronvanW has joined #bitcoin-core-dev
1542017-04-19T09:03:45  *** AaronvanW has joined #bitcoin-core-dev
1552017-04-19T09:10:38  *** AaronvanW has quit IRC
1562017-04-19T09:11:50  *** d9b4bef9 has quit IRC
1572017-04-19T09:12:55  *** d9b4bef9 has joined #bitcoin-core-dev
1582017-04-19T09:14:15  *** PaulCape_ has joined #bitcoin-core-dev
1592017-04-19T09:15:05  *** AaronvanW has joined #bitcoin-core-dev
1602017-04-19T09:15:32  <bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/64c45aada702...e96486cbebc6
1612017-04-19T09:15:33  <bitcoin-git> bitcoin/master 608bbcc Matt Corallo: [qt] Stop treating coinbase outputs differently: show them at 1conf
1622017-04-19T09:15:33  <bitcoin-git> bitcoin/master e96486c Jonas Schnelli: Merge #10221: Stop treating coinbase outputs differently in GUI: show them at 1conf...
1632017-04-19T09:15:53  <bitcoin-git> [bitcoin] jonasschnelli closed pull request #10221: Stop treating coinbase outputs differently in GUI: show them at 1conf (master...2017-04-no-coinbase-display-lag) https://github.com/bitcoin/bitcoin/pull/10221
1642017-04-19T09:16:53  *** PaulCapestany has quit IRC
1652017-04-19T09:21:00  <jonasschnelli> Anyone has an opinion on: https://github.com/bitcoin/bitcoin/pull/9502
1662017-04-19T09:21:18  <jonasschnelli> I think it's useful even if there is the "hidden" feature of clicking the peers-statusbar-icon
1672017-04-19T09:22:05  *** AaronvanW has quit IRC
1682017-04-19T09:23:10  *** AaronvanW has joined #bitcoin-core-dev
1692017-04-19T09:32:05  *** AaronvanW has quit IRC
1702017-04-19T09:40:11  *** AaronvanW has joined #bitcoin-core-dev
1712017-04-19T09:44:42  *** AaronvanW has quit IRC
1722017-04-19T09:46:26  *** AaronvanW has joined #bitcoin-core-dev
1732017-04-19T09:50:42  *** AaronvanW has quit IRC
1742017-04-19T09:51:47  *** AaronvanW has joined #bitcoin-core-dev
1752017-04-19T09:56:42  *** AaronvanW has quit IRC
1762017-04-19T09:56:51  *** Ylbam has joined #bitcoin-core-dev
1772017-04-19T09:58:28  *** AaronvanW has joined #bitcoin-core-dev
1782017-04-19T09:59:18  *** AaronvanW has quit IRC
1792017-04-19T09:59:34  *** AaronvanW has joined #bitcoin-core-dev
1802017-04-19T10:03:54  *** tw2006 has joined #bitcoin-core-dev
1812017-04-19T10:08:36  *** tw2006 has quit IRC
1822017-04-19T10:19:05  *** Guyver2 has joined #bitcoin-core-dev
1832017-04-19T10:24:33  <jonasschnelli> I think this is RFM: https://github.com/bitcoin/bitcoin/pull/9827
1842017-04-19T10:29:33  <wumpus> yep, thanks
1852017-04-19T10:30:25  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e96486cbebc6...c91ca0ace9bd
1862017-04-19T10:30:26  <bitcoin-git> bitcoin/master 30abce7 Russell Yanofsky: Improve ScanForWalletTransactions return value...
1872017-04-19T10:30:26  <bitcoin-git> bitcoin/master c91ca0a Wladimir J. van der Laan: Merge #9827: Improve ScanForWalletTransactions return value...
1882017-04-19T10:30:39  <bitcoin-git> [bitcoin] laanwj closed pull request #9827: Improve ScanForWalletTransactions return value (master...pr/scanret) https://github.com/bitcoin/bitcoin/pull/9827
1892017-04-19T10:36:31  *** goksinen has joined #bitcoin-core-dev
1902017-04-19T10:37:17  <wumpus> jonasschnelli: and yes I think it can be a useful feature
1912017-04-19T10:37:32  <jonasschnelli> wumpus: Thanks for the review.
1922017-04-19T10:37:36  <jonasschnelli> Will fix your points soon
1932017-04-19T10:41:10  *** goksinen has quit IRC
1942017-04-19T10:45:05  *** RubenSomsen has quit IRC
1952017-04-19T10:50:26  *** face has quit IRC
1962017-04-19T10:56:51  *** tw2006 has joined #bitcoin-core-dev
1972017-04-19T10:57:29  *** pepe__ has joined #bitcoin-core-dev
1982017-04-19T11:03:14  *** BashCo has joined #bitcoin-core-dev
1992017-04-19T11:05:42  *** Soligor has quit IRC
2002017-04-19T11:06:09  *** face has joined #bitcoin-core-dev
2012017-04-19T11:10:12  *** Soligor has joined #bitcoin-core-dev
2022017-04-19T11:27:34  *** nOgAnOo has quit IRC
2032017-04-19T11:30:51  *** goksinen has joined #bitcoin-core-dev
2042017-04-19T11:35:24  *** goksinen has quit IRC
2052017-04-19T11:36:23  *** laurentmt has joined #bitcoin-core-dev
2062017-04-19T11:56:07  *** Dahlia2 has quit IRC
2072017-04-19T11:56:08  *** NewLiberty has joined #bitcoin-core-dev
2082017-04-19T11:58:44  *** jtimon has joined #bitcoin-core-dev
2092017-04-19T12:09:01  *** tw2006 has quit IRC
2102017-04-19T12:14:23  *** To7 has quit IRC
2112017-04-19T12:14:53  *** RubenSomsen has joined #bitcoin-core-dev
2122017-04-19T12:26:01  *** laurentmt has quit IRC
2132017-04-19T12:31:05  <instagibbs> wumpus, git add -p also works line by line, in manual edit mode
2142017-04-19T12:32:28  <instagibbs> 's' to keep splitting chunks, if not granular enough, 'e' for manual editor. A bit confusing at first but description is at end.
2152017-04-19T12:33:09  *** NielsvG` is now known as NielsvG
2162017-04-19T12:36:51  <wumpus> instagibbs: ah :) thanks
2172017-04-19T12:43:49  *** nu11p7r has quit IRC
2182017-04-19T12:48:06  *** tw2006 has joined #bitcoin-core-dev
2192017-04-19T12:52:51  *** wasi has joined #bitcoin-core-dev
2202017-04-19T12:53:35  *** To7 has joined #bitcoin-core-dev
2212017-04-19T13:15:38  *** owowo has quit IRC
2222017-04-19T13:18:19  *** jannes has joined #bitcoin-core-dev
2232017-04-19T13:18:51  *** goksinen has joined #bitcoin-core-dev
2242017-04-19T13:23:40  *** goksinen has quit IRC
2252017-04-19T13:34:51  *** SopaXorzTaker has joined #bitcoin-core-dev
2262017-04-19T13:46:39  *** owowo has joined #bitcoin-core-dev
2272017-04-19T13:46:40  *** owowo has joined #bitcoin-core-dev
2282017-04-19T13:50:12  *** d_t has joined #bitcoin-core-dev
2292017-04-19T13:54:17  *** RubenSomsen has quit IRC
2302017-04-19T14:04:22  *** timothy has joined #bitcoin-core-dev
2312017-04-19T14:08:00  *** talmai has joined #bitcoin-core-dev
2322017-04-19T14:13:13  *** goksinen has joined #bitcoin-core-dev
2332017-04-19T14:17:17  *** goksinen has quit IRC
2342017-04-19T14:19:34  <BlueMatt> sipa: re #10148: I'm still super unconvinced that multi-head is worth it. in the future optimization space of "flush in chunks in the background", there is relatively little harm in requiring that mid-flush-states be in only one direction - either you're during ibd, in which cas I'd certainly hope this is already the case, or you're not in which case it should be relatively rare that your disk cant keep up and enforcing a
2352017-04-19T14:19:35  <BlueMatt> fully-flushed state prior to block disconnect seems perfectly reasonable
2362017-04-19T14:19:38  <gribble> https://github.com/bitcoin/bitcoin/issues/10148 | [WIP] Use non-atomic flushing with block replay by sipa · Pull Request #10148 · bitcoin/bitcoin · GitHub
2372017-04-19T14:19:52  <BlueMatt> sipa: not to mention multihead is super hard to review right now since we dont even have the write side of it implemented
2382017-04-19T14:20:00  <BlueMatt> so the assumptions on the read side just seem arbitrary
2392017-04-19T14:20:07  <BlueMatt> (and complicated)
2402017-04-19T14:20:14  <sipa> BlueMatt: i don't think it's reasonanle to require a full flush before a reorg
2412017-04-19T14:21:04  <sipa> reorgs should lead to network-wide slowdowns
2422017-04-19T14:21:29  <sipa> and the write side is partially implemented; i'm writing a test for it now
2432017-04-19T14:24:22  *** n1ce has joined #bitcoin-core-dev
2442017-04-19T14:25:07  <BlueMatt> sipa: why? if your node cant finish flushing its state before the next block comes in 9 times out of 10 you have no hope of staying up to date anyway
2452017-04-19T14:25:36  <sipa> BlueMatt: the idea is that you'd be flushing continuously
2462017-04-19T14:25:42  <sipa> and never fully flush
2472017-04-19T14:25:49  <BlueMatt> sipa: why?
2482017-04-19T14:25:55  <BlueMatt> why would you want to never fully flush
2492017-04-19T14:26:00  <BlueMatt> that'd mean startup would always be painfully slow
2502017-04-19T14:26:01  <sipa> because wiping your cache is retarded
2512017-04-19T14:26:16  <BlueMatt> well then dont wipe cache when you flush :)
2522017-04-19T14:26:25  <BlueMatt> thats an orthogonal issue, i think
2532017-04-19T14:26:29  <sipa> it isn't
2542017-04-19T14:26:39  <sipa> if you don't wipe when you flush, you need to flush more frequently
2552017-04-19T14:26:59  <sipa> and we've benchmarked that (before non-atomic flush)... it's slower
2562017-04-19T14:26:59  <BlueMatt> what happened to always flushing in the background?
2572017-04-19T14:27:40  <sipa> we're already flushing outside of normal block connection
2582017-04-19T14:27:54  *** RubenSomsen has joined #bitcoin-core-dev
2592017-04-19T14:27:59  <sipa> it's still just more CPU to not wipe your cache
2602017-04-19T14:28:08  <morcos> sipa: at the very least this is an unnecessarily complicated optimization for right now
2612017-04-19T14:28:11  <sipa> (again, before non-atomic)
2622017-04-19T14:28:34  <morcos> this code is difficult to reason about with high certainty and i think BlueMatt is right that multi-head really compounds that
2632017-04-19T14:28:48  <morcos> If we decide we need it later, we can discuss it then...
2642017-04-19T14:29:08  <sipa> morcos: i think both the test code i'm writing and the recovery code would he hardly any simpler without it
2652017-04-19T14:29:23  <sipa> it still needs to be able to deal with reorgs, just not multi-headed ones
2662017-04-19T14:29:24  <morcos> Ideally I think we would do #10195 first and not make that contingent on 10148 (w or w/o multihead)
2672017-04-19T14:29:26  <gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
2682017-04-19T14:29:37  <sipa> oh
2692017-04-19T14:29:42  <sipa> that's certainly possible
2702017-04-19T14:30:54  <morcos> the issue i see with 10148 is that it seems like a lot of complication to solve a relatively simple problem about the way leveldb flushes...   it seems to me it would make more sense to review flush/don't erase strategies with 10195 as a first step
2712017-04-19T14:30:59  <BlueMatt> sipa: I'm more than happy to revisit multihead after per-utxo, but right now I'm super worried about the complication in it
2722017-04-19T14:31:29  <sipa> BlueMatt: if i put an assert(blockhead.size() == 2), would you be happy about it?
2732017-04-19T14:31:44  <morcos> maybe we eventually want to do 10148, but i'm hesitant to rework cache writiing in 2 big ways at the same time...
2742017-04-19T14:32:01  <sipa> i think 10148 is much more urgent
2752017-04-19T14:32:17  <sipa> it dramatically changes our memory usage
2762017-04-19T14:32:25  <morcos> so does 10195?
2772017-04-19T14:32:38  <sipa> how so?
2782017-04-19T14:32:57  <morcos> for the same cache performance you can have a much smaller cache
2792017-04-19T14:33:29  <sipa> eh, slightly
2802017-04-19T14:33:55  <sipa> anyway, i'm happy to rebase 10195 without 10148
2812017-04-19T14:34:04  <sipa> i just assumed we'd want 10148 sooner
2822017-04-19T14:34:39  *** RubenSomsen has quit IRC
2832017-04-19T14:34:45  <BlueMatt> sipa: possibly I'd be ok with an assert like that, but then why have the much more complicated code in our consensus logic when we can push that review to when we actually remove the assert, right where it should be? Otherwise you have dormant code and people wont sufficiently review it when it becomes active?
2842017-04-19T14:34:51  <morcos> really?  only slightly?  i haven't tested 10195 yet, but it was my memory that a lot of the cache mem usage was taken up with dead weight from txs you bring along
2852017-04-19T14:35:00  <BlueMatt> I tend to agree that I like 10148, personally
2862017-04-19T14:35:15  <BlueMatt> i mean both, dont really care tooo much about order, just dont think we need to worry about multi-head
2872017-04-19T14:35:22  <sipa> morcos: but with 10195 you get duplication instead
2882017-04-19T14:35:39  <morcos> in memory?
2892017-04-19T14:35:41  <sipa> yes
2902017-04-19T14:35:54  <morcos> oh i havent' reveiwed 10195 yet, i was envisioning a structure without duplication
2912017-04-19T14:35:55  <sipa> if multiple outputs for the same tx are in the cache, they become independent entries
2922017-04-19T14:36:03  <morcos> like a multi level cache
2932017-04-19T14:36:20  <sipa> we can think about that later, first switch the model to be per-txout
2942017-04-19T14:36:44  <morcos> ok, well i'll shut up until i review more... but i have to say, the complication of 10148 turns me off from getting to 10195!
2952017-04-19T14:37:00  <sipa> have you seen the commit i just added to 10148?
2962017-04-19T14:37:35  <sipa> well, yesterdat
2972017-04-19T14:37:40  <morcos> Yes...  And the part that is confusing is the Multiple reorganizations
2982017-04-19T14:37:55  <morcos> Thats still not clear to me exactly what scenario you guys are envisioning that results in that
2992017-04-19T14:38:20  <BlueMatt> frankly, we only have 2.5 months before 0.15 feature freeze, and we're gonna get in half of what people are PRing these days
3002017-04-19T14:38:37  <sipa> multiple reorgs, with partial flushing
3012017-04-19T14:38:40  <morcos> the rest of that comment is very good though
3022017-04-19T14:38:58  * BlueMatt is entirely unconvinced thats a thing we need to ever worry about
3032017-04-19T14:39:21  <BlueMatt> unless we never fully flush, but if we never fully flush startup will /always/ be painfully slow
3042017-04-19T14:39:25  <BlueMatt> which i also dont think is acceptable
3052017-04-19T14:39:38  <sipa> how so?
3062017-04-19T14:39:44  <sipa> it would just lag a few blocks behind
3072017-04-19T14:40:01  <sdaftuar> how would it only be a few blocks behind?
3082017-04-19T14:40:35  <sipa> at least it's configurable... during IBD it could lag behind more
3092017-04-19T14:40:53  <BlueMatt> during ibd you only need single-head, though, I think
3102017-04-19T14:40:58  <BlueMatt> it should be pretty much all serial
3112017-04-19T14:41:08  <sipa> sure, but i don't want two separate recovery algorithms
3122017-04-19T14:41:15  <BlueMatt> huh?
3132017-04-19T14:41:42  <morcos> I just think its too many steps at once...   Matt and Suhas are trying to explain to me what the series of events that happens here is and I just don't understand
3142017-04-19T14:41:49  <BlueMatt> sipa: I'm saying never support recovery of multiple reorgs at once
3152017-04-19T14:42:09  <sipa> BlueMatt: it's maybe 5 lines less code!
3162017-04-19T14:42:28  <sipa> instead of rolling back from one branch, you roll back from all of them
3172017-04-19T14:42:31  <morcos> I don't understand what a partial flush is
3182017-04-19T14:42:39  <sipa> morcos: write some of the entries in your cache to disk
3192017-04-19T14:42:45  <sipa> instead of all
3202017-04-19T14:42:46  <morcos> And then what?
3212017-04-19T14:42:53  <BlueMatt> and then...thats it?
3222017-04-19T14:42:54  <sipa> continue
3232017-04-19T14:43:18  <sipa> you're running out of memory, pick a few dirty entries in the cache, and write those to disk
3242017-04-19T14:43:24  <sipa> and perhaps delete a few non-dirty entries
3252017-04-19T14:43:26  <sipa> and continue
3262017-04-19T14:43:38  <sipa> there are tons of tweaks and analysis possible to find good strategies
3272017-04-19T14:43:48  <sipa> but non-atomic flushing makes all of it safe
3282017-04-19T14:43:55  <BlueMatt> sipa: but 20 more edge cases in consensus code, 30 more lines of comments to explain why its ok. the previous stuff was very reviewable, now its super tricky unless we /also/ implement the write side (I know you said you have that, but can we leave that for a separate pr?)
3292017-04-19T14:44:03  <morcos> So while you are writing those entries, no one else is modifying the cache...  but then you give up the lock before you've flushed the whole cache, so then when people modify the cache more..  ok i guess  i get it.
3302017-04-19T14:44:19  <morcos> But why can't we save that for a later "improvement" , why is it necessary now?
3312017-04-19T14:44:34  <sipa> morcos: because the algorithm is the same
3322017-04-19T14:44:35  *** tripleslash has quit IRC
3332017-04-19T14:44:47  <sipa> can we just put an assert in it, that forces it to be the simple case?
3342017-04-19T14:45:00  <sipa> so you can review it assuming it only needs to deal with the simple case
3352017-04-19T14:45:10  <morcos> What am I missing, why do you want to have the code there if we are not using it?
3362017-04-19T14:45:23  <sipa> it's 5 lines...
3372017-04-19T14:45:29  <sipa> yes, i can remove it
3382017-04-19T14:46:47  *** tripleslash has joined #bitcoin-core-dev
3392017-04-19T14:47:01  <sipa> but it's nice to at least have the database format support multihead, so it's not yet another backward compatible upgrade that needs upgrade
3402017-04-19T14:47:25  <BlueMatt> hardly? just means you cant downgrade after an unclear shutdown?
3412017-04-19T14:47:38  * BlueMatt is much less concerned about that
3422017-04-19T14:47:38  <sipa> plus new code that needs to deal with the old case
3432017-04-19T14:47:41  <BlueMatt> but maybe others are?
3442017-04-19T14:47:49  <sdaftuar> you can still downgrade with a -reindex-chainstate!
3452017-04-19T14:47:57  <sipa> ok...
3462017-04-19T14:49:13  <sipa> would you be fine with a database format that just has a record saying "rollback block X, rollforward block Y, rollback block Z", and the recovery code literally follows those steps?
3472017-04-19T14:49:52  <sipa> actually, that's pretty complicated on the write side
3482017-04-19T14:50:40  <BlueMatt> possibly, though the "might have had stuff from a future branch way down the line partially flushed" stuff just makes it harder to review consensus-critical crap
3492017-04-19T14:51:14  <sipa> sigh, ok, i'll try to simplify the code as much as possible to only deal with a single reorg
3502017-04-19T14:51:28  <morcos> sipa: i'm not sure that your approach is wrong..  i think its just a lot to hit someone all at once in thinking about it
3512017-04-19T14:51:39  <sipa> morcos: fair enough
3522017-04-19T14:51:49  <BlueMatt> sipa: thanks, now lets get this all merged for 0.14 =D
3532017-04-19T14:51:52  <BlueMatt> ehh, 15
3542017-04-19T14:51:54  <morcos> you might be right that it is a more elegant approach if you have this end goal in mind down the road
3552017-04-19T14:52:22  <morcos> but we're stuck trying to recreate the logical progression you went through to end up there
3562017-04-19T14:52:28  <sipa> understood
3572017-04-19T14:52:49  <sdaftuar> sipa: did you ever test the performance of flush-without-wiping with a per-utxo model?
3582017-04-19T14:52:50  <morcos> that said... i'm getting more comfortable with it after hashing it out a bit
3592017-04-19T14:53:42  <sipa> sdaftuar: i haven't
3602017-04-19T14:56:00  *** pepe__ has quit IRC
3612017-04-19T14:57:10  *** nu11p7r has joined #bitcoin-core-dev
3622017-04-19T15:02:02  <morcos> sipa: another simple improvement would be to instead of having a 2.0x factor for cache memory usage to just track usage =  all cache usage + dirty coins usage
3632017-04-19T15:02:49  <sipa> morcos: i really hope that the non-atomic flushing after simplifying will be simple enough to be reviewed
3642017-04-19T15:03:58  *** Giszmo has joined #bitcoin-core-dev
3652017-04-19T15:20:06  *** tripleslash has quit IRC
3662017-04-19T15:21:26  *** tripleslash has joined #bitcoin-core-dev
3672017-04-19T15:24:09  <sdaftuar> wumpus: i think #9942 is ready for merge
3682017-04-19T15:24:11  <gribble> https://github.com/bitcoin/bitcoin/issues/9942 | Refactor CBlockPolicyEstimator by morcos · Pull Request #9942 · bitcoin/bitcoin · GitHub
3692017-04-19T15:24:52  <bitcoin-git> [bitcoin] jet0 opened pull request #10230: Merge pull request #1 from bitcoin/master (master...freeze) https://github.com/bitcoin/bitcoin/pull/10230
3702017-04-19T15:25:03  <bitcoin-git> [bitcoin] jet0 closed pull request #10230: Merge pull request #1 from bitcoin/master (master...freeze) https://github.com/bitcoin/bitcoin/pull/10230
3712017-04-19T15:29:19  *** tripleslash has quit IRC
3722017-04-19T15:31:44  <jonasschnelli> I have significant freezes in the GUI with current master catching up a couple of days on mainnet..
3732017-04-19T15:32:48  *** tripleslash has joined #bitcoin-core-dev
3742017-04-19T15:33:01  <jonasschnelli> I think this was re-introduced with https://github.com/bitcoin/bitcoin/pull/9583
3752017-04-19T15:33:26  <jonasschnelli> Although not sure...
3762017-04-19T15:34:42  <Lauda> ^happens to me occasionally in 0.14.0
3772017-04-19T15:36:00  <BlueMatt> jonasschnelli: great! review #10179 :p
3782017-04-19T15:36:02  <gribble> https://github.com/bitcoin/bitcoin/issues/10179 | Give CValidationInterface Support for calling notifications on the CScheduler Thread by TheBlueMatt · Pull Request #10179 · bitcoin/bitcoin · GitHub
3792017-04-19T15:36:07  *** n1ce has quit IRC
3802017-04-19T15:38:39  <jonasschnelli> BlueMatt: Oh... I totally forgot that one.. thanks. Will try.
3812017-04-19T15:41:22  <BlueMatt> jonasschnelli: that doesnt do anything by itself
3822017-04-19T15:41:26  <BlueMatt> the real change is the pr after it
3832017-04-19T15:41:29  <BlueMatt> but its blocking :)
3842017-04-19T15:41:33  <jonasschnelli> Okay... thanks.
3852017-04-19T15:41:55  <jonasschnelli> I think the freezes i face are caused by something different then the 9583
3862017-04-19T15:43:03  <sipa> BlueMatt: ha, blocking.
3872017-04-19T15:44:43  <BlueMatt> lol
3882017-04-19T15:45:20  <BlueMatt> jonasschnelli: you may still wish to test my branch which is based on that (https://github.com/TheBlueMatt/bitcoin/tree/2017-01-wallet-cache-inmempool-4, I think, though i believe travis didnt like it last time, i need to go back and fix it prior to pring it)
3892017-04-19T15:45:25  <BlueMatt> would be good feedback if it is faster :)
3902017-04-19T15:46:00  <jonasschnelli> BlueMatt: Yes. I'll give it a try and a review once I have tracked the current freeze down
3912017-04-19T15:46:11  <jonasschnelli> *tracked down the current freeze
3922017-04-19T15:52:23  <cfields> jonasschnelli: https://github.com/bitcoin/bitcoin/issues/10209#issuecomment-295311664
3932017-04-19T15:52:27  <cfields> $10 says it's that :)
3942017-04-19T15:53:20  <jonasschnelli> cfields: But don't I need https://github.com/bitcoin/bitcoin/issues/10228?
3952017-04-19T15:53:54  <cfields> jonasschnelli: 10228 just keeps it from happening in the future. Problem is that your bitcoin-config.h is busted atm
3962017-04-19T15:54:03  <cfields> (i strongly suspect, anyway)
3972017-04-19T15:54:20  <jonasschnelli> ah... I see. That seams reasonable...
3982017-04-19T15:55:09  <cfields> jonasschnelli: specifically MSG_DONTWAIT. Are you seeing a warning about it when you build?
3992017-04-19T15:55:23  <jonasschnelli> oh.. maybe. :|
4002017-04-19T15:55:52  <cfields> if so, this is your problem, and autogen will fix you right up.
4012017-04-19T15:56:49  *** d9b4bef9 has quit IRC
4022017-04-19T15:57:56  *** d9b4bef9 has joined #bitcoin-core-dev
4032017-04-19T16:05:42  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #10231: [Qt] Reduce a significant cs_main lock freeze (master...2017/04/qt_freeze) https://github.com/bitcoin/bitcoin/pull/10231
4042017-04-19T16:08:13  <cfields> jonasschnelli: why not subscribe to UpdatedBlockTip() and cache it there?
4052017-04-19T16:14:31  <jonasschnelli> cfields: IMO we don't have a signal that covers the bestheader (not bestblock)
4062017-04-19T16:14:36  *** abpa has joined #bitcoin-core-dev
4072017-04-19T16:15:34  <jonasschnelli> ermm... we have NotifyHeaderTip
4082017-04-19T16:15:37  *** Guyver2 has quit IRC
4092017-04-19T16:16:40  <jonasschnelli> cfields: Do you think it would be preferable to cache it in the GUI clientmodel instead of the core validation part (validation.cpp)?
4102017-04-19T16:16:44  <cfields> jonasschnelli: heh, I just grepped to the same conclusion :)
4112017-04-19T16:17:14  <jonasschnelli> cfields: Yes. I could cache it in "static void BlockTipChanged(ClientModel *clientmodel, bool initialSync, const CBlockIndex *pIndex, bool fHeader)"
4122017-04-19T16:17:18  <jonasschnelli> when fHeader == true
4132017-04-19T16:17:40  <cfields> jonasschnelli: i think it makes sense for each subsystem to maintain their own view of those things, yes
4142017-04-19T16:17:54  <jonasschnelli> Yes. Let me change this... I don't think there are valid use cases outside the GUI
4152017-04-19T16:17:59  <cfields> (not sure everyone would agree with that, but that's the direction we've been moving in)
4162017-04-19T16:18:01  <jonasschnelli> cfields: indeed.
4172017-04-19T16:19:49  <cfields> jonasschnelli: the exception obviously being if you need atomic access to a few locally cached things, in which case you have to be careful to keep everything in sync. But if it's just for the gui, I think caching it there makes sense.
4182017-04-19T16:20:22  <jonasschnelli> Yes. Right... i'll change the PR
4192017-04-19T16:24:52  *** laurentmt has joined #bitcoin-core-dev
4202017-04-19T16:28:20  *** Dyaheon has quit IRC
4212017-04-19T16:31:53  *** Dyaheon has joined #bitcoin-core-dev
4222017-04-19T16:32:53  *** timothy has quit IRC
4232017-04-19T16:34:23  *** BashCo has quit IRC
4242017-04-19T16:37:24  <cfields> jonasschnelli: any reason we can't do the same thing for the other cs_main takers in there?
4252017-04-19T16:37:45  <jonasschnelli> cfields: Yes. We should do similar things there... i'll have a look
4262017-04-19T16:37:50  <cfields> (adding new ui events, i mean)
4272017-04-19T16:37:50  *** talmai has quit IRC
4282017-04-19T16:39:30  <cfields> jonasschnelli: great :)
4292017-04-19T16:41:34  *** [\\\] has joined #bitcoin-core-dev
4302017-04-19T16:41:57  *** tripleslash has quit IRC
4312017-04-19T16:42:28  <morcos> Here is my attempt at a high level description of the current fee estimation algorithm.
4322017-04-19T16:42:31  <morcos> https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41
4332017-04-19T16:42:47  <morcos> gmaxwell: Please let me know if ^ is what you had in mind
4342017-04-19T16:43:07  <morcos> I thought it best to explain the basic concept of how it currently works without getting into the changes yet
4352017-04-19T16:46:25  <bitcoin-git> [bitcoin] luke-jr opened pull request #10232: release-notes: Accurately explain getblocktemplate improvements (0.14...0.14_relnotes_mining) https://github.com/bitcoin/bitcoin/pull/10232
4362017-04-19T16:49:57  <sipa> morcos: very clear
4372017-04-19T16:50:20  <bitcoin-git> [bitcoin] jet0 opened pull request #10233: Wallet: Support not reusing addresses (master...freezea) https://github.com/bitcoin/bitcoin/pull/10233
4382017-04-19T16:52:52  <morcos> sipa: heh, had a bug in it though!
4392017-04-19T16:58:49  *** [\\\] has quit IRC
4402017-04-19T16:59:53  <bitcoin-git> [bitcoin] jnewbery opened pull request #10234: [net] listbanned RPC and QT should show correct banned subnets (master...list_banned_correctly) https://github.com/bitcoin/bitcoin/pull/10234
4412017-04-19T17:00:50  *** tripleslash has joined #bitcoin-core-dev
4422017-04-19T17:07:26  *** BashCo has joined #bitcoin-core-dev
4432017-04-19T17:09:00  *** tw2006 has quit IRC
4442017-04-19T17:13:03  <sipa> BlueMatt, morcos, sdaftuar: i hope it's easier to review now
4452017-04-19T17:13:14  <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10235: Track keypool entries as internal vs external in memory (master...2017-04-wallet-more-keypool-cache) https://github.com/bitcoin/bitcoin/pull/10235
4462017-04-19T17:13:14  <sipa> i'll leave the WIP marker in until I had a test for the reorganization
4472017-04-19T17:13:14  <sdaftuar> sipa: thanks, i'm taking a look
4482017-04-19T17:13:59  <BlueMatt> sipa: thanks, will review
4492017-04-19T17:14:57  <jonasschnelli> BlueMatt: re: https://github.com/bitcoin/bitcoin/pull/10184#issuecomment-295350649
4502017-04-19T17:14:59  <jonasschnelli> Yes. Makse sense..
4512017-04-19T17:15:10  <jonasschnelli> though the argument of "little money" is dangerous..
4522017-04-19T17:15:18  <sipa> sdaftuar, BlueMatt: thank you
4532017-04-19T17:15:32  <jonasschnelli> Years back some of us probably had little money on VPS's which now has worth a six digit number. :)
4542017-04-19T17:15:51  <jonasschnelli> And while you move your keys away from your VPS,... there is no guarantee they where not compromised..
4552017-04-19T17:16:11  <jonasschnelli> the security requirements can change over time and most people won't sweep the funds to a new address
4562017-04-19T17:16:14  * sipa remembers the linode hack
4572017-04-19T17:16:54  <sipa> but agree that there is not argument why it shouldn't work
4582017-04-19T17:16:55  <jonasschnelli> But I know... i also run nodes on external root servers and sometimes,.. they have a some test mainnet coins
4592017-04-19T17:17:00  <BlueMatt> jonasschnelli: I'm not saying its a *good* idea, just that if people want to do it we shouldnt try to break it
4602017-04-19T17:17:04  <sipa> new key creation performance has been horrible for ages
4612017-04-19T17:17:11  <BlueMatt> (some people buy insurance, too :p)
4622017-04-19T17:17:16  <sipa> we should improve that when we can, period
4632017-04-19T17:18:15  <jonasschnelli> Yes. Sure... I just in general think it's good to show some critical respons whenever someone mentions AWS or Azure. :)
4642017-04-19T17:18:23  <BlueMatt> fair
4652017-04-19T17:18:38  <sipa> btw
4662017-04-19T17:18:48  * sipa had a bitcoind with wallet on a vps, and its money was stolen
4672017-04-19T17:18:56  <jonasschnelli> see! :-)
4682017-04-19T17:18:57  <BlueMatt> lol
4692017-04-19T17:19:08  <sipa> though i do consider that my own damned fault
4702017-04-19T17:19:12  <jonasschnelli> so it even happens to core devs. :)
4712017-04-19T17:39:33  *** talmai has joined #bitcoin-core-dev
4722017-04-19T17:44:04  *** talmai has quit IRC
4732017-04-19T17:45:00  *** vicenteH has quit IRC
4742017-04-19T17:49:50  *** talmai has joined #bitcoin-core-dev
4752017-04-19T17:52:10  *** tripleslash has quit IRC
4762017-04-19T17:54:34  *** talmai has quit IRC
4772017-04-19T17:55:39  *** arowser_ has joined #bitcoin-core-dev
4782017-04-19T17:56:05  *** fao1 has joined #bitcoin-core-dev
4792017-04-19T17:58:06  *** arowser has quit IRC
4802017-04-19T17:58:06  *** fao has quit IRC
4812017-04-19T17:58:06  *** tripleslash has joined #bitcoin-core-dev
4822017-04-19T18:01:22  <gmaxwell> BlueMatt:  I don't understand your complaint about multiple head. It's strictly safer than not having it.
4832017-04-19T18:02:13  <gmaxwell> I agree it will be easier to reason about the effects of multi-head after were're per-txout, and I expect we won't make intentional use of it until then.
4842017-04-19T18:04:39  <sipa> gmaxwell: multi-head is only needed once we do multiple partial flushes
4852017-04-19T18:05:36  <sipa> gmaxwell: we *do* need reorg support immediately, but not necessarily support for multiple reorgs at once
4862017-04-19T18:05:44  *** SopaXorzTaker has quit IRC
4872017-04-19T18:07:12  <BlueMatt> gmaxwell: I'm happy to re-review post-per-utxo
4882017-04-19T18:08:34  <BlueMatt> but right now the review burden is high, and I'm not convinced of its usefulness unless we actually have a write side that we're gonna merge :)
4892017-04-19T18:09:12  <sipa> BlueMatt: well the advantage would be not breaking backward compatibility
4902017-04-19T18:09:20  <sipa> but per-txout will break that anyway
4912017-04-19T18:09:26  <BlueMatt> yes, also not sold on that :)
4922017-04-19T18:09:27  <BlueMatt> indeed
4932017-04-19T18:09:47  <gmaxwell> the same code fixes reorgs to that, the extra stuff that does things for multi-head is just a no-op otherwise.
4942017-04-19T18:10:29  <BlueMatt> gmaxwell: can we not have no-ops in consensus-critical logic?
4952017-04-19T18:11:36  <gmaxwell> so then if there is some corner case we should corrupt the state rather than just handling it?
4962017-04-19T18:12:12  <sipa> gmaxwell: there is no way we can now end up in a situation that needs multi-head support
4972017-04-19T18:12:34  <sipa> unless there is a bug in the code, and in that case it's unlikely the multi-head code actually does the right thing
4982017-04-19T18:14:00  <sipa> my reason for having it in the first place was because i don't consider it much more complicated, so it's easier to get it in now than changing it again later
4992017-04-19T18:14:09  <sipa> but it seems people disagree it's easy to understand
5002017-04-19T18:16:17  *** chartractegg has joined #bitcoin-core-dev
5012017-04-19T18:33:40  *** d_t has joined #bitcoin-core-dev
5022017-04-19T18:35:42  *** Dyaheon has quit IRC
5032017-04-19T18:36:29  *** Dyaheon has joined #bitcoin-core-dev
5042017-04-19T18:49:13  <luke-jr> wumpus: might make sense to backport #10207
5052017-04-19T18:49:15  <gribble> https://github.com/bitcoin/bitcoin/issues/10207 | Clarify importprivkey help text ... example of blank label without rescan by wtogami · Pull Request #10207 · bitcoin/bitcoin · GitHub
5062017-04-19T18:50:26  *** tw2006 has joined #bitcoin-core-dev
5072017-04-19T18:51:48  *** chartractegg has quit IRC
5082017-04-19T18:54:58  *** tw2006 has quit IRC
5092017-04-19T18:58:38  <luke-jr> why is abortrescan not allowed in safe mode?
5102017-04-19T18:58:55  <sipa> lol
5112017-04-19T19:02:34  *** tw2006 has joined #bitcoin-core-dev
5122017-04-19T19:07:39  <jonasschnelli> luke-jr: heh... is that already merged?
5132017-04-19T19:07:57  <luke-jr> seems so
5142017-04-19T19:25:35  *** talmai has joined #bitcoin-core-dev
5152017-04-19T19:33:35  *** jtimon has quit IRC
5162017-04-19T19:45:11  *** chjj has quit IRC
5172017-04-19T19:54:42  *** vicenteH has joined #bitcoin-core-dev
5182017-04-19T19:56:40  <luke-jr> Travis jobs are randomly cancelling?
5192017-04-19T19:59:04  *** chjj has joined #bitcoin-core-dev
5202017-04-19T20:04:14  *** chjj has quit IRC
5212017-04-19T20:04:15  <BlueMatt> luke-jr: they do that automagically if you force push before they run now
5222017-04-19T20:07:21  <luke-jr> BlueMatt: it doesn't *look* like jonasschnelli is force-pushing on #10231
5232017-04-19T20:07:23  <gribble> https://github.com/bitcoin/bitcoin/issues/10231 | [Qt] Reduce a significant cs_main lock freeze by jonasschnelli · Pull Request #10231 · bitcoin/bitcoin · GitHub
5242017-04-19T20:07:39  <BlueMatt> luke-jr: oh, then i dont know
5252017-04-19T20:07:47  <BlueMatt> i think people can also manually cancel their own jobs
5262017-04-19T20:07:53  <BlueMatt> maybe someone hit it on accident
5272017-04-19T20:08:07  <luke-jr> hmm
5282017-04-19T20:10:36  *** tw2006 has quit IRC
5292017-04-19T20:10:38  *** justanotheruser has quit IRC
5302017-04-19T20:13:58  *** talmai has quit IRC
5312017-04-19T20:16:07  *** chjj has joined #bitcoin-core-dev
5322017-04-19T20:16:10  *** Guest36442 has quit IRC
5332017-04-19T20:16:50  *** jtimon has joined #bitcoin-core-dev
5342017-04-19T20:16:58  *** juscamarena has joined #bitcoin-core-dev
5352017-04-19T20:17:20  *** juscamarena is now known as Guest12838
5362017-04-19T20:21:10  *** chjj has quit IRC
5372017-04-19T20:26:49  *** CubicEarth has joined #bitcoin-core-dev
5382017-04-19T20:31:46  *** goksinen has joined #bitcoin-core-dev
5392017-04-19T20:35:03  *** chjj has joined #bitcoin-core-dev
5402017-04-19T20:36:34  *** goksinen has quit IRC
5412017-04-19T20:55:29  *** talmai has joined #bitcoin-core-dev
5422017-04-19T21:00:13  *** talmai has quit IRC
5432017-04-19T21:13:46  *** vicenteH` has joined #bitcoin-core-dev
5442017-04-19T21:15:56  *** vicenteH has quit IRC
5452017-04-19T21:17:11  *** CubicEarth has quit IRC
5462017-04-19T21:20:29  *** e4xit has joined #bitcoin-core-dev
5472017-04-19T21:20:43  *** chjj has quit IRC
5482017-04-19T21:29:20  *** d_t has quit IRC
5492017-04-19T21:34:52  *** chjj has joined #bitcoin-core-dev
5502017-04-19T21:36:53  *** belcher has joined #bitcoin-core-dev
5512017-04-19T21:41:19  *** chjj has quit IRC
5522017-04-19T21:55:19  *** chjj has joined #bitcoin-core-dev
5532017-04-19T21:59:32  *** tw2006 has joined #bitcoin-core-dev
5542017-04-19T22:01:44  *** chjj has quit IRC
5552017-04-19T22:04:39  *** tw2006 has quit IRC
5562017-04-19T22:10:58  *** AaronvanW has quit IRC
5572017-04-19T22:15:46  *** chjj has joined #bitcoin-core-dev
5582017-04-19T22:17:32  *** Giszmo has quit IRC
5592017-04-19T22:20:20  *** chjj has quit IRC
5602017-04-19T22:22:20  *** Naphex has quit IRC
5612017-04-19T22:22:37  *** Naphex has joined #bitcoin-core-dev
5622017-04-19T22:33:29  *** jannes has quit IRC
5632017-04-19T22:33:47  *** chjj has joined #bitcoin-core-dev
5642017-04-19T22:35:05  *** Dyaheon has quit IRC
5652017-04-19T22:36:05  *** Giszmo has joined #bitcoin-core-dev
5662017-04-19T22:38:54  *** Dyaheon has joined #bitcoin-core-dev
5672017-04-19T22:50:16  *** CubicEarth has joined #bitcoin-core-dev
5682017-04-19T22:55:59  *** Giszmo has quit IRC
5692017-04-19T23:15:45  *** Giszmo has joined #bitcoin-core-dev
5702017-04-19T23:27:57  *** dermoth has quit IRC
5712017-04-19T23:48:27  *** tw2006 has joined #bitcoin-core-dev
5722017-04-19T23:48:49  *** CubicEarth has quit IRC
5732017-04-19T23:53:09  *** tw2006 has quit IRC
5742017-04-19T23:56:01  *** d_t has joined #bitcoin-core-dev