1 2020-06-11T00:00:02  *** flo1 has quit IRC
  2 2020-06-11T00:00:08  *** bitcoin-git has joined #bitcoin-core-dev
  3 2020-06-11T00:00:08  <bitcoin-git> [bitcoin] luke-jr opened pull request #19241: help: Generate checkpoint height from chainparams (master...help_checkpoint_num) https://github.com/bitcoin/bitcoin/pull/19241
  4 2020-06-11T00:00:09  *** bitcoin-git has left #bitcoin-core-dev
  5 2020-06-11T00:14:37  *** proofofk_ has quit IRC
  6 2020-06-11T00:15:12  *** proofofkeags has joined #bitcoin-core-dev
  7 2020-06-11T00:16:18  *** proofofkeags has quit IRC
  8 2020-06-11T00:17:13  *** proofofkeags has joined #bitcoin-core-dev
  9 2020-06-11T00:21:03  *** pretyflaco1 has quit IRC
 10 2020-06-11T00:22:14  *** proofofkeags has quit IRC
 11 2020-06-11T00:30:05  *** proofofkeags has joined #bitcoin-core-dev
 12 2020-06-11T00:41:31  *** proofofkeags has quit IRC
 13 2020-06-11T00:42:06  *** proofofkeags has joined #bitcoin-core-dev
 14 2020-06-11T00:46:43  *** proofofkeags has quit IRC
 15 2020-06-11T00:52:24  *** S3RK has joined #bitcoin-core-dev
 16 2020-06-11T00:56:48  *** Eartaker has joined #bitcoin-core-dev
 17 2020-06-11T01:05:54  *** dfmb_ has joined #bitcoin-core-dev
 18 2020-06-11T01:06:03  *** dfmb_ has quit IRC
 19 2020-06-11T01:07:23  *** bitdex has quit IRC
 20 2020-06-11T01:15:45  *** AaronvanW has quit IRC
 21 2020-06-11T01:16:42  *** proofofkeags has joined #bitcoin-core-dev
 22 2020-06-11T01:21:14  *** proofofkeags has quit IRC
 23 2020-06-11T01:25:58  *** Relis has quit IRC
 24 2020-06-11T01:30:50  *** promag has joined #bitcoin-core-dev
 25 2020-06-11T01:32:08  *** Relis has joined #bitcoin-core-dev
 26 2020-06-11T01:35:35  *** promag has quit IRC
 27 2020-06-11T01:36:40  <sipa> fanquake: can you mark your "changes requested" as resolved on #19228 ?
 28 2020-06-11T01:36:41  <gribble> https://github.com/bitcoin/bitcoin/issues/19228 | Update libsecp256k1 subtree by sipa · Pull Request #19228 · bitcoin/bitcoin · GitHub
 29 2020-06-11T01:37:17  <fanquake> sipa: sure
 30 2020-06-11T01:41:45  <fanquake> Flat out confusing myself with the GH UI, but managed to get it sorted
 31 2020-06-11T01:43:16  <luke-jr> more like it managed to get you sorted :P
 32 2020-06-11T01:44:06  <fanquake> heh. Managed to re-request a review from myself
 33 2020-06-11T01:44:24  <luke-jr> XD
 34 2020-06-11T01:44:31  <sipa> fanquake is now known as aaefknqu
 35 2020-06-11T01:44:54  <luke-jr> lol
 36 2020-06-11T01:47:24  *** bitdex has joined #bitcoin-core-dev
 37 2020-06-11T01:57:06  *** thaumavorio has quit IRC
 38 2020-06-11T01:58:17  *** thaumavorio has joined #bitcoin-core-dev
 39 2020-06-11T02:04:28  *** Highway61 has quit IRC
 40 2020-06-11T02:07:16  *** proofofkeags has joined #bitcoin-core-dev
 41 2020-06-11T02:09:53  *** Relis has quit IRC
 42 2020-06-11T02:20:32  *** Highway61 has joined #bitcoin-core-dev
 43 2020-06-11T02:22:31  *** Relis has joined #bitcoin-core-dev
 44 2020-06-11T02:24:50  *** Relis has quit IRC
 45 2020-06-11T02:26:02  *** Relis has joined #bitcoin-core-dev
 46 2020-06-11T02:28:18  *** bitcoin-git has joined #bitcoin-core-dev
 47 2020-06-11T02:28:18  <bitcoin-git> [bitcoin] luke-jr opened pull request #19242: Add -uaappend option to append a literal string to user agent (master...uaappend) https://github.com/bitcoin/bitcoin/pull/19242
 48 2020-06-11T02:28:30  *** bitcoin-git has left #bitcoin-core-dev
 49 2020-06-11T02:33:31  <aj> luke-jr: shouldn't uaappends be separated by "; " or something?
 50 2020-06-11T02:50:59  *** proofofkeags has quit IRC
 51 2020-06-11T02:51:26  <luke-jr> aj: '/', but I'm assuming the using application knows that
 52 2020-06-11T02:51:32  *** proofofkeags has joined #bitcoin-core-dev
 53 2020-06-11T02:51:37  <luke-jr> -uaappend 'foo:1.0/'
 54 2020-06-11T02:51:47  <luke-jr> -uaappend 'foo:1.0/bar:9999/'
 55 2020-06-11T02:55:05  <aj> luke-jr: i would have expected use more like -uappend=foo:1.0 -uappend=bar:9999
 56 2020-06-11T02:55:27  *** justanotheruser has quit IRC
 57 2020-06-11T02:55:41  *** S3RK has quit IRC
 58 2020-06-11T02:56:02  *** proofofkeags has quit IRC
 59 2020-06-11T02:56:06  <aj> apparently the double-a is hard for me
 60 2020-06-11T02:56:25  <luke-jr> aj: but then you can't reliably predict order
 61 2020-06-11T02:59:22  <aj> luke-jr: sure, but don't see why order matters much? (and if it does, then allowing many uaappend's doesn't seem right?)
 62 2020-06-11T03:00:02  *** Eartaker has quit IRC
 63 2020-06-11T03:08:47  *** justanotheruser has joined #bitcoin-core-dev
 64 2020-06-11T03:16:32  *** Eagle[TM] has joined #bitcoin-core-dev
 65 2020-06-11T03:17:28  <luke-jr> aj: maybe it does, maybe not *shrug*
 66 2020-06-11T03:17:54  <luke-jr> we don't act on it, but others might
 67 2020-06-11T03:18:06  <luke-jr> probably shouldn't I guess, but it's also nice for consistency :x
 68 2020-06-11T03:18:26  *** EagleTM has quit IRC
 69 2020-06-11T03:18:28  *** justanotheruser has quit IRC
 70 2020-06-11T03:22:14  *** meltheadorable has joined #bitcoin-core-dev
 71 2020-06-11T03:22:56  *** Relis has quit IRC
 72 2020-06-11T03:25:46  <luke-jr> I guess always ensuring there's a / at the end makes sense
 73 2020-06-11T03:48:35  *** justanotheruser has joined #bitcoin-core-dev
 74 2020-06-11T04:20:35  *** vasild_ has joined #bitcoin-core-dev
 75 2020-06-11T04:21:01  *** S3RK has joined #bitcoin-core-dev
 76 2020-06-11T04:23:23  *** vasild has quit IRC
 77 2020-06-11T04:23:24  *** vasild_ is now known as vasild
 78 2020-06-11T04:31:55  *** ppisati has quit IRC
 79 2020-06-11T04:36:08  *** shesek has quit IRC
 80 2020-06-11T04:36:32  *** shesek has joined #bitcoin-core-dev
 81 2020-06-11T04:36:32  *** shesek has joined #bitcoin-core-dev
 82 2020-06-11T04:38:40  *** ppisati has joined #bitcoin-core-dev
 83 2020-06-11T04:57:06  *** afk11` has quit IRC
 84 2020-06-11T04:57:28  *** afk11` has joined #bitcoin-core-dev
 85 2020-06-11T04:58:48  *** jarthur_ has joined #bitcoin-core-dev
 86 2020-06-11T05:01:02  *** jarthur has quit IRC
 87 2020-06-11T05:03:02  *** S3RK has quit IRC
 88 2020-06-11T05:03:29  *** S3RK has joined #bitcoin-core-dev
 89 2020-06-11T05:08:09  *** S3RK has quit IRC
 90 2020-06-11T05:32:00  *** bitcoin-git has joined #bitcoin-core-dev
 91 2020-06-11T05:32:01  <bitcoin-git> [bitcoin] hebasto closed pull request #19238: refactor: Replace RecursiveMutex with Mutex in CAddrMan (master...200610-addrman-mx) https://github.com/bitcoin/bitcoin/pull/19238
 92 2020-06-11T05:32:01  *** bitcoin-git has left #bitcoin-core-dev
 93 2020-06-11T05:32:20  *** bitcoin-git has joined #bitcoin-core-dev
 94 2020-06-11T05:32:21  <bitcoin-git> [bitcoin] hebasto reopened pull request #19238: refactor: Replace RecursiveMutex with Mutex in CAddrMan (master...200610-addrman-mx) https://github.com/bitcoin/bitcoin/pull/19238
 95 2020-06-11T05:32:21  *** bitcoin-git has left #bitcoin-core-dev
 96 2020-06-11T05:37:47  *** endogenic has quit IRC
 97 2020-06-11T05:37:57  *** CodeShark___ has quit IRC
 98 2020-06-11T05:38:05  *** endogenic has joined #bitcoin-core-dev
 99 2020-06-11T05:38:15  *** CodeShark___ has joined #bitcoin-core-dev
100 2020-06-11T05:38:22  *** digi_james has quit IRC
101 2020-06-11T05:38:37  *** digi_james has joined #bitcoin-core-dev
102 2020-06-11T06:00:02  *** meltheadorable has quit IRC
103 2020-06-11T06:21:57  *** engil1 has joined #bitcoin-core-dev
104 2020-06-11T06:28:19  *** sdaftuar has quit IRC
105 2020-06-11T06:28:42  *** sdaftuar has joined #bitcoin-core-dev
106 2020-06-11T06:30:00  *** justanotheruser has quit IRC
107 2020-06-11T06:34:41  *** S3RK has joined #bitcoin-core-dev
108 2020-06-11T06:39:03  *** harrigan has quit IRC
109 2020-06-11T06:39:04  *** S3RK has quit IRC
110 2020-06-11T06:39:44  *** harrigan has joined #bitcoin-core-dev
111 2020-06-11T06:55:28  *** stackingcore21_ has joined #bitcoin-core-dev
112 2020-06-11T06:56:06  *** justanotheruser has joined #bitcoin-core-dev
113 2020-06-11T06:56:23  *** stackingcore21 has quit IRC
114 2020-06-11T07:02:52  *** windsok has quit IRC
115 2020-06-11T07:05:08  *** jarthur_ has quit IRC
116 2020-06-11T07:05:42  *** windsok has joined #bitcoin-core-dev
117 2020-06-11T07:05:42  *** windsok has joined #bitcoin-core-dev
118 2020-06-11T07:22:58  *** bitcoin-git has joined #bitcoin-core-dev
119 2020-06-11T07:22:59  <bitcoin-git> [bitcoin] luke-jr opened pull request #19243: banman: Limit resources consumed by misbehaving node deprioitisation (master...misbehaving_limit) https://github.com/bitcoin/bitcoin/pull/19243
120 2020-06-11T07:23:00  *** bitcoin-git has left #bitcoin-core-dev
121 2020-06-11T07:23:53  *** SiAnDoG has joined #bitcoin-core-dev
122 2020-06-11T07:35:10  *** kabaum has joined #bitcoin-core-dev
123 2020-06-11T07:36:41  <luke-jr> is it just me, or do we currently have a bug where a misbehaving node makes itself immune to a real/user-set ban less than 24 hours long?
124 2020-06-11T07:37:28  <luke-jr> also, is there any realistic way to write functional tests for many misbehaving nodes? XD
125 2020-06-11T07:37:40  <luke-jr> (or even a handful..)
126 2020-06-11T07:37:50  *** Guyver2 has joined #bitcoin-core-dev
127 2020-06-11T07:54:47  *** tryphe has quit IRC
128 2020-06-11T07:55:13  *** tryphe has joined #bitcoin-core-dev
129 2020-06-11T07:55:43  *** braydonf has quit IRC
130 2020-06-11T07:57:43  *** braydonf has joined #bitcoin-core-dev
131 2020-06-11T08:15:46  *** sipsorcery has quit IRC
132 2020-06-11T08:22:55  *** justan0theruser has joined #bitcoin-core-dev
133 2020-06-11T08:25:48  *** justanotheruser has quit IRC
134 2020-06-11T08:31:19  *** Pavlenex has joined #bitcoin-core-dev
135 2020-06-11T08:33:29  *** AaronvanW has joined #bitcoin-core-dev
136 2020-06-11T08:37:45  *** luke-jr has quit IRC
137 2020-06-11T08:38:37  *** luke-jr has joined #bitcoin-core-dev
138 2020-06-11T08:38:40  *** bitcoin-git has joined #bitcoin-core-dev
139 2020-06-11T08:38:42  <bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/6762a627ecb8...45a6811d36fc
140 2020-06-11T08:38:42  <bitcoin-git> bitcoin/master faedb50 MarcoFalke: test: pep-8 mining_basic
141 2020-06-11T08:38:44  <bitcoin-git> bitcoin/master fa98e10 MarcoFalke: test: Remove leftover comment in mining_basic
142 2020-06-11T08:38:44  <bitcoin-git> bitcoin/master 45a6811 fanquake: Merge #19206: test: Remove leftover comment in mining_basic
143 2020-06-11T08:38:46  *** bitcoin-git has left #bitcoin-core-dev
144 2020-06-11T08:39:00  *** bitcoin-git has joined #bitcoin-core-dev
145 2020-06-11T08:39:00  <bitcoin-git> [bitcoin] fanquake merged pull request #19206: test: Remove leftover comment in mining_basic (master...2006-testComment) https://github.com/bitcoin/bitcoin/pull/19206
146 2020-06-11T08:39:01  *** bitcoin-git has left #bitcoin-core-dev
147 2020-06-11T08:43:09  *** windsok has quit IRC
148 2020-06-11T08:44:23  *** windsok has joined #bitcoin-core-dev
149 2020-06-11T08:55:11  *** justan0theruser has quit IRC
150 2020-06-11T08:55:19  *** justanotheruser has joined #bitcoin-core-dev
151 2020-06-11T09:00:02  *** engil1 has quit IRC
152 2020-06-11T09:05:39  *** jarthur has joined #bitcoin-core-dev
153 2020-06-11T09:10:56  *** jarthur has quit IRC
154 2020-06-11T09:21:48  *** Waithamai has joined #bitcoin-core-dev
155 2020-06-11T09:22:12  *** Waithamai is now known as Guest65675
156 2020-06-11T09:48:34  *** S3RK has joined #bitcoin-core-dev
157 2020-06-11T09:56:41  *** S3RK has quit IRC
158 2020-06-11T10:01:05  *** S3RK has joined #bitcoin-core-dev
159 2020-06-11T10:05:20  *** Marie16Stracke has joined #bitcoin-core-dev
160 2020-06-11T10:08:27  *** awesome-doge has joined #bitcoin-core-dev
161 2020-06-11T10:10:10  *** Marie16Stracke has quit IRC
162 2020-06-11T10:12:03  *** S3RK has quit IRC
163 2020-06-11T10:16:10  *** promag has joined #bitcoin-core-dev
164 2020-06-11T10:21:22  *** Asbestos_Vapor has joined #bitcoin-core-dev
165 2020-06-11T10:25:04  *** promag has quit IRC
166 2020-06-11T10:25:41  *** Mercury_Vapor has quit IRC
167 2020-06-11T10:25:52  *** promag has joined #bitcoin-core-dev
168 2020-06-11T10:27:53  *** promag_ has joined #bitcoin-core-dev
169 2020-06-11T10:27:53  *** promag has quit IRC
170 2020-06-11T10:28:23  *** S3RK has joined #bitcoin-core-dev
171 2020-06-11T10:51:23  *** rafalcpp has joined #bitcoin-core-dev
172 2020-06-11T10:53:11  *** Relis has joined #bitcoin-core-dev
173 2020-06-11T11:02:46  *** Relis has quit IRC
174 2020-06-11T11:06:16  *** Pavlenex has quit IRC
175 2020-06-11T11:06:52  *** jarthur has joined #bitcoin-core-dev
176 2020-06-11T11:12:03  *** jarthur has quit IRC
177 2020-06-11T11:27:07  *** S3RK has quit IRC
178 2020-06-11T11:27:34  *** S3RK has joined #bitcoin-core-dev
179 2020-06-11T11:29:49  *** S3RK has quit IRC
180 2020-06-11T11:29:56  *** S3RK has joined #bitcoin-core-dev
181 2020-06-11T11:39:34  *** Relis has joined #bitcoin-core-dev
182 2020-06-11T11:40:03  *** S3RK has quit IRC
183 2020-06-11T11:40:05  *** bitcoin-git has joined #bitcoin-core-dev
184 2020-06-11T11:40:05  <bitcoin-git> [bitcoin] kiminuo opened pull request #19245: [WIP DONOTMERGE] Replace boost::filesystem with std::filesystem (in c++17) (master...feature/2020-06-replace-boost-filesystem-with-cpp17-filesystem) https://github.com/bitcoin/bitcoin/pull/19245
185 2020-06-11T11:40:06  *** bitcoin-git has left #bitcoin-core-dev
186 2020-06-11T11:40:30  *** S3RK has joined #bitcoin-core-dev
187 2020-06-11T11:42:30  *** Kiminuo has joined #bitcoin-core-dev
188 2020-06-11T11:45:25  *** bitdex has quit IRC
189 2020-06-11T11:47:05  *** S3RK has quit IRC
190 2020-06-11T11:57:32  *** owowo has quit IRC
191 2020-06-11T11:58:11  *** belcher has joined #bitcoin-core-dev
192 2020-06-11T12:00:02  *** Guest65675 has quit IRC
193 2020-06-11T12:02:25  *** owowo has joined #bitcoin-core-dev
194 2020-06-11T12:09:26  *** rafalcpp has quit IRC
195 2020-06-11T12:11:42  *** justanotheruser has quit IRC
196 2020-06-11T12:14:05  *** Guyver2 has quit IRC
197 2020-06-11T12:15:12  *** justanotheruser has joined #bitcoin-core-dev
198 2020-06-11T12:22:14  *** izaki1 has joined #bitcoin-core-dev
199 2020-06-11T12:25:31  *** S3RK has joined #bitcoin-core-dev
200 2020-06-11T12:30:16  *** rafalcpp has joined #bitcoin-core-dev
201 2020-06-11T12:32:11  *** prusnak has quit IRC
202 2020-06-11T12:32:24  *** prusnak has joined #bitcoin-core-dev
203 2020-06-11T12:32:40  *** hugohn has quit IRC
204 2020-06-11T12:32:46  *** schmidty has quit IRC
205 2020-06-11T12:32:54  *** hugohn has joined #bitcoin-core-dev
206 2020-06-11T12:33:03  *** arik__ has quit IRC
207 2020-06-11T12:33:04  *** schmidty has joined #bitcoin-core-dev
208 2020-06-11T12:33:05  *** pierre_rochard has quit IRC
209 2020-06-11T12:33:05  *** jkczyz has quit IRC
210 2020-06-11T12:33:05  *** amiti has quit IRC
211 2020-06-11T12:33:06  *** michagogo has quit IRC
212 2020-06-11T12:33:07  *** vfP56jSe has quit IRC
213 2020-06-11T12:33:25  *** arik__ has joined #bitcoin-core-dev
214 2020-06-11T12:33:27  *** jkczyz has joined #bitcoin-core-dev
215 2020-06-11T12:33:27  *** amiti has joined #bitcoin-core-dev
216 2020-06-11T12:33:27  *** pierre_rochard has joined #bitcoin-core-dev
217 2020-06-11T12:33:27  *** vfP56jSe has joined #bitcoin-core-dev
218 2020-06-11T12:33:47  *** michagogo has joined #bitcoin-core-dev
219 2020-06-11T12:36:14  *** S3RK has quit IRC
220 2020-06-11T12:38:34  *** pretyflaco has joined #bitcoin-core-dev
221 2020-06-11T12:43:38  *** troygiorshev has joined #bitcoin-core-dev
222 2020-06-11T13:02:39  *** troygiorshev has quit IRC
223 2020-06-11T13:02:59  *** troygiorshev has joined #bitcoin-core-dev
224 2020-06-11T13:07:59  *** jarthur has joined #bitcoin-core-dev
225 2020-06-11T13:11:05  *** bitcoin-git has joined #bitcoin-core-dev
226 2020-06-11T13:11:06  <bitcoin-git> [bitcoin] practicalswift opened pull request #19247: tests: Add fuzzing harness for {Read,Write}{LE,BE}{16,32,64} (crypto/common.h) (master...fuzzers-crypto_common) https://github.com/bitcoin/bitcoin/pull/19247
227 2020-06-11T13:11:06  *** bitcoin-git has left #bitcoin-core-dev
228 2020-06-11T13:12:19  *** rafalcpp has quit IRC
229 2020-06-11T13:12:48  *** jarthur has quit IRC
230 2020-06-11T13:27:53  *** rafalcpp has joined #bitcoin-core-dev
231 2020-06-11T13:39:39  *** dfmb_ has joined #bitcoin-core-dev
232 2020-06-11T13:39:59  *** dfmb_ has quit IRC
233 2020-06-11T13:54:10  *** bitcoin-git has joined #bitcoin-core-dev
234 2020-06-11T13:54:11  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/45a6811d36fc...7a24cca82906
235 2020-06-11T13:54:11  <bitcoin-git> bitcoin/master f42f5e5 Russell Yanofsky: refactor: Combine GetWalletForJSONRPCRequest and EnsureWalletIsAvailable f...
236 2020-06-11T13:54:11  <bitcoin-git> bitcoin/master 7a24cca MarcoFalke: Merge #19100: refactor: Combine GetWalletForJSONRPCRequest and EnsureWalle...
237 2020-06-11T13:54:12  *** bitcoin-git has left #bitcoin-core-dev
238 2020-06-11T13:54:30  *** bitcoin-git has joined #bitcoin-core-dev
239 2020-06-11T13:54:31  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #19100: refactor: Combine GetWalletForJSONRPCRequest and EnsureWalletIsAvailable functions (master...pr/ensa) https://github.com/bitcoin/bitcoin/pull/19100
240 2020-06-11T13:54:31  *** bitcoin-git has left #bitcoin-core-dev
241 2020-06-11T14:06:39  *** bitcoin-git has joined #bitcoin-core-dev
242 2020-06-11T14:06:39  <bitcoin-git> [bitcoin] hebasto opened pull request #19249: Add means to handle negative capabilities in the Clang Thread Safety annotations (master...200611-nc) https://github.com/bitcoin/bitcoin/pull/19249
243 2020-06-11T14:06:40  *** bitcoin-git has left #bitcoin-core-dev
244 2020-06-11T14:09:38  *** proofofkeags has joined #bitcoin-core-dev
245 2020-06-11T14:20:59  *** Kiminuo has quit IRC
246 2020-06-11T14:25:13  *** bitcoin-git has joined #bitcoin-core-dev
247 2020-06-11T14:25:13  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #19250: wallet: [move-only bugfix] Make RPC help compile-time static (master...2006-rpcWalletHelp) https://github.com/bitcoin/bitcoin/pull/19250
248 2020-06-11T14:25:14  *** bitcoin-git has left #bitcoin-core-dev
249 2020-06-11T14:34:30  *** Kiminuo has joined #bitcoin-core-dev
250 2020-06-11T14:37:57  *** real_or_random has quit IRC
251 2020-06-11T14:38:20  *** real_or_random has joined #bitcoin-core-dev
252 2020-06-11T14:44:47  *** mol_ has quit IRC
253 2020-06-11T14:49:50  *** Pavlenex has joined #bitcoin-core-dev
254 2020-06-11T15:00:01  *** izaki1 has quit IRC
255 2020-06-11T15:08:44  *** jarthur has joined #bitcoin-core-dev
256 2020-06-11T15:13:36  *** jarthur has quit IRC
257 2020-06-11T15:22:23  *** llamma1 has joined #bitcoin-core-dev
258 2020-06-11T15:22:28  *** mol has joined #bitcoin-core-dev
259 2020-06-11T15:22:47  *** midnight has quit IRC
260 2020-06-11T15:23:17  *** jarthur has joined #bitcoin-core-dev
261 2020-06-11T15:25:32  <hebasto> please remind how to propose a meeting topic in advance?
262 2020-06-11T15:26:15  <achow101> hebasto: using #proposedmeetingtopic
263 2020-06-11T15:26:27  <hebasto> achow101: thanks
264 2020-06-11T15:27:25  <hebasto> #proposedmeetingtopic Bump minimum required Clang version to 3.5
265 2020-06-11T15:27:48  <hebasto> ^ in the context of #19249
266 2020-06-11T15:27:50  <gribble> https://github.com/bitcoin/bitcoin/issues/19249 | Add means to handle negative capabilities in the Clang Thread Safety annotations by hebasto · Pull Request #19249 · bitcoin/bitcoin · GitHub
267 2020-06-11T15:32:59  *** Relis has quit IRC
268 2020-06-11T15:34:25  *** sipsorcery has joined #bitcoin-core-dev
269 2020-06-11T15:41:56  *** troygiorshev has quit IRC
270 2020-06-11T15:42:30  *** jarthur has quit IRC
271 2020-06-11T15:43:46  *** Relis has joined #bitcoin-core-dev
272 2020-06-11T15:43:53  *** bitcoin-git has joined #bitcoin-core-dev
273 2020-06-11T15:43:53  <bitcoin-git> [bitcoin] hebasto opened pull request #19251: [Do Not Merge] ci: Temporary Test Case for negative capabilities in the Clang Thread Safety annotations (master...200611-dnm-test) https://github.com/bitcoin/bitcoin/pull/19251
274 2020-06-11T15:43:54  *** bitcoin-git has left #bitcoin-core-dev
275 2020-06-11T15:46:13  *** justanotheruser has quit IRC
276 2020-06-11T15:47:42  *** jarthur has joined #bitcoin-core-dev
277 2020-06-11T15:47:48  *** midnight has joined #bitcoin-core-dev
278 2020-06-11T15:52:48  *** troygiorshev has joined #bitcoin-core-dev
279 2020-06-11T16:02:16  *** justanotheruser has joined #bitcoin-core-dev
280 2020-06-11T16:05:36  *** Talkless has joined #bitcoin-core-dev
281 2020-06-11T16:13:37  *** S3RK has joined #bitcoin-core-dev
282 2020-06-11T16:20:39  *** vasild_ has joined #bitcoin-core-dev
283 2020-06-11T16:23:43  *** vasild has quit IRC
284 2020-06-11T16:23:44  *** vasild_ is now known as vasild
285 2020-06-11T16:32:13  <wumpus> I think we should bump compiler versions after C++17, not bother witht it sooner
286 2020-06-11T16:32:31  <wumpus> no need to complicate this with multiple bumps
287 2020-06-11T16:38:58  <wumpus> but note that #16684 has no mention of clang versions
288 2020-06-11T16:39:00  <gribble> https://github.com/bitcoin/bitcoin/issues/16684 | Discussion: upgrading to C++17 · Issue #16684 · bitcoin/bitcoin · GitHub
289 2020-06-11T16:39:17  <wumpus> I think we need to determine what clang version to require as minimum then
290 2020-06-11T16:39:44  *** justanotheruser has quit IRC
291 2020-06-11T16:41:44  *** pretyflaco1 has joined #bitcoin-core-dev
292 2020-06-11T16:41:46  <sipa> clang advertizes full c++17 support as of version 5
293 2020-06-11T16:41:59  <sipa> but it seems nearly all features are present in 4
294 2020-06-11T16:44:12  *** troygiorshev has quit IRC
295 2020-06-11T16:44:16  *** pretyflaco has quit IRC
296 2020-06-11T16:44:31  *** troygiorshev has joined #bitcoin-core-dev
297 2020-06-11T16:44:48  *** guest534543 has joined #bitcoin-core-dev
298 2020-06-11T16:47:21  <wumpus> right: https://clang.llvm.org/cxx_status.html#cxx17  and some (more obscure?) things are only in 9/10
299 2020-06-11T16:47:24  <hebasto> wumpus: yes, C++17 is near. Do you mean 19249 should be dropped for now, or could move on without clang version bumping?
300 2020-06-11T16:47:42  <wumpus> hebasto: if you can make it optional
301 2020-06-11T16:48:14  *** Kiminuo has quit IRC
302 2020-06-11T16:48:16  <wumpus> I think we should let the minimum version also depend on what is generally available in Linux distros' to make sure we can test against it easily
303 2020-06-11T16:48:18  <hebasto> that is the problem: make it optional will clutter the code
304 2020-06-11T16:48:35  <wumpus> hebasto: then I'd say delay it until a bump is needed for c++17
305 2020-06-11T16:49:00  <hebasto> jessie 3.5; xenial 3.8
306 2020-06-11T16:50:46  *** troygiorshev has quit IRC
307 2020-06-11T16:51:06  *** troygiorshev has joined #bitcoin-core-dev
308 2020-06-11T16:51:33  *** bitcoin-git has joined #bitcoin-core-dev
309 2020-06-11T16:51:34  <bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/7a24cca82906...85f7db22841e
310 2020-06-11T16:51:35  <bitcoin-git> bitcoin/master e380818 John Newbery: Revert "[TESTS] Move base58 to own module to break circular dependency"
311 2020-06-11T16:51:36  <bitcoin-git> bitcoin/master b216b0b John Newbery: [tests] sort imports in rpc_createmultisig.py
312 2020-06-11T16:51:36  <bitcoin-git> bitcoin/master 3a83a01 John Newbery: [tests] move generate_wif_key to wallet_util.py
313 2020-06-11T16:51:38  *** bitcoin-git has left #bitcoin-core-dev
314 2020-06-11T16:51:53  *** bitcoin-git has joined #bitcoin-core-dev
315 2020-06-11T16:51:53  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #19239: tests: move generate_wif_key to wallet_util.py (master...2020-06-generate-wif-key) https://github.com/bitcoin/bitcoin/pull/19239
316 2020-06-11T16:51:54  *** bitcoin-git has left #bitcoin-core-dev
317 2020-06-11T16:52:24  <wumpus> hebasto: you might want to post that into the c++17 issue
318 2020-06-11T16:57:20  *** roconnor has quit IRC
319 2020-06-11T17:01:02  *** bitcoin-git has joined #bitcoin-core-dev
320 2020-06-11T17:01:02  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/85f7db22841e...8682414d0238
321 2020-06-11T17:01:02  <bitcoin-git> bitcoin/master 4a8181b practicalswift: tests: Add std::vector<uint8_t> ConsumeFixedLengthByteVector(FuzzedDataPro...
322 2020-06-11T17:01:03  <bitcoin-git> bitcoin/master cf5b8f6 practicalswift: tests: Add fuzzing harness for {Read,Write}{LE,BE}{16,32,64} (crypto/commo...
323 2020-06-11T17:01:03  <bitcoin-git> bitcoin/master 8682414 MarcoFalke: Merge #19247: tests: Add fuzzing harness for {Read,Write}{LE,BE}{16,32,64}...
324 2020-06-11T17:01:04  *** bitcoin-git has left #bitcoin-core-dev
325 2020-06-11T17:01:21  *** bitcoin-git has joined #bitcoin-core-dev
326 2020-06-11T17:01:22  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #19247: tests: Add fuzzing harness for {Read,Write}{LE,BE}{16,32,64} (crypto/common.h) (master...fuzzers-crypto_common) https://github.com/bitcoin/bitcoin/pull/19247
327 2020-06-11T17:01:23  *** bitcoin-git has left #bitcoin-core-dev
328 2020-06-11T17:02:14  <wumpus> hebasto: thanks for doing the research though, let's discuss it further in the meeting
329 2020-06-11T17:03:28  *** icota[m] has joined #bitcoin-core-dev
330 2020-06-11T17:04:46  *** ExEric3 has joined #bitcoin-core-dev
331 2020-06-11T17:04:49  *** troygiorshev has quit IRC
332 2020-06-11T17:05:07  *** troygiorshev has joined #bitcoin-core-dev
333 2020-06-11T17:08:02  *** Guyver2 has joined #bitcoin-core-dev
334 2020-06-11T17:10:37  *** troygiorshev has quit IRC
335 2020-06-11T17:10:51  *** troygiorshev has joined #bitcoin-core-dev
336 2020-06-11T17:25:03  *** ghost43 has quit IRC
337 2020-06-11T17:25:24  *** ghost43 has joined #bitcoin-core-dev
338 2020-06-11T17:31:44  *** mol_ has joined #bitcoin-core-dev
339 2020-06-11T17:33:05  *** troygiorshev has quit IRC
340 2020-06-11T17:33:24  *** troygiorshev has joined #bitcoin-core-dev
341 2020-06-11T17:34:30  *** molz_ has joined #bitcoin-core-dev
342 2020-06-11T17:35:02  *** mol has quit IRC
343 2020-06-11T17:35:34  *** molz_ has quit IRC
344 2020-06-11T17:35:55  *** molz_ has joined #bitcoin-core-dev
345 2020-06-11T17:36:09  *** rafalcpp has quit IRC
346 2020-06-11T17:36:15  *** justanotheruser has joined #bitcoin-core-dev
347 2020-06-11T17:37:00  *** molz_ has quit IRC
348 2020-06-11T17:37:24  *** molz_ has joined #bitcoin-core-dev
349 2020-06-11T17:37:41  *** proofofkeags has quit IRC
350 2020-06-11T17:38:14  *** mol_ has quit IRC
351 2020-06-11T17:38:16  *** proofofkeags has joined #bitcoin-core-dev
352 2020-06-11T17:38:41  *** rafalcpp has joined #bitcoin-core-dev
353 2020-06-11T17:39:58  *** Guyver2_ has joined #bitcoin-core-dev
354 2020-06-11T17:42:32  *** Guyver2 has quit IRC
355 2020-06-11T17:42:50  *** molz_ has quit IRC
356 2020-06-11T17:42:56  *** proofofkeags has quit IRC
357 2020-06-11T17:43:20  *** Guyver2_ is now known as Guyver2
358 2020-06-11T17:44:45  *** troygiorshev has quit IRC
359 2020-06-11T17:45:13  *** troygiorshev has joined #bitcoin-core-dev
360 2020-06-11T17:45:32  *** isis_ is now known as isis
361 2020-06-11T17:45:46  *** proofofkeags has joined #bitcoin-core-dev
362 2020-06-11T17:47:44  *** rafalcpp has quit IRC
363 2020-06-11T17:50:26  *** mol has joined #bitcoin-core-dev
364 2020-06-11T17:51:37  *** troygiorshev has quit IRC
365 2020-06-11T17:52:36  *** troygiorshev has joined #bitcoin-core-dev
366 2020-06-11T17:53:50  *** dviola has quit IRC
367 2020-06-11T17:54:01  *** troygiorshev has joined #bitcoin-core-dev
368 2020-06-11T18:00:02  *** llamma1 has quit IRC
369 2020-06-11T18:03:46  *** bitcoin-git has joined #bitcoin-core-dev
370 2020-06-11T18:03:46  <bitcoin-git> [bitcoin] gzhao408 opened pull request #19252: [wip] test: wait for disconnect in disconnect_p2ps + bloomfilter test followups (master...test-disconnect-p2ps-wait) https://github.com/bitcoin/bitcoin/pull/19252
371 2020-06-11T18:03:47  *** bitcoin-git has left #bitcoin-core-dev
372 2020-06-11T18:07:15  *** bitcoin-git has joined #bitcoin-core-dev
373 2020-06-11T18:07:15  <bitcoin-git> [bitcoin] jnewbery opened pull request #19253: Tests: tidy up address.py and segwit_addr.py (master...2020-06-addr-unit-tests) https://github.com/bitcoin/bitcoin/pull/19253
374 2020-06-11T18:07:16  *** bitcoin-git has left #bitcoin-core-dev
375 2020-06-11T18:13:36  *** dr-orlovsky has joined #bitcoin-core-dev
376 2020-06-11T18:13:57  *** rafalcpp has joined #bitcoin-core-dev
377 2020-06-11T18:16:05  *** guest534543 has quit IRC
378 2020-06-11T18:16:26  *** Kiminuo has joined #bitcoin-core-dev
379 2020-06-11T18:20:38  *** jtk has joined #bitcoin-core-dev
380 2020-06-11T18:22:24  *** Dean_Guss has quit IRC
381 2020-06-11T18:26:22  *** gleb has joined #bitcoin-core-dev
382 2020-06-11T18:29:18  *** Dean_Guss has joined #bitcoin-core-dev
383 2020-06-11T18:37:01  *** bitcoin-git has joined #bitcoin-core-dev
384 2020-06-11T18:37:03  <bitcoin-git> [bitcoin] MarcoFalke pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/8682414d0238...b33136b6ba98
385 2020-06-11T18:37:03  <bitcoin-git> bitcoin/master e8acc60 gzhao408: [test] add mempool msg test for node with bloomfilter enabled
386 2020-06-11T18:37:04  <bitcoin-git> bitcoin/master 497a619 gzhao408: [test] add BIP 37 test for node with fRelay=false
387 2020-06-11T18:37:05  <bitcoin-git> bitcoin/master 4ef80f0 gzhao408: [test] sending invalid msgs to node with bloomfilters=0 causes disconnect
388 2020-06-11T18:37:07  *** bitcoin-git has left #bitcoin-core-dev
389 2020-06-11T18:37:21  *** bitcoin-git has joined #bitcoin-core-dev
390 2020-06-11T18:37:21  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #19083: test: msg_mempool, fRelay, and other bloomfilter tests (master...test-bloomfilter) https://github.com/bitcoin/bitcoin/pull/19083
391 2020-06-11T18:37:22  *** bitcoin-git has left #bitcoin-core-dev
392 2020-06-11T18:40:26  *** rafalcpp has quit IRC
393 2020-06-11T18:47:22  *** danielyin has joined #bitcoin-core-dev
394 2020-06-11T18:47:49  *** danielyi1 has joined #bitcoin-core-dev
395 2020-06-11T18:52:48  *** danielyin has quit IRC
396 2020-06-11T18:52:49  *** danielyi1 has quit IRC
397 2020-06-11T18:53:11  *** danielyin has joined #bitcoin-core-dev
398 2020-06-11T18:57:29  *** gimballock has joined #bitcoin-core-dev
399 2020-06-11T18:59:36  <phantomcircuit> MarcoFalke, are you the wallet maintainer?
400 2020-06-11T18:59:47  <MarcoFalke> no :shock:
401 2020-06-11T18:59:51  <jonasschnelli> phantomcircuit: meshcollider
402 2020-06-11T19:00:17  <meshcollider> Hi :)
403 2020-06-11T19:00:18  <wumpus> #startmeeting
404 2020-06-11T19:00:18  <lightningbot> Meeting started Thu Jun 11 19:00:18 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
405 2020-06-11T19:00:18  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
406 2020-06-11T19:00:21  <achow101> hi
407 2020-06-11T19:00:24  <jonasschnelli> hi
408 2020-06-11T19:00:30  <hebasto> hi
409 2020-06-11T19:00:31  <kanzure> hi
410 2020-06-11T19:00:34  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james amiti fjahr
411 2020-06-11T19:00:34  <wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
412 2020-06-11T19:00:35  <jeremyrubin> hola
413 2020-06-11T19:00:37  <fjahr> hi
414 2020-06-11T19:00:48  <meshcollider> hi
415 2020-06-11T19:00:48  <jamesob> hi
416 2020-06-11T19:01:15  <jonatack> hi
417 2020-06-11T19:01:16  <amiti> hi
418 2020-06-11T19:01:17  <gleb> hi
419 2020-06-11T19:01:28  <wumpus> hi
420 2020-06-11T19:01:33  <sipa> hi
421 2020-06-11T19:01:36  <troygiorshev> hi
422 2020-06-11T19:01:57  <jnewbery> hi
423 2020-06-11T19:02:13  <MarcoFalke> hi
424 2020-06-11T19:02:15  <gwillen> hi
425 2020-06-11T19:02:54  <jkczyz> hi
426 2020-06-11T19:02:55  <wumpus> one proposed topic: Bump minimum required Clang version to 3.5 (hebasto)
427 2020-06-11T19:03:19  <dongcarl> hebasto: links?
428 2020-06-11T19:03:21  <MarcoFalke> As I posted in the thread, debian oldoldstable is on clang-4
429 2020-06-11T19:03:22  <wumpus> (you can propose topics between meetings with #proposedmeetingtopic, or now before the meeting)
430 2020-06-11T19:03:42  <MarcoFalke> Not sure why this is so controversial
431 2020-06-11T19:03:47  <wumpus> please wait with discussion about the topic until the topic
432 2020-06-11T19:03:50  <MarcoFalke> sorry
433 2020-06-11T19:03:56  <dongcarl> sry
434 2020-06-11T19:04:10  <jeremyrubin> #proposedmeetingtopic feature detection API
435 2020-06-11T19:04:34  <wumpus> yeah you don't have to use that tag inside the meeting we see it :)
436 2020-06-11T19:04:56  <jeremyrubin> (i think it helps for grepping logs)
437 2020-06-11T19:04:57  <wumpus> #topic High priority for review
438 2020-06-11T19:05:16  <gleb> Could I nominate #18991 for blockers? I think it's a big improvement for p2p privacy, and it would also unlock me from further work on AddrMan.
439 2020-06-11T19:05:19  <gribble> https://github.com/bitcoin/bitcoin/issues/18991 | Cache responses to GETADDR to prevent topology leaks by naumenkogs · Pull Request #18991 · bitcoin/bitcoin · GitHub
440 2020-06-11T19:05:24  <wumpus> 13(!) blockers, 0 bugfixes, 3 items chasing ACK https://github.com/bitcoin/bitcoin/projects/8
441 2020-06-11T19:05:40  <gleb> Oh i see....
442 2020-06-11T19:06:02  <jamesob> if anyone wants to see forward motion on assumeutxo, #18637 is the one to review
443 2020-06-11T19:06:05  <gribble> https://github.com/bitcoin/bitcoin/issues/18637 | coins: allow cache resize after init by jamesob · Pull Request #18637 · bitcoin/bitcoin · GitHub
444 2020-06-11T19:06:22  <MarcoFalke> I'd like to add #19071
445 2020-06-11T19:06:24  <gribble> https://github.com/bitcoin/bitcoin/issues/19071 | doc: Separate repository for the gui by MarcoFalke · Pull Request #19071 · bitcoin/bitcoin · GitHub
446 2020-06-11T19:06:26  <MarcoFalke> Not sure what is left there
447 2020-06-11T19:06:40  <wumpus> gleb: added
448 2020-06-11T19:07:25  <MarcoFalke> Mine is not a blocker, so feel free to ignore ;)
449 2020-06-11T19:07:46  <gleb> thank you! We need couple more eyes on #18991. It's a little code with big impact, not much prior knowledge required but it would expose you to the logic of addr relay! So really nice to review please come :)
450 2020-06-11T19:07:48  *** ghost43 has quit IRC
451 2020-06-11T19:07:49  <gribble> https://github.com/bitcoin/bitcoin/issues/18991 | Cache responses to GETADDR to prevent topology leaks by naumenkogs · Pull Request #18991 · bitcoin/bitcoin · GitHub
452 2020-06-11T19:07:56  <wumpus> 18637 is already in there
453 2020-06-11T19:08:59  <wumpus> 19071 added
454 2020-06-11T19:09:04  *** proofofkeags has quit IRC
455 2020-06-11T19:09:04  <jamesob> wumupus: yep just additional heads-up since people seem to ask about where the project's at from time to time
456 2020-06-11T19:09:05  <jnewbery> #proposedmeetingtopic Add Really Really High Priority For Review project
457 2020-06-11T19:09:08  *** ghost43 has joined #bitcoin-core-dev
458 2020-06-11T19:09:12  <jamesob> haha
459 2020-06-11T19:09:18  <wumpus> oh noooo
460 2020-06-11T19:09:37  *** proofofkeags has joined #bitcoin-core-dev
461 2020-06-11T19:09:52  <wumpus> sky high elite priority for review project
462 2020-06-11T19:10:19  <gleb> Jokes aside, maybe would be useful to re-iterate on the usability/usefulness of the high-prio stuff. Maybe PRs should expire from there or somehting.
463 2020-06-11T19:10:57  <jamesob> that's interesting. probably no way of doing automatic expiry with github though
464 2020-06-11T19:11:04  <jamesob> maybe drahtbot?
465 2020-06-11T19:11:14  *** Talkless has quit IRC
466 2020-06-11T19:11:16  <MarcoFalke> I found that putting something in high prio has no effect on review activity
467 2020-06-11T19:11:23  <wumpus> I don't think we need automatic expiry, let's just try to pay attention ourselves
468 2020-06-11T19:11:26  <gleb> I don't think it makes sense to automate such a low-latency thing.
469 2020-06-11T19:11:38  <gleb> Or rather low-bandwidth I should say.
470 2020-06-11T19:11:39  <wumpus> MarcoFalke: well at least I pay more attention to it, for what it's worth
471 2020-06-11T19:11:57  <gleb> I just wanted to make sure wumpus and co are comfortable with evicting things from tht list.
472 2020-06-11T19:11:59  <wumpus> although, the higher the number of things on there the less it matters I'd definiltly agree
473 2020-06-11T19:12:08  <jonatack> jnewbery: good point. when the list is short, i follow it. when it's long, i make my own list.
474 2020-06-11T19:12:29  <jeremyrubin> although review blocked, I am happy having a project
475 2020-06-11T19:12:29  <wumpus> I guess it's good that every contributor can propose something that's most important for them now
476 2020-06-11T19:12:52  <jeremyrubin> So maybe letting more contributors manage a project is better than the high prior for review as it is better to sort work
477 2020-06-11T19:13:02  <wumpus> I'm not sure that needs any bots or automatic expiry to be honest
478 2020-06-11T19:13:09  <MarcoFalke> Agree
479 2020-06-11T19:13:11  <jeremyrubin> Especially if the important-ness is blocking related, projects can help hilight the follow on work
480 2020-06-11T19:13:23  <jnewbery> wumpus: I agree. At the very least, it's useful for contributors to signal "this is _my_ highest priority PR right now"
481 2020-06-11T19:13:31  <hebasto> a bit more projects seems good
482 2020-06-11T19:13:31  <wumpus> jnewbery: exactly
483 2020-06-11T19:13:48  <gleb> jnewbery: only when people look at the list :)
484 2020-06-11T19:13:49  <jnewbery> but you shouldn't assume that anyone else cares :)
485 2020-06-11T19:14:04  <wumpus> if no one cares, no one cares, nothing to do about that
486 2020-06-11T19:14:22  *** kvaciral has joined #bitcoin-core-dev
487 2020-06-11T19:14:26  *** proofofkeags has quit IRC
488 2020-06-11T19:14:47  <fjahr> I think the length is ok. Reviewers just have to take a pick and often not all of them are relevant for oneself.
489 2020-06-11T19:15:02  <wumpus> it's, sometimes, kind of absurd sometimes how much money sails on this project compared to how little attention review gets, but it's only one of the many mysteries
490 2020-06-11T19:15:45  <jeremyrubin> wumpus: you need to tokenize review for that
491 2020-06-11T19:15:52  <MarcoFalke> For some high prio stuff I am unqualfied to review because I am lacking the background, so even forcing me to review wouldn't yield anything better than a "Concept ACK"
492 2020-06-11T19:16:10  <jeremyrubin> MarcoFalke: +1
493 2020-06-11T19:16:13  <wumpus> yes, I don't have any solutions either, that's what I meant
494 2020-06-11T19:16:41  <gleb> maybe lists per domain: wallet p2p mining consensus etc with a maintainer would make it efficient, i dunno.
495 2020-06-11T19:16:49  <jnewbery> wumpus: I expect there's more effort and time going into review on this project than at any point in the past
496 2020-06-11T19:16:59  <wumpus> jnewbery: I'm happy to hear that
497 2020-06-11T19:17:18  <wumpus> gleb: nah…
498 2020-06-11T19:17:28  <wumpus> you can already sort issues per label, you know
499 2020-06-11T19:17:31  <wumpus> and PRs
500 2020-06-11T19:17:59  <gleb> Right.
501 2020-06-11T19:18:07  <wumpus> I don't think high priority for review is suppsoed to become that long that it needs to be sorted into categories as well
502 2020-06-11T19:18:13  <wumpus> but who knows :-)
503 2020-06-11T19:18:36  <MarcoFalke> The number of open pull requests keeps growing ...
504 2020-06-11T19:18:40  <wumpus> I think one problem is the huge number of different concerns and aspects in one project
505 2020-06-11T19:18:46  <wumpus> but we've been over that
506 2020-06-11T19:19:11  <wumpus> #topic Bump minimum required Clang version to 3.5 (hebasto)
507 2020-06-11T19:19:15  <hebasto> hi
508 2020-06-11T19:19:18  <hebasto> negative capabilities in clang thread safety analysis are a great tool to prevent deadlocks
509 2020-06-11T19:19:36  <jonatack> I agree with it remaining ad hoc. Ideally people would not put non-blocking, non-completely review-ready PRs in the list, and pull their own PRs off if less high-priority than others.
510 2020-06-11T19:19:40  <wumpus> personally, I think we should hold off doing any compiler version bumps until C++17
511 2020-06-11T19:19:41  <hebasto> #19249
512 2020-06-11T19:19:43  <gribble> https://github.com/bitcoin/bitcoin/issues/19249 | Add means to handle negative capabilities in the Clang Thread Safety annotations by hebasto · Pull Request #19249 · bitcoin/bitcoin · GitHub
513 2020-06-11T19:19:59  <MarcoFalke> I think I misunderstood what the annotation do, so I will need to re-review the changes, but if they are useful, we shouldn't hold them back for 4 months.
514 2020-06-11T19:20:01  <hebasto> example of usage: #19238
515 2020-06-11T19:20:03  <gribble> https://github.com/bitcoin/bitcoin/issues/19238 | refactor: Replace RecursiveMutex with Mutex in CAddrMan by hebasto · Pull Request #19238 · bitcoin/bitcoin · GitHub
516 2020-06-11T19:20:31  <hebasto> example of error catching #19251
517 2020-06-11T19:20:33  <gribble> https://github.com/bitcoin/bitcoin/issues/19251 | [Do Not Merge] ci: Temporary Test Case for negative capabilities in the Clang Thread Safety annotations by hebasto · Pull Request #19251 · bitcoin/bitcoin · GitHub
518 2020-06-11T19:20:34  <MarcoFalke> no distro is using this ancient version of clang, and gcc is used by default to compile  anyway
519 2020-06-11T19:20:35  <wumpus> I don't think requiring *everyone* to use a newer compiler just for some annotations and checking is that great
520 2020-06-11T19:20:44  <sipa> wumpus: i have no strong opinion either way; bumping to (already such an old) new clang seems fairly low friction
521 2020-06-11T19:20:48  <hebasto> it requires clang 3.5+
522 2020-06-11T19:21:02  <MarcoFalke> wumpus: Is any os using pre-3.5 clang?
523 2020-06-11T19:21:06  <wumpus> if a few peopel compile with those annotations it aleady helps
524 2020-06-11T19:21:08  <dongcarl> https://repology.org/project/clang/versions
525 2020-06-11T19:21:10  <wumpus> it doesn't have to be everyone
526 2020-06-11T19:21:11  *** ajonas has quit IRC
527 2020-06-11T19:21:14  <sipa> but if we're going to do a big bump soon anyway, that's ok too
528 2020-06-11T19:21:15  <MarcoFalke> oldoldstable debian is on clang-4
529 2020-06-11T19:21:43  <sipa> clang 3.5 is from 2015
530 2020-06-11T19:21:44  *** adamjonas has joined #bitcoin-core-dev
531 2020-06-11T19:21:44  <wumpus> I'm not necessarily opposed to this specific bump, but I think we're spending too much time doing small bumps
532 2020-06-11T19:22:03  *** dviola has joined #bitcoin-core-dev
533 2020-06-11T19:22:20  <wumpus> I'd like to make an "ambitious" bump for C++17, it's a good rationale
534 2020-06-11T19:22:30  <MarcoFalke> This is merely a documentation change. It should have no effect in practice
535 2020-06-11T19:22:41  <hebasto> agree
536 2020-06-11T19:23:11  <wumpus> ok...
537 2020-06-11T19:23:18  <wumpus> I don't care strongly just update it then
538 2020-06-11T19:23:32  <wumpus> please don't come back next week that you need another bump though ;)
539 2020-06-11T19:23:32  <jeremyrubin> Personal note that I find the safety annotations really confusing
540 2020-06-11T19:23:47  <hebasto> which way?
541 2020-06-11T19:24:24  <hebasto> EXCLUSIVE_LOCKS_REQUIRED(!mutex) looks good and works well
542 2020-06-11T19:24:33  <MarcoFalke> if the change doesn't make it in because it is not worthwhile, clang won't be bumped
543 2020-06-11T19:25:00  <wumpus> I think it's worthwhile to check
544 2020-06-11T19:25:05  <wumpus> for compilers that support it
545 2020-06-11T19:25:13  <jeremyrubin> I don't quite know how to use them for some of the tasks that I would like to prove safe :) Would be interested to learn more; I have a couple examples where we over-lock and I'm not sure how to use the exclusive locks required negation to accomplish that
546 2020-06-11T19:25:16  <wumpus> I do not think it's a worthwhile reason to drop compilers that don't support it
547 2020-06-11T19:25:17  <jeremyrubin> We can take it offline though
548 2020-06-11T19:25:42  <wumpus> then again I'm not fanatic in supporting ancient stuff either
549 2020-06-11T19:26:03  <wumpus> if oldoldstable is already 4.0, let's require 4.09
550 2020-06-11T19:26:13  <wumpus> 4.0*
551 2020-06-11T19:26:39  <MarcoFalke> Anyway, let's first check if the annotations make sense
552 2020-06-11T19:27:02  <hebasto> examples are here #19238
553 2020-06-11T19:27:04  <gribble> https://github.com/bitcoin/bitcoin/issues/19238 | refactor: Replace RecursiveMutex with Mutex in CAddrMan by hebasto · Pull Request #19238 · bitcoin/bitcoin · GitHub
554 2020-06-11T19:27:24  <wumpus> but my point was, we *know* we're going to drop support for old compilers with C++17, so all time spend discussing bumps before that is probably wasted
555 2020-06-11T19:27:56  <hebasto> so 3.5 or 4.0 ?
556 2020-06-11T19:28:15  <wumpus> MarcoFalke: yes, let's be sure of that first
557 2020-06-11T19:28:32  <hebasto> ok
558 2020-06-11T19:28:55  <wumpus> #topic Feature detection API (jeremyrubin)
559 2020-06-11T19:29:42  <jeremyrubin> Not too much; but there was some discussion on this w.r.t. people building on top of core
560 2020-06-11T19:30:01  <jeremyrubin> That detecting which RPCs are available requires firing off a batch of RPCs and seeing what error codes come back
561 2020-06-11T19:30:08  <jeremyrubin> This is... suboptimal
562 2020-06-11T19:30:16  *** proofofkeags has joined #bitcoin-core-dev
563 2020-06-11T19:30:17  <MarcoFalke> jeremyrubin: Only with whitelists
564 2020-06-11T19:30:23  <jeremyrubin> MarcoFalke: no, all the time
565 2020-06-11T19:30:40  <jeremyrubin> BTCPayServer does this to detect features across versions on startup
566 2020-06-11T19:30:41  <jnewbery> doesn't the help RPC list all methods?
567 2020-06-11T19:30:53  <MarcoFalke> Yeah, what jnewbery said ^
568 2020-06-11T19:31:29  <jeremyrubin> But there's also a need to know what semantics/arguments are available and if the semantic has changed at all
569 2020-06-11T19:31:37  <wumpus> well you only have to do it once
570 2020-06-11T19:31:52  <MarcoFalke> jeremyrubin: The RPC version number is used for that
571 2020-06-11T19:31:54  <wumpus> it's only suboptimal if you have to do it all the time, in which case, you're probably doing something wrong
572 2020-06-11T19:31:56  <MarcoFalke> or you can parse the help
573 2020-06-11T19:32:18  <wumpus> yes, the RPC version number would be the thing to check for that
574 2020-06-11T19:32:27  <jeremyrubin> Yeah. I think it's more that we should expose some nicer way of doing this and filtering across the whitelists.
575 2020-06-11T19:32:32  <sipa> i wouldn't object to an RPC that returns all supported RPCs in JSON form
576 2020-06-11T19:32:39  <sipa> if that's what we're talking about
577 2020-06-11T19:32:40  <jnewbery> this seems to be part of integration testing if BTCPayServer or whatever starts using a new version
578 2020-06-11T19:32:47  <sipa> we already have that information ready anyway
579 2020-06-11T19:33:18  <jeremyrubin> Also the whitelists are non-interpreted, so they aren't that useful because you then need to replicate the whitelist algorithm locally from it
580 2020-06-11T19:33:32  <wumpus> would be nice to have a machine-interpratable version of the RPC help in general
581 2020-06-11T19:33:34  *** justanotheruser has quit IRC
582 2020-06-11T19:33:40  <jeremyrubin> I think there was also a desire to have per-RPC versioning
583 2020-06-11T19:33:44  <wumpus> this is an idea that has been around since 2012 or so
584 2020-06-11T19:33:44  <MarcoFalke> I am working on that
585 2020-06-11T19:33:50  <MarcoFalke> (the machine readable help)
586 2020-06-11T19:33:53  <jeremyrubin> Which IDK if it's super useful, but it was requested
587 2020-06-11T19:34:08  <dongcarl> machine-readable help would just be something like an OpenAPI spec?
588 2020-06-11T19:34:14  <jeremyrubin> It is nice to know if theres a breaking RPC change that you are aware on startup that there was a change
589 2020-06-11T19:34:18  <wumpus> per-rpc versioning? oh no, please don't make RPC versioning any more of a hassle as it is already
590 2020-06-11T19:34:50  <MarcoFalke> wumpus the rpc is versioned on the major version of Bitcoin Core https://github.com/bitcoin/bitcoin/blob/master/doc/JSON-RPC-interface.md
591 2020-06-11T19:34:53  *** proofofkeags has quit IRC
592 2020-06-11T19:34:55  <jeremyrubin> don't shoot the messenger. If it's an issue I'd rather just rename RPCs rpc_name_v1 when theres a change
593 2020-06-11T19:35:04  <wumpus> I don't get it, what does it pprovide on top of the global version number
594 2020-06-11T19:35:05  *** proofofkeags has joined #bitcoin-core-dev
595 2020-06-11T19:35:20  <MarcoFalke> oh, it is the same as the global version number
596 2020-06-11T19:35:25  <wumpus> in general, only major bitcoin core versions introduce breaking RPC changes
597 2020-06-11T19:35:57  <wumpus> (that's how it's supposed to be, at least, if not, I guess that's a bug in itself)
598 2020-06-11T19:35:58  <MarcoFalke> dongcarl: It can be anything, even just `help(format="json")` as an RPC
599 2020-06-11T19:36:08  <jeremyrubin> I think it's that a major version doesn't break *everything*
600 2020-06-11T19:36:12  <MarcoFalke> wumpus: Correct, that is what the doc says
601 2020-06-11T19:36:16  <jeremyrubin> So it's if you need to upgrade all your logic or not
602 2020-06-11T19:36:34  <wumpus> before upgrading to a new major version you need to check the release notes for all the calls you're using in your software
603 2020-06-11T19:36:51  <jeremyrubin> Well the issue is that's not a developer issue
604 2020-06-11T19:36:55  <jeremyrubin> that's a userland issue
605 2020-06-11T19:37:02  <jeremyrubin> unless the user is bundling the node
606 2020-06-11T19:37:06  <jeremyrubin> *developer
607 2020-06-11T19:37:14  <wumpus> same for client software I guess
608 2020-06-11T19:38:09  <jeremyrubin> Yeah so if a user starts with an older node, BTCPayServer tries to be compatible. And every developer could write their own maps of breaking changes and what works or doesn't
609 2020-06-11T19:38:16  <wumpus> what would per-RPC versioning look like in any case? like, instead of calling sendtoaddress, you'd call sendtoaddress/v4 ?
610 2020-06-11T19:38:22  <jeremyrubin> But i think the request is to handle it inside of core
611 2020-06-11T19:38:32  <jeremyrubin> Ah, I think it would be in the get_avail_rpcs
612 2020-06-11T19:38:47  <jeremyrubin> You would get a current version, and a broken at version
613 2020-06-11T19:38:55  <wumpus> there was an idea like that at one point I guess
614 2020-06-11T19:39:16  <jeremyrubin> so if you're expecting something v3 compliant, but it tells you broken at v4, then you can alert the user to upgrade
615 2020-06-11T19:39:22  <wumpus> e.g. have an endpoint /v2  that would expose calls with new arguments
616 2020-06-11T19:39:37  <jeremyrubin> yeah. I don't have a proposal for this BTW.
617 2020-06-11T19:39:47  <wumpus> but, to be honest, nothing is that organized, you really need to pay attention to the major bitcoin core release in practice
618 2020-06-11T19:40:09  <jeremyrubin> That's why I think it makes a good meeting topic as it's something downstream users are complaining about, and would be good to make life easier for them.
619 2020-06-11T19:40:46  <jeremyrubin> I think a JSON of rpcs and available args would be good.
620 2020-06-11T19:41:07  <wumpus> I still don't see how that is better than just looking at the major version. We don't need to expose release notes information on the RPC interface.
621 2020-06-11T19:41:38  <sipa> i don't think the current_version and broken_at_version idea is crazy
622 2020-06-11T19:41:38  <jnewbery> I think we've generally been pretty responsible with maintaining RPC compatibility. The deprecatedrpc functionality gives clients plenty of warning when anything important changes.
623 2020-06-11T19:41:56  <wumpus> yes
624 2020-06-11T19:42:13  <wumpus> I'm not sure for what RPCs this is a practical problem
625 2020-06-11T19:42:59  <jeremyrubin> I think the reason for putting thought into it is if we're going to do *some* feature detection, we want it to be sufficiently future proof as then future feature detection would be broken
626 2020-06-11T19:43:06  <jeremyrubin> if we change the feature detection API
627 2020-06-11T19:43:16  *** adamjonas has quit IRC
628 2020-06-11T19:43:22  <sipa> having some examples of what RPCs have caused issues in the past would be good to know, indeed
629 2020-06-11T19:43:31  <dongcarl> Sounds like if this is a downstream complaint we need to look at the specific cases and see what could be done that would solve a majority of them. jeremyrubin Are there links?
630 2020-06-11T19:43:34  *** ajonas has joined #bitcoin-core-dev
631 2020-06-11T19:43:37  <sipa> perhaps all we need to do is be more careful about breaking compatbility
632 2020-06-11T19:43:49  <jeremyrubin> https://github.com/bitcoin/bitcoin/issues/12248
633 2020-06-11T19:43:57  <wumpus> sipa: especially in cases that can pass silently
634 2020-06-11T19:44:14  <jeremyrubin> https://github.com/bitcoin/bitcoin/pull/19117
635 2020-06-11T19:44:18  <wumpus> maybe renaming a RPC if its fields change isn't that bad an idea
636 2020-06-11T19:44:51  <dongcarl> jeremyrubin: Are there links to the downstream convo?
637 2020-06-11T19:44:55  <wumpus> though in general we've been careful to keep the same patern for arguments, e.g. we *still* have a dummy argument for getbalance
638 2020-06-11T19:45:12  <jeremyrubin> I think the main thing I broke is batching API when using whitelists. unaware of links for their internal issue on that
639 2020-06-11T19:45:52  <jeremyrubin> Because if you're using whitelists, the method of feature discovery (calling all required RPCS) fails
640 2020-06-11T19:45:59  <wumpus> I'm still confused about whitelisting tbh
641 2020-06-11T19:46:12  <jeremyrubin> Which calling all RPCs to discover the features is... bad. Because RPCs can do things
642 2020-06-11T19:46:28  <wumpus> I don't think RPC whitelisting should have been something that ended up in bitcoind
643 2020-06-11T19:46:31  <wumpus> been anyhow
644 2020-06-11T19:47:18  <wumpus> some very application-specific security requirements are finding their way in
645 2020-06-11T19:47:41  <jnewbery> all of this stuff seems like it should be the responsibility of a proxy
646 2020-06-11T19:47:43  <wumpus> and this has nothing to do with differences between versions
647 2020-06-11T19:47:46  <wumpus> jnewbery: yes
648 2020-06-11T19:47:46  <jeremyrubin> dongcarl: here's the issue https://github.com/bitcoin/bitcoin/issues/19087
649 2020-06-11T19:47:55  <MarcoFalke> But then different rpcusers shouldn't be in bitcoind either?
650 2020-06-11T19:48:21  <jeremyrubin> I do think that we could rip out all authentication for RPCusers
651 2020-06-11T19:48:35  <MarcoFalke> Just have one authpair and the proxy can deal with users
652 2020-06-11T19:48:53  <jeremyrubin> It's a lot of complexity and if the answer is to proxy it just make Bitcoind not listen by default & require SSH auth'd proxy to connect
653 2020-06-11T19:49:01  <wumpus> MarcoFalke: I'm not for reverting it, just, it's not a no-holds-barred pretext to introduce all kinds of per-RPC auth mechanisms into bitcoind
654 2020-06-11T19:49:47  <yevaud> I think that it gives the wrong message, that unprivileged users are an expected thing. there's already a large number of people running with RPC bound to public interfaces as it is.
655 2020-06-11T19:50:02  <wumpus> wait, no, don't bind RPC to public interfaces
656 2020-06-11T19:50:08  <MarcoFalke> I am not for reverting it either. Just saying that we already have more than the minimal required functionality in core
657 2020-06-11T19:50:21  <wumpus> this kind of people that want this are enterprises I guess, with *very specific* security and auditing requirements
658 2020-06-11T19:50:40  <yevaud> by all means it allows you to have granular control of the permissions from your service, but it is easily misinterpreted.
659 2020-06-11T19:51:01  <wumpus> exposing things on the public internet is just plain dumb
660 2020-06-11T19:51:25  <jeremyrubin> i think public probably means internal-public
661 2020-06-11T19:51:31  <wumpus> the only interface that bitcoind provides that (hopefully) is internet-hardened is P2P
662 2020-06-11T19:51:39  <wumpus> anyhow, any other topics?
663 2020-06-11T19:51:42  <jnewbery> It looks to me like 19087 is the result of two features interacting badly (batching and whitelists). Adding more complexity and another feature (versioning) doesn't seem like the correct remedy.
664 2020-06-11T19:52:04  <jeremyrubin> So the need for versioning exists outside of the conflict there
665 2020-06-11T19:52:16  <jeremyrubin> The core issue is that people are struggling to do feature detection
666 2020-06-11T19:52:23  <jeremyrubin> And are calling a list of all RPCs to do that
667 2020-06-11T19:52:30  <jeremyrubin> So we should have a better paradigm for that
668 2020-06-11T19:52:45  <wumpus> imo: look at the major version number of bitcoin core
669 2020-06-11T19:52:51  <MarcoFalke> What about the pull request that returns the RPC methods for the current user?
670 2020-06-11T19:52:52  <wumpus> if you're not sure, warn the user
671 2020-06-11T19:53:07  <jeremyrubin> MarcoFalke: it returns the whitelist, not the list of RPC methods
672 2020-06-11T19:53:14  <wumpus> nothing will be enough to machine-represent the subtleties of differences between versions
673 2020-06-11T19:53:25  <jeremyrubin> And the whitelist can contain things that aren't currently defined RPCs
674 2020-06-11T19:53:46  <wumpus> whitelist has nothing to do with this
675 2020-06-11T19:53:46  <jeremyrubin> Hence the issue being, what people want is a detect-avaialble-features API
676 2020-06-11T19:53:53  <MarcoFalke> why can't the whitelist be sanitized before returning it?
677 2020-06-11T19:54:07  <jeremyrubin> Then it's a detect available features API
678 2020-06-11T19:54:23  <jeremyrubin> Which is what the issue is about; but if we're doing that it makes sense to think it through
679 2020-06-11T19:54:37  <jeremyrubin> And listen to users on what sort of feature detection things they need/want
680 2020-06-11T19:54:46  <jeremyrubin> And RPC versioning came up as a request
681 2020-06-11T19:54:48  <wumpus> jnewbery: it definitely seems like digging in deeper after making a mistake
682 2020-06-11T19:55:23  <jeremyrubin> I'm OK with just returning a filtered RPC whitelist tho, it would work, but maybe we need a v2 feature detection later which I'd want to avoid
683 2020-06-11T19:55:33  <wumpus> to be clear I applaud attempts to have machine-readable documentation for RPCs like MarcoFalke is working on
684 2020-06-11T19:55:38  <jonatack> jeremyrubin: wasn't there a really good external site once that documented all the RPC API versions in detail?
685 2020-06-11T19:56:07  <wumpus> and if that gives a list of available RPC calls, sure, that could be useful
686 2020-06-11T19:56:08  <jnewbery> jonatack: bitcoincore.org :)
687 2020-06-11T19:56:20  <yevaud> https://chainquery.com/bitcoin-cli probably.
688 2020-06-11T19:56:31  <jnewbery> https://bitcoincore.org/en/doc/
689 2020-06-11T19:56:47  *** rafalcpp has joined #bitcoin-core-dev
690 2020-06-11T19:57:36  <jeremyrubin> Anyways I agree largely it doesn't belong in core; things like the wallet also probably shouldn't be there
691 2020-06-11T19:57:52  <wumpus> yes
692 2020-06-11T19:57:55  <jonatack> yes, and I knew another one that was outstanding, but don't recall what it was
693 2020-06-11T19:57:58  <wumpus> too much score creep
694 2020-06-11T19:58:04  <wumpus> scope creep
695 2020-06-11T19:58:17  <jeremyrubin> But it's just making due with helping users/devs write secure software
696 2020-06-11T19:58:22  <jeremyrubin> *making do
697 2020-06-11T19:58:45  <jeremyrubin> If someone has a good proxy implementation that can be put into a sub-process maybe that would help
698 2020-06-11T19:58:49  <wumpus> I think a layered approach is a better way to make secure software
699 2020-06-11T19:58:53  *** justanotheruser has joined #bitcoin-core-dev
700 2020-06-11T20:00:02  <sipa> *DONG*
701 2020-06-11T20:00:06  <wumpus> #endmeeting
702 2020-06-11T20:00:06  <lightningbot> Meeting ended Thu Jun 11 20:00:06 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
703 2020-06-11T20:00:06  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-06-11-19.00.html
704 2020-06-11T20:00:06  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-06-11-19.00.txt
705 2020-06-11T20:00:06  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-06-11-19.00.log.html
706 2020-06-11T20:00:18  <dongcarl> Perhaps a good topic for some day where there aren't many topics is: what things can we remove from bitcoin-core that would have a net-positive impact?
707 2020-06-11T20:00:27  <dongcarl> sipa: yes? :P
708 2020-06-11T20:00:34  <hebasto> jeremyrubin: "I have a couple examples where we over-lock..." mind sharing?\
709 2020-06-11T20:00:42  <jnewbery> please don't remove sipa
710 2020-06-11T20:01:01  <wumpus> dongcarl: I'm just trying to prevent adding too many things
711 2020-06-11T20:01:05  <aj> jnewbery: but sipa's something that has a net-positive impact, so fits dongcarl's requirements
712 2020-06-11T20:01:28  <jeremyrubin> dongcarl: russ has a great way of doing that but it requires adding something big :p
713 2020-06-11T20:01:31  <dongcarl> :brainfried:
714 2020-06-11T20:02:02  <sipa> *floink*
715 2020-06-11T20:02:03  <wumpus> we have a kitchen_sink.cpp now, that should be enough, stop adding things please xD
716 2020-06-11T20:02:11  <sipa> wut?
717 2020-06-11T20:02:21  <wumpus> ./src/test/fuzz/kitchen_sink.cpp
718 2020-06-11T20:02:22  <achow101> dongcarl: deep fried brains?
719 2020-06-11T20:02:22  <jeremyrubin> you've been removed sipa
720 2020-06-11T20:02:50  <jamesob> > *DONG*
721 2020-06-11T20:02:50  <jamesob> didn't know there was a gong in here
722 2020-06-11T20:02:51  <sipa> hmm does that not need some kind of voting algorithm?
723 2020-06-11T20:02:53  <jeremyrubin> I like MarcoFalke's suggestion of completely getting rid of credentials in core
724 2020-06-11T20:03:01  <sipa> "you are the weakest link, bye bye" style
725 2020-06-11T20:03:24  <dongcarl> jeremyrubin: A proxy could be maintained in a separate repo
726 2020-06-11T20:03:47  <wumpus> I don't think it's worth getting rid of now
727 2020-06-11T20:03:50  <jeremyrubin> I think you probably do want it to be... shipped with and started by 'bitcoind' tho
728 2020-06-11T20:04:00  <MarcoFalke> Make it opt in for now -use_rpcusers_that_is_going_to_be_removed_in_2025=1
729 2020-06-11T20:04:02  <MarcoFalke> then remove
730 2020-06-11T20:04:02  <wumpus> checking against 3 credentials instead of 1, is not that much overhead
731 2020-06-11T20:04:15  <jeremyrubin> I kind of like a model where bitcoind is a compatible set of processes that run
732 2020-06-11T20:04:16  <sipa> i think getting rid of the auth mechanism is too big a breaking change
733 2020-06-11T20:04:22  <wumpus> yes
734 2020-06-11T20:04:25  <yevaud> "a proxy" can just be nginx, except for the rpccookie bit.
735 2020-06-11T20:04:26  <jeremyrubin> and bitcoin-node is the just network process
736 2020-06-11T20:04:36  <jeremyrubin> I think it doesn't have to be breaking at all
737 2020-06-11T20:04:38  <sipa> yes, dreaming is nice
738 2020-06-11T20:04:43  <wumpus> you can argue it shouldn't have been introduced in the first place, but it makes no sense to remove it now
739 2020-06-11T20:04:58  <wumpus> you should be careful what you PR
740 2020-06-11T20:05:04  <wumpus> and what you merge
741 2020-06-11T20:05:55  <wumpus> pay attention and review, also conceptually
742 2020-06-11T20:06:05  <wumpus> and with regard to maintenance burden
743 2020-06-11T20:06:07  <yevaud> jeremyrubin: it turns out that breaking up bitcoin into different daemons needs a comical amount of state exposed, sadly.
744 2020-06-11T20:06:18  <jeremyrubin> I don't think so for RPC credentials
745 2020-06-11T20:06:24  <jeremyrubin> I think it's relatively small
746 2020-06-11T20:06:36  <wumpus> I'm trying to be careful but too many people just want to kitchen sink everything
747 2020-06-11T20:07:28  <jeremyrubin> Is anyone opposed to work that separates out RPC credentials to a different thread, makes sure there's no state leak? Then when Russ pushes through the experimental capnproto stuff it can be forked out?
748 2020-06-11T20:07:49  <wumpus> it shouldn't be a different thread, no
749 2020-06-11T20:07:54  <yevaud> capnproto?
750 2020-06-11T20:07:59  <sipa> i don't see how any of these things are related
751 2020-06-11T20:08:04  <wumpus> agree
752 2020-06-11T20:08:21  <wumpus> it sounds like complicating things even more (at least inthe repository)
753 2020-06-11T20:09:02  <jeremyrubin> The idea being to make the credentialing system removed from core. Doesn't need to be a thread, just an object that can pass things to core through a proxy-like interface
754 2020-06-11T20:09:13  <sipa> define "removed from core"
755 2020-06-11T20:09:16  <sipa> from the codebase?
756 2020-06-11T20:09:18  <sipa> from the process?
757 2020-06-11T20:09:24  <sipa> from the interface?
758 2020-06-11T20:09:28  <wumpus> some people are actually filtering RPC and using some external proxy to filter allowed/disallowed RPC calls
759 2020-06-11T20:09:36  <wumpus> no changes to bitcoin coren eeded, at all
760 2020-06-11T20:09:42  <jeremyrubin> Ah
761 2020-06-11T20:09:48  <jeremyrubin> I'm not just talking about the lists
762 2020-06-11T20:09:55  <jeremyrubin> I'm talking about the identities as well
763 2020-06-11T20:10:01  <wumpus> they can do that as well
764 2020-06-11T20:10:04  <jeremyrubin> Yep
765 2020-06-11T20:10:09  <wumpus> and logging
766 2020-06-11T20:10:11  <wumpus> et
767 2020-06-11T20:10:16  <jeremyrubin> And by removed I mean that it could be a separate binary
768 2020-06-11T20:10:31  <wumpus> yes, or a script
769 2020-06-11T20:10:52  <wumpus> there's nothing we need to do for this
770 2020-06-11T20:10:55  <wumpus> it's socially scalable :)
771 2020-06-11T20:11:39  <jeremyrubin> wumpus: it's more if you want to 'remove the crap' from Core, you can actually get rid of the code that's there
772 2020-06-11T20:11:44  <yevaud> the panacea really is getting the wallet and networking into their own daemons, but that's not going to happen any time soon.
773 2020-06-11T20:11:53  <wumpus> I'm not trying to remove anything, just to prevent adding it
774 2020-06-11T20:12:10  <wumpus> once added it's pretty much too late
775 2020-06-11T20:12:14  *** Eagle[TM] has quit IRC
776 2020-06-11T20:12:25  <jeremyrubin> Ah ok. So one thing that is in favor of feature discovery in that context
777 2020-06-11T20:12:47  <jeremyrubin> Is that you can write a generic proxy that learns the features from core and not have to ever touch that program
778 2020-06-11T20:13:35  <jeremyrubin> So maybe there's some minimal set of features that make writing these proxies a bit better.
779 2020-06-11T20:13:39  <wumpus> the proxy should already know what is allowd and what not, that shouldn't determine on the target
780 2020-06-11T20:14:10  <jeremyrubin> Allowed/disallowed differs from exists/doesn't exist and versions
781 2020-06-11T20:14:30  <jeremyrubin> E.g., if I configure a proxy for v1 to be safe, but v2 adds an argument which is unsafe
782 2020-06-11T20:14:35  <jeremyrubin> That's a bad situation
783 2020-06-11T20:14:41  <wumpus> yes before upgrading bitcoin core (definitely the major version) you need to make sure your other software is compatible
784 2020-06-11T20:15:12  <jeremyrubin> Yeah i think that's just asking a bit much of the user...
785 2020-06-11T20:15:30  <jeremyrubin> but I guess they'll lose their funds sooner or later if that's the case so maybe we don't care to help them?
786 2020-06-11T20:15:35  <wumpus> I don't think any general mechanism can prevent that unless you can describe *every* detail of the RPC interface programatically ,and even then
787 2020-06-11T20:16:05  <wumpus> wait, I don't think we should do RPC changes that can result in losing funds in the first place?!?
788 2020-06-11T20:16:26  <wumpus> we've been very careful with this, even getbalance still has a dummy argument
789 2020-06-11T20:16:37  <jeremyrubin> I think that's inevitable that new flags can do stupid things
790 2020-06-11T20:16:56  <jeremyrubin> E.g., adding a maxFeeRate flag that previously was set to a fixed constant
791 2020-06-11T20:17:07  <wumpus> if you see any RPC change that can result in old software suddenly doing destructive things please flag it on review
792 2020-06-11T20:17:44  <jeremyrubin> Herculean task :p
793 2020-06-11T20:17:59  <wumpus> well if it is too much of a task to pay attention to review of things like that
794 2020-06-11T20:18:37  <wumpus> it's definitely too much to expect people to update some featur detection mechanism
795 2020-06-11T20:18:38  <jeremyrubin> I mean to say I'm not even aware of all of the downstream software, let alone how it handles these things
796 2020-06-11T20:18:47  <wumpus> be realistic here
797 2020-06-11T20:19:30  <jeremyrubin> Well I think it's sort of a case of helping the developers do the right thing.
798 2020-06-11T20:19:46  <jeremyrubin> I'm growing in fondness for explicit aliases for all rpcs
799 2020-06-11T20:20:22  <jeremyrubin> I think swift's mangler does something where A(foo: int, bar:String?) becomes A() and A_with_bar()
800 2020-06-11T20:20:59  <wumpus> you could achieve something like that by forbidding default arguments
801 2020-06-11T20:21:38  <wumpus> if some new argument is added, it needs to be specified ... then again, that completely breaks backwards compatibility, which is for most people even worse I think
802 2020-06-11T20:21:59  <jeremyrubin> Well... maybe not?
803 2020-06-11T20:22:05  <wumpus> there's an implicit expectation already that calling the same RPCs with the same arguments keeps doing the same
804 2020-06-11T20:22:26  <wumpus> if any arguments are added their default is the same as what was done before
805 2020-06-11T20:22:45  <wumpus> in any case, it would help if you have specific examples of where this went wrong in the past
806 2020-06-11T20:22:56  <wumpus> where people lost funds due to RPCs changing
807 2020-06-11T20:23:32  <jeremyrubin> Not off the top of my head. But I can imagine someone sanitizing a JSON for arguments by checking what's there against the old arguments, but not checking for presence of new ones
808 2020-06-11T20:23:33  <wumpus> if not, this is kind of an empty discussion, something that is already avoided at all ocsts
809 2020-06-11T20:23:53  <jeremyrubin> and then an attacker being able to sneak in an argument that changes the behavior.
810 2020-06-11T20:24:18  <wumpus> where did the attacker come from? this was about accidental version incompatiblities right
811 2020-06-11T20:24:19  <jeremyrubin> Would be prevented by explicitly destructing/rebuilding the JSON with only the desired args. Don't know how common that is tho
812 2020-06-11T20:24:27  * wumpus is confused, logging off for now
813 2020-06-11T20:24:37  <jeremyrubin> Yeah sorry not trying to cause a kerfuffle over it
814 2020-06-11T20:25:05  <jeremyrubin> I don't know what to tell end-users other than to ship their applications with a specific bitcoind version
815 2020-06-11T20:25:12  <jeremyrubin> which i think is an OK answerrt
816 2020-06-11T20:26:27  *** lightlike has joined #bitcoin-core-dev
817 2020-06-11T20:26:43  *** SiAnDoG has quit IRC
818 2020-06-11T20:27:56  <phantomcircuit> meshcollider, i've been working on the "rescanblockchain" rpc and noticed a few oddities in the wallet logic; for example #19216
819 2020-06-11T20:27:58  <gribble> https://github.com/bitcoin/bitcoin/issues/19216 | wallet: Remove first parameter to ScanForWalletTransactions start_hash by pstratem · Pull Request #19216 · bitcoin/bitcoin · GitHub
820 2020-06-11T20:28:16  <sipa> jeremyrubin: i think that wumpus' point is that no matter how well we try to encode compatibilities electronically, things may be too subtle and in the end people/client developers will for production use still need to refer to the release notes
821 2020-06-11T20:28:32  <jeremyrubin> sipa: agree 100%.
822 2020-06-11T20:28:34  <sipa> jeremyrubin: but at the same time, solving compatibility is a much more widely scoped problem than the security side
823 2020-06-11T20:28:48  <sipa> RPC changes should not impact security
824 2020-06-11T20:28:49  <phantomcircuit> meshcollider, im going through other parameters looking for oddities as well
825 2020-06-11T20:29:54  <harding> This is what I tell devs to do if they want to learn all the differences in RPCs between releases: https://github.com/zkSNACKs/WalletWasabi/issues/3037#issuecomment-581143233
826 2020-06-11T20:29:55  <wumpus> yes, I think that's another reason I'm confused about things like whitelists and credentials, the RPC interface was never supposed to be hardened against attackers like that, it was supposed to be a trusted interface for applications
827 2020-06-11T20:30:28  <jeremyrubin> sipa: in the example I was giving above I was imagining some frontend app passes a JSON of a desired RPC call. The server checks all the arguments it knows about for that rpc, and sends to the server. But a new RPC was added in the new version of core running. Then the frontend-hacker adds that parameter. And a bad RPC call accidentally gets passed.
828 2020-06-11T20:31:06  <sipa> jeremyrubin: if the frontend that does the security check is compromised, i don't see how problems can be avoided?
829 2020-06-11T20:31:19  <jeremyrubin> No the backend server is doing the check
830 2020-06-11T20:31:42  <sipa> ok, then i don't understand the problem
831 2020-06-11T20:32:16  <jeremyrubin> Ok. So imagine v1 RPC A has arg 'good'. V2 adds arg 'bad' default = 0
832 2020-06-11T20:32:29  <MarcoFalke> I plan to write a feature detection in 5 lines of python and add it to the test framework. No changes to core required.
833 2020-06-11T20:32:34  <sipa> jeremyrubin: that should never happen
834 2020-06-11T20:32:52  <MarcoFalke> We might be over-engineering this a bit
835 2020-06-11T20:32:54  <jeremyrubin> sipa: why not? We add default args all the time.
836 2020-06-11T20:33:07  <sipa> and they shouldn't impact security
837 2020-06-11T20:33:10  <jeremyrubin> and the 'bad' one by default does nothing
838 2020-06-11T20:33:19  *** Pavlenex has quit IRC
839 2020-06-11T20:33:24  <jeremyrubin> But we add ones that could impact security if set to a bad value?
840 2020-06-11T20:33:41  <wumpus> sipa: exactly, that should already never happen, so there shouldn't be need to describe it
841 2020-06-11T20:33:41  <jeremyrubin> things like feerates
842 2020-06-11T20:33:58  <wumpus> which was my point with catching these things at review time
843 2020-06-11T20:34:22  <sipa> jeremyrubin: i'm still missing part of your context
844 2020-06-11T20:34:31  <sipa> "the server checks ... and sends to the server"
845 2020-06-11T20:34:36  <jeremyrubin> Ah yeah I was still explaining but you told me that I was already off
846 2020-06-11T20:34:37  <sipa> there are multiple servers involved?
847 2020-06-11T20:34:44  <sipa> ok
848 2020-06-11T20:34:48  <jeremyrubin> There's a frontend, a backend, and a core node
849 2020-06-11T20:35:00  <jeremyrubin> (I'll tell you when I'm done)
850 2020-06-11T20:35:22  <jeremyrubin> Frontend generates and RPC, passes it to the backend. Backend sanitizes, passes to core
851 2020-06-11T20:35:40  <jeremyrubin> v1: A good. v2: A good, bad=0
852 2020-06-11T20:36:04  <sipa> sounds like the backends needs to disallow parameters it does not know about
853 2020-06-11T20:36:04  <jeremyrubin> the backend initially checks that A.good is 0 or 1
854 2020-06-11T20:36:07  <jeremyrubin> Yes
855 2020-06-11T20:36:19  <jeremyrubin> My point being that originally Core was doing this check
856 2020-06-11T20:36:30  <jeremyrubin> And then when the default arg gets introduced core stops doing this
857 2020-06-11T20:36:36  <wumpus> exactly, the security checking thing should be careful to only pass through what it knows about
858 2020-06-11T20:36:49  <wumpus> this was always the case
859 2020-06-11T20:36:50  *** Kiminuo has quit IRC
860 2020-06-11T20:36:51  <jeremyrubin> So when core goes V1 -> V2 there's a potential for a security issue
861 2020-06-11T20:36:53  <sipa> jeremyrubin: that's why a security-enforcing proxy needs to work with whitelisting
862 2020-06-11T20:37:04  <sipa> per RPC, per parameter
863 2020-06-11T20:37:20  <jeremyrubin> I don't think we're disagreeing on any of this
864 2020-06-11T20:37:31  <sipa> then i don't see the problem
865 2020-06-11T20:38:07  <jeremyrubin> I'm just saying I don't think it's that common that this happens, and there's an opportunity to introduce some stuff that helps prevent these bugs.
866 2020-06-11T20:38:19  <jeremyrubin> I don't think it eliminates them
867 2020-06-11T20:38:46  <jeremyrubin> But I think it could help reasonable app developers not have these sorts of mistake
868 2020-06-11T20:38:55  <sipa> ok, i agree there - but i don't think it's worth the complexity, especially as it risks giving a false sense of security
869 2020-06-11T20:39:39  <jeremyrubin> fwiw my proposal is essentially an API where you do feature detect and fail to start if it doesn't match your expected feature set
870 2020-06-11T20:39:54  <sipa> changes to the RPC interface should be safe in such a way that if an RPC that worked in the past was fine, if it still exists in the new version, is still fine
871 2020-06-11T20:40:32  <sipa> jeremyrubin: but how do you define feature? is a slightly different way that ping messages are scheduled a feature change? because it may be observable through the minping field
872 2020-06-11T20:41:02  <sipa> and if feature changes are restricted to things that could have a security impact... the probably just shouldn't happen
873 2020-06-11T20:41:32  <jeremyrubin> You know it's a good question to ask more of the app developers (e.g., LN btcpay)
874 2020-06-11T20:42:11  <jeremyrubin> I think it's also an interesting question if there were a change we had to make for security, how would we make sure old software didn't do the broken thing on new nodes (hopefully never happens but you never know)
875 2020-06-11T20:42:32  <jeremyrubin> Again I don't really have a concrete proposal here
876 2020-06-11T20:42:34  <sipa> we could rename RPCs if we're somehow forced to change their semantics very substantially
877 2020-06-11T20:42:48  <jeremyrubin> I just know that calling all the RPCs in a batch to see what's on sounds like a very wrong idea
878 2020-06-11T20:43:05  <jeremyrubin> And would like to help BTCPayServer not do that
879 2020-06-11T20:43:19  <sipa> yes, they should check version numbers - i agree
880 2020-06-11T20:43:24  <sipa> with wumpus
881 2020-06-11T20:43:30  <jeremyrubin> Maybe a good one is just an RPC where you submit a list of RPCs an arguments intended to the node
882 2020-06-11T20:43:31  <sipa> and just fail to start if it's not a known one
883 2020-06-11T20:44:04  <jeremyrubin> Yeah that could be the answer
884 2020-06-11T20:44:21  <meshcollider> phantomcircuit: sounds good :)
885 2020-06-11T20:44:59  <jeremyrubin> I do know that RPC whitelisting did expose this problem by changing what batching returns when something isn't whitelisted in the batch. So I regret that. But seems like there should be a good answer of what BTCPayServer should implement instead of that for detection
886 2020-06-11T20:45:16  <jeremyrubin> NicolasDorier: ^^^ stop it :)
887 2020-06-11T20:45:27  <sipa> and we could automate some things, which would mean that generally client versions will break slightly less often when facing an unknown server... but if semantics are super critical, that still risks breaking things, and they still really should just check the version number
888 2020-06-11T20:45:54  *** dgenr8 has quit IRC
889 2020-06-11T20:47:20  <jeremyrubin> Ah!
890 2020-06-11T20:47:39  <jeremyrubin> Here's a great reason to do this; makes people more likely to upgrade their supported node version :p
891 2020-06-11T20:48:19  *** dgenr8 has joined #bitcoin-core-dev
892 2020-06-11T20:48:55  <jeremyrubin> But I'm basically at my depth on this issue; I don't have a current major core-dependent app dealing with compatibility issues so it is really a matter of e.g. roasbeef, NicolasDorier to chime in on it.
893 2020-06-11T20:49:46  <jeremyrubin> I think in terms of the actual Bug I'm OK with wontfix if you're using batching + whitelist with non whitelisted rpcs
894 2020-06-11T20:50:14  <sipa> it sounds like the batching/whitelist implementation was just broken?
895 2020-06-11T20:50:23  <jeremyrubin> Not really?
896 2020-06-11T20:50:42  <sipa> i'm not familiar with the issue
897 2020-06-11T20:50:56  <jeremyrubin> So if you call a batch
898 2020-06-11T20:51:03  <jeremyrubin> and one of the RPCs is not whitelisted
899 2020-06-11T20:51:09  <jeremyrubin> It will call the prefix
900 2020-06-11T20:51:21  <jeremyrubin> and then just return the RPC not found for the whole thing
901 2020-06-11T20:51:30  <jeremyrubin> rather than RPC not found for that specific RPC
902 2020-06-11T20:51:39  <jeremyrubin> as the batch result
903 2020-06-11T20:51:44  <jeremyrubin> Was my understanding of the issue
904 2020-06-11T20:51:48  <sipa> that sounds like a bug?
905 2020-06-11T20:52:31  <jeremyrubin> https://github.com/bitcoin/bitcoin/issues/19087#issuecomment-636883880
906 2020-06-11T20:53:08  <jeremyrubin> I mean the bigger picture issue is that this *should* have come up in review and integration testing
907 2020-06-11T20:53:15  <jeremyrubin> as it seems to break btcpayserver on startup
908 2020-06-11T20:53:28  <jeremyrubin> And whitelistrpc has been merged for a while
909 2020-06-11T20:53:29  <sipa> and it should definitely have come up during rc testing...
910 2020-06-11T20:53:47  <jeremyrubin> It's not like some corner case issue
911 2020-06-11T20:54:07  <sipa> but i don't see why we can't just fix this in 0.20.1
912 2020-06-11T20:54:51  <jeremyrubin> It can be fixed, but permanently 0.20 will be hard to start against for BTCPayServer if using rpcwhitelist
913 2020-06-11T20:54:53  <sipa> sure, they should have a better way of doing feature detection, but it sounds like this just gratutiously broke compatibility, so we should restore it?
914 2020-06-11T20:55:07  <sipa> well that's what you have bugfix releases for
915 2020-06-11T20:55:32  <sipa> bugs happen, and sometimes they're detected too late
916 2020-06-11T20:55:35  <jeremyrubin> Well it didn't break it thaaat gratuitously. If you don't use RPC Whitelist OR you detect features differently, it would not come up
917 2020-06-11T20:55:57  <sipa> by gratuitously i don't mean that this was trivial to find; just that it comes at no benefit
918 2020-06-11T20:56:10  *** promag has joined #bitcoin-core-dev
919 2020-06-11T20:56:13  <sipa> as in: i don't expect anyone to (want to) rely on the new behavior
920 2020-06-11T20:56:23  <jeremyrubin> Ah. Yes. Agree 100%
921 2020-06-11T20:56:27  <sipa> so we should fix it
922 2020-06-11T20:56:31  <jeremyrubin> The new behavior is obviously a defect
923 2020-06-11T20:56:58  <sipa> the feature discovery (or version checking) discussion is orthogonal
924 2020-06-11T20:57:11  <jeremyrubin> It is, which is what I've been trying to get across
925 2020-06-11T20:57:35  <jeremyrubin> There's a defect. The reason we found it was doing X. X is shocking. We should fix the defect and provide a better way to X
926 2020-06-11T20:58:07  <sipa> or tell people that instead of X, they should be doing Y which is already possible instead :)
927 2020-06-11T20:58:14  <sipa> but we should still fix the defect
928 2020-06-11T20:59:04  <sipa> is there an issue (or PR) for the fix?
929 2020-06-11T20:59:06  <jeremyrubin> Sure... which is sort of the question that started this. What is Y? Is just parsing the help page sufficient? Should we JSON expose it?
930 2020-06-11T20:59:12  <jeremyrubin> sipa: no, not yet.
931 2020-06-11T20:59:23  <sipa> Y is checking the version number
932 2020-06-11T21:00:02  *** jtk has quit IRC
933 2020-06-11T21:00:20  <jeremyrubin> I think that it's sort of a 'draw the fucking owl' answer though. So check the version number and hardcode all RPCs and the arguments they can take?
934 2020-06-11T21:00:46  <wumpus> also, as said, there is work underway in making the help more programatically parsable, so if that's what you want to do it's only going to become easier
935 2020-06-11T21:01:29  <sipa> jeremyrubin: i mean... what are they doing with the information about which RPCs are available? presumably pretty much something like that already?
936 2020-06-11T21:02:08  <wumpus> of course it's never going to be a perfect representation fully covering all changes and all subtleties, it's not there to give a false sense of security
937 2020-06-11T21:03:32  <jeremyrubin> sipa: good question? Not sure. I would imagine some kind of start with assuming a base version with X features and a dispatch table of functionality that implemented inefficiently client side. See what comes back and replace the client versions with RPC versions?
938 2020-06-11T21:04:00  <sipa> yes
939 2020-06-11T21:04:13  <jeremyrubin> So the code is never aware of what version at all, just aware of what's allowed and adds the on-node versions as applicable.
940 2020-06-11T21:04:27  <jeremyrubin> There's no mapping of version 18 has Y and version 19 has Y + Z
941 2020-06-11T21:04:35  <jeremyrubin> but i'm not sure
942 2020-06-11T21:04:42  <jeremyrubin> That's just a guess
943 2020-06-11T21:04:45  <promag> jnewbery: https://github.com/bitcoin/bitcoin/projects/2 needs minor update
944 2020-06-11T21:04:46  <sipa> i think we're grasping at straws
945 2020-06-11T21:05:19  <jeremyrubin> yeah I'll defer to roasbeef and NicolasDorier who probably have the best knowledge on their use case
946 2020-06-11T21:05:43  <promag> 1. replace #17457 with #18894 (which is already merged) and 2. #15202 is merged too
947 2020-06-11T21:05:46  <gribble> https://github.com/bitcoin/bitcoin/issues/17457 | gui: Fix manual coin control with multiple wallets loaded by promag · Pull Request #17457 · bitcoin/bitcoin · GitHub
948 2020-06-11T21:05:48  <gribble> https://github.com/bitcoin/bitcoin/issues/18894 | gui: Fix manual coin control with multiple wallets loaded by promag · Pull Request #18894 · bitcoin/bitcoin · GitHub
949 2020-06-11T21:05:51  <gribble> https://github.com/bitcoin/bitcoin/issues/15202 | gui: Add Close All Wallets action by promag · Pull Request #15202 · bitcoin/bitcoin · GitHub
950 2020-06-11T21:10:43  <dongcarl> jonasschnelli: Rebased your 2019/08/net_v2 branch using the commits from the latest PRs here: https://github.com/bitcoin/bitcoin/compare/master...dongcarl:2020-06-netv2-no-simplify, the netv2 test fails due to UB, is this worth pursuing or shall I wait until there's more work on the BIP?
951 2020-06-11T21:11:23  <jeremyrubin> sipa: wumpus: apologies for the drawn out conversation here. It's not a particularly major thing I'm trying to get in for Core, but I just feel somewhat responsible for having introduced it to advocate for the users even if I don't really know what they want/need on this one.
952 2020-06-11T21:13:42  *** Guyver2 has quit IRC
953 2020-06-11T21:29:02  *** Chris_Stewart_5 has quit IRC
954 2020-06-11T21:32:41  <jnewbery> promag: done. Thank you for you persistance on multiwallet!
955 2020-06-11T21:36:05  <promag> jnewbery: https://imgflip.com/i/44tpti
956 2020-06-11T21:42:19  *** Dali has joined #bitcoin-core-dev
957 2020-06-11T21:44:51  *** Dali has left #bitcoin-core-dev
958 2020-06-11T21:55:59  *** rafalcpp has quit IRC
959 2020-06-11T21:56:44  *** fredy2 has joined #bitcoin-core-dev
960 2020-06-11T22:02:28  *** pinheadm_ has joined #bitcoin-core-dev
961 2020-06-11T22:03:56  *** danielyin has left #bitcoin-core-dev
962 2020-06-11T22:04:26  *** justanotheruser has quit IRC
963 2020-06-11T22:05:38  *** pinheadmz has quit IRC
964 2020-06-11T22:07:26  *** danielyin has joined #bitcoin-core-dev
965 2020-06-11T22:23:30  *** justanotheruser has joined #bitcoin-core-dev
966 2020-06-11T22:33:09  *** lightlike has quit IRC
967 2020-06-11T22:48:21  *** rafalcpp has joined #bitcoin-core-dev
968 2020-06-11T22:52:59  *** AaronvanW has quit IRC
969 2020-06-11T23:14:23  *** sipsorcery has quit IRC
970 2020-06-11T23:36:16  *** gimballock has quit IRC
971 2020-06-11T23:38:44  *** proofofkeags has quit IRC
972 2020-06-11T23:39:20  *** proofofkeags has joined #bitcoin-core-dev
973 2020-06-11T23:43:47  *** proofofkeags has quit IRC
974 2020-06-11T23:51:58  *** rafalcpp has quit IRC
975 2020-06-11T23:59:35  *** pinheadm_ has quit IRC