1 2020-09-08T00:00:02  *** AIM` has quit IRC
  2 2020-09-08T00:36:56  *** kanzure has quit IRC
  3 2020-09-08T00:37:07  *** kanzure has joined #bitcoin-core-dev
  4 2020-09-08T00:46:25  *** davec has quit IRC
  5 2020-09-08T00:52:50  *** davec has joined #bitcoin-core-dev
  6 2020-09-08T00:56:50  *** lahwran has joined #bitcoin-core-dev
  7 2020-09-08T01:12:02  *** berndj has quit IRC
  8 2020-09-08T01:12:18  *** berndj has joined #bitcoin-core-dev
  9 2020-09-08T01:40:09  *** luke-jr has quit IRC
 10 2020-09-08T01:41:04  *** luke-jr has joined #bitcoin-core-dev
 11 2020-09-08T02:07:05  *** arowser has quit IRC
 12 2020-09-08T02:07:31  *** arowser has joined #bitcoin-core-dev
 13 2020-09-08T02:38:52  *** justanotheruser has quit IRC
 14 2020-09-08T02:40:24  *** Highway61 has quit IRC
 15 2020-09-08T02:45:05  *** arowser has quit IRC
 16 2020-09-08T02:45:28  *** arowser has joined #bitcoin-core-dev
 17 2020-09-08T02:56:44  *** vadorovsky__ has joined #bitcoin-core-dev
 18 2020-09-08T02:59:03  *** mrostecki_ has quit IRC
 19 2020-09-08T03:00:01  *** lahwran has quit IRC
 20 2020-09-08T03:22:05  *** arowser has quit IRC
 21 2020-09-08T03:22:17  *** davidfg41 has joined #bitcoin-core-dev
 22 2020-09-08T03:22:35  *** arowser has joined #bitcoin-core-dev
 23 2020-09-08T03:23:59  *** Highway61 has joined #bitcoin-core-dev
 24 2020-09-08T03:25:50  *** dongcarl has joined #bitcoin-core-dev
 25 2020-09-08T03:28:11  *** Highway61 has quit IRC
 26 2020-09-08T03:38:16  *** Highway61 has joined #bitcoin-core-dev
 27 2020-09-08T03:38:32  *** vadorovsky__ has quit IRC
 28 2020-09-08T03:39:00  *** vadorovsky__ has joined #bitcoin-core-dev
 29 2020-09-08T03:59:32  *** Davterra has quit IRC
 30 2020-09-08T03:59:48  *** Davterra has joined #bitcoin-core-dev
 31 2020-09-08T04:15:40  *** Highway61 has quit IRC
 32 2020-09-08T04:22:04  *** Highway61 has joined #bitcoin-core-dev
 33 2020-09-08T04:24:54  *** Highway61 has quit IRC
 34 2020-09-08T04:25:14  *** Highway61 has joined #bitcoin-core-dev
 35 2020-09-08T04:31:59  *** Highway61 has quit IRC
 36 2020-09-08T04:32:30  *** Highway61 has joined #bitcoin-core-dev
 37 2020-09-08T04:43:25  *** Highway61 has quit IRC
 38 2020-09-08T04:43:46  *** rodarmor has joined #bitcoin-core-dev
 39 2020-09-08T04:45:42  *** elenaIncognito has joined #bitcoin-core-dev
 40 2020-09-08T04:48:54  *** Highway61 has joined #bitcoin-core-dev
 41 2020-09-08T05:02:36  *** Emcy has quit IRC
 42 2020-09-08T05:02:38  *** Highway61 has quit IRC
 43 2020-09-08T05:04:33  *** Highway61 has joined #bitcoin-core-dev
 44 2020-09-08T05:04:38  *** Emcy has joined #bitcoin-core-dev
 45 2020-09-08T05:10:59  *** IGHOR has quit IRC
 46 2020-09-08T05:13:01  *** IGHOR has joined #bitcoin-core-dev
 47 2020-09-08T05:15:06  *** arowser has quit IRC
 48 2020-09-08T05:15:26  *** arowser has joined #bitcoin-core-dev
 49 2020-09-08T05:17:51  *** elenaIncognito has quit IRC
 50 2020-09-08T05:20:15  *** Highway61 has quit IRC
 51 2020-09-08T05:41:12  <fanquake> Wumpus / sipa: can you block maza1374
 52 2020-09-08T05:41:43  *** Davterra has quit IRC
 53 2020-09-08T05:42:04  *** arowser has quit IRC
 54 2020-09-08T05:42:46  *** arowser has joined #bitcoin-core-dev
 55 2020-09-08T05:57:07  *** bitcoin-git has joined #bitcoin-core-dev
 56 2020-09-08T05:57:08  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #19914: refactor: Do not pass chain params to CheckForStaleTipAndEvictPeers twice (master...2009-netNo2ChainParams) https://github.com/bitcoin/bitcoin/pull/19914
 57 2020-09-08T05:57:08  *** bitcoin-git has left #bitcoin-core-dev
 58 2020-09-08T05:58:37  *** worc3131 has quit IRC
 59 2020-09-08T06:00:01  *** davidfg41 has quit IRC
 60 2020-09-08T06:17:24  *** jonatack has quit IRC
 61 2020-09-08T06:21:22  *** nihui has joined #bitcoin-core-dev
 62 2020-09-08T06:23:57  *** wumpus has joined #bitcoin-core-dev
 63 2020-09-08T06:37:53  *** andreacab has joined #bitcoin-core-dev
 64 2020-09-08T06:42:14  *** andreacab has quit IRC
 65 2020-09-08T06:42:41  *** andreacab has joined #bitcoin-core-dev
 66 2020-09-08T06:44:05  *** arowser has quit IRC
 67 2020-09-08T06:44:37  *** arowser has joined #bitcoin-core-dev
 68 2020-09-08T06:47:18  *** andreacab has quit IRC
 69 2020-09-08T06:47:25  <gleb> #19895 should be closed I assume.
 70 2020-09-08T06:47:26  <gribble> https://github.com/bitcoin/bitcoin/issues/19895 | I find this line very offensive. · Issue #19895 · bitcoin/bitcoin · GitHub
 71 2020-09-08T06:49:28  *** Guyver2 has joined #bitcoin-core-dev
 72 2020-09-08T06:52:39  <aj> closed/locked
 73 2020-09-08T06:55:49  *** marcoagner has joined #bitcoin-core-dev
 74 2020-09-08T06:56:28  *** luke-jr has quit IRC
 75 2020-09-08T06:57:02  *** luke-jr has joined #bitcoin-core-dev
 76 2020-09-08T06:58:43  *** sipa has quit IRC
 77 2020-09-08T06:59:55  *** bitcoin-git has joined #bitcoin-core-dev
 78 2020-09-08T06:59:55  <bitcoin-git> [bitcoin] hebasto closed pull request #19913: refactor: Drop unused `UniqueLock(Mutex*, ...)` constructor in sync.h (master...200907-sync) https://github.com/bitcoin/bitcoin/pull/19913
 79 2020-09-08T06:59:56  *** bitcoin-git has left #bitcoin-core-dev
 80 2020-09-08T07:00:50  *** sipa has joined #bitcoin-core-dev
 81 2020-09-08T07:05:54  *** vadorovsky__ has quit IRC
 82 2020-09-08T07:06:16  *** vadorovsky__ has joined #bitcoin-core-dev
 83 2020-09-08T07:14:33  *** EagleTM has joined #bitcoin-core-dev
 84 2020-09-08T07:15:20  *** shesek has quit IRC
 85 2020-09-08T07:20:07  *** arowser has quit IRC
 86 2020-09-08T07:20:26  *** arowser has joined #bitcoin-core-dev
 87 2020-09-08T07:21:38  *** davterra has joined #bitcoin-core-dev
 88 2020-09-08T07:28:07  *** reallll has joined #bitcoin-core-dev
 89 2020-09-08T07:31:52  *** belcher_ has quit IRC
 90 2020-09-08T07:40:36  *** kljasdfvv has quit IRC
 91 2020-09-08T07:42:37  *** kljasdfvv has joined #bitcoin-core-dev
 92 2020-09-08T07:56:29  *** xxxx has joined #bitcoin-core-dev
 93 2020-09-08T07:58:53  *** xxxx has quit IRC
 94 2020-09-08T07:59:37  *** promag has joined #bitcoin-core-dev
 95 2020-09-08T08:00:37  *** dermoth_ has joined #bitcoin-core-dev
 96 2020-09-08T08:00:53  *** dermoth has quit IRC
 97 2020-09-08T08:00:55  *** dermoth_ is now known as dermoth
 98 2020-09-08T08:03:55  *** MasterdonX has quit IRC
 99 2020-09-08T08:04:51  *** promag has quit IRC
100 2020-09-08T08:05:50  *** MasterdonX has joined #bitcoin-core-dev
101 2020-09-08T08:21:46  *** jb55 has quit IRC
102 2020-09-08T08:22:14  *** jb55 has joined #bitcoin-core-dev
103 2020-09-08T08:28:49  *** vadorovsky__ has quit IRC
104 2020-09-08T08:29:12  *** vadorovsky__ has joined #bitcoin-core-dev
105 2020-09-08T08:30:56  *** bitcoin-git has joined #bitcoin-core-dev
106 2020-09-08T08:30:57  <bitcoin-git> [bitcoin] hebasto opened pull request #19915: refactor: Use Mutex type for some mutexes in CNode class (master...200908-netmx) https://github.com/bitcoin/bitcoin/pull/19915
107 2020-09-08T08:30:58  *** bitcoin-git has left #bitcoin-core-dev
108 2020-09-08T08:36:44  *** bitcoin-git has joined #bitcoin-core-dev
109 2020-09-08T08:36:44  <bitcoin-git> [bitcoin] Crypt-iQ opened pull request #19916: build: allow user to specify DIR_FUZZ_SEED_CORPUS when invoking cov_fuzz target (master...cov_fuzz_cleanup_0908) https://github.com/bitcoin/bitcoin/pull/19916
110 2020-09-08T08:36:45  *** bitcoin-git has left #bitcoin-core-dev
111 2020-09-08T08:42:08  *** theStack has joined #bitcoin-core-dev
112 2020-09-08T08:52:49  *** Dean_Guss has quit IRC
113 2020-09-08T08:53:01  *** promag has joined #bitcoin-core-dev
114 2020-09-08T08:53:10  *** Dean_Guss has joined #bitcoin-core-dev
115 2020-09-08T08:55:52  *** Dean_Guss has quit IRC
116 2020-09-08T08:56:09  *** andreacab has joined #bitcoin-core-dev
117 2020-09-08T08:56:14  *** Dean_Guss has joined #bitcoin-core-dev
118 2020-09-08T09:00:01  *** nihui has quit IRC
119 2020-09-08T09:00:04  *** jonatack has joined #bitcoin-core-dev
120 2020-09-08T09:02:17  *** bitcoin-git has joined #bitcoin-core-dev
121 2020-09-08T09:02:17  <bitcoin-git> [bitcoin] naumenkogs closed pull request #19697: Improvements on ADDR caching (master...2020-08-addr-cache-follow-up) https://github.com/bitcoin/bitcoin/pull/19697
122 2020-09-08T09:02:18  *** bitcoin-git has left #bitcoin-core-dev
123 2020-09-08T09:02:36  *** bitcoin-git has joined #bitcoin-core-dev
124 2020-09-08T09:02:36  <bitcoin-git> [bitcoin] naumenkogs reopened pull request #19697: Improvements on ADDR caching (master...2020-08-addr-cache-follow-up) https://github.com/bitcoin/bitcoin/pull/19697
125 2020-09-08T09:02:37  *** bitcoin-git has left #bitcoin-core-dev
126 2020-09-08T09:05:28  *** jonatack has quit IRC
127 2020-09-08T09:06:01  *** promag has quit IRC
128 2020-09-08T09:06:20  *** jonatack has joined #bitcoin-core-dev
129 2020-09-08T09:08:12  *** andreacab has quit IRC
130 2020-09-08T09:08:38  *** andreacab has joined #bitcoin-core-dev
131 2020-09-08T09:12:59  *** andreaca_ has joined #bitcoin-core-dev
132 2020-09-08T09:13:10  *** andreacab has quit IRC
133 2020-09-08T09:14:05  *** arowser has quit IRC
134 2020-09-08T09:14:26  *** arowser has joined #bitcoin-core-dev
135 2020-09-08T09:15:57  *** andreaca_ has quit IRC
136 2020-09-08T09:16:25  *** andreacab has joined #bitcoin-core-dev
137 2020-09-08T09:20:48  *** opsec_x12 has quit IRC
138 2020-09-08T09:21:02  *** andreacab has quit IRC
139 2020-09-08T09:21:13  *** opsec_x12 has joined #bitcoin-core-dev
140 2020-09-08T09:22:32  *** shesek has joined #bitcoin-core-dev
141 2020-09-08T09:22:38  *** dfkt has joined #bitcoin-core-dev
142 2020-09-08T09:27:29  *** andreacab has joined #bitcoin-core-dev
143 2020-09-08T09:30:11  <meshcollider> I propose for discussion that fanquake be made an admin on the repo so he can block people like Wladimir and Peter can (assuming he wants the ability)
144 2020-09-08T09:33:30  *** dfkt has quit IRC
145 2020-09-08T09:43:52  <wumpus> sgtm
146 2020-09-08T09:45:47  <provoostenator> No objection. I assume it's announced somewhere who is blocked?
147 2020-09-08T09:46:39  <provoostenator> (or I guess the blockee can complain via other channels, it's not like the Black Mirror episode)
148 2020-09-08T09:49:05  *** arowser has quit IRC
149 2020-09-08T09:49:24  *** arowser has joined #bitcoin-core-dev
150 2020-09-08T09:52:01  *** Guyver2_ has joined #bitcoin-core-dev
151 2020-09-08T09:52:49  *** Dean_Guss has quit IRC
152 2020-09-08T09:53:31  *** Dean_Guss has joined #bitcoin-core-dev
153 2020-09-08T09:55:12  *** Guyver2 has quit IRC
154 2020-09-08T10:01:08  *** sr_gi has joined #bitcoin-core-dev
155 2020-09-08T10:01:13  <wumpus> it's always mentioned here
156 2020-09-08T10:02:06  <wumpus> at least, that's what we should aim for
157 2020-09-08T10:09:16  *** promag has joined #bitcoin-core-dev
158 2020-09-08T10:09:19  <wumpus> apart from the really rare persistent troll it's only been used for obvious fake and scam and spam accounts, who never complain because they understand what they're doing
159 2020-09-08T10:09:36  *** sdad12121 has joined #bitcoin-core-dev
160 2020-09-08T10:12:10  *** promag has quit IRC
161 2020-09-08T10:23:46  *** andreacab has quit IRC
162 2020-09-08T10:24:13  *** andreacab has joined #bitcoin-core-dev
163 2020-09-08T10:25:17  *** yonatanbl has joined #bitcoin-core-dev
164 2020-09-08T10:28:42  *** andreacab has quit IRC
165 2020-09-08T10:29:55  <yonatanbl> Can anyone here review the Hebrew translation for Core on Transifex?
166 2020-09-08T10:30:45  *** auscompgeek1 has joined #bitcoin-core-dev
167 2020-09-08T10:31:19  *** andreacab has joined #bitcoin-core-dev
168 2020-09-08T10:36:07  <wumpus> hi, not sure anyone reads Hebrew here but you never know
169 2020-09-08T10:37:57  <elichai2> yonatanbl: sure, a link?
170 2020-09-08T10:40:16  <yonatanbl> https://www.transifex.com/bitcoin/bitcoin/language/he/
171 2020-09-08T10:42:10  <elichai2> oh I thought you meant something specific, I went over it a couple of times in the past, but it's pretty exhausting honestly
172 2020-09-08T10:43:27  <yonatanbl> I see
173 2020-09-08T10:46:59  *** Guyver2__ has joined #bitcoin-core-dev
174 2020-09-08T10:47:27  *** mdunnio has joined #bitcoin-core-dev
175 2020-09-08T10:48:14  *** andreacab has quit IRC
176 2020-09-08T10:48:32  *** andreacab has joined #bitcoin-core-dev
177 2020-09-08T10:50:01  *** Guyver2_ has quit IRC
178 2020-09-08T10:52:25  *** mdunnio has quit IRC
179 2020-09-08T10:56:37  *** jonatack has quit IRC
180 2020-09-08T10:57:31  *** jonatack has joined #bitcoin-core-dev
181 2020-09-08T10:59:03  *** vasild has quit IRC
182 2020-09-08T11:01:07  *** vasild has joined #bitcoin-core-dev
183 2020-09-08T11:03:14  <elichai2> did anyone see this error while trying to compile the fuzzers? `crypto/sha256_sse4.cpp:44:9: error: expected relocatable expression`
184 2020-09-08T11:06:32  *** andreacab has quit IRC
185 2020-09-08T11:06:55  <wumpus> never saw it before
186 2020-09-08T11:07:05  *** andreacab has joined #bitcoin-core-dev
187 2020-09-08T11:07:24  <wumpus> apparently it cannot make the inline assembly relocatable? is that a compiler or linker error?
188 2020-09-08T11:07:48  *** andreaca_ has joined #bitcoin-core-dev
189 2020-09-08T11:09:15  *** Guyver2__ is now known as Guyver2
190 2020-09-08T11:11:24  *** andreacab has quit IRC
191 2020-09-08T11:12:20  <elichai2> Looks like compiler, bigger output: https://pastebin.com/raw/fnV6J9MR. I'm trying to mix some flags to pinpoint what's doing that (currently it's fuzzer+debug+asan+libfuzzer+clang)
192 2020-09-08T11:12:25  *** jonatack has quit IRC
193 2020-09-08T11:15:40  *** yonatanbl has quit IRC
194 2020-09-08T11:17:18  <elichai2> Ok, that's weird, it only happens with asan+fuzzer, but not with any of them alone (`AS=clang CC=clang CXX=clang++ ./configure --enable-debug --with-incompatible-bdb --enable-fuzz --with-sanitizers=address`)
195 2020-09-08T11:17:35  <elichai2> Ops, * `AS=clang CC=clang CXX=clang++ ./configure --enable-debug --with-incompatible-bdb --enable-fuzz --with-sanitizers=fuzzer,address`
196 2020-09-08T11:18:49  *** andreaca_ has quit IRC
197 2020-09-08T11:19:19  *** andreacab has joined #bitcoin-core-dev
198 2020-09-08T11:22:34  *** andreaca_ has joined #bitcoin-core-dev
199 2020-09-08T11:23:22  *** andreacab has quit IRC
200 2020-09-08T11:25:15  <elichai2> so apparently it only happens with debug, I guess i'll live with longer compile times
201 2020-09-08T11:27:05  *** arowser has quit IRC
202 2020-09-08T11:27:35  *** arowser has joined #bitcoin-core-dev
203 2020-09-08T11:29:01  *** gleb has quit IRC
204 2020-09-08T11:29:13  <jonasschnelli> sipa, elichai2, real_or_random: what are your thoughts on the BIP342 comment here: https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52#gistcomment-3345400
205 2020-09-08T11:29:51  <jonasschnelli> Especially the point to retrieve further packets up to MAX_PACKET_LENGTH on an invalid MAC
206 2020-09-08T11:30:49  <jonasschnelli> ^ ariard
207 2020-09-08T11:36:28  *** gleb has joined #bitcoin-core-dev
208 2020-09-08T11:38:03  *** vadorovsky__ has quit IRC
209 2020-09-08T11:38:36  <real_or_random> jonasschnelli: oh I think I missed that one, I need to read up on this first
210 2020-09-08T11:38:57  <jonasschnelli> would be great! thanks
211 2020-09-08T11:39:07  <jonasschnelli> Unifying the error case for invalid MAC and MAX_PACKET_SIZE overflow makes much sense to me
212 2020-09-08T11:40:10  *** mrostecki has joined #bitcoin-core-dev
213 2020-09-08T11:42:09  *** andreaca_ has quit IRC
214 2020-09-08T11:42:36  *** andreacab has joined #bitcoin-core-dev
215 2020-09-08T11:46:45  *** andreacab has quit IRC
216 2020-09-08T11:48:43  *** worc3131 has joined #bitcoin-core-dev
217 2020-09-08T11:55:17  *** Highway61 has joined #bitcoin-core-dev
218 2020-09-08T11:56:03  <elichai2> jonasschnelli: hmm I think it would still be obvious that it is an invalid MAC error, but at least it hides the size. what happens if the sender doesn't try to send that many packets? the connection will halt until timeout?
219 2020-09-08T11:57:27  *** auscompgeek1 has quit IRC
220 2020-09-08T11:58:35  *** hadjiszs has quit IRC
221 2020-09-08T12:08:59  <fanquake> meshcollider: fine with me
222 2020-09-08T12:10:06  *** arowser has quit IRC
223 2020-09-08T12:10:27  *** arowser has joined #bitcoin-core-dev
224 2020-09-08T12:12:57  <jonasschnelli> elichai2: yes. It will lead to the timeout... (currently checking the code path)
225 2020-09-08T12:14:56  <jonasschnelli> elichai2: the pnode->nLastRecv is indifferent in V1/V2. So no traffic == timeout-disconnect (V1/V2)
226 2020-09-08T12:16:35  *** Highway61 has quit IRC
227 2020-09-08T12:17:07  *** Highway61 has joined #bitcoin-core-dev
228 2020-09-08T12:22:07  *** sammuel86 has joined #bitcoin-core-dev
229 2020-09-08T12:23:50  *** EagleTM has quit IRC
230 2020-09-08T12:31:54  *** reallll is now known as belcher
231 2020-09-08T12:46:27  *** TheRec has quit IRC
232 2020-09-08T12:50:40  *** Highway61 has quit IRC
233 2020-09-08T12:51:32  *** Highway61 has joined #bitcoin-core-dev
234 2020-09-08T12:55:43  *** palazzovincenzo has joined #bitcoin-core-dev
235 2020-09-08T12:55:45  *** vincenzopalazzo has quit IRC
236 2020-09-08T13:01:45  *** Tennis has joined #bitcoin-core-dev
237 2020-09-08T13:02:03  *** ghost43 has quit IRC
238 2020-09-08T13:04:05  *** arowser has quit IRC
239 2020-09-08T13:04:25  *** arowser has joined #bitcoin-core-dev
240 2020-09-08T13:05:05  *** arowser has quit IRC
241 2020-09-08T13:05:26  *** arowser has joined #bitcoin-core-dev
242 2020-09-08T13:06:05  *** arowser has quit IRC
243 2020-09-08T13:06:25  *** arowser has joined #bitcoin-core-dev
244 2020-09-08T13:07:06  *** arowser has quit IRC
245 2020-09-08T13:07:25  *** arowser has joined #bitcoin-core-dev
246 2020-09-08T13:08:06  *** arowser has quit IRC
247 2020-09-08T13:08:25  *** arowser has joined #bitcoin-core-dev
248 2020-09-08T13:09:06  *** arowser has quit IRC
249 2020-09-08T13:09:26  *** arowser has joined #bitcoin-core-dev
250 2020-09-08T13:10:05  *** arowser has quit IRC
251 2020-09-08T13:10:15  *** TheRec has joined #bitcoin-core-dev
252 2020-09-08T13:10:15  *** TheRec has joined #bitcoin-core-dev
253 2020-09-08T13:10:26  *** arowser has joined #bitcoin-core-dev
254 2020-09-08T13:11:01  *** jonatack has joined #bitcoin-core-dev
255 2020-09-08T13:12:05  *** arowser has quit IRC
256 2020-09-08T13:12:26  *** arowser has joined #bitcoin-core-dev
257 2020-09-08T13:13:05  *** arowser has quit IRC
258 2020-09-08T13:13:25  *** arowser has joined #bitcoin-core-dev
259 2020-09-08T13:14:05  *** arowser has quit IRC
260 2020-09-08T13:14:26  *** arowser has joined #bitcoin-core-dev
261 2020-09-08T13:16:38  *** ghost43 has joined #bitcoin-core-dev
262 2020-09-08T13:26:04  *** arowser has quit IRC
263 2020-09-08T13:26:25  *** arowser has joined #bitcoin-core-dev
264 2020-09-08T13:27:29  *** shesek has quit IRC
265 2020-09-08T13:30:05  *** arowser has quit IRC
266 2020-09-08T13:30:23  *** arowser has joined #bitcoin-core-dev
267 2020-09-08T13:43:05  *** arowser has quit IRC
268 2020-09-08T13:43:23  *** arowser has joined #bitcoin-core-dev
269 2020-09-08T13:45:39  *** mdunnio has joined #bitcoin-core-dev
270 2020-09-08T13:54:12  *** justanotheruser has joined #bitcoin-core-dev
271 2020-09-08T13:57:26  *** bitcoin-git has joined #bitcoin-core-dev
272 2020-09-08T13:57:26  <bitcoin-git> [bitcoin] promag opened pull request #19917: RemoveUnbroadcastTx requires mempool lock (master...2020-09-removeunbroadcasttx) https://github.com/bitcoin/bitcoin/pull/19917
273 2020-09-08T13:57:27  *** bitcoin-git has left #bitcoin-core-dev
274 2020-09-08T14:12:32  *** mrostecki has quit IRC
275 2020-09-08T14:12:54  *** mdunnio has quit IRC
276 2020-09-08T14:13:08  *** mdunnio has joined #bitcoin-core-dev
277 2020-09-08T14:15:27  *** sr_gi has quit IRC
278 2020-09-08T14:15:49  *** sr_gi has joined #bitcoin-core-dev
279 2020-09-08T14:34:10  *** harrigan has quit IRC
280 2020-09-08T14:34:22  *** harrigan has joined #bitcoin-core-dev
281 2020-09-08T14:42:06  *** arowser has quit IRC
282 2020-09-08T14:42:26  *** arowser has joined #bitcoin-core-dev
283 2020-09-08T14:43:04  *** arowser has quit IRC
284 2020-09-08T14:43:04  <jnewbery> #17785 may be close to ready for merge
285 2020-09-08T14:43:07  <gribble> https://github.com/bitcoin/bitcoin/issues/17785 | p2p: Unify Send and Receive protocol versions by hebasto · Pull Request #17785 · bitcoin/bitcoin · GitHub
286 2020-09-08T14:43:25  *** arowser has joined #bitcoin-core-dev
287 2020-09-08T14:44:20  <jnewbery> sipa: not sure if you want to take a quick look. It's somewhat adjacent (though not conflicting) with your work in #19503 and I think you mentioned something about wanting to tidy up how we handle p2p versions
288 2020-09-08T14:44:23  <gribble> https://github.com/bitcoin/bitcoin/issues/19503 | Add parameter feature to serialization and use it for CAddress by sipa · Pull Request #19503 · bitcoin/bitcoin · GitHub
289 2020-09-08T14:45:25  <jnewbery> reminder: p2p meeting in 15 minutes. One suggested topic so far "What would a good transaction propagation framework look like? See a first draw Transactions propagation design goals" #19820 (ariard)
290 2020-09-08T14:45:26  <gribble> https://github.com/bitcoin/bitcoin/issues/19820 | Transactions propagation design goals · Issue #19820 · bitcoin/bitcoin · GitHub
291 2020-09-08T14:46:01  <jnewbery> #19914 is also RFM
292 2020-09-08T14:46:03  <gribble> https://github.com/bitcoin/bitcoin/issues/19914 | refactor: Do not pass chain params to CheckForStaleTipAndEvictPeers twice by MarcoFalke · Pull Request #19914 · bitcoin/bitcoin · GitHub
293 2020-09-08T14:52:48  *** lightlike has joined #bitcoin-core-dev
294 2020-09-08T15:00:02  *** sammuel86 has quit IRC
295 2020-09-08T15:00:18  <jnewbery> #startmeeting
296 2020-09-08T15:00:18  <lightningbot> Meeting started Tue Sep  8 15:00:18 2020 UTC.  The chair is jnewbery. Information about MeetBot at http://wiki.debian.org/MeetBot.
297 2020-09-08T15:00:18  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
298 2020-09-08T15:00:29  <sdaftuar> hello
299 2020-09-08T15:00:31  <hebasto> hi
300 2020-09-08T15:00:34  <gleb> hi!
301 2020-09-08T15:00:35  <jnewbery> #bitcoin-core-dev P2P 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
302 2020-09-08T15:00:36  <ariard> hi
303 2020-09-08T15:00:42  <jnewbery> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
304 2020-09-08T15:00:48  <jnewbery> hi folks
305 2020-09-08T15:00:57  <ajonas> hi
306 2020-09-08T15:00:57  <sdaftuar> topic suggestion: gleb's PR on netgroup diversity of outbound peers
307 2020-09-08T15:01:22  <gleb> sure :)
308 2020-09-08T15:01:39  <jonasschnelli> hi
309 2020-09-08T15:01:44  <fanquake> hi
310 2020-09-08T15:02:04  <jnewbery> one proposed topic in https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings: Follow-up on last meeting's "What would a good transaction propagation framework look like? See a first draw Transactions propagation design goals #19820 (ariard)
311 2020-09-08T15:02:05  <gribble> https://github.com/bitcoin/bitcoin/issues/19820 | Transactions propagation design goals · Issue #19820 · bitcoin/bitcoin · GitHub
312 2020-09-08T15:02:10  <amiti> hi
313 2020-09-08T15:02:35  <ariard> we can start by gleb's one np
314 2020-09-08T15:02:51  <jnewbery> ok, before we get started with those topics, does anyone have any general updates on what they're working on, or what they're prioritizing? Raise your hand if you want to give an update o/
315 2020-09-08T15:03:01  <gleb> Over the last 10 days I opened 4 addr-related prs… I really think addr needs some attention, and my further work is blocked on this. I know addr is not the most well-known topic. I’m willing to provide any help to facilitate that review :)
316 2020-09-08T15:03:08  <sipa> hi
317 2020-09-08T15:03:35  <aj> oh, sdaftuar said something other than hi!
318 2020-09-08T15:03:40  <aj> holla
319 2020-09-08T15:03:41  <gleb> Some of them is refactoring, other have important implications and fix bugs
320 2020-09-08T15:03:43  <jonatack> hi
321 2020-09-08T15:03:51  <sdaftuar> aj: hi
322 2020-09-08T15:04:02  <aj> sdaftuar: nack
323 2020-09-08T15:04:30  <jnewbery> ok, well if no-one else has any general updates, I'll just share one of mine, then we can go onto proposed topics?
324 2020-09-08T15:04:39  <sdaftuar> jnewbery: ack
325 2020-09-08T15:04:54  <ariard> yes
326 2020-09-08T15:04:58  <jnewbery> I'd still encourage review of the remaining backport #19606
327 2020-09-08T15:05:01  <gribble> https://github.com/bitcoin/bitcoin/issues/19606 | Backport wtxid relay to v0.20 by jnewbery · Pull Request #19606 · bitcoin/bitcoin · GitHub
328 2020-09-08T15:05:34  <jnewbery> there was some confusion about Marco's comment a few weeks ago about merge order. Is MarcoFalke here?
329 2020-09-08T15:06:13  <jnewbery> Either way, I'd encourage review. It's not a totally clean backport, but it shouldn't be impossible to review
330 2020-09-08T15:06:19  <jonatack> quick reminder to review the bip155 and bip324 implementation PRs
331 2020-09-08T15:06:41  <jnewbery> #topic netgroup diversity of outbound peers (gleb)
332 2020-09-08T15:06:48  <gleb> #19860
333 2020-09-08T15:06:49  <gribble> https://github.com/bitcoin/bitcoin/issues/19860 | Improve diversification of new connections: privacy and stability by naumenkogs · Pull Request #19860 · bitcoin/bitcoin · GitHub
334 2020-09-08T15:07:17  <sdaftuar> i suggested that topic because some of the changes are non-obvious to me, and thought discussion would help
335 2020-09-08T15:07:46  <gleb> This PR has some obvious improvement: e.g. don't look at current feelers when make new persistent connection, because feelers are temporary so shold not affect I believe.
336 2020-09-08T15:07:53  <gleb> I guess there is one nuance that is not obvious.
337 2020-09-08T15:07:58  *** andreacab has joined #bitcoin-core-dev
338 2020-09-08T15:08:30  <gleb> I suggested to not look at the *existent* block-relay-only conns (2 conns we have) while making *new* full relay conns.
339 2020-09-08T15:08:55  <gleb> Because block-relay-conns should be more private (we rely on them for anti-eclipse).
340 2020-09-08T15:09:36  <gleb> And someone controlling our AddrMan (e.g. by occupying all our full relay slots) may deduce which netgroups are existent block-relay-o conns are taking.
341 2020-09-08T15:10:10  <gleb> The disadvantage of this change is that we will have a little less diversity as a whole
342 2020-09-08T15:10:24  <gleb> (new full-relay conns may be in same net group with existent block relay only conns)
343 2020-09-08T15:10:49  <sdaftuar> That last point is the one that I thought should be the primary consideration, as that seems like it has the greatest effect on our partition-resistance -- more diversity seems better
344 2020-09-08T15:10:51  <gleb> So I guess it's questionable whether this privacy benefit worth sacrificing a bit of diversity. And whether this kind of privacy threat is real, in general.
345 2020-09-08T15:10:58  <amiti> if someone has taken over our addrman & we're trying to open block-relay-only conns, isn't the bigger concern that we would just be opening connections to the poisoned addresses?
346 2020-09-08T15:11:39  <gleb> amiti: I assume that at that time we still have 2 healthy block-relay-only conns, and I want to expose them as little as possible.
347 2020-09-08T15:12:16  <ariard> sdaftuar: does the design goal of block-relay-only connections was to mask better block-relay topology, thus masking netgroups of such peers should be in agreement?
348 2020-09-08T15:12:57  <gleb> sdaftuar: I was fine with sacrificing diversity here, because it has so little effect. The only difference will be that *just two* existing block-relay-only conns may overlap with new full relay conns.
349 2020-09-08T15:13:11  <amiti> whats the worst attack that could be carried out if an adversary knows the netgroups of the conns?
350 2020-09-08T15:13:15  <gleb> And if we have more than two in the future, we can make 2 of them private, and N-2 of them overlappable.
351 2020-09-08T15:13:28  <jnewbery> gleb: is it fair to say the effect is that we'll have the same level of diversity as we did prior to block-relay-only peers being introduced?
352 2020-09-08T15:13:46  <gleb> amiti: they can further deduce what are those peers in the network, and evict us from them.
353 2020-09-08T15:13:56  <amiti> gleb: how?
354 2020-09-08T15:14:06  <ariard> amiti: I think about looking among available public peers in this netgroup and open connection to them to try to evict inbound slot of your victim
355 2020-09-08T15:14:07  <gleb> jnewbery: Yes, I think it's fair. sdaftuar?
356 2020-09-08T15:14:17  <sdaftuar> gleb: we do have keyed network groups, so i am curious what you have in mind there?
357 2020-09-08T15:14:51  <sdaftuar> jnewbery: yes, i think that's likely true
358 2020-09-08T15:14:59  <amiti> ariard: thanks!
359 2020-09-08T15:15:02  <sdaftuar> ariard: the goal of the connections is twofold:
360 2020-09-08T15:15:30  <sdaftuar> - the main goal is to increase the difficulty/cost/power of an adversary required to carry out a network partitioning attack against a target node
361 2020-09-08T15:16:09  <sdaftuar> and the specific motivation was that our existing full-relay connections leak topology information, and fixing that is sort of hopeless in the long run, though we certainly can and should make improvements where possible
362 2020-09-08T15:16:27  <jnewbery> the questions I'd ask are: was diversity a problem to block-relay-only peers being introduced? Did block-relay-only peers make it measurably better? I guess there aren't answers to those except "more is generally better"
363 2020-09-08T15:16:51  <sdaftuar> - the second goal is a bit more nebulous, but my thinking is that it's easier to get the anti-DoS tradeoffs right if we focus on the different aspects of network traffic separately
364 2020-09-08T15:17:06  <sdaftuar> so for instance i think the design goals around transaction relay may leads us to different peering strategies than the design goals around block relay
365 2020-09-08T15:17:46  <gleb> jnewbery: In my opinion, block-relay-only connections wasn't intended to improve diversity at all. I'd say it was a side-effect benefit we got for free.
366 2020-09-08T15:18:27  <sdaftuar> gleb: i think i agree, but that benefit seems so substantial that i think taking it away for the sake of privacy is hard for me to imagine, without a concrete understanding of where the privacy would be lost
367 2020-09-08T15:18:40  <gleb> sdaftuar: an attacker just forces us to connect to a peer from some netgroup, sees that we refuses, and deduces that our block-relay-only is in that group.
368 2020-09-08T15:18:42  <sipa> sdaftuar: i think you're missing one point: block-only connections increase partition resistance without the bandwidth overhead that full connections have
369 2020-09-08T15:18:51  <sdaftuar> sipa: yes, thank you
370 2020-09-08T15:18:57  <ariard> wrt to increase the difficulty/cost/power, I think you can achieve this by either more diversity and/or more non-observability of your peerings, what gleb's PR is underscoring IMO is a potential trade-off between them
371 2020-09-08T15:19:20  <sipa> gleb: how can they force us to connect somewhere?
372 2020-09-08T15:20:01  <gleb> sipa: have all our full relay slots, feed only selected addr records of their sybils, drop connections and see us connect to one of their sybils
373 2020-09-08T15:20:25  <jnewbery> gleb: 'just forces us to connect to a peer from some netgroup' sounds very difficult. If an attacker can already do that, I think we're in a lot of trouble already
374 2020-09-08T15:20:41  <sipa> gleb: that sounds like they've already succesfully pattitioned us?
375 2020-09-08T15:20:52  <gleb> I assume a scenario when we lost all our full relay slots, but still have 2 block-relay-only slots.
376 2020-09-08T15:20:57  <sipa> or are trivially able to do so as well
377 2020-09-08T15:21:05  <ariard> do we assume that our full-relay can be discovered through transaction relay in that way you can learn their netgroups and exclude block-relay-o to be there
378 2020-09-08T15:21:10  <gleb> b-r-o slots don't answer addr queries i believe, so they won't help to sanitize our addr man
379 2020-09-08T15:21:28  <sdaftuar> correct, or rather we ignore addr messages from our block-relay peers
380 2020-09-08T15:21:28  *** afb has joined #bitcoin-core-dev
381 2020-09-08T15:21:36  <aj> sipa: if we had (say) 10 blocks-only connectoins and 6 tx-relay connections, it might make sense to have separate netgroups for each blocks-only peer and separate netgroups for each tx-relay peer, but not worry about overlap between the two?
382 2020-09-08T15:21:56  <ariard> if you can learn the full-relay peers of your victim, you can try to influence peering of those full-relay by exploiting their inbound eviction logic
383 2020-09-08T15:21:59  <sdaftuar> aj: isn't more diversity still better?
384 2020-09-08T15:22:19  <jonatack> sdaftuar: separate design goals make sense to me as well given the very different characteristics of tx relay and block relay. for instance, from what i see, last tx is frequent, many/most peers, and often in seconds. last block is rare, comes from only a few peers, over minutes and hours.
385 2020-09-08T15:22:53  <sipa> my thinking (but i haven't thought/looked too much) is that you want to maximize diversity of (full+blockonly), and of (full) alone
386 2020-09-08T15:23:08  <sdaftuar> sipa: that lines up with my intuition as well
387 2020-09-08T15:23:16  <ariard> aj: I agree with these logic, but as of today full-relay we have an overlap between connections types, that's more how we address this while moving in this direction
388 2020-09-08T15:23:20  <ariard> *this
389 2020-09-08T15:23:41  <sipa> the former for partition resistance, the second for actual short-term efficient connectivity
390 2020-09-08T15:24:07  <gleb> I just thought that the impact of dropping block-relay-only from the full relay diversity set would be fine. It's just 2 peers. And they still be diverse among themselves.
391 2020-09-08T15:24:23  <aj> sdaftuar: i guess my gut feel is that once you have sufficient diversity, then having them be independent gets you more robustness as well since one network can't interfere with the other?
392 2020-09-08T15:24:36  <gleb> And block-relay-only will be diverse w.r.t existent full-relay conns. Just not vice versa :)
393 2020-09-08T15:24:43  <aj> sdaftuar: (2 peers not being sufficiently diverse, 6-10 maybe being sufficiently diverse)
394 2020-09-08T15:24:54  <jnewbery> aj: that seems like a good end-goal. Totally separating logic for the connection types allows us to reason about each individually and prevents potentially privacy/exploitability by not allowing information to leak between the two.
395 2020-09-08T15:25:01  <sdaftuar> gleb: that part of the logic is strange to me, because the peering logic is not symmetric depending on what order you connect in?
396 2020-09-08T15:25:39  <sipa> jnewbery: hmm, i see the appeal for that too
397 2020-09-08T15:25:41  <gleb> sdaftuar: I don't see symmetry as a good goal :)
398 2020-09-08T15:26:37  <sdaftuar> aj: yeah so i guess there are two goals, one is how we minimize the likelihood of being partitioned, but then maybe once we're close enough on that point, we can choose other tradeoffs e.g. for robustness/design clarity as jnewbery suggested
399 2020-09-08T15:26:39  <gleb> Maybe we should keep this until more block-relay-only, and then make part of them private and part of them diverse?
400 2020-09-08T15:27:18  <amiti> I'm still trying to wrap my head around the attack vectors in the scenario (full-relay taken over, block-relay safe). I think ofc diversity is good, but the small decrease might be worthwhile if its offering protection. but I need to understand exactly what its protecting against in order to evaluate that tradeoff.
401 2020-09-08T15:27:24  <sdaftuar> it does seem like we're a long way from truly separating connection types, as long as addrman is firmly in the middle here
402 2020-09-08T15:27:25  <sipa> sdaftuar: looking at full only when making a new full connection, and looking at both when making a blocksonly connection... isn't that how you'd implememt maximization of diversity for (blocksonly+full) and for (full) alone?
403 2020-09-08T15:27:55  <ariard> sdaftuar: non-observability of victim's connections likely minimizes the likelihood of being partitioned
404 2020-09-08T15:28:14  <gleb> sipa: this is my exact suggestion btw.
405 2020-09-08T15:28:19  <sipa> amiti: i'm not there is a concrete attack beyond "8 connections is easier to partition than 10"
406 2020-09-08T15:28:25  <sdaftuar> sipa: i was going to point out that achieving maximum diversity for blocksonly+full is sufficient to achieve maximum diversity for full alone
407 2020-09-08T15:28:53  <sipa> sdaftuar: hmm!
408 2020-09-08T15:29:04  <sipa> of course
409 2020-09-08T15:30:04  <jnewbery> it seems like it's ok for information about full connections to leak into our blocksonly connection logic, since blocksonly are meant to be private?
410 2020-09-08T15:30:34  <sdaftuar> i think this comes down to whether we think this attack -- can we observe keyed-netgroup collisions from observed outbound connections -- is practical for some kind of attacker we're concerned about?
411 2020-09-08T15:30:45  <gleb> jnewbery: yeah, I think so. Because there are probably better ways to learn full conns anyway
412 2020-09-08T15:31:14  <gleb> sdaftuar: do you accept the setting where we lost all our full conns, but 2 block-relay-only are still healthy?
413 2020-09-08T15:31:25  <gleb> or you think it's unrealistic
414 2020-09-08T15:31:40  <sdaftuar> if our addrman starts off healthy, then i think we're probably ok in that scenario
415 2020-09-08T15:32:00  <sdaftuar> if our addrman is already poisoned but for the two block-relay only connections, i think that's a very edge-case scenario to try to optimize for
416 2020-09-08T15:32:17  <sdaftuar> (i think we're ok because of feelers, maybe that's wrong)
417 2020-09-08T15:32:55  <gleb> i see.
418 2020-09-08T15:32:57  <sipa> i have a hard time imagining how that's not a problem
419 2020-09-08T15:33:10  <ariard> gleb: when you assume addrman poisoning, do you scope knocking-out the feeler logic by an attacker?
420 2020-09-08T15:33:26  <jnewbery> does anchor connections make gleb's scenario more likely?
421 2020-09-08T15:33:41  <sdaftuar> sipa: i guess one thing that goes wrong is that eventually nodes go offline, and so in the long run you lose all your honest peers?
422 2020-09-08T15:33:43  <sipa> because with all normal connections sybilled, the attacker can probably start poisoning addrman, and leave you no way to recover
423 2020-09-08T15:33:54  <amiti> jnewbery: was wondering that. I think so
424 2020-09-08T15:33:57  <ariard> jnewbery: I think it makes it easier to observe them as block-relay-o become more stable?
425 2020-09-08T15:34:00  <jnewbery> (#17428)
426 2020-09-08T15:34:04  <gribble> https://github.com/bitcoin/bitcoin/issues/17428 | p2p: Try to preserve outbound block-relay-only connections during restart by hebasto · Pull Request #17428 · bitcoin/bitcoin · GitHub
427 2020-09-08T15:34:29  <sdaftuar> sipa: does this problem get solved if we introduce some level of rotation of tx-relay peers?
428 2020-09-08T15:34:40  <gleb> Yeah I don't have big faith in feelers once we lost all our full conns
429 2020-09-08T15:34:54  <gleb> We don't even send GETADDR to feelers iirc?
430 2020-09-08T15:35:00  <sdaftuar> sorry, i don't mean feelers
431 2020-09-08T15:35:07  <sdaftuar> what i mean is the tried-table-collision resolution algorithm
432 2020-09-08T15:35:17  <sipa> that's feelers, no?
433 2020-09-08T15:35:26  <gleb> oh, that's interesting.
434 2020-09-08T15:35:28  <ariard> that's done by feelers connection
435 2020-09-08T15:35:29  <sdaftuar> no, feelers are for connecting to NEW table entries and trying to mive them to tried
436 2020-09-08T15:35:32  <gleb> Not sure how that thing is effective.
437 2020-09-08T15:35:34  <sdaftuar> yes, we call them feelers too
438 2020-09-08T15:35:36  <sdaftuar> but it's confusing
439 2020-09-08T15:35:50  <sipa> mive?
440 2020-09-08T15:35:54  <sdaftuar> move*
441 2020-09-08T15:35:56  <jnewbery> I do like the concept of not allowing any information at all to leak from our blocksonly connections into our other connection logic. Even if this particular scenario is unlikely, it's still nice to be able to count out any such similar attacks.
442 2020-09-08T15:35:56  <sipa> ah, move
443 2020-09-08T15:36:44  <sipa> thinking ahout this, i wonder if we need addr-only connections too
444 2020-09-08T15:36:56  <gleb> The worst diversity degradation here btw: 2 newly selected full peers are from the same netgroup as 2 existent block-relay-only conns
445 2020-09-08T15:37:03  <gleb> sipa: working on that stuff.
446 2020-09-08T15:37:05  <sdaftuar> sipa: yeah i was thinking about that a bit as well
447 2020-09-08T15:37:15  <gleb> it's blocked by my 4 addr-related prs :)
448 2020-09-08T15:37:23  <sipa> i'm not worried about information leakage of our selection of full/blockonly connections
449 2020-09-08T15:37:49  <sipa> but our partitition resistance gained (assuming blockonly is diverse wrt full) is only for block connectivity
450 2020-09-08T15:37:53  <sipa> not for addrmam health
451 2020-09-08T15:38:04  <sipa> which is valuable, but shorter term
452 2020-09-08T15:38:15  <aj> sipa: maybe addr-only connections should mean occassionally requery dns-seeds too (once a day or once a week, poisson'ed eg) ?
453 2020-09-08T15:38:31  <sipa> maybe
454 2020-09-08T15:38:37  <ariard> sipa: you mean an attacker can't interfere with victim's blockonly connections if it learns their netgroups?
455 2020-09-08T15:38:49  <sdaftuar> aj: that leaks different information that people are concerend about i think?
456 2020-09-08T15:38:56  <gleb> aj: this is a follow-up for #18421
457 2020-09-08T15:38:59  <gribble> https://github.com/bitcoin/bitcoin/issues/18421 | Periodically update DNS caches for better privacy of non-reachable nodes by naumenkogs · Pull Request #18421 · bitcoin/bitcoin · GitHub
458 2020-09-08T15:39:07  <gleb> I gave up on periodic DNS queries for now :)
459 2020-09-08T15:39:30  <sipa> ariard: i think that if all connections that convey addr informarion are sybilled, it's game over for addrman sanity
460 2020-09-08T15:39:41  <sipa> ariard: and blocksonly connections cannot help with that
461 2020-09-08T15:39:55  <gleb> sipa: but we're not eclipsed at least?
462 2020-09-08T15:40:04  <sdaftuar> sipa: one alternate implementation idea i had for syncing our chain tip with more peers, was to couple that with addrman updates
463 2020-09-08T15:40:13  <sipa> gleb: not eclipsed wrt to block propagation
464 2020-09-08T15:40:42  <gleb> sipa: sure.
465 2020-09-08T15:40:43  <ariard> sipa: you might still be okay for a while more until your current block-relay-only are stable, and this is already a gain
466 2020-09-08T15:40:47  <sipa> gleb: but you are eclipsed wrt addr relay, which means addrman will (if the situation persists) become attacker controlled
467 2020-09-08T15:40:48  <sdaftuar> sipa: so that we bump a peer's status (maybe just updating its times in the tried table) only if their tip was synced to something with as much work as ours, or something like that
468 2020-09-08T15:42:02  *** proofofkeags has quit IRC
469 2020-09-08T15:42:13  <sipa> so i think this means we want full connections, blockonly connections, addronly connections... and diversity of (full+blockonly) and of (full+addronly) ?
470 2020-09-08T15:42:13  <sdaftuar> i think it would be helpful to run some simulations on that point
471 2020-09-08T15:42:44  <sipa> or just diversity of everything, really
472 2020-09-08T15:42:49  <ariard> sdaftuar: if you take this info for future peers selections, you might favor even more performant peers, and tight network topology ?
473 2020-09-08T15:43:27  <sipa> ariard: being more or less in sync isn't a very strong preference for.performamt peers
474 2020-09-08T15:43:40  <sipa> just an aversion for broken ones
475 2020-09-08T15:44:03  <sdaftuar> right, we could put in a tolerance of being a block or two behind, that's very different from having no knowledge of their chain
476 2020-09-08T15:44:13  <ariard> sipa: aren't low-grades peers really likely to be late on tip view ?
477 2020-09-08T15:44:15  *** bitcoin-git has joined #bitcoin-core-dev
478 2020-09-08T15:44:15  <bitcoin-git> [bitcoin] ryanofsky opened pull request #19918: sync: Replace LockAssertion with WeaklyAssertLockHeld (master...pr/lockb) https://github.com/bitcoin/bitcoin/pull/19918
479 2020-09-08T15:44:16  *** bitcoin-git has left #bitcoin-core-dev
480 2020-09-08T15:44:41  <sipa> ariard: by a few seconds maybe
481 2020-09-08T15:45:32  <sdaftuar> sipa: it seems a shame to not relay blocks on addronly links
482 2020-09-08T15:45:37  <sdaftuar> (or at least headers)
483 2020-09-08T15:45:47  <gleb> sdaftuar: agree.
484 2020-09-08T15:45:58  <jnewbery> gleb: one of your concerns was about an attackers knowing about which netgroups you're connected to. Would it make sense for each node to have their own way of dividing the address space into netgroups (eg by clustering ASs differently)
485 2020-09-08T15:46:12  <sdaftuar> jnewbery: we do that already, don't we?
486 2020-09-08T15:46:19  <sipa> jnewbery: we do!
487 2020-09-08T15:46:25  <jnewbery> oh! Good!
488 2020-09-08T15:46:28  <sipa> there is an addrman key for that
489 2020-09-08T15:46:33  <ariard> should we have a hierarchy of types of traffic, i.e it's okay to relay public informations like block on more private ones (tx/addr) but not the reverse ?
490 2020-09-08T15:46:33  <sdaftuar> that's what i said before about keyed network groups
491 2020-09-08T15:46:35  <jnewbery> I should have reviewed the AS PRs
492 2020-09-08T15:46:48  <jnewbery> sdaftuar: got it. Thanks!
493 2020-09-08T15:46:58  <sipa> jnewbery: this was part of the original addrman :)
494 2020-09-08T15:47:06  <gleb> Yeah, this part makes it a bit less realistic.
495 2020-09-08T15:47:17  <jonatack> question: how effective is -seednode/-addnode to trusted peers as an anti-eclipse tactic?
496 2020-09-08T15:47:35  <jnewbery> sipa: ah, ok. I guess I should just review more of the code in general then :)
497 2020-09-08T15:47:43  <sipa> jonatack: assuming no network-level attacker, addnode is great for that
498 2020-09-08T15:47:57  <sdaftuar> well, hopefully your trusted peer is also not eclipsed :)
499 2020-09-08T15:48:20  <ariard> jonatack: really depends of the capabilites of your eclipse attacker
500 2020-09-08T15:48:43  <sipa> i see no reason why you wouldn't also send blocks over addr links, agree
501 2020-09-08T15:48:58  <sdaftuar> sipa: so perhaps we should have two kinds of block-relay links then
502 2020-09-08T15:48:59  <jonatack> thanks. i seem to recall matt tweeting about doing that a while back
503 2020-09-08T15:49:21  <gleb> sdaftuar: I'm lost. Which kinds?
504 2020-09-08T15:49:28  *** andreacab has quit IRC
505 2020-09-08T15:49:51  <sipa> gleb: blocksonly and addrplusblocksonly
506 2020-09-08T15:49:55  *** andreacab has joined #bitcoin-core-dev
507 2020-09-08T15:50:01  <aj> is the idea that addr-relay nodes are long-lived or short-lived (like feelers) ?
508 2020-09-08T15:50:21  <sipa> long-lived, i'd say
509 2020-09-08T15:50:25  <sdaftuar> aj: i think they could be long lived?  they would be very low bandwidth
510 2020-09-08T15:50:25  <gleb> I have a branch with short-lived self-announcement addr links :)
511 2020-09-08T15:50:35  <ariard> even if they're short-lived you want to do headers-sync on them
512 2020-09-08T15:50:40  <gleb> But that's different from what was discussed.
513 2020-09-08T15:51:22  <lightlike> hi - we probably can't rely much on our addr-links staying private, or can we?
514 2020-09-08T15:51:28  <aj> so blocks-only is eclipse prevention, addr+blocks is low-bw extra diversity, tx-relay is tx relay?
515 2020-09-08T15:51:39  <sdaftuar> i'm actually not sure if it's better to use a connection slot on a long-lived addr+block-relay peer, than it is to just rotate our full-relay peers some and get addrman updates from the getaddr message we send
516 2020-09-08T15:51:43  <jnewbery> We have 10 minutes left and one other topic (What would a good transaction propagation framework look like? See a first draw Transactions propagation design goals)
517 2020-09-08T15:51:56  <jnewbery> ariard: are you happy to punt that to the next meeting?
518 2020-09-08T15:52:01  <ariard> aj: being eclipsed at the tx-relay level is really bad for offchain stuff
519 2020-09-08T15:52:12  <ariard> jnewbery: I feel we need it better to end on this topics
520 2020-09-08T15:52:26  *** andreacab has quit IRC
521 2020-09-08T15:52:27  <aj> ariard: not as bad as being eclipsed from the most-work chain though
522 2020-09-08T15:52:32  *** andreacab has joined #bitcoin-core-dev
523 2020-09-08T15:52:38  <sdaftuar> lightlike: agreed, addr relay likely leaks topology
524 2020-09-08T15:52:56  <aj> sipa: (what's the blocker for getting tx relay overhaul rebased/out-of-draft?)
525 2020-09-08T15:53:15  <gleb> sdaftuar: have you checked out caches yet? It's getting better!
526 2020-09-08T15:53:26  <sipa> ariard: parse error
527 2020-09-08T15:53:28  <jnewbery> ariard: does that mean punt to next meeting?
528 2020-09-08T15:53:37  <ariard> aj: in fact I think that's a bit more subtle, you can close your channels without knowing what the state chain is ?
529 2020-09-08T15:53:41  <sdaftuar> gleb: no idea what you're referring to...
530 2020-09-08T15:53:44  <ariard> jnewbery: yes next meeting :)
531 2020-09-08T15:54:02  <gleb> sdaftuar: #18991
532 2020-09-08T15:54:06  <gribble> https://github.com/bitcoin/bitcoin/issues/18991 | Cache responses to GETADDR to prevent topology leaks by naumenkogs · Pull Request #18991 · bitcoin/bitcoin · GitHub
533 2020-09-08T15:54:08  <sdaftuar> gleb: oh, addr-relay privacy leaks
534 2020-09-08T15:54:10  <jnewbery> great. Thanks. That'll also give people a bit more time to read your doc here: https://github.com/bitcoin/bitcoin/issues/19820
535 2020-09-08T15:54:11  <ariard> sipa: if a LN node can't broadcast its punishment transaction that's worthless to see a revoked commitment transaction on the most-valid PoW chain
536 2020-09-08T15:55:09  <sipa> ariard: you know my thinking on that
537 2020-09-08T15:55:24  <aj> ariard: if you see the revoked commitment tx, you can aggressively try connecting to many peers to find one that relays honestly; if you don't see the commitment tx at all, your opportunity to do a punishment can time out
538 2020-09-08T15:55:42  <sipa> aj: i have a branch where it's half done, but i got preempted by bip340/taproot stuff
539 2020-09-08T15:56:07  <ariard> sipa: I know, I know that's the reason to talk about #19820 next time :)
540 2020-09-08T15:56:07  <gribble> https://github.com/bitcoin/bitcoin/issues/19820 | Transactions propagation design goals · Issue #19820 · bitcoin/bitcoin · GitHub
541 2020-09-08T15:57:39  <gleb> Alright, so I think i'll turn that PR into a harmless refactoring (don't diversify by current feeler or oneshot/addr_fetch), and keep the non-diverse/more-private idea for future.
542 2020-09-08T15:57:57  <sdaftuar> gleb: that sounds good to me.  thanks for the discussion!
543 2020-09-08T15:58:01  <sipa> gleb: sounds good
544 2020-09-08T15:58:12  <jnewbery> Thanks gleb!
545 2020-09-08T15:58:13  <ariard> aj: you can probalistically close your channel, if you don't see block for a hour, that's likely something is wrong (but more an open question how offchain stuff  should react in case of block eclipse)
546 2020-09-08T15:58:43  <jnewbery> Any final topics before we end? Remember it's feature freeze in 5 weeks (https://github.com/bitcoin/bitcoin/issues/18947) so it's a great time to shill your PRs!
547 2020-09-08T15:59:10  <sdaftuar> if we're shilling, i'd love review on #19858
548 2020-09-08T15:59:13  <gribble> https://github.com/bitcoin/bitcoin/issues/19858 | Periodically make block-relay connections and sync headers by sdaftuar · Pull Request #19858 · bitcoin/bitcoin · GitHub
549 2020-09-08T15:59:24  <ariard> sdaftuar: updated #19871 in the hope to clarify outbound eviction
550 2020-09-08T15:59:25  <gribble> https://github.com/bitcoin/bitcoin/issues/19871 | doc: Clarify scope of eviction protection of outbound block-relay peers by ariard · Pull Request #19871 · bitcoin/bitcoin · GitHub
551 2020-09-08T15:59:37  <sdaftuar> ariard: thanks, i'll take a look
552 2020-09-08T15:59:39  <hebasto> o/
553 2020-09-08T15:59:41  <sipa> i have been succesfully shilled
554 2020-09-08T15:59:43  <jnewbery> any advances on one shilling?
555 2020-09-08T15:59:46  <jnewbery> going once
556 2020-09-08T15:59:46  <hebasto> #17785
557 2020-09-08T15:59:48  <jonatack> It would be great to have #19643 in master and it seems RFM
558 2020-09-08T15:59:48  <gribble> https://github.com/bitcoin/bitcoin/issues/17785 | p2p: Unify Send and Receive protocol versions by hebasto · Pull Request #17785 · bitcoin/bitcoin · GitHub
559 2020-09-08T15:59:49  <jnewbery> going twice
560 2020-09-08T15:59:51  <gribble> https://github.com/bitcoin/bitcoin/issues/19643 | Add -netinfo peer connections dashboard by jonatack · Pull Request #19643 · bitcoin/bitcoin · GitHub
561 2020-09-08T15:59:54  <gleb> super-easy little refactoring which will unlock my future work #19843
562 2020-09-08T15:59:55  <gribble> https://github.com/bitcoin/bitcoin/issues/19843 | Refactoring and minor improvement for self-advertisements by naumenkogs · Pull Request #19843 · bitcoin/bitcoin · GitHub
563 2020-09-08T15:59:59  <jnewbery> #endmeeting
564 2020-09-08T15:59:59  <lightningbot> Meeting ended Tue Sep  8 15:59:59 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
565 2020-09-08T15:59:59  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-08-15.00.html
566 2020-09-08T15:59:59  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-08-15.00.txt
567 2020-09-08T15:59:59  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-08-15.00.log.html
568 2020-09-08T16:00:16  <sdaftuar> two shillings
569 2020-09-08T16:00:31  <jnewbery> sold!
570 2020-09-08T16:00:47  <sdaftuar> i forgot what i was bidding on
571 2020-09-08T16:05:26  <instagibbs> leading the next core pr review
572 2020-09-08T16:06:12  <sdaftuar> sweet, instagibbs i pick you
573 2020-09-08T16:07:27  <aj> "tangy and quite full-bodied, with a lasting, mostly pleasant, aftertaste"
574 2020-09-08T16:07:34  * aj reviews instagibbs now to get it out of the way
575 2020-09-08T16:09:02  <sipa> aj: is that how we'll describe connection types in getpeerinfo ?
576 2020-09-08T16:09:26  <sdaftuar> block-relay peers: mostly pleasant?
577 2020-09-08T16:10:03  <aj> sipa: full-bodied: relays tx; tangy: relays addresses; lasting aftertase: longlived; mostly pleasant: low but nonzero discouragement score?
578 2020-09-08T16:10:59  <sipa> something like that
579 2020-09-08T16:11:25  <aj> bool IsTangy(conn_type ct);
580 2020-09-08T16:11:28  *** alko89 has quit IRC
581 2020-09-08T16:11:38  *** alko89 has joined #bitcoin-core-dev
582 2020-09-08T16:12:18  *** lightlike has quit IRC
583 2020-09-08T16:13:01  <luke-jr> aj: aftertaste implies you stopped using it..?
584 2020-09-08T16:13:15  <sdaftuar> addr-relay peers really have the best aftertaste imo
585 2020-09-08T16:13:35  <aj> luke-jr: pause inbetween uses works to i think?
586 2020-09-08T16:13:49  <luke-jr> not enough to tell that the aftertaste is lasting
587 2020-09-08T16:14:36  <aj> luke-jr: unrelated, any thoughts on https://github.com/bitcoin/bitcoin/pull/19401#pullrequestreview-482271390
588 2020-09-08T16:15:19  <aj> (or anyone else, re: gbt for test chains)
589 2020-09-08T16:15:35  <luke-jr> aj: I think it's better to avoid special casing test code in the main codebase
590 2020-09-08T16:17:21  <luke-jr> (not sure if we do, but we *should* have a test that one node by itself can't mine)
591 2020-09-08T16:19:13  <aj> luke-jr: regtest nodes can trivially mine on their own via generate
592 2020-09-08T16:19:33  <luke-jr> ok?
593 2020-09-08T16:19:36  <aj> luke-jr: not being able to mine without being connected matters for mainnet, sure; but not for anything else
594 2020-09-08T16:19:47  <luke-jr> mainnet is all that matters in the end
595 2020-09-08T16:21:39  *** EagleTM has joined #bitcoin-core-dev
596 2020-09-08T16:23:24  *** Talkless has joined #bitcoin-core-dev
597 2020-09-08T16:45:07  *** proofofkeags has joined #bitcoin-core-dev
598 2020-09-08T16:45:49  *** cato_ has quit IRC
599 2020-09-08T16:46:55  *** bitcoin-git has joined #bitcoin-core-dev
600 2020-09-08T16:46:55  <bitcoin-git> [bitcoin] AkioNak opened pull request #19919: bugfix: make LoadWallet assigns status always (master...set_databasestatus) https://github.com/bitcoin/bitcoin/pull/19919
601 2020-09-08T16:46:56  *** bitcoin-git has left #bitcoin-core-dev
602 2020-09-08T16:51:08  *** cato_ has joined #bitcoin-core-dev
603 2020-09-08T16:51:38  *** EagleTM has quit IRC
604 2020-09-08T17:05:29  <darosior> jnewbery: you were right regarding #18766: it's much nicer by keeping the feeEstimator as a separate component :)
605 2020-09-08T17:05:31  <gribble> https://github.com/bitcoin/bitcoin/issues/18766 | Disable fee estimation in blocksonly mode (by removing the fee estimates global) by darosior · Pull Request #18766 · bitcoin/bitcoin · GitHub
606 2020-09-08T17:15:02  *** IGHOR has quit IRC
607 2020-09-08T17:17:31  *** IGHOR has joined #bitcoin-core-dev
608 2020-09-08T17:24:02  <jnewbery> darosior: cool. Thanks for being open to trying it both ways. Hopefully I'll have time to review the new version this week.
609 2020-09-08T17:26:01  *** andreacab has quit IRC
610 2020-09-08T17:26:36  *** andreacab has joined #bitcoin-core-dev
611 2020-09-08T17:30:47  *** andreacab has quit IRC
612 2020-09-08T17:33:46  *** Highway62 has joined #bitcoin-core-dev
613 2020-09-08T17:35:33  *** Highway61 has quit IRC
614 2020-09-08T17:35:33  *** Highway62 is now known as Highway61
615 2020-09-08T17:45:53  *** theStack has quit IRC
616 2020-09-08T17:48:13  *** opsec_x12 has quit IRC
617 2020-09-08T17:54:51  *** andreacab has joined #bitcoin-core-dev
618 2020-09-08T18:00:01  *** afb has quit IRC
619 2020-09-08T18:14:31  *** filchef has joined #bitcoin-core-dev
620 2020-09-08T18:25:24  *** sr_gi has quit IRC
621 2020-09-08T18:26:01  *** sr_gi has joined #bitcoin-core-dev
622 2020-09-08T18:36:51  *** andreacab has quit IRC
623 2020-09-08T18:38:38  *** andreacab has joined #bitcoin-core-dev
624 2020-09-08T18:42:58  *** andreacab has quit IRC
625 2020-09-08T18:47:24  *** Highway62 has joined #bitcoin-core-dev
626 2020-09-08T18:48:51  *** Highway61 has quit IRC
627 2020-09-08T18:54:45  *** ecrist1 has joined #bitcoin-core-dev
628 2020-09-08T19:00:35  *** justanotheruser has quit IRC
629 2020-09-08T19:03:01  *** afk11 has quit IRC
630 2020-09-08T19:03:30  *** afk11 has joined #bitcoin-core-dev
631 2020-09-08T19:18:02  *** andreacab has joined #bitcoin-core-dev
632 2020-09-08T19:22:53  *** andreacab has quit IRC
633 2020-09-08T19:27:59  *** shesek has joined #bitcoin-core-dev
634 2020-09-08T19:27:59  *** shesek has joined #bitcoin-core-dev
635 2020-09-08T19:31:11  <shesek> does bitcoin core ever verify merkle inclusion proofs? (I assume not, it only verifies that the merkle root matches the set of txids. but maybe I'm missing some other ways its being used?)
636 2020-09-08T19:32:00  *** Talkless has quit IRC
637 2020-09-08T19:32:04  <sipa> gettxoutproof will let you construct one
638 2020-09-08T19:32:09  <sipa> i don't think anything verifies them
639 2020-09-08T19:32:15  <phantomcircuit> shesek, why?
640 2020-09-08T19:34:10  <shesek> just curious. I was writing about that in a comment in the context of me claiming that merkle trees aren't an essential component of Bitcoin's breakthrough, and someone saying that they are (and being wrong :p)
641 2020-09-08T19:34:40  <pinheadmz> sipa isnt there a verifytxoutproof rpc ?
642 2020-09-08T19:34:46  <shesek> I wanted to write that full nodes don't ever verify merkle inclusion proofs at all, and wanted to be sure I'm not wrong
643 2020-09-08T19:34:53  <sipa> pinheadmz: oh, there is!
644 2020-09-08T19:35:03  *** opsec_x122 has joined #bitcoin-core-dev
645 2020-09-08T19:35:04  <sipa> shesek: no, they don't even ever receive any
646 2020-09-08T19:35:06  <shesek> I was thinking more in the context of the protocol and p2p interaction, not the user facing rpcs
647 2020-09-08T19:35:23  <sipa> though they were an essential part of BIP37
648 2020-09-08T19:35:29  <shesek> (if anyone is curious: https://news.ycombinator.com/item?id=24407196)
649 2020-09-08T19:35:54  <phantomcircuit> shesek, for a full node theres no real difference between receiving a merkle tree and a hash of a list
650 2020-09-08T19:36:15  <phantomcircuit> but for spvish clients its very different
651 2020-09-08T19:36:57  <sipa> yeah, for a full-blocks-only bitcoin like protocol, the "merkle root" stored in the block header could just be a flat hash of all txids
652 2020-09-08T19:36:58  <shesek> right, my claim was that the SPV model isn't all that important, and that if Satoshi released Bitcoin without considering light clients at all it would still be the incredible breakthrough that it is
653 2020-09-08T19:37:28  <shesek> I'm aware. :) "If light SPV clients weren't a consideration, we could just concatenate all txids together and use the hash of that in the block header instead of a merkle root, and get the same effect. ... For a full node that has the full list of txids regardless, this is basically meaningless."
654 2020-09-08T19:37:29  <yanmaani> is txn noninclusion proofs something bitcoin core intends to include?
655 2020-09-08T19:37:41  <yanmaani> 'UTXO X did/did not exist in the UTXO set as of this block"
656 2020-09-08T19:37:58  <sipa> yanmaani: the current bitcoin protocol does not permit compact proofs for that
657 2020-09-08T19:38:09  *** opsec_x122 has quit IRC
658 2020-09-08T19:38:23  *** opsec_x12 has joined #bitcoin-core-dev
659 2020-09-08T19:39:49  *** opsec_x122 has joined #bitcoin-core-dev
660 2020-09-08T19:39:55  *** opsec_x12 has quit IRC
661 2020-09-08T19:40:18  *** opsec_x122 is now known as opsec_x12
662 2020-09-08T19:42:12  <yanmaani> I know, but is there any research being done? Like on BIPs or stuff? I know about utreexo
663 2020-09-08T19:42:35  <sipa> in that case, you're asking about proposal bitcoin protocol changes, not bitcoin core
664 2020-09-08T19:42:53  *** opsec_x122 has joined #bitcoin-core-dev
665 2020-09-08T19:43:11  <sipa> utreexo doesn't permit this, as it's insertion ordered
666 2020-09-08T19:43:16  *** opsec_x12 has quit IRC
667 2020-09-08T19:43:36  <sipa> probably better for #bitcoin-wizards
668 2020-09-08T19:48:07  *** arowser has quit IRC
669 2020-09-08T19:48:43  *** davterra has quit IRC
670 2020-09-08T19:48:44  *** justanotheruser has joined #bitcoin-core-dev
671 2020-09-08T19:48:48  *** arowser has joined #bitcoin-core-dev
672 2020-09-08T19:59:50  *** crtn32002[m] has joined #bitcoin-core-dev
673 2020-09-08T20:03:05  *** gzhao408 has quit IRC
674 2020-09-08T20:09:52  *** lightlike has joined #bitcoin-core-dev
675 2020-09-08T20:13:05  *** arowser has quit IRC
676 2020-09-08T20:13:26  *** arowser has joined #bitcoin-core-dev
677 2020-09-08T20:17:12  *** bitcoin-git has joined #bitcoin-core-dev
678 2020-09-08T20:17:12  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/147d50d63e07...4f229d8904f8
679 2020-09-08T20:17:12  <bitcoin-git> bitcoin/master fa7e407 MarcoFalke: Do not pass chain params to CheckForStaleTipAndEvictPeers twice
680 2020-09-08T20:17:13  <bitcoin-git> bitcoin/master 4f229d8 MarcoFalke: Merge #19914: refactor: Do not pass chain params to CheckForStaleTipAndEvi...
681 2020-09-08T20:17:14  *** bitcoin-git has left #bitcoin-core-dev
682 2020-09-08T20:17:32  *** bitcoin-git has joined #bitcoin-core-dev
683 2020-09-08T20:17:32  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #19914: refactor: Do not pass chain params to CheckForStaleTipAndEvictPeers twice (master...2009-netNo2ChainParams) https://github.com/bitcoin/bitcoin/pull/19914
684 2020-09-08T20:17:33  *** bitcoin-git has left #bitcoin-core-dev
685 2020-09-08T20:20:22  *** harrigan has quit IRC
686 2020-09-08T20:24:03  *** Guyver2 has quit IRC
687 2020-09-08T20:53:53  *** gleb has quit IRC
688 2020-09-08T20:58:54  *** gleb has joined #bitcoin-core-dev
689 2020-09-08T21:00:02  *** ecrist1 has quit IRC
690 2020-09-08T21:03:27  *** Highway61 has joined #bitcoin-core-dev
691 2020-09-08T21:15:09  *** filchef has joined #bitcoin-core-dev
692 2020-09-08T21:21:14  *** Voker571 has joined #bitcoin-core-dev
693 2020-09-08T21:21:58  *** promag has joined #bitcoin-core-dev
694 2020-09-08T21:22:23  *** davterra has joined #bitcoin-core-dev
695 2020-09-08T21:29:27  *** bitcoin-git has joined #bitcoin-core-dev
696 2020-09-08T21:29:27  <bitcoin-git> [bitcoin] elichai opened pull request #19920: test: Fuzzing siphash against reference implementation [Request for feedback] (master...2020-fuzzing-siphash) https://github.com/bitcoin/bitcoin/pull/19920
697 2020-09-08T21:29:37  *** bitcoin-git has left #bitcoin-core-dev
698 2020-09-08T21:35:23  *** yanmaani has quit IRC
699 2020-09-08T21:37:49  *** yanmaani has joined #bitcoin-core-dev
700 2020-09-08T21:39:07  *** davterra has quit IRC
701 2020-09-08T21:39:08  *** yanmaani has quit IRC
702 2020-09-08T21:39:32  *** davterra has joined #bitcoin-core-dev
703 2020-09-08T21:39:50  *** yanmaani has joined #bitcoin-core-dev
704 2020-09-08T21:45:18  *** morcos has quit IRC
705 2020-09-08T21:45:34  *** morcos has joined #bitcoin-core-dev
706 2020-09-08T21:57:05  *** andreacab has joined #bitcoin-core-dev
707 2020-09-08T22:00:23  *** davterra has quit IRC
708 2020-09-08T22:01:51  *** andreacab has quit IRC
709 2020-09-08T22:11:07  *** promag_ has joined #bitcoin-core-dev
710 2020-09-08T22:26:25  *** palazzovincenzo has quit IRC
711 2020-09-08T22:38:55  *** justanotheruser has quit IRC
712 2020-09-08T22:47:53  *** lightlike has quit IRC
713 2020-09-08T22:54:04  *** proofofkeags has quit IRC
714 2020-09-08T22:59:03  *** vasild has quit IRC
715 2020-09-08T23:01:16  *** vasild has joined #bitcoin-core-dev
716 2020-09-08T23:02:30  *** proofofkeags has joined #bitcoin-core-dev
717 2020-09-08T23:04:07  *** bitcoin-git has joined #bitcoin-core-dev
718 2020-09-08T23:04:07  <bitcoin-git> [bitcoin] dr-orlovsky closed pull request #19907: util: add psbt combiner role (master...feat/psbt-combiner) https://github.com/bitcoin/bitcoin/pull/19907
719 2020-09-08T23:04:19  *** bitcoin-git has left #bitcoin-core-dev
720 2020-09-08T23:08:32  *** marcoagner has quit IRC
721 2020-09-08T23:09:03  *** Highway61 has quit IRC
722 2020-09-08T23:10:40  *** justanotheruser has joined #bitcoin-core-dev
723 2020-09-08T23:23:01  *** davterra has joined #bitcoin-core-dev
724 2020-09-08T23:29:03  *** tryphe_ has joined #bitcoin-core-dev
725 2020-09-08T23:32:15  *** tryphe has quit IRC
726 2020-09-08T23:56:05  *** arowser has quit IRC
727 2020-09-08T23:56:25  *** arowser has joined #bitcoin-core-dev
728 2020-09-08T23:59:33  *** AaronvanW has quit IRC