1 2020-02-11T00:00:02  *** yano1 has quit IRC
  2 2020-02-11T00:00:07  *** lukedashjr is now known as luke-jr
  3 2020-02-11T00:00:21  *** marcoagner has quit IRC
  4 2020-02-11T00:00:32  *** kristapsk_ has quit IRC
  5 2020-02-11T00:00:54  *** kristapsk_ has joined #bitcoin-core-dev
  6 2020-02-11T00:02:08  *** lukedashjr has joined #bitcoin-core-dev
  7 2020-02-11T00:03:32  *** luke-jr- has joined #bitcoin-core-dev
  8 2020-02-11T00:04:27  *** luke-jr has quit IRC
  9 2020-02-11T00:05:49  *** luke-jr has joined #bitcoin-core-dev
 10 2020-02-11T00:06:05  *** bitcoin-git has joined #bitcoin-core-dev
 11 2020-02-11T00:06:06  <bitcoin-git> [bitcoin] za-kk reopened pull request #17355: gui: grey out used address in address book (master...oct-19-17174) https://github.com/bitcoin/bitcoin/pull/17355
 12 2020-02-11T00:06:07  *** bitcoin-git has left #bitcoin-core-dev
 13 2020-02-11T00:07:17  *** lukedashjr has quit IRC
 14 2020-02-11T00:08:09  *** lukedashjr has joined #bitcoin-core-dev
 15 2020-02-11T00:08:51  *** luke-jr- has quit IRC
 16 2020-02-11T00:09:36  *** luke-jr- has joined #bitcoin-core-dev
 17 2020-02-11T00:11:17  *** luke-jr has quit IRC
 18 2020-02-11T00:12:33  *** turbo_choo has quit IRC
 19 2020-02-11T00:13:11  *** lukedashjr has quit IRC
 20 2020-02-11T00:13:39  *** luke-jr has joined #bitcoin-core-dev
 21 2020-02-11T00:14:20  *** lukedashjr has joined #bitcoin-core-dev
 22 2020-02-11T00:15:39  *** luke-jr- has quit IRC
 23 2020-02-11T00:16:20  *** luke-jr- has joined #bitcoin-core-dev
 24 2020-02-11T00:18:17  *** angvp has joined #bitcoin-core-dev
 25 2020-02-11T00:18:19  *** luke-jr has quit IRC
 26 2020-02-11T00:18:40  *** angvp is now known as Guest20816
 27 2020-02-11T00:20:06  *** luke-jr has joined #bitcoin-core-dev
 28 2020-02-11T00:20:20  *** lukedashjr has quit IRC
 29 2020-02-11T00:22:16  *** luke-jr- has quit IRC
 30 2020-02-11T00:22:57  *** mryandao has quit IRC
 31 2020-02-11T00:23:18  *** mryandao has joined #bitcoin-core-dev
 32 2020-02-11T00:25:29  *** bitcoin-git has joined #bitcoin-core-dev
 33 2020-02-11T00:25:29  <bitcoin-git> [bitcoin] jnewbery opened pull request #18113: [coins] Don't allow a coin to spent and FRESH. Improve commenting. (master...2020-01-prune-pruned) https://github.com/bitcoin/bitcoin/pull/18113
 34 2020-02-11T00:25:30  *** bitcoin-git has left #bitcoin-core-dev
 35 2020-02-11T00:28:15  *** lukedashjr has joined #bitcoin-core-dev
 36 2020-02-11T00:31:56  *** luke-jr has quit IRC
 37 2020-02-11T00:33:18  *** luke-jr has joined #bitcoin-core-dev
 38 2020-02-11T00:34:05  *** lukedashjr has quit IRC
 39 2020-02-11T00:36:17  *** opsec_x12 has joined #bitcoin-core-dev
 40 2020-02-11T00:39:25  *** opsec_x122 has joined #bitcoin-core-dev
 41 2020-02-11T00:40:24  *** opsec_x122 has quit IRC
 42 2020-02-11T00:43:31  *** opsec_x12 has quit IRC
 43 2020-02-11T00:44:22  *** lukedashjr has joined #bitcoin-core-dev
 44 2020-02-11T00:45:04  *** luke-jr- has joined #bitcoin-core-dev
 45 2020-02-11T00:45:20  *** AaronvanW has quit IRC
 46 2020-02-11T00:47:13  *** promag has quit IRC
 47 2020-02-11T00:47:29  *** luke-jr has quit IRC
 48 2020-02-11T00:47:40  *** luke-jr| has joined #bitcoin-core-dev
 49 2020-02-11T00:49:20  *** lukedashjr has quit IRC
 50 2020-02-11T00:50:27  *** luke-jr has joined #bitcoin-core-dev
 51 2020-02-11T00:51:02  *** lukedashjr has joined #bitcoin-core-dev
 52 2020-02-11T00:51:16  *** luke-jr- has quit IRC
 53 2020-02-11T00:51:52  *** pkr has joined #bitcoin-core-dev
 54 2020-02-11T00:52:19  *** luke-jr- has joined #bitcoin-core-dev
 55 2020-02-11T00:52:51  *** luke-jr| has quit IRC
 56 2020-02-11T00:54:38  *** luke-jr| has joined #bitcoin-core-dev
 57 2020-02-11T00:55:11  *** luke-jr has quit IRC
 58 2020-02-11T00:55:17  *** jarthur_ has joined #bitcoin-core-dev
 59 2020-02-11T00:55:39  *** lukedashjr has quit IRC
 60 2020-02-11T00:57:04  *** luke-jr- has quit IRC
 61 2020-02-11T00:58:53  *** luke-jr| is now known as luke-jr
 62 2020-02-11T00:59:29  *** jarthur has quit IRC
 63 2020-02-11T00:59:58  *** jarthur_ has quit IRC
 64 2020-02-11T01:01:25  *** rafalcpp_ has joined #bitcoin-core-dev
 65 2020-02-11T01:01:39  *** rafalcpp has quit IRC
 66 2020-02-11T01:03:09  *** lukedashjr has joined #bitcoin-core-dev
 67 2020-02-11T01:04:11  *** luke-jr- has joined #bitcoin-core-dev
 68 2020-02-11T01:06:23  *** luke-jr has quit IRC
 69 2020-02-11T01:06:43  *** Dean_Guss has quit IRC
 70 2020-02-11T01:07:12  *** luke-jr has joined #bitcoin-core-dev
 71 2020-02-11T01:08:25  *** luke-jr| has joined #bitcoin-core-dev
 72 2020-02-11T01:08:27  *** lukedashjr has quit IRC
 73 2020-02-11T01:10:11  *** luke-jr- has quit IRC
 74 2020-02-11T01:12:03  *** luke-jr has quit IRC
 75 2020-02-11T01:12:13  <cfields_> gitian builders: detached sigs for v0.19.1rc2 are up.
 76 2020-02-11T01:12:25  <fanquake> 🚀
 77 2020-02-11T01:12:49  *** luke-jr has joined #bitcoin-core-dev
 78 2020-02-11T01:13:39  *** luke-jr| has quit IRC
 79 2020-02-11T01:14:40  *** lukedashjr has joined #bitcoin-core-dev
 80 2020-02-11T01:18:14  *** luke-jr- has joined #bitcoin-core-dev
 81 2020-02-11T01:18:25  *** luke-jr has quit IRC
 82 2020-02-11T01:19:39  *** lukedashjr has quit IRC
 83 2020-02-11T01:21:07  *** promag has joined #bitcoin-core-dev
 84 2020-02-11T01:24:07  *** luke-jr- has quit IRC
 85 2020-02-11T01:25:20  *** luke-jr has joined #bitcoin-core-dev
 86 2020-02-11T01:28:20  *** lukedashjr has joined #bitcoin-core-dev
 87 2020-02-11T01:31:07  *** promag has quit IRC
 88 2020-02-11T01:31:43  *** luke-jr has quit IRC
 89 2020-02-11T01:33:37  *** lukedashjr has quit IRC
 90 2020-02-11T01:34:52  *** luke-jr has joined #bitcoin-core-dev
 91 2020-02-11T01:41:08  *** luke-jr has quit IRC
 92 2020-02-11T01:42:24  *** luke-jr has joined #bitcoin-core-dev
 93 2020-02-11T01:43:20  *** lukedashjr has joined #bitcoin-core-dev
 94 2020-02-11T01:46:51  *** luke-jr has quit IRC
 95 2020-02-11T01:49:27  *** lukedashjr has quit IRC
 96 2020-02-11T01:49:30  *** luke-jr has joined #bitcoin-core-dev
 97 2020-02-11T02:01:09  *** jarthur has joined #bitcoin-core-dev
 98 2020-02-11T02:03:23  *** promag has joined #bitcoin-core-dev
 99 2020-02-11T02:05:03  *** vasild has quit IRC
100 2020-02-11T02:08:07  *** promag has quit IRC
101 2020-02-11T02:27:21  *** krvopije has joined #bitcoin-core-dev
102 2020-02-11T02:29:47  *** krvopije has quit IRC
103 2020-02-11T02:45:36  *** jarthur has quit IRC
104 2020-02-11T02:47:34  *** turbo_choo has joined #bitcoin-core-dev
105 2020-02-11T02:49:29  *** Dean_Guss has joined #bitcoin-core-dev
106 2020-02-11T03:00:01  *** Guest20816 has quit IRC
107 2020-02-11T03:01:36  *** abrissbi1ne has joined #bitcoin-core-dev
108 2020-02-11T03:04:44  *** abrissbirne has quit IRC
109 2020-02-11T03:04:54  *** commavir has quit IRC
110 2020-02-11T03:06:26  *** commavir has joined #bitcoin-core-dev
111 2020-02-11T03:13:39  *** Highway61 has quit IRC
112 2020-02-11T03:14:43  *** jb55 has quit IRC
113 2020-02-11T03:15:04  *** ghost43 has quit IRC
114 2020-02-11T03:15:04  *** braydonf_ has quit IRC
115 2020-02-11T03:15:04  *** afk11 has quit IRC
116 2020-02-11T03:15:31  *** jarthur has joined #bitcoin-core-dev
117 2020-02-11T03:15:43  *** Dean_Guss has quit IRC
118 2020-02-11T03:15:44  *** kristapsk_ has quit IRC
119 2020-02-11T03:15:44  *** morcos has quit IRC
120 2020-02-11T03:15:44  *** alec has quit IRC
121 2020-02-11T03:15:44  *** sipa has quit IRC
122 2020-02-11T03:15:44  *** SiAnDoG__ has quit IRC
123 2020-02-11T03:17:02  *** wyk has joined #bitcoin-core-dev
124 2020-02-11T03:17:36  *** StarBrilliant1 has joined #bitcoin-core-dev
125 2020-02-11T03:18:35  *** wyk has quit IRC
126 2020-02-11T03:24:27  *** turbo_choo has quit IRC
127 2020-02-11T03:26:22  *** turbo_choo has joined #bitcoin-core-dev
128 2020-02-11T03:29:07  *** ddustin has joined #bitcoin-core-dev
129 2020-02-11T03:40:53  *** felixfoertsch has joined #bitcoin-core-dev
130 2020-02-11T03:41:33  *** felixfoertsch23 has quit IRC
131 2020-02-11T03:47:15  *** ddustin has quit IRC
132 2020-02-11T03:59:38  *** jb55 has joined #bitcoin-core-dev
133 2020-02-11T04:02:07  *** sipa has joined #bitcoin-core-dev
134 2020-02-11T04:03:48  *** braydonf_ has joined #bitcoin-core-dev
135 2020-02-11T04:03:49  *** afk11 has joined #bitcoin-core-dev
136 2020-02-11T04:05:45  *** DeanGuss has joined #bitcoin-core-dev
137 2020-02-11T04:12:14  *** vasild has joined #bitcoin-core-dev
138 2020-02-11T04:16:45  *** ghost43 has joined #bitcoin-core-dev
139 2020-02-11T04:40:59  *** promag has joined #bitcoin-core-dev
140 2020-02-11T04:42:01  *** alec has joined #bitcoin-core-dev
141 2020-02-11T04:46:09  *** promag has quit IRC
142 2020-02-11T04:58:44  *** Eagle[TM] has joined #bitcoin-core-dev
143 2020-02-11T05:00:39  *** EagleTM has quit IRC
144 2020-02-11T05:23:43  *** bitcoin-git has joined #bitcoin-core-dev
145 2020-02-11T05:23:43  <bitcoin-git> [bitcoin] achow101 opened pull request #18115: [wallet] Pass in transactions and messages for signing instead of exporting the private keys (master...sign-in-spkman) https://github.com/bitcoin/bitcoin/pull/18115
146 2020-02-11T05:23:53  *** bitcoin-git has left #bitcoin-core-dev
147 2020-02-11T05:42:34  *** ttttt has joined #bitcoin-core-dev
148 2020-02-11T05:47:46  *** ttttt has left #bitcoin-core-dev
149 2020-02-11T05:59:25  *** ghost43 has quit IRC
150 2020-02-11T05:59:43  *** ghost43 has joined #bitcoin-core-dev
151 2020-02-11T06:00:02  *** StarBrilliant1 has quit IRC
152 2020-02-11T06:06:33  *** morcos has joined #bitcoin-core-dev
153 2020-02-11T06:25:26  *** rjected has quit IRC
154 2020-02-11T06:42:54  *** rex4539 has joined #bitcoin-core-dev
155 2020-02-11T06:46:58  *** ButterflyOfFire has joined #bitcoin-core-dev
156 2020-02-11T06:50:00  *** promag has joined #bitcoin-core-dev
157 2020-02-11T06:53:39  *** anon_ribit has quit IRC
158 2020-02-11T06:54:03  *** promag has quit IRC
159 2020-02-11T06:54:53  *** anon_ribit has joined #bitcoin-core-dev
160 2020-02-11T07:00:48  *** ddustin has joined #bitcoin-core-dev
161 2020-02-11T07:04:00  *** jarthur has quit IRC
162 2020-02-11T07:06:55  *** goatpig has joined #bitcoin-core-dev
163 2020-02-11T07:11:10  *** Eagle[TM] has quit IRC
164 2020-02-11T07:16:21  *** jaheller has joined #bitcoin-core-dev
165 2020-02-11T07:20:03  <jaheller> Hi, some multisig "gurus" here? Got a question regarding multisig, seems like there was a change in how multisig transactions are being created. Running a node using bitcoind v0.16.3 and another one using latest bitcoind (v.0.19.0.1). The multisig transaction created on the old node can be decoded by https://coinb.in correctly (it's displayed as a
166 2020-02-11T07:20:04  <jaheller> multisig 2:3 transaction). Using the newest bitcoind to create transaction coinb.in isn't able to display it correctly. Someone involved into this?
167 2020-02-11T07:26:58  *** bitcoin-git has joined #bitcoin-core-dev
168 2020-02-11T07:26:59  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/646f0ada0205...35b7a8e539fa
169 2020-02-11T07:26:59  <bitcoin-git> bitcoin/master 0e0fa27 Pieter Wuille: Get rid of VARINT default argument
170 2020-02-11T07:27:00  <bitcoin-git> bitcoin/master 35b7a8e fanquake: Merge #18087: Get rid of VARINT default argument
171 2020-02-11T07:27:08  *** bitcoin-git has left #bitcoin-core-dev
172 2020-02-11T07:27:23  *** bitcoin-git has joined #bitcoin-core-dev
173 2020-02-11T07:27:23  <bitcoin-git> [bitcoin] fanquake merged pull request #18087: Get rid of VARINT default argument (master...202002_novarintvarmacro) https://github.com/bitcoin/bitcoin/pull/18087
174 2020-02-11T07:27:24  *** bitcoin-git has left #bitcoin-core-dev
175 2020-02-11T07:31:24  *** turbo_choo has quit IRC
176 2020-02-11T07:34:16  *** turbo_choo has joined #bitcoin-core-dev
177 2020-02-11T07:43:43  *** vasild has quit IRC
178 2020-02-11T07:45:16  *** vasild has joined #bitcoin-core-dev
179 2020-02-11T07:48:34  *** manantial has joined #bitcoin-core-dev
180 2020-02-11T08:03:37  *** coucou_bot has joined #bitcoin-core-dev
181 2020-02-11T08:03:37  *** coucou_bot has left #bitcoin-core-dev
182 2020-02-11T08:03:48  *** morcos has quit IRC
183 2020-02-11T08:04:42  *** ddustin has quit IRC
184 2020-02-11T08:07:30  <sipa> jaheller: ask on bitcoin.stackexchange.com
185 2020-02-11T08:07:41  *** morcos has joined #bitcoin-core-dev
186 2020-02-11T08:10:01  *** rockhouse has quit IRC
187 2020-02-11T08:10:01  *** victorSN has quit IRC
188 2020-02-11T08:10:50  *** rockhouse has joined #bitcoin-core-dev
189 2020-02-11T08:11:14  *** victorSN has joined #bitcoin-core-dev
190 2020-02-11T08:16:09  *** promag has joined #bitcoin-core-dev
191 2020-02-11T08:17:29  *** marcoagner has joined #bitcoin-core-dev
192 2020-02-11T08:18:57  *** ddustin has joined #bitcoin-core-dev
193 2020-02-11T08:21:15  *** bitcoin-git has joined #bitcoin-core-dev
194 2020-02-11T08:21:15  <bitcoin-git> [bitcoin] hebasto opened pull request #18116: depends: Use clang for Ubuntu 16.04 (master...20200211-clang-ubuntu) https://github.com/bitcoin/bitcoin/pull/18116
195 2020-02-11T08:21:26  *** bitcoin-git has left #bitcoin-core-dev
196 2020-02-11T08:24:01  *** ddustin has quit IRC
197 2020-02-11T08:24:15  <jaheller> sipa Done, thanks.
198 2020-02-11T08:32:48  *** bitcoin-git has joined #bitcoin-core-dev
199 2020-02-11T08:32:49  <bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/35b7a8e539fa...98264e2ccb17
200 2020-02-11T08:32:50  <bitcoin-git> bitcoin/master fa55a25 MarcoFalke: depends: Remove reference to win32
201 2020-02-11T08:32:51  <bitcoin-git> bitcoin/master fae9084 MarcoFalke: build: Skip i686 build by default in guix and gitian
202 2020-02-11T08:32:52  <bitcoin-git> bitcoin/master 98264e2 fanquake: Merge #18104: build: Skip i686 build by default in guix and gitian
203 2020-02-11T08:32:53  *** bitcoin-git has left #bitcoin-core-dev
204 2020-02-11T08:33:08  *** bitcoin-git has joined #bitcoin-core-dev
205 2020-02-11T08:33:09  <bitcoin-git> [bitcoin] fanquake merged pull request #18104: build: Skip i686 build by default in guix and gitian (master...2002-i686NoBuildByDefault) https://github.com/bitcoin/bitcoin/pull/18104
206 2020-02-11T08:33:10  *** bitcoin-git has left #bitcoin-core-dev
207 2020-02-11T08:44:43  *** jaheller has quit IRC
208 2020-02-11T08:59:03  *** Guyver2 has joined #bitcoin-core-dev
209 2020-02-11T09:00:01  *** ButterflyOfFire has quit IRC
210 2020-02-11T09:04:28  *** jarthur has joined #bitcoin-core-dev
211 2020-02-11T09:05:54  *** rex4539 has quit IRC
212 2020-02-11T09:08:39  *** rex4539 has joined #bitcoin-core-dev
213 2020-02-11T09:09:28  *** jarthur has quit IRC
214 2020-02-11T09:18:07  *** Kmos has joined #bitcoin-core-dev
215 2020-02-11T09:19:45  *** promag has quit IRC
216 2020-02-11T09:25:23  *** promag has joined #bitcoin-core-dev
217 2020-02-11T09:38:37  *** rex4539 has joined #bitcoin-core-dev
218 2020-02-11T09:38:54  *** rex4539 has joined #bitcoin-core-dev
219 2020-02-11T09:39:28  *** rex4539 has joined #bitcoin-core-dev
220 2020-02-11T09:40:09  *** rex4539 has joined #bitcoin-core-dev
221 2020-02-11T09:41:07  *** rex4539 has joined #bitcoin-core-dev
222 2020-02-11T09:41:39  *** rex4539 has joined #bitcoin-core-dev
223 2020-02-11T09:41:57  *** rex4539 has joined #bitcoin-core-dev
224 2020-02-11T09:42:24  *** rex4539 has joined #bitcoin-core-dev
225 2020-02-11T09:47:37  *** rex4539 has quit IRC
226 2020-02-11T09:52:11  *** tecnecio_ has joined #bitcoin-core-dev
227 2020-02-11T09:53:57  *** manantial has quit IRC
228 2020-02-11T09:56:07  *** AaronvanW has joined #bitcoin-core-dev
229 2020-02-11T09:58:47  *** Kmos has quit IRC
230 2020-02-11T10:06:52  <elichai2> j #regex
231 2020-02-11T10:06:54  <elichai2> ops
232 2020-02-11T10:08:04  *** Guyver2 has quit IRC
233 2020-02-11T10:22:09  *** bitcoin-git has joined #bitcoin-core-dev
234 2020-02-11T10:22:09  <bitcoin-git> [bitcoin] hebasto opened pull request #18117: build: Fix Qt link issue for macOS target with DEBUG=1 (master...20200211-macos-debug) https://github.com/bitcoin/bitcoin/pull/18117
235 2020-02-11T10:22:10  *** bitcoin-git has left #bitcoin-core-dev
236 2020-02-11T10:27:12  *** jcoe has joined #bitcoin-core-dev
237 2020-02-11T10:31:28  *** turbo_choo has quit IRC
238 2020-02-11T10:39:12  *** timothy has joined #bitcoin-core-dev
239 2020-02-11T10:42:39  *** jaqque1 has joined #bitcoin-core-dev
240 2020-02-11T10:45:15  *** promag has quit IRC
241 2020-02-11T10:45:59  *** promag has joined #bitcoin-core-dev
242 2020-02-11T10:46:51  *** jaqque1 has quit IRC
243 2020-02-11T10:48:30  *** anon_ribit has quit IRC
244 2020-02-11T10:48:49  *** anon_ribit has joined #bitcoin-core-dev
245 2020-02-11T11:03:58  *** Delbert71Koelpin has joined #bitcoin-core-dev
246 2020-02-11T11:05:54  *** jarthur has joined #bitcoin-core-dev
247 2020-02-11T11:07:29  *** rex4539 has joined #bitcoin-core-dev
248 2020-02-11T11:10:42  *** jarthur has quit IRC
249 2020-02-11T11:10:44  *** mterwoord has joined #bitcoin-core-dev
250 2020-02-11T11:12:33  *** rex4539 has quit IRC
251 2020-02-11T11:19:10  *** ddustin has joined #bitcoin-core-dev
252 2020-02-11T11:19:29  *** rex4539 has joined #bitcoin-core-dev
253 2020-02-11T11:23:57  *** ddustin has quit IRC
254 2020-02-11T11:24:43  *** turbo_choo has joined #bitcoin-core-dev
255 2020-02-11T11:54:53  *** Delbert71Koelpin has quit IRC
256 2020-02-11T12:00:02  *** mterwoord has quit IRC
257 2020-02-11T12:05:44  *** filchef has joined #bitcoin-core-dev
258 2020-02-11T12:14:09  *** ghost43 has quit IRC
259 2020-02-11T12:18:01  *** guilhermeblanco has joined #bitcoin-core-dev
260 2020-02-11T12:30:58  *** Zenton has quit IRC
261 2020-02-11T12:34:18  *** Zenton has joined #bitcoin-core-dev
262 2020-02-11T13:06:53  *** jarthur has joined #bitcoin-core-dev
263 2020-02-11T13:09:18  *** Highway61 has joined #bitcoin-core-dev
264 2020-02-11T13:11:27  *** jarthur has quit IRC
265 2020-02-11T13:19:23  *** sdaftuar has quit IRC
266 2020-02-11T13:22:36  *** abrissbi1ne is now known as abrissbirne
267 2020-02-11T13:24:38  *** ghost43 has joined #bitcoin-core-dev
268 2020-02-11T13:25:00  *** rex4539 has quit IRC
269 2020-02-11T13:29:05  <wumpus> newer boost::test output is nicely colorful
270 2020-02-11T13:29:10  *** promag has quit IRC
271 2020-02-11T13:29:24  *** promag has joined #bitcoin-core-dev
272 2020-02-11T13:49:53  *** pabed____ has joined #bitcoin-core-dev
273 2020-02-11T13:57:19  *** mol has quit IRC
274 2020-02-11T14:04:39  *** PaulTroon has quit IRC
275 2020-02-11T14:09:55  *** belcher has joined #bitcoin-core-dev
276 2020-02-11T14:12:01  *** vasild_ has joined #bitcoin-core-dev
277 2020-02-11T14:12:23  *** vasild has quit IRC
278 2020-02-11T14:24:21  *** AaronvanW has quit IRC
279 2020-02-11T14:40:17  *** PaulTroon has joined #bitcoin-core-dev
280 2020-02-11T14:41:42  *** emilengler has joined #bitcoin-core-dev
281 2020-02-11T14:51:29  *** AaronvanW has joined #bitcoin-core-dev
282 2020-02-11T14:56:55  *** qwerty has joined #bitcoin-core-dev
283 2020-02-11T14:59:06  *** qwerty has quit IRC
284 2020-02-11T15:00:01  *** guilhermeblanco has quit IRC
285 2020-02-11T15:07:31  *** EagleTM has joined #bitcoin-core-dev
286 2020-02-11T15:07:37  *** jarthur has joined #bitcoin-core-dev
287 2020-02-11T15:12:03  *** EagleTM has quit IRC
288 2020-02-11T15:12:07  *** jarthur has quit IRC
289 2020-02-11T15:14:48  *** promag has quit IRC
290 2020-02-11T15:18:20  *** SAnnaBot has joined #bitcoin-core-dev
291 2020-02-11T15:21:07  *** ddustin has joined #bitcoin-core-dev
292 2020-02-11T15:25:15  *** ddustin has quit IRC
293 2020-02-11T15:32:52  *** andrewtoth has joined #bitcoin-core-dev
294 2020-02-11T15:39:51  *** jarthur has joined #bitcoin-core-dev
295 2020-02-11T15:44:44  *** turbo_choo has quit IRC
296 2020-02-11T15:48:17  *** mdunnio has joined #bitcoin-core-dev
297 2020-02-11T15:48:57  *** goatpig has quit IRC
298 2020-02-11T15:49:07  *** jonatack has quit IRC
299 2020-02-11T15:57:56  *** ghost43 has quit IRC
300 2020-02-11T15:58:46  *** ghost43 has joined #bitcoin-core-dev
301 2020-02-11T16:04:06  *** jonatack has joined #bitcoin-core-dev
302 2020-02-11T16:06:51  *** cubancorona has joined #bitcoin-core-dev
303 2020-02-11T16:11:23  *** jarthur has quit IRC
304 2020-02-11T16:13:43  *** goatpig has joined #bitcoin-core-dev
305 2020-02-11T16:16:15  *** Highway61 has quit IRC
306 2020-02-11T16:28:18  *** andrewtoth has quit IRC
307 2020-02-11T16:28:40  *** andrewtoth has joined #bitcoin-core-dev
308 2020-02-11T16:29:11  *** pabed____ has quit IRC
309 2020-02-11T16:36:15  *** dviola has joined #bitcoin-core-dev
310 2020-02-11T16:41:22  *** ghost43 has quit IRC
311 2020-02-11T16:42:06  *** ghost43 has joined #bitcoin-core-dev
312 2020-02-11T16:43:27  <jb55> sipa: do we know how slow passing around vector of vectors is in script eval? its the one thing I noticed when writing my own script interpreter, that can't be good for overall perf? or does it not matter much.
313 2020-02-11T16:46:22  <sipa> jb55: where specifically?
314 2020-02-11T16:46:35  <jb55> sipa: I'm working from memory, sec I'll look
315 2020-02-11T16:48:53  <jb55> sipa: the stack, first argument to EvalScript
316 2020-02-11T16:51:46  <sipa> that one is passed bt reference
317 2020-02-11T16:51:51  <sipa> *by
318 2020-02-11T16:52:41  <jb55> sipa: like, is vector moving contiguous chunks of memory on each operations, or just pointers to chunks?
319 2020-02-11T16:52:50  <jb55> talking about the inner vector in stack
320 2020-02-11T16:53:34  <sipa> that depends on the operation
321 2020-02-11T16:53:45  <sipa> hard to say without a specific case to talk about
322 2020-02-11T17:00:52  <jb55> I think I just misunderstood the memory layout... looks like its all points to dynamically allocated memory, so my concern wasn't really valid, modulo you could probably come up with something more cache friendly.
323 2020-02-11T17:02:08  <sipa> oh, you definitely can
324 2020-02-11T17:02:30  <sipa> but most stack affecting operations only happen once during script execution
325 2020-02-11T17:03:03  <sipa> one crazy one is OP_ROLL that can cause a huge amount of memory operations
326 2020-02-11T17:03:09  *** emilengler has quit IRC
327 2020-02-11T17:04:40  *** Talkless has joined #bitcoin-core-dev
328 2020-02-11T17:05:19  <jb55> but alas, consensus code. probably won't be able to make drastic changes to that just for a slight perf increase
329 2020-02-11T17:14:51  <sipa> well, if it doesn't hurt it's also not worth optimizing :)
330 2020-02-11T17:15:27  *** promag has joined #bitcoin-core-dev
331 2020-02-11T17:19:51  *** promag has quit IRC
332 2020-02-11T17:32:39  *** ddustin has joined #bitcoin-core-dev
333 2020-02-11T17:40:28  *** ddustin has quit IRC
334 2020-02-11T18:00:02  *** SAnnaBot has quit IRC
335 2020-02-11T18:16:06  *** Zao_ has joined #bitcoin-core-dev
336 2020-02-11T18:24:36  <jeremyrubin> you could imagine making everything COW non atomic shared pointers
337 2020-02-11T18:25:07  <sipa> that wouldn't help with OP_ROLL actually
338 2020-02-11T18:25:14  <jeremyrubin> hang on
339 2020-02-11T18:28:54  *** jarthur has joined #bitcoin-core-dev
340 2020-02-11T18:29:06  <jeremyrubin> had a phone call come up was going to suggest not doing this
341 2020-02-11T18:49:27  <jeremyrubin> anyways my point was going to be that it would help with things like OP_PICK but not OP_ROLL because any time you're moving something it has to move a lot of pointers on the stack.
342 2020-02-11T18:51:35  <jeremyrubin> doing this plus a double linked list would be the space/time tradeoff you'd want to make
343 2020-02-11T18:51:53  <jeremyrubin> (maybe single works too...)
344 2020-02-11T18:52:08  <jeremyrubin> Then you could detach a node and rotate it without having to do O(n) moves
345 2020-02-11T18:53:01  <jeremyrubin> But, then you would have to walk the entire list for a lot of operations which could be just as bad
346 2020-02-11T18:53:07  <aj> i think a deque instead of a vector would fix ROLL for very large stacks on some implementations
347 2020-02-11T18:53:23  <jeremyrubin> not quite
348 2020-02-11T18:53:50  <jeremyrubin> deque remove is O(N)
349 2020-02-11T18:54:55  <aj> http://www.cplusplus.com/reference/deque/deque/erase/ -- only linear in remaining elements on some implementations
350 2020-02-11T18:55:07  <jeremyrubin> which is the same as std::vector no?
351 2020-02-11T18:55:36  <aj> it's a vector of vectors instead sometimes apparently
352 2020-02-11T18:56:08  <jeremyrubin> OP_DEPTH OP_ROLL gets you the last thing on the stack (or OP_DEPTH OP_1 OP_ROLL...)
353 2020-02-11T18:56:35  <jeremyrubin> aj: I mean that remove from vector is also linear in remaining elements
354 2020-02-11T18:56:56  <jeremyrubin> but you can use some efficient backshifting thing IIRC
355 2020-02-11T18:57:44  <jeremyrubin> The benefit of the deque is just at best a 1/2 improvement
356 2020-02-11T18:57:58  *** dviola has quit IRC
357 2020-02-11T18:58:00  <aj> http://www.cplusplus.com/reference/vector/vector/erase/ -- vector is always linear in subsequent elements, deque can be more efficient
358 2020-02-11T18:58:15  <jeremyrubin> It's at most 1/2
359 2020-02-11T18:58:54  <jeremyrubin> err I guess you're saying if it is a vector<vector<T>> then you can be better...
360 2020-02-11T18:58:56  <jeremyrubin> I see
361 2020-02-11T18:59:03  <jeremyrubin> depending on the bucket size
362 2020-02-11T18:59:20  <aj> bucket size is a constant factor, so you ignore that with O notation
363 2020-02-11T18:59:34  <aj> but probably means it's worse for every real script
364 2020-02-11T18:59:40  <jeremyrubin> well ~kinda. If the bucket size is > max stack...
365 2020-02-11T19:00:14  <jeremyrubin> Then for big O we can ignore, but for our intepreter we're already at the maximally bad thing
366 2020-02-11T19:00:18  <jeremyrubin> Buckets are what? 128?
367 2020-02-11T19:00:33  <jeremyrubin> (in normal implementations)
368 2020-02-11T19:01:56  <jeremyrubin> it seems implementations vary widely
369 2020-02-11T19:02:23  <jeremyrubin> something like 200 stack elements
370 2020-02-11T19:02:51  <jeremyrubin> MAX_STACK_SIZE = 1000
371 2020-02-11T19:08:11  <jeremyrubin> (I think it'd be better to stick with something that has more regular implementations so that there isn't divergent performance characteristics)
372 2020-02-11T19:11:43  <sipa> as long as the max stack size isn't increased there is no reason to worry about any of this
373 2020-02-11T19:18:00  *** sdaftuar has joined #bitcoin-core-dev
374 2020-02-11T19:18:20  <sdaftuar> jeremyrubin: around?
375 2020-02-11T19:18:43  <jeremyrubin> ya
376 2020-02-11T19:19:05  *** kristapsk has joined #bitcoin-core-dev
377 2020-02-11T19:19:26  <jeremyrubin> So I thought of a hybrid approach you might like
378 2020-02-11T19:19:28  <sdaftuar> i thought it might be easier to talk about your very detailed comment here rather than go back and forth on your PR
379 2020-02-11T19:19:43  <sdaftuar> first observation: you make a good point about memory blowup
380 2020-02-11T19:19:43  <jeremyrubin> Keep the cache, but only store it if it is larger than 32 elements or something
381 2020-02-11T19:20:01  * jeremyrubin listening mode
382 2020-02-11T19:20:48  <sdaftuar> i have not quite worked through your picture examples involving N/2 parents and N/2 children yet, but i had a question for you about your linear example-
383 2020-02-11T19:21:26  <jeremyrubin> ask away!
384 2020-02-11T19:21:28  <sdaftuar> in the linear case, aren't we doing N^2 lookups into GetMempoolChildren, versus something much smaller if we use a cache?
385 2020-02-11T19:21:43  *** DeanGuss has quit IRC
386 2020-02-11T19:21:44  <sdaftuar> I think N
387 2020-02-11T19:21:49  <jeremyrubin> Good question.
388 2020-02-11T19:22:23  <jeremyrubin> At node M (M < N), we look at the cache below us and do (N-M) lookups
389 2020-02-11T19:22:43  <sdaftuar> it's just one lookup?
390 2020-02-11T19:22:54  <sdaftuar> the cache is built from bottom to top
391 2020-02-11T19:22:55  <jeremyrubin> but what's the length of the cache!
392 2020-02-11T19:23:13  <jeremyrubin> We need to iterate over that cache to "read it"
393 2020-02-11T19:23:25  <jeremyrubin> So maybe I'm confusing you when I say lookup
394 2020-02-11T19:23:26  *** cubancorona has quit IRC
395 2020-02-11T19:23:32  <sdaftuar> well, it's one map lookup, and then we read N-M elements i guess
396 2020-02-11T19:23:36  <jeremyrubin> Yes
397 2020-02-11T19:23:41  <jeremyrubin> That's the point I'm making
398 2020-02-11T19:24:00  <jeremyrubin> Reading those N - M elements also requires visiting them for de-duplication
399 2020-02-11T19:24:07  <jeremyrubin> Pre epochs, this was... really bad
400 2020-02-11T19:24:32  <jeremyrubin> (well in the linear case not so bad, but in general n log n to merge into our set)
401 2020-02-11T19:24:41  <sdaftuar> oh right
402 2020-02-11T19:24:56  <jeremyrubin> Post epochs, you just iterate and visit
403 2020-02-11T19:25:02  <sdaftuar> yeah so if your point is we're already doing N^2 work in this pathological case, that doing a little more N^2 work isn't asymptotically worse
404 2020-02-11T19:25:09  <sdaftuar> then maybe that's a good point
405 2020-02-11T19:25:10  <jeremyrubin> We could maybe make an optimization where if you only have one child we do something smart
406 2020-02-11T19:25:32  <jeremyrubin> sdaftuar: yeah that's my point
407 2020-02-11T19:25:33  <sdaftuar> i wonder if we should be doing something else altogether in these pathological cases
408 2020-02-11T19:25:52  <jeremyrubin> evict everything and reinsert isn't too bad
409 2020-02-11T19:25:54  <sdaftuar> hmm, ok i will give this more thought, thanks for the clarification
410 2020-02-11T19:26:37  <jeremyrubin> I think the case I'm concerned about most is a -> b -> c....-> {big tree of things}
411 2020-02-11T19:27:09  <jeremyrubin> because if the first part is N/2 and the big tree of things is (N/2)^2, it can get kind of annoying
412 2020-02-11T19:27:15  <jeremyrubin> and then you really do want a cache
413 2020-02-11T19:27:50  <sdaftuar> you're saying there's a sweet spot where the memory tradeoff is worth the cpu benefit?
414 2020-02-11T19:27:55  <jeremyrubin> which might be why only caching when you have more than X things not in the cache could be nice
415 2020-02-11T19:28:30  <jeremyrubin> Yeah. essentially any time you are running and you trigger some traversal limit excluding things in the cache, you make a new cache entry
416 2020-02-11T19:28:45  <jeremyrubin> right now we work this way, but the limit is 1
417 2020-02-11T19:29:44  <jeremyrubin> you could imagine preferring to traverse until our traversal is having a poor hit rate and is big. E.g., we traversed 10000 things, but we only saw 100 things uniquely, so we should create a cache line for this sub-unit
418 2020-02-11T19:30:01  <sdaftuar> if i understand you correctly -- something like this is just a constant factor benefit at best, fundamentally we're pretty screwed by pathological chains in reorged blocks, right?
419 2020-02-11T19:30:11  <jeremyrubin> Yeah
420 2020-02-11T19:30:28  <jeremyrubin> But we can maybe make the constants large enough so that the pathological case is bounded
421 2020-02-11T19:30:34  <sdaftuar> so that is disappointing :)  i mean, i feel like we need to do something just much smarter
422 2020-02-11T19:30:39  <jeremyrubin> maybe goes from N^3 to N^2
423 2020-02-11T19:30:50  <sdaftuar> N here is the number of transactions in a block though
424 2020-02-11T19:30:56  <jeremyrubin> But overall my opinion is I expect the map lookups and insertions (using ordered or not) to dominate just not using a map
425 2020-02-11T19:30:57  <sdaftuar> which is way too big for even N^2 i think
426 2020-02-11T19:31:22  <jeremyrubin> Well so that's what I did the math on, or tried to
427 2020-02-11T19:31:32  <jeremyrubin> smallest txn is 61 bytes
428 2020-02-11T19:32:09  <sdaftuar> yeah well the memory blowup there is certainly bad, but the cpu blowup is something that is more fundamentally broken i think?
429 2020-02-11T19:32:23  <sdaftuar> i mean, we can take your advice and get rid of the cache to avoid OOM
430 2020-02-11T19:32:33  <jeremyrubin> also fundamentally a memory blowup implies a CPU blowup
431 2020-02-11T19:32:35  <sdaftuar> but we need to rearchitect what happens on a reorg to get rid of the CPU DoS
432 2020-02-11T19:32:41  <jeremyrubin> because you need to touch the memory anywasy
433 2020-02-11T19:32:50  <sdaftuar> sure
434 2020-02-11T19:32:54  <jeremyrubin> it only matters if the memory blowup is less than the CPU blowup
435 2020-02-11T19:33:40  <jeremyrubin> But I agree
436 2020-02-11T19:33:56  <jeremyrubin> We're talking about something very slow to deal with
437 2020-02-11T19:35:25  <jeremyrubin> how long do we think traversal takes?
438 2020-02-11T19:35:38  <jeremyrubin> Because another option is to parallelize it
439 2020-02-11T19:36:22  <sdaftuar> i think maybe the best option is to evict things that have too many descendants? or come up with some lazily updating data structures
440 2020-02-11T19:37:16  <sdaftuar> not sure exactly how to do either of those ideas
441 2020-02-11T19:37:24  <jeremyrubin> Or maybe we run a thread which times out the reorg
442 2020-02-11T19:37:32  <jeremyrubin> and evicts everything if it took too long to update
443 2020-02-11T19:37:56  <jeremyrubin> E.g., optimistically this should be simple. But if it takes too long, do the dumb thing
444 2020-02-11T19:38:03  <sdaftuar> the fundamental problem is that we need to get the mempool back in a consistent state, ideally with some useful fee-paying transactions, so that we can produce a new block template as quickly as possible
445 2020-02-11T19:39:12  <jeremyrubin> Maybe we should spend the effort to time some "worst case" blocks?
446 2020-02-11T19:39:15  <sdaftuar> so evicting everything is nice for consistency, but not really the right thing in the long run
447 2020-02-11T19:39:40  <sdaftuar> yeah i will try to do that.  after giving this more thought and reading your writeup, i'm not optimistic about the results
448 2020-02-11T19:39:55  <jeremyrubin> sdaftuar: hence do the right thing optimistically (e.g., 10 seconds? 100 seconds?) and otherwise evict 50% and repeat?
449 2020-02-11T19:39:57  <sdaftuar> but maybe you're right that we're within a constant factor of workable
450 2020-02-11T19:40:11  <sdaftuar> small constant factor*
451 2020-02-11T19:40:27  <jeremyrubin> (100 seconds/((1e6/61)**2)) == 370 ns
452 2020-02-11T19:41:26  <jeremyrubin> but it's actual n-1*n/2 so
453 2020-02-11T19:41:35  <jeremyrubin> 750 ns
454 2020-02-11T19:42:59  <jeremyrubin> We can parallelize traversals (let's assume this helps us by at most a factor of 2 because of concurrency overhead)
455 2020-02-11T19:43:02  <sdaftuar> if you want to be a bit more depressed, we're not bounded by the size of a block here
456 2020-02-11T19:43:11  <jeremyrubin> Ah is it mempool bounded?
457 2020-02-11T19:43:18  <jeremyrubin> I thought we were block bounded
458 2020-02-11T19:43:37  <jeremyrubin> I guess we're updating descendents in mempool?
459 2020-02-11T19:43:38  <sdaftuar> in a multi-block reorg, i think we will process a big batch of transactions in this way
460 2020-02-11T19:43:43  *** vasild_ has quit IRC
461 2020-02-11T19:43:53  <sdaftuar> and yes we can have an unbounded number of descendants in mempool
462 2020-02-11T19:44:00  <jeremyrubin> Well in multi-block reorg we should definitely go block by block not all at once
463 2020-02-11T19:44:10  <jeremyrubin> But in multi-block I guess we can then get unbounded?
464 2020-02-11T19:44:17  <jeremyrubin> I thought we have a 25 limit presently?
465 2020-02-11T19:44:27  <sdaftuar> the 25 limit does not apply in the case of a reorg
466 2020-02-11T19:44:31  <jeremyrubin> Ah
467 2020-02-11T19:44:47  *** ddustin has joined #bitcoin-core-dev
468 2020-02-11T19:44:49  <jeremyrubin> So in multi block it might not be that bad to at a certain point evict everything and resubmit to mempool
469 2020-02-11T19:44:51  <sdaftuar> the issue is that our main code path for accepting a new transaction to the mempool implicitly assumes no in-mempool descendants
470 2020-02-11T19:45:17  *** vasild has joined #bitcoin-core-dev
471 2020-02-11T19:45:22  <sdaftuar> jeremyrubin: i think conceptually that is corret
472 2020-02-11T19:45:24  <jeremyrubin> because then we're at least guaranteed to not have too much N^2 stuff
473 2020-02-11T19:45:39  <jeremyrubin> But it still is sucky
474 2020-02-11T19:46:40  <sdaftuar> architecting it might be a bit messy, but maybe the right intuition is to build the mempool from scratch by reinserting things from disconnected blocks in-order for just as long as you need to produce a reasonable new fee-paying block
475 2020-02-11T19:46:48  <sdaftuar> and then let the mining code run, and go back to inserting more stuff, etc
476 2020-02-11T19:47:04  *** Highway61 has joined #bitcoin-core-dev
477 2020-02-11T19:47:13  <sdaftuar> i think we should have some alternative to the whole thing hanging if we get some messy blocks reorged out, anyway
478 2020-02-11T19:48:11  <jeremyrubin> I guess as a sidebar, if we know that reorging is already *yikes* I see a few paths forward for this PR: 1) drop entirely because review not worth if we're going to need to re-do it all 2) Accept, if we can show that it's better/not worse 3) Accept half and keep cache so we at least preserve the same failure modes 4) Accept both, knowing we have new/different failure modes 5) time out after 100 seconds, switch algorithms, try
479 2020-02-11T19:48:12  <jeremyrubin> again for unbounded with caching?
480 2020-02-11T19:48:55  <jeremyrubin> the switching between algorithms with some exponential backing on time isn't actually that dumb.
481 2020-02-11T19:49:12  <sdaftuar> i think either 2/4 or 3 are the most likely outcomes IMO? but i want to do some more benchmarking to get a sense of how bad things acn be
482 2020-02-11T19:49:16  <aj> a 100 second "stall" sounds horrible?
483 2020-02-11T19:49:17  <jeremyrubin> Because you would need to have an attack against both the memory version and the time version which maybe we can prove is impossible
484 2020-02-11T19:49:37  <jeremyrubin> aj: scylla charbidis
485 2020-02-11T19:50:06  <jeremyrubin> This isn't a problem that we're introducing, the existing algorithms can already be wicked slow
486 2020-02-11T19:50:28  <jeremyrubin> the 100 second switch is *in the hopes* that a different algorithm could be faster for this reorg
487 2020-02-11T19:50:54  <jeremyrubin> We could measure historical reorg times (e.g., if it's 10s per block, do 20, and then switch back and forth doubling)
488 2020-02-11T19:51:46  <jeremyrubin> The idea is just to time a give up point and switch to a different algorithm (for the rest of the block that is, we're still making monotonic progress)
489 2020-02-11T19:53:02  <aj> if we've got a different algorithm that goes faster, seems better to do that from the start i guess
490 2020-02-11T19:53:08  <jeremyrubin> aj we don't
491 2020-02-11T19:53:14  <jeremyrubin> you can review the problem here
492 2020-02-11T19:53:22  <jeremyrubin> #18063
493 2020-02-11T19:53:23  <gribble> https://github.com/bitcoin/bitcoin/issues/18063 | Improve UpdateForDescendants by using Epochs and Removing CacheMap by JeremyRubin · Pull Request #18063 · bitcoin/bitcoin · GitHub
494 2020-02-11T19:54:01  <jeremyrubin> The algorithms we have with or without caching have different worst cases
495 2020-02-11T19:54:14  <jeremyrubin> And caching opens up to memory based attackers
496 2020-02-11T19:54:32  <jeremyrubin> so short of no new magic bullet, getting rid of caching reduces attack surface to just time based DoS
497 2020-02-11T19:54:33  <aj> all we really need is to from {reorged blocks} + {old mempool} to 4 to 8 megaweight of highish-value txs in a new mempool as quickly as possible
498 2020-02-11T19:54:51  *** ddustin has quit IRC
499 2020-02-11T19:54:52  <sdaftuar> aj: agreed
500 2020-02-11T19:55:59  <jeremyrubin> we could filter the to_reorg set by feerate
501 2020-02-11T19:56:37  <jeremyrubin> with a max 8 megaweight ordered map, dropping anything else
502 2020-02-11T19:57:07  <jeremyrubin> Then, we could process the updates for just that max feerate list
503 2020-02-11T19:58:06  <jeremyrubin> But then the descendants could still be unbounded.
504 2020-02-11T19:59:51  *** jarthur_ has joined #bitcoin-core-dev
505 2020-02-11T20:00:02  *** sdaftuar has quit IRC
506 2020-02-11T20:00:21  <jeremyrubin> didn't even say bye :'(
507 2020-02-11T20:00:25  *** sdaftuar has joined #bitcoin-core-dev
508 2020-02-11T20:00:31  <jeremyrubin> ragequit
509 2020-02-11T20:00:37  <aj> ragerejoin
510 2020-02-11T20:00:45  <sdaftuar> maybe i quit in disgust at this problem
511 2020-02-11T20:01:02  <sdaftuar> (or maybe my internet is flaky)
512 2020-02-11T20:01:34  <jeremyrubin> hah
513 2020-02-11T20:02:15  <jeremyrubin> Anyways... maybe I should abandon #18603 for the "fast track" and open up some more obvious mempool wins (like eliminating mapLinks)?
514 2020-02-11T20:02:16  <gribble> https://github.com/bitcoin/bitcoin/issues/18603 | HTTP Error 404: Not Found
515 2020-02-11T20:02:27  <jeremyrubin> #18063
516 2020-02-11T20:02:29  <gribble> https://github.com/bitcoin/bitcoin/issues/18063 | Improve UpdateForDescendants by using Epochs and Removing CacheMap by JeremyRubin · Pull Request #18063 · bitcoin/bitcoin · GitHub
517 2020-02-11T20:02:53  <jeremyrubin> It seems like it's going to take some time to ensure we're doing the right thing.
518 2020-02-11T20:03:10  <aj> yay for easy wins?
519 2020-02-11T20:03:14  <sdaftuar> hmm, i think if we're not getting rid of cachemap, it should be the case that your patch is strictly better.  i think i need to do a little more work to determine whether removing the cache is strictly better, probably better overall but maybe not strictly better, or somehow worse
520 2020-02-11T20:03:32  *** jarthur has quit IRC
521 2020-02-11T20:03:35  <sdaftuar> but eg the first commit seems like a no-brainer?
522 2020-02-11T20:04:01  <jeremyrubin> ok why don't I open up a new PR with just the no-brainer one?
523 2020-02-11T20:04:26  <jeremyrubin> We can keep the broader discussion going on 18063
524 2020-02-11T20:04:33  <sdaftuar> sure, that's fine with me
525 2020-02-11T20:04:59  <jeremyrubin> And then we can keep progress up on fixing all the other hot mess in the mempool ;)
526 2020-02-11T20:05:02  <aj> sdaftuar: did you get a chance to look at https://github.com/ajtowns/bitcoin/commit/43528b17e88ec5b8378c923106053561c909a7e5 ?
527 2020-02-11T20:05:49  <aj> sdaftuar: does an O( peers * log(txs_announced) ) lookup to retry NOTFOUNDs
528 2020-02-11T20:05:51  <sdaftuar> oh, i did look at it briefly -- my immediate reaction was a small amount of concern at iterating over all peers whenever there's a NOTFOUND
529 2020-02-11T20:07:08  <sdaftuar> because we coudl get up to 100 at once, i think, in one message -- so that's like 10k map lookups?
530 2020-02-11T20:07:59  <sdaftuar> if we spaced out processing though then i think that would be fine, or maybe it's fast enough as-is and i just need to benchmark it to convince myself
531 2020-02-11T20:09:00  <aj> hmm, 100 is also the max in flight from a peer
532 2020-02-11T20:09:36  <sdaftuar> right, that's why i figure we could get 100 at once
533 2020-02-11T20:10:29  <sdaftuar> (we coudl get more from a malicious peer, but we filter out things that weren't in-flight, so 100 should be the right max)
534 2020-02-11T20:10:39  <aj> txs_announced maxes out at 100k
535 2020-02-11T20:10:54  <sdaftuar> oh, right
536 2020-02-11T20:10:58  *** bitcoin-git has joined #bitcoin-core-dev
537 2020-02-11T20:10:58  <bitcoin-git> [bitcoin] JeremyRubin opened pull request #18120: Change UpdateForDescendants to use Epochs (master...epoch-mempool-clean-split-updatefordescendants-pt1) https://github.com/bitcoin/bitcoin/pull/18120
538 2020-02-11T20:10:59  *** bitcoin-git has left #bitcoin-core-dev
539 2020-02-11T20:11:47  <jeremyrubin> ok feel free to review just that chunk (same as the commit from the other branch)
540 2020-02-11T20:11:54  <sdaftuar> jeremyrubin: will do
541 2020-02-11T20:11:59  <aj> jeremyrubin: ack
542 2020-02-11T20:12:12  <aj> hmm, maybe that's ambiguous :)
543 2020-02-11T20:12:17  <sdaftuar> ready for merge!
544 2020-02-11T20:12:25  <jeremyrubin> lgtm
545 2020-02-11T20:12:50  <jeremyrubin> sdaftuar: good catch with the grandchild it thing btw earlier
546 2020-02-11T20:12:57  <jeremyrubin> We should probably have a test for that...
547 2020-02-11T20:13:15  <sdaftuar> agreed, that code is definitely undertested
548 2020-02-11T20:14:30  <sdaftuar> oh! i misremembered how chain limits get applied in the case of a reorg
549 2020-02-11T20:15:15  <sdaftuar> so there are an unbounded number of in-mempool descendants, but there is a bound on chain limits with respect to what is in the block(s)
550 2020-02-11T20:15:16  <jeremyrubin> I was just thinking more about that
551 2020-02-11T20:15:19  *** owowo has quit IRC
552 2020-02-11T20:15:34  <sdaftuar> so the worst-case scenarios we were talking about are not quite right
553 2020-02-11T20:15:47  <jeremyrubin> The issue with the unbounded in-mempool descendants is also that the cache entries can get HUGE
554 2020-02-11T20:15:55  <jeremyrubin> e.g., the entire mempool
555 2020-02-11T20:15:56  <sdaftuar> yes
556 2020-02-11T20:16:13  <jeremyrubin> so we should definitely get rid of the cache IMO, even if our runtime goes up
557 2020-02-11T20:16:25  <jeremyrubin> because the entire mempool * N is bad
558 2020-02-11T20:17:20  <jeremyrubin> like maybe even brick the network today with a few blocks bad
559 2020-02-11T20:17:26  <sdaftuar> well, one alternative is to memory cap it instead?
560 2020-02-11T20:17:33  <jeremyrubin> Or LRU cache
561 2020-02-11T20:17:37  <sdaftuar> right
562 2020-02-11T20:18:33  <jeremyrubin> IIRC the philosophy that BCash deals with this is not... awful?
563 2020-02-11T20:18:43  <jeremyrubin> step 1: clone the mempool
564 2020-02-11T20:18:50  <jeremyrubin> step 2: fork the reorging
565 2020-02-11T20:18:54  <sdaftuar> it's starting to make more sense to me though that if what is in the mempool is bounded in some reasonable-ish way, and what gets added back from blocks is bounded in some way, that we could get comfortable with some kind of CPU bound on the combination and be comfortable dropping the cache
566 2020-02-11T20:19:04  <jeremyrubin> step3: continue mining on the non-reorg chain
567 2020-02-11T20:19:12  <jeremyrubin> step4; if reorg finishes, switch
568 2020-02-11T20:20:02  <jeremyrubin> if the reorg never finishes then it was done by a malicious miner, so it's not economically good anyways maybe
569 2020-02-11T20:20:10  <sdaftuar> not sure that really makes sense, as until we return a new block template, mining on the old chain is almost certainly what the default behavior of miners would be regardless
570 2020-02-11T20:20:20  <sdaftuar> so i think our job is to make it so that we can produce a valid new block on the new chain as fast as possible
571 2020-02-11T20:20:37  <jeremyrubin> Fair point
572 2020-02-11T20:21:48  <jeremyrubin> I wonder if a randomized algorithm can also help here
573 2020-02-11T20:21:49  *** owowo has joined #bitcoin-core-dev
574 2020-02-11T20:22:01  <jeremyrubin> The attacker is exploiting some specific structures
575 2020-02-11T20:22:22  <jeremyrubin> I wonder if there's an algorithm with a random order that can prevent them from exposing some of the worst case stuff
576 2020-02-11T20:22:33  <jeremyrubin> but being on average much slower maybe
577 2020-02-11T20:23:01  *** Talkless has quit IRC
578 2020-02-11T20:25:57  *** jarthur_ has quit IRC
579 2020-02-11T20:26:12  *** jarthur has joined #bitcoin-core-dev
580 2020-02-11T20:38:04  *** PaulTroon has quit IRC
581 2020-02-11T20:44:18  *** Guyver2 has joined #bitcoin-core-dev
582 2020-02-11T20:44:45  *** bitcoin-git has joined #bitcoin-core-dev
583 2020-02-11T20:44:45  <bitcoin-git> [bitcoin] hebasto opened pull request #18121: gui: Throttle GUI update pace when -reindex (master...20200211-reindex-gui) https://github.com/bitcoin/bitcoin/pull/18121
584 2020-02-11T20:44:46  *** bitcoin-git has left #bitcoin-core-dev
585 2020-02-11T21:00:02  *** Zao_ has quit IRC
586 2020-02-11T21:00:28  *** goatpig has quit IRC
587 2020-02-11T21:03:45  *** timothy has quit IRC
588 2020-02-11T21:10:21  *** Highway61 has quit IRC
589 2020-02-11T21:12:58  *** Victorsueca has quit IRC
590 2020-02-11T21:13:19  *** Victorsueca has joined #bitcoin-core-dev
591 2020-02-11T21:15:10  *** bsm1175321 has joined #bitcoin-core-dev
592 2020-02-11T21:18:05  *** Khaytsus1 has joined #bitcoin-core-dev
593 2020-02-11T21:18:22  *** jonatack has quit IRC
594 2020-02-11T21:27:43  *** DeanGuss has joined #bitcoin-core-dev
595 2020-02-11T21:27:53  *** PaulTroon has joined #bitcoin-core-dev
596 2020-02-11T21:32:27  *** PaulTroon has quit IRC
597 2020-02-11T21:43:42  *** jonatack has joined #bitcoin-core-dev
598 2020-02-11T21:51:30  *** morcos has quit IRC
599 2020-02-11T21:51:49  *** morcos has joined #bitcoin-core-dev
600 2020-02-11T21:58:12  *** ddustin has joined #bitcoin-core-dev
601 2020-02-11T22:09:32  *** tecnecio_ has quit IRC
602 2020-02-11T22:11:09  *** ddustin has quit IRC
603 2020-02-11T22:15:57  *** promag has joined #bitcoin-core-dev
604 2020-02-11T22:19:31  *** michagogo has joined #bitcoin-core-dev
605 2020-02-11T22:20:19  *** promag has quit IRC
606 2020-02-11T22:20:46  *** bitcoin-git has joined #bitcoin-core-dev
607 2020-02-11T22:20:47  <bitcoin-git> [bitcoin] theStack opened pull request #18122: rpc: update validateaddress RPCExamples to bech32 (master...20200211-rpc-update-validateaddress-rpcexamples-to-bech32) https://github.com/bitcoin/bitcoin/pull/18122
608 2020-02-11T22:20:48  *** bitcoin-git has left #bitcoin-core-dev
609 2020-02-11T22:28:48  *** bitcoin-git has joined #bitcoin-core-dev
610 2020-02-11T22:28:48  <bitcoin-git> [bitcoin] ryanofsky opened pull request #18123: gui: Fix race in WalletModel::pollBalanceChanged (master...pr/pollbug) https://github.com/bitcoin/bitcoin/pull/18123
611 2020-02-11T22:28:50  *** bitcoin-git has left #bitcoin-core-dev
612 2020-02-11T22:31:14  *** filchef has quit IRC
613 2020-02-11T22:33:05  *** bitcoin-git has joined #bitcoin-core-dev
614 2020-02-11T22:33:05  <bitcoin-git> [bitcoin] practicalswift opened pull request #18124: init: Clarify C and C++ locale assumptions. Add locale sanity check to verify assumptions at run-time. (master...LocaleSanityCheck) https://github.com/bitcoin/bitcoin/pull/18124
615 2020-02-11T22:33:16  *** bitcoin-git has left #bitcoin-core-dev
616 2020-02-11T22:33:27  *** andrewtoth has quit IRC
617 2020-02-11T22:33:54  *** andrewtoth has joined #bitcoin-core-dev
618 2020-02-11T22:36:10  *** dviola has joined #bitcoin-core-dev
619 2020-02-11T23:00:14  *** mol has joined #bitcoin-core-dev
620 2020-02-11T23:03:23  *** Highway61 has joined #bitcoin-core-dev
621 2020-02-11T23:07:28  *** DeanGuss has quit IRC
622 2020-02-11T23:07:50  *** DeanGuss has joined #bitcoin-core-dev
623 2020-02-11T23:09:25  *** jcoe has quit IRC
624 2020-02-11T23:10:33  *** mdunnio has quit IRC
625 2020-02-11T23:15:17  *** Guyver2 has quit IRC
626 2020-02-11T23:18:54  *** EagleTM has joined #bitcoin-core-dev
627 2020-02-11T23:43:13  *** hirish_ has quit IRC
628 2020-02-11T23:56:59  *** Zenton has quit IRC