1 2017-05-25T00:10:02  *** justan0theruser has joined #bitcoin-core-dev
  2 2017-05-25T00:14:17  *** kadoban has quit IRC
  3 2017-05-25T00:14:21  *** kadoban_ has joined #bitcoin-core-dev
  4 2017-05-25T00:41:02  *** Apocalyptic has joined #bitcoin-core-dev
  5 2017-05-25T00:57:05  *** jtimon has quit IRC
  6 2017-05-25T01:00:05  *** dermoth has quit IRC
  7 2017-05-25T01:00:59  *** dermoth has joined #bitcoin-core-dev
  8 2017-05-25T01:07:36  <phantomcircuit> gmaxwell, no issue for me here
  9 2017-05-25T01:07:44  <phantomcircuit> 96c850c20913b191cff9f66fedbb68812b1a41ea
 10 2017-05-25T01:07:59  <sipa> works fine here as well
 11 2017-05-25T01:08:00  <phantomcircuit> wait this is probably not actual master
 12 2017-05-25T01:08:01  <phantomcircuit> hmm
 13 2017-05-25T01:08:05  <sipa> but i think gmaxwell's using qt4
 14 2017-05-25T01:08:36  *** dstadulis has joined #bitcoin-core-dev
 15 2017-05-25T01:35:36  <phantomcircuit> gmaxwell, yeah it's broken
 16 2017-05-25T01:35:41  <phantomcircuit> sipa, yeah i have qt4 also
 17 2017-05-25T01:36:24  *** Ylbam has quit IRC
 18 2017-05-25T01:39:21  <luke-jr> gmaxwell: Gentoo's 0.14.1-r1 seems to work with any configuration I try; can you be more specific on how to get a failure? Do you have the overlay?
 19 2017-05-25T01:44:14  <gmaxwell> luke-jr: the issue is that it puts  BITCOIND_OPTS="-disablewallet"  in /etc/conf.d even when the wallet useflag is set.
 20 2017-05-25T01:44:25  <gmaxwell> both the overlay and not.
 21 2017-05-25T01:47:20  <luke-jr> gmaxwell: aha, interesting. I wonder if we should tolerate/ignore that in such cases
 22 2017-05-25T01:47:27  <luke-jr> I'll hack the ebuild to get rid of it for now
 23 2017-05-25T01:47:45  <luke-jr> wait, "even when the wallet useflag is set"? that's to be expected?
 24 2017-05-25T01:48:21  <gmaxwell> You are saying that when the wallet useflag is set, it should disable the wallet?
 25 2017-05-25T01:48:22  <luke-jr> (okay, looks like -disablewallet should safely be ignored already too)
 26 2017-05-25T01:48:43  <luke-jr> gmaxwell: it builds with wallet support, but the init script in typical usage wouldn't enable the wallet because it's a system bitcoind
 27 2017-05-25T01:49:18  <luke-jr> at least, that seems to be the typical assumption users have had before; and it can be changed where people want something else
 28 2017-05-25T01:49:34  <gmaxwell> This is insanely confusing and imposible to support, I wasted about a half an hour trying to help someone today with this.
 29 2017-05-25T01:49:34  <luke-jr> ie, when people want bitcoind-with-wallet, they usually run that as a normal user
 30 2017-05-25T01:49:39  <luke-jr> hmm
 31 2017-05-25T01:49:54  <luke-jr> I suppose an unused wallet is harmless
 32 2017-05-25T01:50:00  <gmaxwell> if you don't want to use a wallet you.. exactly!
 33 2017-05-25T01:51:23  <luke-jr> gmaxwell: it's contrib/init/bitcoind.openrcconf in Core itself; do you want to open the PR, or should I?
 34 2017-05-25T01:52:20  <gmaxwell> I'd rather you do so since I'm not in a position to test it myself.
 35 2017-05-25T01:54:33  <luke-jr> k
 36 2017-05-25T01:57:39  <bitcoin-git> [bitcoin] luke-jr opened pull request #10451: contrib/init/bitcoind.openrcconf: Don't disable wallet by default (master...openrc_wallet) https://github.com/bitcoin/bitcoin/pull/10451
 37 2017-05-25T01:59:19  <luke-jr> gmaxwell: ^
 38 2017-05-25T02:04:01  *** justan0theruser has quit IRC
 39 2017-05-25T02:08:47  *** PRab has quit IRC
 40 2017-05-25T02:33:34  *** kadoban_ is now known as kadoban
 41 2017-05-25T02:41:08  *** marcoagner has joined #bitcoin-core-dev
 42 2017-05-25T02:43:51  *** talmai has joined #bitcoin-core-dev
 43 2017-05-25T02:53:54  *** justanotheruser has joined #bitcoin-core-dev
 44 2017-05-25T02:56:12  <phantomcircuit> #10420 breaks qt4
 45 2017-05-25T02:56:14  <gribble> https://github.com/bitcoin/bitcoin/issues/10420 | Add Qt tests for wallet spends & bumpfee by ryanofsky · Pull Request #10420 · bitcoin/bitcoin · GitHub
 46 2017-05-25T03:01:30  <phantomcircuit> actually maybe not?
 47 2017-05-25T03:02:36  *** tunafizz has quit IRC
 48 2017-05-25T03:03:09  *** tunafizz has joined #bitcoin-core-dev
 49 2017-05-25T03:11:58  *** marcoagner has quit IRC
 50 2017-05-25T03:12:21  *** marcoagner has joined #bitcoin-core-dev
 51 2017-05-25T03:19:14  *** goatturneer has quit IRC
 52 2017-05-25T03:24:27  *** marcoagner has quit IRC
 53 2017-05-25T03:26:09  *** talmai has quit IRC
 54 2017-05-25T03:28:45  *** hourandahalf has joined #bitcoin-core-dev
 55 2017-05-25T03:29:10  *** hourandahalf has joined #bitcoin-core-dev
 56 2017-05-25T03:30:33  *** hourandahalf has quit IRC
 57 2017-05-25T03:31:55  *** chikensore has joined #bitcoin-core-dev
 58 2017-05-25T03:34:06  *** RubenSomsen has joined #bitcoin-core-dev
 59 2017-05-25T03:36:43  *** chikensore has quit IRC
 60 2017-05-25T03:37:35  *** chikensore has joined #bitcoin-core-dev
 61 2017-05-25T03:40:27  *** tunafizz has quit IRC
 62 2017-05-25T03:40:54  *** tunafizz has joined #bitcoin-core-dev
 63 2017-05-25T03:42:01  *** goatturneer has joined #bitcoin-core-dev
 64 2017-05-25T03:47:00  *** JackH has quit IRC
 65 2017-05-25T03:49:32  *** tunafizz has quit IRC
 66 2017-05-25T03:49:39  *** tunafizz has joined #bitcoin-core-dev
 67 2017-05-25T03:59:49  *** QBcrusher_ has joined #bitcoin-core-dev
 68 2017-05-25T04:00:17  *** chikensore has quit IRC
 69 2017-05-25T04:02:29  *** QBcrusher has quit IRC
 70 2017-05-25T04:07:48  *** tunafizz has quit IRC
 71 2017-05-25T04:08:20  *** tunafizz has joined #bitcoin-core-dev
 72 2017-05-25T04:14:51  *** SopaXorzTaker has joined #bitcoin-core-dev
 73 2017-05-25T04:24:37  *** Dyaheon has quit IRC
 74 2017-05-25T04:26:04  *** Dyaheon has joined #bitcoin-core-dev
 75 2017-05-25T04:29:33  *** str4d has joined #bitcoin-core-dev
 76 2017-05-25T04:37:25  *** song_ has joined #bitcoin-core-dev
 77 2017-05-25T04:51:12  *** song_ has quit IRC
 78 2017-05-25T05:39:23  *** marcoagner has joined #bitcoin-core-dev
 79 2017-05-25T05:45:45  *** marcoagner has joined #bitcoin-core-dev
 80 2017-05-25T05:48:35  *** paveljanik has quit IRC
 81 2017-05-25T05:50:12  *** Alina-malina has quit IRC
 82 2017-05-25T05:54:53  *** RubenSomsen has quit IRC
 83 2017-05-25T05:59:47  *** arowser has joined #bitcoin-core-dev
 84 2017-05-25T06:00:39  *** RubenSomsen has joined #bitcoin-core-dev
 85 2017-05-25T06:01:47  *** Alina-malina has joined #bitcoin-core-dev
 86 2017-05-25T06:03:42  *** Alina-malina has quit IRC
 87 2017-05-25T06:03:42  *** Alina-malina has joined #bitcoin-core-dev
 88 2017-05-25T06:21:42  *** d_t has quit IRC
 89 2017-05-25T06:30:11  *** Dyaheon has quit IRC
 90 2017-05-25T06:32:43  *** Dyaheon has joined #bitcoin-core-dev
 91 2017-05-25T06:34:44  *** str4d has quit IRC
 92 2017-05-25T06:45:15  *** arowser has quit IRC
 93 2017-05-25T06:47:29  *** arowser has joined #bitcoin-core-dev
 94 2017-05-25T06:56:22  *** jtimon has joined #bitcoin-core-dev
 95 2017-05-25T07:19:19  *** jtimon has quit IRC
 96 2017-05-25T07:27:48  *** SopaXorzTaker has quit IRC
 97 2017-05-25T07:28:05  *** justan0theruser has joined #bitcoin-core-dev
 98 2017-05-25T07:31:08  *** justanotheruser has quit IRC
 99 2017-05-25T07:50:37  *** Ylbam has joined #bitcoin-core-dev
100 2017-05-25T07:55:41  *** Guyver2 has joined #bitcoin-core-dev
101 2017-05-25T08:21:22  *** timothy has joined #bitcoin-core-dev
102 2017-05-25T08:28:20  *** riemann has joined #bitcoin-core-dev
103 2017-05-25T08:44:50  *** RubenSomsen has quit IRC
104 2017-05-25T08:51:45  <phantomcircuit> btw
105 2017-05-25T08:51:52  <phantomcircuit> git bisect run is pretty neat
106 2017-05-25T08:51:58  <phantomcircuit> (it was 10420)
107 2017-05-25T08:55:41  <gmaxwell> phantomcircuit: thanks for bisecting.
108 2017-05-25T08:56:07  <gmaxwell> ryanofsky: 10420 appears to have broken the build for QT4. See above.
109 2017-05-25T08:57:18  <phantomcircuit> gmaxwell, tbh i really just wanted to try git bisect run
110 2017-05-25T08:57:31  <phantomcircuit> it's neat
111 2017-05-25T09:06:04  *** RubenSomsen has joined #bitcoin-core-dev
112 2017-05-25T09:54:33  *** tunafizz has quit IRC
113 2017-05-25T09:54:53  *** tunafizz has joined #bitcoin-core-dev
114 2017-05-25T10:07:16  *** jtimon has joined #bitcoin-core-dev
115 2017-05-25T10:08:56  *** beatrootfarmer has joined #bitcoin-core-dev
116 2017-05-25T10:12:28  *** goatturneer has quit IRC
117 2017-05-25T10:22:56  *** RubenSomsen has quit IRC
118 2017-05-25T10:27:58  *** Dyaheon has quit IRC
119 2017-05-25T10:29:29  *** Dyaheon has joined #bitcoin-core-dev
120 2017-05-25T11:00:43  *** paveljanik has joined #bitcoin-core-dev
121 2017-05-25T11:12:35  *** cryptapus_afk has quit IRC
122 2017-05-25T11:25:06  *** snortblort has joined #bitcoin-core-dev
123 2017-05-25T11:43:15  *** snortblort has quit IRC
124 2017-05-25T11:56:25  *** NewLiberty has joined #bitcoin-core-dev
125 2017-05-25T11:56:26  *** NewLiberty_ has joined #bitcoin-core-dev
126 2017-05-25T12:01:21  <bitcoin-git> [bitcoin] ryanofsky opened pull request #10454: Fix broken q4 test build (master...pr/qt4ctx) https://github.com/bitcoin/bitcoin/pull/10454
127 2017-05-25T12:07:21  *** NewLiberty_ has quit IRC
128 2017-05-25T12:33:53  *** chjj has quit IRC
129 2017-05-25T12:35:31  *** Alina-malina has quit IRC
130 2017-05-25T12:41:50  *** cryptapus_afk has joined #bitcoin-core-dev
131 2017-05-25T12:45:03  *** marcoagner has quit IRC
132 2017-05-25T13:00:57  *** chjj has joined #bitcoin-core-dev
133 2017-05-25T13:09:31  *** Alina-malina has joined #bitcoin-core-dev
134 2017-05-25T13:14:26  *** Alina-malina has quit IRC
135 2017-05-25T13:23:24  *** NewLiberty_ has joined #bitcoin-core-dev
136 2017-05-25T13:24:28  *** NewLiberty has quit IRC
137 2017-05-25T13:37:29  *** jannes has quit IRC
138 2017-05-25T13:43:15  *** jannes has joined #bitcoin-core-dev
139 2017-05-25T13:50:32  *** d_t has joined #bitcoin-core-dev
140 2017-05-25T13:55:31  *** d_t has quit IRC
141 2017-05-25T14:20:16  <bitcoin-git> [bitcoin] ryanofsky opened pull request #10455: Simplify feebumper minimum fee code slightly (master...pr/bumpmin) https://github.com/bitcoin/bitcoin/pull/10455
142 2017-05-25T14:23:47  *** laurentmt has joined #bitcoin-core-dev
143 2017-05-25T14:30:37  *** Joseph__ has joined #bitcoin-core-dev
144 2017-05-25T14:30:54  *** laurentmt has quit IRC
145 2017-05-25T14:33:27  *** NewLiberty_ has quit IRC
146 2017-05-25T14:36:17  *** justan0theruser has quit IRC
147 2017-05-25T14:38:57  *** Alina-malina has joined #bitcoin-core-dev
148 2017-05-25T14:41:00  *** justan0theruser has joined #bitcoin-core-dev
149 2017-05-25T14:43:45  *** Alina-malina has quit IRC
150 2017-05-25T14:56:55  *** goatturneer has joined #bitcoin-core-dev
151 2017-05-25T14:59:42  *** riemann has quit IRC
152 2017-05-25T15:00:13  <bitcoin-git> [bitcoin] earonesty closed pull request #10442: add a -bip148 option (master...master) https://github.com/bitcoin/bitcoin/pull/10442
153 2017-05-25T15:00:29  *** beatrootfarmer has quit IRC
154 2017-05-25T15:27:23  *** beatrootfarmer has joined #bitcoin-core-dev
155 2017-05-25T15:30:48  *** goatturneer has quit IRC
156 2017-05-25T15:31:43  *** beatrootfarmer has quit IRC
157 2017-05-25T15:43:25  *** elkalamar_ has joined #bitcoin-core-dev
158 2017-05-25T15:45:31  *** elkalamar has quit IRC
159 2017-05-25T15:45:48  *** abpa has joined #bitcoin-core-dev
160 2017-05-25T15:45:55  *** RubenSomsen has joined #bitcoin-core-dev
161 2017-05-25T15:58:00  *** dgenr8 has joined #bitcoin-core-dev
162 2017-05-25T15:59:42  *** timothy has quit IRC
163 2017-05-25T16:15:56  *** SopaXorzTaker has joined #bitcoin-core-dev
164 2017-05-25T16:46:00  *** arowser has quit IRC
165 2017-05-25T16:46:16  *** arowser has joined #bitcoin-core-dev
166 2017-05-25T16:48:59  *** dstadulis has quit IRC
167 2017-05-25T16:51:29  *** laurentmt has joined #bitcoin-core-dev
168 2017-05-25T16:51:35  *** beatrootfarmer has joined #bitcoin-core-dev
169 2017-05-25T16:51:36  *** laurentmt has quit IRC
170 2017-05-25T16:58:29  *** bsm1175321 has quit IRC
171 2017-05-25T17:01:44  *** juscamarena has joined #bitcoin-core-dev
172 2017-05-25T17:02:08  *** juscamarena is now known as Guest72157
173 2017-05-25T17:02:48  *** juscamarena_ has quit IRC
174 2017-05-25T17:05:21  *** belcher has joined #bitcoin-core-dev
175 2017-05-25T17:05:30  *** belcher has quit IRC
176 2017-05-25T17:15:13  *** Joseph__ has quit IRC
177 2017-05-25T17:46:28  *** Guyver2 has quit IRC
178 2017-05-25T17:49:27  *** Alina-malina has joined #bitcoin-core-dev
179 2017-05-25T17:53:28  *** Alina-malina has quit IRC
180 2017-05-25T17:53:28  *** Alina-malina has joined #bitcoin-core-dev
181 2017-05-25T18:15:58  <jonasschnelli> Grml... qt4.
182 2017-05-25T18:16:15  <wumpus> don't be angry, let the people that care about fix it
183 2017-05-25T18:16:31  <jonasschnelli> Yeah... ideally it would be in our CI
184 2017-05-25T18:16:39  <jonasschnelli> otherwise this pops up here and there
185 2017-05-25T18:16:52  <jonasschnelli> but right, I don't care about qt4. If people do, then they must fix it.
186 2017-05-25T18:18:16  <wumpus> yes, same there, let the people that care about it add it to CI :)
187 2017-05-25T18:19:19  <sipa> is Qt4 still intended to be supported?
188 2017-05-25T18:19:38  <wumpus> yes
189 2017-05-25T18:20:03  <wumpus> but no one of us actually uses it anymore, for a long time
190 2017-05-25T18:20:57  <sipa> i believe that gmaxwell's setup had both qt4 and qt5, and configure automatically picked qt4?
191 2017-05-25T18:21:42  <jonasschnelli> even worse, I think BlueMatt's PPA builds against qt4?!
192 2017-05-25T18:21:57  <wumpus> there's an issue for qt4 eol, but apparently some people are still relying on it, so if they want to spend work on supporting it it's 100% fine by me, just don't expect me to: https://github.com/bitcoin/bitcoin/issues/8263
193 2017-05-25T18:22:20  *** Ylbam has quit IRC
194 2017-05-25T18:22:20  <wumpus> if both qt4 and qt5 is installed and detected it should pick qt5
195 2017-05-25T18:22:51  <jonasschnelli> during runtime? Do they compatible ABIs?
196 2017-05-25T18:23:05  <wumpus> nono at configure time
197 2017-05-25T18:23:19  <jonasschnelli> But the PPA is pre-built?
198 2017-05-25T18:23:36  <wumpus> sipa was asking about configure, my answer was to that
199 2017-05-25T18:23:41  <jonasschnelli> ah. sry
200 2017-05-25T18:24:00  <jonasschnelli> Yes. It prefers qt5 since a while.
201 2017-05-25T18:24:01  <wumpus> yes, because of an issue with ubuntu unity tray icon handling apparently qt4 works better on some ubuntu versions
202 2017-05-25T18:25:02  <wumpus> it's pretty sad, but nothing really to be done about it, except wait for unity to be history
203 2017-05-25T18:25:33  <wumpus> this is not a problem with our code, or even qt upstream, but with ubuntu specific plugins
204 2017-05-25T18:28:34  <sipa> how about we just remove the tray icon support...?
205 2017-05-25T18:28:47  <wumpus> it's possible, but it works fine for other OSes and other linux distros
206 2017-05-25T18:29:05  <wumpus> I wouldn't mind removing tray icon support, but this in itself is a lousy reason
207 2017-05-25T18:29:58  <wumpus> sure - disabling it specifically for the ppa would work, including a custom patch
208 2017-05-25T18:30:04  <sipa> i was about to say that one distro with lousy trayicon support is a bad reason to stick with qt4... except we only stick to qt4 on ubuntu
209 2017-05-25T18:30:11  <wumpus> that's up to BlueMatt
210 2017-05-25T18:30:15  <wumpus> exactly!
211 2017-05-25T18:30:35  <gmaxwell> I don't care about QT4 but I thought we still supported it.
212 2017-05-25T18:30:55  <gmaxwell> And as sipa mentioned, I have both installed and it's building against 4.
213 2017-05-25T18:31:07  <gmaxwell> (on debian testing)
214 2017-05-25T18:31:19  <wumpus> (last time I tried tray icon support on ubuntu 16.04, with self-compiled bitcoin-qt on qt5 it seemed to work fine for me, btw, maybe they've fixed it, at least on some versions... or it's somehow dependent on a combination of circumstances)
215 2017-05-25T18:31:20  <jonasschnelli> gmaxwell: hmm... bitcoin.m4 should prefere qt5 though... strange
216 2017-05-25T18:31:31  <gmaxwell> I suppose it's possible something is screwed up, but it seems to be useful that it is since I keep catching build failures.
217 2017-05-25T18:31:40  <sipa> gmaxwell: perhaps you have some tiny dependency missing for qt5?
218 2017-05-25T18:31:44  <jonasschnelli> Maybe one of the qt5 libs is missin?
219 2017-05-25T18:31:49  <jonasschnelli> +g
220 2017-05-25T18:32:06  <jonasschnelli> config.log should probably tell you why...
221 2017-05-25T18:32:11  <wumpus> my guess is that the qt5 detection is either broken on your distro, or a required component is missing
222 2017-05-25T18:32:19  <wumpus> yeah that'd help
223 2017-05-25T18:32:40  <sipa> well there are two independent issues here... building for qt4 should work if it's intended to be supported
224 2017-05-25T18:32:47  <sipa> and qt5 should be detected properly for gmaxwell
225 2017-05-25T18:33:42  <luke-jr> wumpus: I already tried to add it to CI, and then it was supposed to be part of the daily CI..
226 2017-05-25T18:34:03  <wumpus> luke-jr: ok, but it isn't?
227 2017-05-25T18:34:32  <luke-jr> I guess someone removed it? Daily CI thing seems to be closed/dead?
228 2017-05-25T18:34:40  <wumpus> it's run from a crontab now
229 2017-05-25T18:34:50  <wumpus> (a new travis CI feature)
230 2017-05-25T18:35:05  <luke-jr> so what happened to the qt4 part?
231 2017-05-25T18:35:08  <wumpus> I don't know
232 2017-05-25T18:35:30  <jonasschnelli> But I guess cron is not sufficient for qt4 support. We want to know before a merge
233 2017-05-25T18:35:42  <luke-jr> I wonder if .. yeah, maybe it should be a primary QA
234 2017-05-25T18:36:42  <wumpus> I think the problem back then was that we don't really want to add a new configuration/build for it,and it couldn't be fit into one of the current ones
235 2017-05-25T18:36:46  <wumpus> but I might misremember
236 2017-05-25T18:37:30  <luke-jr> well, if you want to reopen https://github.com/bitcoin/bitcoin/pull/7142 , I can rebase..
237 2017-05-25T18:39:38  <bitcoin-git> [bitcoin] laanwj reopened pull request #7142: [WIP] Travis: Test build against system Qt4 (master...travis_qt4) https://github.com/bitcoin/bitcoin/pull/7142
238 2017-05-25T18:41:49  <gmaxwell> wumpus: thanks. I think we need it in build CI or we need to drop support for it.
239 2017-05-25T18:42:11  <wumpus> gmaxwell: I'm fine with either
240 2017-05-25T18:43:17  <wumpus> I really don't have an opinion on qt4, just refuse to spend time in it myself
241 2017-05-25T18:45:30  <wumpus> but I guess it's the same in linux, I doubt e.g. Linus cares personally about all the drivers for ancient devices still in there, but as long as someone is willing to put in the time to keep it working it's better to keep including it instead of nuke it just because, after all it's a community effort
242 2017-05-25T18:47:26  <gmaxwell> I don't know if I should care about QT4 or not. (don't know what the deployment rate of QT5 is)
243 2017-05-25T18:50:19  <wumpus> I don't know either, this is the last thing qt.io ever posted on qt4: https://blog.qt.io/blog/2014/11/27/qt-4-8-x-support-to-be-extended-for-another-year/
244 2017-05-25T18:51:44  <wumpus> never was able to find a real EOL announcement, but it's been dead in the water for a long time
245 2017-05-25T18:51:59  *** SopaXorzTaker has quit IRC
246 2017-05-25T18:54:57  <wumpus> not that it says much, I know for fact that some industrial systems are still using qt4, even qt3 probably (was the case a few years ago)
247 2017-05-25T18:55:44  <luke-jr> FWIW, I looked into adding Qt3 support briefly and decided it would be a pain :p
248 2017-05-25T18:56:46  <wumpus> qt5 is much better for multimedia/modern app kind of interfaces, but for simple boring widget interfaces there's only a small difference between qt3 and qt4 and the difference between qt4 and qt5 is negible
249 2017-05-25T18:59:10  <gmaxwell> If QT5 is shipping by default on the common linux distributions, perhaps we should stop QT4 support. Even though the difference is small, the effort to keep supporting it is non-trivial.
250 2017-05-25T18:59:16  <wumpus> luke-jr: yes the API is quite different, I mean the user experience isn't that different
251 2017-05-25T18:59:57  *** marsu has joined #bitcoin-core-dev
252 2017-05-25T19:00:25  <wumpus> gmaxwell: yup qt5 has been the default on linux distros for a few years (don't know exactly how long / since which versions of particular distros though)
253 2017-05-25T19:00:39  <luke-jr> gmaxwell: Qt5 doesn't have native look/feel on Qt4-based DEs.. but even that seems dead now
254 2017-05-25T19:00:45  <instagibbs> meeting time?
255 2017-05-25T19:00:46  <wumpus> but at least in ubuntu 14.04 it already was
256 2017-05-25T19:00:52  <wumpus> #startmeeting
257 2017-05-25T19:00:52  <lightningbot> Meeting started Thu May 25 19:00:52 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
258 2017-05-25T19:00:52  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
259 2017-05-25T19:00:57  <BlueMatt> sipa: last i heard we were gonna try to just remove the trayicon
260 2017-05-25T19:01:08  <jonasschnelli> proposed topic multiwallet-concept
261 2017-05-25T19:01:21  <BlueMatt> (since it doesnt seem to be "the thing to do" anymore)
262 2017-05-25T19:01:27  <sipa> woah, meeting!
263 2017-05-25T19:01:35  <sipa> i totally forgot
264 2017-05-25T19:01:38  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure blue matt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 instagibbs
265 2017-05-25T19:01:56  <cfields> hi
266 2017-05-25T19:02:00  <wumpus> #topic multiwallet-concept
267 2017-05-25T19:03:11  <luke-jr> ..
268 2017-05-25T19:03:16  <jonasschnelli> We should think about if we want run-time wallet creation/loading/unloading or per startup -wallet argument.
269 2017-05-25T19:03:30  <luke-jr> jonasschnelli: IMO both eventually, but the latter is a good first stpe
270 2017-05-25T19:03:31  <jonasschnelli> Also,.. what should we do with rescan/zapwallet/salvage/upgrade
271 2017-05-25T19:03:43  <wumpus> yes, in the long term we want both
272 2017-05-25T19:03:56  <wumpus> in the short term just do what is realistic for the (not too long!) timespan until 0.15
273 2017-05-25T19:03:59  <sipa> i would disable rescan if you have more than one wallet configured
274 2017-05-25T19:04:03  <jonasschnelli> the -wallet= approach seems very confusing. You either -usehd on all wallte, -rescan all wallets, etc.
275 2017-05-25T19:04:04  <sipa> and use the RPC instead
276 2017-05-25T19:04:38  <sipa> or better, remove it
277 2017-05-25T19:04:48  <jonasschnelli> We can start with the all or nothing -wallet configuration. But ideally we move it to runtime over RPC
278 2017-05-25T19:05:03  <jonasschnelli> also,... creation-flags can then be passed in.
279 2017-05-25T19:05:10  <wumpus> yes
280 2017-05-25T19:05:11  <sipa> right, all those options that affect the creation of new wallets ideally go into a new-wallet-creation RPC
281 2017-05-25T19:05:21  <jonasschnelli> yes
282 2017-05-25T19:05:21  <luke-jr> /GUI
283 2017-05-25T19:05:24  <sipa> and rescan and upgrade become wallet-specific RPCs
284 2017-05-25T19:05:25  <wumpus> so the command line options only work for the default wallet
285 2017-05-25T19:05:29  <jonasschnelli> The GUI can be done later
286 2017-05-25T19:05:30  <wumpus> that's fine
287 2017-05-25T19:05:33  <wumpus> yes
288 2017-05-25T19:05:36  <luke-jr> sipa: they already are?
289 2017-05-25T19:05:46  <sipa> luke-jr: they're not RPCs
290 2017-05-25T19:05:47  <sipa> ?
291 2017-05-25T19:05:58  <luke-jr> sipa: rescan is, although maybe not merged in Core yet?
292 2017-05-25T19:06:03  <jonasschnelli> I ack luke-jr current PR but deploying that may cause confusion (because of lack of a concept)=
293 2017-05-25T19:06:14  <sipa> luke-jr: #7061
294 2017-05-25T19:06:17  <gribble> https://github.com/bitcoin/bitcoin/issues/7061 | [Wallet] Replace -rescan with a new RPC call "rescanblockchain" by jonasschnelli · Pull Request #7061 · bitcoin/bitcoin · GitHub
295 2017-05-25T19:06:32  * sipa really really really wants to see rescan go away entirely, but fears he cannot win this fight
296 2017-05-25T19:06:49  <luke-jr> actually, -rescan might be better with multiwallet
297 2017-05-25T19:06:53  <jonasschnelli> Heh. Its just to handy to remove rescan
298 2017-05-25T19:07:00  <luke-jr> since you'd want to rescan all the wallets concurrently
299 2017-05-25T19:07:14  <sipa> fair point
300 2017-05-25T19:07:38  <luke-jr> the overhead for rescanning N wallets vs 1 is minimal IMO
301 2017-05-25T19:07:40  <jonasschnelli> Another point is that we should consider wallet flags combined with the new wallet db format we have introduced with the HD chain split.
302 2017-05-25T19:08:01  <jonasschnelli> wallet flags would probably better allow to store "creation flags"
303 2017-05-25T19:08:07  <sipa> what do you mean by wallet flags?
304 2017-05-25T19:08:27  <jtimon> labels?
305 2017-05-25T19:08:37  <jonasschnelli> I have first implemented wallet flags here: https://github.com/bitcoin/bitcoin/pull/9662
306 2017-05-25T19:08:52  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/9662/files#diff-b2bb174788c7409b671c46ccc86034bdR1357
307 2017-05-25T19:09:35  <jonasschnelli> But maybe it's not required for the current feature set. But think like: "is the wallet using HD", "is it using chain split", .. "are pkeys diables"?
308 2017-05-25T19:09:43  <sipa> yup
309 2017-05-25T19:09:49  <luke-jr> eh, the wallet already supports that?
310 2017-05-25T19:10:00  <sipa> but i think that's orthogonal to the new database format
311 2017-05-25T19:10:20  <jonasschnelli> Yes. But we already do a new wallet-format type in 0.15. Ideally we push in everything that usefull for 0.15+
312 2017-05-25T19:10:32  <sipa> a new wallet format in 0.15?
313 2017-05-25T19:10:34  <sipa> what?
314 2017-05-25T19:10:42  <jtimon> sounds too optimistic
315 2017-05-25T19:10:48  <jonasschnelli> the HD chain-split is not backward compatible
316 2017-05-25T19:10:51  <sipa> oh!
317 2017-05-25T19:10:52  <jonasschnelli> Not a new database format.
318 2017-05-25T19:10:52  <sipa> ok
319 2017-05-25T19:10:53  <wumpus> let's not make multiwallet dependent on a new wallet format
320 2017-05-25T19:10:57  <sipa> nvm
321 2017-05-25T19:11:02  <wumpus> okay, makes sense
322 2017-05-25T19:11:03  <sipa> i thought you were talking about logdb
323 2017-05-25T19:11:08  <jonasschnelli> nono...
324 2017-05-25T19:11:32  <jonasschnelli> Just saying that the 0.15er wallet.dat files will not be backward comp.
325 2017-05-25T19:11:43  <sipa> yeah, sure
326 2017-05-25T19:11:46  <jonasschnelli> ideally we push in as much as we can... to avoid the same non -back com. in 0.16
327 2017-05-25T19:11:50  <luke-jr> 0.15-created*?
328 2017-05-25T19:12:05  <jonasschnelli> 0.15 created.. yes
329 2017-05-25T19:12:12  <sipa> i think breaking backward compatibility in major releases is fine
330 2017-05-25T19:12:35  <jonasschnelli> Yes. But if we can avoid it with little effort we may want to do it.
331 2017-05-25T19:12:40  <jonasschnelli> But lets park this problem for now.
332 2017-05-25T19:12:41  <jtimon> but his point is the more we get in now the less we have to break the next time
333 2017-05-25T19:12:47  <gmaxwell> luke-jr: if you what to preserve rescan you need to make it faster.  I think rescan is already functionally dead for many users: It takes something like 8 hours on my laptop.
334 2017-05-25T19:12:57  <jonasschnelli> Way more important is what we do with -zap/-salvage/-upgrade in multiwallet
335 2017-05-25T19:13:18  <luke-jr> jonasschnelli: forbid them with >1 -wallet?
336 2017-05-25T19:13:30  <jonasschnelli> luke-jr: yes. why not.
337 2017-05-25T19:13:45  <gmaxwell> jonasschnelli: I replied to your comment on that PR: I think zap and salvage should ultimately go away or move to another tool. Upgrade, I dunno.
338 2017-05-25T19:13:45  <jonasschnelli> How would you run a non-hd and a hd-wallet (seems to be a reasonable use case)
339 2017-05-25T19:13:52  <jonasschnelli> gmaxwell: agree with you
340 2017-05-25T19:13:56  * sipa suggest removing zap in favor of abandontransaction, replacing salvage with a standalone tool, and leaving ugprade to apply to all wallets
341 2017-05-25T19:13:58  <luke-jr> jonasschnelli: it just works right now..
342 2017-05-25T19:14:20  <jonasschnelli> luke-jr: Can it work? If you call -usehd on a non-hd wallet is stops during init
343 2017-05-25T19:14:28  <luke-jr> jonasschnelli: don't set -usehd
344 2017-05-25T19:14:37  <jonasschnelli> The its 1 by default
345 2017-05-25T19:14:47  <luke-jr> no, it's <whatever> by default, for existing wallets
346 2017-05-25T19:14:51  <jonasschnelli> I guess you can't mix right now
347 2017-05-25T19:15:06  <luke-jr> I test multiwallet with a combo of HD and non-HD
348 2017-05-25T19:15:13  <jonasschnelli> Okay. Sorry then.
349 2017-05-25T19:15:14  <sipa> -usehd should go away and become a parameter of the createnewwallet RPC
350 2017-05-25T19:15:20  <jonasschnelli> yes
351 2017-05-25T19:15:25  <gmaxwell> what sipa said.
352 2017-05-25T19:15:49  <luke-jr> createnewwallet won't make 0.15 IMO
353 2017-05-25T19:15:54  <sipa> that's fine
354 2017-05-25T19:16:16  <jonasschnelli> I once stared with a standalone wallet tool but had problems with circular dependencies (cfields may know more): https://github.com/bitcoin/bitcoin/pull/8745
355 2017-05-25T19:16:42  <jonasschnelli> Starting with luke-jr's current PR is fine..
356 2017-05-25T19:16:56  <kanzure> is there interaction between multiwallet and accounts?
357 2017-05-25T19:17:01  <sipa> kanzure: no
358 2017-05-25T19:17:06  <cfields> jonasschnelli: i'm sure we could get that worked out
359 2017-05-25T19:17:23  <jonasschnelli> cfields: okay. Great
360 2017-05-25T19:17:34  <sipa> for the time being, i think that -usehd (if specified) should apply to all wallets, if not specified, every wallet can be whatever it already is
361 2017-05-25T19:17:36  <wumpus> yes, that's fine, let's aim to get at least basic multiwallet support in 0.15 though
362 2017-05-25T19:17:54  <jonasschnelli> agree
363 2017-05-25T19:18:07  <wumpus> not let it slip another release because we want too much from it, or make it conditional on other changes which haven't been done yet
364 2017-05-25T19:18:14  <sipa> short topic suggestion: variable naming style
365 2017-05-25T19:18:28  <gmaxwell> sha256 hashes for all variables!
366 2017-05-25T19:18:31  <jonasschnelli> I just think we should have a (the same) concept in the backhead to avoid extra loops
367 2017-05-25T19:18:37  <jonasschnelli> lol
368 2017-05-25T19:18:39  <morcos> if this is better offline, fine, but sipa, how would we remove rescan?
369 2017-05-25T19:18:45  <kanzure> no abbreviated variable names plzkthx. actually i would take sha256 hashes over abbreviations.
370 2017-05-25T19:18:54  <sipa> morcos: let's discuss after the meeting
371 2017-05-25T19:18:56  <wumpus> gmaxwell: I was about to suggest xxd on /dev/urandom, but that works for me  too :p
372 2017-05-25T19:18:57  <morcos> k
373 2017-05-25T19:19:00  <wumpus> #topic variable naming style
374 2017-05-25T19:19:04  * cfields would kill for m_ == member
375 2017-05-25T19:19:27  <luke-jr> pls don't kill
376 2017-05-25T19:19:32  <sipa> i've recently seen several people write patches with variable names that look like they're hungarian, but aren't
377 2017-05-25T19:19:45  <sipa> i don't care personally for that particular style, but i like consistency
378 2017-05-25T19:19:53  <wumpus> the hungerian onvention should die
379 2017-05-25T19:20:03  <sipa> but what to replace it with?
380 2017-05-25T19:20:05  <luke-jr> I particularly dislike hungarian-looking names that don't have the hungarian meaning :p
381 2017-05-25T19:21:13  <gmaxwell> Greek characters.
382 2017-05-25T19:21:16  <sipa> i guess the first question is, do we want any convention specified (in developer-notes) at all, and enforce it in new code?
383 2017-05-25T19:21:19  <wumpus> luke-jr: exactly - and that's what happens, because we have abandoned the style a long time ago and don't describe it in the style doc
384 2017-05-25T19:21:21  <cfields> any convention that ties a variable to a type is broken imo
385 2017-05-25T19:21:22  <luke-jr> Unicode var names?
386 2017-05-25T19:21:31  <wumpus> cfields: RIGHT
387 2017-05-25T19:21:36  <jtimon> is this about gArgs ?
388 2017-05-25T19:21:39  <luke-jr> no
389 2017-05-25T19:21:43  <wumpus> people mimic the style but don't know what it means
390 2017-05-25T19:21:49  <wumpus> they should stop mimicing the style too
391 2017-05-25T19:22:02  <sipa> wumpus: the only way that's going to happen is by prescribing a style to use in new code
392 2017-05-25T19:22:06  <cfields> wumpus: well, it's been common practice to mimic the code around your changes
393 2017-05-25T19:22:32  <gmaxwell> cfields: yes but mimiking the style of hungarin notation and getting it wrong misses the point of it. :P
394 2017-05-25T19:22:36  <sipa> i've come to dislike the "mimick the code around you" suggestion - it does not lead to consistency
395 2017-05-25T19:22:43  <wumpus> gmaxwell: haha exactly... something with cargo cults
396 2017-05-25T19:22:50  <luke-jr> sipa: okay, let's switch to tabs instead of spaces then
397 2017-05-25T19:22:52  <luke-jr> :P
398 2017-05-25T19:23:31  <gmaxwell> I'm not aware of any evidence supporting any of these highly structured variable name recommendations as actually providing benefits.
399 2017-05-25T19:23:36  <jtimon> sipa: right, people do it naturally, but I don't think it should be a convention
400 2017-05-25T19:23:38  <wumpus> gmaxwell: +1
401 2017-05-25T19:23:54  <paveljanik> nah, these TAB/spaces wars: delete all indentation and let editor choose the right indentation! ;-)
402 2017-05-25T19:23:55  <cfields> gmaxwell: m_foo and g_foo are extremely helpful imo
403 2017-05-25T19:23:59  <cfields> but not much else
404 2017-05-25T19:24:13  <luke-jr> paveljanik: that's what tabs do
405 2017-05-25T19:24:16  <gmaxwell> (esp since pretty much no one is sadistic to encode the full type into the name.)
406 2017-05-25T19:24:28  <paveljanik> nono, tabsonly compress. No TABs/spaces...
407 2017-05-25T19:24:29  <wumpus> sure, including the scope might be reasonably useful, unlike encoding the type
408 2017-05-25T19:24:37  <luke-jr> maybe we should use C++ mangled names
409 2017-05-25T19:24:38  <wumpus> but I'm not looking forward to sweeping code style changes
410 2017-05-25T19:24:46  <sipa> sigh, nobody is talking about encouraging structured variable name recommendations
411 2017-05-25T19:25:09  <wumpus> before you know it there are 10 PRs open for renaming variables (again, after the shadow fiasco)
412 2017-05-25T19:25:23  <jtimon> gmaxwell: I've seen some sadistic java code that was close
413 2017-05-25T19:25:29  <luke-jr> I like the "style changes only affect new code" policy
414 2017-05-25T19:25:33  <sipa> luke-jr: me too
415 2017-05-25T19:25:42  <cfields> sipa: maybe suggest the kind of style policy you have in mind? you mean simple things like camelCase vs under_score?
416 2017-05-25T19:25:43  <sipa> and even exclude purely moved code
417 2017-05-25T19:25:46  <wumpus> yes - feel free to write up a style recommendation for new code
418 2017-05-25T19:25:49  <kanzure> would be nice to have style preference mentioned in docs
419 2017-05-25T19:25:50  <sipa> cfields: either of those is fine
420 2017-05-25T19:25:56  <sipa> cfields: but one, not both
421 2017-05-25T19:26:19  <wumpus> and consistency is good, but please don't be a jerk about it, especially not to new contributors
422 2017-05-25T19:26:21  <jtimon> ack only one not both
423 2017-05-25T19:26:45  <jcorgan> my experience is that code is read far more often than it is written, and especially so if it serves as documentation
424 2017-05-25T19:26:51  <sipa> if i had to choose, i'd say under_score - that's what STL uses
425 2017-05-25T19:27:05  <jcorgan> when code has disjoint styles, people reading it might wonder if it is different for a reason, or just an accident
426 2017-05-25T19:27:13  <jtimon> or maybe camelCaseForVariables, UNDER_SCORE_FOR_CONSTANTS
427 2017-05-25T19:27:22  <sipa> and i'm also fine m_X and g_X if that considered useful
428 2017-05-25T19:27:32  <morcos> My only real contribution to this discussion is whatever we decide on should be clearly spelled out in developer documentation, so we can just point to it over and over gain.  Otherwise we'll come away with an agreement that means somethign different to each party.
429 2017-05-25T19:27:32  <jtimon> since I believe that's closer to what we have
430 2017-05-25T19:27:44  <wumpus> morcos: yes yes yes
431 2017-05-25T19:27:47  <gmaxwell> I'm not a fan of the camelcase, because then you get things wrong based just on the case. seems weird.
432 2017-05-25T19:27:53  <jcorgan> morcos: now when did that happen recently?
433 2017-05-25T19:27:54  <luke-jr> camel case isn't bad, but it creates the hungarian confuson
434 2017-05-25T19:28:02  <gmaxwell> luke-jr: that too
435 2017-05-25T19:28:05  <sipa> camelcase also is easily confused with hungarian
436 2017-05-25T19:28:07  <sipa> what luke-jr said
437 2017-05-25T19:28:29  <wumpus> morcos: most important to get it into a document in the repository, as to make clear reviewrs aren't forcing their personal style preferences
438 2017-05-25T19:28:31  <jtimon> super ack to morcos suggestion, if it's not documented, it is simply not a convention
439 2017-05-25T19:29:05  <cfields> morcos: ok, so camelCase today, and hard-fork in a month?
440 2017-05-25T19:29:07  <cfields> :p
441 2017-05-25T19:29:09  <jcorgan> my heuristic is, if you can't tell that a body of code was written my multiple authors over time, that's a win
442 2017-05-25T19:29:16  <luke-jr> let's simply agree for variable names on bit 4. the rest can be subjective.
443 2017-05-25T19:29:25  <sipa> so, if i would create a PR that added to the dev documentation "For new code, the following style for variables is encouraged: local_variable for local variables, m_variable for members, g_variable for globals"
444 2017-05-25T19:29:40  <luke-jr> local_* seems annoying
445 2017-05-25T19:29:50  <sipa> luke-jr: oops, i didn't mean that as a prefix
446 2017-05-25T19:29:54  <luke-jr> k
447 2017-05-25T19:29:58  <gmaxwell> I still don't know when to ask someone touching code to fix things per documented style or not.  E.g. 10441 cfields introduces both new braced and unbraced iffs in a function that contains both.
448 2017-05-25T19:30:14  <sipa> variable, a_variable, j, var, bla, foo, ... all good
449 2017-05-25T19:30:26  <morcos> gmaxwell: he should fix that
450 2017-05-25T19:30:33  <gmaxwell> okay. I'll nitpick then.
451 2017-05-25T19:30:34  <wumpus> gmaxwell: if it's cfields you should certainly make him aware of it, he's supposed to know better :)
452 2017-05-25T19:31:00  <cfields> heh, yes. I think that was a mix of matching nearby code and copy/paste
453 2017-05-25T19:31:03  * wumpus ducks
454 2017-05-25T19:31:10  <jtimon> I think moving away from camel case it's the most disruptive option for local variables
455 2017-05-25T19:31:19  <jtimon> but no strong opinion
456 2017-05-25T19:31:37  <cfields> i'd certainly never make that mistake again if we added "don't attempt to match nearby code" to the style doc
457 2017-05-25T19:31:37  <sipa> it's already often used for loop variables etc
458 2017-05-25T19:31:44  <luke-jr> variables were never camel-case..?
459 2017-05-25T19:31:47  <jtimon> just saying that it would be nicer if the style was as close as possible to what we have now
460 2017-05-25T19:31:57  <cfields> without that, i'd never add another unbraced if :)
461 2017-05-25T19:31:59  <wumpus> abandoning the camels for the snakes
462 2017-05-25T19:32:02  <sipa> luke-jr: sure some where, CBlockIndex* pindexBlock = ...
463 2017-05-25T19:32:08  <luke-jr> sipa: that's just hungarian
464 2017-05-25T19:32:24  <sipa> luke-jr: hungarian is just a more constrained camelcase
465 2017-05-25T19:32:34  <luke-jr> camelcase is where you use it as a word separater..
466 2017-05-25T19:32:41  <sipa> cfields: ack on adding "Do not attempt to match nearby code, unless you're creating a move-only commit"
467 2017-05-25T19:32:52  <morcos> sipa: +!
468 2017-05-25T19:32:53  <morcos> 1
469 2017-05-25T19:32:54  <jtimon> luke-jr: well if camel case it's less common than underscore for variables then my argument goes away
470 2017-05-25T19:33:16  <jtimon> I really don't know for sure, was just guessing
471 2017-05-25T19:33:20  <sipa> luke-jr: and hungarian is using case as word separator, plus the requirement that the first word is the type :)
472 2017-05-25T19:33:55  <morcos> i'll defer to group, but i prefer camel to underscores, but do like at least identifying global variables with g_ or :: or something
473 2017-05-25T19:34:13  <luke-jr> gCamel/mCamel wouldn't be terrible
474 2017-05-25T19:34:20  <gmaxwell> I would ACK doing something consistent for globals.
475 2017-05-25T19:34:36  <sipa> anyway, any comments on those suggestions? encouraging lowercase + underscore for local variables, and m_ for members, g_ for globals, and a mention to not mimick surrounding code?
476 2017-05-25T19:34:39  <wumpus> I prefer snakecase like sipa
477 2017-05-25T19:34:49  <gmaxwell> One thing I don't like about C++ is that when there is a variable that isn't local I dunno if its coming from the class or if it's a global... without going and digging in other files.
478 2017-05-25T19:35:24  <cfields> gmaxwell: hence m_ :)
479 2017-05-25T19:35:26  <gmaxwell> so if naming helps disambiguate that I would not be unhappy.
480 2017-05-25T19:35:40  <wumpus> for variable names, for method names we should obviously keep sticking to camelcase
481 2017-05-25T19:35:48  <morcos> are we ok with combining small words without the udnerscore like feerate or blocksize or something?
482 2017-05-25T19:35:51  <sipa> wumpus: agree, and class names as well
483 2017-05-25T19:35:55  <wumpus> sipa: yes
484 2017-05-25T19:35:56  <sdaftuar> bit_coin right?
485 2017-05-25T19:35:56  <sipa> morcos: ack from me
486 2017-05-25T19:36:09  <wumpus> sdaftuar: it's better than BitCoin
487 2017-05-25T19:36:10  <sipa> one lowercase word is totally fine for local variables
488 2017-05-25T19:36:14  <wumpus> yes
489 2017-05-25T19:36:17  <cfields> sipa: ack all of the above
490 2017-05-25T19:36:18  <luke-jr> I prefer camelcase, except for the annoying conflict w/ hungarian
491 2017-05-25T19:36:35  <luke-jr> I don't care strongly tho
492 2017-05-25T19:36:56  <sipa> oh, what to do with the cs_* variables we have now?
493 2017-05-25T19:37:02  <sipa> do we want an exception for that?
494 2017-05-25T19:37:07  <morcos> oh ok, so we're keeping camel for class and method names and snake for variables..  ok someone write it up
495 2017-05-25T19:37:13  <gmaxwell> I would be fine with an exception for cs_.
496 2017-05-25T19:37:26  <wumpus> cs_ for locks? it's fine with me
497 2017-05-25T19:37:33  <sipa> so... g_blockindex g_cs_blockindex?
498 2017-05-25T19:37:37  <wumpus> though I still thing the scope is more useful
499 2017-05-25T19:37:44  <morcos> but no exception for pblockindex ?
500 2017-05-25T19:38:01  <sipa> that's hungarian - dia
501 2017-05-25T19:38:02  <sipa> die
502 2017-05-25T19:38:05  <sipa> ;)
503 2017-05-25T19:38:15  <wumpus> pblockindex could just be block_index
504 2017-05-25T19:38:21  <sipa> indeed
505 2017-05-25T19:38:23  <wumpus> though we aren't actrually going to rename variables en-messe
506 2017-05-25T19:38:24  <cfields> [11:17:50] -*- cfields would kill for m_ == member
507 2017-05-25T19:38:24  <cfields> [11:18:13] <luke-jr> pls don't kill
508 2017-05-25T19:38:27  <sipa> wumpus: indeed
509 2017-05-25T19:38:41  <gmaxwell> cfields: thou shall not kill
510 2017-05-25T19:38:48  <sipa> i'll write up a PR, and we discuss there further?
511 2017-05-25T19:38:51  <gmaxwell> is all I think luke was saying.
512 2017-05-25T19:38:57  <luke-jr> yes
513 2017-05-25T19:38:58  <morcos> sounds good
514 2017-05-25T19:39:01  <sipa> ok, topic closed
515 2017-05-25T19:39:06  <gmaxwell> sipa to do all the work, agreed.
516 2017-05-25T19:39:09  <wumpus> I don't want to see any more variable renaming PRs, the Wshadow war made me so tired of that
517 2017-05-25T19:39:13  <wumpus> other topics?
518 2017-05-25T19:39:19  <luke-jr> BIP148
519 2017-05-25T19:39:46  <morcos> next topic
520 2017-05-25T19:39:59  <wumpus> I have nothing to say about that, at least
521 2017-05-25T19:40:25  <wumpus> but i f you insist
522 2017-05-25T19:40:26  <wumpus> #topic BIP148
523 2017-05-25T19:40:27  <jonasschnelli> I guess we have already enough comments on the PRs..
524 2017-05-25T19:40:32  <sipa> my opinion is that it would go against our principles to merge BIP148 into core
525 2017-05-25T19:40:40  <luke-jr> sipa: how so?
526 2017-05-25T19:40:59  <BlueMatt> sipa: +100
527 2017-05-25T19:41:08  <sipa> i've given my opinion more than enough on existing PRs
528 2017-05-25T19:41:25  <sipa> i strongly disagree with the "less safe" argument
529 2017-05-25T19:41:26  <wumpus> right, I think everyone already had their say on this
530 2017-05-25T19:41:37  <sipa> and we shouldn't encourage forks in the network
531 2017-05-25T19:41:43  <sipa> nor is it out place to push for consensus changes
532 2017-05-25T19:41:43  <luke-jr> so we should put users at risk by refusing to enforce the new rule?
533 2017-05-25T19:41:44  <wumpus> let's merge BIP149 instead
534 2017-05-25T19:41:51  <luke-jr> sipa: refusing to merge is what encourages the fork in this case
535 2017-05-25T19:41:56  <sipa> luke-jr: i strongly disagree that it puts users more at risk
536 2017-05-25T19:42:26  <gmaxwell> wumpus: I brought up 149's timeout on the list, but its author hasn't replied, I think it is needlessly long.
537 2017-05-25T19:42:33  <morcos> My opinion closely matches sdaftuars from : https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014377.html
538 2017-05-25T19:42:34  <luke-jr> not only does not-merging it encourage a chain split, it also puts users on the side vulnerable to reorg wipeout
539 2017-05-25T19:42:48  <luke-jr> gmaxwell: I think it's too early
540 2017-05-25T19:43:01  <morcos> I'd be in favor of 149, but I think we should start by being a bit more public about the idea and building consensus for it before actually merging
541 2017-05-25T19:43:06  <BlueMatt> gmaxwell: ack, your proposal of 6 months seemed reasonable to me
542 2017-05-25T19:43:08  <morcos> And eys I agree we could tweak it a bit
543 2017-05-25T19:43:11  <BlueMatt> morcos: +1
544 2017-05-25T19:43:16  <wumpus> gmaxwell: yes we need to agree on the timeout at lesat
545 2017-05-25T19:43:19  <sipa> luke-jr: the only condition under which it helps users avoid a huge reorg is one under which those who didn't upgrade already experienced a (temporary, but long) fork
546 2017-05-25T19:43:53  <jtimon> as said on the mailing list I think bip148 is rushed and that makes it risky, bip8 on the other hand...(although I'm writing suggestions for changing bip8)
547 2017-05-25T19:44:01  <luke-jr> sipa: this seems tautological?
548 2017-05-25T19:44:37  <jtimon> we can merge bip8 without merging bip149 yet, although the sooner it is released the more secure it will be
549 2017-05-25T19:44:39  <sipa> luke-jr: then how is merging it less risky?
550 2017-05-25T19:44:49  <sipa> luke-jr: it only helps in case a fork already happened!
551 2017-05-25T19:45:06  <sipa> while at the same time encouraging said fork
552 2017-05-25T19:45:17  <gmaxwell> luke-jr: I haven't seen the kind of support required to justify your position on that; afaict so far no exchange or payment processor of note has said they would stick with 148.  I think you'd have an argument if there was any of that, but right now I think it's hard to distinguish a subsanstive level of support. (And I've seen some clearly malicious parties pumping support for it too.)
553 2017-05-25T19:45:18  <luke-jr> sipa: if a fork happens, it puts them on the side that isn't vulnerable to a reorg, and it helps avoid the fork in the first place
554 2017-05-25T19:45:24  <sipa> not encouraging it seems far safer than slightly reducing the risk in case it does
555 2017-05-25T19:45:36  <sipa> luke-jr: under the assumption a hashrate majority adopts it
556 2017-05-25T19:45:40  <sipa> luke-jr: which i think is crazy
557 2017-05-25T19:45:54  <gmaxwell> My discussions on reddit with people promoting BIP148 seemed to be because they earniestly believed it was the only choice.
558 2017-05-25T19:45:57  <luke-jr> sipa: BIP148 only needs about 25% hashrate to be successful
559 2017-05-25T19:45:58  <morcos> At the end of the day I think most of us have no interest in greatly increasing the risk of a devastating currency split.  I think 148 does that..  But 149 has a decent chance of not doing that if there have been no other consensus rule changes in the interim.  But will require consensus building.
560 2017-05-25T19:46:10  <gmaxwell> E.g. someone managed to convince them that the project would never adopt something like BIP149.
561 2017-05-25T19:46:13  <sipa> morcos: +1
562 2017-05-25T19:46:19  <sipa> it will require consensus building
563 2017-05-25T19:46:21  <sipa> not discussions here
564 2017-05-25T19:46:38  <BlueMatt> yup
565 2017-05-25T19:46:46  <jtimon> gmaxwell: ack on making the period shorter
566 2017-05-25T19:46:47  <gmaxwell> which seemed really weird to me, because I thought it was pretty obvious that a 149-like thing would be done.
567 2017-05-25T19:47:08  <petertodd> gmaxwell: it's only obvious if people say that
568 2017-05-25T19:48:24  <morcos> And to be clear, I think we'd all like to activate segwit via UASF before we could do so with BIP149 (and it would be feasible I think to build support in a shorter time frame), but we just don't have the technical bandwidth to code that up safely in time.
569 2017-05-25T19:48:34  <wumpus> I think that wasn't obvioius, no
570 2017-05-25T19:48:36  <luke-jr> if businesses get to decide protocol changes, then I guess bit 4 SW it is
571 2017-05-25T19:49:36  <gmaxwell> luke-jr: there is a big difference between saying 'businesses get to decide' and saying that the fact that virtually no industry participant is resolute with 148 is a strong sign the support isn't significant enough. If 148 and six months or a year on its clock that would be another matter.
572 2017-05-25T19:49:39  <sipa> gmaxwell: i don't think it's obvious that BIP149 will happen at all
573 2017-05-25T19:49:39  <morcos> luke-jr: no one even knows what bit 4 SW is?  we might like it, what if its compatible with BIP141 segwit...  lets not make decisions based on a single line in a medium post.
574 2017-05-25T19:49:40  <luke-jr> in the meantime, a sizable portion of the community will be enforcing BIP148, and with success eventually replacing the non-compliant chain
575 2017-05-25T19:50:01  <luke-jr> gmaxwell: it's only virtually none if you exclude the ones who have supported it
576 2017-05-25T19:50:12  *** Joseph__ has joined #bitcoin-core-dev
577 2017-05-25T19:50:24  <jonasschnelli> luke-jr: that's speculation
578 2017-05-25T19:50:29  <petertodd> luke-jr: while technically the result of bip148 may be a reorg, in practice if there is a non-trivial split the result will be two currencies, as someone will launch a currency based on a checkpoint
579 2017-05-25T19:50:30  <jonasschnelli> You can't measure "community"
580 2017-05-25T19:50:33  <gmaxwell> luke-jr: maybe I'm just not aware then.
581 2017-05-25T19:50:34  <sipa> luke-jr: i hope you're right, but my expectation is that every economically relevant full node will revert away from bip148 code hours after the hashrate fails to adopts it
582 2017-05-25T19:50:49  <morcos> luke-jr: I would hope that BIP148 and BIP149 supporters are able to agree at least that they should all support the same thing.
583 2017-05-25T19:51:04  <luke-jr> sipa: Bitfury has already agreed to enforce BIP148 if the bit-4 thing doesn't activate Segwit by August
584 2017-05-25T19:51:08  <petertodd> sipa: depends on how much hash rate... lots of incentive for exchanges to support it and let the two coins trade against each other
585 2017-05-25T19:51:24  <jonasschnelli> sipa: I guess they have also agree (among others) to run Classic
586 2017-05-25T19:51:31  <jonasschnelli> (meant luke-jr)
587 2017-05-25T19:51:34  <sipa> luke-jr: well, i hope you're right
588 2017-05-25T19:51:47  <sipa> but i'm very skeptical about that
589 2017-05-25T19:52:34  <sipa> topic suggestion: high-priority PRs?
590 2017-05-25T19:52:38  <luke-jr> if we're divided in opinion on this, we should at *least* give users the choice, even if they want to stick to Core releases
591 2017-05-25T19:52:44  <gmaxwell> If 148 managed to get the kind of support needed to result in avoiding a chain split, I'm fine with that. But I think it's a very poor and needlessly risky approach.
592 2017-05-25T19:52:52  <sipa> luke-jr: users already have a choice to not run Core
593 2017-05-25T19:52:56  <morcos> luke-jr: you already have a release process, release Knots with the option.
594 2017-05-25T19:53:01  <luke-jr> sipa: many don't want to choose that
595 2017-05-25T19:53:13  <jonasschnelli> maybe for a reason?
596 2017-05-25T19:53:14  <sipa> luke-jr: for good reasons, because we don't do reckless things
597 2017-05-25T19:53:16  *** NewLiberty_ has joined #bitcoin-core-dev
598 2017-05-25T19:53:18  <gmaxwell> luke-jr: then perhaps because the realize that we've usually had good judgement...
599 2017-05-25T19:53:23  <kanzure> what was the default in the bip148 paramflag pull request?
600 2017-05-25T19:53:29  <petertodd> kanzure: false
601 2017-05-25T19:53:32  <jcorgan> off
602 2017-05-25T19:53:34  <luke-jr> gmaxwell: and in this case, we disagree on that judgement.
603 2017-05-25T19:53:38  <petertodd> kanzure: I wouldn't have concept acked it otherwise...
604 2017-05-25T19:53:55  <BlueMatt> alright, next topic
605 2017-05-25T19:53:57  <jtimon> alright, sent suggestions to change bip8 to the mailing list...
606 2017-05-25T19:54:07  <sdfkjs23> deciding what choices users do or do not get seems overly political to me, if core developers want to make a political statement that's fine, but pretending to be neutral and not allowing an optional switch for bip148 seems disingenuous
607 2017-05-25T19:54:14  <kanzure> with context of "default off" some of the above comments make less sense
608 2017-05-25T19:54:39  <cfields> oh, quick topic suggestion: 0.14.2
609 2017-05-25T19:54:41  <jonasschnelli> sdfkjs23? You can offer it yourself by forking and deploying or patching?
610 2017-05-25T19:54:49  <gmaxwell> jtimon: I don't think we should change BIP8 generally: the reason we can do a shorter termination with SW is because we've already done one deployment-- so we know what the uptake looks like and how fast it went the first time.
611 2017-05-25T19:54:52  <petertodd> sdfkjs23: there's a multiple of optional switches that we could add to be neutral - we're not going to add them all, thus we have to make some kind of (hopefully conservative) political statement
612 2017-05-25T19:54:59  <cfields> (sorry, forgot all about it. we can pick it up after the meeting)
613 2017-05-25T19:55:02  <luke-jr> jonasschnelli: too many people (and especially companies) refuse to run anything unless Core releases it
614 2017-05-25T19:55:06  <luke-jr> jonasschnelli: it sucks, but it's reality
615 2017-05-25T19:55:22  <gmaxwell> sdfkjs23: Offering users settings we believe will harm third parties and the user is not 'neutral'.
616 2017-05-25T19:55:23  <kanzure> luke-jr: they want default-off merged and that's what will get them interested in bip148?
617 2017-05-25T19:55:27  <wumpus> #topic 0.14.2
618 2017-05-25T19:55:32  <jtimon> gmaxwell: the changes are just for providing warnngs in unkown deployments, like bip9 did
619 2017-05-25T19:55:37  <jonasschnelli> luke-jr: But core is consensus among devs for a reason. And I guess we mostly (never?) merged controversial consensus changes
620 2017-05-25T19:55:37  <gmaxwell> sdfkjs23: if users want 'neutral' they have a copy of GCC, they can write their own node.
621 2017-05-25T19:55:44  <petertodd> gmaxwell: +1
622 2017-05-25T19:55:46  <wumpus> let's do a 0.14.2 soon, even if just for the UPNP CVE
623 2017-05-25T19:55:47  <gmaxwell> (want neutral in that sense)
624 2017-05-25T19:55:53  <luke-jr> gmaxwell: we don't all believe that in this case. some of us admit that it's riskier to NOT enforce BIP148
625 2017-05-25T19:55:57  <wumpus> (of course we want to include some other fixes as well)
626 2017-05-25T19:56:04  <gmaxwell> sdfkjs23: sofware worth running is always opinionated in many ways, even if you don't realize it.
627 2017-05-25T19:56:07  <luke-jr> jonasschnelli: it's controversial to fail to enforce the softfork now
628 2017-05-25T19:56:26  <gmaxwell> wumpus: ack on 0.14.2 I think there are a couple other fairly modest fixes that could be backported.
629 2017-05-25T19:56:31  <cfields> I'd like to suggest a quick 0.14.2 for the upnp and recent peer visibility fix from marcos, along with whatever else has piled up in the meantime
630 2017-05-25T19:56:35  *** Joseph__ has quit IRC
631 2017-05-25T19:56:40  <cfields> heh, far too slow
632 2017-05-25T19:56:41  <sipa> sounds good to me
633 2017-05-25T19:56:53  <jonasschnelli> ack 0.14.2 ... there is also an important GUI fix
634 2017-05-25T19:56:54  <sdfkjs23> if that's what the main core developers want to say sure, but it's pretty clear that core is then the implementation as defined by this small group here, it is their vision and not open really to general community.
635 2017-05-25T19:56:58  <morcos> yes i think we could use more public notice on the peer visibility fix
636 2017-05-25T19:57:13  <wumpus> ok, please mark anything that should be backported to 0,14,2 as such
637 2017-05-25T19:57:19  <wumpus> (or ask us to do it)
638 2017-05-25T19:57:24  * jonasschnelli looking...
639 2017-05-25T19:57:41  <cfields> thanks, will do
640 2017-05-25T19:57:42  <morcos> even people who have connections, but are behind NAT are going to want to upgrade b/c eventually they wont' have connections (maybe.. i can't remember now)
641 2017-05-25T19:57:57  <sdaftuar> incoming connections*
642 2017-05-25T19:58:01  <morcos> yes sorry
643 2017-05-25T19:58:20  <gmaxwell> morcos: yes, so for backport the visiblity fix, cfields open PR with the connection stuff..
644 2017-05-25T19:58:48  <jonasschnelli> wumpus: https://github.com/bitcoin/bitcoin/pull/10231 (closed 0.14.2 milestone... needs backport)
645 2017-05-25T19:58:55  <jonasschnelli> (should apply IMO)
646 2017-05-25T19:59:28  <cfields> jonasschnelli: ah, good one if it backports cleanly
647 2017-05-25T19:59:34  <wumpus> jonasschnelli: that one is correctly marked, will port those in one go at some point (at lesat the ones that cleanly apply or need only small changes)
648 2017-05-25T19:59:35  <sipa> sdfkjs23: it's open source, anyone can repackage the software in any way they like, and i encourage everyone to do so (as long as they don't misrepresent the choices made)... but Bitcoin Core as a project has established some practices, and those include not accepting consensus rule changes without broad support and weighing the risks - it seems most people in this room now believe that bar isn't
649 2017-05-25T19:59:38  <luke-jr> sdfkjs23: in this case, it seems it's a minority of pessimistic devs holding back a softfork that the community largely wants and most of the devs are okay with merging, putting users who trust us collectively at a risk they shouldn't be :<
650 2017-05-25T19:59:41  <kanzure> sdfkjs23: open-source does not mean the project must "merge anything", it means you can compile whatever patches you want.
651 2017-05-25T19:59:41  <sipa> met for BIP148
652 2017-05-25T20:00:19  <wumpus> it's time
653 2017-05-25T20:00:21  <wumpus> #endmeeting
654 2017-05-25T20:00:21  <lightningbot> Meeting ended Thu May 25 20:00:21 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
655 2017-05-25T20:00:21  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-25-19.00.html
656 2017-05-25T20:00:21  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-25-19.00.txt
657 2017-05-25T20:00:21  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-25-19.00.log.html
658 2017-05-25T20:00:22  <jonasschnelli> sdfkjs23: with your argument we could not reject optional hard-fork proposals? Right?
659 2017-05-25T20:00:34  <gmaxwell> luke-jr: I think you're pusing the same kind of irresponsiblity as classic did, just this time it happens to be in favor of changes I want.  But I still reject it just the same, the purpose of the system is to come to consensus. Intentionally splitting it is in no ones interest except that of opponents to bitcoin.  If you had an order of magnitude more support than I've seen (and perhaps I've mi
660 2017-05-25T20:00:40  <gmaxwell> ssed some of it) OR months more to gain it-- I'd have a different view.
661 2017-05-25T20:00:52  <jtimon> luke-jr: sdfkjs23 not merging bip148 is not taking a position against segwit or uasf, it's just being conservative
662 2017-05-25T20:00:52  <luke-jr> gmaxwell: the split is LESS likely by merging BIP148; it isn't a hardfork
663 2017-05-25T20:01:08  <luke-jr> jtimon: it's not conservative when it increases the risk
664 2017-05-25T20:01:11  <sipa> luke-jr: i think you're insane
665 2017-05-25T20:01:22  <sdfkjs23> i've been following development for some time, i was under the false impression that core was intended to be the 'reference' client, just a generalized client that is neutral towards any consensus changes
666 2017-05-25T20:01:24  <jtimon> luke-jr: but we don't accept your premise
667 2017-05-25T20:01:26  <BlueMatt> luke-jr: wut
668 2017-05-25T20:01:27  <sipa> a split is less likely by merging a consensus change a few months agead of time?
669 2017-05-25T20:01:27  <paveljanik> luke-jr, in reality, it can even be much worse. People could signal UASF but not enforce it.
670 2017-05-25T20:01:28  <kanzure> gmaxwell: i think luke-jr is arguing that there is support for bip148 if default-off bip148 is merged. but only on condition of that sort of endorsement from core.  seems like a chicken-egg scenario, so perhaps caution is warranted.
671 2017-05-25T20:01:31  <luke-jr> great, now we get ad hominems as argument
672 2017-05-25T20:01:40  <gmaxwell> luke-jr: I don't think it's that precise to say that it isn't a hardfork.  In the sense that there is a nearly guarenteed hardfork (a miner violating it) which will happen.
673 2017-05-25T20:01:53  <sipa> luke-jr: apologies for the ad hominem... but i believe your argument it nonsense
674 2017-05-25T20:02:13  <gmaxwell> luke-jr: with softforks we have historically staged things to minimize the risk of block orphaning, so no hardforked blocks.
675 2017-05-25T20:02:33  <luke-jr> paveljanik: the signal is irrelevant
676 2017-05-25T20:02:40  <gmaxwell> kanzure: I haven't seen that.
677 2017-05-25T20:02:57  <kanzure> haven't seen evidence of community requiring endorsement from core by merging?
678 2017-05-25T20:03:05  <BlueMatt> luke-jr: if it were true that a vast, vast majority of users, businesses, and miners were not only supporting 148 but actually honestly committing to running it irrespective of what their peers do, maybe, but that is blatanly obviously not the case
679 2017-05-25T20:03:22  <paveljanik> luke-jr, yes. I also do not think where people get "large support" in the community for BIP148 etc.
680 2017-05-25T20:03:24  <jtimon> gmaxwell: I disagree, I see it as a controversial softfork
681 2017-05-25T20:03:30  <sipa> sdfkjs23: bitcoin core implements bitcoin's consensus rules... we need to make a judgement about what those rules are, as they can change and are not under our control
682 2017-05-25T20:03:31  <luke-jr> BlueMatt: it seems to be the case, perhaps minus businesses
683 2017-05-25T20:03:43  <gmaxwell> sdfkjs23: nonsense. we are not netural. E.g. We support Bitcoin and are not ambivilant towards things that would damage it.   Would you suggest the project also merge a switch that if set allows mtgox to make 600k bitcoin out of thin air to replace the losses, 'neutral' right?
684 2017-05-25T20:03:44  <luke-jr> BlueMatt: maybe it's not obviously the case, but it certainly isn't obviously NOT the case
685 2017-05-25T20:03:59  <morcos> luke-jr: even you think only 10% of nodes are running bip148 right?
686 2017-05-25T20:04:00  <gmaxwell> jtimon: you have a lot of weird opinions.
687 2017-05-25T20:04:03  <BlueMatt> luke-jr: would you like me to buy you a plane ticket so you can talk to people?
688 2017-05-25T20:04:04  <luke-jr> jtimon: Segwit itself is a controversial softfork; that's only a barrier for hardforks
689 2017-05-25T20:04:06  <BlueMatt> I'd be happy to
690 2017-05-25T20:04:22  <BlueMatt> you spend too much time on reddit and not talking to real people, I think
691 2017-05-25T20:04:23  <sdfkjs23> gmaxwell, you have a bad habit of using outrageous counter examples, they aren't analogous, please stick to the actual issues at hand
692 2017-05-25T20:04:23  <kanzure> BlueMatt: you can also talk with people over the internet. travel is not required.
693 2017-05-25T20:04:27  <luke-jr> morcos: so far, and that's in a short timeframe since binaries were released
694 2017-05-25T20:04:38  <luke-jr> BlueMatt: go talk to CodeShark, who reports a lot of support in NYC
695 2017-05-25T20:04:52  <gmaxwell> sdfkjs23: welcome to /ignore -- don't enter my channels and then lecture me on how I should debate.
696 2017-05-25T20:05:00  <kanzure> sdfkjs23: it's only outrageus for your position from your argument-- that was the point.
697 2017-05-25T20:05:02  <jtimon> gmaxwell: fair enough, but I think they aren't so weird, they are actually quite simple: what causes chain splits (apart from mistakes) are controversial rule changes, not whether they are hf or sf
698 2017-05-25T20:05:02  <BlueMatt> luke-jr: I live in NY, and strongly beg to differ
699 2017-05-25T20:05:15  <sdfkjs23> i'm being civil, and this isn't *your* channel this channel is for core development discussion
700 2017-05-25T20:05:28  *** gmaxwell has left #bitcoin-core-dev
701 2017-05-25T20:05:32  <sipa> sdfkjs23: and we've now far strayed from that topic, imho
702 2017-05-25T20:05:39  <sipa> none of this discussion belongs here
703 2017-05-25T20:05:43  <jcorgan> gentlemen, please
704 2017-05-25T20:05:50  <petertodd> sipa: quite correct
705 2017-05-25T20:05:51  <morcos> luke-jr: I think a lot of people support the concept of a UASF, but I actually made it a point to ask people wearing UASF hats what that meant to them..   And many actively preferred BIP149 or something else to BIP148
706 2017-05-25T20:05:51  <luke-jr> jtimon: what causes chain splits are negligent or malicious miners who fail to enforce the rules
707 2017-05-25T20:05:56  <sipa> if it's clear that BIP148 is accepted by the ecosystem, then obviously it will be implemented
708 2017-05-25T20:06:05  <sipa> usually we don't discuss consensus changes here at all
709 2017-05-25T20:06:07  <petertodd> morcos: indeed, I prefer bip149
710 2017-05-25T20:06:25  <luke-jr> morcos: preference isn't the question, though. BIP148 is happening, so the question is how many will support and go along with it
711 2017-05-25T20:06:26  <petertodd> luke-jr: we have to design systems that are robust to negligent and malicious miners
712 2017-05-25T20:06:36  <sdfkjs23> bip148 was brought up as the topic -- it appears the current argument against it (it is hard to follow because this changes very rapidly) is that there isn't enough 'community' support even though no one can argee on how to even measure it
713 2017-05-25T20:06:46  <luke-jr> petertodd: and BIP148 does, so long as people enforce it
714 2017-05-25T20:06:49  <jtimon> luke-jr: let's say halfthe users want to increase the monetary limit to 22 M but the other half doesn't: both chains will be mined and used
715 2017-05-25T20:07:01  <luke-jr> jtimon: that's not a softfork
716 2017-05-25T20:07:05  <sipa> sdfkjs23: a consensus change merged a few months before it happens is madness
717 2017-05-25T20:07:16  <sipa> we hardly have time to create a release in that time
718 2017-05-25T20:07:17  <luke-jr> sipa: yet you want to delay the merge longer?
719 2017-05-25T20:07:17  <jonasschnelli> sdfkjs23: this channel is specific for bitcoin-core (the client) development. General bitcoin protocol and consensus discussion shall happen in #bitcoin-dev
720 2017-05-25T20:07:18  <jtimon> that is a controversial hardfork, let me think of a controversial softfork example
721 2017-05-25T20:07:34  <sipa> luke-jr: my expectation is that bip148 will not have any effect, but i hope i'm wrong
722 2017-05-25T20:07:35  <sdfkjs23> a switch which woudl easily allow the community to opt in is now being rejected by 3 or 4 core developers because they find it dangerous
723 2017-05-25T20:07:39  <luke-jr> jtimon: in this case, it's not controversial anyway
724 2017-05-25T20:07:45  <jtimon> let's say half the users want to some aml softfork feature
725 2017-05-25T20:07:50  <sipa> sdfkjs23: then don't run Core; i beg you
726 2017-05-25T20:08:01  <luke-jr> at least not more controversial than Segwit itself
727 2017-05-25T20:08:13  <sipa> the maintainers of this software shouldn't determine what the network's consensus rules are
728 2017-05-25T20:08:13  <jtimon> luke-jr: to me it is controversial on grounds of the deployment plan alone
729 2017-05-25T20:08:20  <jtimon> like bip109 was
730 2017-05-25T20:09:09  <jtimon> I mean, that was controversial for other reasons too, but I think you get my point
731 2017-05-25T20:09:13  <luke-jr> I don't.
732 2017-05-25T20:09:15  <Lauda> which is why Core should add opt-in consensus proposals, not opt-out
733 2017-05-25T20:09:26  *** sipa has left #bitcoin-core-dev
734 2017-05-25T20:09:45  <morcos> luke-jr: sdfkjs23: Lets be clear, the resistance here isn't against UASF, or even a UASF for segwit.  It's against the particular activation methodology and schedule for BIP148.  It would behoove us all to try to build support from current BIP148 activists for 149 or another more cautious path
735 2017-05-25T20:10:13  <jonasschnelli> morcos: +1
736 2017-05-25T20:10:19  <jtimon> +1
737 2017-05-25T20:10:51  <kanzure> luke-jr: have you considered something like bip148 except with best chain tip selection weighted by segwit-signalling? instead of blanket rjeection of all blocks, you'd get competing long reorgs, which is arguably better than rejecting all blocks.
738 2017-05-25T20:11:08  <kanzure> wait, no, not better.
739 2017-05-25T20:11:10  *** grubles has quit IRC
740 2017-05-25T20:11:11  <luke-jr> What "activation methodology" besides UASF are you referring to?
741 2017-05-25T20:11:18  <kanzure> it's better so long as your confirmation threshold is longer than the reorg length :P
742 2017-05-25T20:11:19  <jcorgan> this is #bitcoin-dev or even #bitcoin territory, can we please get back to business
743 2017-05-25T20:11:37  <morcos> luke-jr: you could help, if you wanted to avoid a split, by making the argument that at this point BIP148 doesn't HAVE to happen.   Since you are such an advocate for 148, maybe others would take some advice from you if you felt another path safer
744 2017-05-25T20:11:42  <luke-jr> kanzure: I couldn't change BIP148 if I tried.
745 2017-05-25T20:11:50  <jonasschnelli> What jcorgan said...
746 2017-05-25T20:11:54  <kanzure> luke-jr: i said "something like bip148"
747 2017-05-25T20:11:58  <luke-jr> morcos: the ONLY way to avoid the split is to make sure BIP148 succeeds. It WILL happen. Nobody can change that.
748 2017-05-25T20:12:12  <morcos> ok. yeah i'm done discussing in this channel.  agreed.
749 2017-05-25T20:12:26  <jtimon> if I proposed something like bip148 but actiavting next week instead of august, would you ack that if some users support it?
750 2017-05-25T20:12:29  <luke-jr> and BIP149 is NOT safer anyway.
751 2017-05-25T20:12:50  <jtimon> of course it is, but yeah, let's go #bitcoin or something
752 2017-05-25T20:12:58  <luke-jr> jtimon: it's not "some users", it's a LOT of users, perhaps even a majority already
753 2017-05-25T20:13:41  <petertodd> luke-jr: chances are the majority of bitcoin users aren't on any social media at all you know...
754 2017-05-25T20:13:45  <jtimon> well, if "a LOT of users" supported my like-bip148-but-next-week proposal
755 2017-05-25T20:13:47  <petertodd> luke-jr: they may not even speak english
756 2017-05-25T20:14:01  *** grubles has joined #bitcoin-core-dev
757 2017-05-25T20:14:02  *** grubles has joined #bitcoin-core-dev
758 2017-05-25T20:14:39  *** sipa has joined #bitcoin-core-dev
759 2017-05-25T20:18:30  <paveljanik> luke-jr, from where you get "a lot of"?
760 2017-05-25T20:22:11  <instagibbs> discussion has been moved to #bitcoin, fwiw...
761 2017-05-25T20:28:48  <paveljanik> great. I can't follow such intense communication though :-)
762 2017-05-25T20:30:25  *** deego has joined #bitcoin-core-dev
763 2017-05-25T20:33:35  *** RubenSomsen has quit IRC
764 2017-05-25T20:43:35  *** dstadulis has joined #bitcoin-core-dev
765 2017-05-25T20:46:26  <morcos> sipa: are you interested in briefly describing how we'd do away with rescan?
766 2017-05-25T20:47:43  <sipa> morcos: requiring birthdays on all imports
767 2017-05-25T20:48:50  <sipa> and rescanning on demand, rather than explicitly
768 2017-05-25T20:51:55  <morcos> sipa: i've found that sometimes there is a need to import multiple keys in a short period.  forcing that to happen in a single importmulti call is a bit cumbersome
769 2017-05-25T20:52:43  <morcos> it can be easier to do a batch of all the imports with rescan false, and then later do 1 explicit rescan
770 2017-05-25T20:52:59  <morcos> anyway, thats just my opinion
771 2017-05-25T20:54:24  *** cryptapus_afk has quit IRC
772 2017-05-25T20:54:55  *** cryptapus has joined #bitcoin-core-dev
773 2017-05-25T20:55:04  *** cryptapus is now known as cryptapus_afk
774 2017-05-25T20:57:07  <sipa> morcos: rescanning could also move to a background job
775 2017-05-25T20:57:17  <sipa> which just restarts if needed
776 2017-05-25T20:57:33  <jtimon> that sounds simpler
777 2017-05-25T20:59:34  <jtimon> maybe a rescanning progress bar in the gui, seems very usable, and maybe in the rpc if you ask for imported stuff that needs rescaning and rescan is in progress, throw an error
778 2017-05-25T20:59:37  <morcos> i don't know about simpler, but yeah a better design
779 2017-05-25T20:59:52  <jtimon> yeah, I guess I meant simpler to use
780 2017-05-25T20:59:57  <da2ce7> On a slightly related topic, what contingency planning is there for the case that BIP148 has a non-zero hash-power?
781 2017-05-25T21:00:25  <da2ce7> That would force all the non-bip148 nodes to checkpoint for continued safe operation.
782 2017-05-25T21:00:38  <da2ce7> Is there a way to distribute such a checkpoint in a safe manner?
783 2017-05-25T21:01:15  <da2ce7> Or dose Bitcoin Core not want to merge in such code?
784 2017-05-25T21:01:24  <jtimon> if bip148 gets the hashrate majority we don't need to do anything
785 2017-05-25T21:01:46  <jtimon> we will reorg to their chain
786 2017-05-25T21:02:05  <da2ce7> jtimon, what happens if it has 10%.  Then all non-BIP148 nodes are zombie until they checkpoint.
787 2017-05-25T21:02:15  <sipa> ??
788 2017-05-25T21:02:34  <jtimon> no, no zombie, we go on with the majority chain which is also valid to us
789 2017-05-25T21:02:58  <da2ce7> This is fine, except the risk is asymmetrical.
790 2017-05-25T21:03:11  <sipa> da2ce7: i don't understand what risk you're even talking about
791 2017-05-25T21:03:34  <da2ce7> Because if at any date in the future the BIP148 chain overtakes, the non-BIP148 chain will be wiped out.
792 2017-05-25T21:03:46  <sipa> yes?
793 2017-05-25T21:04:33  <jtimon> that's what I said, if it gets the hashrate majority non-bip148 nodes will follow their chain, no problem
794 2017-05-25T21:04:57  <jtimon> I mean, apart from maybe a big reorg
795 2017-05-25T21:05:21  <da2ce7> If I disagreed with BIP148, I would checkpoint so my transactions wound't face the wipeout risk.  The same if for example if BIP148 as replaced with "evil softfork".
796 2017-05-25T21:05:38  <jtimon> I will wait and see with my node
797 2017-05-25T21:06:05  <sdfkjs23> a large reorg will cause issues for everyone not paying attention -- or anyone who goes along with cores deployment at this time. essentially core development team is handling the risk for the end client instead of allowing the client to manage the risk with a optional switch.
798 2017-05-25T21:06:23  <da2ce7> If Bitcoin XT was a soft-fork, I would checkpoint so that my node would NEVER reorg onto their chain, even if they gain a majority hashrate.
799 2017-05-25T21:06:29  <sipa> you can use invalidateblock
800 2017-05-25T21:06:38  <sipa> to force your node onto another chain
801 2017-05-25T21:07:50  <jtimon> oh, I didn't know that option
802 2017-05-25T21:08:33  *** Giszmo1 has quit IRC
803 2017-05-25T21:10:47  <da2ce7> My personal view is that the risks involved in BIP148 (a partial fix) are less than the risks covert CVE-2017-9230 continuing for a minimum of another 6mth.  So I have decided to run BIP148 on my nodes.
804 2017-05-25T21:12:51  <da2ce7> However it is always a trade-off of risks between mitigating a security vulnerability and the risks of the deployment of the security mitigation.
805 2017-05-25T21:12:53  <sdfkjs23> core should probably note in the release notes that running their software after august 1st could result in a large reorg
806 2017-05-25T21:16:41  <da2ce7> It is my view that the miners who don't use covert asicboost have a very strong incentive to support the swiftest deployment of any mitigation of CVE-2017-9230, including BIP148.  Hence, I expect the mining power for BIP148 to be similar to the mining power that signals for SegWit now.
807 2017-05-25T21:17:14  <da2ce7> At this hash-rate the changes of BIP148 failing are very small.
808 2017-05-25T21:18:39  <da2ce7> *chances.
809 2017-05-25T21:24:25  <da2ce7> I'm assuming that the miners who support SegWit are don't just support it out of the "good of their heart" but because it partly-mitigates a unfair competitive advantage against them.
810 2017-05-25T21:30:28  *** NewLiberty_ has quit IRC
811 2017-05-25T21:39:22  *** quark has joined #bitcoin-core-dev
812 2017-05-25T21:39:44  *** quark is now known as Guest26217
813 2017-05-25T21:39:59  <jtimon> I really feel I'm missing something here: https://github.com/bitcoin/bitcoin/commit/15ac75f65e6712339f13dd55b401d1b13a94ab41#commitcomment-22285343 and https://github.com/bitcoin/bitcoin/commit/c10271e46f9bba621c4a9943e53d87a792836be5
814 2017-05-25T21:41:02  <jtimon> I don't know much about the p2p part, but I really don't get it
815 2017-05-25T21:42:25  *** Guest26217 is now known as quarkionk
816 2017-05-25T21:43:16  *** quarkionk has quit IRC
817 2017-05-25T21:43:29  <da2ce7> I have been taken back by the core developers from the lack-of-response to my posts on AsicBoost, now CVE-2017-9230. I would have expected that there would be some sort of announcement about the risks and possible mitigation of an accepted Security Vulnerability.  - I have not received any negative feedback; In my mailing list post I received three positive responses.  - Yet, here I'm met with silence.
818 2017-05-25T21:44:06  <jtimon> oh, I didn't read this part in the bip: "This deployment is incompatible with the BIP9-segwit deployment and should not be run concurrently with it.", but I really don't understand why, please, help undesrtanding very welcomed
819 2017-05-25T21:47:06  <sipa> da2ce7: i don't know what you think we can do?
820 2017-05-25T21:48:08  <da2ce7> Well, at least say: "No you are stupid! The risk of another 6 to 9 mth of Covert ASICBOOST are far-less than the risks of being seen to support BIP148".
821 2017-05-25T21:48:40  <jtimon> I think we could deploy the proposed fix to covert asicboost with bip8 pretty fast, but maybe still not august
822 2017-05-25T21:48:51  <sipa> that's something the whole ecosystem needs to decide on
823 2017-05-25T21:49:13  <jtimon> I mean, miners could accelerate it, I mean the max deployment time
824 2017-05-25T21:50:43  <jtimon> but for segwit there's already an ongoing activation coordination deployed in many nodes
825 2017-05-25T21:52:34  <sipa> da2ce7: my personal opinion is that bip148 is reckless even if it succeeds...
826 2017-05-25T21:53:26  <sipa> it being a solution for some forms of asicboost is not nearly a reason to abandon safe practices
827 2017-05-25T21:53:45  <sipa> but that's my personal opinion, and others may have another
828 2017-05-25T21:53:47  <deego> newbie q: how can it just succeed. It has to first be committed, right? right now, it's just a B I "proposal", right?
829 2017-05-25T21:54:04  <Chris_Stewart_5> sipa: Would you support BIP148 that *only* solves covert ASICBOOST? No segwit stuff involved
830 2017-05-25T21:54:25  <sipa> Chris_Stewart_5: my problem with bip148 is its deployment, not its rule changes
831 2017-05-25T21:54:37  <jtimon> right, if that's the urgency let's do just that faster without taking unnecessary risks
832 2017-05-25T21:54:40  <sipa> it being about asicboost or segwit is orthogonal
833 2017-05-25T21:55:20  <sipa> deego: it's open source; bitcoin core is a software project, we don't decide or try to tell people what code they should run
834 2017-05-25T21:55:38  <Chris_Stewart_5> gotcha. I'm interested in solving covert asicboost first because I doubt we are going to get support from the mining majority to solve that, but I'm fairly confident the economic majority would support it
835 2017-05-25T21:55:40  <jtimon> I wouldn't be sure how to write the code, but it is said that the pre-segwit fix of covert asicboost is simple to implement
836 2017-05-25T21:55:45  <sipa> and it's not just a proposal... there is software out there that implements bip148
837 2017-05-25T21:55:54  <Chris_Stewart_5> if we are going to do some sort of UASF..
838 2017-05-25T21:56:21  <deego> sipa: i see, thanks
839 2017-05-25T21:56:46  <jtimon> Chris_Stewart_5: I'm all for adding a bip8 deployment for the covert asicboost fix, and its final activation can be earlier than nov 2017 I think
840 2017-05-25T21:57:26  <Chris_Stewart_5> jtimon: I like that idea. When is the next release scheduled for core?
841 2017-05-25T21:57:35  <da2ce7> For me, BIP148 is a reasonable for an emergency soft-fork. Are we fixing an emergency security vulnerability?  The more I study CVE-2017-9230, the more I'm inclined to say Yes.
842 2017-05-25T21:57:45  <jtimon> I mean, I say this because I expect a patch with very little changes, perhaps I'm being too optimistic
843 2017-05-25T21:58:31  <da2ce7> There is no faster potentially viable rollout of this partial mitigation.
844 2017-05-25T21:58:32  <jtimon> I believe 14.2 when it's ready, but you could even put it in a 14.3 if this is not ready by the time 14.2 is released
845 2017-05-25T21:58:49  <da2ce7> With core support it goes to about 100% viable.
846 2017-05-25T21:59:04  <sipa> da2ce7: i don't understand the need for emergency
847 2017-05-25T21:59:45  <da2ce7> Bitcoin isn't Bitcoin if there is only one miner.  AsicBoost has a exponentially growing advantage for miners who adopt it.
848 2017-05-25T21:59:54  <sipa> please
849 2017-05-25T22:00:13  <da2ce7> So it's effect starts off small, but as miners re-invest profit, the effect gets larger.
850 2017-05-25T22:00:15  <jtimon> I generally disregard claimed needs for emergency, but the simpler it is, the less conservative you need to be with deployment schedules I think
851 2017-05-25T22:00:16  <Chris_Stewart_5> da2ce7: I think it would be wise to separate the concerns of segwit and covert asicboost
852 2017-05-25T22:00:16  <sipa> don't use the word exponential where you just mean big
853 2017-05-25T22:00:43  <sipa> yes, the effect of asicboost may be terrible - or may not exist at all
854 2017-05-25T22:00:52  <sipa> and i would very much like to fix it
855 2017-05-25T22:01:13  <sipa> but not with a hasty patch that encourages forking the chain
856 2017-05-25T22:01:13  <jtimon> Chris_Stewart_5: I agree on separating concerns, I believe that was precisely what gmaxwell's proposal was about
857 2017-05-25T22:01:36  <sipa> we're better than that
858 2017-05-25T22:01:38  <da2ce7> I mean, if you have a constant factor advantage in mining, over time that advantage is exponential against your competition that doesn't have this constant factor advantage.  -  Unless my understanding of the gamer-theory is wrong.
859 2017-05-25T22:03:28  <jtimon> sipa: let's say (as an example, not an actual proposal) the asicboost fix is included in 14.3 with bip8, minimum activation by miners august, final activation dec 2017, would you say that is conservative enough?
860 2017-05-25T22:03:57  <sipa> jtimon: with clear community acceptance
861 2017-05-25T22:04:02  <Chris_Stewart_5> da2ce7: Are you talking about generically using the deployment mechanism specified in BIP148, or BIP148 itself? BIP148 only pertains to segwit IIRC
862 2017-05-25T22:04:17  <sipa> jtimon: it's not a boolean
863 2017-05-25T22:04:34  <sipa> jtimon: but the riskier a change is, the higher the bar for acceptance
864 2017-05-25T22:04:43  <da2ce7> Chris_Stewart_5: SegWit is the only well-tested partial-mitigation of CVE-2017-9230 I know of.
865 2017-05-25T22:04:56  <da2ce7> So I mean BIP148, activating SegWit.
866 2017-05-25T22:04:59  <sipa> and i think bip148 is both high risk, and with very unclear support
867 2017-05-25T22:05:36  <Chris_Stewart_5> sipa: Would worst case be similar to what happened a few years back with BIP66 (or 62)?
868 2017-05-25T22:05:48  <jtimon> sipa: fair enough, yeah, I'm all for community acceptance, maybe I'm over optimistic about the community wanting the covert asicboost fix
869 2017-05-25T22:07:16  <Chris_Stewart_5> da2ce7: Yeah, but I think we need to deal with realities of the baggage that comes along with segwit
870 2017-05-25T22:07:21  <jtimon> but from my conversations with users, it seems pretty clear to everyone that nobody would oppose to such a change unless is benefitting directly from covert asicboost, which nobody seem to claim
871 2017-05-25T22:07:36  <da2ce7> jtimon, I have no idea how the time to validate the asicboost fix faster than deploying SegWit.  The logical soft-fork afterwards with BIP 8 would be to make Witness Commitments non-voluntary.
872 2017-05-25T22:07:38  <Chris_Stewart_5> I think we all agree segwit is awesome, but we can't stall progress of the system anymore based on the deployment of segwit
873 2017-05-25T22:07:44  <sipa> i think segwit is much more widely accepted than asicboost being a problem
874 2017-05-25T22:08:29  <jtimon> da2ce7: I think gmaxwell described it in his proposal, but sadly I don't know how to translate his specification into code
875 2017-05-25T22:09:18  <jtimon> by it, I mean activate  asicboost fix before sw
876 2017-05-25T22:09:29  <Chris_Stewart_5> I don't think there has been any consensus rule changes since segwit has been deployed, I think fixing covert asicboost would be a good way to get that ball rolling again
877 2017-05-25T22:10:00  <da2ce7> Since SegWit is not controversial, we can deploy it as a partial mitigation of asicboost.
878 2017-05-25T22:10:22  <jtimon> Chris_Stewart_5: me too, but yeah, as sipa points out, assuming community support and reasonable dates
879 2017-05-25T22:12:04  <sipa> da2ce7: totally agree, i just don't think bip148 is a good or likely succesful way of doing that
880 2017-05-25T22:14:02  <da2ce7> sipa, do you think that my assumption that the miners who signal for SegWit now are likely doing it because they want the partial-fix to AsicBoost Deployed?  If so, would they reasonably support a BIP148 soft-fork?
881 2017-05-25T22:22:20  <sipa> da2ce7: i honestly don't know
882 2017-05-25T22:23:40  <da2ce7> this we can agree on. :)
883 2017-05-25T22:24:39  <da2ce7> I'm going to try and refine this assumption with more evidence.  With 33% mining support, I think that doing BIP148 is remarkably safe in the face of an active exploit.
884 2017-05-25T22:25:39  <sipa> 33% of mining support, excluding miners who already signal segwit?
885 2017-05-25T22:27:15  <da2ce7> I mean, 33% total.  For upgraded node, the remaining 67% doesn't exist.  - The network effects for a 33% soft-fork are huge. Because of the asymmetrical wipeout risk.
886 2017-05-25T22:27:26  *** EagleTM has joined #bitcoin-core-dev
887 2017-05-25T22:27:54  <da2ce7> The only risk is that the 67% explicitly attacks the smaller chain. However this is grounds for an immediate change of PoW.
888 2017-05-25T22:29:38  <Chris_Stewart_5> da2ce7: I don't think so. An immediate change of PoW for the majority of miners following the old rules? Seems rash to me
889 2017-05-25T22:30:35  <da2ce7> Chris_Stewart_5, no they are not following the old rules, they implement the soft-fork, except at the same time attack the smaller chain maybe by producing 0tx blocks.
890 2017-05-25T22:31:15  <da2ce7> This is what I mean by an 'explicit attack'.
891 2017-05-25T22:33:01  *** marcoagner has joined #bitcoin-core-dev
892 2017-05-25T22:33:30  <Chris_Stewart_5> da2ce7: So you would encourage an extended chain split, which could last forever? I don't think I would support that. We need to remain on one chain
893 2017-05-25T22:34:30  *** marsu has quit IRC
894 2017-05-25T22:34:47  <da2ce7> Chris_Stewart_5 for any other exploit I would encourage a chain split to fix the exploit, In this case is no different.  If the miners could make 2btc extra each block, then I would soft-fork with less than 50% to fix this bug.
895 2017-05-25T22:35:42  <da2ce7> Even if the miners +2btc chain could last for a longer time.
896 2017-05-25T22:41:42  *** belcher has joined #bitcoin-core-dev
897 2017-05-25T22:42:07  <da2ce7> I'm going to sleep now.  Goodnight all.
898 2017-05-25T22:56:38  *** Ylbam has joined #bitcoin-core-dev
899 2017-05-25T23:15:22  *** Squidicuz has joined #bitcoin-core-dev
900 2017-05-25T23:16:45  *** marcoagner has quit IRC
901 2017-05-25T23:38:38  *** jannes has quit IRC
902 2017-05-25T23:47:54  *** jchrome has joined #bitcoin-core-dev
903 2017-05-25T23:48:38  *** jchrome has quit IRC
904 2017-05-25T23:49:04  *** jchrome has joined #bitcoin-core-dev
905 2017-05-25T23:58:30  *** abpa has quit IRC