1 2020-05-21T00:00:02  *** mreider has quit IRC
  2 2020-05-21T00:15:10  *** baldur has quit IRC
  3 2020-05-21T00:15:54  <luke-jr> promag: that's something UniValue handles, not us
  4 2020-05-21T00:16:21  <luke-jr> not to mention rounding other things at 6 places would be bad
  5 2020-05-21T00:16:54  <promag> im just suggesting rounding this one
  6 2020-05-21T00:18:20  <luke-jr> I'm pointing out that isn't something practical
  7 2020-05-21T00:18:49  <promag> why not?
  8 2020-05-21T00:20:27  <sipa> luke-jr: actually, UniValue very specifically does support setting the string representation of a number, if we really wanted to
  9 2020-05-21T00:20:52  <sipa> (that's the reason it was written, to have control over exact parsing of amounts without round-tripping through double)
 10 2020-05-21T00:21:12  <sipa> though i don't think it's particularly interesting to add code for that here
 11 2020-05-21T00:22:03  *** Tobbi has joined #bitcoin-core-dev
 12 2020-05-21T00:24:12  <luke-jr> sipa: per-Number? :o
 13 2020-05-21T00:24:39  <sipa> UniValue::setNumStr(const std::string& val)
 14 2020-05-21T00:24:43  <luke-jr> hmm
 15 2020-05-21T00:25:08  <luke-jr> promag: also, look at your example value
 16 2020-05-21T00:25:16  <luke-jr> 1.882374845250915e-09
 17 2020-05-21T00:25:20  <promag> I just think exp notation or so many decimal places is not that humah friendly
 18 2020-05-21T00:25:27  <luke-jr> that would round to 0
 19 2020-05-21T00:25:28  <promag> that oyld be 0
 20 2020-05-21T00:25:34  <promag> right X)
 21 2020-05-21T00:25:42  <luke-jr> that isn't accurate :P
 22 2020-05-21T00:26:03  <sipa> promag: well, it's JSON
 23 2020-05-21T00:26:18  <sipa> JSON happens to use exponential notation for this
 24 2020-05-21T00:28:07  *** baldur has joined #bitcoin-core-dev
 25 2020-05-21T00:30:12  *** proofofkeags has quit IRC
 26 2020-05-21T00:48:32  *** promag has quit IRC
 27 2020-05-21T00:54:15  *** AaronvanW has quit IRC
 28 2020-05-21T01:13:02  *** Victor_sueca has quit IRC
 29 2020-05-21T01:25:35  *** tryphe_ has quit IRC
 30 2020-05-21T01:25:48  *** AaronvanW has joined #bitcoin-core-dev
 31 2020-05-21T01:26:06  *** tryphe has joined #bitcoin-core-dev
 32 2020-05-21T01:26:16  *** proofofkeags has joined #bitcoin-core-dev
 33 2020-05-21T01:26:41  *** momo27 has joined #bitcoin-core-dev
 34 2020-05-21T01:32:09  *** momo27 has quit IRC
 35 2020-05-21T01:58:41  *** belcher has quit IRC
 36 2020-05-21T02:15:49  *** nanotube has quit IRC
 37 2020-05-21T02:22:16  *** Victorsueca has joined #bitcoin-core-dev
 38 2020-05-21T02:26:29  *** Victor_sueca has joined #bitcoin-core-dev
 39 2020-05-21T02:28:10  *** Victorsueca has quit IRC
 40 2020-05-21T02:30:49  *** AaronvanW has quit IRC
 41 2020-05-21T02:43:03  *** bitdex has quit IRC
 42 2020-05-21T02:43:27  *** bitdex has joined #bitcoin-core-dev
 43 2020-05-21T02:50:05  *** ironhelix has quit IRC
 44 2020-05-21T02:57:27  *** surja795 has quit IRC
 45 2020-05-21T02:58:10  *** AaronvanW has joined #bitcoin-core-dev
 46 2020-05-21T02:59:32  *** nanotube has joined #bitcoin-core-dev
 47 2020-05-21T02:59:46  *** surja795 has joined #bitcoin-core-dev
 48 2020-05-21T03:00:01  *** Tobbi has quit IRC
 49 2020-05-21T03:04:10  *** surja795 has quit IRC
 50 2020-05-21T03:13:41  *** PaulTroon has joined #bitcoin-core-dev
 51 2020-05-21T03:17:37  *** AaronvanW has quit IRC
 52 2020-05-21T03:19:06  *** PaulTroon has quit IRC
 53 2020-05-21T03:20:56  *** CCoent has joined #bitcoin-core-dev
 54 2020-05-21T03:21:26  *** altoid has joined #bitcoin-core-dev
 55 2020-05-21T03:24:15  *** CCoent has quit IRC
 56 2020-05-21T03:28:53  *** justanotheruser has quit IRC
 57 2020-05-21T03:31:56  *** proofofkeags has quit IRC
 58 2020-05-21T03:39:28  *** AaronvanW has joined #bitcoin-core-dev
 59 2020-05-21T03:41:13  *** justanotheruser has joined #bitcoin-core-dev
 60 2020-05-21T03:44:17  *** AaronvanW has quit IRC
 61 2020-05-21T03:54:36  *** ironhelix has joined #bitcoin-core-dev
 62 2020-05-21T04:11:13  *** Highway61 has quit IRC
 63 2020-05-21T04:20:03  *** vasild_ has joined #bitcoin-core-dev
 64 2020-05-21T04:23:03  *** vasild has quit IRC
 65 2020-05-21T04:23:04  *** vasild_ is now known as vasild
 66 2020-05-21T04:46:11  *** Talkless has joined #bitcoin-core-dev
 67 2020-05-21T05:13:42  *** berndj has quit IRC
 68 2020-05-21T05:24:28  *** berndj has joined #bitcoin-core-dev
 69 2020-05-21T05:29:57  *** jarthur has quit IRC
 70 2020-05-21T05:34:22  *** jonatack has joined #bitcoin-core-dev
 71 2020-05-21T05:41:03  *** jarthur has joined #bitcoin-core-dev
 72 2020-05-21T05:46:17  *** jarthur has quit IRC
 73 2020-05-21T05:52:23  *** jonatack has quit IRC
 74 2020-05-21T05:57:31  *** jonatack has joined #bitcoin-core-dev
 75 2020-05-21T06:00:01  *** altoid has quit IRC
 76 2020-05-21T06:12:46  *** jarthur has joined #bitcoin-core-dev
 77 2020-05-21T06:14:37  *** jonatack has quit IRC
 78 2020-05-21T06:17:47  *** jarthur has quit IRC
 79 2020-05-21T06:19:19  *** ironhelix has quit IRC
 80 2020-05-21T06:20:59  *** Smaczny has joined #bitcoin-core-dev
 81 2020-05-21T06:47:32  *** jonatack has joined #bitcoin-core-dev
 82 2020-05-21T06:53:47  *** jarthur has joined #bitcoin-core-dev
 83 2020-05-21T06:58:37  *** jarthur has quit IRC
 84 2020-05-21T07:02:23  *** marcoagner has joined #bitcoin-core-dev
 85 2020-05-21T07:06:51  *** Pavlenex has joined #bitcoin-core-dev
 86 2020-05-21T07:09:41  *** jonatack has quit IRC
 87 2020-05-21T07:10:26  *** jonatack has joined #bitcoin-core-dev
 88 2020-05-21T07:10:28  *** bitcoin-git has joined #bitcoin-core-dev
 89 2020-05-21T07:10:29  <bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/3eda7ea9ba72...17df15efb546
 90 2020-05-21T07:10:30  <bitcoin-git> bitcoin/master 85f4a4b Carl Dong: guix: Make V=1 more powerful for debugging
 91 2020-05-21T07:10:31  <bitcoin-git> bitcoin/master f852761 Carl Dong: guix: Add clarifying documentation for V env var
 92 2020-05-21T07:10:32  <bitcoin-git> bitcoin/master 17df15e fanquake: Merge #18958: guix: Make V=1 more powerful for debugging
 93 2020-05-21T07:10:33  *** bitcoin-git has left #bitcoin-core-dev
 94 2020-05-21T07:10:48  *** bitcoin-git has joined #bitcoin-core-dev
 95 2020-05-21T07:10:49  <bitcoin-git> [bitcoin] fanquake merged pull request #18958: guix: Make V=1 more powerful for debugging (master...2020-05-guix-improvements) https://github.com/bitcoin/bitcoin/pull/18958
 96 2020-05-21T07:10:49  *** bitcoin-git has left #bitcoin-core-dev
 97 2020-05-21T07:10:52  *** harrigan has quit IRC
 98 2020-05-21T07:12:32  *** harrigan has joined #bitcoin-core-dev
 99 2020-05-21T07:15:02  *** PaulTroon has joined #bitcoin-core-dev
100 2020-05-21T07:20:00  *** PaulTroon has quit IRC
101 2020-05-21T07:20:21  *** Guyver2 has joined #bitcoin-core-dev
102 2020-05-21T07:26:10  <vasild> CI seems to be not starting on #19031 for 10ish hours. How do I kick it to start?
103 2020-05-21T07:26:12  <gribble> https://github.com/bitcoin/bitcoin/issues/19031 | Implement ADDRv2 support (part of BIP155) by vasild · Pull Request #19031 · bitcoin/bitcoin · GitHub
104 2020-05-21T07:27:13  <vasild> More importantly - why did it not start? Could it be that I force pushed two times within a few minutes?
105 2020-05-21T07:28:14  <sipa> yeah, that may cause it
106 2020-05-21T07:28:17  <sipa> just push again
107 2020-05-21T07:28:24  <fanquake> Looks like it did run
108 2020-05-21T07:28:26  <fanquake> https://travis-ci.org/github/bitcoin/bitcoin/builds/689316499
109 2020-05-21T07:28:36  <fanquake> Results may have just not made it back  to GH  for some reason
110 2020-05-21T07:28:42  <elichai2> Hi, I'm looking at issue #19036, and shouldn't this: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L328 be `continue;` instead of `return false;` so it will continue trying master keys?
111 2020-05-21T07:28:43  <gribble> https://github.com/bitcoin/bitcoin/issues/19036 | Cannot change passphrase even if it is correct · Issue #19036 · bitcoin/bitcoin · GitHub
112 2020-05-21T07:29:00  <elichai2> just like here: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L302
113 2020-05-21T07:29:34  <fanquake> vasild: I can restart it, but  looks like you'll want to browse those logs
114 2020-05-21T07:30:13  * vasild looking...
115 2020-05-21T07:33:45  <vasild> fanquake: https://travis-ci.org/github/bitcoin/bitcoin/builds/689316499 that is the result from the initial run after PR was opened. Afterwards I push-f'ed 2 times, hopefully resolving those failures (first push -f) and rebasing (second push -f)
116 2020-05-21T07:34:52  <fanquake> vasild: ok. I'll restart that build and see what happens,  and if it re-connects to GH
117 2020-05-21T07:35:00  *** bitcoin-git has joined #bitcoin-core-dev
118 2020-05-21T07:35:01  <bitcoin-git> [bitcoin] fanquake pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/17df15efb546...97b21b302a11
119 2020-05-21T07:35:02  <bitcoin-git> bitcoin/master 5d1377b Russell Yanofsky: build: multiprocess autotools changes
120 2020-05-21T07:35:03  <bitcoin-git> bitcoin/master 603fd6a Russell Yanofsky: depends: add MULTIPROCESS depends option
121 2020-05-21T07:35:04  <bitcoin-git> bitcoin/master e2bab2a Russell Yanofsky: multiprocess: add multiprocess travis configuration
122 2020-05-21T07:35:05  <vasild> It is not very obvious but the travis job says "Commit d48ece5" and when I click on it I see on github "Merge 89d346a into 448bdff". 89d346a was the tip when the PR was opened
123 2020-05-21T07:35:05  *** bitcoin-git has left #bitcoin-core-dev
124 2020-05-21T07:35:30  *** bitcoin-git has joined #bitcoin-core-dev
125 2020-05-21T07:35:30  <bitcoin-git> [bitcoin] fanquake merged pull request #18677: Multiprocess build support (master...pr/ipc-build2) https://github.com/bitcoin/bitcoin/pull/18677
126 2020-05-21T07:35:31  *** bitcoin-git has left #bitcoin-core-dev
127 2020-05-21T07:37:08  <fanquake> vasild: ah I think I see the issue
128 2020-05-21T07:37:22  <fanquake> "GitHub payload is missing a merge commit (mergeable_state: "dirty", merged: false)"
129 2020-05-21T07:37:42  <fanquake> If you look here: https://travis-ci.org/github/bitcoin/bitcoin/requests, that was the status for your branch
130 2020-05-21T07:38:05  <vasild> hmm, what does that mean?
131 2020-05-21T07:38:45  <fanquake> Maybe GHs API being a bit broken
132 2020-05-21T07:41:41  <fanquake> If the results don't show up on GH shortly, I'd say just push to the branch again, and that might kick everything back into gear
133 2020-05-21T07:42:09  <vasild> https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/common-build-problems.md
134 2020-05-21T07:42:24  <vasild> "GitHub payload is missing a merge commit", please confirm your pull request is open and mergeable.
135 2020-05-21T07:43:06  *** bitcoin-git has joined #bitcoin-core-dev
136 2020-05-21T07:43:07  <bitcoin-git> [bitcoin] hebasto closed pull request #19029: net: Fix CThreadInterrupt::sleep_for TSan issues (master...200520-interrupts) https://github.com/bitcoin/bitcoin/pull/19029
137 2020-05-21T07:43:08  *** bitcoin-git has left #bitcoin-core-dev
138 2020-05-21T07:43:09  <vasild> it wasn't mergeable
139 2020-05-21T07:43:15  <fanquake> Maybe it got caught out somehow between the two forces pushes
140 2020-05-21T07:43:34  <fanquake> You should probably just push again for good measure
141 2020-05-21T07:44:13  <vasild> yes, I will (needlessly) rebase now and push again
142 2020-05-21T07:44:29  <vasild> hopefully nobody started reviewing yet :)
143 2020-05-21T07:46:45  <vasild> So, at the time I pushed some fixes to the PR the master branch has advanced in such a way that it would conflict. Makes sense that CI stumbled because it tries to merge the PR into master and build/test that.
144 2020-05-21T07:47:56  *** hebasto has quit IRC
145 2020-05-21T07:48:08  <vasild> And maybe the second push which rebased on latest master (resovling conflicts) was missed because it came too soon.
146 2020-05-21T07:48:48  <vasild> pushed
147 2020-05-21T07:49:02  <fanquake> Looks like it good now
148 2020-05-21T07:50:05  <vasild> yes, thanks!
149 2020-05-21T07:50:29  *** hebasto has joined #bitcoin-core-dev
150 2020-05-21T07:58:07  *** jonatack has quit IRC
151 2020-05-21T07:59:14  *** jonatack has joined #bitcoin-core-dev
152 2020-05-21T08:04:11  *** AaronvanW has joined #bitcoin-core-dev
153 2020-05-21T08:12:04  *** DeanWeen has joined #bitcoin-core-dev
154 2020-05-21T08:14:23  *** Dean_Guss has quit IRC
155 2020-05-21T08:28:24  *** promag has joined #bitcoin-core-dev
156 2020-05-21T08:40:46  *** emilengler has joined #bitcoin-core-dev
157 2020-05-21T08:53:54  *** jonatack_ has joined #bitcoin-core-dev
158 2020-05-21T08:56:34  *** Talkless has quit IRC
159 2020-05-21T08:57:04  *** jonatack has quit IRC
160 2020-05-21T08:57:56  *** Talkless has joined #bitcoin-core-dev
161 2020-05-21T09:00:02  *** Smaczny has quit IRC
162 2020-05-21T09:02:31  *** jonatack_ has quit IRC
163 2020-05-21T09:02:54  *** jonatack has joined #bitcoin-core-dev
164 2020-05-21T09:03:43  *** AaronvanW has quit IRC
165 2020-05-21T09:05:23  *** Pavlenex has quit IRC
166 2020-05-21T09:10:25  *** timothy has joined #bitcoin-core-dev
167 2020-05-21T09:16:39  *** PaulTroon has joined #bitcoin-core-dev
168 2020-05-21T09:17:58  *** dfmb_ has joined #bitcoin-core-dev
169 2020-05-21T09:20:13  *** Dieterbe has joined #bitcoin-core-dev
170 2020-05-21T09:21:10  *** Emcy has quit IRC
171 2020-05-21T09:21:13  *** PaulTroon has quit IRC
172 2020-05-21T09:24:41  *** Emcy has joined #bitcoin-core-dev
173 2020-05-21T09:32:52  *** Talkless has quit IRC
174 2020-05-21T09:33:52  *** Talkless has joined #bitcoin-core-dev
175 2020-05-21T09:34:44  *** AaronvanW has joined #bitcoin-core-dev
176 2020-05-21T09:51:15  *** filchef has joined #bitcoin-core-dev
177 2020-05-21T10:03:27  *** Ferne24Gaylord has joined #bitcoin-core-dev
178 2020-05-21T10:04:25  *** kristapsk has quit IRC
179 2020-05-21T10:04:56  *** kristapsk has joined #bitcoin-core-dev
180 2020-05-21T10:15:32  *** yojoots has joined #bitcoin-core-dev
181 2020-05-21T10:16:17  *** Pavlenex has joined #bitcoin-core-dev
182 2020-05-21T10:16:54  *** surja795 has joined #bitcoin-core-dev
183 2020-05-21T10:28:56  *** Ferne24Gaylord has quit IRC
184 2020-05-21T10:29:36  *** cnich has quit IRC
185 2020-05-21T10:41:30  *** webchat__ has joined #bitcoin-core-dev
186 2020-05-21T10:41:54  *** SiAnDoG_ has quit IRC
187 2020-05-21T10:51:14  *** gio98 has joined #bitcoin-core-dev
188 2020-05-21T10:56:01  *** bitcoin-git has joined #bitcoin-core-dev
189 2020-05-21T10:56:03  <bitcoin-git> [bitcoin] MarcoFalke pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/97b21b302a11...25ad2c623af3
190 2020-05-21T10:56:04  <bitcoin-git> bitcoin/master 691c817 Russell Yanofsky: Add util::Ref class as temporary alternative for c++17 std::any
191 2020-05-21T10:56:04  <bitcoin-git> bitcoin/master 6fca33b Russell Yanofsky: refactor: Pass NodeContext to RPC and REST methods through util::Ref
192 2020-05-21T10:56:05  <bitcoin-git> bitcoin/master ccb5059 Russell Yanofsky: scripted-diff: Remove g_rpc_node references
193 2020-05-21T10:56:07  *** bitcoin-git has left #bitcoin-core-dev
194 2020-05-21T10:56:32  *** bitcoin-git has joined #bitcoin-core-dev
195 2020-05-21T10:56:32  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18740: Remove g_rpc_node global (master...pr/frpc) https://github.com/bitcoin/bitcoin/pull/18740
196 2020-05-21T10:56:33  *** bitcoin-git has left #bitcoin-core-dev
197 2020-05-21T10:58:25  *** helo has quit IRC
198 2020-05-21T11:09:33  *** Talkless has quit IRC
199 2020-05-21T11:10:12  *** Talkless has joined #bitcoin-core-dev
200 2020-05-21T11:12:01  *** timothy has quit IRC
201 2020-05-21T11:13:38  *** Pavlenex has joined #bitcoin-core-dev
202 2020-05-21T11:16:09  <wumpus> promag: I don't think rounding it makes sense, despite looking silly it's simply a JSON number invalid JSON number format, and JSON is not a presentation but interchange format
203 2020-05-21T11:16:16  <wumpus> invalid -> in valid
204 2020-05-21T11:16:52  <wumpus> if you want it to look nicer in some monitoring program, rounding it client-side is the way to go
205 2020-05-21T11:17:52  <wumpus> should we do a meeting today?
206 2020-05-21T11:19:05  *** timothy has joined #bitcoin-core-dev
207 2020-05-21T11:19:18  <wumpus> (I don't mind, but at least here it's officially a free day due to Christian holiday)
208 2020-05-21T11:19:23  *** DeanWeen has quit IRC
209 2020-05-21T11:19:58  *** Pavlenex has quit IRC
210 2020-05-21T11:34:16  *** promag has quit IRC
211 2020-05-21T11:35:26  *** gio98 has quit IRC
212 2020-05-21T11:53:13  *** belcher has joined #bitcoin-core-dev
213 2020-05-21T11:57:36  <fanquake> wumpus: I will be sleeping either way heh
214 2020-05-21T11:58:02  *** gio98 has joined #bitcoin-core-dev
215 2020-05-21T11:58:34  *** jorijn has quit IRC
216 2020-05-21T11:59:47  *** jorijn has joined #bitcoin-core-dev
217 2020-05-21T12:00:02  *** Dieterbe has quit IRC
218 2020-05-21T12:12:20  *** gio98 has quit IRC
219 2020-05-21T12:12:26  <vasild> Has anybody tried to map code coverage reports with lines modified by a patch? To generate a report like "This PR modified 10 lines and from those 8 are covered and 2 are not".
220 2020-05-21T12:14:25  <wumpus> vasild: I don't think I've ever heard that idea before, it's kind of interesting!
221 2020-05-21T12:16:53  *** Highway61 has joined #bitcoin-core-dev
222 2020-05-21T12:18:34  <vasild> wumpus: it would help assess how much of the modified code is covered
223 2020-05-21T12:19:07  <vasild> => to write tests that cover the modifications
224 2020-05-21T12:20:17  *** Stephnix has joined #bitcoin-core-dev
225 2020-05-21T12:27:10  *** bitcoin-git has joined #bitcoin-core-dev
226 2020-05-21T12:27:10  <bitcoin-git> [bitcoin] hebasto reopened pull request #19029: net: Fix CThreadInterrupt::sleep_for TSan issues (master...200520-interrupts) https://github.com/bitcoin/bitcoin/pull/19029
227 2020-05-21T12:27:11  *** bitcoin-git has left #bitcoin-core-dev
228 2020-05-21T12:42:11  *** troygiorshev has joined #bitcoin-core-dev
229 2020-05-21T12:42:52  *** fearbeag has joined #bitcoin-core-dev
230 2020-05-21T12:49:37  *** promag has joined #bitcoin-core-dev
231 2020-05-21T12:51:58  *** emilengler has quit IRC
232 2020-05-21T13:02:50  *** bitcoin-git has joined #bitcoin-core-dev
233 2020-05-21T13:02:51  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/25ad2c623af3...cfe22a5f9e1d
234 2020-05-21T13:02:51  <bitcoin-git> bitcoin/master be01449 glowang: Add test for param interaction b/w -blocksonly and -whitelistforcerelay
235 2020-05-21T13:02:52  <bitcoin-git> bitcoin/master 0ea5d70 glowang: Updated comment for the condition where a transaction relay is denied
236 2020-05-21T13:02:52  <bitcoin-git> bitcoin/master cfe22a5 MarcoFalke: Merge #18530: Add test for -blocksonly and -whitelistforcerelay param inte...
237 2020-05-21T13:02:53  *** bitcoin-git has left #bitcoin-core-dev
238 2020-05-21T13:03:20  *** bitcoin-git has joined #bitcoin-core-dev
239 2020-05-21T13:03:21  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18530: Add test for -blocksonly and -whitelistforcerelay param interaction (master...add_blocksonly_tests) https://github.com/bitcoin/bitcoin/pull/18530
240 2020-05-21T13:03:22  *** bitcoin-git has left #bitcoin-core-dev
241 2020-05-21T13:06:55  *** sipa has quit IRC
242 2020-05-21T13:17:21  *** sipa has joined #bitcoin-core-dev
243 2020-05-21T13:17:21  *** PaulTroon has joined #bitcoin-core-dev
244 2020-05-21T13:21:54  *** PaulTroon has quit IRC
245 2020-05-21T13:22:13  <jonatack> vasild: i've used https://coveralls.io in work and side projects (e.g. https://github.com/jonatack/cl-kraken) these past years...did you have another one in mind?
246 2020-05-21T13:31:13  *** DeanWeen has joined #bitcoin-core-dev
247 2020-05-21T13:32:16  *** lucaferr has joined #bitcoin-core-dev
248 2020-05-21T13:33:01  *** lucaferr has joined #bitcoin-core-dev
249 2020-05-21T13:33:36  *** owowo has quit IRC
250 2020-05-21T13:33:47  *** lucaferr has quit IRC
251 2020-05-21T13:40:52  <vasild> jonatack: I did not have anything in mind, other than I need that info to extend the coverage on a PR :)
252 2020-05-21T13:41:01  *** owowo has joined #bitcoin-core-dev
253 2020-05-21T13:44:43  *** mdunnio has joined #bitcoin-core-dev
254 2020-05-21T13:50:30  *** d_t has joined #bitcoin-core-dev
255 2020-05-21T13:53:08  <vasild> Can coveralls.io do that?
256 2020-05-21T13:56:00  *** lucaferr has joined #bitcoin-core-dev
257 2020-05-21T14:02:10  <MarcoFalke> [15:13] <achow101> how do I run the travis lsan build locally?
258 2020-05-21T14:02:15  <MarcoFalke> See ci/Readme.md
259 2020-05-21T14:06:36  <jonatack> vasild: it should, see https://coveralls.io/features "Line by line coverage: Quickly browse through individual files that have changed in a new commit, and see exactly what changed in the build coverage line by line."
260 2020-05-21T14:07:18  <MarcoFalke> vasild: DrahtBot does that, but it is not yet public
261 2020-05-21T14:07:19  <jonatack> vasild: but ISTM that MarcoFalke has that already with his online coverage pages?
262 2020-05-21T14:07:44  <jonatack> MarcoFalke: oh ok, not surprised
263 2020-05-21T14:08:25  <MarcoFalke> Though, it is currently blocked on #[15:13] <achow101> how do I run the travis lsan build locally?
264 2020-05-21T14:08:27  <lucaferr> I'm trying to understand Compact Filters. In blockfilters.json are "[Prev Output Scripts for Block]" each supposed to match with the basic filter provided? I can't get them to match, although outputs from the same block do match the filter.
265 2020-05-21T14:08:41  <MarcoFalke> (wrong clipboard)
266 2020-05-21T14:08:42  <vasild> I think coveralls.io can do full report on a branch and then another full report on branch+commit.
267 2020-05-21T14:08:44  <MarcoFalke> #14343
268 2020-05-21T14:08:47  <gribble> https://github.com/bitcoin/bitcoin/issues/14343 | coverage reports non-deterministic · Issue #14343 · bitcoin/bitcoin · GitHub
269 2020-05-21T14:09:50  <MarcoFalke> You will have to do the diff manually for now
270 2020-05-21T14:10:04  <jonatack> vasild: it did for my use, it wasn't c++ but it likely can, yes
271 2020-05-21T14:10:08  <MarcoFalke> But I can tell DrahtBot to run on a pull to generate the raw data
272 2020-05-21T14:13:27  <vasild> "You will have to do the diff manually for now" -- so I have a full report on branch that is 100k+ lines, another full report on branch+commitX that is 100k+ lines and commitX that modifies e.g. 1000 lines.
273 2020-05-21T14:14:13  <vasild> I am now trying to do something locally, if that works, then it should be possible to teach some CI system to do it too (e.g. coveralls.io or another one).
274 2020-05-21T14:14:45  <MarcoFalke> Jup :( . Not sure how to solve that. But if you only modify net_processing, for exmple, you can probably discard coverage diffs in init.cpp or so
275 2020-05-21T14:15:08  <MarcoFalke> vasild: Nice. Let me know if you make progress :)
276 2020-05-21T14:15:55  <vasild> actually the full report on branch (before commitX) is not needed. My idea is to strip the report from branch+commitX to only the lines modified by commitX
277 2020-05-21T14:16:35  <MarcoFalke> That would exclude all side effects, no?
278 2020-05-21T14:17:22  <vasild> hmm :/
279 2020-05-21T14:17:38  *** webchat__ has quit IRC
280 2020-05-21T14:17:39  <MarcoFalke> For example a commit that restructures the validation interface might have a coverage effect on the wallet or the txindex
281 2020-05-21T14:18:00  <vasild> right
282 2020-05-21T14:18:11  *** SiAnDoG has joined #bitcoin-core-dev
283 2020-05-21T14:18:57  <MarcoFalke> If you goal is to show coverage of the lines you modify in a patch (and they happen to have debug log statements, or otherwise show effects that can be tested), I recommend just writing a test to prove coverage
284 2020-05-21T14:19:13  *** Relis has joined #bitcoin-core-dev
285 2020-05-21T14:20:34  <vasild> that is my goal, yes
286 2020-05-21T14:22:09  <MarcoFalke> but longer term we really need a way to automate this
287 2020-05-21T14:22:56  <MarcoFalke> One option could be to build a deterministic CPU to kill all non-determinism in the unit tests. Not sure if that is possible with qemu or rr
288 2020-05-21T14:23:47  *** Relis has quit IRC
289 2020-05-21T14:26:25  *** Relis has joined #bitcoin-core-dev
290 2020-05-21T14:30:14  <vasild> Just run the tests on Windows where the OS random number generator is so flawed that it returns always the same numbers :-D
291 2020-05-21T14:30:17  <wumpus> what is non-deterministic about a CPU? (besides race conditions in threading)
292 2020-05-21T14:30:54  *** Relis has quit IRC
293 2020-05-21T14:31:43  <wumpus> for random instructions it should be as easy as 'don't use them', i guess, only use deterministic randomness in tests
294 2020-05-21T14:31:47  <vasild> is "if (GetMainSignals().CallbacksPending() > 10) {" mentioned in https://github.com/bitcoin/bitcoin/issues/14343#issuecomment-426916136 exactly that, "race conditions in threading"?
295 2020-05-21T14:32:15  <vasild> yeah, random number are easy to deal with
296 2020-05-21T14:32:21  <vasild> numbers
297 2020-05-21T14:32:46  <wumpus> the thing is, even if the CPU is determinstic, things such as I/O won't be
298 2020-05-21T14:33:19  <wumpus> even RAM might not be 100% deterministic (regarding timing)
299 2020-05-21T14:38:03  <MarcoFalke> Ok, then we also need deterministic RAM :)
300 2020-05-21T14:40:05  *** Relis has joined #bitcoin-core-dev
301 2020-05-21T14:43:01  <wumpus> heh
302 2020-05-21T14:43:45  *** Relis has quit IRC
303 2020-05-21T14:47:00  <lucaferr> Would it be possible to get the expanded uint64:s of the basic filter field as well as siphashed/fastranged values of the prev output scripts in the blockfilters.json?
304 2020-05-21T14:50:03  *** d_t has quit IRC
305 2020-05-21T14:56:04  <MarcoFalke> lucaferr: Not without modifying the rest interface. But why would you want to do that?
306 2020-05-21T14:57:56  <lucaferr> I'm just trying to build some code around it to better understand what is going on. My understanding is that all the prev output scripts should be encoded in the basic filter? However, I cannot get them to match the basic filter. Am I perhaps wrong in assuming that? It would be nice to see the decoded uint64:s from the golomb encoded bitstream, for verification...
307 2020-05-21T15:00:02  *** Stephnix has quit IRC
308 2020-05-21T15:00:45  *** Relis has joined #bitcoin-core-dev
309 2020-05-21T15:00:51  *** bitcoin-git has joined #bitcoin-core-dev
310 2020-05-21T15:00:51  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/cfe22a5f9e1d...741816936441
311 2020-05-21T15:00:52  <bitcoin-git> bitcoin/master 4444dbf MarcoFalke: gui: Remove un-actionable TODO
312 2020-05-21T15:00:52  <bitcoin-git> bitcoin/master 7418169 MarcoFalke: Merge #18997: gui: Remove un-actionable TODO
313 2020-05-21T15:00:54  *** bitcoin-git has left #bitcoin-core-dev
314 2020-05-21T15:01:06  *** Pavlenex has joined #bitcoin-core-dev
315 2020-05-21T15:01:12  *** bitcoin-git has joined #bitcoin-core-dev
316 2020-05-21T15:01:12  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18997: gui: Remove un-actionable TODO (master...2005-guiNoTodo) https://github.com/bitcoin/bitcoin/pull/18997
317 2020-05-21T15:01:13  *** bitcoin-git has left #bitcoin-core-dev
318 2020-05-21T15:02:00  *** timothy has quit IRC
319 2020-05-21T15:02:15  <MarcoFalke> lucaferr: I suggest playing around with that in a unit test. They should be in ./src/test/blockfilter_tests or ./src/test/golomb_tests
320 2020-05-21T15:02:36  <lucaferr> MarcoFalke: thanks, I'll take a look
321 2020-05-21T15:07:50  <jnewbery> jonasschnelli: do you mind looking at #1896
322 2020-05-21T15:07:51  <gribble> https://github.com/bitcoin/bitcoin/issues/1896 | Translation update for 0.7.1 · Issue #1896 · bitcoin/bitcoin · GitHub
323 2020-05-21T15:08:02  <jnewbery> jonasschnelli: do you mind looking at #18960
324 2020-05-21T15:08:06  <gribble> https://github.com/bitcoin/bitcoin/issues/18960 | indexes: Add compact block filter headers cache by jnewbery · Pull Request #18960 · bitcoin/bitcoin · GitHub
325 2020-05-21T15:11:05  <jnewbery> I think it may be ready for merge (4 ACKs). You thought the last one might have been merged too soon quickly, so I want to make sure that there are no concerns about merging this one
326 2020-05-21T15:16:12  *** timothy has joined #bitcoin-core-dev
327 2020-05-21T15:18:53  *** PaulTroon has joined #bitcoin-core-dev
328 2020-05-21T15:20:46  *** Relis has quit IRC
329 2020-05-21T15:21:28  *** aaronmcadam has joined #bitcoin-core-dev
330 2020-05-21T15:23:16  *** PaulTroon has quit IRC
331 2020-05-21T15:23:30  *** PaulTroon has joined #bitcoin-core-dev
332 2020-05-21T15:28:01  *** bitcoin-git has joined #bitcoin-core-dev
333 2020-05-21T15:28:01  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/741816936441...99e5e21b38bc
334 2020-05-21T15:28:02  <bitcoin-git> bitcoin/master fab908f MarcoFalke: test: Fix intermittent ETIMEDOUT on FreeBSD
335 2020-05-21T15:28:02  <bitcoin-git> bitcoin/master 99e5e21 Wladimir J. van der Laan: Merge #19023: test: Fix intermittent ETIMEDOUT on FreeBSD
336 2020-05-21T15:28:04  *** bitcoin-git has left #bitcoin-core-dev
337 2020-05-21T15:28:21  *** bitcoin-git has joined #bitcoin-core-dev
338 2020-05-21T15:28:21  <bitcoin-git> [bitcoin] laanwj merged pull request #19023: test: Fix intermittent ETIMEDOUT on FreeBSD (master...2005-testFixIntermFreeBsdTimeout) https://github.com/bitcoin/bitcoin/pull/19023
339 2020-05-21T15:28:22  *** bitcoin-git has left #bitcoin-core-dev
340 2020-05-21T15:33:50  *** jarthur has joined #bitcoin-core-dev
341 2020-05-21T15:35:53  *** jarthur has quit IRC
342 2020-05-21T15:36:20  *** jarthur has joined #bitcoin-core-dev
343 2020-05-21T15:38:37  *** mr_burdell has quit IRC
344 2020-05-21T15:41:21  *** mr_burdell has joined #bitcoin-core-dev
345 2020-05-21T15:41:26  *** ctrlbreak_MAD has quit IRC
346 2020-05-21T15:41:53  *** ctrlbreak_MAD has joined #bitcoin-core-dev
347 2020-05-21T15:42:05  *** setpill has joined #bitcoin-core-dev
348 2020-05-21T15:44:40  *** bitcoin-git has joined #bitcoin-core-dev
349 2020-05-21T15:44:40  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/99e5e21b38bc...fed1a9043fdf
350 2020-05-21T15:44:41  <bitcoin-git> bitcoin/master fa8bbb1 MarcoFalke: net: Use C++11 member initialization in protocol
351 2020-05-21T15:44:41  <bitcoin-git> bitcoin/master fed1a90 Wladimir J. van der Laan: Merge #19020: net: Use C++11 member initialization in protocol
352 2020-05-21T15:44:43  *** bitcoin-git has left #bitcoin-core-dev
353 2020-05-21T15:45:00  *** bitcoin-git has joined #bitcoin-core-dev
354 2020-05-21T15:45:00  <bitcoin-git> [bitcoin] laanwj merged pull request #19020: net: Use C++11 member initialization in protocol (master...2005-netCxx11MemberInit) https://github.com/bitcoin/bitcoin/pull/19020
355 2020-05-21T15:45:01  *** bitcoin-git has left #bitcoin-core-dev
356 2020-05-21T15:49:23  *** jarthur has quit IRC
357 2020-05-21T15:53:38  *** Pavlenex has quit IRC
358 2020-05-21T15:56:27  *** justanotheruser has quit IRC
359 2020-05-21T15:58:23  *** ghost43 has joined #bitcoin-core-dev
360 2020-05-21T16:02:41  *** setpill has quit IRC
361 2020-05-21T16:11:37  *** justanotheruser has joined #bitcoin-core-dev
362 2020-05-21T16:20:16  *** vasild_ has joined #bitcoin-core-dev
363 2020-05-21T16:23:23  *** vasild has quit IRC
364 2020-05-21T16:23:24  *** vasild_ is now known as vasild
365 2020-05-21T16:30:14  *** Relis has joined #bitcoin-core-dev
366 2020-05-21T16:30:19  *** promag has quit IRC
367 2020-05-21T16:34:09  *** bitcoin-git has joined #bitcoin-core-dev
368 2020-05-21T16:34:09  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #19041: ci: tsan with -stdlib=libc++ (master...2005-ciTsanFix) https://github.com/bitcoin/bitcoin/pull/19041
369 2020-05-21T16:34:10  *** bitcoin-git has left #bitcoin-core-dev
370 2020-05-21T16:40:31  *** IGHOR has quit IRC
371 2020-05-21T16:44:55  *** _Sam-- has joined #bitcoin-core-dev
372 2020-05-21T16:45:36  *** theStack has joined #bitcoin-core-dev
373 2020-05-21T16:47:25  *** timothy has quit IRC
374 2020-05-21T16:47:34  *** IGHOR has joined #bitcoin-core-dev
375 2020-05-21T16:48:13  *** proofofkeags has joined #bitcoin-core-dev
376 2020-05-21T16:49:35  *** promag has joined #bitcoin-core-dev
377 2020-05-21T16:59:10  *** emilengler has joined #bitcoin-core-dev
378 2020-05-21T17:02:39  *** jarthur has joined #bitcoin-core-dev
379 2020-05-21T17:14:04  *** Pavlenex has joined #bitcoin-core-dev
380 2020-05-21T17:21:16  *** ironhelix has joined #bitcoin-core-dev
381 2020-05-21T17:26:10  *** kristapsk has quit IRC
382 2020-05-21T17:35:08  *** bitcoin-git has joined #bitcoin-core-dev
383 2020-05-21T17:35:10  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fed1a9043fdf...4479eb04d928
384 2020-05-21T17:35:10  <bitcoin-git> bitcoin/master 0187d4c John Newbery: [indexes] Add compact block filter headers cache
385 2020-05-21T17:35:11  <bitcoin-git> bitcoin/master 4479eb0 Wladimir J. van der Laan: Merge #18960: indexes: Add compact block filter headers cache
386 2020-05-21T17:35:13  *** bitcoin-git has left #bitcoin-core-dev
387 2020-05-21T17:35:29  *** bitcoin-git has joined #bitcoin-core-dev
388 2020-05-21T17:35:29  <bitcoin-git> [bitcoin] laanwj merged pull request #18960: indexes: Add compact block filter headers cache (master...2020-05-cfcheckpts-cache) https://github.com/bitcoin/bitcoin/pull/18960
389 2020-05-21T17:35:30  *** bitcoin-git has left #bitcoin-core-dev
390 2020-05-21T17:45:17  *** PaulTroon has quit IRC
391 2020-05-21T17:47:17  *** ctrlbreak_MAD has quit IRC
392 2020-05-21T17:47:45  *** ctrlbreak_MAD has joined #bitcoin-core-dev
393 2020-05-21T17:58:48  *** d_t has joined #bitcoin-core-dev
394 2020-05-21T17:59:07  *** d_t has quit IRC
395 2020-05-21T18:00:02  *** aaronmcadam has quit IRC
396 2020-05-21T18:02:50  <wumpus> PSA bitcoin-acks has a repository in the bitcoincore organization now: https://github.com/bitcoin-core/bitcoin-acks @ jonatack pierre_rochard
397 2020-05-21T18:05:47  *** kristapsk has joined #bitcoin-core-dev
398 2020-05-21T18:05:55  <pierre_rochard> Thank you wumpus!
399 2020-05-21T18:07:37  <theStack> that's great news! i wondered recently what happened to bitcoin-acks.com
400 2020-05-21T18:07:41  *** d_t has joined #bitcoin-core-dev
401 2020-05-21T18:09:01  <theStack> i think jonatack proposed to run it on bitcoin.org recently if i remember correctly; any plans about that? or is the idea that people spin it up locally? (should also be quite easy thanks to docker)
402 2020-05-21T18:11:17  <wumpus> pierre_rochard: yw, thanks for creating it in the first place!
403 2020-05-21T18:12:38  <wumpus> theStack: i think it should be back up
404 2020-05-21T18:14:22  *** d_t has quit IRC
405 2020-05-21T18:14:25  <theStack> wumpus: ah, indeed! i just mistyped... it's without the dash, i.e. bitcoinacks.com
406 2020-05-21T18:16:10  <wumpus> right the repository has a dash but the site doesn't :)
407 2020-05-21T18:18:54  *** Pavlenex has joined #bitcoin-core-dev
408 2020-05-21T18:22:01  *** mshadle1 has joined #bitcoin-core-dev
409 2020-05-21T18:22:03  *** andrewtoth has quit IRC
410 2020-05-21T18:26:12  *** proofofkeags has quit IRC
411 2020-05-21T18:26:46  *** proofofkeags has joined #bitcoin-core-dev
412 2020-05-21T18:28:59  *** Pavlenex has quit IRC
413 2020-05-21T18:29:05  *** proofofk_ has joined #bitcoin-core-dev
414 2020-05-21T18:29:11  *** proofofkeags has quit IRC
415 2020-05-21T18:31:28  <luke-jr> theStack: you mean bitcoincore.org?
416 2020-05-21T18:33:12  *** Pavlenex has joined #bitcoin-core-dev
417 2020-05-21T18:34:06  *** proofofk_ has quit IRC
418 2020-05-21T18:35:02  <wumpus> probably; but bitcoincore.org itself only hosts static content, it would be possible to host it as a subdomain but the original domain is better
419 2020-05-21T18:39:42  <jonatack> theStack: luke-jr: i proposed to bring bitcoinacks, with pierre_rochard's permission, into https://github.com/bitcoin-core/ to see more attention
420 2020-05-21T18:40:00  <jonatack> http://www.erisian.com.au/bitcoin-core-dev/log-2020-05-15.html#l-383
421 2020-05-21T18:43:52  <theStack> luke-jr: yes indeed; bitcoin.org is not under the control of the core devs now i guess?
422 2020-05-21T18:44:13  <achow101> theStack: it never really was
423 2020-05-21T18:44:24  <theStack> wumpus: agreed that the original domain is good
424 2020-05-21T18:45:51  <theStack> jonatack: great initiative! will for sure use it (and maybe in the course of that even contribute) for reviewing
425 2020-05-21T18:46:51  *** promag has quit IRC
426 2020-05-21T18:49:07  *** promag has joined #bitcoin-core-dev
427 2020-05-21T18:50:57  *** bitcoin-git has joined #bitcoin-core-dev
428 2020-05-21T18:50:57  <bitcoin-git> [bitcoin] laanwj pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/4479eb04d928...9abed46871a7
429 2020-05-21T18:50:58  <bitcoin-git> bitcoin/master a8334f7 Andrew Chow: Read and write a checksum for encrypted keys
430 2020-05-21T18:50:59  <bitcoin-git> bitcoin/master c9a9ddb Andrew Chow: Set fDecryptionThoroughlyChecked based on whether crypted key checksums ar...
431 2020-05-21T18:50:59  <bitcoin-git> bitcoin/master d67055e Andrew Chow: Upgrade or rewrite encrypted key checksums
432 2020-05-21T18:51:00  *** bitcoin-git has left #bitcoin-core-dev
433 2020-05-21T18:51:56  <jonatack> the
434 2020-05-21T18:52:12  *** bitcoin-git has joined #bitcoin-core-dev
435 2020-05-21T18:52:13  <bitcoin-git> [bitcoin] laanwj merged pull request #16946: wallet: include a checksum of encrypted private keys (master...wallet-enckey-checksum) https://github.com/bitcoin/bitcoin/pull/16946
436 2020-05-21T18:52:14  *** bitcoin-git has left #bitcoin-core-dev
437 2020-05-21T18:52:32  <jonatack> theStack: 👍
438 2020-05-21T18:55:18  *** promag has quit IRC
439 2020-05-21T18:59:09  *** ghost43 has quit IRC
440 2020-05-21T19:00:05  *** d_t has joined #bitcoin-core-dev
441 2020-05-21T19:01:19  <wumpus> #startmeeting
442 2020-05-21T19:01:19  <lightningbot> Meeting started Thu May 21 19:01:19 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
443 2020-05-21T19:01:19  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
444 2020-05-21T19:01:22  <jnewbery> hi
445 2020-05-21T19:01:23  <kanzure> hi
446 2020-05-21T19:01:24  <jeremyrubin> hi
447 2020-05-21T19:01:24  <wumpus> let's try...
448 2020-05-21T19:01:26  <jkczyz> hi
449 2020-05-21T19:01:36  <achow101> hi
450 2020-05-21T19:01:42  <fjahr> hi
451 2020-05-21T19:01:49  <ariard> hi
452 2020-05-21T19:01:51  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james amiti fjahr
453 2020-05-21T19:01:52  <jonatack> late night hi
454 2020-05-21T19:01:52  <wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
455 2020-05-21T19:01:55  *** ghost43 has joined #bitcoin-core-dev
456 2020-05-21T19:02:02  <hebasto> hi
457 2020-05-21T19:02:24  <elichai2> Hi
458 2020-05-21T19:02:33  <wumpus> one proposed meeting topic: alternative transports support (ariard)
459 2020-05-21T19:02:39  <ariard> yes!
460 2020-05-21T19:02:49  <instagibbs> hi
461 2020-05-21T19:02:51  <wumpus> any last minute proposals?
462 2020-05-21T19:02:53  <amiti> hi
463 2020-05-21T19:02:59  <meshcollider> hi
464 2020-05-21T19:03:42  <wumpus> okay, let's start with high priority for review as usual
465 2020-05-21T19:03:48  <wumpus> #topic High priority for review
466 2020-05-21T19:03:48  <luke-jr> hi
467 2020-05-21T19:03:57  <aj> hi
468 2020-05-21T19:03:58  <hebasto> could #18297 be added to hi-prio?
469 2020-05-21T19:04:00  <gribble> https://github.com/bitcoin/bitcoin/issues/18297 | build: Use pkg-config in BITCOIN_QT_CONFIGURE for all hosts including Windows by hebasto · Pull Request #18297 · bitcoin/bitcoin · GitHub
470 2020-05-21T19:04:05  <wumpus> https://github.com/bitcoin/bitcoin/projects/8  4 blockers, 1 bugfix, 4 chasing concept ACK
471 2020-05-21T19:04:28  <wumpus> hebasto: yes
472 2020-05-21T19:04:37  <hebasto> wumpus: thanks
473 2020-05-21T19:05:00  <achow101> #18787 for hi prio
474 2020-05-21T19:05:02  <gribble> https://github.com/bitcoin/bitcoin/issues/18787 | wallet: descriptor wallet release notes and cleanups by achow101 · Pull Request #18787 · bitcoin/bitcoin · GitHub
475 2020-05-21T19:05:55  <wumpus> achow101: added
476 2020-05-21T19:07:31  <wumpus> #topic Alternative transports support (ariard)
477 2020-05-21T19:07:41  <wumpus> #18989
478 2020-05-21T19:07:43  <gribble> https://github.com/bitcoin/bitcoin/issues/18989 | Towards alternative transports first-class support · Issue #18989 · bitcoin/bitcoin · GitHub
479 2020-05-21T19:07:48  <ariard> Okay so I've explored a bit alternative transports support
480 2020-05-21T19:08:08  <ariard> as it has been previously attempted by Matt with headers-over-radio or headers-over-DNS
481 2020-05-21T19:08:15  <wumpus> is there anything special needed at our side with regard to that?
482 2020-05-21T19:08:27  *** jarthur_ has joined #bitcoin-core-dev
483 2020-05-21T19:08:32  <ariard> well I want to assert project worthiness
484 2020-05-21T19:08:39  <wumpus> couldn't any extenal software route the P2P port over some other transport?
485 2020-05-21T19:08:40  <luke-jr> there's also Blockstream's blocks-over-satellite
486 2020-05-21T19:08:54  *** proofofkeags has joined #bitcoin-core-dev
487 2020-05-21T19:09:02  <ariard> yes but idea is to increase easiness of link layer diversity
488 2020-05-21T19:09:34  <ariard> wumpus: you may want to receive blocks on one transport like satellites and broadcast them over another medium
489 2020-05-21T19:09:49  <wumpus> while I think alternative transports are great, I don't think we should integrate the code for all the transports into bitcoin core
490 2020-05-21T19:10:05  <wumpus> I didn't read your proposal yet so I might be off
491 2020-05-21T19:10:12  <ariard> wumpus: I agree that's why my proposal is splitting drivers from fetching logic
492 2020-05-21T19:10:27  <ariard> It's just a generic driver framework
493 2020-05-21T19:10:40  <sipa> but the drivers would things you compile in?
494 2020-05-21T19:10:41  <ariard> drivers should obviously lay outside of core
495 2020-05-21T19:10:44  <sipa> or external applications?
496 2020-05-21T19:10:52  <wumpus> if it's external applications that's great
497 2020-05-21T19:10:55  <sipa> (even if not maintained in our repository)
498 2020-05-21T19:11:01  <ariard> sipa: compile in or external applications like meek or snowflake
499 2020-05-21T19:11:10  <jb55> why do we integrate tor then
500 2020-05-21T19:11:13  <ariard> yes I don't want them to be maintained in the repo
501 2020-05-21T19:11:34  <sipa> jb55: i think there is a difference between routing and non-routing transports
502 2020-05-21T19:11:34  <wumpus> jb55: historical legacy, as well as being the most popular one probably
503 2020-05-21T19:11:36  <ariard> jb55: with regards to their pluggable transports
504 2020-05-21T19:12:02  <sipa> i think the things ariard is thinking about doesn't have addresses or a way to initiate a connection to a particular peer
505 2020-05-21T19:12:05  <ariard> wumpus: it's the most popuplar one ofc, but their threat model is a bit diffrent than our
506 2020-05-21T19:12:07  <luke-jr> we don't integrate tor really
507 2020-05-21T19:12:15  <luke-jr> we just have bits to interoperate with it
508 2020-05-21T19:12:21  <ariard> sipa: yes peer policy would be left to the driver
509 2020-05-21T19:12:22  <sipa> but just a "i have a way to connect to some other node, please communicate through it"
510 2020-05-21T19:12:27  *** jarthur has quit IRC
511 2020-05-21T19:12:41  *** Guest44696 has joined #bitcoin-core-dev
512 2020-05-21T19:12:53  <wumpus> that makes sense
513 2020-05-21T19:12:57  <ariard> like if your alternative transport is a satellite, there is no that much peer
514 2020-05-21T19:13:21  <sipa> so this would be outside addrman, addr (or addrv2) messages, ...
515 2020-05-21T19:13:22  <ariard> also you may receive block from an uni-directional channel but want to broadcast tx over another one
516 2020-05-21T19:13:23  <wumpus> yes, I agree that could be facilitatd better
517 2020-05-21T19:13:26  <ariard> in reaction to this
518 2020-05-21T19:13:39  <ariard> sipa: yes not melding with addrman
519 2020-05-21T19:13:45  <wumpus> maybe through hints in a special-permissioned P2P connection
520 2020-05-21T19:13:56  <ariard> sipa: you may reuse addr messages but that's up to driver
521 2020-05-21T19:13:58  *** Guest44696 has quit IRC
522 2020-05-21T19:13:59  <luke-jr> p2p stuff needs Core-side integration ofc
523 2020-05-21T19:14:13  <luke-jr> well, maybe not
524 2020-05-21T19:14:17  <wumpus> yes, in a sense
525 2020-05-21T19:14:18  <ariard> luke-jr: may you precise ?
526 2020-05-21T19:14:31  <luke-jr> I guess they can do their own addr-equivalent messages on their own transport
527 2020-05-21T19:14:31  <sipa> i'm not sure what the best way to support such things is... on the face of it, it could all be done as an external application talking P2P
528 2020-05-21T19:14:39  <sipa> but there may be easier ways of integrating
529 2020-05-21T19:14:50  <fjahr> ariard: have users expressed interest in any specific alternative transports? which one would have the most interest in the beginning do you think?
530 2020-05-21T19:15:00  <ariard> sipa: like a supplemental daemon supporting all drivers ?
531 2020-05-21T19:15:02  <sipa> fibre-like things are harder, as they need mempool access
532 2020-05-21T19:15:07  *** jarthur_ has quit IRC
533 2020-05-21T19:15:08  <luke-jr> would be ideal to split out current p2p stuff external someday too
534 2020-05-21T19:15:11  <sipa> ariard: or one daemon per driver
535 2020-05-21T19:15:13  <wumpus> what we're not going to do: include it all into the repository, or dynamic library based plugin mechanisms
536 2020-05-21T19:15:23  <sipa> wumpus: agree
537 2020-05-21T19:15:25  *** Talkless has quit IRC
538 2020-05-21T19:15:30  <ariard> fjahr: yes some LN routing nodes operators would like block redundancy
539 2020-05-21T19:15:34  <wumpus> everything else is fine
540 2020-05-21T19:16:03  <ariard> sipa: yes you may have one daemon per driver but ideally you may react on what your learn one driver
541 2020-05-21T19:16:21  <sipa> i can't parse your sentence
542 2020-05-21T19:16:46  *** IGHOR has quit IRC
543 2020-05-21T19:16:48  <wumpus> if it runs in an external process and communicates with bitcoin core that's the right way
544 2020-05-21T19:16:56  <ariard> wumpus: yes agree doesn't make sense to include it all into the repo
545 2020-05-21T19:17:01  *** jonatack_ has joined #bitcoin-core-dev
546 2020-05-21T19:17:08  <wumpus> if it requires a little extra support on our side that's ok
547 2020-05-21T19:17:15  <jb55> for tor it just connects to a local proxy socket right? isn't this general enough?
548 2020-05-21T19:17:19  <jeremyrubin> What about making our P2P function that way wumpus?
549 2020-05-21T19:17:43  <wumpus> jb55: yes, there's a little specificsupport for incoming connections by creating a hidden service
550 2020-05-21T19:17:52  <ariard> sipa: let's say I learn I'm currently eclipsed, I send a notification to my LN daemon, LN daemon react by closing channnel and broadcast through some emergency channel
551 2020-05-21T19:17:55  <sipa> jb55: that wouldn't work for a satellite connection for example
552 2020-05-21T19:18:02  <jeremyrubin> I mean it seems like a silly suggestion but if we want fully capable alt-p2ps, then we should be able to dogfood it with our current p2p system
553 2020-05-21T19:18:12  <wumpus> jeremyrubin: in the long run maybe
554 2020-05-21T19:18:13  <sipa> jb55: as you can't route a bidirectional byte stream
555 2020-05-21T19:18:26  <jb55> sipa: satellite would require custom deserialization code as well if I understand correctly
556 2020-05-21T19:18:28  *** jonatack has quit IRC
557 2020-05-21T19:18:33  <ariard> jeremyrubin: ideally but that's too much carefull refactor
558 2020-05-21T19:18:34  <jeremyrubin> wumpus: also seems good from a security perspective -- no DMA if you pop the transit layer :)
559 2020-05-21T19:19:00  <jeremyrubin> I think ryanofsky probably has some insight here
560 2020-05-21T19:19:16  <jeremyrubin> Don't you have a seperate network process branch right now?
561 2020-05-21T19:19:25  <jeremyrubin> Or is it just wallet stuff presently
562 2020-05-21T19:19:26  <ariard> better integration with core would ease deployement therefore making the number of such alternative transport used higher
563 2020-05-21T19:19:36  <wumpus> jeremyrubin: yes, gmaxwell had some ideas in that direction as well, run the whole P2P in a sandboxed process
564 2020-05-21T19:19:38  <sipa> if one goal is supporting FIBRE in an external process... that's pretty hard; i think the reconstruction code needs low latency access to the mempool etc
565 2020-05-21T19:19:39  <ariard> and this would increase network security
566 2020-05-21T19:20:11  <ariard> sipa: fibre is so much special, not in my integration target
567 2020-05-21T19:20:16  <sipa> ariard: ok
568 2020-05-21T19:20:29  <ariard> I'm more interesred by headers-over-DNS or domain-fronting or radio integration
569 2020-05-21T19:20:35  <wumpus> let's aim lower first ...
570 2020-05-21T19:20:37  <jeremyrubin> sipa: IPC shared memeory the mempool for fibre?
571 2020-05-21T19:20:38  * jeremyrubin ducks
572 2020-05-21T19:20:39  <sipa> that's fair
573 2020-05-21T19:20:40  <wumpus> it coudl always be extended later
574 2020-05-21T19:20:50  <wumpus> to way-out ideas like that
575 2020-05-21T19:20:57  <ariard> yes I want something simple first, like headers-over-DNS
576 2020-05-21T19:20:58  <jb55> what's the simplest non-invasive use case?
577 2020-05-21T19:21:14  <sipa> ariard: headers-over-DNS could even just done with RPC, i think?
578 2020-05-21T19:21:16  <wumpus> nothgin is going to happen at all if that's a requirement for the first version though :)
579 2020-05-21T19:21:23  <sipa> (a daemon communicating through RPC)
580 2020-05-21T19:21:47  <wumpus> memmap the mempool lol :)
581 2020-05-21T19:21:54  <ariard> sipa: yes my concern is if you have to manage one daemon per alternative transport that's a bit cumbersome to deploy
582 2020-05-21T19:21:59  *** Pavlenex has quit IRC
583 2020-05-21T19:22:01  <ariard> even for power users
584 2020-05-21T19:22:22  *** IGHOR has joined #bitcoin-core-dev
585 2020-05-21T19:22:54  <ariard> I want to explore if we can integrate with multiprocess and just have another new process supporting the drivers
586 2020-05-21T19:22:56  <sipa> ariard: compared to c-lightning which is already half a dozen daemons? ;)
587 2020-05-21T19:23:36  *** IGHOR has quit IRC
588 2020-05-21T19:23:36  <ariard> sipa: I know it doesn't work well for embedded or mobile envs
589 2020-05-21T19:23:36  *** jonatack_ has quit IRC
590 2020-05-21T19:24:38  *** jonatack has joined #bitcoin-core-dev
591 2020-05-21T19:24:41  <wumpus> why not?
592 2020-05-21T19:24:57  <ariard> and I think actually blocksat is its own fork of core
593 2020-05-21T19:24:58  <wumpus> on limited 32-bit platforms it's usually better to have a zillion separate processes than threads within the same process
594 2020-05-21T19:25:28  <wumpus> e.g. at least they don't have to share an address space
595 2020-05-21T19:25:42  <ariard> well actually with my driver interface design if you want to fork() behind you can
596 2020-05-21T19:25:46  <ryanofsky> sipa/wumpus is there quick way to say what you don't like about the shared library approach? build complications? memory safety?
597 2020-05-21T19:25:53  <ariard> it's up to the driver implementation
598 2020-05-21T19:26:14  <wumpus> ryanofsky: security, limits static linking, and having to provide a binary interface
599 2020-05-21T19:26:51  <wumpus> also cross platform stuf
600 2020-05-21T19:27:07  <wumpus> dynamic libraries are slightly but different enough to make your life a pain between windows and linux
601 2020-05-21T19:27:11  <ariard> wumpus: on security/fault-tolerance that's why I think a separate process would be better
602 2020-05-21T19:27:17  <wumpus> yes, it is
603 2020-05-21T19:27:24  <ariard> contrary to Matt stuff spawning new threads
604 2020-05-21T19:27:41  <wumpus> separate processes are better for isolation/security
605 2020-05-21T19:27:41  <ariard> now what should be the threading model of such new process it's another question
606 2020-05-21T19:27:49  <ariard> wumpus: agree
607 2020-05-21T19:28:47  <ariard> but current proposal is just to have fetching/broadcast logic in this new process and talk to a driver interface
608 2020-05-21T19:29:04  <ryanofsky> ariard, i'll take a look at your prs and what the interfaces are. i'd expect they are easy just to get working across processes
609 2020-05-21T19:29:05  <ariard> fetching logic is operating over abstract driver attributes like fHeaders or fBlocks
610 2020-05-21T19:29:07  <wumpus> that's interesting, I'll read the issue more closely
611 2020-05-21T19:29:18  *** IGHOR has joined #bitcoin-core-dev
612 2020-05-21T19:29:36  <ryanofsky> the issue is just performance, it's a easier to have great performance if you aren't doing io and just accessing memory
613 2020-05-21T19:29:50  <ariard> wumpus: yes I want to rely drivers devs to write their own fetching logic for each transport
614 2020-05-21T19:29:51  <BlueMatt> ariard: i think it may be useful for you to take a look at all the rust-based drivers that I had written
615 2020-05-21T19:30:07  <BlueMatt> ariard: I think the current API design in 18988 is much too tied to certain assumptions about what the thing will look like
616 2020-05-21T19:30:20  <wumpus> bitcoin core is I/O bound but usually only on disk, not on P2P/network
617 2020-05-21T19:30:37  <ariard> BlueMatt: I know, I need to rework the threading model, but ideally your rust-based drivers should be reused
618 2020-05-21T19:30:48  <BlueMatt> ariard: I dont think the threading model is the only issue there
619 2020-05-21T19:30:53  <BlueMatt> i think it needs to be way more free-form
620 2020-05-21T19:31:15  <BlueMatt> eg the rust stuff was just exposing ProcessNewBlock(Headers) and FindNextBlocksToDownload
621 2020-05-21T19:31:20  <BlueMatt> as well as an api to get header state
622 2020-05-21T19:31:21  <ariard> BlueMatt: more asynchronous ?
623 2020-05-21T19:31:32  <BlueMatt> and leaving it up to the driver what to do with that
624 2020-05-21T19:31:41  <BlueMatt> cause drivers may have very different capabilities in terms of how to query
625 2020-05-21T19:31:52  <sipa> i guess that's a question of layering
626 2020-05-21T19:31:53  <ryanofsky> BlueMatt, is starting with an API and just changing over time hard here? it seems like a brand new API you can declare unstable
627 2020-05-21T19:32:03  <BlueMatt> eg headers-over-dns may only be able to query by block height, and its a poll, its not a file descriptor or a socket.
628 2020-05-21T19:32:13  <sipa> it does make sense to have a "i have a bidirection byte stream connection to another node... tell me what to route over it" interface
629 2020-05-21T19:32:21  <BlueMatt> ryanofsky: I'm suggesting start with less api, and add more over time :)
630 2020-05-21T19:32:22  <sipa> but it's not the right solution for everything
631 2020-05-21T19:32:37  <BlueMatt> i dont think its the right solution for...almost anything we'd want to do here?
632 2020-05-21T19:32:50  <BlueMatt> like, some of the most exciting options would be https domain fronting
633 2020-05-21T19:32:56  <BlueMatt> and its not a byte stream, its a query interface
634 2020-05-21T19:33:08  <sipa> what is https domain fronting?
635 2020-05-21T19:33:08  <ariard> yes that's why fetching logic should adapt its request to driver capabilities
636 2020-05-21T19:33:18  <ariard> like don't send GETHEADERS if it's unidirectional
637 2020-05-21T19:33:41  <ariard> sipa: https://www.bamsoftware.com/papers/fronting/
638 2020-05-21T19:33:42  <BlueMatt> sipa: where you hit commoncdn.amazon.com in SNI, but the http host header is magicbitcoinproxy.amazonuser.com
639 2020-05-21T19:33:54  <sipa> SNI?
640 2020-05-21T19:33:54  *** fearbeag has quit IRC
641 2020-05-21T19:34:10  <BlueMatt> sipa: and it routes to your domain. this is a *functional* way to connect to tor through the gfw still today, last i heard, though the common endpoint is slow
642 2020-05-21T19:34:17  <BlueMatt> sipa: ssl plaintext hostname in the connection setup
643 2020-05-21T19:34:19  <ariard> sipa: https://en.wikipedia.org/wiki/Server_Name_Indication
644 2020-05-21T19:34:32  <sipa> i'll read the link
645 2020-05-21T19:34:41  <sipa> no need to unnoob be here
646 2020-05-21T19:35:10  <BlueMatt> ariard: i dont even think 'bidirectional' is a reasonable assumption here - eg radio-based stuff is likely to be unidirectional
647 2020-05-21T19:35:16  <BlueMatt> (and could be *either* read or write)
648 2020-05-21T19:35:20  <ariard> yes censorship circumvention is a huge topic in itself, and some of Tor stuff may not fit your threat model
649 2020-05-21T19:35:33  <jnewbery> if it's possible to unnoob the rest of us in a sentence or two, that might be helpful though
650 2020-05-21T19:35:46  <ariard> BlueMatt: yes capabilities need refinement
651 2020-05-21T19:35:59  <ryanofsky> jnewbery, it's just a string passed to disambiguate when you have web servers for different domains on the same ip
652 2020-05-21T19:36:03  <jb55> jnewbery: its like the http Host header for tls connections
653 2020-05-21T19:36:23  <BlueMatt> jnewbery: tl;dr: a way to connect to a super common https endpoint (so common that any censors wont block it cause they'd break many websites) and then route your own data over it
654 2020-05-21T19:36:31  <sipa> i feel people are trying to explain minor details while i (or some) are missing the big picture
655 2020-05-21T19:36:38  <BlueMatt> think of, eg, amazon aws javascript cache
656 2020-05-21T19:36:56  *** Livestradamus has quit IRC
657 2020-05-21T19:37:05  <BlueMatt> but you magically make the censor think you're connecting to that but are in fact connecting to a bitcoin core reset endpoint
658 2020-05-21T19:37:05  <sipa> i hear "something something https bypass GFW", but not what or how that'd be used
659 2020-05-21T19:37:13  <ariard> sipa: agree there is a lot of alternative transports, integration with each of them may bring you more security/privacy
660 2020-05-21T19:37:16  *** Livestradamus has joined #bitcoin-core-dev
661 2020-05-21T19:37:28  <ariard> therefore making them easier to deploy would be great
662 2020-05-21T19:37:35  <jeremyrubin> ariard: or less as you add more too
663 2020-05-21T19:37:39  <ryanofsky> i think big picture is it's harder to censor an ip when it's an amazon ip also hosting things you're not trying to censor
664 2020-05-21T19:37:57  <sipa> ryanofsky: ok, that's helpful!
665 2020-05-21T19:38:01  <sipa> why is it unidirectional?
666 2020-05-21T19:38:04  <ariard> jeremyrubin: there is a risk of privacy leakage, it should be well-documented I agree
667 2020-05-21T19:38:24  <jnewbery> Very helpful. Thanks ryanofsky jb55 BlueMatt
668 2020-05-21T19:39:05  <ariard> domain-fronting increase cost of censorship, because now you have to harm ingenous traffic too
669 2020-05-21T19:39:16  <instagibbs> Signal uses this IIRC
670 2020-05-21T19:39:59  <jb55> could I use altnet to send a tx via carrier pidgin
671 2020-05-21T19:40:03  <BlueMatt> its been very effecive for signal, in fact
672 2020-05-21T19:40:18  <ariard> but sipa was right, we miss the bigger picture, I would be glad to explain domain-fronting or how we may incorporate it in core in a pr review club session or other
673 2020-05-21T19:40:20  <instagibbs> BlueMatt, AWS got mad at them didn't hear the result of it :P
674 2020-05-21T19:40:32  <BlueMatt> instagibbs: the result was to use azure
675 2020-05-21T19:40:35  <BlueMatt> who did not get mad
676 2020-05-21T19:40:37  <sipa> jb55: using pidgin to steganographically hide the traffic is a great idea!
677 2020-05-21T19:40:40  <instagibbs> Ahhh
678 2020-05-21T19:40:41  <BlueMatt> (yet)
679 2020-05-21T19:40:48  *** proofofkeags has quit IRC
680 2020-05-21T19:40:52  <wumpus> hehe
681 2020-05-21T19:40:54  <jb55> pigeon*
682 2020-05-21T19:41:01  <instagibbs> But indeed, seems to work inside China quite well considering
683 2020-05-21T19:41:26  <ariard> yes if we have such generic driver framework, drivers devs may just focus on improving protocol fingerprint hidding
684 2020-05-21T19:42:58  <BlueMatt> exactly. but it needs to be super flexible to support all these different crazy ideas
685 2020-05-21T19:43:11  <wumpus> but not necessarily initially, it just needs to be extendable
686 2020-05-21T19:43:17  <ariard> I invite anyone to let comment on the PR/issues and in the meanwhile I will explore more each alt-transports to see how much generic framework
687 2020-05-21T19:43:30  <ariard> and come with a cleaner design proposal
688 2020-05-21T19:43:31  <jnewbery> ariard: what do you need help with? From my perspective, there's still a lot of work to be done internally in Bitcoin Core cleaning up the layer separation between net / net_processing / validation, but I haven't reviewed your branch yet
689 2020-05-21T19:43:35  * BlueMatt notes that, after initialization, before any read()/write()s to the remote host, openssl can be run in a sanboxed processes which has no access to any syscalls except read() and write() :)
690 2020-05-21T19:44:06  <sipa> maybe it's good to make a list of potential alternative transport that are useful, and then see if there's a reasonable subset that can easily be supported
691 2020-05-21T19:44:20  <wumpus> you don't want to overdesign either, nor make such a large stack of requirements that you give up in the idea
692 2020-05-21T19:44:26  <ariard> sipa: I've been working on this the last few days, will make it public soon
693 2020-05-21T19:44:41  *** proofofkeags has joined #bitcoin-core-dev
694 2020-05-21T19:44:46  <ariard> wumpus: you don't want to overdesign, but let room in the design to step-by-step extend it
695 2020-05-21T19:44:47  <BlueMatt> jnewbery: these types of things need only very few calls into the rest of core
696 2020-05-21T19:44:53  <wumpus> ariard: yes
697 2020-05-21T19:45:03  <BlueMatt> eg you can write dns + http + radio + a full second p2p client with only these functions: https://github.com/TheBlueMatt/bitcoin/blob/d3ca09afbc38d7f73866da33948651ac2c40fd58/src/rusty/src/cpp_bridge.cpp
698 2020-05-21T19:45:04  *** ransua has joined #bitcoin-core-dev
699 2020-05-21T19:45:12  <ariard> jnewbery: the kind of changes Carl is working on to separate net_processing from validation
700 2020-05-21T19:45:21  <BlueMatt> (and that branch has all 4 written, though in rust)
701 2020-05-21T19:45:24  <wumpus> just trying to warn to not get overenthousiastic I've seen this before :)
702 2020-05-21T19:45:32  <BlueMatt> so I really dont think separating or cleaning up net_processing is at all required here
703 2020-05-21T19:45:47  <BlueMatt> in fact, I think using any parts of net_processing or even net is an anti-goal.
704 2020-05-21T19:45:47  * jeremyrubin excited for audio relay so I can fill my neighborhood with the glorious sound of decentralization
705 2020-05-21T19:45:54  <ariard> wumpus: I agree, that's kind of slow work like multiprocess is
706 2020-05-21T19:45:54  <wumpus> jeremyrubin: ROFL
707 2020-05-21T19:45:58  <BlueMatt> and validation.h is a relatively small API
708 2020-05-21T19:46:01  <ariard> I'm well aware of
709 2020-05-21T19:46:46  <wumpus> i'm stoked for neutrino relay, uncensorable by physics !
710 2020-05-21T19:46:55  <sipa> "it's faster than C!"
711 2020-05-21T19:47:02  <BlueMatt> lol
712 2020-05-21T19:47:05  <wumpus> hehe
713 2020-05-21T19:47:06  <ariard> jeremyrubin: receives block from space and pass headers-over-radio to your neighboors, be a good network citizen :)
714 2020-05-21T19:47:33  * BlueMatt is excited for cross-ocean global radio header relay
715 2020-05-21T19:47:56  <wumpus> that would be very nice
716 2020-05-21T19:47:57  <BlueMatt> cause, like, some issues with using spectrum without pissing off a bunch of hams aside, is totally practical
717 2020-05-21T19:48:00  <jeremyrubin> I'd just be worried that if we set up neutrino relay that we'd start getting extraterrestrial blocks
718 2020-05-21T19:48:11  <sipa> 800 bytes per 10 minutes is slightly higher than 1 bit per second
719 2020-05-21T19:48:17  <wumpus> jeremyrubin: win/win
720 2020-05-21T19:48:18  <sipa> i wonder how much energy you need to moonbounce that
721 2020-05-21T19:48:29  <ariard> if anyone has idea of alternarive transport pleae note them in the issue, I will inquiry to see how you can integrate
722 2020-05-21T19:48:33  <BlueMatt> sipa: ha! I was having a conversation about moonbouncing header relay like an hour ago
723 2020-05-21T19:48:47  <BlueMatt> ariard: I just have the 4 that I listed previously, all of which I think are cool.
724 2020-05-21T19:48:56  <jeremyrubin> How many TXs can we fit in the latency between here and the moon?
725 2020-05-21T19:49:03  *** proofofkeags has quit IRC
726 2020-05-21T19:49:06  <BlueMatt> (and sufficiently variable in the features they offer that they are a good test case)
727 2020-05-21T19:49:06  <jeremyrubin> MoonMemPoolTapeDeck
728 2020-05-21T19:49:15  *** proofofkeags has joined #bitcoin-core-dev
729 2020-05-21T19:49:17  <ariard> BlueMatt: cooool will go through this whole conv again to bookmark
730 2020-05-21T19:49:44  <ariard> oh in fact i've already you branch bookmarked :) the doc starter is nice
731 2020-05-21T19:49:44  <BlueMatt> ariard: also take a look at the fn list at https://github.com/TheBlueMatt/bitcoin/blob/d3ca09afbc38d7f73866da33948651ac2c40fd58/src/rusty/src/cpp_bridge.cpp or the actual api at https://github.com/TheBlueMatt/bitcoin/blob/d3ca09afbc38d7f73866da33948651ac2c40fd58/src/rusty/src/bridge.rs
732 2020-05-21T19:50:11  <BlueMatt> thats the api that I was exposing to all 4 clients in rust, and was pretty easy to write again. its not a class-based thing, just a bag of functions, though, so not quite what you're going for.
733 2020-05-21T19:50:43  <ariard> okay I've had a different concern, if such stuff get wider deployement we may have side-effect on the network topology
734 2020-05-21T19:50:44  <BlueMatt> in other news, these things are back in stock, and can be used to pick up headers most places in new york city: https://unsigned.io/product/rnode/
735 2020-05-21T19:50:57  <ariard> anyone has opinion on this ?
736 2020-05-21T19:51:16  <BlueMatt> ariard: as long as its purely additive, who cares! :)
737 2020-05-21T19:51:16  <ariard> and such side-effect may not be desirable
738 2020-05-21T19:51:30  <jonatack> ariard: at the risk of stating the obvious (but that is often forgotten in the excitement): restrict scope inititally to the smallest possible, minimum viable thing, that can be reviewed and that people can/will actually use on a small scale but eagerly
739 2020-05-21T19:51:31  <ariard> BlueMatt: right if everything is opt-in I think that's okay
740 2020-05-21T19:51:53  <jeremyrubin> I don't think it's addititive
741 2020-05-21T19:51:57  <BlueMatt> (one of the key observations made previously is that these types of relays can be bucketed into a few categories: a) privacy preserving ones, often which only provide headers due to bandwidth constraints, and b) not that...)
742 2020-05-21T19:51:59  <ariard> jonatack: I know review process and getting the first chunks PRs are the hardest steps :)
743 2020-05-21T19:52:03  <jeremyrubin> This increases partitionability
744 2020-05-21T19:52:21  <jeremyrubin> but increases availability I think?
745 2020-05-21T19:52:22  <BlueMatt> in such cases, we can use (a)-category sources to detect when there are blocks we dont have, and turn on the non-privacy-preserving modes in such cases
746 2020-05-21T19:52:36  <BlueMatt> but maybe only after having the regular p2p code make some new connections
747 2020-05-21T19:52:45  <ariard> BlueMatt: exactly that's kind of the idea of having a watchdog for this
748 2020-05-21T19:52:58  <BlueMatt> you dont need anything fancy to do that, though
749 2020-05-21T19:53:04  <BlueMatt> only a sleep(300) :)
750 2020-05-21T19:53:13  <ariard> that's hacky
751 2020-05-21T19:53:16  <BlueMatt> no its not
752 2020-05-21T19:53:24  <BlueMatt> its actually exactly what you want here
753 2020-05-21T19:53:35  <sipa> wth are you guys talking about
754 2020-05-21T19:53:38  *** FoxTrote has joined #bitcoin-core-dev
755 2020-05-21T19:53:38  <BlueMatt> give net_processing a chance to figure out how to fetch the block if we're missing one
756 2020-05-21T19:53:47  <ariard> BlueMatt: don't use a privacy-harming communication channel if you don't have to
757 2020-05-21T19:53:51  <BlueMatt> and if it fails to within 5 minutes, turn on the http client and give up privacy for the block data
758 2020-05-21T19:54:00  <BlueMatt> right, exactly, thats why you sleep(300) :)
759 2020-05-21T19:54:17  <wumpus> ~5 minutes to go
760 2020-05-21T19:54:19  <jnewbery> I agree with sipa
761 2020-05-21T19:54:24  <BlueMatt> sipa: if, eg, you learn a header over radio, but that source doesnt provide blocks, what do you do?
762 2020-05-21T19:54:36  <BlueMatt> oh, wait, is this still a meeting? lol I'll shut up.
763 2020-05-21T19:54:47  <jnewbery> perhaps this more speculative discussion is better suited to bitcoin-wizards or similar?
764 2020-05-21T19:54:49  <ariard> BlueMatt: but no, you may start to be eclipsed after IBD and due to block variance sleep doesn't make sense IMO :p
765 2020-05-21T19:54:51  <sipa> sleep(300) till the end of the meeting
766 2020-05-21T19:55:04  <wumpus> jnewbery: yes, though we don't have any other topics queued for today
767 2020-05-21T19:55:39  <ariard> jnewbery: agree again I invite people to pursue discussion on the issue or PR, it's better suited
768 2020-05-21T19:55:43  <sipa> BlueMatt: i don't know, why would you do anything?
769 2020-05-21T19:56:24  <sipa> i feel like i'm missing a lot of context
770 2020-05-21T19:56:26  *** promag has joined #bitcoin-core-dev
771 2020-05-21T19:56:58  <wumpus> anyhow I agree with jonatack: restrict scope initially, don't try to do too many out-there things at once
772 2020-05-21T19:57:25  <wumpus> though it's good that you're clearly having a lot of ideas
773 2020-05-21T19:57:28  <ariard> sipa: yes I will try to come with some Q&A-style of doc to inform people better
774 2020-05-21T19:57:40  <wumpus> but some of us hardly follow :)
775 2020-05-21T19:57:44  <BlueMatt> ariard: no thats my point - you learn absolutely that there is probably something amiss if you have headers for which you do not have a block, and several of these things are fine from a privacy perspective to learn that. in that case, it makes sense for net_processing to go make some new connections and see if it cant find the block. if it fails to after some time, go query cloudflare.deanonymizingseed.com cause, like, its better
776 2020-05-21T19:57:44  <BlueMatt> than not getting the block (at least if you're a ln user or so and have it configured to do this), but you first want to give net_processing a chance here. so, essentially, sleep(300) is exactly what you want :)
777 2020-05-21T19:58:16  <ariard> wumpus: thanks, I want to spend more time scoping to the minimal step but yet extendable after
778 2020-05-21T19:58:42  <BlueMatt> wumpus: lol, sorry...I wrote out all 4 of the (headers-over-dns, headers-over-radio, blocks-over-http, secondary-p2p-client) things before, so apologies we're a bit three-steps-ahead here :/
779 2020-05-21T19:59:38  <BlueMatt> this all was, in fact, the rust branches.
780 2020-05-21T20:00:01  *** jarthur has joined #bitcoin-core-dev
781 2020-05-21T20:00:05  <wumpus> BlueMatt: yes, I know, it was great! unfortuantely the approach to integrate them into bitcoin core didn't work with regard to review and organizationaly
782 2020-05-21T20:00:05  <ariard> BlueMatt: okay I see your point, but you need to dissociate cleanly 1) anomalies detection and 2) reaction
783 2020-05-21T20:00:14  <ariard> reaction may happen through net_processing or alt-transports
784 2020-05-21T20:00:20  <BlueMatt> wullon5: yea, no, not complaining, just providing historical context for folks
785 2020-05-21T20:00:22  <BlueMatt> wumpus:
786 2020-05-21T20:00:50  *** promag has quit IRC
787 2020-05-21T20:00:54  <BlueMatt> ariard: right, kinda, but I think part of my goal at least here is that there should be an absolute minmal amount of common code between the various sources
788 2020-05-21T20:01:06  <wumpus> wrapping up the meeting
789 2020-05-21T20:01:14  <wumpus> thanks everyone for the lively discussion
790 2020-05-21T20:01:22  <ariard> BlueMatt: ideally yes but I fear our internal components aren't that much clean yet
791 2020-05-21T20:01:29  <BlueMatt> ariard: cause if there's a bug in anomoly-detection (which we've had 20 issues with in the past, turns out its hard to get right), then all of a sudden your 5 block sources are all stuck, instead of providing the redundancy they're there for.
792 2020-05-21T20:01:41  <wumpus> #endmeeting
793 2020-05-21T20:01:41  <lightningbot> Meeting ended Thu May 21 20:01:41 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
794 2020-05-21T20:01:41  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-05-21-19.01.html
795 2020-05-21T20:01:41  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-05-21-19.01.txt
796 2020-05-21T20:01:41  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-05-21-19.01.log.html
797 2020-05-21T20:01:54  <sipa> BlueMatt: i think that depends on the goal; for some transports i think it's easier to have a "i can relay bytes/messages back and forth for bitcoind, but i don't want to care about all the protocol details like blocks and transactions and addresses"
798 2020-05-21T20:02:12  <sipa> it's additional complexity for the transport to need to care about these things
799 2020-05-21T20:02:40  <ariard> BlueMatt: I spent some times thinking about anomaly detection, there is clearly a tradeoff between false positive and complexity
800 2020-05-21T20:03:06  <ariard> and even worst, you may want to fine-tune depending of your second-layer timelocks...
801 2020-05-21T20:03:56  <BlueMatt> ariard: right! sleep(300) is bulletproof. detecting slow chain progress is....not :)
802 2020-05-21T20:04:23  <sipa> BlueMatt: by "sleep(300)" you actually mean "a fixed time-out" right, not an actual sleep in the code
803 2020-05-21T20:04:31  <BlueMatt> sipa: right, sure lol
804 2020-05-21T20:05:07  <BlueMatt> sipa: as for "the goal", thats true, if we want to model after eg tor's pluggable transport, we want a byte stream, but I think bitcoin data is a little too unique for that - because its so small, we end up being able to shove it in all kinds of queries
805 2020-05-21T20:05:22  <BlueMatt> and we probaby often want it to be unidirectional
806 2020-05-21T20:05:49  <sipa> BlueMatt: i just think there are distinct goals, and doing both right means doing things at a different layer
807 2020-05-21T20:07:07  <BlueMatt> right, fair. i guess just in my past thinking on this I've always considered mostly more nice bitcoin data providers, less p2p-encryption/modoulation-style providers. I agree that would be a cool goal as well, though i guess is fully separate from things I was thinking about
808 2020-05-21T20:07:18  <sipa> one is a transport that deals with concepts like blocks and transactions, and probably plugs in at the validation layer directly
809 2020-05-21T20:08:06  <sipa> another is just connecting bitcoinds, which is more like routing P2P traffic directly (and may even be dealt with as a "peer" from the net perspective, subject to throtting/banning if better DoS protection are added)
810 2020-05-21T20:08:34  <BlueMatt> right.
811 2020-05-21T20:10:21  <ariard> sipa: but it's a layer question, 1) may rely on 2) once serialization is done?
812 2020-05-21T20:11:22  <sipa> ariard: i don't know what you mean
813 2020-05-21T20:11:50  <BlueMatt> ariard: maybe, but (1) provides you ability to get data from things that arent bidirectional high-bandwidth sockets. (2) is just a way to shove bitcoin p2p protocol over top of something else.
814 2020-05-21T20:13:34  <ariard> sipa: you may have a first layer caring about protocols details like blocks and transactions and then passing to a dumb byte stream transport
815 2020-05-21T20:14:08  <ariard> or sorry I think I don't get your distinction laid out above, if you have concrete example
816 2020-05-21T20:14:24  <BlueMatt> ariard: if you're farmiliar, (2) is tor's pluggable transport system.
817 2020-05-21T20:15:51  <BlueMatt> (which is to say, just a socks proxy that does its own encryption/scrambling, but doesn't use a different protocol inside)
818 2020-05-21T20:16:50  <ariard> BlueMatt: okay I see compare to blocksat where you do have your own serialization for compressing tx?
819 2020-05-21T20:17:12  <BlueMatt> right, and especially where you have unidirectional coms
820 2020-05-21T20:17:13  <BlueMatt> like blocksat
821 2020-05-21T20:17:30  <BlueMatt> or like headers-over-dns where you have to do strange queries (height -> header data instead of hash -> header data)
822 2020-05-21T20:19:18  <sipa> imagine we'd have had support and a nice variety of actually used protocols of the first type, before compact blocks existed
823 2020-05-21T20:19:43  <sipa> compact blocks gets invented, and now each protocol needs to invent its own way of adding support for that in its protocol
824 2020-05-21T20:20:30  <sipa> things that are just route-a-dumb-byte-stream (which isn't applicable always for sure) would just immediately get support for it without any effort
825 2020-05-21T20:21:08  <sipa> if you do things at a lower level, there may be a cost incurred to keep up with protocol development
826 2020-05-21T20:21:26  <sipa> so i really think what is appropriate where is very application specific
827 2020-05-21T20:21:41  <sipa> but interfaces may differ wildly between them
828 2020-05-21T20:23:16  <ariard> sipa: agree you may have a driver lib somewhere? I think some serialization may be reused between radio and blocksat or stuff like this?
829 2020-05-21T20:23:17  <BlueMatt> right, its a question of goals
830 2020-05-21T20:23:45  <BlueMatt> my thinking was the goal wasnt to try to just scramble the bitcoin data to make it look like noise on the wire, it was to actually have redundant codepaths (and network paths) to fetch block data
831 2020-05-21T20:24:00  <BlueMatt> which is a very different goal from only getting around port 8333 blocking
832 2020-05-21T20:24:14  <BlueMatt> ariard: those two goals have very different APIs, though.
833 2020-05-21T20:24:21  *** promag has joined #bitcoin-core-dev
834 2020-05-21T20:25:38  *** LucasNickle has joined #bitcoin-core-dev
835 2020-05-21T20:36:49  *** EagleTM has joined #bitcoin-core-dev
836 2020-05-21T20:40:43  *** jarthur has quit IRC
837 2020-05-21T20:46:12  *** kristapsk has quit IRC
838 2020-05-21T20:47:34  *** Chris_Stewart_5 has quit IRC
839 2020-05-21T20:52:09  *** kristapsk has joined #bitcoin-core-dev
840 2020-05-21T20:53:01  *** ctrlbreak_MAD has quit IRC
841 2020-05-21T20:53:26  *** ctrlbreak_MAD has joined #bitcoin-core-dev
842 2020-05-21T20:59:11  *** SiAnDoG has quit IRC
843 2020-05-21T20:59:55  *** SiAnDoG has joined #bitcoin-core-dev
844 2020-05-21T21:00:01  *** mshadle1 has quit IRC
845 2020-05-21T21:00:28  *** jeremyrubin has quit IRC
846 2020-05-21T21:01:12  *** jeremyrubin has joined #bitcoin-core-dev
847 2020-05-21T21:09:03  *** vasild has quit IRC
848 2020-05-21T21:11:43  *** vasild has joined #bitcoin-core-dev
849 2020-05-21T21:12:27  *** troygiorshev has quit IRC
850 2020-05-21T21:13:10  *** EagleTM has quit IRC
851 2020-05-21T21:13:44  *** emilengler has quit IRC
852 2020-05-21T21:22:00  *** Relis has quit IRC
853 2020-05-21T21:22:02  *** jtk has joined #bitcoin-core-dev
854 2020-05-21T21:25:34  *** Relis has joined #bitcoin-core-dev
855 2020-05-21T21:40:03  *** shesek has quit IRC
856 2020-05-21T21:43:27  *** shesek has joined #bitcoin-core-dev
857 2020-05-21T21:43:39  *** Chris_Stewart_5 has joined #bitcoin-core-dev
858 2020-05-21T21:45:30  *** marcoagner has quit IRC
859 2020-05-21T22:00:29  *** helo has joined #bitcoin-core-dev
860 2020-05-21T22:00:45  *** helo has joined #bitcoin-core-dev
861 2020-05-21T22:05:05  *** waxwing has quit IRC
862 2020-05-21T22:05:12  *** Guyver2 has quit IRC
863 2020-05-21T22:07:25  *** FoxTrote has quit IRC
864 2020-05-21T22:11:39  *** waxwing has joined #bitcoin-core-dev
865 2020-05-21T22:13:20  *** bitcoin-git has joined #bitcoin-core-dev
866 2020-05-21T22:13:20  <bitcoin-git> [bitcoin] MDrollette opened pull request #19043: torcontrol: add -tortarget config (master...tor-hidden-target) https://github.com/bitcoin/bitcoin/pull/19043
867 2020-05-21T22:13:21  *** bitcoin-git has left #bitcoin-core-dev
868 2020-05-21T22:16:09  *** shesek has quit IRC
869 2020-05-21T22:16:09  *** shesek has joined #bitcoin-core-dev
870 2020-05-21T22:17:50  *** waxwing has quit IRC
871 2020-05-21T22:17:50  *** waxwing has joined #bitcoin-core-dev
872 2020-05-21T22:22:38  *** mdunnio has quit IRC
873 2020-05-21T22:31:16  *** theStack has quit IRC
874 2020-05-21T22:33:45  *** troygiorshev has joined #bitcoin-core-dev
875 2020-05-21T22:51:01  *** bitcoin-git has joined #bitcoin-core-dev
876 2020-05-21T22:51:02  <bitcoin-git> [bitcoin] jnewbery opened pull request #19044: net processing: Add support for getcfilters (master...2020-05-cfilters) https://github.com/bitcoin/bitcoin/pull/19044
877 2020-05-21T22:51:02  *** bitcoin-git has left #bitcoin-core-dev
878 2020-05-21T22:53:10  *** justanotheruser has quit IRC
879 2020-05-21T22:53:16  *** ctrlbreak_MAD has quit IRC
880 2020-05-21T22:53:41  *** ctrlbreak_MAD has joined #bitcoin-core-dev
881 2020-05-21T22:58:35  *** bitcoin-git has joined #bitcoin-core-dev
882 2020-05-21T22:58:36  <bitcoin-git> [bitcoin] gabrieldonadel opened pull request #19045: qt: pt_BR translation adjustments (master...2020-05-qt-pt_BR-translation-adjustments) https://github.com/bitcoin/bitcoin/pull/19045
883 2020-05-21T22:58:37  *** bitcoin-git has left #bitcoin-core-dev
884 2020-05-21T23:02:53  *** dfmb_ has quit IRC
885 2020-05-21T23:09:45  *** justanotheruser has joined #bitcoin-core-dev
886 2020-05-21T23:13:45  *** proofofkeags has quit IRC
887 2020-05-21T23:15:37  *** proofofkeags has joined #bitcoin-core-dev
888 2020-05-21T23:15:39  *** proofofkeags has quit IRC
889 2020-05-21T23:15:56  *** proofofkeags has joined #bitcoin-core-dev
890 2020-05-21T23:18:10  *** Dean_Guss has joined #bitcoin-core-dev
891 2020-05-21T23:19:23  *** DeanWeen has quit IRC
892 2020-05-21T23:20:14  *** owowo has quit IRC
893 2020-05-21T23:22:15  *** ironhelix has quit IRC
894 2020-05-21T23:25:02  *** bitcoin-git has joined #bitcoin-core-dev
895 2020-05-21T23:25:02  <bitcoin-git> [bitcoin] fanquake closed pull request #19045: qt: pt_BR translation adjustments (master...2020-05-qt-pt_BR-translation-adjustments) https://github.com/bitcoin/bitcoin/pull/19045
896 2020-05-21T23:25:03  *** bitcoin-git has left #bitcoin-core-dev
897 2020-05-21T23:25:07  *** owowo has joined #bitcoin-core-dev
898 2020-05-21T23:25:07  *** owowo has joined #bitcoin-core-dev
899 2020-05-21T23:33:05  *** promag has quit IRC
900 2020-05-21T23:33:44  *** promag has joined #bitcoin-core-dev
901 2020-05-21T23:38:16  *** promag has quit IRC
902 2020-05-21T23:42:09  *** AaronvanW has quit IRC
903 2020-05-21T23:46:01  *** dfmb_ has joined #bitcoin-core-dev
904 2020-05-21T23:49:18  *** proofofkeags has quit IRC
905 2020-05-21T23:52:28  *** bitcoin-git has joined #bitcoin-core-dev
906 2020-05-21T23:52:30  <bitcoin-git> [bitcoin] fanquake pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/9abed46871a7...ad3a61c5f5c9
907 2020-05-21T23:52:31  <bitcoin-git> bitcoin/master d160069 gzhao408: [wallet] remove nLastResend logic
908 2020-05-21T23:52:31  <bitcoin-git> bitcoin/master a7ebe48 gzhao408: [rpc] add unbroadcast info to mempool entries and getmempoolinfo
909 2020-05-21T23:52:32  <bitcoin-git> bitcoin/master 9d3f7eb gzhao408: [mempool] sanity check that all unbroadcast txns are in mempool
910 2020-05-21T23:52:34  *** bitcoin-git has left #bitcoin-core-dev
911 2020-05-21T23:52:49  *** bitcoin-git has joined #bitcoin-core-dev
912 2020-05-21T23:52:49  <bitcoin-git> [bitcoin] fanquake merged pull request #18895: p2p: unbroadcast followups: rpcs, nLastResend, mempool sanity check (master...unbroadcast-followup) https://github.com/bitcoin/bitcoin/pull/18895
913 2020-05-21T23:52:50  *** bitcoin-git has left #bitcoin-core-dev