1 2017-01-06T00:00:01  *** Squidicc has quit IRC
  2 2017-01-06T00:02:53  *** Evel-Knievel has quit IRC
  3 2017-01-06T00:11:15  *** brg444 has quit IRC
  4 2017-01-06T00:31:05  *** TomMc has quit IRC
  5 2017-01-06T00:36:22  *** PRab has quit IRC
  6 2017-01-06T00:39:02  *** brg444 has joined #bitcoin-core-dev
  7 2017-01-06T00:42:15  *** dcousens has joined #bitcoin-core-dev
  8 2017-01-06T00:57:26  *** Ylbam has quit IRC
  9 2017-01-06T00:57:37  <luke-jr> sipa: I see your point. paveljanik: are you already working on a PR, or shall I?
 10 2017-01-06T00:57:42  <gmaxwell> 16:53 < Michail1> gmaxwell - Mental note:  bitcoin-0.13.2-win64-setup.exe is detected by Norton (File Insight) as not safe and  automatically removes it.  (Not that you can do anything about it, just letting you know.)  I am confirming the prior  versions are not auto deleted.
 11 2017-01-06T00:58:06  *** abpa has quit IRC
 12 2017-01-06T00:58:40  *** wasi has joined #bitcoin-core-dev
 13 2017-01-06T01:07:47  *** Chris_Stewart_5 has quit IRC
 14 2017-01-06T01:13:51  *** belcher has quit IRC
 15 2017-01-06T01:13:51  *** rubensayshi has quit IRC
 16 2017-01-06T01:13:52  *** owowo has quit IRC
 17 2017-01-06T01:13:52  *** paracyst has quit IRC
 18 2017-01-06T01:13:52  *** PatBoy has quit IRC
 19 2017-01-06T01:13:52  *** Eliel has quit IRC
 20 2017-01-06T01:13:52  *** michagogo has quit IRC
 21 2017-01-06T01:13:52  *** sipa has quit IRC
 22 2017-01-06T01:13:52  *** Lightsword has quit IRC
 23 2017-01-06T01:13:52  *** ill has quit IRC
 24 2017-01-06T01:13:52  *** nanotube has quit IRC
 25 2017-01-06T01:13:53  *** aspect_ has quit IRC
 26 2017-01-06T01:13:53  *** midnightmagic has quit IRC
 27 2017-01-06T01:13:53  *** jonasschnelli has quit IRC
 28 2017-01-06T01:13:53  *** ryan-c has quit IRC
 29 2017-01-06T01:17:53  *** lightningbot has joined #bitcoin-core-dev
 30 2017-01-06T01:18:48  *** rubensayshi has joined #bitcoin-core-dev
 31 2017-01-06T01:21:10  *** michagogo has joined #bitcoin-core-dev
 32 2017-01-06T01:21:57  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 33 2017-01-06T01:22:03  *** nanotube has joined #bitcoin-core-dev
 34 2017-01-06T01:22:19  *** gwollon is now known as gwillen
 35 2017-01-06T01:24:44  *** wallet42 has joined #bitcoin-core-dev
 36 2017-01-06T01:24:59  *** limpkin has joined #bitcoin-core-dev
 37 2017-01-06T01:25:41  <bitcoin-git> [bitcoin] kallewoof closed pull request #9478: Trivial refactor: BOOST_FOREACH(a, b) -> for (a : b) (master...replace-boostforeach) https://github.com/bitcoin/bitcoin/pull/9478
 38 2017-01-06T01:26:16  *** CodeShark has joined #bitcoin-core-dev
 39 2017-01-06T01:33:54  *** aspect_ has joined #bitcoin-core-dev
 40 2017-01-06T01:40:03  *** eragmus has joined #bitcoin-core-dev
 41 2017-01-06T01:41:05  *** mappum has joined #bitcoin-core-dev
 42 2017-01-06T01:49:55  *** abpa has joined #bitcoin-core-dev
 43 2017-01-06T02:20:15  <kallewoof> sipa: i have 4 nodes (n1-n4) partitioned into two nets (n12 n34). n2 and n3 both spend the same UTXO, then 6 blocks are generated on each side after which the nets are merged and an additional block is generated on n4 causing the n3 transaction to take precedence, knocking the n1 transaction out. this is sometimes listed in listsinceblock and sometimes not.
 44 2017-01-06T02:21:08  <kallewoof> sipa: I tried putting a 1 sec delay after the generate to see if there was some wallet fiddling that did not finish in time but this did not change the outcome.
 45 2017-01-06T02:31:03  <gmaxwell> listed in listsinceblock on which side?
 46 2017-01-06T02:31:18  <gmaxwell> and which block are you listing since?
 47 2017-01-06T02:34:29  <kallewoof> I am calling listsinceblock from n1
 48 2017-01-06T02:36:32  <kallewoof> What's fascinating is that, for the MISSING case (i.e. when it doesn't list the now-orphaned transaction originating from n2), n1 has this in the debug.log file, and for the present case it does not have this:
 49 2017-01-06T02:36:34  <kallewoof> 2017-01-05 11:04:46 Transaction efd9e5d4daf8d47a2cc07db0e153513b2d02da2e031d3f2398f804b2a3d7ba03 (in block 2fd09b11259689722ec38873aeedc7e27753a587f66a542bb2ae64546b17943f) conflicts with wallet transaction 5c717b80ee4e4909e9f4a15bfacd728c3be8c1e75d6eed83a3e9324f6b9ea38c (both spend f72d9d38468c40777640e5b7731dab76cd961ee60cc93198b2ec706c21fb1801:0)
 50 2017-01-06T02:40:54  <kallewoof> I guess since the transaction was overridden by another one, 'orphaned' is probably not the right term. 'Invalidated'? 'Betrayed'? Anyway, the tx that lost the UTXO race.
 51 2017-01-06T02:42:04  <kallewoof> A bit verbose but you can compare the two cases here: http://pastebin.com/EqupZuFM (missing) and here: http://pastebin.com/Phy6mN3G (present)
 52 2017-01-06T02:45:39  *** Chris_Stewart_5 has quit IRC
 53 2017-01-06T02:46:27  *** Giszmo has quit IRC
 54 2017-01-06T03:01:25  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 55 2017-01-06T03:14:51  *** abpa has quit IRC
 56 2017-01-06T03:17:52  *** Chris_Stewart_5 has quit IRC
 57 2017-01-06T03:43:30  *** tunafizz has joined #bitcoin-core-dev
 58 2017-01-06T04:02:40  <phantomcircuit> kallewoof, conflicted
 59 2017-01-06T05:01:52  *** roidster has quit IRC
 60 2017-01-06T05:06:36  *** CubicEarth has quit IRC
 61 2017-01-06T05:10:32  *** CubicEarth has joined #bitcoin-core-dev
 62 2017-01-06T05:15:48  *** CubicEarth has quit IRC
 63 2017-01-06T05:35:13  <paveljanik> luke-jr, I'm not (I was sleeping ;-)
 64 2017-01-06T06:32:40  <gmaxwell> morcos:  par=4 synctime of 24453.715550 (all signatures checked), and par=max (24 actual core host) 12182.296543...  so yea, I suppose it's scaling better than it used to.
 65 2017-01-06T06:33:10  <gmaxwell> (these figures with dbcache=2000)
 66 2017-01-06T06:52:07  *** Ylbam has joined #bitcoin-core-dev
 67 2017-01-06T06:54:12  *** Alopex has quit IRC
 68 2017-01-06T06:55:17  *** Alopex has joined #bitcoin-core-dev
 69 2017-01-06T07:00:07  *** dermoth has quit IRC
 70 2017-01-06T07:01:06  *** dermoth has joined #bitcoin-core-dev
 71 2017-01-06T07:09:55  *** brg444 has quit IRC
 72 2017-01-06T07:59:06  *** Alopex has quit IRC
 73 2017-01-06T08:00:12  *** Alopex has joined #bitcoin-core-dev
 74 2017-01-06T08:08:17  *** kadoban has quit IRC
 75 2017-01-06T08:21:28  *** Victor_sueca has quit IRC
 76 2017-01-06T08:22:26  *** paveljanik has quit IRC
 77 2017-01-06T08:23:31  *** Guest26441 has quit IRC
 78 2017-01-06T08:23:48  *** instagibbs has quit IRC
 79 2017-01-06T08:24:40  *** paveljanik has joined #bitcoin-core-dev
 80 2017-01-06T08:25:25  *** sdaftuar has quit IRC
 81 2017-01-06T08:25:57  *** zxzzt has quit IRC
 82 2017-01-06T08:26:28  *** roasbeef has quit IRC
 83 2017-01-06T08:26:32  *** sdaftuar has joined #bitcoin-core-dev
 84 2017-01-06T08:26:41  *** zxzzt has joined #bitcoin-core-dev
 85 2017-01-06T08:27:04  *** thib_ has joined #bitcoin-core-dev
 86 2017-01-06T08:28:28  *** jyap has joined #bitcoin-core-dev
 87 2017-01-06T08:28:37  *** windsok has quit IRC
 88 2017-01-06T08:28:46  *** instagibbs has joined #bitcoin-core-dev
 89 2017-01-06T08:29:35  <jonasschnelli> I'm not very familiar with bloom filters,... for the concept of a block filter committment, I get the point of creating a CBloomFilter for a block containing al inputs and outputs of the containing txs.
 90 2017-01-06T08:29:43  <jonasschnelli> What I don't see how this would be possible is...
 91 2017-01-06T08:30:16  <jonasschnelli> how you then could compare a CBloomFilter created with ones wallet pubkeys against the block committment CBloomFilter.
 92 2017-01-06T08:30:35  <jonasschnelli> I though you have to compare each key from your local wallet against the block-wide committment filter?
 93 2017-01-06T08:31:30  *** morcos has quit IRC
 94 2017-01-06T08:31:31  *** amiller has quit IRC
 95 2017-01-06T08:31:31  *** mr_burdell has quit IRC
 96 2017-01-06T08:31:32  *** Guest98817 has quit IRC
 97 2017-01-06T08:31:32  *** so has quit IRC
 98 2017-01-06T08:31:32  *** AaronvanW has quit IRC
 99 2017-01-06T08:31:33  *** wumpus has quit IRC
100 2017-01-06T08:31:33  *** cjamthagen has quit IRC
101 2017-01-06T08:31:33  *** afk11 has quit IRC
102 2017-01-06T08:31:33  *** molz has quit IRC
103 2017-01-06T08:31:34  *** eenoch has quit IRC
104 2017-01-06T08:31:34  *** GAit has quit IRC
105 2017-01-06T08:31:34  *** kallewoof has quit IRC
106 2017-01-06T08:31:34  *** warren has quit IRC
107 2017-01-06T08:31:34  *** lesderid has quit IRC
108 2017-01-06T08:31:34  *** thestringpuller has quit IRC
109 2017-01-06T08:31:35  *** jeremias has quit IRC
110 2017-01-06T08:31:35  *** NicolasDorier has quit IRC
111 2017-01-06T08:31:35  *** pindarhk has quit IRC
112 2017-01-06T08:31:35  *** btcdrak has quit IRC
113 2017-01-06T08:31:35  *** jcorgan has quit IRC
114 2017-01-06T08:31:35  *** shinobimonkey has quit IRC
115 2017-01-06T08:31:35  *** gmaxwell has quit IRC
116 2017-01-06T08:31:35  *** adiabat has quit IRC
117 2017-01-06T08:31:35  *** Cory has quit IRC
118 2017-01-06T08:31:36  *** atroxes has quit IRC
119 2017-01-06T08:31:36  *** xHire has quit IRC
120 2017-01-06T08:31:36  *** emzy has quit IRC
121 2017-01-06T08:31:36  *** wbnns has quit IRC
122 2017-01-06T08:31:36  *** thrasher` has quit IRC
123 2017-01-06T08:31:36  *** isis has quit IRC
124 2017-01-06T08:31:36  *** petertodd has quit IRC
125 2017-01-06T08:31:36  *** fengling has quit IRC
126 2017-01-06T08:31:36  *** Magma has quit IRC
127 2017-01-06T08:31:36  *** [Author] has quit IRC
128 2017-01-06T08:31:36  *** LeMiner has quit IRC
129 2017-01-06T08:31:37  *** achow101 has quit IRC
130 2017-01-06T08:31:37  *** cryptapus_afk has quit IRC
131 2017-01-06T08:31:37  *** murchandamus has quit IRC
132 2017-01-06T08:31:38  *** Jouke has quit IRC
133 2017-01-06T08:31:38  *** crudel has quit IRC
134 2017-01-06T08:31:38  *** Madars has quit IRC
135 2017-01-06T08:31:38  *** face has quit IRC
136 2017-01-06T08:31:38  *** mturquette has quit IRC
137 2017-01-06T08:31:38  *** Anduck has quit IRC
138 2017-01-06T08:31:38  *** rabidus_ has quit IRC
139 2017-01-06T08:31:38  *** ensign has quit IRC
140 2017-01-06T08:31:38  *** cfields has quit IRC
141 2017-01-06T08:31:38  *** kanzure has quit IRC
142 2017-01-06T08:31:38  *** cysm has quit IRC
143 2017-01-06T08:31:38  *** thib has quit IRC
144 2017-01-06T08:31:38  *** e4xit has quit IRC
145 2017-01-06T08:31:39  *** echonaut has quit IRC
146 2017-01-06T08:31:39  *** dgenr8 has quit IRC
147 2017-01-06T08:31:39  *** thermoman has quit IRC
148 2017-01-06T08:31:39  *** jeremyrubin has quit IRC
149 2017-01-06T08:31:39  *** niska` has quit IRC
150 2017-01-06T08:33:49  *** profall has quit IRC
151 2017-01-06T08:33:59  *** limpkin has quit IRC
152 2017-01-06T08:37:45  *** LeMiner has joined #bitcoin-core-dev
153 2017-01-06T08:37:45  *** AaronvanW has joined #bitcoin-core-dev
154 2017-01-06T08:37:45  *** fengling has joined #bitcoin-core-dev
155 2017-01-06T08:37:45  *** jeremias has joined #bitcoin-core-dev
156 2017-01-06T08:37:45  *** NicolasDorier has joined #bitcoin-core-dev
157 2017-01-06T08:37:45  *** pindarhk has joined #bitcoin-core-dev
158 2017-01-06T08:37:45  *** jcorgan has joined #bitcoin-core-dev
159 2017-01-06T08:37:45  *** molz has joined #bitcoin-core-dev
160 2017-01-06T08:37:45  *** e4xit has joined #bitcoin-core-dev
161 2017-01-06T08:37:45  *** achow101 has joined #bitcoin-core-dev
162 2017-01-06T08:37:45  *** wumpus has joined #bitcoin-core-dev
163 2017-01-06T08:37:45  *** shinobimonkey has joined #bitcoin-core-dev
164 2017-01-06T08:37:45  *** cryptapus_afk has joined #bitcoin-core-dev
165 2017-01-06T08:37:45  *** cjamthagen has joined #bitcoin-core-dev
166 2017-01-06T08:37:45  *** afk11 has joined #bitcoin-core-dev
167 2017-01-06T08:37:45  *** gmaxwell has joined #bitcoin-core-dev
168 2017-01-06T08:37:45  *** eenoch has joined #bitcoin-core-dev
169 2017-01-06T08:37:45  *** echonaut has joined #bitcoin-core-dev
170 2017-01-06T08:37:45  *** adiabat has joined #bitcoin-core-dev
171 2017-01-06T08:37:45  *** dgenr8 has joined #bitcoin-core-dev
172 2017-01-06T08:37:45  *** morcos has joined #bitcoin-core-dev
173 2017-01-06T08:37:45  *** Magma has joined #bitcoin-core-dev
174 2017-01-06T08:37:45  *** Guest98817 has joined #bitcoin-core-dev
175 2017-01-06T08:37:45  *** GAit has joined #bitcoin-core-dev
176 2017-01-06T08:37:45  *** murchandamus has joined #bitcoin-core-dev
177 2017-01-06T08:37:45  *** thermoman has joined #bitcoin-core-dev
178 2017-01-06T08:37:45  *** kallewoof has joined #bitcoin-core-dev
179 2017-01-06T08:37:45  *** jeremyrubin has joined #bitcoin-core-dev
180 2017-01-06T08:37:45  *** Jouke has joined #bitcoin-core-dev
181 2017-01-06T08:37:45  *** petertodd has joined #bitcoin-core-dev
182 2017-01-06T08:37:45  *** Cory has joined #bitcoin-core-dev
183 2017-01-06T08:37:45  *** xHire has joined #bitcoin-core-dev
184 2017-01-06T08:37:45  *** [Author] has joined #bitcoin-core-dev
185 2017-01-06T08:37:45  *** crudel has joined #bitcoin-core-dev
186 2017-01-06T08:37:45  *** Madars has joined #bitcoin-core-dev
187 2017-01-06T08:37:45  *** face has joined #bitcoin-core-dev
188 2017-01-06T08:37:45  *** amiller has joined #bitcoin-core-dev
189 2017-01-06T08:37:45  *** mturquette has joined #bitcoin-core-dev
190 2017-01-06T08:37:45  *** atroxes has joined #bitcoin-core-dev
191 2017-01-06T08:37:45  *** mr_burdell has joined #bitcoin-core-dev
192 2017-01-06T08:37:45  *** warren has joined #bitcoin-core-dev
193 2017-01-06T08:37:45  *** Anduck has joined #bitcoin-core-dev
194 2017-01-06T08:37:45  *** rabidus_ has joined #bitcoin-core-dev
195 2017-01-06T08:37:45  *** emzy has joined #bitcoin-core-dev
196 2017-01-06T08:37:45  *** ensign has joined #bitcoin-core-dev
197 2017-01-06T08:37:45  *** lesderid has joined #bitcoin-core-dev
198 2017-01-06T08:37:45  *** cfields has joined #bitcoin-core-dev
199 2017-01-06T08:37:45  *** kanzure has joined #bitcoin-core-dev
200 2017-01-06T08:37:45  *** cysm has joined #bitcoin-core-dev
201 2017-01-06T08:37:45  *** thestringpuller has joined #bitcoin-core-dev
202 2017-01-06T08:37:45  *** thrasher` has joined #bitcoin-core-dev
203 2017-01-06T08:37:45  *** niska` has joined #bitcoin-core-dev
204 2017-01-06T08:37:45  *** wbnns has joined #bitcoin-core-dev
205 2017-01-06T08:37:45  *** isis has joined #bitcoin-core-dev
206 2017-01-06T08:39:15  *** jyap has quit IRC
207 2017-01-06T08:39:15  *** jyap has joined #bitcoin-core-dev
208 2017-01-06T08:39:32  *** Victorsueca has joined #bitcoin-core-dev
209 2017-01-06T08:40:03  *** thib_ has quit IRC
210 2017-01-06T08:40:04  *** michagogo has quit IRC
211 2017-01-06T08:40:31  *** wallet42 has quit IRC
212 2017-01-06T08:41:21  *** roasbeef has joined #bitcoin-core-dev
213 2017-01-06T08:41:47  *** profall has joined #bitcoin-core-dev
214 2017-01-06T08:42:20  *** btcdrak has joined #bitcoin-core-dev
215 2017-01-06T08:45:21  *** jonasschnelli has quit IRC
216 2017-01-06T08:46:27  *** jonasschnelli has joined #bitcoin-core-dev
217 2017-01-06T08:47:49  *** jonasschnelli has quit IRC
218 2017-01-06T08:47:49  *** jonasschnelli has joined #bitcoin-core-dev
219 2017-01-06T08:47:59  *** limpkin has joined #bitcoin-core-dev
220 2017-01-06T08:51:21  *** wallet42 has joined #bitcoin-core-dev
221 2017-01-06T08:55:17  *** michagogo has joined #bitcoin-core-dev
222 2017-01-06T09:14:00  *** chjj has joined #bitcoin-core-dev
223 2017-01-06T09:17:02  *** windsok has joined #bitcoin-core-dev
224 2017-01-06T09:24:33  *** jannes has joined #bitcoin-core-dev
225 2017-01-06T09:31:08  *** goregrin1 is now known as goregrind
226 2017-01-06T09:31:57  *** so has joined #bitcoin-core-dev
227 2017-01-06T09:41:21  *** laurentmt has joined #bitcoin-core-dev
228 2017-01-06T09:48:53  <bitcoin-git> [bitcoin] jonasschnelli closed pull request #7826: [Qt] show conflicts of unconfirmed transactions in the UI (master...2016/04/ui_mem_cflct) https://github.com/bitcoin/bitcoin/pull/7826
229 2017-01-06T09:49:14  <bitcoin-git> [bitcoin] jonasschnelli closed pull request #7817: [Qt] attribute replaceable (RBF) transactions (master...2016/04/qt_rbf) https://github.com/bitcoin/bitcoin/pull/7817
230 2017-01-06T09:56:09  *** laurentmt has quit IRC
231 2017-01-06T10:03:11  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #9481: [Qt] Show more significant warning if we fall back to the default fee (master...2017/01/fee_warning) https://github.com/bitcoin/bitcoin/pull/9481
232 2017-01-06T10:13:52  <btcdrak> jonasschnelli: I'm willing to test those this weekend...
233 2017-01-06T10:14:27  <jonasschnelli> btcdrak: They need overhaul from my side, don't bother
234 2017-01-06T10:14:33  <btcdrak> ok
235 2017-01-06T10:14:50  <jonasschnelli> I'll re-base overhaul them as soon as they rise on my pile-of-work
236 2017-01-06T10:27:49  *** Giszmo has joined #bitcoin-core-dev
237 2017-01-06T10:46:31  *** windsok has quit IRC
238 2017-01-06T10:56:36  *** MarcoFalke has joined #bitcoin-core-dev
239 2017-01-06T11:25:44  *** paveljanik has quit IRC
240 2017-01-06T11:35:57  *** windsok has joined #bitcoin-core-dev
241 2017-01-06T12:37:47  *** MarcoFalke has left #bitcoin-core-dev
242 2017-01-06T13:01:22  *** laurentmt has joined #bitcoin-core-dev
243 2017-01-06T13:02:12  *** laurentmt has quit IRC
244 2017-01-06T13:25:59  *** berndj has joined #bitcoin-core-dev
245 2017-01-06T13:38:26  *** Chris_Stewart_5 has joined #bitcoin-core-dev
246 2017-01-06T13:43:42  *** Chris_Stewart_5 has quit IRC
247 2017-01-06T13:49:19  <jonasschnelli> Request for review: #9294
248 2017-01-06T13:49:21  <gribble> https://github.com/bitcoin/bitcoin/issues/9294 | Use internal HD chain for change outputs (hd split) by jonasschnelli · Pull Request #9294 · bitcoin/bitcoin · GitHub
249 2017-01-06T13:53:24  *** Chris_Stewart_5 has joined #bitcoin-core-dev
250 2017-01-06T13:55:58  <morcos> gmaxwell: re: CreateTransaction logging, I think thats a great idea.  If needed we could even make fee estimation take a bool to output more debugging information for the times its called via CreateTransaction.  but even without that, just having the basic info would be nice.
251 2017-01-06T14:04:22  *** BashCo has quit IRC
252 2017-01-06T14:06:38  *** laurentmt has joined #bitcoin-core-dev
253 2017-01-06T14:15:39  *** Chris_Stewart_5 has quit IRC
254 2017-01-06T14:23:24  <jonasschnelli> Idea: would it be stupid to use the first 16 addrs of the dns-seeder DNS response as a "hidden" secp256k1 compact sig for the next 16 addrs of a complete response of 32 addrs?
255 2017-01-06T14:23:41  *** BashCo has joined #bitcoin-core-dev
256 2017-01-06T14:23:58  <jonasschnelli> Then ship apps with an ec pubkey per seeder (that supports signed dns responses)
257 2017-01-06T14:24:23  <jonasschnelli> I think this approach would be a simple hack and much less work then switching to DNSSEC
258 2017-01-06T14:26:34  <sipa> jonasschnelli: i believw intermediate resolvers can reorder/filter responses
259 2017-01-06T14:29:13  <gmaxwell> s/can/constantly/
260 2017-01-06T14:30:03  <gmaxwell> a lot of intermediate resolvers trim the results to just a few,  and many (most?) reorder them (e.g. under the assumption that the final device will use the first, then yielding a cached response they reorder to avoid overloading the source).
261 2017-01-06T14:31:39  *** Chris_Stewart_5 has joined #bitcoin-core-dev
262 2017-01-06T14:39:20  *** Guyver2 has joined #bitcoin-core-dev
263 2017-01-06T14:40:02  *** BCBot_ has quit IRC
264 2017-01-06T14:49:10  *** laurentmt has quit IRC
265 2017-01-06T14:51:45  <jonasschnelli> hmm... that unfortunate.
266 2017-01-06T14:55:33  *** BCBot has joined #bitcoin-core-dev
267 2017-01-06T14:58:18  *** BCBot has quit IRC
268 2017-01-06T14:58:33  *** BCBot has joined #bitcoin-core-dev
269 2017-01-06T15:04:21  *** TomMc has joined #bitcoin-core-dev
270 2017-01-06T15:05:52  *** MarcoFalke has joined #bitcoin-core-dev
271 2017-01-06T15:19:18  *** Evel-Knievel has joined #bitcoin-core-dev
272 2017-01-06T15:20:08  *** Alina-malina has quit IRC
273 2017-01-06T15:20:30  *** Alina-malina has joined #bitcoin-core-dev
274 2017-01-06T15:22:23  *** Alina-malina has quit IRC
275 2017-01-06T15:22:23  *** Alina-malina has joined #bitcoin-core-dev
276 2017-01-06T16:05:05  *** whphhg has joined #bitcoin-core-dev
277 2017-01-06T16:05:06  *** Chris_Stewart_5 has quit IRC
278 2017-01-06T16:06:07  *** Chris_Stewart_5 has joined #bitcoin-core-dev
279 2017-01-06T16:12:10  <jonasschnelli> We do we try to connect to the dnsseeder on 8333? One-shot getaddr?
280 2017-01-06T16:14:04  <sipa> ?
281 2017-01-06T16:14:46  <sipa> you mean why does the oneshot concept exist?
282 2017-01-06T16:15:14  <sipa> if you're connecting over Tor you shouldn't do DNS lookups, as they'd leak your traffic
283 2017-01-06T16:15:37  <jonasschnelli> sipa: That was the problem! Dam Qt settings...
284 2017-01-06T16:16:03  <jonasschnelli> Now I also know why my SPV block downloads where slower then expected. :)
285 2017-01-06T16:16:19  <sipa> so instead we "connect" to the seeder, which in practice means we're connecting to a Tor exit router, and make the router resoove the seeder, and connect tovit
286 2017-01-06T16:16:37  <sipa> we don't actually learn what IP we're connecting to in that case
287 2017-01-06T16:26:26  *** Chris_Stewart_5 has quit IRC
288 2017-01-06T16:32:17  *** Chris_Stewart_5 has joined #bitcoin-core-dev
289 2017-01-06T16:38:09  <bitcoin-git> [bitcoin] sipa pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/f646275b90b1...a55716abe566
290 2017-01-06T16:38:10  <bitcoin-git> bitcoin/master 50bd12c Gregory Maxwell: Break addnode out from the outbound connection limits....
291 2017-01-06T16:38:11  <bitcoin-git> bitcoin/master 90f13e1 Gregory Maxwell: Add release notes for addnode changes.
292 2017-01-06T16:38:11  <bitcoin-git> bitcoin/master 032ba3f Gregory Maxwell: RPC help documentation for addnode peerinfo....
293 2017-01-06T16:38:24  <bitcoin-git> [bitcoin] sipa closed pull request #9319: Break addnode out from the outbound connection limits. (master...addnode_own_count) https://github.com/bitcoin/bitcoin/pull/9319
294 2017-01-06T16:44:57  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #9483: Complete hybrid full block SPV mode (master...2017/01/spv) https://github.com/bitcoin/bitcoin/pull/9483
295 2017-01-06T16:45:10  <midnightmagic> \o/  YAYYY
296 2017-01-06T16:45:45  *** brg444 has joined #bitcoin-core-dev
297 2017-01-06T16:47:07  *** abpa has joined #bitcoin-core-dev
298 2017-01-06T16:50:03  *** brg444 has quit IRC
299 2017-01-06T16:50:15  *** brg444 has joined #bitcoin-core-dev
300 2017-01-06T16:53:42  *** TomMc has quit IRC
301 2017-01-06T16:57:40  *** kadoban has joined #bitcoin-core-dev
302 2017-01-06T17:03:36  *** Chris_Stewart_5 has quit IRC
303 2017-01-06T17:08:47  <morcos> cfields: just finished reading through 9441, didn't understand your last comment on the PR, you are going to change it back to what?
304 2017-01-06T17:08:59  *** TomMc has joined #bitcoin-core-dev
305 2017-01-06T17:09:27  <sipa> morcos: the current PR makes ProcessMessages only process one message at a timre
306 2017-01-06T17:09:39  <morcos> i don't think you need to change it (now) i think its fairly clear any edge case change from current behavior is a net benefit
307 2017-01-06T17:09:44  <morcos> sipa: but thats what it did before
308 2017-01-06T17:10:01  <sipa> yes
309 2017-01-06T17:10:40  <morcos> so you think he should change it to process more than one?
310 2017-01-06T17:10:52  <sipa> i'd be more confortable with that
311 2017-01-06T17:11:11  <BlueMatt> you'd be more comfortable with a change in behavior?
312 2017-01-06T17:11:15  <morcos> that seems like the change to me, possibly a good one, but the PR seems more clearly correct without doing that b/c it doesn't require thinking about that
313 2017-01-06T17:11:20  <BlueMatt> I mean I agree we should probably do that in the furture, but why change it now?
314 2017-01-06T17:11:25  <morcos> BlueMatt: +!
315 2017-01-06T17:11:26  <morcos> 1
316 2017-01-06T17:11:34  <sipa> i'm confused
317 2017-01-06T17:11:41  <sipa> the current code processes multiple messages at once
318 2017-01-06T17:11:48  <BlueMatt> the pr does not change the behavior except for some stupid weird edge cases
319 2017-01-06T17:11:55  <sipa> his current PR changes that to only process one at a time
320 2017-01-06T17:11:59  <BlueMatt> specifically, currently, if you have a message with a bad hash, it will process more than once
321 2017-01-06T17:12:07  <morcos> morcos> sipa: but thats what it did before  (meaning master does not process more than one)
322 2017-01-06T17:12:09  <BlueMatt> but the current code does NOT process more than one message if it calls ProcessMessage
323 2017-01-06T17:12:22  <sipa> morcos: heh?
324 2017-01-06T17:12:26  <BlueMatt> (also the pr just disconnects on a bad hash, which I think is a change, but a good one imo)
325 2017-01-06T17:12:33  <sipa> master does process more than one, unless it's a block
326 2017-01-06T17:12:36  <BlueMatt> no
327 2017-01-06T17:12:36  <sipa> or the send buffer is full
328 2017-01-06T17:12:37  <BlueMatt> it does not
329 2017-01-06T17:13:28  <BlueMatt> I had the same misunderstanding initially
330 2017-01-06T17:14:10  <morcos> line 2566 in net_processing.cpp on master i think
331 2017-01-06T17:14:53  <sipa> ok, i was not aware of that
332 2017-01-06T17:15:00  <sipa> but that seems to be a bug
333 2017-01-06T17:15:11  <morcos> :) i think cfields tried to explain it multiple times
334 2017-01-06T17:15:36  <morcos> i think we all agree it may be better to process multiple messages, but it seems to me to make more sense to do that as a follow on PR
335 2017-01-06T17:16:08  <BlueMatt> (and the overhead of not doing so is (likely) not too terrible)
336 2017-01-06T17:16:30  <BlueMatt> (except for the bug fixed by #9315)
337 2017-01-06T17:16:32  <gribble> https://github.com/bitcoin/bitcoin/issues/9315 | Request announcement by cmpctblock AFTER requesting cmpctblock/blocktxn by rebroad · Pull Request #9315 · bitcoin/bitcoin · GitHub
338 2017-01-06T17:18:46  <morcos> we need to think carefully if there could be negative situations in the other direction..  you're about to announce blocks to all your peers or respond to their getblocktxns messages and some other peer manages to tie you up with a slew of expensive to process received msgs
339 2017-01-06T17:18:57  <BlueMatt> heh, fun github bug - if you "start a review" and then "add single comment", it will publish all pending comments
340 2017-01-06T17:19:12  *** Chris_Stewart_5 has joined #bitcoin-core-dev
341 2017-01-06T17:19:20  <sipa> on a different page?
342 2017-01-06T17:20:11  <sipa> ok, so it seems i had completely forgotten about #3180 (> 3 years old)
343 2017-01-06T17:20:13  <gribble> https://github.com/bitcoin/bitcoin/issues/3180 | Reduce latency in network processing by pstratem · Pull Request #3180 · bitcoin/bitcoin · GitHub
344 2017-01-06T17:20:36  <BlueMatt> you dont /usually/ forget prs from 3 years ago???!
345 2017-01-06T17:20:46  <BlueMatt> man, I cant remember prs from 6 months ago
346 2017-01-06T17:20:52  <cfields> sipa: heh, i commented on it in about ~5 places :)
347 2017-01-06T17:20:52  <morcos> i think clearly we should do SOMETHING smarter, i mean if a block has been announced to you and is sitting in yoru receive queue, seems silly to announce it back just b/c you haven't read it...
348 2017-01-06T17:21:01  <cfields> sipa: i thought you just wanted to minimize the diff here
349 2017-01-06T17:21:45  <sipa> cfields: you said "in nearly all cases, only one message is processed" - i thought that referred to cases where the buffer was full or we're processing blocks - the pre-3180 behaviour
350 2017-01-06T17:21:54  <sipa> and i didn't understand why you'd be changing it
351 2017-01-06T17:22:24  <morcos> so do we all agree that cfields should leave 9441 alone, and any further change should be in a separate PR?
352 2017-01-06T17:22:46  <sipa> yes.
353 2017-01-06T17:22:52  <cfields> sipa: ah, sorry. the only cases for processing multiple are for bad hash, or bad header
354 2017-01-06T17:22:58  *** brg444 has quit IRC
355 2017-01-06T17:23:16  <sipa> i was trying to ask "why are you changing behaviour" - it would have been clearer if you just had said "it doesn't"
356 2017-01-06T17:23:16  <sipa> :)
357 2017-01-06T17:23:31  <morcos> s/only cases/only preexisting cases were/
358 2017-01-06T17:23:34  <jonasschnelli> luke-jr: I first was using the term "non-validation mode". But than – after reading satoshis whitepaper again – considered to use the name "Simple Payment Verification".
359 2017-01-06T17:23:38  <BlueMatt> fucking engineers - always precise.....
360 2017-01-06T17:23:44  <sipa> sorry, i was probably misreading what you said
361 2017-01-06T17:24:01  <morcos> or something.. nm
362 2017-01-06T17:24:16  <cfields> sipa: it's mentioned in a bunch of places and at one point you said "I certainly noticed it only processed one message at a time", so i thought we were on the same page
363 2017-01-06T17:24:26  <cfields> no worries though, sounds like we're all good now
364 2017-01-06T17:24:44  <morcos> cfields: i'll review again after you fix outstanding comments
365 2017-01-06T17:24:53  <sipa> cfields: i noticed that your PR changed it to only processing one message at a time
366 2017-01-06T17:25:06  <sipa> i didn't realize that that was not a change
367 2017-01-06T17:25:17  <cfields> sipa: ah, heh. i misread you too then :)
368 2017-01-06T17:25:45  <morcos> i'm not sure i 100% understand the wait_until condition,  is the idea that you don't want spurious wakeups to cause another loop?
369 2017-01-06T17:25:56  <cfields> ok. I rebased this morning to address all nits and keep the loop in. Will back that out and push.
370 2017-01-06T17:26:01  <sipa> anyway - misunderstandings in both directions. i should have read the code, instead of making (apparently 3-year old) assumptions about the code
371 2017-01-06T17:26:31  <cfields> sipa: sure, no worries. It's not obvious behavior _at all_.
372 2017-01-06T17:27:03  <cfields> morcos: the condition lets us wake the processor from the message handler thread when a new message comes in
373 2017-01-06T17:27:11  <cfields> and yea, avoids spurious wakes too
374 2017-01-06T17:31:35  *** brg444 has joined #bitcoin-core-dev
375 2017-01-06T17:38:07  <bitcoin-git> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/a55716abe566...46b249e578e8
376 2017-01-06T17:38:08  <bitcoin-git> bitcoin/master 9479f8d Jonas Schnelli: Allow shutdown during LoadMempool, dump only when necessary
377 2017-01-06T17:38:09  <bitcoin-git> bitcoin/master 325e400 Jonas Schnelli: [Qt] Do proper shutdown
378 2017-01-06T17:38:09  <bitcoin-git> bitcoin/master 46b249e Pieter Wuille: Merge #9408: Allow shutdown during LoadMempool, dump only when necessary...
379 2017-01-06T17:38:18  <bitcoin-git> [bitcoin] sipa closed pull request #9408: Allow shutdown during LoadMempool, dump only when necessary (master...2016/12/memp_dump) https://github.com/bitcoin/bitcoin/pull/9408
380 2017-01-06T17:38:57  *** wrkrcoop has joined #bitcoin-core-dev
381 2017-01-06T17:45:15  *** wrkrcoop has quit IRC
382 2017-01-06T17:45:37  *** wrkrcoop has joined #bitcoin-core-dev
383 2017-01-06T17:47:42  <morcos> cfields: ah yes, ok good..  cool.  i like the new design...
384 2017-01-06T17:48:59  <cfields> morcos: great, thanks.
385 2017-01-06T17:50:55  *** brg444 has quit IRC
386 2017-01-06T17:51:28  *** brg444 has joined #bitcoin-core-dev
387 2017-01-06T17:53:38  <luke-jr> BlueMatt: how's this look now?
388 2017-01-06T17:56:20  *** paveljanik has joined #bitcoin-core-dev
389 2017-01-06T17:56:20  *** paveljanik has joined #bitcoin-core-dev
390 2017-01-06T17:57:24  <cfields> morcos: updated. Very little changed from before, mostly just fixed some things in the interim commits to be more correct for easier review
391 2017-01-06T18:00:55  *** wasi has quit IRC
392 2017-01-06T18:05:14  *** jannes has quit IRC
393 2017-01-06T18:25:46  *** sipa has quit IRC
394 2017-01-06T18:25:46  *** sipa has joined #bitcoin-core-dev
395 2017-01-06T18:37:38  *** laurentmt has joined #bitcoin-core-dev
396 2017-01-06T18:38:12  *** laurentmt has quit IRC
397 2017-01-06T18:40:28  <brg444> can someone confirm how many iterations of segwit testnet there were?
398 2017-01-06T18:41:21  <sipa> 4, i believe
399 2017-01-06T18:42:54  <brg444> thanks
400 2017-01-06T19:18:58  <morcos> cfields: one more question on that wait_until..  lets say a block message comes in, takes you a while to process..  if any peers sent you a new message in the interim, you won't wait b/c of fMsgProcWake correct?
401 2017-01-06T19:19:56  <morcos> But if no peers sent you a message, you will announce quickly to peers N+1 -> MAX_CONNECTIONS, but then sleep up to 100ms before announcing to peers 1 -> N-1 ?
402 2017-01-06T19:20:51  <gmaxwell> sipa: Processmessage _currently_ processes one at a time, there is a break stuck in the bottom of the loop.
403 2017-01-06T19:21:38  *** Guest98817 has quit IRC
404 2017-01-06T19:21:50  <morcos> I thought I had seen somewhere talk about making the wait_until time be 100ms from start of loop and not end, or perhaps we should add a WakeMessageHandler for new tips in particular?
405 2017-01-06T19:22:08  *** cjamthagen_ has joined #bitcoin-core-dev
406 2017-01-06T19:22:12  *** wump has joined #bitcoin-core-dev
407 2017-01-06T19:22:27  *** so has quit IRC
408 2017-01-06T19:22:27  *** AaronvanW has quit IRC
409 2017-01-06T19:22:27  *** wumpus has quit IRC
410 2017-01-06T19:22:28  *** cjamthagen has quit IRC
411 2017-01-06T19:22:28  *** afk11 has quit IRC
412 2017-01-06T19:22:44  *** afk11 has joined #bitcoin-core-dev
413 2017-01-06T19:22:44  *** afk11 has quit IRC
414 2017-01-06T19:22:44  *** afk11 has joined #bitcoin-core-dev
415 2017-01-06T19:23:03  <gmaxwell> morcos: I opened a PR that did those things, and also explicitly asked about the fact that it changed the message handling back to process multiple messages. After no one replied for a bit I just changed it back to one message at a time.
416 2017-01-06T19:23:13  <gmaxwell> Then after cfields said he preferred his net refactors I closed it.
417 2017-01-06T19:23:13  <cfields> morcos: yes, that would probably make sense. I think gmaxwell's change included that
418 2017-01-06T19:23:46  <gmaxwell> it didn't really make that much of a difference when the other problems were fixed.
419 2017-01-06T19:24:32  <morcos> gmaxwell: I like the changes in 9441 and i think its good to be making progress as part of a larger roadmap..  i think it captures most of the improtant improvements..
420 2017-01-06T19:25:18  <morcos> perhaps we can add quick relay of new tips,  and processing multiple messages requires a bit more thought in my view..  as we can see by the fact that it was ever taken out in the first place
421 2017-01-06T19:25:38  <morcos> that said, i admit i did not look at your PRs
422 2017-01-06T19:25:53  <morcos> hard to keep up!
423 2017-01-06T19:26:18  <cfields> It's certainly reasonable to tweak it now that the dependencies are untangled, I just tried to keep the scope narrow at first
424 2017-01-06T19:26:29  <gmaxwell> I know, that why I closed them rather than have more things to look at!
425 2017-01-06T19:26:57  <gmaxwell> not gonna stop me from going 'I already pointed this out, if you only listened!' :P
426 2017-01-06T19:27:22  <morcos> insufficient emoticons
427 2017-01-06T19:27:35  <sipa> gmaxwell: i finally understand your comment on the PR
428 2017-01-06T19:27:53  <sipa> gmaxwell: i thought you were trying to say that that PR changed it to only process one at a time (which i noticed)... and i was very confused by what you said afterwards about fixing it
429 2017-01-06T19:30:02  <gmaxwell> sipa: it changed it to process multiple at a time initially, and I immediately added a line comment on that change asking for review of that (which github seems to have lost when I force pushed a change that reverted back to the old behavior)
430 2017-01-06T19:30:03  <cfields> morcos: hmm, wait. Are you talking about the new quick-relay from 9375 in particular?
431 2017-01-06T19:30:15  <morcos> cfields: no i'm talking about exactly not that
432 2017-01-06T19:30:20  <sipa> seems i was just assuming i knew what master did, and i misinterpreted everything that people tried to explain it to me
433 2017-01-06T19:30:39  <cfields> morcos: ok, good
434 2017-01-06T19:31:18  *** AaronvanW has joined #bitcoin-core-dev
435 2017-01-06T19:31:19  *** AaronvanW has quit IRC
436 2017-01-06T19:31:19  *** AaronvanW has joined #bitcoin-core-dev
437 2017-01-06T19:31:36  <gmaxwell> sipa: I think it should probably handle multiple at a time subject to some time limit. ::shrugs::
438 2017-01-06T19:31:43  <morcos> cfields: its very easy to see the behavior with 9375 now though b/c of the cached blocks making the annoucements so fast.  you watch annoucements in quick succession up to some high numbered peer and then a pause before announcements start to low numbered peers
439 2017-01-06T19:32:40  <sipa> gmaxwell: absolutely agree
440 2017-01-06T19:33:06  <sipa> but if we've done it this way since 0.10, i really don't care whether that happens in 0.14 or not
441 2017-01-06T19:33:42  <morcos> sipa: gmaxwell: i think ideally we might do something even smarter, such as queue received transactions to be ATMP'ed after we'd gotten through block relay..  however its a bit tricky in that you dont' want to reorder those after any potential other cmpctblock messages for reconstruction purposes
442 2017-01-06T19:33:51  <cfields> morcos: ah, i think that'd be a different culprit then
443 2017-01-06T19:34:08  <gmaxwell> sipa:  in other things people probably didn't notice,  I've been complaining that our socket recieve buffer (5 MB) is _way_ too small given how long executions of the message handler take; and it is adversely impacting performance; even with cfields' PR.
444 2017-01-06T19:34:25  <morcos> cfields: wait, why a different culprit?  didn't the old code have the same problem in a different way?
445 2017-01-06T19:35:25  <cfields> morcos: to be clear, you're saying that you observe that behavior with the cached blocks?
446 2017-01-06T19:36:04  <morcos> cfields: :) yes, but not the pre-announced cached blocks.  we use the cached blocks for regular announcment too.
447 2017-01-06T19:36:10  <gmaxwell> sipa: e.g. right now we can, during a single handler run, connect 999 blocks which will take 2000 seconds even on a moderately fast computer... all the rx buffers just fill. (and on a really slow computer, we'll ping timeout our peers while connecting a wad of blocks)
448 2017-01-06T19:36:53  <cfields> gmaxwell: https://github.com/bitcoin/bitcoin/pull/9441#issuecomment-270397280 . I think we should consider changing this for 0.14 as well.
449 2017-01-06T19:39:21  <cfields> morcos: aha, i see. I'm with you now.
450 2017-01-06T19:39:47  <morcos> they just make the rest of the loop so fast that the pause is more visible
451 2017-01-06T19:43:53  <gmaxwell> morcos: my strategy was basically to make the loop run immediately again after anything interestin happened.  I think it's harmless to always execute the loop an extra time.
452 2017-01-06T19:47:06  <morcos> gmaxwell: how would you define interesting?  any message processed?
453 2017-01-06T19:48:28  <gmaxwell> morcos: yes, though my PR didn't bother catching any message processed, it did catch any message sent or any block recieved, I believe.
454 2017-01-06T19:49:27  <gmaxwell> I think it would be fine to make it do any message sent or recieved.
455 2017-01-06T19:51:25  <gmaxwell> I also made it run through the loop an extra time in any case it skipped something due to lock contention.
456 2017-01-06T19:51:36  <sipa> gmaxwell: i'm aware... but i think it's just fundamentally broken that we're pegging the message handler thread for 2000s
457 2017-01-06T19:51:56  <sipa> gmaxwell: it's not too hard to not always connect everything we have
458 2017-01-06T19:52:27  <gmaxwell> sipa: That would be good, the change to accomplish that wasn't obvious to me or I would have PRed it already; though that is necessary it's not sufficient.
459 2017-01-06T19:53:19  <gmaxwell> sipa: since even a _1_ second delay coupled with a 5MB buffer is enough to limit our IBD sync speed to far below what we can reindex-chainstate at on reasonable hardware.
460 2017-01-06T19:54:02  *** wrkrcoop has quit IRC
461 2017-01-06T19:56:19  <gmaxwell> morcos: the wake on lock contention seemed important to me, otherwise we could get a message from a peer, bounce off cs_main before getting to handle it, then sleep for 100ms before trying again.
462 2017-01-06T19:57:40  <gmaxwell> (e.g. if we're competing with rpc for cs_main)
463 2017-01-06T19:59:12  *** wrkrcoop has joined #bitcoin-core-dev
464 2017-01-06T19:59:27  <morcos> gmaxwell: hmm.. that makes sense.  where are you referring to where we skip handling the message if we can't get cs_main?
465 2017-01-06T20:00:38  *** wrkrcoop has quit IRC
466 2017-01-06T20:02:06  <gmaxwell> morcos: ah, I think one of the just merged networking changes just removed where we did that.
467 2017-01-06T20:02:07  <morcos> oh in SendMessages
468 2017-01-06T20:02:20  <gmaxwell> oh no, there it is.
469 2017-01-06T20:05:03  <morcos> gmaxwell: on another note, i guess our ability to make use of >4 cores isn't as good as I thought...  I had a whole series of PR's that removed successive bottlenecks, but i'd misremembered how much progress we could make wiht only the cuckoocache
470 2017-01-06T20:05:43  <morcos> And then I got sidetracked by the near conesnsus bug with CCoinsViewCache..  but when I get a chance I'll go back and see if there are other parts of that that are still worth doing now
471 2017-01-06T20:05:47  <gmaxwell> yea...
472 2017-01-06T20:07:25  <BlueMatt> ugh, ffs, fibre cuts in india means fibre rtt between eu and asia is up 90ms on one path :(
473 2017-01-06T20:07:58  <BlueMatt> luke-jr: did you fix https://github.com/bitcoin/bitcoin/pull/8775#discussion_r94985339 ?
474 2017-01-06T20:07:59  <sipa> that try_lock cs_main can go away after #9419 (+ follow ups), i think, as it will be replaced by the nodestate locks
475 2017-01-06T20:08:03  <gribble> https://github.com/bitcoin/bitcoin/issues/9419 | Stop Using cs_main for CNodeState/State() by TheBlueMatt · Pull Request #9419 · bitcoin/bitcoin · GitHub
476 2017-01-06T20:10:08  <luke-jr> BlueMatt: no, where is it assumed to return non-NULL?
477 2017-01-06T20:10:27  <gmaxwell> there is some advantage in skipping processing peers that need a lock, when other peers can be processed without it.
478 2017-01-06T20:10:48  <BlueMatt> luke-jr: ok, please add documentation to note that it is assumed it can return null
479 2017-01-06T20:12:17  <gmaxwell> though on the other hand, I think that that construction could leave us sending pings even if cs_main is deadlocked which would be undesirable. (not an actual issue because our message handler will get stuck elsewhere in the case, but still)
480 2017-01-06T20:12:30  <luke-jr> I would think that's implied in returning a pointer type, but ok
481 2017-01-06T20:15:22  <BlueMatt> luke-jr: could you not rebase when people are in the middle of review?
482 2017-01-06T20:18:21  <luke-jr> haven't rebased that PR in a week, but ok
483 2017-01-06T20:18:48  <BlueMatt> did you just rebase again?
484 2017-01-06T20:18:55  <luke-jr> no, just added the comment
485 2017-01-06T20:19:05  <BlueMatt> no? the previous head is now gone?
486 2017-01-06T20:19:35  <luke-jr> indeed, I amended it
487 2017-01-06T20:19:46  <BlueMatt> please do not do that
488 2017-01-06T20:19:56  *** wrkrcoop has joined #bitcoin-core-dev
489 2017-01-06T20:21:36  * luke-jr starts a list of the contradicting development processes preferred by various people.
490 2017-01-06T20:25:37  * BlueMatt restarts review from the start :(
491 2017-01-06T20:25:40  <BlueMatt> does anyone ask for regular squash/rebase mid-review?
492 2017-01-06T20:28:36  <luke-jr> I don't usually distinguish (or have a way to) when others are actively reviewing. (note there was already amended commits before I became aware you were)
493 2017-01-06T20:29:10  <gmaxwell> at what point is someone not reviewing?
494 2017-01-06T20:30:18  <luke-jr> gmaxwell: exactly, hence why some desiring squashing vs others not liking squashing [at particular times] is confusing to resolve
495 2017-01-06T20:30:22  <BlueMatt> when it is time to merge and/or there are limited comments showing up?
496 2017-01-06T20:30:50  <BlueMatt> no one desires squashing unless its been a while since things have been commented on, though to be fair, you should, at a minimum, comment when you squash and note changes
497 2017-01-06T20:31:07  <BlueMatt> eg respond to the previous comments and note where you did/didnt make changes, instead of letting them sit
498 2017-01-06T20:32:02  <sipa> i usually prefer squashing trivial fixes immediately, unless it's a very complicated PR
499 2017-01-06T20:32:22  <sipa> most of the time is understanding what the PR is trying to achieve and how... reading the code is easy
500 2017-01-06T20:32:48  *** wrkrcoop has quit IRC
501 2017-01-06T20:33:06  <gmaxwell> matt's style can be helpful on more complicated ones, but as someone who has often come to a PR to review later, I've found the style to really suck in that case.  I waste my time finding bugs that are already fixed in later updates.
502 2017-01-06T20:33:08  <BlueMatt> not for a major refactor pr where most of the pr is just code movement
503 2017-01-06T20:33:12  *** wrkrcoop has joined #bitcoin-core-dev
504 2017-01-06T20:33:18  <sipa> gmaxwell: likewise
505 2017-01-06T20:33:20  *** wrkrcoop has quit IRC
506 2017-01-06T20:33:40  <sipa> (but i don't mind following either style... just my personal preference is usually fixing things immediately)
507 2017-01-06T20:33:42  <BlueMatt> gmaxwell: I try to title such commits f "Commit title this should be squashed into" fix XYZ
508 2017-01-06T20:33:48  <BlueMatt> which should at least make it easy to glance at such changes
509 2017-01-06T20:34:06  <sipa> i guess things have improved with the "review" thing
510 2017-01-06T20:34:19  <gmaxwell> also it leaves me having to re-review the squash since sometimes a pair of reasonable looking changes my reveal their brokenness once merged. (also we have no tools to tell if a squash was faithful in any case, so someone malicious could slip something in if people didn't review the squash just as carefully)
511 2017-01-06T20:34:38  <sipa> so you can comment on an issue, and then later delete if you see it's already fixed ahead of time
512 2017-01-06T20:35:13  <BlueMatt> yes, my bigger annoyance is having to re-review after squash was shit
513 2017-01-06T20:35:30  <BlueMatt> its easy if its clear and the commits are just being cleanly squashed (can compare treeish)
514 2017-01-06T20:35:40  <luke-jr> I have an alias that compares diffs that I've gotten used to using to see what changed in an amend
515 2017-01-06T20:41:10  *** wrkrcoop has joined #bitcoin-core-dev
516 2017-01-06T20:50:10  *** Giszmo has quit IRC
517 2017-01-06T21:04:12  *** wrkrcoop has quit IRC
518 2017-01-06T21:10:46  <owowo> is there a time when core drops a tx if unconfirmed for a long time? Or will it just keep on rebroadcasting it until the return of the Messiah?
519 2017-01-06T21:11:11  <BlueMatt> the wallet will keep rebroadcasting, but you can "abandon" a transaction both in the gui and the rpc
520 2017-01-06T21:11:32  <BlueMatt> the mempool will eventually drop them, but there are "helpful" nodes which like to rebroadcast lots of shit to their peers all the time
521 2017-01-06T21:12:18  <owowo> ok, thx
522 2017-01-06T21:23:06  *** wrkrcoop has joined #bitcoin-core-dev
523 2017-01-06T21:35:40  *** brg444 has quit IRC
524 2017-01-06T21:39:34  *** brg444 has joined #bitcoin-core-dev
525 2017-01-06T21:43:48  *** Chris_Stewart_5 has quit IRC
526 2017-01-06T21:45:50  *** Guyver2 has quit IRC
527 2017-01-06T21:49:04  *** btcdrak has quit IRC
528 2017-01-06T21:49:17  *** Chris_Stewart_5 has joined #bitcoin-core-dev
529 2017-01-06T22:30:45  *** juscamarena_ has quit IRC
530 2017-01-06T22:38:04  *** fengling has quit IRC
531 2017-01-06T22:46:56  *** Chris_Stewart_5 has quit IRC
532 2017-01-06T23:00:10  *** Chris_Stewart_5 has joined #bitcoin-core-dev
533 2017-01-06T23:06:44  *** fengling has joined #bitcoin-core-dev
534 2017-01-06T23:14:28  *** afk11 has quit IRC
535 2017-01-06T23:16:55  *** fengling has quit IRC
536 2017-01-06T23:18:48  *** afk11 has joined #bitcoin-core-dev
537 2017-01-06T23:18:48  *** afk11 has quit IRC
538 2017-01-06T23:18:48  *** afk11 has joined #bitcoin-core-dev
539 2017-01-06T23:18:55  <bitcoin-git> [bitcoin] gmaxwell opened pull request #9484: Introduce assumevalid setting to skip validation presumed valid scripts. (master...script_elide_verified) https://github.com/bitcoin/bitcoin/pull/9484
540 2017-01-06T23:29:08  <bitcoin-git> [bitcoin] mcelrath opened pull request #9485: ZMQ example using python3 and asyncio (master...python3zmq) https://github.com/bitcoin/bitcoin/pull/9485
541 2017-01-06T23:43:45  *** MarcoFalke has quit IRC
542 2017-01-06T23:44:13  *** fengling has joined #bitcoin-core-dev
543 2017-01-06T23:44:54  *** laurentmt has joined #bitcoin-core-dev
544 2017-01-06T23:54:04  *** wrkrcoop has quit IRC
545 2017-01-06T23:58:40  *** TomMc has quit IRC
546 2017-01-06T23:59:48  *** wrkrcoop has joined #bitcoin-core-dev