12016-10-04T00:00:30  *** jtimon has quit IRC
  22016-10-04T00:01:08  *** aureianimus has quit IRC
  32016-10-04T00:01:21  *** aureianimus has joined #bitcoin-core-dev
  42016-10-04T00:07:33  <GitHub62> [bitcoin] achow101 opened pull request #8874: Multiple Selection for peer and ban tables (master...peer-multiselect) https://github.com/bitcoin/bitcoin/pull/8874
  52016-10-04T00:12:38  <achow101> it seems that I am unable to ban. For some reason the string for the node's address is empty
  62016-10-04T00:18:21  *** aureianimus_ has joined #bitcoin-core-dev
  72016-10-04T00:18:21  *** aureianimus has quit IRC
  82016-10-04T00:30:57  *** JackH has quit IRC
  92016-10-04T00:31:14  *** aureianimus_ has quit IRC
 102016-10-04T00:31:23  *** aureianimus has joined #bitcoin-core-dev
 112016-10-04T00:42:51  *** JackH has joined #bitcoin-core-dev
 122016-10-04T00:43:49  *** juscamarena has joined #bitcoin-core-dev
 132016-10-04T00:43:55  *** aureianimus has quit IRC
 142016-10-04T00:44:08  *** aureianimus has joined #bitcoin-core-dev
 152016-10-04T00:47:01  *** Ylbam has quit IRC
 162016-10-04T00:47:53  *** tErik_mc has quit IRC
 172016-10-04T00:55:19  *** aureianimus has quit IRC
 182016-10-04T00:55:31  *** aureianimus has joined #bitcoin-core-dev
 192016-10-04T01:05:45  *** bsm117532 is now known as Guest95984
 202016-10-04T01:10:01  *** juscamarena has quit IRC
 212016-10-04T01:16:13  *** aureianimus has quit IRC
 222016-10-04T01:16:25  *** aureianimus has joined #bitcoin-core-dev
 232016-10-04T01:17:03  *** aureianimus has joined #bitcoin-core-dev
 242016-10-04T01:20:23  *** mkarrer_ has joined #bitcoin-core-dev
 252016-10-04T01:23:09  *** mkarrer has quit IRC
 262016-10-04T01:33:49  *** aureianimus has quit IRC
 272016-10-04T01:34:01  *** aureianimus has joined #bitcoin-core-dev
 282016-10-04T01:45:12  *** aureianimus has quit IRC
 292016-10-04T01:45:19  *** aureianimus has joined #bitcoin-core-dev
 302016-10-04T01:56:05  *** aureianimus has quit IRC
 312016-10-04T01:56:15  *** aureianimus has joined #bitcoin-core-dev
 322016-10-04T02:02:48  *** randy-waterhouse has joined #bitcoin-core-dev
 332016-10-04T02:03:06  *** randy-waterhouse has joined #bitcoin-core-dev
 342016-10-04T02:06:33  *** Chris_Stewart_5 has quit IRC
 352016-10-04T02:06:57  *** aureianimus has quit IRC
 362016-10-04T02:07:11  *** aureianimus has joined #bitcoin-core-dev
 372016-10-04T02:15:14  *** juscamarena has joined #bitcoin-core-dev
 382016-10-04T02:15:31  *** Alopex has quit IRC
 392016-10-04T02:16:37  *** Alopex has joined #bitcoin-core-dev
 402016-10-04T02:16:50  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 412016-10-04T02:19:56  *** aureianimus has quit IRC
 422016-10-04T02:20:06  *** aureianimus has joined #bitcoin-core-dev
 432016-10-04T02:20:52  *** aureianimus_ has joined #bitcoin-core-dev
 442016-10-04T02:21:08  *** aureianimus has quit IRC
 452016-10-04T02:22:09  *** Chris_Stewart_5 has quit IRC
 462016-10-04T02:25:38  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 472016-10-04T02:28:31  *** Alopex has quit IRC
 482016-10-04T02:28:33  <achow101> so how's the prefinal alert doing?
 492016-10-04T02:28:48  <achow101> gmaxwell: ^
 502016-10-04T02:29:36  *** Alopex has joined #bitcoin-core-dev
 512016-10-04T02:39:32  *** aureianimus_ has quit IRC
 522016-10-04T02:39:43  *** aureianimus has joined #bitcoin-core-dev
 532016-10-04T02:40:22  *** Alopex has quit IRC
 542016-10-04T02:41:27  *** Alopex has joined #bitcoin-core-dev
 552016-10-04T02:52:10  *** aureianimus has quit IRC
 562016-10-04T02:52:15  *** aureianimus_ has joined #bitcoin-core-dev
 572016-10-04T03:00:00  *** moli has joined #bitcoin-core-dev
 582016-10-04T03:04:09  *** Chris_Stewart_5 has quit IRC
 592016-10-04T03:17:01  *** Alopex has quit IRC
 602016-10-04T03:18:06  *** Alopex has joined #bitcoin-core-dev
 612016-10-04T03:20:13  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 622016-10-04T03:32:01  *** Alopex has quit IRC
 632016-10-04T03:33:06  *** Alopex has joined #bitcoin-core-dev
 642016-10-04T03:36:05  *** aureianimus_ has quit IRC
 652016-10-04T03:36:19  *** aureianimus has joined #bitcoin-core-dev
 662016-10-04T03:36:34  *** Chris_Stewart_5 has quit IRC
 672016-10-04T03:39:44  *** meowzus has joined #bitcoin-core-dev
 682016-10-04T03:43:12  *** Alopex has quit IRC
 692016-10-04T03:44:17  *** Alopex has joined #bitcoin-core-dev
 702016-10-04T03:49:40  *** aureianimus has quit IRC
 712016-10-04T03:49:53  *** aureianimus has joined #bitcoin-core-dev
 722016-10-04T03:49:59  *** meowzus has quit IRC
 732016-10-04T03:54:46  * luke-jr wonders why testnet rewinds blocks every time he runs it
 742016-10-04T04:00:55  *** aureianimus has quit IRC
 752016-10-04T04:00:56  *** aureianimus_ has joined #bitcoin-core-dev
 762016-10-04T04:02:46  *** ill has joined #bitcoin-core-dev
 772016-10-04T04:08:16  *** Alopex has quit IRC
 782016-10-04T04:09:21  *** Alopex has joined #bitcoin-core-dev
 792016-10-04T04:13:23  *** aureianimus_ has quit IRC
 802016-10-04T04:13:37  *** aureianimus has joined #bitcoin-core-dev
 812016-10-04T04:18:34  *** justan0theruser has joined #bitcoin-core-dev
 822016-10-04T04:19:53  *** justanotheruser has quit IRC
 832016-10-04T04:32:34  *** aureianimus has quit IRC
 842016-10-04T04:32:48  *** aureianimus has joined #bitcoin-core-dev
 852016-10-04T04:38:16  <gmaxwell> luke-jr: thats the chainstate check.
 862016-10-04T04:39:00  <luke-jr> oh, somehow I was thinking it was for segwit
 872016-10-04T04:43:37  *** aureianimus has quit IRC
 882016-10-04T04:44:20  *** aureianimus has joined #bitcoin-core-dev
 892016-10-04T04:47:06  *** DigiByteDev has joined #bitcoin-core-dev
 902016-10-04T04:55:04  *** aureianimus has quit IRC
 912016-10-04T04:55:14  *** aureianimus has joined #bitcoin-core-dev
 922016-10-04T05:08:26  *** Alopex has quit IRC
 932016-10-04T05:09:31  *** Alopex has joined #bitcoin-core-dev
 942016-10-04T05:10:43  <GitHub87> [bitcoin] luke-jr opened pull request #8877: Qt RPC console: history sensitive-data filter, and saving input line when browsing history (master...qt_console_history_filter) https://github.com/bitcoin/bitcoin/pull/8877
 952016-10-04T05:14:32  *** aureianimus has quit IRC
 962016-10-04T05:14:43  *** aureianimus has joined #bitcoin-core-dev
 972016-10-04T05:21:02  *** Alopex has quit IRC
 982016-10-04T05:22:07  *** Alopex has joined #bitcoin-core-dev
 992016-10-04T05:26:08  *** paveljanik has quit IRC
1002016-10-04T05:38:36  *** Ylbam has joined #bitcoin-core-dev
1012016-10-04T05:39:16  *** aureianimus has quit IRC
1022016-10-04T05:39:25  *** aureianimus has joined #bitcoin-core-dev
1032016-10-04T06:00:10  *** aureianimus has quit IRC
1042016-10-04T06:00:19  *** aureianimus has joined #bitcoin-core-dev
1052016-10-04T06:05:16  *** Alopex has quit IRC
1062016-10-04T06:06:21  *** Alopex has joined #bitcoin-core-dev
1072016-10-04T06:21:15  *** aureianimus has quit IRC
1082016-10-04T06:21:25  *** aureianimus has joined #bitcoin-core-dev
1092016-10-04T06:32:16  *** aureianimus has quit IRC
1102016-10-04T06:32:29  *** aureianimus has joined #bitcoin-core-dev
1112016-10-04T06:52:49  *** DigiByteDev has quit IRC
1122016-10-04T06:53:59  *** BashCo has quit IRC
1132016-10-04T06:54:37  *** BashCo has joined #bitcoin-core-dev
1142016-10-04T06:57:10  *** rubensayshi has joined #bitcoin-core-dev
1152016-10-04T06:58:49  *** BashCo has quit IRC
1162016-10-04T06:59:58  *** aureianimus has quit IRC
1172016-10-04T07:00:09  *** aureianimus has joined #bitcoin-core-dev
1182016-10-04T07:10:52  *** aureianimus has quit IRC
1192016-10-04T07:11:05  *** aureianimus has joined #bitcoin-core-dev
1202016-10-04T07:19:38  *** BashCo has joined #bitcoin-core-dev
1212016-10-04T07:22:05  *** Giszmo has quit IRC
1222016-10-04T07:22:07  *** DigiByteDev has joined #bitcoin-core-dev
1232016-10-04T07:23:31  *** BashCo_ has joined #bitcoin-core-dev
1242016-10-04T07:24:09  *** juscamarena has quit IRC
1252016-10-04T07:27:05  *** BashCo has quit IRC
1262016-10-04T07:31:48  *** aureianimus has quit IRC
1272016-10-04T07:32:01  *** aureianimus has joined #bitcoin-core-dev
1282016-10-04T07:43:02  *** aureianimus has quit IRC
1292016-10-04T07:43:14  *** aureianimus has joined #bitcoin-core-dev
1302016-10-04T08:04:10  *** aureianimus has quit IRC
1312016-10-04T08:04:22  *** aureianimus has joined #bitcoin-core-dev
1322016-10-04T08:10:39  *** laurentmt has joined #bitcoin-core-dev
1332016-10-04T08:15:05  *** aureianimus has quit IRC
1342016-10-04T08:15:18  *** aureianimus has joined #bitcoin-core-dev
1352016-10-04T08:21:11  *** MarcoFalke has joined #bitcoin-core-dev
1362016-10-04T08:21:17  *** laurentmt has quit IRC
1372016-10-04T08:26:04  *** aureianimus has quit IRC
1382016-10-04T08:26:17  *** aureianimus has joined #bitcoin-core-dev
1392016-10-04T08:26:49  *** laurentmt has joined #bitcoin-core-dev
1402016-10-04T08:29:30  *** chris2000 has joined #bitcoin-core-dev
1412016-10-04T08:34:45  <wumpus> aureianimus: if you don't fix your IRC client I'll have to ban you to reduce join/part noise in this channel
1422016-10-04T08:37:04  *** aureianimus has quit IRC
1432016-10-04T08:37:16  *** aureianimus has joined #bitcoin-core-dev
1442016-10-04T08:37:43  *** ChanServ sets mode: +o wumpus
1452016-10-04T08:39:46  *** wumpus sets mode: +b #bitcoin-core-de!*@*
1462016-10-04T08:39:53  *** wumpus sets mode: -b #bitcoin-core-de!*@*
1472016-10-04T08:40:45  *** wumpus sets mode: +b *!*@s55963df3.adsl.online.nl
1482016-10-04T08:41:54  *** ChanServ sets mode: -o wumpus
1492016-10-04T08:42:25  <wumpus> PM me if fixed
1502016-10-04T08:50:39  *** aureianimus has quit IRC
1512016-10-04T08:52:17  *** laurentmt has quit IRC
1522016-10-04T09:08:31  <GitHub132> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/a7e5cbb209d4...7dce175f5d89
1532016-10-04T09:08:32  <GitHub132> bitcoin/master 47314e6 Wladimir J. van der Laan: prevector: add C++11-like data() method...
1542016-10-04T09:08:32  <GitHub132> bitcoin/master f00705a Wladimir J. van der Laan: serialize: Deprecate `begin_ptr` / `end_ptr`...
1552016-10-04T09:08:32  <GitHub132> bitcoin/master 7dce175 Wladimir J. van der Laan: Merge #8850: Implement (begin|end)_ptr in C++11 and add deprecation comment...
1562016-10-04T09:08:45  <GitHub115> [bitcoin] laanwj closed pull request #8850: Implement (begin|end)_ptr in C++11 and add deprecation comment (master...2016_09_beginptr_deprecation) https://github.com/bitcoin/bitcoin/pull/8850
1572016-10-04T09:21:37  <MarcoFalke> luke-jr: "Rewinding blocks" is always displayed when you run a recent version.
1582016-10-04T09:21:47  <MarcoFalke> (It does not actually do any rewinding)
1592016-10-04T09:22:05  *** jannes has joined #bitcoin-core-dev
1602016-10-04T09:29:54  <wumpus> let's correct the message
1612016-10-04T09:31:13  <sipa> yeah, just produce no message wgen there is nothing to rewind
1622016-10-04T09:31:46  <wumpus> it must be doing something if it is visible at all, though
1632016-10-04T09:32:40  <wumpus> well okay not true in the log, but is in the GUI, you won't notice the first message if it updates two times in a row
1642016-10-04T09:32:55  <sipa> probably the next thing it does after it takes a non-negilgable amount of time
1652016-10-04T09:33:08  <wumpus> so *that* needs its own message
1662016-10-04T09:33:12  <wumpus> better fix
1672016-10-04T09:33:12  <sipa> right
1682016-10-04T09:33:25  <randy-waterhouse> unwinding ... get a drink
1692016-10-04T09:33:44  <wumpus> :-)
1702016-10-04T09:41:20  *** rubensayshi has quit IRC
1712016-10-04T09:57:54  *** kyletorpey has quit IRC
1722016-10-04T10:12:12  *** murch has joined #bitcoin-core-dev
1732016-10-04T10:12:31  *** cdecker has joined #bitcoin-core-dev
1742016-10-04T10:14:06  *** DigiByteDev has quit IRC
1752016-10-04T10:14:12  <GitHub70> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7dce175f5d89...d93f0c61843f
1762016-10-04T10:14:12  <GitHub70> bitcoin/master 905bc68 Cory Fields: net: fix a few cases where messages were sent rather than dropped upon disconnection...
1772016-10-04T10:14:12  <GitHub70> bitcoin/master d93f0c6 Wladimir J. van der Laan: Merge #8862: Fix a few cases where messages were sent after requested disconnect...
1782016-10-04T10:14:25  <GitHub157> [bitcoin] laanwj closed pull request #8862: Fix a few cases where messages were sent after requested disconnect (master...fix-disconnect-send) https://github.com/bitcoin/bitcoin/pull/8862
1792016-10-04T10:18:33  <GitHub79> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d93f0c61843f...d7615af34e8e
1802016-10-04T10:18:33  <GitHub79> bitcoin/master 2fa0063 Johnson Lau: Add NULLDUMMY verify flag in bitcoinconsensus.h
1812016-10-04T10:18:34  <GitHub79> bitcoin/master d7615af Wladimir J. van der Laan: Merge #8848: Add NULLDUMMY verify flag in bitcoinconsensus.h...
1822016-10-04T10:18:47  <GitHub150> [bitcoin] laanwj closed pull request #8848: Add NULLDUMMY verify flag in bitcoinconsensus.h (master...consensusnulldummy) https://github.com/bitcoin/bitcoin/pull/8848
1832016-10-04T10:22:18  *** jtimon has joined #bitcoin-core-dev
1842016-10-04T10:28:39  *** murch has quit IRC
1852016-10-04T10:29:28  *** wasi has joined #bitcoin-core-dev
1862016-10-04T10:33:12  *** wasi_ has joined #bitcoin-core-dev
1872016-10-04T10:33:12  *** wasi_ has quit IRC
1882016-10-04T10:41:20  <GitHub49> [bitcoin] MarcoFalke opened pull request #8879: [doc] Rework docs (master...Mf1610-docCleanup) https://github.com/bitcoin/bitcoin/pull/8879
1892016-10-04T10:46:11  *** belcher has quit IRC
1902016-10-04T10:58:33  *** belcher has joined #bitcoin-core-dev
1912016-10-04T11:03:09  *** randy-waterhouse has quit IRC
1922016-10-04T11:18:05  <GitHub185> [bitcoin] laanwj opened pull request #8880: protocol.h: Move MESSAGE_START_SIZE into CMessageHeader (master...2016_10_cosmetic) https://github.com/bitcoin/bitcoin/pull/8880
1932016-10-04T11:21:02  *** justan0theruser has quit IRC
1942016-10-04T11:40:48  *** cryptapus_ has joined #bitcoin-core-dev
1952016-10-04T11:41:03  *** cryptapus_ is now known as cryptapus
1962016-10-04T11:47:58  *** DigiByteDev has joined #bitcoin-core-dev
1972016-10-04T11:53:49  *** paveljanik has joined #bitcoin-core-dev
1982016-10-04T11:53:49  *** paveljanik has joined #bitcoin-core-dev
1992016-10-04T12:03:12  *** DigiByteDev has quit IRC
2002016-10-04T12:05:09  *** paveljanik has quit IRC
2012016-10-04T12:20:00  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2022016-10-04T12:22:48  *** wasi has quit IRC
2032016-10-04T12:23:29  *** wasi has joined #bitcoin-core-dev
2042016-10-04T12:40:11  *** Evel-Knievel has quit IRC
2052016-10-04T12:41:14  *** Evel-Knievel has joined #bitcoin-core-dev
2062016-10-04T12:41:53  *** Chris_Stewart_5 has quit IRC
2072016-10-04T12:42:23  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2082016-10-04T12:43:59  *** wasi has quit IRC
2092016-10-04T12:44:23  *** wasi has joined #bitcoin-core-dev
2102016-10-04T12:55:09  *** cryptapus has quit IRC
2112016-10-04T12:55:24  *** cryptapus has joined #bitcoin-core-dev
2122016-10-04T12:55:24  *** cryptapus has joined #bitcoin-core-dev
2132016-10-04T13:19:26  <BlueMatt> cfields_: whats your opinion on switching g_connman to a std::shared_ptr and then using that in the map of logica validators?
2142016-10-04T13:21:45  *** Chris_Stewart_5 has quit IRC
2152016-10-04T13:32:14  *** DigiByteDev has joined #bitcoin-core-dev
2162016-10-04T13:34:32  *** Lightsword has left #bitcoin-core-dev
2172016-10-04T13:37:46  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2182016-10-04T13:41:56  *** DigiByteDev has quit IRC
2192016-10-04T13:48:07  *** Guyver2 has joined #bitcoin-core-dev
2202016-10-04T13:48:44  *** laurentmt has joined #bitcoin-core-dev
2212016-10-04T13:52:17  *** cryptapus has quit IRC
2222016-10-04T13:53:28  *** laurentmt has quit IRC
2232016-10-04T13:59:43  *** cryptapus has joined #bitcoin-core-dev
2242016-10-04T13:59:45  *** cryptapus has joined #bitcoin-core-dev
2252016-10-04T14:08:09  *** Guest95984 is now known as bsm117532
2262016-10-04T14:27:32  *** Giszmo has joined #bitcoin-core-dev
2272016-10-04T14:30:21  <BlueMatt> cfields_: nvm, i pushed a change to switch to a shared_ptr there, makes everything safe without adding a GetId() to CConnman, which I like
2282016-10-04T14:36:44  *** cryptapus has quit IRC
2292016-10-04T14:41:01  *** cryptapus has joined #bitcoin-core-dev
2302016-10-04T14:59:37  <cfields_> BlueMatt: please please no :)
2312016-10-04T14:59:54  <BlueMatt> ehh, its better than another global GetId() thing
2322016-10-04T15:00:48  <cfields_> BlueMatt: it breaks down ownership models, and will almost certainly lead to teardown issues/races eventually
2332016-10-04T15:01:24  <BlueMatt> i mean i dunno how to resolve that without having an ownership model for who owns the CConnman and who owns the logic
2342016-10-04T15:01:35  <BlueMatt> unless you want the CConnman to own the logic
2352016-10-04T15:02:45  <cfields_> BlueMatt: right, we need to think about that carefully. But punting to a shared_ptr effectively just masks the problem, imo
2362016-10-04T15:03:09  <GitHub59> [bitcoin] laanwj closed pull request #8843: rpc: Handle `getinfo` client-side in bitcoin-cli w/ `-getinfo` (master...2016_09_getinfo_clientside) https://github.com/bitcoin/bitcoin/pull/8843
2372016-10-04T15:04:02  <BlueMatt> i mean if a failure to teardown in the right order does anything more than cause memory to keep growing as you push events that arent handled, then you have other issues
2382016-10-04T15:05:01  <cfields_> wumpus: thoughts on the above? IIRC we've discussed briefly before. The question is: what model do we use to glue networking and message handling together?
2392016-10-04T15:06:02  <cfields_> BlueMatt: i don't see the problem with the approach before the shared_ptr? As long as a signal is broadcast to the processors that the connman is no longer valid, that seems fine to me?
2402016-10-04T15:06:32  <BlueMatt> before the shared ptr? you could delete and dereference null, no?
2412016-10-04T15:06:43  <BlueMatt> i mean if you failed to teardown, that is
2422016-10-04T15:07:25  <wumpus> well if it is CConnMan that manages the lifecycle of connections there's not need for shared_ptr
2432016-10-04T15:07:29  <cfields_> BlueMatt: right, with the caveat that the handler would have to appropriately act on the signal in time
2442016-10-04T15:07:50  <wumpus> you may need 'weak-pointer' like callbacks in that case, to prevent anyone still holding keeping handle when a connection goes away
2452016-10-04T15:08:17  <BlueMatt> wumpus: not about connections, about the CConnman itself
2462016-10-04T15:08:56  <wumpus> Init() and Shutdown() 'own' CConnman
2472016-10-04T15:08:58  <cfields_> BlueMatt: then CConnman will have advertised that all connections have been torn down before it itself is deleted
2482016-10-04T15:09:05  <wumpus> we have a well defined lifecycle there
2492016-10-04T15:09:31  <wumpus> after Shutdown there should be no networking anymore, and no connman
2502016-10-04T15:09:35  *** instagibbs has quit IRC
2512016-10-04T15:10:09  <wumpus> and everything that uses connman should be deinitialized before ConnMan gets deinitialized
2522016-10-04T15:10:31  <wumpus> better to have deterministic lifecycles for objects then rely on shared pointers to happen to get things right
2532016-10-04T15:10:55  <wumpus> or even worse, relying on global constructors/destructors order
2542016-10-04T15:15:12  <cfields_> +1. Though I think also it's important to design such that net users essentially have no chance of trying to send messages by the time CConnman has shut down, so that the fact that it's "owned" by Init really doesn't matter.
2552016-10-04T15:15:49  <cfields_> eg. queued messages should be deleted when the nodes are advertised as disconnected, and processors should be shutdown when their connman advertises that it's stopping
2562016-10-04T15:16:22  <wumpus> that depends on what preconditions you try to enforce, if net users remain by the time CConMan shuts down you'd say that's a bug
2572016-10-04T15:16:50  <wumpus> oh right, it may be a multi-phase process
2582016-10-04T15:18:59  <luke-jr> wumpus: I wasn't objecting to -getinfo <.<
2592016-10-04T15:19:11  <cfields_> right, the processor will get an interrupt which should break its loops, then a blocking stop, after which it should assume that its connman is null'd
2602016-10-04T15:20:17  <wumpus> luke-jr: I know, but I just don't think it's worth pushing too much for, it's something I'd use myself but I don't think anyone else cares and maybe I should just get used to using the respective commands, or simply make a python script
2612016-10-04T15:22:29  *** shesek has quit IRC
2622016-10-04T15:23:00  <wumpus> heck or just a bash alias. bitcoin-cli getwalletinfo && bitcoin-cli getnetworkinfo | head -20 or such. I'd been overthinking it a bit because I thought it was neat to do RPC batch from bitcoin-cli
2632016-10-04T15:25:18  *** molz has joined #bitcoin-core-dev
2642016-10-04T15:27:26  *** droark has joined #bitcoin-core-dev
2652016-10-04T15:27:30  *** shesek has joined #bitcoin-core-dev
2662016-10-04T15:27:37  *** moli has quit IRC
2672016-10-04T15:29:43  *** Lightsword has joined #bitcoin-core-dev
2682016-10-04T15:31:27  <cfields_> wumpus: you mentioned in #8856 that you'd like to see an api for options eventually. I have a few generic base classes that I've been working on in order to break some global dependencies out of utils. for threading, logging, options, etc. Wasn't sure if you'd want those or not. I could PR an RFC if you think it's worth discussing
2692016-10-04T15:32:42  <cfields_> (it was done as an exercise for CConnman, seeing what it would take to drop all global state deps by passing in a base logger, base options parser, etc)
2702016-10-04T15:35:57  <wumpus> cfields_: yes I think that would be a good thing, options handling has always been somewhat of a mess. And when boost has to be dropped as a dependency we need a replacement for boost::options.
2712016-10-04T15:36:16  <cfields_> wumpus: right
2722016-10-04T15:36:30  <cfields_> wumpus: seems the only thing we actually use it for is parsing the config file?
2732016-10-04T15:36:37  <wumpus> cfields_: there's a lot unclear though, e.g. do we want to be able to change (some) options on the fly (which would require callbacks), how to handle types, how to handle defaults, etc
2742016-10-04T15:36:53  <wumpus> yes, just replacing it would be trivial, doesn't need a whole options overhaul :)
2752016-10-04T15:37:07  <cfields_> wumpus: as a stopgap, I just kept it all pretty much as-is
2762016-10-04T15:38:01  <wumpus> e.g. how we handle defaults is kind of ugly. In stead of declaring the option and its type and default e.g. at the top of the module where it gets used, we have to declare a constant DEFAULT_BLABLA then pass it in in every place where the option gets used
2772016-10-04T15:38:07  <cfields_> wumpus: stores a const map of strings, a const multimap, then a non-const map for the soft-sets. The getters treat that as an overlay, and fallback to const
2782016-10-04T15:38:22  <wumpus> also there's a lot of overhead as arguments get parsed to their type time after time, in some places
2792016-10-04T15:38:47  <wumpus> and it's possible to call GetBOol on an argument in one place and GetString on it in another place
2802016-10-04T15:38:48  <cfields_> wumpus: heh, yes. There's certainly the argument that the options shouldn't even be visibile outside of init
2812016-10-04T15:39:24  <wumpus> and my favorite pet issue https://github.com/bitcoin/bitcoin/issues/1044
2822016-10-04T15:40:19  <cfields_> mmm, yuck
2832016-10-04T15:40:38  <wumpus> cfields_: that would be one way, though it means all the argument propagation logic is centralized. Right now we are moving towards having the wallet handle its own arguments, for example, which makes sense to break the circular dependency and get rid of ENABLE_WALLET defines.
2842016-10-04T15:40:53  <wumpus> it's in no way a trivial thing to get right
2852016-10-04T15:41:11  <wumpus> many constraints, and low priority, and the current state well... kind of works
2862016-10-04T15:41:28  <wumpus> cfields_: yes, validation would be good :)
2872016-10-04T15:42:33  <cfields_> wumpus: low priority, hint taken :)
2882016-10-04T15:43:01  <wumpus> well the net refactor is much more important
2892016-10-04T15:43:33  <wumpus> as well as build system/gitian security
2902016-10-04T15:44:18  <wumpus> speaking of which how's your mac code-signer project doing?
2912016-10-04T15:45:33  <sipa> wumpus: i once started on an options system (inspired a bit by google's, where you just declare a global IntOption nMaxConnections("-maxconnections", minval, maxval, description); or so, and then can query nMaxConnections as if it were an integer
2922016-10-04T15:46:02  <cfields_> wumpus: got distracted when some net stuff got merged. It's fully working and stable though, the only work left is to figure out the detach/attach scheme
2932016-10-04T15:46:18  <sipa> i also think luke started on an options thing where they could be changed over time
2942016-10-04T15:47:08  <wumpus> sipa: sounds good to me
2952016-10-04T15:48:10  <wumpus> and yes luke-jr has some pulls open that accomplish some of these things
2962016-10-04T15:49:11  <wumpus> haven't looked very much yet at those, sorry
2972016-10-04T15:55:20  *** cdecker has quit IRC
2982016-10-04T15:58:08  *** cdecker has joined #bitcoin-core-dev
2992016-10-04T15:59:21  <GitHub163> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/5f3e4a8a2ae2dd0e0fa316c6caa50e97280be773
3002016-10-04T15:59:21  <GitHub163> bitcoin/master 5f3e4a8 Wladimir J. van der Laan: protocol.h: Make enums in GetDataMsg concrete values...
3012016-10-04T15:59:35  <wumpus> gah oh fuck
3022016-10-04T16:01:26  <GitHub108> [bitcoin] laanwj force-pushed master from 5f3e4a8 to d7615af: https://github.com/bitcoin/bitcoin/commits/master
3032016-10-04T16:01:52  *** instagibbs has joined #bitcoin-core-dev
3042016-10-04T16:01:52  <wumpus> emergency force-push back to d7615af34e8e19920ed12bfdafb09e0e4b57c7c5
3052016-10-04T16:02:33  * cfields_ goes to verify, i just pulled 5min ago
3062016-10-04T16:04:08  <wumpus> thanks
3072016-10-04T16:05:56  <cfields_> hmm, wonder if there's a quick way to ask git for a repo contents hash (ignoring that the commit hash kinda represents that)
3082016-10-04T16:07:55  <sipa> the tree hash?
3092016-10-04T16:07:56  *** davec has quit IRC
3102016-10-04T16:07:57  <wumpus> that's the 'tree hash' I suppose?
3112016-10-04T16:08:12  *** davec has joined #bitcoin-core-dev
3122016-10-04T16:08:28  <wumpus> it's unfortunate that github's bot only logs the short commit hash, otherwise you could just browse back and compare ids
3132016-10-04T16:09:53  <cfields_> cory@cory-i7:~/dev/bitcoin2(connman-send)$ git ls-tree origin/master | sha256sum
3142016-10-04T16:09:53  <cfields_> 5f470267d0fc7161ac6193c223f7e76fe135ba33fac35ec39d1adde9324f021f  -
3152016-10-04T16:10:05  <cfields_> cory@Macbook:~/dev/bitcoin(fix-gui-ban)$ git ls-tree origin/master | sha256sum
3162016-10-04T16:10:05  <cfields_> 5f470267d0fc7161ac6193c223f7e76fe135ba33fac35ec39d1adde9324f021f  -
3172016-10-04T16:10:35  <cfields_> 1 pre force-push, 1 post. No surprise, they match :)
3182016-10-04T16:11:10  <wumpus> good
3192016-10-04T16:16:04  <BlueMatt> cfields_: sorry, had to step out...do you prefer, then, that we stick with the map<pointer, thing>?
3202016-10-04T16:16:34  <BlueMatt> I mean I'm open to that, you just objected that it was fragile, and shared_ptr is an explicit fix for fragility of using a ptr there
3212016-10-04T16:16:43  <cfields_> BlueMatt: for the sake of not holding it up, sure.
3222016-10-04T16:18:20  <BlueMatt> I mean, ok, I'll revert the shared_ptr change, then, but what would be the long-term target there? a logic class which owns the CConnman?
3232016-10-04T16:18:30  *** Chris_Stewart_5 has quit IRC
3242016-10-04T16:20:14  <GitHub196> [bitcoin] laanwj closed pull request #8746: [Qt][RPC] Hide passphrases in debug console history (master...hide-walletpassphrase) https://github.com/bitcoin/bitcoin/pull/8746
3252016-10-04T16:21:53  <cfields_> BlueMatt: it doesn't own it, it just holds a reference to one. It should receive signals that the connman is being torn down, and assume that it's invalid from that point forward
3262016-10-04T16:23:54  *** Guyver2 has quit IRC
3272016-10-04T16:29:14  *** Guyver2 has joined #bitcoin-core-dev
3282016-10-04T16:33:41  <BlueMatt> cfields_: hmm, ok...I find that harder to reason about (and it generates more code), but, ehh, whatever
3292016-10-04T16:33:52  <BlueMatt> cfields_: in any case, thats not something that is less than a lot of work to make happen
3302016-10-04T16:36:05  <cfields_> BlueMatt: well, lots of things are going to want to own the CConnman. They can't all have it :)
3312016-10-04T16:36:15  *** mkarrer_ has quit IRC
3322016-10-04T16:36:38  <sipa> well either it's owned by one thing and one thing only, or it's refcounted
3332016-10-04T16:37:05  <BlueMatt> cfields_: oh? what else wants to own CConnman? I think not much else cares about anything at a lower level than what peers are doing
3342016-10-04T16:37:17  <BlueMatt> cfields_: aside from the need to provide the setup argument sin init
3352016-10-04T16:38:55  <cfields_> BlueMatt: rpc/wallet/gui could all make the argument
3362016-10-04T16:40:28  <sipa> i'd say init creates&owns CConnman, and passes it as argument to rpc/wallet/gui
3372016-10-04T16:40:37  <sipa> who hold a reference to CConnman, but don't own it
3382016-10-04T16:40:53  <sipa> and it's init's responsibility to not shut down CConnman before all its users are destroyed
3392016-10-04T16:41:12  <BlueMatt> cfields_: why does rpc/wallet/or gui care about anything more than the list of nodes connected to, outside of the context of configuration options
3402016-10-04T16:41:15  <sipa> (please tell me to shut up if there are large issues i'm not aware of, i haven't actively followed the code)
3412016-10-04T16:41:19  <cfields_> sipa: agree, that's what I'm suggesting as well
3422016-10-04T16:41:30  <BlueMatt> sipa: ok, well thats what it is now
3432016-10-04T16:41:35  <BlueMatt> cfields_: was taking objection to that
3442016-10-04T16:41:58  *** shesek has quit IRC
3452016-10-04T16:41:59  <sipa> BlueMatt: how so?
3462016-10-04T16:42:08  <cfields_> BlueMatt: eh? I'm aligned with that. I'm taking objection to a processor taking ownership
3472016-10-04T16:42:22  <BlueMatt> "a processor"?
3482016-10-04T16:42:31  <BlueMatt> you mean the PeerValidationLogic
3492016-10-04T16:42:39  <BlueMatt> it doesnt take ownership, it keeps a pointer to the object
3502016-10-04T16:42:43  <cfields_> message handler, validator, etc
3512016-10-04T16:43:04  <BlueMatt> and " it's init's responsibility to not shut down CConnman before all its users are destroyed" :p
3522016-10-04T16:43:10  <cfields_> BlueMatt: yes, and I'm fine with that :)
3532016-10-04T16:43:16  <BlueMatt> wait, now I'm confuseg
3542016-10-04T16:43:20  <BlueMatt> ugh, ok, I'll leave it how it is
3552016-10-04T16:43:21  <cfields_> just not a shared_ptr
3562016-10-04T16:43:27  <sipa> well ideally, the PeerValidationLogic is a class, and there is a seaprate instance of it for each CConnman
3572016-10-04T16:43:35  <sipa> so it can hold a pointer, and does not need a map
3582016-10-04T16:43:35  <BlueMatt> cfields_: yea, I'll remove that
3592016-10-04T16:43:50  <BlueMatt> sipa: it does, the map is only as a place to put the storage, mostly
3602016-10-04T16:44:09  <sipa> BlueMatt: i'll shut up before looking at the
3612016-10-04T16:44:12  <sipa> code
3622016-10-04T16:44:44  <BlueMatt> its just there so you can do Register(CConnman*) and Deregister(CConnman*) and it knows which PeerValidationLogic object is associated with that connman so it can destroy the right one
3632016-10-04T16:45:30  <sipa> hmm, shouldn't init create the PeerValidationLogic object, and just pass it the CConnman pointer?
3642016-10-04T16:45:41  <sipa> there should never be a need to look something up
3652016-10-04T16:46:03  <BlueMatt> How else do you know which PeerValidationLogic to destroy when someone hands you a CConnman* to Deregister()?
3662016-10-04T16:46:07  <BlueMatt> i mean aside from iterating
3672016-10-04T16:46:14  <BlueMatt> anyway, whatever, could also iterate, doesnt matter much
3682016-10-04T16:46:19  <sipa> init would create the PeerValidationLogic
3692016-10-04T16:46:22  <sipa> and destroy it
3702016-10-04T16:46:33  *** shesek has joined #bitcoin-core-dev
3712016-10-04T16:47:18  <BlueMatt> ahh, yea, i mean thats maybe a more forward-looking thing...once the code is well-separated and designed, maybe, but for now it lets main store it
3722016-10-04T16:47:27  <sipa> ok
3732016-10-04T16:47:40  <cfields_> BlueMatt: ^^ seems simpler than stashing it in main?
3742016-10-04T16:47:54  <sipa> all good; "it requires too much refactoring" is a good reason
3752016-10-04T16:47:58  *** laurentmt has joined #bitcoin-core-dev
3762016-10-04T16:48:08  <BlueMatt> cfields_: I didnt really want to expose the PeerValidationLogic in main.h yet
3772016-10-04T16:48:17  <sipa> gah stupid github and its author date based ordering of commits
3782016-10-04T16:48:23  <BlueMatt> i had originally started doing what sipa said, and then decided i wanted less exposing of shit
3792016-10-04T16:48:53  <sipa> it took me 10 minutes to figure out why #8871's commits didn't show up in #8393
3802016-10-04T16:49:08  <sipa> turns out they are there... at the end
3812016-10-04T16:49:10  <cfields_> BlueMatt: mm, ok. Giving you a pass since the intention is to break stuff out anyway
3822016-10-04T16:49:14  <cfields_> :)
3832016-10-04T16:50:36  <BlueMatt> cfields_: heh, ok, will need like 2 more prs for that :p
3842016-10-04T16:51:32  <cfields_> BlueMatt: wait, isn't it a child of CValidationInterface ?
3852016-10-04T16:51:43  <BlueMatt> is what?
3862016-10-04T16:53:01  <cfields_> yea, PeerLogicValidation
3872016-10-04T16:53:25  <cfields_> why not just keep a base pointer in init?
3882016-10-04T16:53:58  <BlueMatt> oh, you mean ptr to CValidationInterface
3892016-10-04T16:54:08  <BlueMatt> hmm, dont we need like a virtual destructor or something crazy like that?
3902016-10-04T16:54:37  <cfields_> er, setup a base ptr to a dummy interface in init, then actually create it later in the process
3912016-10-04T16:54:52  <BlueMatt> wait, what?
3922016-10-04T16:56:35  <cfields_> oh, it's already non-virtual anyway. no need for the dummy
3932016-10-04T16:56:43  <cfields_> BlueMatt: nm, it can wait 'til later
3942016-10-04T16:56:45  * BlueMatt is so confused
3952016-10-04T16:58:18  <cfields_> BlueMatt: i can write it up real quick
3962016-10-04T16:59:07  <BlueMatt> ugh, y'all and your C++ magic
3972016-10-04T16:59:08  *** laurentmt has quit IRC
3982016-10-04T17:03:15  <sipa> BlueMatt: for my grammar-based password generator, i wrote an stl-like list where the iterators are refcounted, and elements automatically get destructed when no iterators remain... epic fun with rvalue references everywhere :)
3992016-10-04T17:03:37  <BlueMatt> fuck you people
4002016-10-04T17:04:20  <sipa> though i don't think cfields_ is talking about anything as extreme as that :)
4012016-10-04T17:04:54  <cfields_> sipa: haha
4022016-10-04T17:05:04  <cfields_> no, I just mean using a base class as a base class :)
4032016-10-04T17:07:52  *** BashCo_ has quit IRC
4042016-10-04T17:08:21  <BlueMatt> heh, one of these days sipa is gonna learn my name (https://github.com/bitcoin/bitcoin/pull/8393/commits/e15a0584911f142d5819cc7fb967028c76682792)...
4052016-10-04T17:08:28  <BlueMatt> right after he finishes learning english, mabye :p
4062016-10-04T17:09:13  <cfields_> BlueMatt: still hacking it up, just a few min
4072016-10-04T17:09:33  *** juscamarena has joined #bitcoin-core-dev
4082016-10-04T17:10:23  <sipa> BlueMatt: crap
4092016-10-04T17:11:00  <sipa> BlueMatt: fixed
4102016-10-04T17:17:54  <luke-jr> BlueMatt: "We went looking everywhere, but couldn’t find those commits."
4112016-10-04T17:18:05  <luke-jr> oh, prob cuz sipa deleted it
4122016-10-04T17:18:55  * luke-jr peers at MarcoFalke deleting branches quickly after merge
4132016-10-04T17:20:45  *** juscamarena has quit IRC
4142016-10-04T17:20:53  <MarcoFalke> luke-jr: You need to modify the url to get the commit: e.g. https://github.com/bitcoin/bitcoin/commit/e15a0584911f142d5819cc7fb967028c76682792
4152016-10-04T17:21:04  <MarcoFalke> for the above one
4162016-10-04T17:21:55  <cfields_> BlueMatt: untested POC: https://github.com/theuni/bitcoin/commit/31438dd973a95934ab847fb5ba7d6fa604ee506c
4172016-10-04T17:22:06  <BlueMatt> testing? who does that???
4182016-10-04T17:22:36  <BlueMatt> cfields_: omgno
4192016-10-04T17:22:40  <cfields_> BlueMatt: the unique_ptr is awkward because it has to be passed to main for creation. Once the header can be exposed, nearly all of that ugliness goes away
4202016-10-04T17:22:49  <BlueMatt> the second I see std::move my eyes glaze over
4212016-10-04T17:22:54  <cfields_> eh?
4222016-10-04T17:23:17  <BlueMatt> you're like passing around something without knowledge of the type and using std::move and things
4232016-10-04T17:23:23  <BlueMatt> i really dont like that
4242016-10-04T17:23:36  <cfields_> huh? Yes, I'm using virtuals and rvalues...
4252016-10-04T17:23:50  <cfields_> Everything there is type-safe and defined
4262016-10-04T17:24:34  <cfields_> but as mentioned above, that's only there to work around the fact that the header isn't exposed. The moves go away once you can create the inteface directly in init
4272016-10-04T17:26:19  <BlueMatt> i mean you had to add a virtual destructor......
4282016-10-04T17:26:26  <BlueMatt> was mostly what i was referring to
4292016-10-04T17:26:28  *** BashCo has joined #bitcoin-core-dev
4302016-10-04T17:26:37  <BlueMatt> can we just push this off until its in net_processing.h and we can expose the class there?
4312016-10-04T17:27:18  <BlueMatt> like, ehh, you're bending over backwards to make this work without exposing the PeerLogicValidation, whereas I'd kinda prefer to expose it in main.h
4322016-10-04T17:27:27  <BlueMatt> though, mostly, Id rather put it off into peer_validator.h
4332016-10-04T17:27:35  <BlueMatt> ehh, net_processing.h is what i was calling it
4342016-10-04T17:27:58  <cfields_> BlueMatt: I'm just coding it up with the constraints I've been given. Obviously it's much nicer to just split out the header and use it directly
4352016-10-04T17:27:59  <luke-jr> BlueMatt virtually self-destructs.
4362016-10-04T17:28:01  * luke-jr hides
4372016-10-04T17:28:06  <cfields_> so if that's the plan, sure, no need to do it now
4382016-10-04T17:28:30  <BlueMatt> yea, sorry, i mean my "dont want to expose this" is a weak preference just because main.h is Too Damn Big (tm)
4392016-10-04T17:28:48  <BlueMatt> after the split i see no reason why it shouldnt be exposed (net_processing.h right now is like 4 functions and some forward-declarations)
4402016-10-04T17:29:01  <cfields_> BlueMatt: ok, how about this then...
4412016-10-04T17:29:48  <cfields_> stuff it in main.h for now, hold it cleanly in init, then split it out of main.h as the next step?
4422016-10-04T17:30:03  <cfields_> that way the plan is clear all along. Or is there a reason that doesn't work?
4432016-10-04T17:30:41  <BlueMatt> sure, can do that, too, then I'll just move all the to-be-moved stuff together - RegisterNodeSignals, UnregisterNodeSignals, ProcessMessages, SendMessages, GetNodeStateStats, and Misbehaving
4442016-10-04T17:31:47  <cfields_> BlueMatt: that sounds much better :)
4452016-10-04T17:32:01  <BlueMatt> since main.h moves are easy
4462016-10-04T17:33:09  <BlueMatt> ok, I'ma overwrite the shit out of history on that pr, then
4472016-10-04T17:33:44  <luke-jr> lol
4482016-10-04T17:34:52  * cfields_ salivates at the thought of PeerLogicValidation::mapNodeState
4492016-10-04T17:35:32  <BlueMatt> heh, yup
4502016-10-04T17:36:25  <sipa> at some point i thought about a generic NetmessageProcessor<state> class you could inherit from (with your own state type filled in), which you could register to net
4512016-10-04T17:36:32  <cfields_> maybe this can be the final home for CChainParams as well.
4522016-10-04T17:37:13  <sipa> and you'd have separate instances for dealing with tx relay, block relay, ping, addr management, ...
4532016-10-04T17:37:15  <cfields_> sipa: state types being?
4542016-10-04T17:37:28  <cfields_> ah
4552016-10-04T17:37:36  <sipa> cfields_: well for the ping handler, the state would be a struct that remembers the last sent ping
4562016-10-04T17:37:47  <sipa> for addr management it would be the addrKnown and tosend vectors
4572016-10-04T17:37:49  <sipa> etc
4582016-10-04T17:38:10  <sipa> and you'd have the ability to do parallel processing across different nodes as long as it was about different handlers
4592016-10-04T17:38:16  <cfields_> hmm, interesting
4602016-10-04T17:38:36  <cfields_> how to order dependent messages?
4612016-10-04T17:38:42  <sipa> you don't
4622016-10-04T17:38:49  <cfields_> (for ex the ping ordering that ruins everything)
4632016-10-04T17:39:01  <sipa> you only ever process the oldest unprocessed message for each peer
4642016-10-04T17:39:13  <BlueMatt> we need to discuss ping ordering at some point
4652016-10-04T17:39:26  <BlueMatt> sdaftuar: pointed out that its pretty much violated everywhere wrt block processing
4662016-10-04T17:39:37  <cfields_> oh, gotcha. I missed the "different nodes" part. My brain turned that into "across different messages"
4672016-10-04T17:39:56  <BlueMatt> essentially, i think we need to grep bitcoinj and other spv clients, find all the places where they actually use ping sync, define those, than then say that that is the protocol
4682016-10-04T17:40:16  <sipa> BlueMatt: heh, i thought we'd just stick to synchronous processing all messages
4692016-10-04T17:40:25  *** paveljanik has joined #bitcoin-core-dev
4702016-10-04T17:40:25  *** paveljanik has joined #bitcoin-core-dev
4712016-10-04T17:40:38  <sipa> that's such a huge change to deviate from
4722016-10-04T17:40:51  <sipa> i'd rather redo the p2p protocol from scratch if you're going to change that
4732016-10-04T17:41:15  <BlueMatt> sipa: we already violate it a) with block processing sometimes (sdaftuar thinks this is the cause for some of the compact block test failures, last I heard) and definitely on reject messages
4742016-10-04T17:41:25  <BlueMatt> sipa: so we kinda already deviate from it :/
4752016-10-04T17:41:29  <sipa> we don't
4762016-10-04T17:41:37  <sipa> when receiving a block, we *process* the block fully
4772016-10-04T17:41:46  <sipa> and send all messages in response to that
4782016-10-04T17:41:47  <BlueMatt> sipa: there are several things we send in SendMessages instead of ProcessMessages
4792016-10-04T17:41:50  <BlueMatt> which will violate it
4802016-10-04T17:41:51  <sipa> that doesn't mean we fully validate
4812016-10-04T17:42:07  <sdaftuar> sipa: block announcements are delivered asynchronously (as are block reject messages)
4822016-10-04T17:42:14  <sipa> sdaftuar: sure
4832016-10-04T17:42:23  *** shesek has quit IRC
4842016-10-04T17:43:12  <BlueMatt> cfields_: hope you like your main.h with some #include "validationinterface.h" :p
4852016-10-04T17:44:09  <cfields_> oh wow, i didn't realize we'd slimmed the main.h includes down so much
4862016-10-04T17:44:17  <BlueMatt> yea, they're pretty minimal now
4872016-10-04T17:44:33  <BlueMatt> I dont really mind adding validationinterface, though...we'll kill it soon :)
4882016-10-04T17:44:40  <cfields_> BlueMatt: i think that's fine as long as it's temporary
4892016-10-04T17:45:21  <BlueMatt> yup
4902016-10-04T17:55:10  *** jnewbery has joined #bitcoin-core-dev
4912016-10-04T17:55:17  <BlueMatt> ok, cfields_ see current branch
4922016-10-04T17:57:47  <BlueMatt> gotta love https://github.com/bitcoin/bitcoin/pull/8865/files#diff-e8db9b851adc2422aadfffca88f14c91R523
4932016-10-04T17:58:47  <cfields_> BlueMatt: much better
4942016-10-04T18:00:11  *** microbe has joined #bitcoin-core-dev
4952016-10-04T18:00:31  <luke-jr> lol
4962016-10-04T18:02:36  *** laurentmt has joined #bitcoin-core-dev
4972016-10-04T18:02:44  *** laurentmt has quit IRC
4982016-10-04T18:05:17  <cfields_> BlueMatt: any reason not to simply register/unregister in PeerLogicValidation's ctor/dtor?
4992016-10-04T18:05:36  <BlueMatt> layer violation?
5002016-10-04T18:05:42  <BlueMatt> feel yucky to me
5012016-10-04T18:06:07  <BlueMatt> yea, it feels yucky because "hidden magic"
5022016-10-04T18:07:00  <BlueMatt> the zmq one doesnt do that
5032016-10-04T18:07:19  <cfields_> hmm, as long as the registration is global, it all seems like the same hidden magic to me.
5042016-10-04T18:07:29  <cfields_> but np, was just a thought
5052016-10-04T18:07:48  <BlueMatt> true, but the registration will eventually not be global :p
5062016-10-04T18:08:14  <BlueMatt> i guess I'm kinda thinking about chunks of code as if they were classes even though they are currently not
5072016-10-04T18:08:38  <BlueMatt> since they should be eventually, or even if not they'll be well-isolated so even if not a class, a single common interface feels similar
5082016-10-04T18:09:50  <cfields_> ok, then future request: when you're registering to a signagls instance, and you pass that instance into PeerLogicValidation, make it RAII please :)
5092016-10-04T18:10:46  <BlueMatt> maybe we should just use weak_ptrs for signal instances :p
5102016-10-04T18:10:58  <cfields_> and I think i see what you mean, and sounds good
5112016-10-04T18:11:43  <cfields_> I really wish there was some unique_ptr with a weak_ptr, it would be really useful sometimes. Though some of the semantics kinda make no sense
5122016-10-04T18:12:29  <BlueMatt> yea, would be cool to not have to use shared_ptrs, i guess...would just be somewhat oxymoronic to use it with a unique_ptr
5132016-10-04T18:12:49  *** shesek has joined #bitcoin-core-dev
5142016-10-04T18:13:18  <cfields_> Well the interesting use-case would be: I'm using a unique_ptr, grab it and hold it if it's non-null.
5152016-10-04T18:13:32  <cfields_> so basically a shared_ptr with a max refcount of 2
5162016-10-04T18:13:48  <BlueMatt> yea
5172016-10-04T18:19:09  *** mkarrer has joined #bitcoin-core-dev
5182016-10-04T18:25:14  <GitHub126> [bitcoin] jnewbery opened pull request #8881: Add some verbose logging to bitcoin-util-test.py (master...verbose-bitcoin-util-output) https://github.com/bitcoin/bitcoin/pull/8881
5192016-10-04T18:26:15  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5202016-10-04T18:45:05  *** kyletorpey has joined #bitcoin-core-dev
5212016-10-04T18:45:47  <ill> abovetghelaw
5222016-10-04T18:58:05  *** ill has quit IRC
5232016-10-04T19:10:13  *** microbe has quit IRC
5242016-10-04T19:26:44  *** ill has joined #bitcoin-core-dev
5252016-10-04T19:39:41  *** waxwing has quit IRC
5262016-10-04T19:40:59  *** kyletorpey has quit IRC
5272016-10-04T19:45:41  *** juscamarena has joined #bitcoin-core-dev
5282016-10-04T19:52:53  *** cryptapus has quit IRC
5292016-10-04T19:56:36  <GitHub126> [bitcoin] sdaftuar opened pull request #8882: [qa] Another attempt to fix race condition in p2p-compactblocks.py (master...fix-race-again) https://github.com/bitcoin/bitcoin/pull/8882
5302016-10-04T20:11:04  *** chris2000 has left #bitcoin-core-dev
5312016-10-04T20:11:14  *** shesek has quit IRC
5322016-10-04T20:14:43  *** cdecker_ has joined #bitcoin-core-dev
5332016-10-04T20:14:55  *** cdecker has quit IRC
5342016-10-04T20:21:59  *** jnewbery has quit IRC
5352016-10-04T20:25:33  *** shesek has joined #bitcoin-core-dev
5362016-10-04T20:28:08  *** MarcoFalke has left #bitcoin-core-dev
5372016-10-04T20:33:22  *** Cory has quit IRC
5382016-10-04T20:35:05  *** jnewbery has joined #bitcoin-core-dev
5392016-10-04T20:36:46  *** Cory has joined #bitcoin-core-dev
5402016-10-04T20:45:20  *** Chris_Stewart_5 has quit IRC
5412016-10-04T20:58:15  *** Guyver2 has quit IRC
5422016-10-04T21:00:25  *** juscamarena has quit IRC
5432016-10-04T21:29:17  <GitHub177> [bitcoin] jnewbery opened pull request #8883: Add all standard TXO types to bitcoin-tx (master...add-p2sh-segwit-options-to-bitcoin-tx) https://github.com/bitcoin/bitcoin/pull/8883
5442016-10-04T21:31:48  <luke-jr> sipa: would it help if I rebase and address comments on https://github.com/bitcoin/bitcoin/pull/8448 ?
5452016-10-04T21:57:56  <sipa> luke-jr: i'll do it after 0.13.1
5462016-10-04T21:58:04  <luke-jr> ok
5472016-10-04T21:58:07  <sipa> you can of course, but i wanted to change a few things
5482016-10-04T22:00:30  <luke-jr> sipa: if you'd rather I take it off your load, just let me know what things you'd like changed ;)
5492016-10-04T22:02:25  <sipa> luke-jr: thanks
5502016-10-04T22:14:20  *** justanotheruser has joined #bitcoin-core-dev
5512016-10-04T22:21:44  <GitHub119> [bitcoin] luke-jr opened pull request #8884: Bugfix: Trivial: RPC: getblockchaininfo help: pruneheight is the lowest, not highest, block (master...trivial_pruneheight_help) https://github.com/bitcoin/bitcoin/pull/8884
5522016-10-04T22:35:18  *** jnewbery has quit IRC
5532016-10-04T22:45:51  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5542016-10-04T22:58:42  *** owowo has quit IRC
5552016-10-04T23:04:29  *** owowo has joined #bitcoin-core-dev
5562016-10-04T23:26:29  *** cdecker_ has quit IRC
5572016-10-04T23:42:37  <GitHub135> [bitcoin] theuni opened pull request #8885: gui: fix ban from qt console (master...fix-gui-ban) https://github.com/bitcoin/bitcoin/pull/8885
5582016-10-04T23:57:30  *** jannes has quit IRC