1 2017-04-27T00:00:09  *** goksinen has quit IRC
  2 2017-04-27T00:23:55  <cfields> well since we're all doing PRs for lots-of-changes-but-the-reason-isn't-obvious-until-the-next-PR, I suppose I'll do mine too.
  3 2017-04-27T00:24:20  *** marcoagner has quit IRC
  4 2017-04-27T00:24:53  *** marcoagner has joined #bitcoin-core-dev
  5 2017-04-27T00:24:59  <bitcoin-git> [bitcoin] theuni opened pull request #10285: net: refactor the connection process. moving towards async connections. (master...connman-events6) https://github.com/bitcoin/bitcoin/pull/10285
  6 2017-04-27T00:29:59  <fanquake> cfields Now just open two more, each with another 5 commits, all building on top of each other.
  7 2017-04-27T00:30:33  <cfields> fanquake: haha
  8 2017-04-27T00:31:40  <BlueMatt> cfields: to be fair, sipa objected to mine and so I'm gonna open the reason to get concept acks before merge of the dependant
  9 2017-04-27T00:32:58  <cfields> BlueMatt: sorry, that wasn't meant to be an insult. I've just been staring at this code for a week trying to figure out how to PR it. Just funny timing.
 10 2017-04-27T00:33:30  <BlueMatt> nor was mine, i was just pointing to the vague policy understanding i took from sipa's understanding of my own comments and figured I'd mention it as a possible suggestion
 11 2017-04-27T00:35:28  <sipa> as it seems to be a developing practice the past minutes in the vicinity of this communication channel to speak in relatively length sentences, i shall participate
 12 2017-04-27T00:35:42  <fanquake> cfields If you'd rather stare at some different code for a while; I've been tracking down a Windows issue that's blocking us from moving to latest ZMQ #9254
 13 2017-04-27T00:35:43  <gribble> https://github.com/bitcoin/bitcoin/issues/9254 | [depends] ZeroMQ 4.2.2 by fanquake · Pull Request #9254 · bitcoin/bitcoin · GitHub
 14 2017-04-27T00:36:14  <cfields> greg was here.
 15 2017-04-27T00:36:16  <cfields> (probably)
 16 2017-04-27T00:36:29  <cfields> fanquake: looking
 17 2017-04-27T00:36:56  <BlueMatt> sipa: is your understanding of the developing practice of relatively lengthy sentences that it shall eventually move towards policy, or is it only a temporal disturbance in the sentence length requirement understanding of the participants of the vicinity of this channel?
 18 2017-04-27T00:37:49  <fanquake> Also, noticed that libzmq is being relicensed.
 19 2017-04-27T00:38:09  <fanquake> https://github.com/zeromq/libzmq/issues/2376
 20 2017-04-27T00:38:26  <BlueMatt> would that effect us?
 21 2017-04-27T00:38:42  <BlueMatt> ahh, if anything positively
 22 2017-04-27T00:38:55  <cfields> neat
 23 2017-04-27T00:39:14  <BlueMatt> man i do not envy them in having to collect license grants from /everyone/
 24 2017-04-27T00:39:44  <cfields> BlueMatt: they usually take the route of /everyone with a significant contribution/
 25 2017-04-27T00:39:50  <BlueMatt> even still
 26 2017-04-27T00:40:17  <cfields> yea: "from each individual contributor who wrote a major piece of code in the development process of libzmq"
 27 2017-04-27T00:40:37  <cfields> no fun
 28 2017-04-27T00:41:02  <cfields> but on the bright side, hooray for github centralization! Must make this much easier.
 29 2017-04-27T00:41:09  <BlueMatt> f$cking internet...isp has peering presence but only uses it for IPv6...time to go annoy some noc operators
 30 2017-04-27T00:41:24  <BlueMatt> s/peering/ix peering/
 31 2017-04-27T00:41:42  <cfields> heh
 32 2017-04-27T00:41:57  <cfields> fanquake: that error is very confusing. seems to be in a system header
 33 2017-04-27T00:42:21  <cfields> my best guess is there's some define magic going on somewhere?
 34 2017-04-27T00:44:36  <sipa> BlueMatt: i for one am of the opinion - which i shall hold until presented with sufficient evidence of the contrary - that this is merely a temporary phase, which will soon be considered inconvenient and unnecessary
 35 2017-04-27T00:46:35  <fanquake> cfields Yea I'll have to look into it further.
 36 2017-04-27T00:46:38  <gmaxwell> sipa: are you trying to match my length of lines on IRC?  It will take you an awful long time to catch up to my average.
 37 2017-04-27T00:46:48  *** marcoagner has quit IRC
 38 2017-04-27T00:47:34  <fanquake> cfields While you're here, any significant plans depends wise for 0.15.0 ? I had a bunch of updates lined up, but haven't PR'd anything because I wanted to know what you were doing.
 39 2017-04-27T00:47:56  <cfields> fanquake: go for it! the qt overhaul is the big one
 40 2017-04-27T00:48:01  <cfields> fanquake: an osx toolchain bump
 41 2017-04-27T00:48:47  <cfields> fanquake: I'll be doing the toolchain builder as well, but that should just plug in to current depends without too much interruption
 42 2017-04-27T00:49:05  <sipa> gmaxwell: that is an impossible task, i might venture to state, and surely one should not let mere statistics in the history of an ephemeral communication channel like this guide one's actions
 43 2017-04-27T00:49:19  <gmaxwell> sipa: You are currently at an average length of 54 in this channel... compared to my 103.
 44 2017-04-27T00:49:59  <fanquake> cfields qt overhaul in regard to 5.8? I think they have some new "lite" build system. Will we see any benefit from that, I would have thought we were already pretty optimised?
 45 2017-04-27T00:50:19  <achow101> gmaxwell: while you're here, any update on the alert key stuff?
 46 2017-04-27T00:50:26  <BlueMatt> lol
 47 2017-04-27T00:50:35  <cfields> fanquake: split builds for host/target.
 48 2017-04-27T00:50:36  <BlueMatt> saw that one coming
 49 2017-04-27T00:51:01  <cfields> fanquake: and yea, we'll benefit from the lite thing. We just need to crank up a long list of -no-feature-X
 50 2017-04-27T00:51:16  <cfields> (they're supposed to actually work now, rather than just breaking stuff)
 51 2017-04-27T00:51:33  <sipa> perhaps i shall go construct a plugin module for my Internet Relay Chat client to implement nagle's algorithm for outgoing messages and make it combine multiple successive lines into one?
 52 2017-04-27T00:51:46  <fanquake> cfields No worries, I'll have a look at that as well.
 53 2017-04-27T00:53:21  <cfields> fanquake: have you tried to bisect the zmq change? There are a bunch of versions in between :(
 54 2017-04-27T00:54:24  <gmaxwell> achow101: not yet. personally I'm hoping for more old stuff to age off the network, since the key is explotable against that old stuff. (A fact we didn't really know until I did the final homework before releasing the key)
 55 2017-04-27T00:55:03  *** vicenteH` has joined #bitcoin-core-dev
 56 2017-04-27T00:55:59  <fanquake> Somewhat, I originally opened that PR with 4.2.0, then moved to 4.2.1, then 4.2.2, all seemed to have the same issue. So I'm assuming it's something that might have happened between 4.1.6 -> 4.2.0 . Which I wouldn't have tested yet. I'll post in that PR if I find anything.
 57 2017-04-27T00:56:27  <achow101> gmaxwell: will those vulnerabilities be disclosed or not until old nodes drop off the network?
 58 2017-04-27T00:56:44  *** vicenteH has quit IRC
 59 2017-04-27T00:57:21  <cfields> fanquake: so 4.1.6 works?
 60 2017-04-27T00:57:52  <gmaxwell> achow101: well I'd rather not post a howto then later post the key. :)
 61 2017-04-27T00:58:19  <gmaxwell> achow101: if you want to amuse yourself, why not go find the issues yourself. Make a write up. though I'd ask you to keep ir private for now, though ultimately that would be up to you.
 62 2017-04-27T00:58:53  <achow101> but I can't know if I actually found something without the key
 63 2017-04-27T00:59:45  <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10286: Call wallet notify callbacks in scheduler thread (without cs_main) (master...2017-01-wallet-cache-inmempool-4) https://github.com/bitcoin/bitcoin/pull/10286
 64 2017-04-27T01:00:27  <gmaxwell> achow101: well if you wanted to try it, you can change the key or rig the signature validation to return true for it.
 65 2017-04-27T01:01:10  <fanquake> cfields I can't remember if I tested it or just jumped straight to 4.2.0. I'll go back and take a look.
 66 2017-04-27T01:01:46  <cfields> fanquake: maybe try disabling the precompiled stuff?
 67 2017-04-27T01:02:07  <fanquake> The main windows related change from 4.1.6 seems to be https://github.com/zeromq/libzmq/issues/2091
 68 2017-04-27T01:03:16  <cfields> fanquake: aha! that could definitely be it. we may need to force the WINNT version
 69 2017-04-27T01:03:49  <achow101> gmaxwell: heh. social engineering failed :(. I will amuse myself and find those vulns
 70 2017-04-27T01:04:31  *** jcliff42 has quit IRC
 71 2017-04-27T01:04:35  <sipa> achow101: hahaha
 72 2017-04-27T01:05:39  <gmaxwell> hehe.
 73 2017-04-27T01:32:37  *** jcliff42 has joined #bitcoin-core-dev
 74 2017-04-27T01:34:00  <bitcoin-git> [bitcoin] jimmysong opened pull request #10287: [tests] Update Unit Test for addrman.h/addrman.cpp (master...test_addrman) https://github.com/bitcoin/bitcoin/pull/10287
 75 2017-04-27T01:36:04  *** tw2006 has joined #bitcoin-core-dev
 76 2017-04-27T01:40:23  *** tw2006 has quit IRC
 77 2017-04-27T01:43:28  *** goksinen has joined #bitcoin-core-dev
 78 2017-04-27T01:47:43  *** goksinen has quit IRC
 79 2017-04-27T01:49:16  *** annanay25 has quit IRC
 80 2017-04-27T01:49:18  *** Victor_sueca has joined #bitcoin-core-dev
 81 2017-04-27T01:49:25  *** annanay25 has joined #bitcoin-core-dev
 82 2017-04-27T01:52:11  *** Victorsueca has quit IRC
 83 2017-04-27T02:04:08  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 84 2017-04-27T02:24:02  *** jcliff42 has quit IRC
 85 2017-04-27T02:47:18  *** AaronvanW has quit IRC
 86 2017-04-27T03:03:17  *** Don_John has joined #bitcoin-core-dev
 87 2017-04-27T03:24:56  *** jcliff42 has joined #bitcoin-core-dev
 88 2017-04-27T03:24:58  *** tw2006 has joined #bitcoin-core-dev
 89 2017-04-27T03:29:05  *** jcliff42 has quit IRC
 90 2017-04-27T03:29:44  *** tw2006 has quit IRC
 91 2017-04-27T03:35:24  *** Azur has joined #bitcoin-core-dev
 92 2017-04-27T03:35:44  *** Azur has left #bitcoin-core-dev
 93 2017-04-27T03:39:57  <jl2012> on testnet I made a script to repeatedly send the same coin to myself every 15 second. When the tx chain becomes long enough, however, it stops working until confirmed. So there is a limit? Is it possible to bypass it?
 94 2017-04-27T03:40:43  <achow101> jl2012: the limit is 25 unconfirmed transactions in a chain
 95 2017-04-27T03:40:58  <achow101> you can raise it for your own node but not anyone else
 96 2017-04-27T03:41:41  <jl2012> so other miners won't mine beyond 25 txs by default?
 97 2017-04-27T03:41:52  <achow101> yes
 98 2017-04-27T03:42:06  <jl2012> thanks
 99 2017-04-27T03:45:54  *** Chris_Stewart_5 has quit IRC
100 2017-04-27T04:01:51  *** goksinen has joined #bitcoin-core-dev
101 2017-04-27T04:04:13  *** dodomojo has joined #bitcoin-core-dev
102 2017-04-27T04:06:28  <sipa> jl2012: there is also an option to make the wallet refuse to create transactions with coins in too long chains (though it avoids using them by default)
103 2017-04-27T04:07:43  *** goksinen has quit IRC
104 2017-04-27T04:12:17  *** goksinen has joined #bitcoin-core-dev
105 2017-04-27T04:14:17  *** moli_ has quit IRC
106 2017-04-27T04:14:55  *** moli_ has joined #bitcoin-core-dev
107 2017-04-27T04:15:37  *** dodomojo has quit IRC
108 2017-04-27T04:26:38  *** jcliff42 has joined #bitcoin-core-dev
109 2017-04-27T04:48:50  *** jcliff42 has quit IRC
110 2017-04-27T04:53:44  *** jtimon has quit IRC
111 2017-04-27T05:13:13  *** goksinen has quit IRC
112 2017-04-27T05:13:55  *** tw2006 has joined #bitcoin-core-dev
113 2017-04-27T05:18:22  *** tw2006 has quit IRC
114 2017-04-27T05:45:10  *** jcliff42 has joined #bitcoin-core-dev
115 2017-04-27T05:46:45  *** juscamarena has joined #bitcoin-core-dev
116 2017-04-27T05:46:53  *** juscamarena_ has joined #bitcoin-core-dev
117 2017-04-27T05:47:08  *** juscamarena is now known as Guest87345
118 2017-04-27T06:00:14  *** dermoth has quit IRC
119 2017-04-27T06:01:01  *** dermoth has joined #bitcoin-core-dev
120 2017-04-27T06:06:04  *** Guest87345 has quit IRC
121 2017-04-27T06:06:29  *** jcliff42 has quit IRC
122 2017-04-27T06:44:22  *** vicenteH` is now known as vicenteH
123 2017-04-27T07:00:40  *** BashCo has quit IRC
124 2017-04-27T07:00:48  *** goksinen has joined #bitcoin-core-dev
125 2017-04-27T07:02:54  *** tw2006 has joined #bitcoin-core-dev
126 2017-04-27T07:03:56  *** kexkey has quit IRC
127 2017-04-27T07:08:54  *** lightningbot has joined #bitcoin-core-dev
128 2017-04-27T07:12:23  *** berndj has quit IRC
129 2017-04-27T07:16:45  *** berndj has joined #bitcoin-core-dev
130 2017-04-27T07:19:53  *** BashCo has joined #bitcoin-core-dev
131 2017-04-27T07:25:53  *** Victor_sueca is now known as Victorsueca
132 2017-04-27T07:48:16  *** BashCo has quit IRC
133 2017-04-27T07:52:58  *** BashCo has joined #bitcoin-core-dev
134 2017-04-27T07:53:28  *** isis has quit IRC
135 2017-04-27T08:14:45  *** Ylbam has joined #bitcoin-core-dev
136 2017-04-27T08:16:19  *** timothy has joined #bitcoin-core-dev
137 2017-04-27T08:29:55  *** BashCo has quit IRC
138 2017-04-27T08:30:14  *** jannes has joined #bitcoin-core-dev
139 2017-04-27T08:30:39  *** mol has joined #bitcoin-core-dev
140 2017-04-27T08:31:29  *** kungfuant has quit IRC
141 2017-04-27T08:31:48  *** BashCo has joined #bitcoin-core-dev
142 2017-04-27T08:32:08  *** moli_ has quit IRC
143 2017-04-27T08:37:07  *** Don_John has quit IRC
144 2017-04-27T08:51:47  *** tw2006 has joined #bitcoin-core-dev
145 2017-04-27T08:55:51  *** Geovanni has joined #bitcoin-core-dev
146 2017-04-27T08:56:16  *** tw2006 has quit IRC
147 2017-04-27T09:43:23  *** goksinen has joined #bitcoin-core-dev
148 2017-04-27T09:48:12  *** goksinen has quit IRC
149 2017-04-27T09:57:15  *** jouke has quit IRC
150 2017-04-27T09:59:22  *** jouke has joined #bitcoin-core-dev
151 2017-04-27T10:11:05  *** mol has quit IRC
152 2017-04-27T10:16:13  *** moli_ has joined #bitcoin-core-dev
153 2017-04-27T10:35:39  *** jtimon has joined #bitcoin-core-dev
154 2017-04-27T10:41:04  *** tw2006 has joined #bitcoin-core-dev
155 2017-04-27T10:45:54  *** tw2006 has quit IRC
156 2017-04-27T10:56:03  *** laurentmt has joined #bitcoin-core-dev
157 2017-04-27T10:56:45  *** laurentmt has quit IRC
158 2017-04-27T11:32:05  *** goksinen has joined #bitcoin-core-dev
159 2017-04-27T11:33:52  *** Guyver2 has joined #bitcoin-core-dev
160 2017-04-27T11:36:56  *** goksinen has quit IRC
161 2017-04-27T11:37:07  *** AaronvanW has joined #bitcoin-core-dev
162 2017-04-27T11:42:07  *** kexkey has joined #bitcoin-core-dev
163 2017-04-27T11:49:47  *** tw2006 has joined #bitcoin-core-dev
164 2017-04-27T12:04:04  *** Geovanni has quit IRC
165 2017-04-27T12:26:21  *** goksinen has joined #bitcoin-core-dev
166 2017-04-27T12:28:37  *** SopaXorzTaker has joined #bitcoin-core-dev
167 2017-04-27T12:30:22  *** Victorsueca has quit IRC
168 2017-04-27T12:31:04  *** goksinen has quit IRC
169 2017-04-27T12:34:33  *** NewLiberty has joined #bitcoin-core-dev
170 2017-04-27T12:35:13  *** NewLiberty has joined #bitcoin-core-dev
171 2017-04-27T12:46:01  <fanquake> Is there a dev meeting tonight?
172 2017-04-27T12:51:18  *** Ona has joined #bitcoin-core-dev
173 2017-04-27T12:53:14  <jonasschnelli> fanquake: Yes.
174 2017-04-27T12:53:28  <jonasschnelli> fanquake: in 6h and 7min.
175 2017-04-27T12:54:06  <fanquake> jonasschnelli 3am :|
176 2017-04-27T12:54:18  <jonasschnelli> fanquake: hah. Yeah. Hard for OZ.
177 2017-04-27T13:08:48  *** Victorsueca has joined #bitcoin-core-dev
178 2017-04-27T13:17:51  *** Chris_Stewart_5 has joined #bitcoin-core-dev
179 2017-04-27T13:25:59  <wumpus> yes the time is not exactly ideal for asia/OZ
180 2017-04-27T13:43:27  *** paveljanik has quit IRC
181 2017-04-27T13:45:09  *** NewLiberty has joined #bitcoin-core-dev
182 2017-04-27T13:46:20  *** nu11p7r has quit IRC
183 2017-04-27T13:50:38  *** d_t has joined #bitcoin-core-dev
184 2017-04-27T13:53:09  *** goksinen has joined #bitcoin-core-dev
185 2017-04-27T14:07:05  *** Chris_Stewart_5 has quit IRC
186 2017-04-27T14:22:26  *** mol has joined #bitcoin-core-dev
187 2017-04-27T14:25:52  *** moli_ has quit IRC
188 2017-04-27T14:46:05  *** altoz_ is now known as altoz
189 2017-04-27T14:53:22  *** Victorsueca has quit IRC
190 2017-04-27T14:54:31  *** Victorsueca has joined #bitcoin-core-dev
191 2017-04-27T14:58:04  *** BashCo has quit IRC
192 2017-04-27T15:00:05  *** BashCo has joined #bitcoin-core-dev
193 2017-04-27T15:42:34  *** laurentmt has joined #bitcoin-core-dev
194 2017-04-27T15:42:49  *** BashCo has quit IRC
195 2017-04-27T15:44:04  *** BashCo has joined #bitcoin-core-dev
196 2017-04-27T15:44:53  *** bsm1175321 has joined #bitcoin-core-dev
197 2017-04-27T15:49:14  *** bsm1175321 has quit IRC
198 2017-04-27T15:53:15  *** abpa has joined #bitcoin-core-dev
199 2017-04-27T16:08:05  *** BashCo has quit IRC
200 2017-04-27T16:21:25  *** goksinen has quit IRC
201 2017-04-27T16:24:46  *** BashCo has joined #bitcoin-core-dev
202 2017-04-27T16:25:52  <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/47535d7c3ec7...a550f6e415fd
203 2017-04-27T16:25:52  <bitcoin-git> bitcoin/master 3edbd79 Alex Morcos: cleanup: reduce to one GetMinimumFee call signature
204 2017-04-27T16:25:53  <bitcoin-git> bitcoin/master a550f6e Pieter Wuille: Merge #10283: Cleanup: reduce to one GetMinimumFee call signature...
205 2017-04-27T16:26:15  <bitcoin-git> [bitcoin] sipa closed pull request #10283: Cleanup: reduce to one GetMinimumFee call signature (master...oneGetMinimumFee) https://github.com/bitcoin/bitcoin/pull/10283
206 2017-04-27T16:41:58  *** Victorsueca has quit IRC
207 2017-04-27T16:42:23  *** goksinen has joined #bitcoin-core-dev
208 2017-04-27T16:43:05  *** Victorsueca has joined #bitcoin-core-dev
209 2017-04-27T16:46:40  *** goksinen has quit IRC
210 2017-04-27T16:59:59  *** timothy has quit IRC
211 2017-04-27T17:21:27  *** jtimon has quit IRC
212 2017-04-27T17:23:32  *** goksinen has joined #bitcoin-core-dev
213 2017-04-27T17:28:59  *** goksinen has quit IRC
214 2017-04-27T17:38:10  *** laurentmt has quit IRC
215 2017-04-27T17:44:43  *** goksinen has joined #bitcoin-core-dev
216 2017-04-27T17:45:09  *** Guyver2 has quit IRC
217 2017-04-27T17:49:35  *** goksinen has quit IRC
218 2017-04-27T17:55:30  *** afk11 has quit IRC
219 2017-04-27T17:55:45  *** afk11 has joined #bitcoin-core-dev
220 2017-04-27T18:04:26  *** goksinen has joined #bitcoin-core-dev
221 2017-04-27T18:13:00  *** jcliff42 has joined #bitcoin-core-dev
222 2017-04-27T18:20:01  *** tw2006 has quit IRC
223 2017-04-27T18:20:37  *** tw2006 has joined #bitcoin-core-dev
224 2017-04-27T18:22:14  *** jtimon has joined #bitcoin-core-dev
225 2017-04-27T18:26:12  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a550f6e415fd...4c924011f535
226 2017-04-27T18:26:12  <bitcoin-git> bitcoin/master b51aaf1 practicalswift: Remove unused C++ code not covered by unit tests
227 2017-04-27T18:26:13  <bitcoin-git> bitcoin/master 4c92401 Wladimir J. van der Laan: Merge #10075: Remove unused C++ code not covered by unit tests...
228 2017-04-27T18:26:32  <bitcoin-git> [bitcoin] laanwj closed pull request #10075: Remove unused C++ code not covered by unit tests (master...unused) https://github.com/bitcoin/bitcoin/pull/10075
229 2017-04-27T18:27:10  *** goksinen has quit IRC
230 2017-04-27T18:27:43  *** SopaXorzTaker has quit IRC
231 2017-04-27T18:33:52  *** altoz has quit IRC
232 2017-04-27T18:34:51  *** altoz has joined #bitcoin-core-dev
233 2017-04-27T18:36:22  *** altoz has joined #bitcoin-core-dev
234 2017-04-27T18:37:27  *** altoz has joined #bitcoin-core-dev
235 2017-04-27T18:38:22  *** trippysa1mon has joined #bitcoin-core-dev
236 2017-04-27T18:38:58  *** jonasschnelli has quit IRC
237 2017-04-27T18:38:58  *** trippysalmon has quit IRC
238 2017-04-27T18:38:58  *** thermoman has quit IRC
239 2017-04-27T18:39:04  *** jonasschnelli_ has joined #bitcoin-core-dev
240 2017-04-27T18:39:11  *** thermoman has joined #bitcoin-core-dev
241 2017-04-27T18:40:30  *** jonasschnelli_ has quit IRC
242 2017-04-27T18:40:42  *** jonasschnelli has joined #bitcoin-core-dev
243 2017-04-27T18:40:58  *** jonasschnelli has joined #bitcoin-core-dev
244 2017-04-27T18:49:04  *** Giszmo has joined #bitcoin-core-dev
245 2017-04-27T18:56:39  *** belcher has quit IRC
246 2017-04-27T18:59:27  *** jcliff42 has quit IRC
247 2017-04-27T19:01:09  <luke-jr> meeting?
248 2017-04-27T19:01:21  <jonasschnelli> Yes
249 2017-04-27T19:01:24  <petertodd> yup
250 2017-04-27T19:01:28  <kanzure> yes
251 2017-04-27T19:02:00  <BlueMatt> wumpus, wherefor art thou wumpus
252 2017-04-27T19:02:01  <wumpus> #startmeeting
253 2017-04-27T19:02:01  <lightningbot> Meeting started Thu Apr 27 19:02:01 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
254 2017-04-27T19:02:01  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
255 2017-04-27T19:02:31  <jonasschnelli> I have two topic proposals: "hd-restore" and "limited NODE_NETWORK (NODE_NETWORK_LIMITED) signaling"
256 2017-04-27T19:02:33  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt
257 2017-04-27T19:02:33  <wumpus> instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 instagibbs
258 2017-04-27T19:02:39  <kanzure> hi.
259 2017-04-27T19:02:44  <instagibbs> here
260 2017-04-27T19:02:47  <cfields> hi
261 2017-04-27T19:03:03  *** edcba has joined #bitcoin-core-dev
262 2017-04-27T19:03:17  <wumpus> #topic hd-restore (jonasschnelli)
263 2017-04-27T19:03:17  *** praxeology has joined #bitcoin-core-dev
264 2017-04-27T19:03:21  <jtimon> suggested topic: summary of BlueMatt's overall plan for libconsensu
265 2017-04-27T19:03:41  <kanzure> is this 10240?
266 2017-04-27T19:03:45  <jtimon> if BlueMatt wants of course
267 2017-04-27T19:03:47  <BlueMatt> jtimon: k, can share. jonasschnelli you have the floor :)
268 2017-04-27T19:03:50  <jonasschnelli> Re. HD restore. I'm not sure if we should always try to restore funds or if we should check for the bestblock and compare it to the chain tip and only then restore
269 2017-04-27T19:04:12  <jonasschnelli> The main stuff is in #10240
270 2017-04-27T19:04:13  <gribble> https://github.com/bitcoin/bitcoin/issues/10240 | [WIP] Add basic HD wallet restore functionality by jonasschnelli · Pull Request #10240 · bitcoin/bitcoin · GitHub
271 2017-04-27T19:04:24  <instagibbs> ack libconsensus discussion
272 2017-04-27T19:04:34  <jonasschnelli> But I think we should only restore if the wallet's bestblock lacks behind
273 2017-04-27T19:04:35  <instagibbs> oh sorry, didnt see topic set already :)
274 2017-04-27T19:04:44  <jonasschnelli> Because...
275 2017-04-27T19:04:51  <jonasschnelli> Encrypted wallets may need to unlock
276 2017-04-27T19:05:06  <jonasschnelli> And also for performance / log reasons
277 2017-04-27T19:05:09  <BlueMatt> jonasschnelli: i assumed we'd always keep a buffer of X pubkeys around
278 2017-04-27T19:05:15  <BlueMatt> because you may have wallet "forks"
279 2017-04-27T19:05:21  <BlueMatt> not sure what you mean by "restore"?
280 2017-04-27T19:05:28  <BlueMatt> (feel free to tell me to shut up and go read the pr)
281 2017-04-27T19:05:55  <jonasschnelli> BlueMatt: By restore I mean always check the keypool keys and auto-extend (if only 50 [TBD] keys are left, topup to 100 [TBD]
282 2017-04-27T19:05:57  <kanzure> looks like it's re: finding relevant transactions
283 2017-04-27T19:06:19  <jonasschnelli> If we always restore... we would need to unlock encrypted wallet...
284 2017-04-27T19:06:29  <jonasschnelli> (more often)
285 2017-04-27T19:06:30  <sipa> jonasschnelli: my assumption was that we'd always mark seen keys as used (and we should do that independently)
286 2017-04-27T19:06:43  <sipa> jonasschnelli: we should also always extend the keypool when we can
287 2017-04-27T19:06:54  <BlueMatt> jonasschnelli: ah, you mean like "when do we extend keypool to watch buffer"?
288 2017-04-27T19:06:56  <jonasschnelli> sipa: Yes. But what if we can't?
289 2017-04-27T19:06:59  <sipa> jonasschnelli: and if the keypool runs out in a non-interactive setting, shutdown
290 2017-04-27T19:07:00  <achow101> If it needs to generate keys you could prompt the user right when the main gui pops up
291 2017-04-27T19:07:15  <jonasschnelli> And whats a save gap limit? I would assume >100 keys.
292 2017-04-27T19:07:18  <BlueMatt> another option would be to stop updating best seen block
293 2017-04-27T19:07:29  <BlueMatt> and then kick off a background rescan-from-that-height when wallet next unlocks
294 2017-04-27T19:07:38  <jonasschnelli> If someone has handed out 101 keys and only the position 101 has payed...
295 2017-04-27T19:07:38  <BlueMatt> if gap goes under some threshold
296 2017-04-27T19:07:45  <kanzure> yea, trigger on next unlock is better than achow101 popup
297 2017-04-27T19:07:58  <BlueMatt> achow101: needs to be cli-compatible, though
298 2017-04-27T19:08:03  <jonasschnelli> achow101: GUI is solvable..
299 2017-04-27T19:08:07  <sipa> jonasschnelli: if we fix the bdb flushing stupidity, generating new keys becomes very cheap
300 2017-04-27T19:08:11  <jonasschnelli> I don't know how to solve the non GUI way
301 2017-04-27T19:08:20  <sipa> jonasschnelli: shutdown. make sure it doesn't happen
302 2017-04-27T19:08:21  <achow101> jonasschnelli: how would you hand out 101 keys if the 101st wasn't generated yet?
303 2017-04-27T19:08:29  <BlueMatt> jonasschnelli: i mean keys are cheap, can do 250 or 500 or something crazy
304 2017-04-27T19:08:35  <jonasschnelli> sipa: But how to unlock during init in the first place?
305 2017-04-27T19:08:40  <sipa> jonasschnelli: you can't
306 2017-04-27T19:08:47  <BlueMatt> jonasschnelli: but cant we just use the keypool number now as the "buffer"?
307 2017-04-27T19:08:48  <sipa> ah, i see what you mean
308 2017-04-27T19:08:50  <jonasschnelli> But right after we rescan and sync
309 2017-04-27T19:09:07  <BlueMatt> and, like, the lower bound should be like keypool count / 2
310 2017-04-27T19:09:21  <BlueMatt> sipa: you cant just shutdown mid-sync
311 2017-04-27T19:09:30  <jonasschnelli> BlueMatt: Yes. But with the current 100 default, we would enforce a shutdown on startup for encrypted wallets
312 2017-04-27T19:09:33  <sipa> BlueMatt: why not?
313 2017-04-27T19:09:47  <sipa> it's an error condition that we cannot recover from
314 2017-04-27T19:09:48  * BlueMatt re-proposes that we stop updating wallet's best height if our keypool falls below keypool / 2
315 2017-04-27T19:09:56  <BlueMatt> and then rescan when keypool next gets filled
316 2017-04-27T19:09:57  <sipa> hmm
317 2017-04-27T19:10:05  <jonasschnelli> IMO an explicit "restore-mode" with a "unlock during startup" (not sure how) would be preferable for encrypted wallets
318 2017-04-27T19:10:12  <sipa> BlueMatt: you should also stop pruning
319 2017-04-27T19:10:20  <BlueMatt> sipa: yes, that would be my major reservation
320 2017-04-27T19:10:29  <BlueMatt> jonasschnelli: not sure you realistically can in a daemon setting
321 2017-04-27T19:10:40  <jonasschnelli> is stdin a total nogo? *duck*
322 2017-04-27T19:10:44  <sipa> so i guess we need a special "stop syncing" mode that we go into when the keypool runs out
323 2017-04-27T19:10:49  <sipa> jonasschnelli: there is no stdin with -daemon
324 2017-04-27T19:10:51  <BlueMatt> sipa: i guess you can stop pruning and if disk fills it will do the shutdown part for you :p
325 2017-04-27T19:10:58  <sipa> BlueMatt: ugh
326 2017-04-27T19:11:02  <BlueMatt> yea, i know
327 2017-04-27T19:11:03  <jonasschnelli> sipa: Yes. But at least you could run in non-daemon headless
328 2017-04-27T19:11:07  <wumpus> yes a blocking mode makes sense in that case
329 2017-04-27T19:11:24  <BlueMatt> ok, so blocking in pruning mode, rescan-later in non-pruning mode?
330 2017-04-27T19:11:34  <wumpus> and no, stdin is not an option, there should be no expectation with bitcoind that there's anyone at the terminal
331 2017-04-27T19:11:35  <jonasschnelli> If you run with an encrypted wallet and the bestblock lacks behind, shutdown if we can't unlock over stdin
332 2017-04-27T19:11:52  <BlueMatt> no stdin, just shutdown
333 2017-04-27T19:11:56  <jonasschnelli> wumpus: So we have only RPC to unlock?
334 2017-04-27T19:11:57  <wumpus> everything should be scriptable
335 2017-04-27T19:11:57  <BlueMatt> jonasschnelli: but only in prune mode
336 2017-04-27T19:12:07  <wumpus> jonasschnelli: yes
337 2017-04-27T19:12:14  <jonasschnelli> But how do we unlock/extend before we sync?
338 2017-04-27T19:12:25  <wumpus> just wait until the wallet is unlocked to start
339 2017-04-27T19:12:25  <jonasschnelli> rpc starts after chain sync
340 2017-04-27T19:12:31  <sipa> jonasschnelli: you go into a blocking mode, and you continue after walletunlock
341 2017-04-27T19:12:37  <wumpus> right
342 2017-04-27T19:12:52  <sipa> jonasschnelli: and no, no stdin ever
343 2017-04-27T19:13:03  <jonasschnelli> but can we block the sync and wait for RPC wallettunlock?
344 2017-04-27T19:13:09  <sipa> jonasschnelli: why not?
345 2017-04-27T19:13:15  <wumpus> sure
346 2017-04-27T19:13:18  <jonasschnelli> (without changing too much)?
347 2017-04-27T19:13:18  <BlueMatt> ProcessNewBlock { return false; }
348 2017-04-27T19:13:31  <jonasschnelli> okay... sounds good. Need to take a closer look.
349 2017-04-27T19:13:33  <sipa> add a function to validation.h to let the core know that validation cannot progress
350 2017-04-27T19:13:42  <BlueMatt> maybe stop net too under the current net-pause stuff
351 2017-04-27T19:13:47  <sipa> right
352 2017-04-27T19:13:53  <jonasschnelli> Good point.
353 2017-04-27T19:13:54  <kanzure> should it shutdown if wallet is not unlocked within a certain time period? if it's not shutdown users might expect it to still be syncing.
354 2017-04-27T19:14:00  <jonasschnelli> Next question: what's a sane gap limit?
355 2017-04-27T19:14:02  <wumpus> the only precondition for getting out of Init() is that the genesis block has been processed, everything else can be delayed
356 2017-04-27T19:14:04  <jonasschnelli> 100 seems way to low to me
357 2017-04-27T19:14:16  <sipa> jonasschnelli: fix bdb flushing insanity, and raise it to 1000 or 10000
358 2017-04-27T19:14:17  <BlueMatt> jonasschnelli: keypool / 2?
359 2017-04-27T19:14:18  <jonasschnelli> (risk of losing funds is involved)
360 2017-04-27T19:14:24  <BlueMatt> and we can bump keypool to 500
361 2017-04-27T19:14:25  <achow101> how would you know that it is blocking and you need to walletunlock?
362 2017-04-27T19:14:29  <kanzure> jonasschnelli: i think the answer will depend on performance.  also, do you really want to encourage users to use gaps? the answer might be yes..
363 2017-04-27T19:15:06  <kanzure> achow101: yes that is why i suggested shutdown after a certain period of time. users might not realize that syncing is stopped otherwise.
364 2017-04-27T19:15:15  <jonasschnelli> there my next concern pops up... all user will always have to have 500+ keypools. In an explicit restore more, only then we would need to have a large pool
365 2017-04-27T19:15:30  <sipa> jonasschnelli: who cares about 500 keys'
366 2017-04-27T19:15:41  <sipa> it's 16 kB of memory
367 2017-04-27T19:15:52  <sipa> well, some small constant multiple of that
368 2017-04-27T19:15:52  <kanzure> i thought derivation time was the bottleneck?
369 2017-04-27T19:15:56  <jonasschnelli> Hmm... yes.
370 2017-04-27T19:15:57  *** tw2006 has quit IRC
371 2017-04-27T19:16:08  <jonasschnelli> If it just would be a pubkey and H160 onyl.. but it's also the privatre key! hell
372 2017-04-27T19:16:17  <wumpus> the memory usage of keys is not an issue, just generation time (and that's only due to bdb stupidity)
373 2017-04-27T19:16:33  <sipa> kanzure: we can do ~10000 derivation steps per second on a single thread on modern CPU
374 2017-04-27T19:16:37  *** tw2006 has joined #bitcoin-core-dev
375 2017-04-27T19:16:42  <kanzure> is that with bdb madness? :)
376 2017-04-27T19:16:46  <sipa> and maybe 5 due to BDB flushing
377 2017-04-27T19:16:47  <wumpus> calling fsync after every key is not a good idea, it should create the entire keypool refill in one transaction
378 2017-04-27T19:16:53  <luke-jr> IMO automatic pruning should probably have as a precondition that the wallet has updated to the block being pruned, if it doesn't already; then the wallet can just set its criteria for processing
379 2017-04-27T19:17:20  <luke-jr> and if auto-pruning is enabled, block validation (safely) when the size is hit, until it can prune further?
380 2017-04-27T19:17:30  <sipa> luke-jr: agree, but that's not a concern right now as the wallet updates synchronously... with BlueMatt's coming changes maybe that changes
381 2017-04-27T19:17:42  <BlueMatt> yes, that changes, but it still shouldnt be too slow
382 2017-04-27T19:17:48  <jonasschnelli> With HD, there would also be no need for the disk-keypool for unencrypted wallets,.. it's just legacy. We could always fill up in-mem
383 2017-04-27T19:18:02  <BlueMatt> if your wallet falls behind consensus, you have a very, very large wallet
384 2017-04-27T19:18:13  <BlueMatt> (and should pause sync anyway)
385 2017-04-27T19:18:39  <sipa> right, the wallet should have the ability to pause syncing or prevent pruning
386 2017-04-27T19:18:49  <jonasschnelli> Conclusion: a) always scan keypool and topup, b) extend keypool and gap-limit to 500+, c) block when encrypted until RPC unlocked.
387 2017-04-27T19:19:11  <sipa> sgtm
388 2017-04-27T19:19:17  <wumpus> yes
389 2017-04-27T19:19:18  <jonasschnelli> thanks. That was effective
390 2017-04-27T19:19:32  <wumpus> #topic libconsensus (BlueMatt)
391 2017-04-27T19:19:51  <BlueMatt> yes, so obviously this is all based on #771
392 2017-04-27T19:19:53  <gribble> https://github.com/bitcoin/bitcoin/issues/771 | CBlockStore by TheBlueMatt · Pull Request #771 · bitcoin/bitcoin · GitHub
393 2017-04-27T19:19:59  <BlueMatt> :)
394 2017-04-27T19:20:08  <jonasschnelli> (19 Jan 2012)
395 2017-04-27T19:20:22  <wumpus> archeology?
396 2017-04-27T19:20:23  <BlueMatt> but pr #10279 creates a CChainState class which will hold things like mapBlockIndex chainActive, etc, etc
397 2017-04-27T19:20:24  <gribble> https://github.com/bitcoin/bitcoin/issues/10279 | Add a CChainState class to validation.cpp to take another step towards clarifying internal interfaces by TheBlueMatt · Pull Request #10279 · bitcoin/bitcoin · GitHub
398 2017-04-27T19:20:40  <BlueMatt> and have ProcessNewBlock Activate..., Connect, etc, etc, etc
399 2017-04-27T19:20:53  <sipa> yay
400 2017-04-27T19:21:04  <BlueMatt> long-term that class' public interface will be libbitcoinconsensus, but right now its really just to clean up internal interfaces within validation.cpp
401 2017-04-27T19:21:13  <wumpus> sounds good to me
402 2017-04-27T19:21:29  <BlueMatt> that class would get a pcoinsTip and related stuff to write/read blocks from disk
403 2017-04-27T19:21:39  <BlueMatt> and then only be able to call that and pure functions (eg script validation)
404 2017-04-27T19:21:45  <jtimon> BlueMatt: so what's the next thing we will be able to expose with these changes?
405 2017-04-27T19:21:51  <cfields> ooh, +1
406 2017-04-27T19:21:54  <BlueMatt> there is a bit of cleanup in the pr, but mostly its just moving into a class
407 2017-04-27T19:22:06  <BlueMatt> jtimon: expose-wise? probably nothing for like 2 more releases "until its ready"
408 2017-04-27T19:22:15  * BlueMatt is not a fan of libbitcoinconsensus being a grab-bag of random verification functions
409 2017-04-27T19:22:21  <jtimon> the class itself? mhmm
410 2017-04-27T19:22:32  <BlueMatt> i mean "the class"  but I assume via a C API
411 2017-04-27T19:24:01  <BlueMatt> any other questions? or next topic?
412 2017-04-27T19:24:08  <jtimon> yes, I know, and I'm very open to see what you want to expose, even if I don't renounce to the verifyWithoutChangingState x {block, header, tx, script} + getFlags() vision I had
413 2017-04-27T19:24:38  <jtimon> but that's helpful, I can just imagine the class being exposed as a c api
414 2017-04-27T19:25:15  <wumpus> not directly, it's just another step toward being able to
415 2017-04-27T19:25:36  <wumpus> #topic limited NODE_NETWORK (NODE_NETWORK_LIMITED) signaling (jonasschnelli)
416 2017-04-27T19:25:57  <petertodd> wumpus: +1
417 2017-04-27T19:25:57  <jonasschnelli> I wanted to ask if a first step to announce pruned NODE_NETWORK would make sense.
418 2017-04-27T19:26:04  <jonasschnelli> Could be NODE_NETWORK_LIMITED
419 2017-04-27T19:26:11  <sipa> jonasschnelli: what would it entail?
420 2017-04-27T19:26:14  <jonasschnelli> The only requirement is relay, and serve the last 144 blocks
421 2017-04-27T19:26:21  <petertodd> jonasschnelli: ACK
422 2017-04-27T19:26:22  <wumpus> we had this discussion recently, I thnk the conclusion was to use two service bits
423 2017-04-27T19:26:28  <wumpus> (or one, at first)
424 2017-04-27T19:26:31  <gmaxwell> what wumpus said.
425 2017-04-27T19:26:32  <jonasschnelli> (which is almost always possible with the current auto-prune limit)
426 2017-04-27T19:26:43  <sipa> i would suggest something that guarantees 1 day and 1 week
427 2017-04-27T19:26:51  <wumpus> one bit combination would be 144, one would be ~1000
428 2017-04-27T19:26:58  <luke-jr> jonasschnelli: so segwit prune=550 wouldn't be allowed?
429 2017-04-27T19:27:02  * BlueMatt resists the urge to bikeshed on the "1 week" number
430 2017-04-27T19:27:02  <gmaxwell> Which should be 2 days and 2 weeks so the boundary condition doesn't leave you right out.
431 2017-04-27T19:27:09  <sipa> BlueMatt: i have data!
432 2017-04-27T19:27:11  <jonasschnelli> luke-jr: We would have to bump there
433 2017-04-27T19:27:14  <gmaxwell> BlueMatt: sipa has data on request rates.
434 2017-04-27T19:27:21  <BlueMatt> oh, true, thats right
435 2017-04-27T19:27:22  <wumpus> luke-jr: it's allowed, but it can't signal anything
436 2017-04-27T19:27:44  <sipa> BlueMatt: i'll analyse the numbers again if there is interest
437 2017-04-27T19:27:44  <gmaxwell> The only think to bikeshed is how much higher do we need the cutoff than his data, it should be at least a couple blocks higher because of reorgs/boundary conditions.
438 2017-04-27T19:27:49  *** mol has quit IRC
439 2017-04-27T19:28:20  <gmaxwell> our existing minimum sizing for pruning is sized out for 288 blocks, so I think we should just do that, it will make ~144 pretty reliable.
440 2017-04-27T19:28:29  <bitcoin-git> [bitcoin] sipa opened pull request #10290: Add -stopatheight for benchmarking (master...shutdown_at_height) https://github.com/bitcoin/bitcoin/pull/10290
441 2017-04-27T19:28:38  <wumpus> yep
442 2017-04-27T19:28:47  <BlueMatt> sipa: ack without seeing code
443 2017-04-27T19:28:49  <jonasschnelli> Two service bits seems to be great. Did anyone started with specs/BIP?
444 2017-04-27T19:29:27  <sipa> BlueMatt: i just have a log of which depths of blocks are being fetched from my node
445 2017-04-27T19:29:42  <cfields> how would NODE_NETWORK_LIMITED interact (if at all) with the remote peer's advertised height?
446 2017-04-27T19:29:49  *** jcliff42 has joined #bitcoin-core-dev
447 2017-04-27T19:29:59  <sipa> BlueMatt: since february
448 2017-04-27T19:30:03  <gmaxwell> cfields: I don't think it should?
449 2017-04-27T19:30:05  <luke-jr> IMO would be nicer to have the new service bit require *some* historical storage, but I guess we're not running out..
450 2017-04-27T19:30:08  <jonasschnelli> IMO the purpose is to signal "I have only a limited amount of blocks"
451 2017-04-27T19:30:12  <wumpus> cfields: not at all, we ignore that value
452 2017-04-27T19:30:24  <BlueMatt> sipa: yes, i recall now
453 2017-04-27T19:30:26  <cfields> ok, good
454 2017-04-27T19:30:27  <gmaxwell> That advetised height shouldn't be used for almost anything.
455 2017-04-27T19:30:28  <wumpus> (as it's easily spoofable)
456 2017-04-27T19:30:31  <jonasschnelli> The best-height in version doesn't matter IMO
457 2017-04-27T19:30:32  <wumpus> it isn't used at all
458 2017-04-27T19:30:39  <sipa> i believe it is not used at all
459 2017-04-27T19:30:41  *** jcliff42 has quit IRC
460 2017-04-27T19:30:44  <sipa> (by bitcoin core)
461 2017-04-27T19:30:46  <luke-jr> I'm not sure why more than the last 1-2 blocks should be needed to indicate relaying
462 2017-04-27T19:30:53  <jonasschnelli> wumpus: I  think it's used by SPV
463 2017-04-27T19:31:01  <gmaxwell> luke-jr: because or reorgs.
464 2017-04-27T19:31:14  *** jcliff42 has joined #bitcoin-core-dev
465 2017-04-27T19:31:20  <gmaxwell> if I can't serve you the parents of my tip, I can't help you reorg onto it, making my serving nearly useless.
466 2017-04-27T19:31:24  <wumpus> jonasschnelli: I meant in bitcoin core; I don't know about other implementations
467 2017-04-27T19:31:24  <luke-jr> hmm
468 2017-04-27T19:31:28  <jonasschnelli> Is a min of 144 blocks to height?
469 2017-04-27T19:31:44  <jonasschnelli> No... nm
470 2017-04-27T19:31:45  <petertodd> luke-jr: and requiring nodes to have a GB or two of space for this is a trivial cost these days
471 2017-04-27T19:31:52  <achow101> is the point of NODE_NETWORK_LIMITED just to tell nodes that they can request the most recent blocks from said node?
472 2017-04-27T19:31:55  <luke-jr> assuming we only fetch blocks when reorging to their chain
473 2017-04-27T19:32:02  <instagibbs> It's the unbounded growth that gets people to shut off nodes
474 2017-04-27T19:32:04  <achow101> and right now you can't request any blocks from pruned nodes?
475 2017-04-27T19:32:11  <gmaxwell> In any case the bit must promise more than nodes count on.
476 2017-04-27T19:32:17  <sipa> achow101: pruned nodes don't even advertize they can relay blocks
477 2017-04-27T19:32:34  <instagibbs> achow101, NODE_NETWORK is a flag for that, and it's missing from pruned nodes currently
478 2017-04-27T19:32:36  <jonasschnelli> achow101: once you are in sync (>-144) you can pair with pruned peers and be fine
479 2017-04-27T19:32:53  <achow101> ok
480 2017-04-27T19:32:56  <gmaxwell> Say nodes frequently need to catch up a day.  You only keep 144 blocks.   Peer needs to catch up a day, connects to you.. opps you can't help them because a day turned out to be 150 blocks, they wasted their time connecting to you for nothing.
481 2017-04-27T19:33:43  <gmaxwell> So for this to be useful the requester has to be conservative and not try to talk to you unless it thinks you are _very_ likely to have what it needs, which means that you need a fair amount more than the target.
482 2017-04-27T19:34:11  <gmaxwell> So to serve a day of blocks, you'll need a day and a half or so. Round it up to 288.
483 2017-04-27T19:34:25  <gmaxwell> petertodd: oh hi. long time no see.
484 2017-04-27T19:34:33  <petertodd> gmaxwell: heh
485 2017-04-27T19:34:39  <gmaxwell> and as mentioned, our pruning limit is already there.
486 2017-04-27T19:34:49  <jonasschnelli> I just think we should allow the current auto-pruning 550 peers to signal relay and "limited amount of blocks around the tip".
487 2017-04-27T19:35:08  <luke-jr> so 137 blocks?
488 2017-04-27T19:35:21  <jonasschnelli> If we set NODE_NETWORK_LIMIT higher while allowing to prune shorter,.. this would wast potential peers
489 2017-04-27T19:35:22  <petertodd> luke-jr: 1337 blocks
490 2017-04-27T19:35:27  <gmaxwell> jonasschnelli: then that will never be used.
491 2017-04-27T19:35:28  <jonasschnelli> heh
492 2017-04-27T19:35:43  <gmaxwell> If we don't know how many blocks to except we'll never connect to them.
493 2017-04-27T19:35:55  *** jcliff42 has quit IRC
494 2017-04-27T19:36:14  <gmaxwell> This impacts the connection logic, we'll need logic that changes the requested services based on an estimate of how far back we are.
495 2017-04-27T19:36:17  <sipa> when you're fully synced, why wouldn't you connect to a node that guarantees for example having the last 10 blocks?
496 2017-04-27T19:36:19  <jonasschnelli> gmaxwell: Well, if we are in sync, you could be friendly and make space for the one who need sync and re-connect to limited peers?
497 2017-04-27T19:36:30  <jonasschnelli> Yes. What sipa said
498 2017-04-27T19:36:57  <jonasschnelli> I would expect the larger the chain grows the more pruned peers we will see
499 2017-04-27T19:37:09  <jonasschnelli> (rought assumption)
500 2017-04-27T19:37:11  <sipa> not that we should support pruning that much, but for bandwidth reasons it may be reasonable that someone wants to relay new blocks, but not historical ones
501 2017-04-27T19:37:46  *** midnightmagic has quit IRC
502 2017-04-27T19:38:11  <petertodd> sipa: I think we can make a good argument that requiring nodes to have something like 1GB of storage for historical blocks isn't a big deal, and makes the logic around all this stuff simpler
503 2017-04-27T19:38:12  <jonasschnelli> signaling the amount of block you have is also not extremly effective because of the addr-man, seed/crawl delay
504 2017-04-27T19:38:18  <jonasschnelli> *blocks
505 2017-04-27T19:38:30  <sipa> petertodd: again, not talking about storage, but about bandwidth
506 2017-04-27T19:38:52  <sipa> it's an open question - i'm not convinced it's needed or useful
507 2017-04-27T19:39:02  <jonasschnelli> Yes. Agree with sipa. Main pain point in historical blocks is upstream bandwidth
508 2017-04-27T19:39:07  <gmaxwell> sipa sure that would also work: but (1) nodes that only keep ten blocks are a hazard to the network, and (2) there is no real reason to keep that little, and (3) we don't have signaling room to send out every tiny variation.
509 2017-04-27T19:39:10  <petertodd> sipa: how much more bandwidth do your status say serving ~100 or whatever blocks is vs. 10?
510 2017-04-27T19:39:21  <petertodd> sipa: I mean, you can just turn off NODE_NETWORK_LIMIT entirely
511 2017-04-27T19:39:26  <jonasschnelli> gmaxwell: They would keep more but only willing to serve the last 10
512 2017-04-27T19:39:28  <gmaxwell> sipa: if you want to limit your bandwidth, limit it.
513 2017-04-27T19:39:32  <sipa> gmaxwell: well we have 3 possibilities
514 2017-04-27T19:39:45  <jonasschnelli> NODE_NETWORK_LIMITED would be a limit
515 2017-04-27T19:39:51  <sipa> fair enough, we have other mechanisms for limiting bandwidth
516 2017-04-27T19:39:51  <edcba> QoS on historical blocks :)
517 2017-04-27T19:40:20  <sipa> petertodd: i need to look again... it may not be that much difference
518 2017-04-27T19:40:30  <gmaxwell> sipa: and we have had reorgs longer than 10 in recent memory, what happens if all of your peers are like that?
519 2017-04-27T19:40:57  <BlueMatt> gmaxwell: we have?!
520 2017-04-27T19:41:17  <sipa> BlueMatt: bip50 was 30 deep, iirc
521 2017-04-27T19:41:17  <BlueMatt> oh, you mean the csv false-signaling reorgs?
522 2017-04-27T19:41:22  <BlueMatt> yea, ok
523 2017-04-27T19:41:44  <sipa> ok, i retract my suggestion for 10 deep
524 2017-04-27T19:41:46  <jonasschnelli> Would the two bit amount-of-blocks-available signaling be effective regarding the delay of address distribution?
525 2017-04-27T19:41:52  <BlueMatt> always need 2 * MAX_HUMAN_FIX_TIME_FACTOR for everything :p
526 2017-04-27T19:42:02  <sipa> but we do have 3 possibilities with 2 bits... perhaps we can have a 3rd limit
527 2017-04-27T19:42:08  <jonasschnelli> People tend to prune to MB rather then blocks (which could be a design mistake)
528 2017-04-27T19:42:17  <gmaxwell> jonasschnelli: Why do you think it has much to do with address distribution delay at all?
529 2017-04-27T19:42:29  <gmaxwell> if you keep the last 288 you keep the last 288.. you're not going to flicker that on and off.
530 2017-04-27T19:42:42  <gmaxwell> jonasschnelli: the design guarentees that you'll have 288 blocks.
531 2017-04-27T19:42:48  <gmaxwell> (of the software)
532 2017-04-27T19:42:53  <jonasschnelli> gmaxwell: Maybe I'm looking to much to our seeders,... but the crawling till you serve IPs can be very delayed.
533 2017-04-27T19:43:02  <gmaxwell> so?
534 2017-04-27T19:43:09  <jtimon> jonasschnelli: I think I agree on prunning by height being more useful
535 2017-04-27T19:43:13  <gmaxwell> You'll signal you keep X if you're guarenteed to keep X.
536 2017-04-27T19:43:26  <jtimon> or relative height rather
537 2017-04-27T19:43:33  <sipa> s/height/depth/
538 2017-04-27T19:43:36  <jonasschnelli> Okay. But prune=550 is a MB target. Does it guarantee and amount of blocks?
539 2017-04-27T19:43:42  <jtimon> sipa: right, thanks
540 2017-04-27T19:43:43  <jonasschnelli> *an
541 2017-04-27T19:44:10  <gmaxwell> jonasschnelli: it guarentees we'll keep 288 blocks. The whole feature was designed to guarentee that for reorg reasons, but people thought offering a MB centric UI would be more useful to users.
542 2017-04-27T19:44:21  <gmaxwell> I think in the future we'll change it to a limited set of options.
543 2017-04-27T19:44:45  <gmaxwell> Maybe all of them named after words for big in different languages, like starbucks. :P
544 2017-04-27T19:44:53  <jonasschnelli> Okay. Fair enough...
545 2017-04-27T19:44:53  <achow101> gmaxwell: the MB option confuses people though since it includes the undo data. people see 550 and they assume it means 550 blocks since 1 MB blocks
546 2017-04-27T19:44:53  <luke-jr> eh, 550 MB is only guaranteed 137 blocks with segwit
547 2017-04-27T19:45:04  <luke-jr> oh, forgot undo data
548 2017-04-27T19:45:11  <sipa> gmaxwell: "For me a venti depruned node, please"
549 2017-04-27T19:45:20  <wumpus> lol @ coffee names
550 2017-04-27T19:45:23  <gmaxwell> luke-jr: then that needs to get fixed.
551 2017-04-27T19:45:24  <jonasschnelli> lol
552 2017-04-27T19:45:38  <gmaxwell> sipa: with a double shot of xthin.
553 2017-04-27T19:45:43  <jonasschnelli> pfff
554 2017-04-27T19:46:10  <gmaxwell> luke-jr: easy fix.
555 2017-04-27T19:46:18  <luke-jr> controversial fix
556 2017-04-27T19:46:24  <sipa> gmaxwell: it'll break existing configs
557 2017-04-27T19:46:41  <jonasschnelli> Okay. I can start writing a draft specs about the two bit (144/~1000) NODE_NETWORK_LIMITED.. will announce once I have something
558 2017-04-27T19:46:42  <BlueMatt> sipa: I'm sorry, I dont speak starbucks
559 2017-04-27T19:46:49  <gmaxwell> sipa: so?
560 2017-04-27T19:47:04  <gmaxwell> jonasschnelli: seriously, like why did I bother commenting today?
561 2017-04-27T19:47:18  <sipa> BlueMatt: venti is italian for 20. easy. that's obviously more than "grande" or "tall"
562 2017-04-27T19:47:22  <gmaxwell> first peak is at 144, if _must_ keep more than that to be useful.
563 2017-04-27T19:47:49  <BlueMatt> sipa: ehh, I'll stick with my *good* coffee, thanks
564 2017-04-27T19:47:56  <BlueMatt> anyway, next topic?
565 2017-04-27T19:48:08  <wumpus> #topic high priority for review
566 2017-04-27T19:48:14  <praxeology> My 2 cents: the UI should stay in MB, but underlying the variables stored by the software should be in block count... for the prune threshold.
567 2017-04-27T19:48:43  <wumpus> anything to add to project https://github.com/bitcoin/bitcoin/projects/8?
568 2017-04-27T19:48:55  * BlueMatt suggests adding #10199 for morcos 
569 2017-04-27T19:48:56  <gribble> https://github.com/bitcoin/bitcoin/issues/10199 | Better fee estimates by morcos · Pull Request #10199 · bitcoin/bitcoin · GitHub
570 2017-04-27T19:49:00  <BlueMatt> (who is out today)
571 2017-04-27T19:49:17  <sipa> i'd like to get review on #10195 (which i think is ready)
572 2017-04-27T19:49:18  <gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
573 2017-04-27T19:49:20  * BlueMatt humbly requests rebase of #7729 which is on that list
574 2017-04-27T19:49:21  <gribble> https://github.com/bitcoin/bitcoin/issues/7729 | rpc: introduce label API for wallet by laanwj · Pull Request #7729 · bitcoin/bitcoin · GitHub
575 2017-04-27T19:49:26  <BlueMatt> sipa: pyou already have an entry....
576 2017-04-27T19:49:30  <sipa> oh :(
577 2017-04-27T19:49:50  <wumpus> added 10199
578 2017-04-27T19:50:23  <cfields> It's not urgent, but #10285 is first in a long line towards libevent
579 2017-04-27T19:50:24  <sipa> ok, swap #10148 for #10195 then; 10148 needs more tests
580 2017-04-27T19:50:24  <gribble> https://github.com/bitcoin/bitcoin/issues/10285 | net: refactor the connection process. moving towards async connections. by theuni · Pull Request #10285 · bitcoin/bitcoin · GitHub
581 2017-04-27T19:50:25  <gribble> https://github.com/bitcoin/bitcoin/issues/10148 | [WIP] Use non-atomic flushing with block replay by sipa · Pull Request #10148 · bitcoin/bitcoin · GitHub
582 2017-04-27T19:50:26  <gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
583 2017-04-27T19:50:38  <luke-jr> suggested topic? planned obsolecense
584 2017-04-27T19:50:41  <jtimon> random though: what about maintaining the mb option an adding an incompatible one (you can only set one) with depth ? then the mb can be just an estimation that translates to depth on init, but you don't break old configs, only the expected guarantees about limits
585 2017-04-27T19:51:00  <BlueMatt> luke-jr: NACK
586 2017-04-27T19:51:16  <luke-jr> BlueMatt: NACK topic or NACK it altogether? :/
587 2017-04-27T19:51:24  <achow101> luke-jr: planned obsolecense is a bad name for it
588 2017-04-27T19:51:25  <BlueMatt> second
589 2017-04-27T19:52:09  <wumpus> added 10285, swapped #10148 for #10195
590 2017-04-27T19:52:10  * luke-jr waits for topic change before going into discussion
591 2017-04-27T19:52:10  * jtimon checks https://github.com/bitcoin/bitcoin/pull/8855 is on the priority list
592 2017-04-27T19:52:12  <gribble> https://github.com/bitcoin/bitcoin/issues/10148 | [WIP] Use non-atomic flushing with block replay by sipa · Pull Request #10148 · bitcoin/bitcoin · GitHub
593 2017-04-27T19:52:13  <gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
594 2017-04-27T19:52:28  <sipa> thanks
595 2017-04-27T19:52:50  <wumpus> #topic bitcoind expiration
596 2017-04-27T19:53:42  <jonasschnelli> 10282
597 2017-04-27T19:53:44  <jonasschnelli> #10282
598 2017-04-27T19:53:45  <gribble> https://github.com/bitcoin/bitcoin/issues/10282 | Expire bitcoind & bitcoin-qt 7-8 years after its last change by luke-jr · Pull Request #10282 · bitcoin/bitcoin · GitHub
599 2017-04-27T19:53:50  <luke-jr> BlueMatt: reasoning for NACK?
600 2017-04-27T19:54:11  <cfields> luke-jr: maybe explain reasoning for doing so first?
601 2017-04-27T19:54:12  <luke-jr> re achow101's comment, I don't really think it matters what we call it
602 2017-04-27T19:54:23  <luke-jr> cfields: 10282 has a full explanation
603 2017-04-27T19:54:51  <petertodd> any timeframe short enough to really be useful will probably be short enough to raise political risks...
604 2017-04-27T19:54:51  <luke-jr> 1) it's basically guaranteed to be unsafe by then; 2) hardforks become softforks with enough lead time
605 2017-04-27T19:55:00  <jtimon> I think if it's optional and disabled by default it kind of defeats the point, but I certainly don't want that for myself or the users I recommend to use bitcoin core
606 2017-04-27T19:55:19  <sipa> luke-jr: i don't see how this has anything to do with consensus changes
607 2017-04-27T19:55:32  <petertodd> also, is there any precedent for this kind of expiration in other software?
608 2017-04-27T19:55:40  <BlueMatt> luke-jr: 110% sends the wrong message. if i expected any reasonable person to see that and think "I need to think for myself about what consensus of the network is" I'd be happy with it, but realistically the only people reading that will think "oh, I have to switch to the latest thing from Bitcoin Core, for whatever Bitcoin Core is according to my local google server"
609 2017-04-27T19:55:43  <luke-jr> jtimon: what is the use case for running node software over 7 years after its release, without maintenance?
610 2017-04-27T19:55:53  <gmaxwell> petertodd: yes, but I'm not aware of any that can be overridden.
611 2017-04-27T19:56:06  <sipa> luke-jr: i think insecurity of the software is perhaps a good reason, but not consensus
612 2017-04-27T19:56:07  <petertodd> gmaxwell: got any examples?
613 2017-04-27T19:56:13  <gmaxwell> petertodd: see also the thing with debian and xscreensaver.
614 2017-04-27T19:56:32  <luke-jr> BlueMatt: that's a problem independent of this IMO
615 2017-04-27T19:56:35  <petertodd> gmaxwell: ah, yeah, that crazy situation...
616 2017-04-27T19:56:54  *** Don_John has joined #bitcoin-core-dev
617 2017-04-27T19:57:02  <BlueMatt> luke-jr: how is that independant of the thing which creates it? but, indeed, security may be a reasonable reason, not sure its justified, though
618 2017-04-27T19:57:08  *** jcliff42 has joined #bitcoin-core-dev
619 2017-04-27T19:57:26  <BlueMatt> am i really not allowed to not upgrade the bitcoind I've got running behind by bitcoind/xyz firewall?
620 2017-04-27T19:57:33  <luke-jr> BlueMatt: people will mostly all update before this triggers; probably using the insecure method you describre
621 2017-04-27T19:57:44  <gmaxwell> I agree with petertodd's point about short enough to be useful is short enough to be problematic. :( But there are other not really useful features...
622 2017-04-27T19:57:50  <BlueMatt> oops, bitcoind crashed in production
623 2017-04-27T19:58:23  <luke-jr> BlueMatt: note this has an explicit override allowed
624 2017-04-27T19:58:26  <petertodd> gmaxwell: and there's a larger point too: chances are the surrounding software on your machine is also not getting updated anyway, so you've got other big problems
625 2017-04-27T19:58:32  <luke-jr> if you really don't want to upgrade, just add to your config file
626 2017-04-27T19:58:35  <BlueMatt> luke-jr: yes, and you can do that /after/ your bitcoind has crashed
627 2017-04-27T19:58:36  <jtimon> luke-jr: let's say my friend remembers what I told him about being up to date 6 years and 11 months after I helped him install bitcoin core
628 2017-04-27T19:58:38  <BlueMatt> which is kinda shit
629 2017-04-27T19:58:48  <gmaxwell> it would be nice to be able to say there are no nodes running older than X without the user deciding to keep them running.
630 2017-04-27T19:58:58  <luke-jr> BlueMatt: you could do it before as well, but IMO after 7 years it's okay to force the user to do something
631 2017-04-27T19:59:04  <gmaxwell> BlueMatt: yes, but the crash was an RCE and all your funds are now gone. :)
632 2017-04-27T19:59:27  <wumpus> if you run nodes in production you'll have some system to monitor it
633 2017-04-27T19:59:30  <BlueMatt> gmaxwell: not if its the bitcoind that everything talks to on your network and it just sits behind sufficient layers of regularly-updated bitcoind firewalls
634 2017-04-27T19:59:39  <wumpus> and summon an operator on crashes
635 2017-04-27T19:59:53  <BlueMatt> wumpus: lol, i meannnnn, maybe
636 2017-04-27T20:00:08  <sipa> wumpus: hahaha, yes, with a server farm at the end of the rainbow
637 2017-04-27T20:00:19  <luke-jr> BlueMatt: and what if it doesn't crash, but someone exploits your failure to enforce a softfork?
638 2017-04-27T20:00:21  <jtimon> or shouldn't I recommend bitcoin core for a wallet?
639 2017-04-27T20:00:25  <petertodd> wumpus: you should talk to some banking IT guys about how hard it is to get approval to update things :)
640 2017-04-27T20:00:33  <luke-jr> jtimon: I don't understand your argument.
641 2017-04-27T20:00:45  <wumpus> petertodd: I'm not saying anything about updating
642 2017-04-27T20:00:54  <instagibbs> jtimon, you can over-ride the setting, I believe
643 2017-04-27T20:01:08  <petertodd> wumpus: literally touching a config option is an update by those standards
644 2017-04-27T20:01:09  <jtimon> instagibbs: oh, I missed that
645 2017-04-27T20:01:18  <wumpus> only about crashes, if some software is important to your business and it crashes, you'll notice.
646 2017-04-27T20:01:41  <wumpus> anyhow
647 2017-04-27T20:01:43  <wumpus> #endmeeting
648 2017-04-27T20:01:43  <lightningbot> Meeting ended Thu Apr 27 20:01:43 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
649 2017-04-27T20:01:43  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-04-27-19.02.html
650 2017-04-27T20:01:43  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-04-27-19.02.txt
651 2017-04-27T20:01:43  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-04-27-19.02.log.html
652 2017-04-27T20:01:59  <jtimon> luke-jr: sorry, I missed what instagibbs just said, should read the proposal I guess
653 2017-04-27T20:03:16  <jnewbery> "after 7 years it's okay to force the user to do something" - not sure I understand this. Who's forcing the user to do something?
654 2017-04-27T20:03:24  <wumpus> heck my nodes do nothing imporant and even I have a one-liner script that sends me a mail on crash or unexpected exit
655 2017-04-27T20:03:44  <luke-jr> jnewbery: 7 years after it's released, bitcoind/-qt would exit and refuse to start until the user chose to either upgrade it, or override the expiration
656 2017-04-27T20:03:48  <jtimon> jnewbery: also, this is free software, you can't force users
657 2017-04-27T20:03:59  <jnewbery> jtimon - right that's my point
658 2017-04-27T20:04:07  <sipa> my node does something important, and i have a 0-line script that sends me an mail on crash (= people mail me that my website stopped updating)
659 2017-04-27T20:04:10  * sipa hides
660 2017-04-27T20:04:18  <luke-jr> jtimon: you can force users to *do something* :P
661 2017-04-27T20:04:20  <wumpus> sipa: well that works too
662 2017-04-27T20:04:25  <luke-jr> sipa: haha
663 2017-04-27T20:05:01  * BlueMatt has a feeling sipa's approach is more common
664 2017-04-27T20:05:14  <jtimon> luke-jr: yes, but then I will disable the anti-feature for my friend the first time I help him install and tell him about updates
665 2017-04-27T20:06:03  <luke-jr> jtimon: why?
666 2017-04-27T20:06:12  <luke-jr> the "anti-feature" has no harm in any reasonable scenario
667 2017-04-27T20:06:17  * BlueMatt would do the same
668 2017-04-27T20:06:19  <jnewbery> I'd be happy for there to be a warning if running an old version, but I really don't like it automatically disabling a node after 7 years, particularly if the reason is "this enables a sort of certainty of old nodes ending by a deadline, turning any hardfork into a de facto softfork provided it is planned 8 years out."
669 2017-04-27T20:06:20  <wumpus> another possiblity would be to only refuse to start after 7 years, not stop if already running
670 2017-04-27T20:06:25  <wumpus> this would give less guarantees, but still
671 2017-04-27T20:06:28  <jnewbery> In that case, we might as well have auto-update
672 2017-04-27T20:06:49  * instagibbs imagining someone running a node non-stop for 7 years
673 2017-04-27T20:06:50  <wumpus> jnewbery: wow that's very black and white
674 2017-04-27T20:06:54  <luke-jr> jnewbery: not the same thing at all; the user can always opt to bypass the expiration
675 2017-04-27T20:06:55  <petertodd> wumpus: god help us if we ever release a version that gets the date wrong...
676 2017-04-27T20:07:00  <BlueMatt> wumpus: yea, something much more watered down may be reasonable, including huge fat warnings if the software is like 2 years old
677 2017-04-27T20:07:21  <BlueMatt> wumpus: the perception will be black and white as well
678 2017-04-27T20:07:23  <wumpus> petertodd: well it could mention the flag to override I guess
679 2017-04-27T20:07:44  <jtimon> luke-jr: again, sorry, should read the proposal but "programmed obsolecense" definitely sounds like an anti-feature, after reading the proposal, if I think is a feature, will maybe just suggest to rename it
680 2017-04-27T20:07:51  <BlueMatt> refusing to start with an error message mentioning the flag to override would be reasonable, but also largely useless
681 2017-04-27T20:07:55  <wumpus> anyhow, apparently the consensus is to not do it, that's fine
682 2017-04-27T20:07:59  <BlueMatt> though maybe not just to remind users
683 2017-04-27T20:08:00  <petertodd> wumpus: you still might have quite a bit of chaos of nodes being shut down all at once
684 2017-04-27T20:08:21  <wumpus> petertodd: that's why I suggested "<wumpus> another possiblity would be to only refuse to start after 7 years, not stop if already running"
685 2017-04-27T20:08:41  <wumpus> in any case, seems there's too much drawbacks to this
686 2017-04-27T20:09:01  <sipa> wumpus: so all you need to do after 7 years is find a remote crashing bug, and use it on every remaining node (and finding a remote crash bug for 7 yo software doesn't sound hard...)
687 2017-04-27T20:09:05  <sipa> :)
688 2017-04-27T20:09:06  <petertodd> wumpus: I'd think nodes get restarted reasonably often, and often by automatic means
689 2017-04-27T20:09:15  <BlueMatt> wumpus: yes, your proposal i could get behind, mostly because it would inform users that they can add a conf option, making the "refuse to start" thing kinda moot, while still being really insistent on telling users to upgrade, which is fine
690 2017-04-27T20:09:44  <wumpus> BlueMatt: I think that's acceptable after 7 years
691 2017-04-27T20:10:01  <sipa> i don't think that there is much difference between refusing to start vs stopping to work
692 2017-04-27T20:10:05  <wumpus> come on, 7 years is an eternity on the internet, we shouldn't bee too childish about this
693 2017-04-27T20:10:14  <sipa> especially at that timeframe
694 2017-04-27T20:10:26  <wumpus> sipa: right
695 2017-04-27T20:10:38  <BlueMatt> sipa: I tend to disagree
696 2017-04-27T20:10:41  <jnewbery> wumpus: not helpful. I think people are raising legitimate concerns
697 2017-04-27T20:10:55  <wumpus> a startup check is simpler to implement and less error prone though
698 2017-04-27T20:11:03  <BlueMatt> (re difference between startup and forced shutdown)
699 2017-04-27T20:11:26  <wumpus> jnewbery: really, a legitimate concern, that people are running 7 year old software in production?
700 2017-04-27T20:11:33  <BlueMatt> wumpus: yes
701 2017-04-27T20:11:41  *** Giszmo has quit IRC
702 2017-04-27T20:11:52  <jnewbery> a legitimate concern that devs don't have the right to "force" users to do something
703 2017-04-27T20:11:53  <wumpus> sometimes it's just like people are just making up unlikely \things just to argue
704 2017-04-27T20:11:55  <instagibbs> and can't be bothered to click through, or set a flag?
705 2017-04-27T20:11:59  <BlueMatt> wumpus: 7 years is, in fact, *not* an eternity on the internet
706 2017-04-27T20:12:07  <instagibbs> I understand it would need to be done right, but that's a little nuts.
707 2017-04-27T20:12:17  <wumpus> it wouldn't be forcing to do anything, as there is an override
708 2017-04-27T20:12:17  <wumpus> sigh
709 2017-04-27T20:12:20  <BlueMatt> instagibbs: click through fine, shutdown *while running*?
710 2017-04-27T20:12:31  <luke-jr> BlueMatt: it's only slightly shorter than Bitcoin's current lifetime
711 2017-04-27T20:12:32  <wumpus> BlueMatt: okay, what ever
712 2017-04-27T20:12:37  <instagibbs> BlueMatt, sure, that's another dot on the matrix, I agree on that one
713 2017-04-27T20:12:56  <jtimon> it should still be relatively easy for users to get out of the stuck situation in case they can't upgrade in the same system or something, like maybe deleting a filed named ~/.bitcoin/DELETE_ME_ONLY_IF_YOU_CANT_UPGRADE_IN_THIS_SYSTEM or something
714 2017-04-27T20:13:13  <luke-jr> jtimon: yes, it's already easy to override
715 2017-04-27T20:13:22  <BlueMatt> jtimon: conf flag seems neater, no one checks their bitcoin datadir
716 2017-04-27T20:13:23  <luke-jr> we can make it easier perhaps by taking a YYYY instead of POSIX timestamp
717 2017-04-27T20:13:31  <petertodd> gmaxwell: btw, re: your comment in the meeting, no-one's funding me to do any work on Bitcoin Core these days
718 2017-04-27T20:13:39  <jtimon> luke-jr: BlueMatt: great
719 2017-04-27T20:14:19  <luke-jr> jnewbery: nobody is forcing users to run Core at all.
720 2017-04-27T20:15:09  <BlueMatt> wumpus: on a less controversial note, #7729 is ripe for rebase-and-review, no? or are we now so bogged down on major features that need review you're waiting? :/
721 2017-04-27T20:15:11  <gribble> https://github.com/bitcoin/bitcoin/issues/7729 | rpc: introduce label API for wallet by laanwj · Pull Request #7729 · bitcoin/bitcoin · GitHub
722 2017-04-27T20:15:30  <jnewbery> luke-jr indeed, and I don't think core devs should attempt to force users to upgrade
723 2017-04-27T20:16:00  <luke-jr> jnewbery: we're not. by running Core, they would be opting in to being forced to either upgrade OR tell the software they don't want to
724 2017-04-27T20:16:07  <wumpus> BlueMatt: yes, I tried once, but so much moved around since that it's pretty much "re-do" instead of rebase
725 2017-04-27T20:16:15  <BlueMatt> grr, sorry about that :/
726 2017-04-27T20:16:16  <luke-jr> "forced" is really the wrong word here
727 2017-04-27T20:16:47  <BlueMatt> luke-jr: thats ridiculous, you're living in a world where people have the time go read a ton of bitcoin core docs/code before running it, and do...neither of which are true
728 2017-04-27T20:16:49  <wumpus> I don't think we're going to agree on this luke-jr
729 2017-04-27T20:16:49  <jtimon> yeah, as BlueMatt said, being annoying about upgrading is fine
730 2017-04-27T20:17:25  * BlueMatt goes back to trying to make a dent in the review pile
731 2017-04-27T20:17:28  <luke-jr> BlueMatt: not before, simply read a short notice when it tells them to make a decision
732 2017-04-27T20:17:33  <wumpus> when it detoriorates to arguing about what words to use it's better to just stop
733 2017-04-27T20:17:38  *** tw2006 has quit IRC
734 2017-04-27T20:18:07  <luke-jr> jtimon: well, this proposal comes down to being annoying at worst, and BlueMatt doesn't like it either
735 2017-04-27T20:18:30  <BlueMatt> luke-jr: which proposal now? refusing to startup or crashing while running?
736 2017-04-27T20:18:39  <wumpus> BlueMatt: IIRC I don't think any of the wallet changes that complicate rebasing #7729 are your fault, just a lot happened there
737 2017-04-27T20:18:39  <BlueMatt> but, yea, I'm gonna go back to review, this has devolved
738 2017-04-27T20:18:41  <gribble> https://github.com/bitcoin/bitcoin/issues/7729 | rpc: introduce label API for wallet by laanwj · Pull Request #7729 · bitcoin/bitcoin · GitHub
739 2017-04-27T20:18:52  <luke-jr> BlueMatt: yes, being able to override it means it's merely annoying
740 2017-04-27T20:19:04  <BlueMatt> wumpus: fair, but its on the rest of us to get it reviewed in a timely manner :p
741 2017-04-27T20:19:45  <jtimon> luke-jr: as said, without reading it, my only concern that it wasn't relatively easy or undocumented for a user to overrule the annoyance
742 2017-04-27T20:19:46  <michagogo> Last week we were talking about WSL and Gitian
743 2017-04-27T20:19:49  <wumpus> I would have liked quicker feedback on the API. But I think there's agreement on that now so implementation should be fairy simple
744 2017-04-27T20:20:03  <michagogo> I haven't tried with VBox yet, but I can confirm that LXC doesn't work
745 2017-04-27T20:20:13  <jtimon> what is the link again?
746 2017-04-27T20:20:16  <wumpus> what doesn't work?
747 2017-04-27T20:20:27  <michagogo> make-base-vm fails, as does lxc-create
748 2017-04-27T20:20:28  <wumpus> building master using gitian?
749 2017-04-27T20:20:36  <michagogo> No, running LXC in WSL
750 2017-04-27T20:20:43  <luke-jr> no surprise there
751 2017-04-27T20:20:45  <wumpus> ohh. Yes we know that, that's an upstream problem
752 2017-04-27T20:20:47  <michagogo> Right
753 2017-04-27T20:20:51  <wumpus> bother microsoft :)
754 2017-04-27T20:20:55  <michagogo> I wasn't expecting it to, at all
755 2017-04-27T20:21:08  <michagogo> But someone last week thought maybe it would, so I tried it
756 2017-04-27T20:21:12  <wumpus> even building depends in WSL currently doesn't work, due to some vague change in their ubuntu
757 2017-04-27T20:21:34  <BlueMatt> microsoft: taking "compatibility" to a new level
758 2017-04-27T20:21:38  <wumpus> https://github.com/bitcoin/bitcoin/issues/10269
759 2017-04-27T20:21:54  <wumpus> BlueMatt: yeah embrace and extinguish, round N
760 2017-04-27T20:22:51  <michagogo> Really? I didn't know that.
761 2017-04-27T20:23:07  <michagogo> I remember when WSL was pretty new I tried it and it worked perfectly
762 2017-04-27T20:23:26  <wumpus> it worked at some point
763 2017-04-27T20:24:24  <BlueMatt> it worked when they made the press release for all the people to try it, after that they only cared that it appeared to work so that windows folks build software that doesnt really work on linux, but claims to :p
764 2017-04-27T20:24:39  <michagogo> It's times like this that I wish I had Windows 10 on my computer
765 2017-04-27T20:24:52  <BlueMatt> ewwwwwww
766 2017-04-27T20:25:01  <BlueMatt> thats worse than starbucks coffee!
767 2017-04-27T20:25:05  <michagogo> I mean, I'm on Win7 right now
768 2017-04-27T20:25:14  <BlueMatt> ouch
769 2017-04-27T20:26:11  <michagogo> Haven't upgraded for two reasons. First, I don't use my computer at home so much lately (= the last couple years) and don't have so much time to spend with it to try and fix it if it gets messed up, smooth out the kinks, etc.
770 2017-04-27T20:26:34  <michagogo> Second, at work I have 7, and I'm concerned that one of two things will happen
771 2017-04-27T20:26:35  <edcba> 7yrs software in prod rotfl: in 2016 i was supporting xp at work...
772 2017-04-27T20:27:22  *** Giszmo has joined #bitcoin-core-dev
773 2017-04-27T20:27:25  <jtimon> is there an issue in win7's github for the bug on their side? let's just go concept ack there
774 2017-04-27T20:27:46  <michagogo> Either it'll be too different and I won't adjust to it because I'll still be mostly using 7, and then my time with it will be annoying, or, it'll be amazing and I'll get used to having stuff from it, and then be sad when I go back to 7 at work
775 2017-04-27T20:27:51  <michagogo> "win7's github"?
776 2017-04-27T20:28:00  <jtimon> sorry, bad joke
777 2017-04-27T20:28:01  <BlueMatt> michagogo: i think it was a joke :p
778 2017-04-27T20:28:09  <BlueMatt> jtimon: i found it comical
779 2017-04-27T20:28:25  <michagogo> Wait, which bug?
780 2017-04-27T20:28:33  <michagogo> I first thought you meant Windows 10
781 2017-04-27T20:28:42  <jtimon> BlueMatt: oh, thanks, I read your "I think" as a confirmation that it was bad
782 2017-04-27T20:28:54  <michagogo> Because if Core builds on Ubuntu but not in WSL, that *is* a bug in WSL
783 2017-04-27T20:29:42  <wumpus> after all we did a gitian build very shortly ago, which uses the same version of ubuntu (14.04)
784 2017-04-27T20:30:03  <wumpus> maybe it's some magic with line endings or such
785 2017-04-27T20:30:23  <michagogo> I think as of Creator Update, a couple weeks ago, new WSL installs are Xenial
786 2017-04-27T20:30:39  <wumpus> ugh
787 2017-04-27T20:30:45  <michagogo> Ugh? Why?
788 2017-04-27T20:30:57  <wumpus> the windows toolchain on xenial is kind of broken
789 2017-04-27T20:31:10  <BlueMatt> no wonder wsl is broken
790 2017-04-27T20:31:19  <wumpus> yes, that explains it then
791 2017-04-27T20:31:27  <michagogo> Really? Have bugs been filed?
792 2017-04-27T20:31:30  <wumpus> they can be happy they don't get executables
793 2017-04-27T20:31:49  <wumpus> I don't think it was ever narrowed down
794 2017-04-27T20:32:19  <michagogo> Is there anything different besides gcc being replaced by mingw-w64?
795 2017-04-27T20:32:42  <wumpus> see "Ubuntu 16.04 Windows cross-build" on https://github.com/bitcoin/bitcoin/projects for a collection of issues
796 2017-04-27T20:33:01  <wumpus> it's a newer version of mingw-w64 that doesn't work so well
797 2017-04-27T20:33:10  <michagogo> I was thinking of upgrading my Ubuntu VM (that I use mostly for gitian building) from Trusty to Xenial - should I not do that?
798 2017-04-27T20:33:19  <wumpus> fstack-protector produces broken executables, and there was some c++11 threading snafu
799 2017-04-27T20:33:32  <wumpus> could be that these are solved by now, I have no idea, haven't tried it for months
800 2017-04-27T20:34:12  <wumpus> you can't use xenial for gitian building without everyone else changing too
801 2017-04-27T20:34:27  <michagogo> I meant for the host
802 2017-04-27T20:34:33  <wumpus> oh the host can be anything
803 2017-04-27T20:34:35  <michagogo> Not changing the target container
804 2017-04-27T20:34:41  <wumpus> I use debian for the host
805 2017-04-27T20:34:49  <jtimon> wumpus: btw, it would be nice to put BlueMatt 's libconsensus-related PRs in https://github.com/bitcoin/bitcoin/projects/6 (and always tag anything there with "consensus")
806 2017-04-27T20:34:56  <michagogo> I wonder if I should delete my precise sandbox VM
807 2017-04-27T20:35:22  <wumpus> michagogo: yes, why not
808 2017-04-27T20:35:24  <wumpus> jtimon: ok
809 2017-04-27T20:36:19  *** jcliff42 has quit IRC
810 2017-04-27T20:36:29  <jtimon> wumpus: thanks, I mean, not a priority, just would be somewhat helpful
811 2017-04-27T20:41:17  <jtimon> btw BlueMatt thanks for https://github.com/bitcoin/bitcoin/pull/771 I shouldn't look at it much and look at the new things instead but like these things if I find the time
812 2017-04-27T20:41:52  <BlueMatt> jtimon: lol, that was so long ago even I dont remember how it was designed
813 2017-04-27T20:42:23  <jtimon> but you said it was based on it, so I was hoping some ideas remained
814 2017-04-27T20:43:09  <jtimon> that's what makes it more interesting IMO, it could be the same general idea with very different code
815 2017-04-27T20:44:16  <jtimon> or more or less the same code, which I would find more amusing
816 2017-04-27T20:45:15  *** tommyhot has joined #bitcoin-core-dev
817 2017-04-27T20:45:54  *** JackH has quit IRC
818 2017-04-27T20:55:59  *** jcliff42 has joined #bitcoin-core-dev
819 2017-04-27T21:01:11  <sipa> jtimon: i think the extent of the similarity is "encapsulate all the state related to blockchain censensus"
820 2017-04-27T21:04:21  *** jcliff42 has quit IRC
821 2017-04-27T21:06:30  *** Giszmo has quit IRC
822 2017-04-27T21:09:01  *** jcliff42 has joined #bitcoin-core-dev
823 2017-04-27T21:09:40  *** CubicEarth has joined #bitcoin-core-dev
824 2017-04-27T21:09:50  *** jcliff42 has joined #bitcoin-core-dev
825 2017-04-27T21:12:10  *** Dyaheon has quit IRC
826 2017-04-27T21:13:27  *** Dyaheon has joined #bitcoin-core-dev
827 2017-04-27T21:14:54  *** comboy has joined #bitcoin-core-dev
828 2017-04-27T21:17:01  <achow101> wumpus: michagogo windows cross compile on ubuntu xenial is still broken.
829 2017-04-27T21:17:16  <achow101> on wsl, there's a different problem with depends failing
830 2017-04-27T21:18:52  *** midnightmagic has joined #bitcoin-core-dev
831 2017-04-27T21:21:24  *** Giszmo has joined #bitcoin-core-dev
832 2017-04-27T21:24:09  <wumpus> achow101: yes, seems to be different issues - confusing
833 2017-04-27T21:24:28  <wumpus> building on xenial, for xenial works fine in any case
834 2017-04-27T21:24:45  <wumpus> it only breaks with windows in the picture (either as cross compile or WSL)
835 2017-04-27T21:30:28  *** praxeology has quit IRC
836 2017-04-27T21:33:55  <michagogo> Hm, if I have a VM with a snapshot and a bunch of changes since the snapshot, and I want to create a snapshot of the current state and delete the existing one
837 2017-04-27T21:34:19  <michagogo> Does it matter at all whether I delete the current one before or after taking the new one, in terms of final size?
838 2017-04-27T21:42:57  *** Giszmo has quit IRC
839 2017-04-27T21:44:26  *** marcoagner has joined #bitcoin-core-dev
840 2017-04-27T21:44:54  *** Cheeseo has joined #bitcoin-core-dev
841 2017-04-27T21:56:21  *** jcliff42 has quit IRC
842 2017-04-27T21:57:58  *** Giszmo has joined #bitcoin-core-dev
843 2017-04-27T22:02:55  *** tw2006 has joined #bitcoin-core-dev
844 2017-04-27T22:11:39  *** moli_ has joined #bitcoin-core-dev
845 2017-04-27T22:13:34  *** jamoes has quit IRC
846 2017-04-27T22:17:08  *** giannis has joined #bitcoin-core-dev
847 2017-04-27T22:17:11  *** eragmus has quit IRC
848 2017-04-27T22:17:31  *** giannis is now known as Guest50266
849 2017-04-27T22:18:08  *** pindarhk has quit IRC
850 2017-04-27T22:18:14  *** jamoes has joined #bitcoin-core-dev
851 2017-04-27T22:18:28  *** trotski2000 has quit IRC
852 2017-04-27T22:20:37  *** Guest50266 has quit IRC
853 2017-04-27T22:22:13  *** justanotheruser has quit IRC
854 2017-04-27T22:22:48  *** justanotheruser has joined #bitcoin-core-dev
855 2017-04-27T22:26:07  *** eragmus has joined #bitcoin-core-dev
856 2017-04-27T22:26:57  *** trotski2000 has joined #bitcoin-core-dev
857 2017-04-27T22:27:53  *** pindarhk has joined #bitcoin-core-dev
858 2017-04-27T22:30:31  *** jcliff42 has joined #bitcoin-core-dev
859 2017-04-27T22:30:40  *** tripleslash has quit IRC
860 2017-04-27T22:31:32  *** vicenteH has quit IRC
861 2017-04-27T22:37:58  *** tripleslash has joined #bitcoin-core-dev
862 2017-04-27T22:46:49  *** [\\\] has joined #bitcoin-core-dev
863 2017-04-27T22:46:56  *** tripleslash has quit IRC
864 2017-04-27T22:49:11  <bitcoin-git> [bitcoin] practicalswift closed pull request #9544: [trivial] Add end of namespace comments. Improve consistency. (master...consistent-use-of-end-of-namespace-comments) https://github.com/bitcoin/bitcoin/pull/9544
865 2017-04-27T22:49:39  *** [\\\] is now known as tripleslash
866 2017-04-27T22:51:40  <bitcoin-git> [bitcoin] practicalswift reopened pull request #9544: [trivial] Add end of namespace comments. Improve consistency. (master...consistent-use-of-end-of-namespace-comments) https://github.com/bitcoin/bitcoin/pull/9544
867 2017-04-27T22:59:33  *** laurentmt has joined #bitcoin-core-dev
868 2017-04-27T23:00:29  *** Giszmo has quit IRC
869 2017-04-27T23:08:17  *** laurentmt has quit IRC
870 2017-04-27T23:09:27  *** gm2051 has quit IRC
871 2017-04-27T23:20:08  *** tripleslash has quit IRC
872 2017-04-27T23:23:39  *** jcliff42 has quit IRC
873 2017-04-27T23:24:05  *** marcoagner has quit IRC
874 2017-04-27T23:32:48  *** tripleslash has joined #bitcoin-core-dev
875 2017-04-27T23:33:27  *** jcliff42 has joined #bitcoin-core-dev
876 2017-04-27T23:37:14  *** jamoes has quit IRC
877 2017-04-27T23:37:16  *** marcoagner has joined #bitcoin-core-dev
878 2017-04-27T23:50:38  *** justanotheruser has quit IRC
879 2017-04-27T23:51:08  *** justanotheruser has joined #bitcoin-core-dev
880 2017-04-27T23:58:58  *** abpa has quit IRC