1 2016-10-04T00:00:30  *** jtimon has quit IRC
  2 2016-10-04T00:01:08  *** aureianimus has quit IRC
  3 2016-10-04T00:01:21  *** aureianimus has joined #bitcoin-core-dev
  4 2016-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
  5 2016-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
  6 2016-10-04T00:18:21  *** aureianimus_ has joined #bitcoin-core-dev
  7 2016-10-04T00:18:21  *** aureianimus has quit IRC
  8 2016-10-04T00:30:57  *** JackH has quit IRC
  9 2016-10-04T00:31:14  *** aureianimus_ has quit IRC
 10 2016-10-04T00:31:23  *** aureianimus has joined #bitcoin-core-dev
 11 2016-10-04T00:42:51  *** JackH has joined #bitcoin-core-dev
 12 2016-10-04T00:43:49  *** juscamarena has joined #bitcoin-core-dev
 13 2016-10-04T00:43:55  *** aureianimus has quit IRC
 14 2016-10-04T00:44:08  *** aureianimus has joined #bitcoin-core-dev
 15 2016-10-04T00:47:01  *** Ylbam has quit IRC
 16 2016-10-04T00:47:53  *** tErik_mc has quit IRC
 17 2016-10-04T00:55:19  *** aureianimus has quit IRC
 18 2016-10-04T00:55:31  *** aureianimus has joined #bitcoin-core-dev
 19 2016-10-04T01:05:45  *** bsm117532 is now known as Guest95984
 20 2016-10-04T01:10:01  *** juscamarena has quit IRC
 21 2016-10-04T01:16:13  *** aureianimus has quit IRC
 22 2016-10-04T01:16:25  *** aureianimus has joined #bitcoin-core-dev
 23 2016-10-04T01:17:03  *** aureianimus has joined #bitcoin-core-dev
 24 2016-10-04T01:20:23  *** mkarrer_ has joined #bitcoin-core-dev
 25 2016-10-04T01:23:09  *** mkarrer has quit IRC
 26 2016-10-04T01:33:49  *** aureianimus has quit IRC
 27 2016-10-04T01:34:01  *** aureianimus has joined #bitcoin-core-dev
 28 2016-10-04T01:45:12  *** aureianimus has quit IRC
 29 2016-10-04T01:45:19  *** aureianimus has joined #bitcoin-core-dev
 30 2016-10-04T01:56:05  *** aureianimus has quit IRC
 31 2016-10-04T01:56:15  *** aureianimus has joined #bitcoin-core-dev
 32 2016-10-04T02:02:48  *** randy-waterhouse has joined #bitcoin-core-dev
 33 2016-10-04T02:03:06  *** randy-waterhouse has joined #bitcoin-core-dev
 34 2016-10-04T02:06:33  *** Chris_Stewart_5 has quit IRC
 35 2016-10-04T02:06:57  *** aureianimus has quit IRC
 36 2016-10-04T02:07:11  *** aureianimus has joined #bitcoin-core-dev
 37 2016-10-04T02:15:14  *** juscamarena has joined #bitcoin-core-dev
 38 2016-10-04T02:15:31  *** Alopex has quit IRC
 39 2016-10-04T02:16:37  *** Alopex has joined #bitcoin-core-dev
 40 2016-10-04T02:16:50  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 41 2016-10-04T02:19:56  *** aureianimus has quit IRC
 42 2016-10-04T02:20:06  *** aureianimus has joined #bitcoin-core-dev
 43 2016-10-04T02:20:52  *** aureianimus_ has joined #bitcoin-core-dev
 44 2016-10-04T02:21:08  *** aureianimus has quit IRC
 45 2016-10-04T02:22:09  *** Chris_Stewart_5 has quit IRC
 46 2016-10-04T02:25:38  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 47 2016-10-04T02:28:31  *** Alopex has quit IRC
 48 2016-10-04T02:28:33  <achow101> so how's the prefinal alert doing?
 49 2016-10-04T02:28:48  <achow101> gmaxwell: ^
 50 2016-10-04T02:29:36  *** Alopex has joined #bitcoin-core-dev
 51 2016-10-04T02:39:32  *** aureianimus_ has quit IRC
 52 2016-10-04T02:39:43  *** aureianimus has joined #bitcoin-core-dev
 53 2016-10-04T02:40:22  *** Alopex has quit IRC
 54 2016-10-04T02:41:27  *** Alopex has joined #bitcoin-core-dev
 55 2016-10-04T02:52:10  *** aureianimus has quit IRC
 56 2016-10-04T02:52:15  *** aureianimus_ has joined #bitcoin-core-dev
 57 2016-10-04T03:00:00  *** moli has joined #bitcoin-core-dev
 58 2016-10-04T03:04:09  *** Chris_Stewart_5 has quit IRC
 59 2016-10-04T03:17:01  *** Alopex has quit IRC
 60 2016-10-04T03:18:06  *** Alopex has joined #bitcoin-core-dev
 61 2016-10-04T03:20:13  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 62 2016-10-04T03:32:01  *** Alopex has quit IRC
 63 2016-10-04T03:33:06  *** Alopex has joined #bitcoin-core-dev
 64 2016-10-04T03:36:05  *** aureianimus_ has quit IRC
 65 2016-10-04T03:36:19  *** aureianimus has joined #bitcoin-core-dev
 66 2016-10-04T03:36:34  *** Chris_Stewart_5 has quit IRC
 67 2016-10-04T03:39:44  *** meowzus has joined #bitcoin-core-dev
 68 2016-10-04T03:43:12  *** Alopex has quit IRC
 69 2016-10-04T03:44:17  *** Alopex has joined #bitcoin-core-dev
 70 2016-10-04T03:49:40  *** aureianimus has quit IRC
 71 2016-10-04T03:49:53  *** aureianimus has joined #bitcoin-core-dev
 72 2016-10-04T03:49:59  *** meowzus has quit IRC
 73 2016-10-04T03:54:46  * luke-jr wonders why testnet rewinds blocks every time he runs it
 74 2016-10-04T04:00:55  *** aureianimus has quit IRC
 75 2016-10-04T04:00:56  *** aureianimus_ has joined #bitcoin-core-dev
 76 2016-10-04T04:02:46  *** ill has joined #bitcoin-core-dev
 77 2016-10-04T04:08:16  *** Alopex has quit IRC
 78 2016-10-04T04:09:21  *** Alopex has joined #bitcoin-core-dev
 79 2016-10-04T04:13:23  *** aureianimus_ has quit IRC
 80 2016-10-04T04:13:37  *** aureianimus has joined #bitcoin-core-dev
 81 2016-10-04T04:18:34  *** justan0theruser has joined #bitcoin-core-dev
 82 2016-10-04T04:19:53  *** justanotheruser has quit IRC
 83 2016-10-04T04:32:34  *** aureianimus has quit IRC
 84 2016-10-04T04:32:48  *** aureianimus has joined #bitcoin-core-dev
 85 2016-10-04T04:38:16  <gmaxwell> luke-jr: thats the chainstate check.
 86 2016-10-04T04:39:00  <luke-jr> oh, somehow I was thinking it was for segwit
 87 2016-10-04T04:43:37  *** aureianimus has quit IRC
 88 2016-10-04T04:44:20  *** aureianimus has joined #bitcoin-core-dev
 89 2016-10-04T04:47:06  *** DigiByteDev has joined #bitcoin-core-dev
 90 2016-10-04T04:55:04  *** aureianimus has quit IRC
 91 2016-10-04T04:55:14  *** aureianimus has joined #bitcoin-core-dev
 92 2016-10-04T05:08:26  *** Alopex has quit IRC
 93 2016-10-04T05:09:31  *** Alopex has joined #bitcoin-core-dev
 94 2016-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
 95 2016-10-04T05:14:32  *** aureianimus has quit IRC
 96 2016-10-04T05:14:43  *** aureianimus has joined #bitcoin-core-dev
 97 2016-10-04T05:21:02  *** Alopex has quit IRC
 98 2016-10-04T05:22:07  *** Alopex has joined #bitcoin-core-dev
 99 2016-10-04T05:26:08  *** paveljanik has quit IRC
100 2016-10-04T05:38:36  *** Ylbam has joined #bitcoin-core-dev
101 2016-10-04T05:39:16  *** aureianimus has quit IRC
102 2016-10-04T05:39:25  *** aureianimus has joined #bitcoin-core-dev
103 2016-10-04T06:00:10  *** aureianimus has quit IRC
104 2016-10-04T06:00:19  *** aureianimus has joined #bitcoin-core-dev
105 2016-10-04T06:05:16  *** Alopex has quit IRC
106 2016-10-04T06:06:21  *** Alopex has joined #bitcoin-core-dev
107 2016-10-04T06:21:15  *** aureianimus has quit IRC
108 2016-10-04T06:21:25  *** aureianimus has joined #bitcoin-core-dev
109 2016-10-04T06:32:16  *** aureianimus has quit IRC
110 2016-10-04T06:32:29  *** aureianimus has joined #bitcoin-core-dev
111 2016-10-04T06:52:49  *** DigiByteDev has quit IRC
112 2016-10-04T06:53:59  *** BashCo has quit IRC
113 2016-10-04T06:54:37  *** BashCo has joined #bitcoin-core-dev
114 2016-10-04T06:57:10  *** rubensayshi has joined #bitcoin-core-dev
115 2016-10-04T06:58:49  *** BashCo has quit IRC
116 2016-10-04T06:59:58  *** aureianimus has quit IRC
117 2016-10-04T07:00:09  *** aureianimus has joined #bitcoin-core-dev
118 2016-10-04T07:10:52  *** aureianimus has quit IRC
119 2016-10-04T07:11:05  *** aureianimus has joined #bitcoin-core-dev
120 2016-10-04T07:19:38  *** BashCo has joined #bitcoin-core-dev
121 2016-10-04T07:22:05  *** Giszmo has quit IRC
122 2016-10-04T07:22:07  *** DigiByteDev has joined #bitcoin-core-dev
123 2016-10-04T07:23:31  *** BashCo_ has joined #bitcoin-core-dev
124 2016-10-04T07:24:09  *** juscamarena has quit IRC
125 2016-10-04T07:27:05  *** BashCo has quit IRC
126 2016-10-04T07:31:48  *** aureianimus has quit IRC
127 2016-10-04T07:32:01  *** aureianimus has joined #bitcoin-core-dev
128 2016-10-04T07:43:02  *** aureianimus has quit IRC
129 2016-10-04T07:43:14  *** aureianimus has joined #bitcoin-core-dev
130 2016-10-04T08:04:10  *** aureianimus has quit IRC
131 2016-10-04T08:04:22  *** aureianimus has joined #bitcoin-core-dev
132 2016-10-04T08:10:39  *** laurentmt has joined #bitcoin-core-dev
133 2016-10-04T08:15:05  *** aureianimus has quit IRC
134 2016-10-04T08:15:18  *** aureianimus has joined #bitcoin-core-dev
135 2016-10-04T08:21:11  *** MarcoFalke has joined #bitcoin-core-dev
136 2016-10-04T08:21:17  *** laurentmt has quit IRC
137 2016-10-04T08:26:04  *** aureianimus has quit IRC
138 2016-10-04T08:26:17  *** aureianimus has joined #bitcoin-core-dev
139 2016-10-04T08:26:49  *** laurentmt has joined #bitcoin-core-dev
140 2016-10-04T08:29:30  *** chris2000 has joined #bitcoin-core-dev
141 2016-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
142 2016-10-04T08:37:04  *** aureianimus has quit IRC
143 2016-10-04T08:37:16  *** aureianimus has joined #bitcoin-core-dev
144 2016-10-04T08:37:43  *** ChanServ sets mode: +o wumpus
145 2016-10-04T08:39:46  *** wumpus sets mode: +b #bitcoin-core-de!*@*
146 2016-10-04T08:39:53  *** wumpus sets mode: -b #bitcoin-core-de!*@*
147 2016-10-04T08:40:45  *** wumpus sets mode: +b *!*@s55963df3.adsl.online.nl
148 2016-10-04T08:41:54  *** ChanServ sets mode: -o wumpus
149 2016-10-04T08:42:25  <wumpus> PM me if fixed
150 2016-10-04T08:50:39  *** aureianimus has quit IRC
151 2016-10-04T08:52:17  *** laurentmt has quit IRC
152 2016-10-04T09:08:31  <GitHub132> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/a7e5cbb209d4...7dce175f5d89
153 2016-10-04T09:08:32  <GitHub132> bitcoin/master 47314e6 Wladimir J. van der Laan: prevector: add C++11-like data() method...
154 2016-10-04T09:08:32  <GitHub132> bitcoin/master f00705a Wladimir J. van der Laan: serialize: Deprecate `begin_ptr` / `end_ptr`...
155 2016-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...
156 2016-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
157 2016-10-04T09:21:37  <MarcoFalke> luke-jr: "Rewinding blocks" is always displayed when you run a recent version.
158 2016-10-04T09:21:47  <MarcoFalke> (It does not actually do any rewinding)
159 2016-10-04T09:22:05  *** jannes has joined #bitcoin-core-dev
160 2016-10-04T09:29:54  <wumpus> let's correct the message
161 2016-10-04T09:31:13  <sipa> yeah, just produce no message wgen there is nothing to rewind
162 2016-10-04T09:31:46  <wumpus> it must be doing something if it is visible at all, though
163 2016-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
164 2016-10-04T09:32:55  <sipa> probably the next thing it does after it takes a non-negilgable amount of time
165 2016-10-04T09:33:08  <wumpus> so *that* needs its own message
166 2016-10-04T09:33:12  <wumpus> better fix
167 2016-10-04T09:33:12  <sipa> right
168 2016-10-04T09:33:25  <randy-waterhouse> unwinding ... get a drink
169 2016-10-04T09:33:44  <wumpus> :-)
170 2016-10-04T09:41:20  *** rubensayshi has quit IRC
171 2016-10-04T09:57:54  *** kyletorpey has quit IRC
172 2016-10-04T10:12:12  *** murch has joined #bitcoin-core-dev
173 2016-10-04T10:12:31  *** cdecker has joined #bitcoin-core-dev
174 2016-10-04T10:14:06  *** DigiByteDev has quit IRC
175 2016-10-04T10:14:12  <GitHub70> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7dce175f5d89...d93f0c61843f
176 2016-10-04T10:14:12  <GitHub70> bitcoin/master 905bc68 Cory Fields: net: fix a few cases where messages were sent rather than dropped upon disconnection...
177 2016-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...
178 2016-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
179 2016-10-04T10:18:33  <GitHub79> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d93f0c61843f...d7615af34e8e
180 2016-10-04T10:18:33  <GitHub79> bitcoin/master 2fa0063 Johnson Lau: Add NULLDUMMY verify flag in bitcoinconsensus.h
181 2016-10-04T10:18:34  <GitHub79> bitcoin/master d7615af Wladimir J. van der Laan: Merge #8848: Add NULLDUMMY verify flag in bitcoinconsensus.h...
182 2016-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
183 2016-10-04T10:22:18  *** jtimon has joined #bitcoin-core-dev
184 2016-10-04T10:28:39  *** murch has quit IRC
185 2016-10-04T10:29:28  *** wasi has joined #bitcoin-core-dev
186 2016-10-04T10:33:12  *** wasi_ has joined #bitcoin-core-dev
187 2016-10-04T10:33:12  *** wasi_ has quit IRC
188 2016-10-04T10:41:20  <GitHub49> [bitcoin] MarcoFalke opened pull request #8879: [doc] Rework docs (master...Mf1610-docCleanup) https://github.com/bitcoin/bitcoin/pull/8879
189 2016-10-04T10:46:11  *** belcher has quit IRC
190 2016-10-04T10:58:33  *** belcher has joined #bitcoin-core-dev
191 2016-10-04T11:03:09  *** randy-waterhouse has quit IRC
192 2016-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
193 2016-10-04T11:21:02  *** justan0theruser has quit IRC
194 2016-10-04T11:40:48  *** cryptapus_ has joined #bitcoin-core-dev
195 2016-10-04T11:41:03  *** cryptapus_ is now known as cryptapus
196 2016-10-04T11:47:58  *** DigiByteDev has joined #bitcoin-core-dev
197 2016-10-04T11:53:49  *** paveljanik has joined #bitcoin-core-dev
198 2016-10-04T11:53:49  *** paveljanik has joined #bitcoin-core-dev
199 2016-10-04T12:03:12  *** DigiByteDev has quit IRC
200 2016-10-04T12:05:09  *** paveljanik has quit IRC
201 2016-10-04T12:20:00  *** Chris_Stewart_5 has joined #bitcoin-core-dev
202 2016-10-04T12:22:48  *** wasi has quit IRC
203 2016-10-04T12:23:29  *** wasi has joined #bitcoin-core-dev
204 2016-10-04T12:40:11  *** Evel-Knievel has quit IRC
205 2016-10-04T12:41:14  *** Evel-Knievel has joined #bitcoin-core-dev
206 2016-10-04T12:41:53  *** Chris_Stewart_5 has quit IRC
207 2016-10-04T12:42:23  *** Chris_Stewart_5 has joined #bitcoin-core-dev
208 2016-10-04T12:43:59  *** wasi has quit IRC
209 2016-10-04T12:44:23  *** wasi has joined #bitcoin-core-dev
210 2016-10-04T12:55:09  *** cryptapus has quit IRC
211 2016-10-04T12:55:24  *** cryptapus has joined #bitcoin-core-dev
212 2016-10-04T12:55:24  *** cryptapus has joined #bitcoin-core-dev
213 2016-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?
214 2016-10-04T13:21:45  *** Chris_Stewart_5 has quit IRC
215 2016-10-04T13:32:14  *** DigiByteDev has joined #bitcoin-core-dev
216 2016-10-04T13:34:32  *** Lightsword has left #bitcoin-core-dev
217 2016-10-04T13:37:46  *** Chris_Stewart_5 has joined #bitcoin-core-dev
218 2016-10-04T13:41:56  *** DigiByteDev has quit IRC
219 2016-10-04T13:48:07  *** Guyver2 has joined #bitcoin-core-dev
220 2016-10-04T13:48:44  *** laurentmt has joined #bitcoin-core-dev
221 2016-10-04T13:52:17  *** cryptapus has quit IRC
222 2016-10-04T13:53:28  *** laurentmt has quit IRC
223 2016-10-04T13:59:43  *** cryptapus has joined #bitcoin-core-dev
224 2016-10-04T13:59:45  *** cryptapus has joined #bitcoin-core-dev
225 2016-10-04T14:08:09  *** Guest95984 is now known as bsm117532
226 2016-10-04T14:27:32  *** Giszmo has joined #bitcoin-core-dev
227 2016-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
228 2016-10-04T14:36:44  *** cryptapus has quit IRC
229 2016-10-04T14:41:01  *** cryptapus has joined #bitcoin-core-dev
230 2016-10-04T14:59:37  <cfields_> BlueMatt: please please no :)
231 2016-10-04T14:59:54  <BlueMatt> ehh, its better than another global GetId() thing
232 2016-10-04T15:00:48  <cfields_> BlueMatt: it breaks down ownership models, and will almost certainly lead to teardown issues/races eventually
233 2016-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
234 2016-10-04T15:01:35  <BlueMatt> unless you want the CConnman to own the logic
235 2016-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
236 2016-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
237 2016-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
238 2016-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?
239 2016-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?
240 2016-10-04T15:06:32  <BlueMatt> before the shared ptr? you could delete and dereference null, no?
241 2016-10-04T15:06:43  <BlueMatt> i mean if you failed to teardown, that is
242 2016-10-04T15:07:25  <wumpus> well if it is CConnMan that manages the lifecycle of connections there's not need for shared_ptr
243 2016-10-04T15:07:29  <cfields_> BlueMatt: right, with the caveat that the handler would have to appropriately act on the signal in time
244 2016-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
245 2016-10-04T15:08:17  <BlueMatt> wumpus: not about connections, about the CConnman itself
246 2016-10-04T15:08:56  <wumpus> Init() and Shutdown() 'own' CConnman
247 2016-10-04T15:08:58  <cfields_> BlueMatt: then CConnman will have advertised that all connections have been torn down before it itself is deleted
248 2016-10-04T15:09:05  <wumpus> we have a well defined lifecycle there
249 2016-10-04T15:09:31  <wumpus> after Shutdown there should be no networking anymore, and no connman
250 2016-10-04T15:09:35  *** instagibbs has quit IRC
251 2016-10-04T15:10:09  <wumpus> and everything that uses connman should be deinitialized before ConnMan gets deinitialized
252 2016-10-04T15:10:31  <wumpus> better to have deterministic lifecycles for objects then rely on shared pointers to happen to get things right
253 2016-10-04T15:10:55  <wumpus> or even worse, relying on global constructors/destructors order
254 2016-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.
255 2016-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
256 2016-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
257 2016-10-04T15:16:50  <wumpus> oh right, it may be a multi-phase process
258 2016-10-04T15:18:59  <luke-jr> wumpus: I wasn't objecting to -getinfo <.<
259 2016-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
260 2016-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
261 2016-10-04T15:22:29  *** shesek has quit IRC
262 2016-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
263 2016-10-04T15:25:18  *** molz has joined #bitcoin-core-dev
264 2016-10-04T15:27:26  *** droark has joined #bitcoin-core-dev
265 2016-10-04T15:27:30  *** shesek has joined #bitcoin-core-dev
266 2016-10-04T15:27:37  *** moli has quit IRC
267 2016-10-04T15:29:43  *** Lightsword has joined #bitcoin-core-dev
268 2016-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
269 2016-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)
270 2016-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.
271 2016-10-04T15:36:16  <cfields_> wumpus: right
272 2016-10-04T15:36:30  <cfields_> wumpus: seems the only thing we actually use it for is parsing the config file?
273 2016-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
274 2016-10-04T15:36:53  <wumpus> yes, just replacing it would be trivial, doesn't need a whole options overhaul :)
275 2016-10-04T15:37:07  <cfields_> wumpus: as a stopgap, I just kept it all pretty much as-is
276 2016-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
277 2016-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
278 2016-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
279 2016-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
280 2016-10-04T15:38:48  <cfields_> wumpus: heh, yes. There's certainly the argument that the options shouldn't even be visibile outside of init
281 2016-10-04T15:39:24  <wumpus> and my favorite pet issue https://github.com/bitcoin/bitcoin/issues/1044
282 2016-10-04T15:40:19  <cfields_> mmm, yuck
283 2016-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.
284 2016-10-04T15:40:53  <wumpus> it's in no way a trivial thing to get right
285 2016-10-04T15:41:11  <wumpus> many constraints, and low priority, and the current state well... kind of works
286 2016-10-04T15:41:28  <wumpus> cfields_: yes, validation would be good :)
287 2016-10-04T15:42:33  <cfields_> wumpus: low priority, hint taken :)
288 2016-10-04T15:43:01  <wumpus> well the net refactor is much more important
289 2016-10-04T15:43:33  <wumpus> as well as build system/gitian security
290 2016-10-04T15:44:18  <wumpus> speaking of which how's your mac code-signer project doing?
291 2016-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
292 2016-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
293 2016-10-04T15:46:18  <sipa> i also think luke started on an options thing where they could be changed over time
294 2016-10-04T15:47:08  <wumpus> sipa: sounds good to me
295 2016-10-04T15:48:10  <wumpus> and yes luke-jr has some pulls open that accomplish some of these things
296 2016-10-04T15:49:11  <wumpus> haven't looked very much yet at those, sorry
297 2016-10-04T15:55:20  *** cdecker has quit IRC
298 2016-10-04T15:58:08  *** cdecker has joined #bitcoin-core-dev
299 2016-10-04T15:59:21  <GitHub163> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/5f3e4a8a2ae2dd0e0fa316c6caa50e97280be773
300 2016-10-04T15:59:21  <GitHub163> bitcoin/master 5f3e4a8 Wladimir J. van der Laan: protocol.h: Make enums in GetDataMsg concrete values...
301 2016-10-04T15:59:35  <wumpus> gah oh fuck
302 2016-10-04T16:01:26  <GitHub108> [bitcoin] laanwj force-pushed master from 5f3e4a8 to d7615af: https://github.com/bitcoin/bitcoin/commits/master
303 2016-10-04T16:01:52  *** instagibbs has joined #bitcoin-core-dev
304 2016-10-04T16:01:52  <wumpus> emergency force-push back to d7615af34e8e19920ed12bfdafb09e0e4b57c7c5
305 2016-10-04T16:02:33  * cfields_ goes to verify, i just pulled 5min ago
306 2016-10-04T16:04:08  <wumpus> thanks
307 2016-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)
308 2016-10-04T16:07:55  <sipa> the tree hash?
309 2016-10-04T16:07:56  *** davec has quit IRC
310 2016-10-04T16:07:57  <wumpus> that's the 'tree hash' I suppose?
311 2016-10-04T16:08:12  *** davec has joined #bitcoin-core-dev
312 2016-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
313 2016-10-04T16:09:53  <cfields_> cory@cory-i7:~/dev/bitcoin2(connman-send)$ git ls-tree origin/master | sha256sum
314 2016-10-04T16:09:53  <cfields_> 5f470267d0fc7161ac6193c223f7e76fe135ba33fac35ec39d1adde9324f021f  -
315 2016-10-04T16:10:05  <cfields_> cory@Macbook:~/dev/bitcoin(fix-gui-ban)$ git ls-tree origin/master | sha256sum
316 2016-10-04T16:10:05  <cfields_> 5f470267d0fc7161ac6193c223f7e76fe135ba33fac35ec39d1adde9324f021f  -
317 2016-10-04T16:10:35  <cfields_> 1 pre force-push, 1 post. No surprise, they match :)
318 2016-10-04T16:11:10  <wumpus> good
319 2016-10-04T16:16:04  <BlueMatt> cfields_: sorry, had to step out...do you prefer, then, that we stick with the map<pointer, thing>?
320 2016-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
321 2016-10-04T16:16:43  <cfields_> BlueMatt: for the sake of not holding it up, sure.
322 2016-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?
323 2016-10-04T16:18:30  *** Chris_Stewart_5 has quit IRC
324 2016-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
325 2016-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
326 2016-10-04T16:23:54  *** Guyver2 has quit IRC
327 2016-10-04T16:29:14  *** Guyver2 has joined #bitcoin-core-dev
328 2016-10-04T16:33:41  <BlueMatt> cfields_: hmm, ok...I find that harder to reason about (and it generates more code), but, ehh, whatever
329 2016-10-04T16:33:52  <BlueMatt> cfields_: in any case, thats not something that is less than a lot of work to make happen
330 2016-10-04T16:36:05  <cfields_> BlueMatt: well, lots of things are going to want to own the CConnman. They can't all have it :)
331 2016-10-04T16:36:15  *** mkarrer_ has quit IRC
332 2016-10-04T16:36:38  <sipa> well either it's owned by one thing and one thing only, or it's refcounted
333 2016-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
334 2016-10-04T16:37:17  <BlueMatt> cfields_: aside from the need to provide the setup argument sin init
335 2016-10-04T16:38:55  <cfields_> BlueMatt: rpc/wallet/gui could all make the argument
336 2016-10-04T16:40:28  <sipa> i'd say init creates&owns CConnman, and passes it as argument to rpc/wallet/gui
337 2016-10-04T16:40:37  <sipa> who hold a reference to CConnman, but don't own it
338 2016-10-04T16:40:53  <sipa> and it's init's responsibility to not shut down CConnman before all its users are destroyed
339 2016-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
340 2016-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)
341 2016-10-04T16:41:19  <cfields_> sipa: agree, that's what I'm suggesting as well
342 2016-10-04T16:41:30  <BlueMatt> sipa: ok, well thats what it is now
343 2016-10-04T16:41:35  <BlueMatt> cfields_: was taking objection to that
344 2016-10-04T16:41:58  *** shesek has quit IRC
345 2016-10-04T16:41:59  <sipa> BlueMatt: how so?
346 2016-10-04T16:42:08  <cfields_> BlueMatt: eh? I'm aligned with that. I'm taking objection to a processor taking ownership
347 2016-10-04T16:42:22  <BlueMatt> "a processor"?
348 2016-10-04T16:42:31  <BlueMatt> you mean the PeerValidationLogic
349 2016-10-04T16:42:39  <BlueMatt> it doesnt take ownership, it keeps a pointer to the object
350 2016-10-04T16:42:43  <cfields_> message handler, validator, etc
351 2016-10-04T16:43:04  <BlueMatt> and " it's init's responsibility to not shut down CConnman before all its users are destroyed" :p
352 2016-10-04T16:43:10  <cfields_> BlueMatt: yes, and I'm fine with that :)
353 2016-10-04T16:43:16  <BlueMatt> wait, now I'm confuseg
354 2016-10-04T16:43:20  <BlueMatt> ugh, ok, I'll leave it how it is
355 2016-10-04T16:43:21  <cfields_> just not a shared_ptr
356 2016-10-04T16:43:27  <sipa> well ideally, the PeerValidationLogic is a class, and there is a seaprate instance of it for each CConnman
357 2016-10-04T16:43:35  <sipa> so it can hold a pointer, and does not need a map
358 2016-10-04T16:43:35  <BlueMatt> cfields_: yea, I'll remove that
359 2016-10-04T16:43:50  <BlueMatt> sipa: it does, the map is only as a place to put the storage, mostly
360 2016-10-04T16:44:09  <sipa> BlueMatt: i'll shut up before looking at the
361 2016-10-04T16:44:12  <sipa> code
362 2016-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
363 2016-10-04T16:45:30  <sipa> hmm, shouldn't init create the PeerValidationLogic object, and just pass it the CConnman pointer?
364 2016-10-04T16:45:41  <sipa> there should never be a need to look something up
365 2016-10-04T16:46:03  <BlueMatt> How else do you know which PeerValidationLogic to destroy when someone hands you a CConnman* to Deregister()?
366 2016-10-04T16:46:07  <BlueMatt> i mean aside from iterating
367 2016-10-04T16:46:14  <BlueMatt> anyway, whatever, could also iterate, doesnt matter much
368 2016-10-04T16:46:19  <sipa> init would create the PeerValidationLogic
369 2016-10-04T16:46:22  <sipa> and destroy it
370 2016-10-04T16:46:33  *** shesek has joined #bitcoin-core-dev
371 2016-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
372 2016-10-04T16:47:27  <sipa> ok
373 2016-10-04T16:47:40  <cfields_> BlueMatt: ^^ seems simpler than stashing it in main?
374 2016-10-04T16:47:54  <sipa> all good; "it requires too much refactoring" is a good reason
375 2016-10-04T16:47:58  *** laurentmt has joined #bitcoin-core-dev
376 2016-10-04T16:48:08  <BlueMatt> cfields_: I didnt really want to expose the PeerValidationLogic in main.h yet
377 2016-10-04T16:48:17  <sipa> gah stupid github and its author date based ordering of commits
378 2016-10-04T16:48:23  <BlueMatt> i had originally started doing what sipa said, and then decided i wanted less exposing of shit
379 2016-10-04T16:48:53  <sipa> it took me 10 minutes to figure out why #8871's commits didn't show up in #8393
380 2016-10-04T16:49:08  <sipa> turns out they are there... at the end
381 2016-10-04T16:49:10  <cfields_> BlueMatt: mm, ok. Giving you a pass since the intention is to break stuff out anyway
382 2016-10-04T16:49:14  <cfields_> :)
383 2016-10-04T16:50:36  <BlueMatt> cfields_: heh, ok, will need like 2 more prs for that :p
384 2016-10-04T16:51:32  <cfields_> BlueMatt: wait, isn't it a child of CValidationInterface ?
385 2016-10-04T16:51:43  <BlueMatt> is what?
386 2016-10-04T16:53:01  <cfields_> yea, PeerLogicValidation
387 2016-10-04T16:53:25  <cfields_> why not just keep a base pointer in init?
388 2016-10-04T16:53:58  <BlueMatt> oh, you mean ptr to CValidationInterface
389 2016-10-04T16:54:08  <BlueMatt> hmm, dont we need like a virtual destructor or something crazy like that?
390 2016-10-04T16:54:37  <cfields_> er, setup a base ptr to a dummy interface in init, then actually create it later in the process
391 2016-10-04T16:54:52  <BlueMatt> wait, what?
392 2016-10-04T16:56:35  <cfields_> oh, it's already non-virtual anyway. no need for the dummy
393 2016-10-04T16:56:43  <cfields_> BlueMatt: nm, it can wait 'til later
394 2016-10-04T16:56:45  * BlueMatt is so confused
395 2016-10-04T16:58:18  <cfields_> BlueMatt: i can write it up real quick
396 2016-10-04T16:59:07  <BlueMatt> ugh, y'all and your C++ magic
397 2016-10-04T16:59:08  *** laurentmt has quit IRC
398 2016-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 :)
399 2016-10-04T17:03:37  <BlueMatt> fuck you people
400 2016-10-04T17:04:20  <sipa> though i don't think cfields_ is talking about anything as extreme as that :)
401 2016-10-04T17:04:54  <cfields_> sipa: haha
402 2016-10-04T17:05:04  <cfields_> no, I just mean using a base class as a base class :)
403 2016-10-04T17:07:52  *** BashCo_ has quit IRC
404 2016-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)...
405 2016-10-04T17:08:28  <BlueMatt> right after he finishes learning english, mabye :p
406 2016-10-04T17:09:13  <cfields_> BlueMatt: still hacking it up, just a few min
407 2016-10-04T17:09:33  *** juscamarena has joined #bitcoin-core-dev
408 2016-10-04T17:10:23  <sipa> BlueMatt: crap
409 2016-10-04T17:11:00  <sipa> BlueMatt: fixed
410 2016-10-04T17:17:54  <luke-jr> BlueMatt: "We went looking everywhere, but couldn’t find those commits."
411 2016-10-04T17:18:05  <luke-jr> oh, prob cuz sipa deleted it
412 2016-10-04T17:18:55  * luke-jr peers at MarcoFalke deleting branches quickly after merge
413 2016-10-04T17:20:45  *** juscamarena has quit IRC
414 2016-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
415 2016-10-04T17:21:04  <MarcoFalke> for the above one
416 2016-10-04T17:21:55  <cfields_> BlueMatt: untested POC: https://github.com/theuni/bitcoin/commit/31438dd973a95934ab847fb5ba7d6fa604ee506c
417 2016-10-04T17:22:06  <BlueMatt> testing? who does that???
418 2016-10-04T17:22:36  <BlueMatt> cfields_: omgno
419 2016-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
420 2016-10-04T17:22:49  <BlueMatt> the second I see std::move my eyes glaze over
421 2016-10-04T17:22:54  <cfields_> eh?
422 2016-10-04T17:23:17  <BlueMatt> you're like passing around something without knowledge of the type and using std::move and things
423 2016-10-04T17:23:23  <BlueMatt> i really dont like that
424 2016-10-04T17:23:36  <cfields_> huh? Yes, I'm using virtuals and rvalues...
425 2016-10-04T17:23:50  <cfields_> Everything there is type-safe and defined
426 2016-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
427 2016-10-04T17:26:19  <BlueMatt> i mean you had to add a virtual destructor......
428 2016-10-04T17:26:26  <BlueMatt> was mostly what i was referring to
429 2016-10-04T17:26:28  *** BashCo has joined #bitcoin-core-dev
430 2016-10-04T17:26:37  <BlueMatt> can we just push this off until its in net_processing.h and we can expose the class there?
431 2016-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
432 2016-10-04T17:27:27  <BlueMatt> though, mostly, Id rather put it off into peer_validator.h
433 2016-10-04T17:27:35  <BlueMatt> ehh, net_processing.h is what i was calling it
434 2016-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
435 2016-10-04T17:27:59  <luke-jr> BlueMatt virtually self-destructs.
436 2016-10-04T17:28:01  * luke-jr hides
437 2016-10-04T17:28:06  <cfields_> so if that's the plan, sure, no need to do it now
438 2016-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)
439 2016-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)
440 2016-10-04T17:29:01  <cfields_> BlueMatt: ok, how about this then...
441 2016-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?
442 2016-10-04T17:30:03  <cfields_> that way the plan is clear all along. Or is there a reason that doesn't work?
443 2016-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
444 2016-10-04T17:31:47  <cfields_> BlueMatt: that sounds much better :)
445 2016-10-04T17:32:01  <BlueMatt> since main.h moves are easy
446 2016-10-04T17:33:09  <BlueMatt> ok, I'ma overwrite the shit out of history on that pr, then
447 2016-10-04T17:33:44  <luke-jr> lol
448 2016-10-04T17:34:52  * cfields_ salivates at the thought of PeerLogicValidation::mapNodeState
449 2016-10-04T17:35:32  <BlueMatt> heh, yup
450 2016-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
451 2016-10-04T17:36:32  <cfields_> maybe this can be the final home for CChainParams as well.
452 2016-10-04T17:37:13  <sipa> and you'd have separate instances for dealing with tx relay, block relay, ping, addr management, ...
453 2016-10-04T17:37:15  <cfields_> sipa: state types being?
454 2016-10-04T17:37:28  <cfields_> ah
455 2016-10-04T17:37:36  <sipa> cfields_: well for the ping handler, the state would be a struct that remembers the last sent ping
456 2016-10-04T17:37:47  <sipa> for addr management it would be the addrKnown and tosend vectors
457 2016-10-04T17:37:49  <sipa> etc
458 2016-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
459 2016-10-04T17:38:16  <cfields_> hmm, interesting
460 2016-10-04T17:38:36  <cfields_> how to order dependent messages?
461 2016-10-04T17:38:42  <sipa> you don't
462 2016-10-04T17:38:49  <cfields_> (for ex the ping ordering that ruins everything)
463 2016-10-04T17:39:01  <sipa> you only ever process the oldest unprocessed message for each peer
464 2016-10-04T17:39:13  <BlueMatt> we need to discuss ping ordering at some point
465 2016-10-04T17:39:26  <BlueMatt> sdaftuar: pointed out that its pretty much violated everywhere wrt block processing
466 2016-10-04T17:39:37  <cfields_> oh, gotcha. I missed the "different nodes" part. My brain turned that into "across different messages"
467 2016-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
468 2016-10-04T17:40:16  <sipa> BlueMatt: heh, i thought we'd just stick to synchronous processing all messages
469 2016-10-04T17:40:25  *** paveljanik has joined #bitcoin-core-dev
470 2016-10-04T17:40:25  *** paveljanik has joined #bitcoin-core-dev
471 2016-10-04T17:40:38  <sipa> that's such a huge change to deviate from
472 2016-10-04T17:40:51  <sipa> i'd rather redo the p2p protocol from scratch if you're going to change that
473 2016-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
474 2016-10-04T17:41:25  <BlueMatt> sipa: so we kinda already deviate from it :/
475 2016-10-04T17:41:29  <sipa> we don't
476 2016-10-04T17:41:37  <sipa> when receiving a block, we *process* the block fully
477 2016-10-04T17:41:46  <sipa> and send all messages in response to that
478 2016-10-04T17:41:47  <BlueMatt> sipa: there are several things we send in SendMessages instead of ProcessMessages
479 2016-10-04T17:41:50  <BlueMatt> which will violate it
480 2016-10-04T17:41:51  <sipa> that doesn't mean we fully validate
481 2016-10-04T17:42:07  <sdaftuar> sipa: block announcements are delivered asynchronously (as are block reject messages)
482 2016-10-04T17:42:14  <sipa> sdaftuar: sure
483 2016-10-04T17:42:23  *** shesek has quit IRC
484 2016-10-04T17:43:12  <BlueMatt> cfields_: hope you like your main.h with some #include "validationinterface.h" :p
485 2016-10-04T17:44:09  <cfields_> oh wow, i didn't realize we'd slimmed the main.h includes down so much
486 2016-10-04T17:44:17  <BlueMatt> yea, they're pretty minimal now
487 2016-10-04T17:44:33  <BlueMatt> I dont really mind adding validationinterface, though...we'll kill it soon :)
488 2016-10-04T17:44:40  <cfields_> BlueMatt: i think that's fine as long as it's temporary
489 2016-10-04T17:45:21  <BlueMatt> yup
490 2016-10-04T17:55:10  *** jnewbery has joined #bitcoin-core-dev
491 2016-10-04T17:55:17  <BlueMatt> ok, cfields_ see current branch
492 2016-10-04T17:57:47  <BlueMatt> gotta love https://github.com/bitcoin/bitcoin/pull/8865/files#diff-e8db9b851adc2422aadfffca88f14c91R523
493 2016-10-04T17:58:47  <cfields_> BlueMatt: much better
494 2016-10-04T18:00:11  *** microbe has joined #bitcoin-core-dev
495 2016-10-04T18:00:31  <luke-jr> lol
496 2016-10-04T18:02:36  *** laurentmt has joined #bitcoin-core-dev
497 2016-10-04T18:02:44  *** laurentmt has quit IRC
498 2016-10-04T18:05:17  <cfields_> BlueMatt: any reason not to simply register/unregister in PeerLogicValidation's ctor/dtor?
499 2016-10-04T18:05:36  <BlueMatt> layer violation?
500 2016-10-04T18:05:42  <BlueMatt> feel yucky to me
501 2016-10-04T18:06:07  <BlueMatt> yea, it feels yucky because "hidden magic"
502 2016-10-04T18:07:00  <BlueMatt> the zmq one doesnt do that
503 2016-10-04T18:07:19  <cfields_> hmm, as long as the registration is global, it all seems like the same hidden magic to me.
504 2016-10-04T18:07:29  <cfields_> but np, was just a thought
505 2016-10-04T18:07:48  <BlueMatt> true, but the registration will eventually not be global :p
506 2016-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
507 2016-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
508 2016-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 :)
509 2016-10-04T18:10:46  <BlueMatt> maybe we should just use weak_ptrs for signal instances :p
510 2016-10-04T18:10:58  <cfields_> and I think i see what you mean, and sounds good
511 2016-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
512 2016-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
513 2016-10-04T18:12:49  *** shesek has joined #bitcoin-core-dev
514 2016-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.
515 2016-10-04T18:13:32  <cfields_> so basically a shared_ptr with a max refcount of 2
516 2016-10-04T18:13:48  <BlueMatt> yea
517 2016-10-04T18:19:09  *** mkarrer has joined #bitcoin-core-dev
518 2016-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
519 2016-10-04T18:26:15  *** Chris_Stewart_5 has joined #bitcoin-core-dev
520 2016-10-04T18:45:05  *** kyletorpey has joined #bitcoin-core-dev
521 2016-10-04T18:45:47  <ill> abovetghelaw
522 2016-10-04T18:58:05  *** ill has quit IRC
523 2016-10-04T19:10:13  *** microbe has quit IRC
524 2016-10-04T19:26:44  *** ill has joined #bitcoin-core-dev
525 2016-10-04T19:39:41  *** waxwing has quit IRC
526 2016-10-04T19:40:59  *** kyletorpey has quit IRC
527 2016-10-04T19:45:41  *** juscamarena has joined #bitcoin-core-dev
528 2016-10-04T19:52:53  *** cryptapus has quit IRC
529 2016-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
530 2016-10-04T20:11:04  *** chris2000 has left #bitcoin-core-dev
531 2016-10-04T20:11:14  *** shesek has quit IRC
532 2016-10-04T20:14:43  *** cdecker_ has joined #bitcoin-core-dev
533 2016-10-04T20:14:55  *** cdecker has quit IRC
534 2016-10-04T20:21:59  *** jnewbery has quit IRC
535 2016-10-04T20:25:33  *** shesek has joined #bitcoin-core-dev
536 2016-10-04T20:28:08  *** MarcoFalke has left #bitcoin-core-dev
537 2016-10-04T20:33:22  *** Cory has quit IRC
538 2016-10-04T20:35:05  *** jnewbery has joined #bitcoin-core-dev
539 2016-10-04T20:36:46  *** Cory has joined #bitcoin-core-dev
540 2016-10-04T20:45:20  *** Chris_Stewart_5 has quit IRC
541 2016-10-04T20:58:15  *** Guyver2 has quit IRC
542 2016-10-04T21:00:25  *** juscamarena has quit IRC
543 2016-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
544 2016-10-04T21:31:48  <luke-jr> sipa: would it help if I rebase and address comments on https://github.com/bitcoin/bitcoin/pull/8448 ?
545 2016-10-04T21:57:56  <sipa> luke-jr: i'll do it after 0.13.1
546 2016-10-04T21:58:04  <luke-jr> ok
547 2016-10-04T21:58:07  <sipa> you can of course, but i wanted to change a few things
548 2016-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 ;)
549 2016-10-04T22:02:25  <sipa> luke-jr: thanks
550 2016-10-04T22:14:20  *** justanotheruser has joined #bitcoin-core-dev
551 2016-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
552 2016-10-04T22:35:18  *** jnewbery has quit IRC
553 2016-10-04T22:45:51  *** Chris_Stewart_5 has joined #bitcoin-core-dev
554 2016-10-04T22:58:42  *** owowo has quit IRC
555 2016-10-04T23:04:29  *** owowo has joined #bitcoin-core-dev
556 2016-10-04T23:26:29  *** cdecker_ has quit IRC
557 2016-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
558 2016-10-04T23:57:30  *** jannes has quit IRC