12020-05-21T00:00:02  *** mreider has quit IRC
  22020-05-21T00:15:10  *** baldur has quit IRC
  32020-05-21T00:15:54  <luke-jr> promag: that's something UniValue handles, not us
  42020-05-21T00:16:21  <luke-jr> not to mention rounding other things at 6 places would be bad
  52020-05-21T00:16:54  <promag> im just suggesting rounding this one
  62020-05-21T00:18:20  <luke-jr> I'm pointing out that isn't something practical
  72020-05-21T00:18:49  <promag> why not?
  82020-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
  92020-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)
 102020-05-21T00:21:12  <sipa> though i don't think it's particularly interesting to add code for that here
 112020-05-21T00:22:03  *** Tobbi has joined #bitcoin-core-dev
 122020-05-21T00:24:12  <luke-jr> sipa: per-Number? :o
 132020-05-21T00:24:39  <sipa> UniValue::setNumStr(const std::string& val)
 142020-05-21T00:24:43  <luke-jr> hmm
 152020-05-21T00:25:08  <luke-jr> promag: also, look at your example value
 162020-05-21T00:25:16  <luke-jr> 1.882374845250915e-09
 172020-05-21T00:25:20  <promag> I just think exp notation or so many decimal places is not that humah friendly
 182020-05-21T00:25:27  <luke-jr> that would round to 0
 192020-05-21T00:25:28  <promag> that oyld be 0
 202020-05-21T00:25:34  <promag> right X)
 212020-05-21T00:25:42  <luke-jr> that isn't accurate :P
 222020-05-21T00:26:03  <sipa> promag: well, it's JSON
 232020-05-21T00:26:18  <sipa> JSON happens to use exponential notation for this
 242020-05-21T00:28:07  *** baldur has joined #bitcoin-core-dev
 252020-05-21T00:30:12  *** proofofkeags has quit IRC
 262020-05-21T00:48:32  *** promag has quit IRC
 272020-05-21T00:54:15  *** AaronvanW has quit IRC
 282020-05-21T01:13:02  *** Victor_sueca has quit IRC
 292020-05-21T01:25:35  *** tryphe_ has quit IRC
 302020-05-21T01:25:48  *** AaronvanW has joined #bitcoin-core-dev
 312020-05-21T01:26:06  *** tryphe has joined #bitcoin-core-dev
 322020-05-21T01:26:16  *** proofofkeags has joined #bitcoin-core-dev
 332020-05-21T01:26:41  *** momo27 has joined #bitcoin-core-dev
 342020-05-21T01:32:09  *** momo27 has quit IRC
 352020-05-21T01:58:41  *** belcher has quit IRC
 362020-05-21T02:15:49  *** nanotube has quit IRC
 372020-05-21T02:22:16  *** Victorsueca has joined #bitcoin-core-dev
 382020-05-21T02:26:29  *** Victor_sueca has joined #bitcoin-core-dev
 392020-05-21T02:28:10  *** Victorsueca has quit IRC
 402020-05-21T02:30:49  *** AaronvanW has quit IRC
 412020-05-21T02:43:03  *** bitdex has quit IRC
 422020-05-21T02:43:27  *** bitdex has joined #bitcoin-core-dev
 432020-05-21T02:50:05  *** ironhelix has quit IRC
 442020-05-21T02:57:27  *** surja795 has quit IRC
 452020-05-21T02:58:10  *** AaronvanW has joined #bitcoin-core-dev
 462020-05-21T02:59:32  *** nanotube has joined #bitcoin-core-dev
 472020-05-21T02:59:46  *** surja795 has joined #bitcoin-core-dev
 482020-05-21T03:00:01  *** Tobbi has quit IRC
 492020-05-21T03:04:10  *** surja795 has quit IRC
 502020-05-21T03:13:41  *** PaulTroon has joined #bitcoin-core-dev
 512020-05-21T03:17:37  *** AaronvanW has quit IRC
 522020-05-21T03:19:06  *** PaulTroon has quit IRC
 532020-05-21T03:20:56  *** CCoent has joined #bitcoin-core-dev
 542020-05-21T03:21:26  *** altoid has joined #bitcoin-core-dev
 552020-05-21T03:24:15  *** CCoent has quit IRC
 562020-05-21T03:28:53  *** justanotheruser has quit IRC
 572020-05-21T03:31:56  *** proofofkeags has quit IRC
 582020-05-21T03:39:28  *** AaronvanW has joined #bitcoin-core-dev
 592020-05-21T03:41:13  *** justanotheruser has joined #bitcoin-core-dev
 602020-05-21T03:44:17  *** AaronvanW has quit IRC
 612020-05-21T03:54:36  *** ironhelix has joined #bitcoin-core-dev
 622020-05-21T04:11:13  *** Highway61 has quit IRC
 632020-05-21T04:20:03  *** vasild_ has joined #bitcoin-core-dev
 642020-05-21T04:23:03  *** vasild has quit IRC
 652020-05-21T04:23:04  *** vasild_ is now known as vasild
 662020-05-21T04:46:11  *** Talkless has joined #bitcoin-core-dev
 672020-05-21T05:13:42  *** berndj has quit IRC
 682020-05-21T05:24:28  *** berndj has joined #bitcoin-core-dev
 692020-05-21T05:29:57  *** jarthur has quit IRC
 702020-05-21T05:34:22  *** jonatack has joined #bitcoin-core-dev
 712020-05-21T05:41:03  *** jarthur has joined #bitcoin-core-dev
 722020-05-21T05:46:17  *** jarthur has quit IRC
 732020-05-21T05:52:23  *** jonatack has quit IRC
 742020-05-21T05:57:31  *** jonatack has joined #bitcoin-core-dev
 752020-05-21T06:00:01  *** altoid has quit IRC
 762020-05-21T06:12:46  *** jarthur has joined #bitcoin-core-dev
 772020-05-21T06:14:37  *** jonatack has quit IRC
 782020-05-21T06:17:47  *** jarthur has quit IRC
 792020-05-21T06:19:19  *** ironhelix has quit IRC
 802020-05-21T06:20:59  *** Smaczny has joined #bitcoin-core-dev
 812020-05-21T06:47:32  *** jonatack has joined #bitcoin-core-dev
 822020-05-21T06:53:47  *** jarthur has joined #bitcoin-core-dev
 832020-05-21T06:58:37  *** jarthur has quit IRC
 842020-05-21T07:02:23  *** marcoagner has joined #bitcoin-core-dev
 852020-05-21T07:06:51  *** Pavlenex has joined #bitcoin-core-dev
 862020-05-21T07:09:41  *** jonatack has quit IRC
 872020-05-21T07:10:26  *** jonatack has joined #bitcoin-core-dev
 882020-05-21T07:10:28  *** bitcoin-git has joined #bitcoin-core-dev
 892020-05-21T07:10:29  <bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/3eda7ea9ba72...17df15efb546
 902020-05-21T07:10:30  <bitcoin-git> bitcoin/master 85f4a4b Carl Dong: guix: Make V=1 more powerful for debugging
 912020-05-21T07:10:31  <bitcoin-git> bitcoin/master f852761 Carl Dong: guix: Add clarifying documentation for V env var
 922020-05-21T07:10:32  <bitcoin-git> bitcoin/master 17df15e fanquake: Merge #18958: guix: Make V=1 more powerful for debugging
 932020-05-21T07:10:33  *** bitcoin-git has left #bitcoin-core-dev
 942020-05-21T07:10:48  *** bitcoin-git has joined #bitcoin-core-dev
 952020-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
 962020-05-21T07:10:49  *** bitcoin-git has left #bitcoin-core-dev
 972020-05-21T07:10:52  *** harrigan has quit IRC
 982020-05-21T07:12:32  *** harrigan has joined #bitcoin-core-dev
 992020-05-21T07:15:02  *** PaulTroon has joined #bitcoin-core-dev
1002020-05-21T07:20:00  *** PaulTroon has quit IRC
1012020-05-21T07:20:21  *** Guyver2 has joined #bitcoin-core-dev
1022020-05-21T07:26:10  <vasild> CI seems to be not starting on #19031 for 10ish hours. How do I kick it to start?
1032020-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
1042020-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?
1052020-05-21T07:28:14  <sipa> yeah, that may cause it
1062020-05-21T07:28:17  <sipa> just push again
1072020-05-21T07:28:24  <fanquake> Looks like it did run
1082020-05-21T07:28:26  <fanquake> https://travis-ci.org/github/bitcoin/bitcoin/builds/689316499
1092020-05-21T07:28:36  <fanquake> Results may have just not made it back  to GH  for some reason
1102020-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?
1112020-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
1122020-05-21T07:29:00  <elichai2> just like here: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L302
1132020-05-21T07:29:34  <fanquake> vasild: I can restart it, but  looks like you'll want to browse those logs
1142020-05-21T07:30:13  * vasild looking...
1152020-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)
1162020-05-21T07:34:52  <fanquake> vasild: ok. I'll restart that build and see what happens,  and if it re-connects to GH
1172020-05-21T07:35:00  *** bitcoin-git has joined #bitcoin-core-dev
1182020-05-21T07:35:01  <bitcoin-git> [bitcoin] fanquake pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/17df15efb546...97b21b302a11
1192020-05-21T07:35:02  <bitcoin-git> bitcoin/master 5d1377b Russell Yanofsky: build: multiprocess autotools changes
1202020-05-21T07:35:03  <bitcoin-git> bitcoin/master 603fd6a Russell Yanofsky: depends: add MULTIPROCESS depends option
1212020-05-21T07:35:04  <bitcoin-git> bitcoin/master e2bab2a Russell Yanofsky: multiprocess: add multiprocess travis configuration
1222020-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
1232020-05-21T07:35:05  *** bitcoin-git has left #bitcoin-core-dev
1242020-05-21T07:35:30  *** bitcoin-git has joined #bitcoin-core-dev
1252020-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
1262020-05-21T07:35:31  *** bitcoin-git has left #bitcoin-core-dev
1272020-05-21T07:37:08  <fanquake> vasild: ah I think I see the issue
1282020-05-21T07:37:22  <fanquake> "GitHub payload is missing a merge commit (mergeable_state: "dirty", merged: false)"
1292020-05-21T07:37:42  <fanquake> If you look here: https://travis-ci.org/github/bitcoin/bitcoin/requests, that was the status for your branch
1302020-05-21T07:38:05  <vasild> hmm, what does that mean?
1312020-05-21T07:38:45  <fanquake> Maybe GHs API being a bit broken
1322020-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
1332020-05-21T07:42:09  <vasild> https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/common-build-problems.md
1342020-05-21T07:42:24  <vasild> "GitHub payload is missing a merge commit", please confirm your pull request is open and mergeable.
1352020-05-21T07:43:06  *** bitcoin-git has joined #bitcoin-core-dev
1362020-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
1372020-05-21T07:43:08  *** bitcoin-git has left #bitcoin-core-dev
1382020-05-21T07:43:09  <vasild> it wasn't mergeable
1392020-05-21T07:43:15  <fanquake> Maybe it got caught out somehow between the two forces pushes
1402020-05-21T07:43:34  <fanquake> You should probably just push again for good measure
1412020-05-21T07:44:13  <vasild> yes, I will (needlessly) rebase now and push again
1422020-05-21T07:44:29  <vasild> hopefully nobody started reviewing yet :)
1432020-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.
1442020-05-21T07:47:56  *** hebasto has quit IRC
1452020-05-21T07:48:08  <vasild> And maybe the second push which rebased on latest master (resovling conflicts) was missed because it came too soon.
1462020-05-21T07:48:48  <vasild> pushed
1472020-05-21T07:49:02  <fanquake> Looks like it good now
1482020-05-21T07:50:05  <vasild> yes, thanks!
1492020-05-21T07:50:29  *** hebasto has joined #bitcoin-core-dev
1502020-05-21T07:58:07  *** jonatack has quit IRC
1512020-05-21T07:59:14  *** jonatack has joined #bitcoin-core-dev
1522020-05-21T08:04:11  *** AaronvanW has joined #bitcoin-core-dev
1532020-05-21T08:12:04  *** DeanWeen has joined #bitcoin-core-dev
1542020-05-21T08:14:23  *** Dean_Guss has quit IRC
1552020-05-21T08:28:24  *** promag has joined #bitcoin-core-dev
1562020-05-21T08:40:46  *** emilengler has joined #bitcoin-core-dev
1572020-05-21T08:53:54  *** jonatack_ has joined #bitcoin-core-dev
1582020-05-21T08:56:34  *** Talkless has quit IRC
1592020-05-21T08:57:04  *** jonatack has quit IRC
1602020-05-21T08:57:56  *** Talkless has joined #bitcoin-core-dev
1612020-05-21T09:00:02  *** Smaczny has quit IRC
1622020-05-21T09:02:31  *** jonatack_ has quit IRC
1632020-05-21T09:02:54  *** jonatack has joined #bitcoin-core-dev
1642020-05-21T09:03:43  *** AaronvanW has quit IRC
1652020-05-21T09:05:23  *** Pavlenex has quit IRC
1662020-05-21T09:10:25  *** timothy has joined #bitcoin-core-dev
1672020-05-21T09:16:39  *** PaulTroon has joined #bitcoin-core-dev
1682020-05-21T09:17:58  *** dfmb_ has joined #bitcoin-core-dev
1692020-05-21T09:20:13  *** Dieterbe has joined #bitcoin-core-dev
1702020-05-21T09:21:10  *** Emcy has quit IRC
1712020-05-21T09:21:13  *** PaulTroon has quit IRC
1722020-05-21T09:24:41  *** Emcy has joined #bitcoin-core-dev
1732020-05-21T09:32:52  *** Talkless has quit IRC
1742020-05-21T09:33:52  *** Talkless has joined #bitcoin-core-dev
1752020-05-21T09:34:44  *** AaronvanW has joined #bitcoin-core-dev
1762020-05-21T09:51:15  *** filchef has joined #bitcoin-core-dev
1772020-05-21T10:03:27  *** Ferne24Gaylord has joined #bitcoin-core-dev
1782020-05-21T10:04:25  *** kristapsk has quit IRC
1792020-05-21T10:04:56  *** kristapsk has joined #bitcoin-core-dev
1802020-05-21T10:15:32  *** yojoots has joined #bitcoin-core-dev
1812020-05-21T10:16:17  *** Pavlenex has joined #bitcoin-core-dev
1822020-05-21T10:16:54  *** surja795 has joined #bitcoin-core-dev
1832020-05-21T10:28:56  *** Ferne24Gaylord has quit IRC
1842020-05-21T10:29:36  *** cnich has quit IRC
1852020-05-21T10:41:30  *** webchat__ has joined #bitcoin-core-dev
1862020-05-21T10:41:54  *** SiAnDoG_ has quit IRC
1872020-05-21T10:51:14  *** gio98 has joined #bitcoin-core-dev
1882020-05-21T10:56:01  *** bitcoin-git has joined #bitcoin-core-dev
1892020-05-21T10:56:03  <bitcoin-git> [bitcoin] MarcoFalke pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/97b21b302a11...25ad2c623af3
1902020-05-21T10:56:04  <bitcoin-git> bitcoin/master 691c817 Russell Yanofsky: Add util::Ref class as temporary alternative for c++17 std::any
1912020-05-21T10:56:04  <bitcoin-git> bitcoin/master 6fca33b Russell Yanofsky: refactor: Pass NodeContext to RPC and REST methods through util::Ref
1922020-05-21T10:56:05  <bitcoin-git> bitcoin/master ccb5059 Russell Yanofsky: scripted-diff: Remove g_rpc_node references
1932020-05-21T10:56:07  *** bitcoin-git has left #bitcoin-core-dev
1942020-05-21T10:56:32  *** bitcoin-git has joined #bitcoin-core-dev
1952020-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
1962020-05-21T10:56:33  *** bitcoin-git has left #bitcoin-core-dev
1972020-05-21T10:58:25  *** helo has quit IRC
1982020-05-21T11:09:33  *** Talkless has quit IRC
1992020-05-21T11:10:12  *** Talkless has joined #bitcoin-core-dev
2002020-05-21T11:12:01  *** timothy has quit IRC
2012020-05-21T11:13:38  *** Pavlenex has joined #bitcoin-core-dev
2022020-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
2032020-05-21T11:16:16  <wumpus> invalid -> in valid
2042020-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
2052020-05-21T11:17:52  <wumpus> should we do a meeting today?
2062020-05-21T11:19:05  *** timothy has joined #bitcoin-core-dev
2072020-05-21T11:19:18  <wumpus> (I don't mind, but at least here it's officially a free day due to Christian holiday)
2082020-05-21T11:19:23  *** DeanWeen has quit IRC
2092020-05-21T11:19:58  *** Pavlenex has quit IRC
2102020-05-21T11:34:16  *** promag has quit IRC
2112020-05-21T11:35:26  *** gio98 has quit IRC
2122020-05-21T11:53:13  *** belcher has joined #bitcoin-core-dev
2132020-05-21T11:57:36  <fanquake> wumpus: I will be sleeping either way heh
2142020-05-21T11:58:02  *** gio98 has joined #bitcoin-core-dev
2152020-05-21T11:58:34  *** jorijn has quit IRC
2162020-05-21T11:59:47  *** jorijn has joined #bitcoin-core-dev
2172020-05-21T12:00:02  *** Dieterbe has quit IRC
2182020-05-21T12:12:20  *** gio98 has quit IRC
2192020-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".
2202020-05-21T12:14:25  <wumpus> vasild: I don't think I've ever heard that idea before, it's kind of interesting!
2212020-05-21T12:16:53  *** Highway61 has joined #bitcoin-core-dev
2222020-05-21T12:18:34  <vasild> wumpus: it would help assess how much of the modified code is covered
2232020-05-21T12:19:07  <vasild> => to write tests that cover the modifications
2242020-05-21T12:20:17  *** Stephnix has joined #bitcoin-core-dev
2252020-05-21T12:27:10  *** bitcoin-git has joined #bitcoin-core-dev
2262020-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
2272020-05-21T12:27:11  *** bitcoin-git has left #bitcoin-core-dev
2282020-05-21T12:42:11  *** troygiorshev has joined #bitcoin-core-dev
2292020-05-21T12:42:52  *** fearbeag has joined #bitcoin-core-dev
2302020-05-21T12:49:37  *** promag has joined #bitcoin-core-dev
2312020-05-21T12:51:58  *** emilengler has quit IRC
2322020-05-21T13:02:50  *** bitcoin-git has joined #bitcoin-core-dev
2332020-05-21T13:02:51  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/25ad2c623af3...cfe22a5f9e1d
2342020-05-21T13:02:51  <bitcoin-git> bitcoin/master be01449 glowang: Add test for param interaction b/w -blocksonly and -whitelistforcerelay
2352020-05-21T13:02:52  <bitcoin-git> bitcoin/master 0ea5d70 glowang: Updated comment for the condition where a transaction relay is denied
2362020-05-21T13:02:52  <bitcoin-git> bitcoin/master cfe22a5 MarcoFalke: Merge #18530: Add test for -blocksonly and -whitelistforcerelay param inte...
2372020-05-21T13:02:53  *** bitcoin-git has left #bitcoin-core-dev
2382020-05-21T13:03:20  *** bitcoin-git has joined #bitcoin-core-dev
2392020-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
2402020-05-21T13:03:22  *** bitcoin-git has left #bitcoin-core-dev
2412020-05-21T13:06:55  *** sipa has quit IRC
2422020-05-21T13:17:21  *** sipa has joined #bitcoin-core-dev
2432020-05-21T13:17:21  *** PaulTroon has joined #bitcoin-core-dev
2442020-05-21T13:21:54  *** PaulTroon has quit IRC
2452020-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?
2462020-05-21T13:31:13  *** DeanWeen has joined #bitcoin-core-dev
2472020-05-21T13:32:16  *** lucaferr has joined #bitcoin-core-dev
2482020-05-21T13:33:01  *** lucaferr has joined #bitcoin-core-dev
2492020-05-21T13:33:36  *** owowo has quit IRC
2502020-05-21T13:33:47  *** lucaferr has quit IRC
2512020-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 :)
2522020-05-21T13:41:01  *** owowo has joined #bitcoin-core-dev
2532020-05-21T13:44:43  *** mdunnio has joined #bitcoin-core-dev
2542020-05-21T13:50:30  *** d_t has joined #bitcoin-core-dev
2552020-05-21T13:53:08  <vasild> Can coveralls.io do that?
2562020-05-21T13:56:00  *** lucaferr has joined #bitcoin-core-dev
2572020-05-21T14:02:10  <MarcoFalke> [15:13] <achow101> how do I run the travis lsan build locally?
2582020-05-21T14:02:15  <MarcoFalke> See ci/Readme.md
2592020-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."
2602020-05-21T14:07:18  <MarcoFalke> vasild: DrahtBot does that, but it is not yet public
2612020-05-21T14:07:19  <jonatack> vasild: but ISTM that MarcoFalke has that already with his online coverage pages?
2622020-05-21T14:07:44  <jonatack> MarcoFalke: oh ok, not surprised
2632020-05-21T14:08:25  <MarcoFalke> Though, it is currently blocked on #[15:13] <achow101> how do I run the travis lsan build locally?
2642020-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.
2652020-05-21T14:08:41  <MarcoFalke> (wrong clipboard)
2662020-05-21T14:08:42  <vasild> I think coveralls.io can do full report on a branch and then another full report on branch+commit.
2672020-05-21T14:08:44  <MarcoFalke> #14343
2682020-05-21T14:08:47  <gribble> https://github.com/bitcoin/bitcoin/issues/14343 | coverage reports non-deterministic · Issue #14343 · bitcoin/bitcoin · GitHub
2692020-05-21T14:09:50  <MarcoFalke> You will have to do the diff manually for now
2702020-05-21T14:10:04  <jonatack> vasild: it did for my use, it wasn't c++ but it likely can, yes
2712020-05-21T14:10:08  <MarcoFalke> But I can tell DrahtBot to run on a pull to generate the raw data
2722020-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.
2732020-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).
2742020-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
2752020-05-21T14:15:08  <MarcoFalke> vasild: Nice. Let me know if you make progress :)
2762020-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
2772020-05-21T14:16:35  <MarcoFalke> That would exclude all side effects, no?
2782020-05-21T14:17:22  <vasild> hmm :/
2792020-05-21T14:17:38  *** webchat__ has quit IRC
2802020-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
2812020-05-21T14:18:00  <vasild> right
2822020-05-21T14:18:11  *** SiAnDoG has joined #bitcoin-core-dev
2832020-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
2842020-05-21T14:19:13  *** Relis has joined #bitcoin-core-dev
2852020-05-21T14:20:34  <vasild> that is my goal, yes
2862020-05-21T14:22:09  <MarcoFalke> but longer term we really need a way to automate this
2872020-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
2882020-05-21T14:23:47  *** Relis has quit IRC
2892020-05-21T14:26:25  *** Relis has joined #bitcoin-core-dev
2902020-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
2912020-05-21T14:30:17  <wumpus> what is non-deterministic about a CPU? (besides race conditions in threading)
2922020-05-21T14:30:54  *** Relis has quit IRC
2932020-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
2942020-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"?
2952020-05-21T14:32:15  <vasild> yeah, random number are easy to deal with
2962020-05-21T14:32:21  <vasild> numbers
2972020-05-21T14:32:46  <wumpus> the thing is, even if the CPU is determinstic, things such as I/O won't be
2982020-05-21T14:33:19  <wumpus> even RAM might not be 100% deterministic (regarding timing)
2992020-05-21T14:38:03  <MarcoFalke> Ok, then we also need deterministic RAM :)
3002020-05-21T14:40:05  *** Relis has joined #bitcoin-core-dev
3012020-05-21T14:43:01  <wumpus> heh
3022020-05-21T14:43:45  *** Relis has quit IRC
3032020-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?
3042020-05-21T14:50:03  *** d_t has quit IRC
3052020-05-21T14:56:04  <MarcoFalke> lucaferr: Not without modifying the rest interface. But why would you want to do that?
3062020-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...
3072020-05-21T15:00:02  *** Stephnix has quit IRC
3082020-05-21T15:00:45  *** Relis has joined #bitcoin-core-dev
3092020-05-21T15:00:51  *** bitcoin-git has joined #bitcoin-core-dev
3102020-05-21T15:00:51  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/cfe22a5f9e1d...741816936441
3112020-05-21T15:00:52  <bitcoin-git> bitcoin/master 4444dbf MarcoFalke: gui: Remove un-actionable TODO
3122020-05-21T15:00:52  <bitcoin-git> bitcoin/master 7418169 MarcoFalke: Merge #18997: gui: Remove un-actionable TODO
3132020-05-21T15:00:54  *** bitcoin-git has left #bitcoin-core-dev
3142020-05-21T15:01:06  *** Pavlenex has joined #bitcoin-core-dev
3152020-05-21T15:01:12  *** bitcoin-git has joined #bitcoin-core-dev
3162020-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
3172020-05-21T15:01:13  *** bitcoin-git has left #bitcoin-core-dev
3182020-05-21T15:02:00  *** timothy has quit IRC
3192020-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
3202020-05-21T15:02:36  <lucaferr> MarcoFalke: thanks, I'll take a look
3212020-05-21T15:07:50  <jnewbery> jonasschnelli: do you mind looking at #1896
3222020-05-21T15:07:51  <gribble> https://github.com/bitcoin/bitcoin/issues/1896 | Translation update for 0.7.1 · Issue #1896 · bitcoin/bitcoin · GitHub
3232020-05-21T15:08:02  <jnewbery> jonasschnelli: do you mind looking at #18960
3242020-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
3252020-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
3262020-05-21T15:16:12  *** timothy has joined #bitcoin-core-dev
3272020-05-21T15:18:53  *** PaulTroon has joined #bitcoin-core-dev
3282020-05-21T15:20:46  *** Relis has quit IRC
3292020-05-21T15:21:28  *** aaronmcadam has joined #bitcoin-core-dev
3302020-05-21T15:23:16  *** PaulTroon has quit IRC
3312020-05-21T15:23:30  *** PaulTroon has joined #bitcoin-core-dev
3322020-05-21T15:28:01  *** bitcoin-git has joined #bitcoin-core-dev
3332020-05-21T15:28:01  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/741816936441...99e5e21b38bc
3342020-05-21T15:28:02  <bitcoin-git> bitcoin/master fab908f MarcoFalke: test: Fix intermittent ETIMEDOUT on FreeBSD
3352020-05-21T15:28:02  <bitcoin-git> bitcoin/master 99e5e21 Wladimir J. van der Laan: Merge #19023: test: Fix intermittent ETIMEDOUT on FreeBSD
3362020-05-21T15:28:04  *** bitcoin-git has left #bitcoin-core-dev
3372020-05-21T15:28:21  *** bitcoin-git has joined #bitcoin-core-dev
3382020-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
3392020-05-21T15:28:22  *** bitcoin-git has left #bitcoin-core-dev
3402020-05-21T15:33:50  *** jarthur has joined #bitcoin-core-dev
3412020-05-21T15:35:53  *** jarthur has quit IRC
3422020-05-21T15:36:20  *** jarthur has joined #bitcoin-core-dev
3432020-05-21T15:38:37  *** mr_burdell has quit IRC
3442020-05-21T15:41:21  *** mr_burdell has joined #bitcoin-core-dev
3452020-05-21T15:41:26  *** ctrlbreak_MAD has quit IRC
3462020-05-21T15:41:53  *** ctrlbreak_MAD has joined #bitcoin-core-dev
3472020-05-21T15:42:05  *** setpill has joined #bitcoin-core-dev
3482020-05-21T15:44:40  *** bitcoin-git has joined #bitcoin-core-dev
3492020-05-21T15:44:40  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/99e5e21b38bc...fed1a9043fdf
3502020-05-21T15:44:41  <bitcoin-git> bitcoin/master fa8bbb1 MarcoFalke: net: Use C++11 member initialization in protocol
3512020-05-21T15:44:41  <bitcoin-git> bitcoin/master fed1a90 Wladimir J. van der Laan: Merge #19020: net: Use C++11 member initialization in protocol
3522020-05-21T15:44:43  *** bitcoin-git has left #bitcoin-core-dev
3532020-05-21T15:45:00  *** bitcoin-git has joined #bitcoin-core-dev
3542020-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
3552020-05-21T15:45:01  *** bitcoin-git has left #bitcoin-core-dev
3562020-05-21T15:49:23  *** jarthur has quit IRC
3572020-05-21T15:53:38  *** Pavlenex has quit IRC
3582020-05-21T15:56:27  *** justanotheruser has quit IRC
3592020-05-21T15:58:23  *** ghost43 has joined #bitcoin-core-dev
3602020-05-21T16:02:41  *** setpill has quit IRC
3612020-05-21T16:11:37  *** justanotheruser has joined #bitcoin-core-dev
3622020-05-21T16:20:16  *** vasild_ has joined #bitcoin-core-dev
3632020-05-21T16:23:23  *** vasild has quit IRC
3642020-05-21T16:23:24  *** vasild_ is now known as vasild
3652020-05-21T16:30:14  *** Relis has joined #bitcoin-core-dev
3662020-05-21T16:30:19  *** promag has quit IRC
3672020-05-21T16:34:09  *** bitcoin-git has joined #bitcoin-core-dev
3682020-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
3692020-05-21T16:34:10  *** bitcoin-git has left #bitcoin-core-dev
3702020-05-21T16:40:31  *** IGHOR has quit IRC
3712020-05-21T16:44:55  *** _Sam-- has joined #bitcoin-core-dev
3722020-05-21T16:45:36  *** theStack has joined #bitcoin-core-dev
3732020-05-21T16:47:25  *** timothy has quit IRC
3742020-05-21T16:47:34  *** IGHOR has joined #bitcoin-core-dev
3752020-05-21T16:48:13  *** proofofkeags has joined #bitcoin-core-dev
3762020-05-21T16:49:35  *** promag has joined #bitcoin-core-dev
3772020-05-21T16:59:10  *** emilengler has joined #bitcoin-core-dev
3782020-05-21T17:02:39  *** jarthur has joined #bitcoin-core-dev
3792020-05-21T17:14:04  *** Pavlenex has joined #bitcoin-core-dev
3802020-05-21T17:21:16  *** ironhelix has joined #bitcoin-core-dev
3812020-05-21T17:26:10  *** kristapsk has quit IRC
3822020-05-21T17:35:08  *** bitcoin-git has joined #bitcoin-core-dev
3832020-05-21T17:35:10  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fed1a9043fdf...4479eb04d928
3842020-05-21T17:35:10  <bitcoin-git> bitcoin/master 0187d4c John Newbery: [indexes] Add compact block filter headers cache
3852020-05-21T17:35:11  <bitcoin-git> bitcoin/master 4479eb0 Wladimir J. van der Laan: Merge #18960: indexes: Add compact block filter headers cache
3862020-05-21T17:35:13  *** bitcoin-git has left #bitcoin-core-dev
3872020-05-21T17:35:29  *** bitcoin-git has joined #bitcoin-core-dev
3882020-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
3892020-05-21T17:35:30  *** bitcoin-git has left #bitcoin-core-dev
3902020-05-21T17:45:17  *** PaulTroon has quit IRC
3912020-05-21T17:47:17  *** ctrlbreak_MAD has quit IRC
3922020-05-21T17:47:45  *** ctrlbreak_MAD has joined #bitcoin-core-dev
3932020-05-21T17:58:48  *** d_t has joined #bitcoin-core-dev
3942020-05-21T17:59:07  *** d_t has quit IRC
3952020-05-21T18:00:02  *** aaronmcadam has quit IRC
3962020-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
3972020-05-21T18:05:47  *** kristapsk has joined #bitcoin-core-dev
3982020-05-21T18:05:55  <pierre_rochard> Thank you wumpus!
3992020-05-21T18:07:37  <theStack> that's great news! i wondered recently what happened to bitcoin-acks.com
4002020-05-21T18:07:41  *** d_t has joined #bitcoin-core-dev
4012020-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)
4022020-05-21T18:11:17  <wumpus> pierre_rochard: yw, thanks for creating it in the first place!
4032020-05-21T18:12:38  <wumpus> theStack: i think it should be back up
4042020-05-21T18:14:22  *** d_t has quit IRC
4052020-05-21T18:14:25  <theStack> wumpus: ah, indeed! i just mistyped... it's without the dash, i.e. bitcoinacks.com
4062020-05-21T18:16:10  <wumpus> right the repository has a dash but the site doesn't :)
4072020-05-21T18:18:54  *** Pavlenex has joined #bitcoin-core-dev
4082020-05-21T18:22:01  *** mshadle1 has joined #bitcoin-core-dev
4092020-05-21T18:22:03  *** andrewtoth has quit IRC
4102020-05-21T18:26:12  *** proofofkeags has quit IRC
4112020-05-21T18:26:46  *** proofofkeags has joined #bitcoin-core-dev
4122020-05-21T18:28:59  *** Pavlenex has quit IRC
4132020-05-21T18:29:05  *** proofofk_ has joined #bitcoin-core-dev
4142020-05-21T18:29:11  *** proofofkeags has quit IRC
4152020-05-21T18:31:28  <luke-jr> theStack: you mean bitcoincore.org?
4162020-05-21T18:33:12  *** Pavlenex has joined #bitcoin-core-dev
4172020-05-21T18:34:06  *** proofofk_ has quit IRC
4182020-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
4192020-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
4202020-05-21T18:40:00  <jonatack> http://www.erisian.com.au/bitcoin-core-dev/log-2020-05-15.html#l-383
4212020-05-21T18:43:52  <theStack> luke-jr: yes indeed; bitcoin.org is not under the control of the core devs now i guess?
4222020-05-21T18:44:13  <achow101> theStack: it never really was
4232020-05-21T18:44:24  <theStack> wumpus: agreed that the original domain is good
4242020-05-21T18:45:51  <theStack> jonatack: great initiative! will for sure use it (and maybe in the course of that even contribute) for reviewing
4252020-05-21T18:46:51  *** promag has quit IRC
4262020-05-21T18:49:07  *** promag has joined #bitcoin-core-dev
4272020-05-21T18:50:57  *** bitcoin-git has joined #bitcoin-core-dev
4282020-05-21T18:50:57  <bitcoin-git> [bitcoin] laanwj pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/4479eb04d928...9abed46871a7
4292020-05-21T18:50:58  <bitcoin-git> bitcoin/master a8334f7 Andrew Chow: Read and write a checksum for encrypted keys
4302020-05-21T18:50:59  <bitcoin-git> bitcoin/master c9a9ddb Andrew Chow: Set fDecryptionThoroughlyChecked based on whether crypted key checksums ar...
4312020-05-21T18:50:59  <bitcoin-git> bitcoin/master d67055e Andrew Chow: Upgrade or rewrite encrypted key checksums
4322020-05-21T18:51:00  *** bitcoin-git has left #bitcoin-core-dev
4332020-05-21T18:51:56  <jonatack> the
4342020-05-21T18:52:12  *** bitcoin-git has joined #bitcoin-core-dev
4352020-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
4362020-05-21T18:52:14  *** bitcoin-git has left #bitcoin-core-dev
4372020-05-21T18:52:32  <jonatack> theStack: 👍
4382020-05-21T18:55:18  *** promag has quit IRC
4392020-05-21T18:59:09  *** ghost43 has quit IRC
4402020-05-21T19:00:05  *** d_t has joined #bitcoin-core-dev
4412020-05-21T19:01:19  <wumpus> #startmeeting
4422020-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.
4432020-05-21T19:01:19  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
4442020-05-21T19:01:22  <jnewbery> hi
4452020-05-21T19:01:23  <kanzure> hi
4462020-05-21T19:01:24  <jeremyrubin> hi
4472020-05-21T19:01:24  <wumpus> let's try...
4482020-05-21T19:01:26  <jkczyz> hi
4492020-05-21T19:01:36  <achow101> hi
4502020-05-21T19:01:42  <fjahr> hi
4512020-05-21T19:01:49  <ariard> hi
4522020-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
4532020-05-21T19:01:52  <jonatack> late night hi
4542020-05-21T19:01:52  <wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
4552020-05-21T19:01:55  *** ghost43 has joined #bitcoin-core-dev
4562020-05-21T19:02:02  <hebasto> hi
4572020-05-21T19:02:24  <elichai2> Hi
4582020-05-21T19:02:33  <wumpus> one proposed meeting topic: alternative transports support (ariard)
4592020-05-21T19:02:39  <ariard> yes!
4602020-05-21T19:02:49  <instagibbs> hi
4612020-05-21T19:02:51  <wumpus> any last minute proposals?
4622020-05-21T19:02:53  <amiti> hi
4632020-05-21T19:02:59  <meshcollider> hi
4642020-05-21T19:03:42  <wumpus> okay, let's start with high priority for review as usual
4652020-05-21T19:03:48  <wumpus> #topic High priority for review
4662020-05-21T19:03:48  <luke-jr> hi
4672020-05-21T19:03:57  <aj> hi
4682020-05-21T19:03:58  <hebasto> could #18297 be added to hi-prio?
4692020-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
4702020-05-21T19:04:05  <wumpus> https://github.com/bitcoin/bitcoin/projects/8  4 blockers, 1 bugfix, 4 chasing concept ACK
4712020-05-21T19:04:28  <wumpus> hebasto: yes
4722020-05-21T19:04:37  <hebasto> wumpus: thanks
4732020-05-21T19:05:00  <achow101> #18787 for hi prio
4742020-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
4752020-05-21T19:05:55  <wumpus> achow101: added
4762020-05-21T19:07:31  <wumpus> #topic Alternative transports support (ariard)
4772020-05-21T19:07:41  <wumpus> #18989
4782020-05-21T19:07:43  <gribble> https://github.com/bitcoin/bitcoin/issues/18989 | Towards alternative transports first-class support · Issue #18989 · bitcoin/bitcoin · GitHub
4792020-05-21T19:07:48  <ariard> Okay so I've explored a bit alternative transports support
4802020-05-21T19:08:08  <ariard> as it has been previously attempted by Matt with headers-over-radio or headers-over-DNS
4812020-05-21T19:08:15  <wumpus> is there anything special needed at our side with regard to that?
4822020-05-21T19:08:27  *** jarthur_ has joined #bitcoin-core-dev
4832020-05-21T19:08:32  <ariard> well I want to assert project worthiness
4842020-05-21T19:08:39  <wumpus> couldn't any extenal software route the P2P port over some other transport?
4852020-05-21T19:08:40  <luke-jr> there's also Blockstream's blocks-over-satellite
4862020-05-21T19:08:54  *** proofofkeags has joined #bitcoin-core-dev
4872020-05-21T19:09:02  <ariard> yes but idea is to increase easiness of link layer diversity
4882020-05-21T19:09:34  <ariard> wumpus: you may want to receive blocks on one transport like satellites and broadcast them over another medium
4892020-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
4902020-05-21T19:10:05  <wumpus> I didn't read your proposal yet so I might be off
4912020-05-21T19:10:12  <ariard> wumpus: I agree that's why my proposal is splitting drivers from fetching logic
4922020-05-21T19:10:27  <ariard> It's just a generic driver framework
4932020-05-21T19:10:40  <sipa> but the drivers would things you compile in?
4942020-05-21T19:10:41  <ariard> drivers should obviously lay outside of core
4952020-05-21T19:10:44  <sipa> or external applications?
4962020-05-21T19:10:52  <wumpus> if it's external applications that's great
4972020-05-21T19:10:55  <sipa> (even if not maintained in our repository)
4982020-05-21T19:11:01  <ariard> sipa: compile in or external applications like meek or snowflake
4992020-05-21T19:11:10  <jb55> why do we integrate tor then
5002020-05-21T19:11:13  <ariard> yes I don't want them to be maintained in the repo
5012020-05-21T19:11:34  <sipa> jb55: i think there is a difference between routing and non-routing transports
5022020-05-21T19:11:34  <wumpus> jb55: historical legacy, as well as being the most popular one probably
5032020-05-21T19:11:36  <ariard> jb55: with regards to their pluggable transports
5042020-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
5052020-05-21T19:12:05  <ariard> wumpus: it's the most popuplar one ofc, but their threat model is a bit diffrent than our
5062020-05-21T19:12:07  <luke-jr> we don't integrate tor really
5072020-05-21T19:12:15  <luke-jr> we just have bits to interoperate with it
5082020-05-21T19:12:21  <ariard> sipa: yes peer policy would be left to the driver
5092020-05-21T19:12:22  <sipa> but just a "i have a way to connect to some other node, please communicate through it"
5102020-05-21T19:12:27  *** jarthur has quit IRC
5112020-05-21T19:12:41  *** Guest44696 has joined #bitcoin-core-dev
5122020-05-21T19:12:53  <wumpus> that makes sense
5132020-05-21T19:12:57  <ariard> like if your alternative transport is a satellite, there is no that much peer
5142020-05-21T19:13:21  <sipa> so this would be outside addrman, addr (or addrv2) messages, ...
5152020-05-21T19:13:22  <ariard> also you may receive block from an uni-directional channel but want to broadcast tx over another one
5162020-05-21T19:13:23  <wumpus> yes, I agree that could be facilitatd better
5172020-05-21T19:13:26  <ariard> in reaction to this
5182020-05-21T19:13:39  <ariard> sipa: yes not melding with addrman
5192020-05-21T19:13:45  <wumpus> maybe through hints in a special-permissioned P2P connection
5202020-05-21T19:13:56  <ariard> sipa: you may reuse addr messages but that's up to driver
5212020-05-21T19:13:58  *** Guest44696 has quit IRC
5222020-05-21T19:13:59  <luke-jr> p2p stuff needs Core-side integration ofc
5232020-05-21T19:14:13  <luke-jr> well, maybe not
5242020-05-21T19:14:17  <wumpus> yes, in a sense
5252020-05-21T19:14:18  <ariard> luke-jr: may you precise ?
5262020-05-21T19:14:31  <luke-jr> I guess they can do their own addr-equivalent messages on their own transport
5272020-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
5282020-05-21T19:14:39  <sipa> but there may be easier ways of integrating
5292020-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?
5302020-05-21T19:15:00  <ariard> sipa: like a supplemental daemon supporting all drivers ?
5312020-05-21T19:15:02  <sipa> fibre-like things are harder, as they need mempool access
5322020-05-21T19:15:07  *** jarthur_ has quit IRC
5332020-05-21T19:15:08  <luke-jr> would be ideal to split out current p2p stuff external someday too
5342020-05-21T19:15:11  <sipa> ariard: or one daemon per driver
5352020-05-21T19:15:13  <wumpus> what we're not going to do: include it all into the repository, or dynamic library based plugin mechanisms
5362020-05-21T19:15:23  <sipa> wumpus: agree
5372020-05-21T19:15:25  *** Talkless has quit IRC
5382020-05-21T19:15:30  <ariard> fjahr: yes some LN routing nodes operators would like block redundancy
5392020-05-21T19:15:34  <wumpus> everything else is fine
5402020-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
5412020-05-21T19:16:21  <sipa> i can't parse your sentence
5422020-05-21T19:16:46  *** IGHOR has quit IRC
5432020-05-21T19:16:48  <wumpus> if it runs in an external process and communicates with bitcoin core that's the right way
5442020-05-21T19:16:56  <ariard> wumpus: yes agree doesn't make sense to include it all into the repo
5452020-05-21T19:17:01  *** jonatack_ has joined #bitcoin-core-dev
5462020-05-21T19:17:08  <wumpus> if it requires a little extra support on our side that's ok
5472020-05-21T19:17:15  <jb55> for tor it just connects to a local proxy socket right? isn't this general enough?
5482020-05-21T19:17:19  <jeremyrubin> What about making our P2P function that way wumpus?
5492020-05-21T19:17:43  <wumpus> jb55: yes, there's a little specificsupport for incoming connections by creating a hidden service
5502020-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
5512020-05-21T19:17:55  <sipa> jb55: that wouldn't work for a satellite connection for example
5522020-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
5532020-05-21T19:18:12  <wumpus> jeremyrubin: in the long run maybe
5542020-05-21T19:18:13  <sipa> jb55: as you can't route a bidirectional byte stream
5552020-05-21T19:18:26  <jb55> sipa: satellite would require custom deserialization code as well if I understand correctly
5562020-05-21T19:18:28  *** jonatack has quit IRC
5572020-05-21T19:18:33  <ariard> jeremyrubin: ideally but that's too much carefull refactor
5582020-05-21T19:18:34  <jeremyrubin> wumpus: also seems good from a security perspective -- no DMA if you pop the transit layer :)
5592020-05-21T19:19:00  <jeremyrubin> I think ryanofsky probably has some insight here
5602020-05-21T19:19:16  <jeremyrubin> Don't you have a seperate network process branch right now?
5612020-05-21T19:19:25  <jeremyrubin> Or is it just wallet stuff presently
5622020-05-21T19:19:26  <ariard> better integration with core would ease deployement therefore making the number of such alternative transport used higher
5632020-05-21T19:19:36  <wumpus> jeremyrubin: yes, gmaxwell had some ideas in that direction as well, run the whole P2P in a sandboxed process
5642020-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
5652020-05-21T19:19:39  <ariard> and this would increase network security
5662020-05-21T19:20:11  <ariard> sipa: fibre is so much special, not in my integration target
5672020-05-21T19:20:16  <sipa> ariard: ok
5682020-05-21T19:20:29  <ariard> I'm more interesred by headers-over-DNS or domain-fronting or radio integration
5692020-05-21T19:20:35  <wumpus> let's aim lower first ...
5702020-05-21T19:20:37  <jeremyrubin> sipa: IPC shared memeory the mempool for fibre?
5712020-05-21T19:20:38  * jeremyrubin ducks
5722020-05-21T19:20:39  <sipa> that's fair
5732020-05-21T19:20:40  <wumpus> it coudl always be extended later
5742020-05-21T19:20:50  <wumpus> to way-out ideas like that
5752020-05-21T19:20:57  <ariard> yes I want something simple first, like headers-over-DNS
5762020-05-21T19:20:58  <jb55> what's the simplest non-invasive use case?
5772020-05-21T19:21:14  <sipa> ariard: headers-over-DNS could even just done with RPC, i think?
5782020-05-21T19:21:16  <wumpus> nothgin is going to happen at all if that's a requirement for the first version though :)
5792020-05-21T19:21:23  <sipa> (a daemon communicating through RPC)
5802020-05-21T19:21:47  <wumpus> memmap the mempool lol :)
5812020-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
5822020-05-21T19:21:59  *** Pavlenex has quit IRC
5832020-05-21T19:22:01  <ariard> even for power users
5842020-05-21T19:22:22  *** IGHOR has joined #bitcoin-core-dev
5852020-05-21T19:22:54  <ariard> I want to explore if we can integrate with multiprocess and just have another new process supporting the drivers
5862020-05-21T19:22:56  <sipa> ariard: compared to c-lightning which is already half a dozen daemons? ;)
5872020-05-21T19:23:36  *** IGHOR has quit IRC
5882020-05-21T19:23:36  <ariard> sipa: I know it doesn't work well for embedded or mobile envs
5892020-05-21T19:23:36  *** jonatack_ has quit IRC
5902020-05-21T19:24:38  *** jonatack has joined #bitcoin-core-dev
5912020-05-21T19:24:41  <wumpus> why not?
5922020-05-21T19:24:57  <ariard> and I think actually blocksat is its own fork of core
5932020-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
5942020-05-21T19:25:28  <wumpus> e.g. at least they don't have to share an address space
5952020-05-21T19:25:42  <ariard> well actually with my driver interface design if you want to fork() behind you can
5962020-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?
5972020-05-21T19:25:53  <ariard> it's up to the driver implementation
5982020-05-21T19:26:14  <wumpus> ryanofsky: security, limits static linking, and having to provide a binary interface
5992020-05-21T19:26:51  <wumpus> also cross platform stuf
6002020-05-21T19:27:07  <wumpus> dynamic libraries are slightly but different enough to make your life a pain between windows and linux
6012020-05-21T19:27:11  <ariard> wumpus: on security/fault-tolerance that's why I think a separate process would be better
6022020-05-21T19:27:17  <wumpus> yes, it is
6032020-05-21T19:27:24  <ariard> contrary to Matt stuff spawning new threads
6042020-05-21T19:27:41  <wumpus> separate processes are better for isolation/security
6052020-05-21T19:27:41  <ariard> now what should be the threading model of such new process it's another question
6062020-05-21T19:27:49  <ariard> wumpus: agree
6072020-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
6082020-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
6092020-05-21T19:29:05  <ariard> fetching logic is operating over abstract driver attributes like fHeaders or fBlocks
6102020-05-21T19:29:07  <wumpus> that's interesting, I'll read the issue more closely
6112020-05-21T19:29:18  *** IGHOR has joined #bitcoin-core-dev
6122020-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
6132020-05-21T19:29:50  <ariard> wumpus: yes I want to rely drivers devs to write their own fetching logic for each transport
6142020-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
6152020-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
6162020-05-21T19:30:20  <wumpus> bitcoin core is I/O bound but usually only on disk, not on P2P/network
6172020-05-21T19:30:37  <ariard> BlueMatt: I know, I need to rework the threading model, but ideally your rust-based drivers should be reused
6182020-05-21T19:30:48  <BlueMatt> ariard: I dont think the threading model is the only issue there
6192020-05-21T19:30:53  <BlueMatt> i think it needs to be way more free-form
6202020-05-21T19:31:15  <BlueMatt> eg the rust stuff was just exposing ProcessNewBlock(Headers) and FindNextBlocksToDownload
6212020-05-21T19:31:20  <BlueMatt> as well as an api to get header state
6222020-05-21T19:31:21  <ariard> BlueMatt: more asynchronous ?
6232020-05-21T19:31:32  <BlueMatt> and leaving it up to the driver what to do with that
6242020-05-21T19:31:41  <BlueMatt> cause drivers may have very different capabilities in terms of how to query
6252020-05-21T19:31:52  <sipa> i guess that's a question of layering
6262020-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
6272020-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.
6282020-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
6292020-05-21T19:32:21  <BlueMatt> ryanofsky: I'm suggesting start with less api, and add more over time :)
6302020-05-21T19:32:22  <sipa> but it's not the right solution for everything
6312020-05-21T19:32:37  <BlueMatt> i dont think its the right solution for...almost anything we'd want to do here?
6322020-05-21T19:32:50  <BlueMatt> like, some of the most exciting options would be https domain fronting
6332020-05-21T19:32:56  <BlueMatt> and its not a byte stream, its a query interface
6342020-05-21T19:33:08  <sipa> what is https domain fronting?
6352020-05-21T19:33:08  <ariard> yes that's why fetching logic should adapt its request to driver capabilities
6362020-05-21T19:33:18  <ariard> like don't send GETHEADERS if it's unidirectional
6372020-05-21T19:33:41  <ariard> sipa: https://www.bamsoftware.com/papers/fronting/
6382020-05-21T19:33:42  <BlueMatt> sipa: where you hit commoncdn.amazon.com in SNI, but the http host header is magicbitcoinproxy.amazonuser.com
6392020-05-21T19:33:54  <sipa> SNI?
6402020-05-21T19:33:54  *** fearbeag has quit IRC
6412020-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
6422020-05-21T19:34:17  <BlueMatt> sipa: ssl plaintext hostname in the connection setup
6432020-05-21T19:34:19  <ariard> sipa: https://en.wikipedia.org/wiki/Server_Name_Indication
6442020-05-21T19:34:32  <sipa> i'll read the link
6452020-05-21T19:34:41  <sipa> no need to unnoob be here
6462020-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
6472020-05-21T19:35:16  <BlueMatt> (and could be *either* read or write)
6482020-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
6492020-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
6502020-05-21T19:35:46  <ariard> BlueMatt: yes capabilities need refinement
6512020-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
6522020-05-21T19:36:03  <jb55> jnewbery: its like the http Host header for tls connections
6532020-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
6542020-05-21T19:36:31  <sipa> i feel people are trying to explain minor details while i (or some) are missing the big picture
6552020-05-21T19:36:38  <BlueMatt> think of, eg, amazon aws javascript cache
6562020-05-21T19:36:56  *** Livestradamus has quit IRC
6572020-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
6582020-05-21T19:37:05  <sipa> i hear "something something https bypass GFW", but not what or how that'd be used
6592020-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
6602020-05-21T19:37:16  *** Livestradamus has joined #bitcoin-core-dev
6612020-05-21T19:37:28  <ariard> therefore making them easier to deploy would be great
6622020-05-21T19:37:35  <jeremyrubin> ariard: or less as you add more too
6632020-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
6642020-05-21T19:37:57  <sipa> ryanofsky: ok, that's helpful!
6652020-05-21T19:38:01  <sipa> why is it unidirectional?
6662020-05-21T19:38:04  <ariard> jeremyrubin: there is a risk of privacy leakage, it should be well-documented I agree
6672020-05-21T19:38:24  <jnewbery> Very helpful. Thanks ryanofsky jb55 BlueMatt
6682020-05-21T19:39:05  <ariard> domain-fronting increase cost of censorship, because now you have to harm ingenous traffic too
6692020-05-21T19:39:16  <instagibbs> Signal uses this IIRC
6702020-05-21T19:39:59  <jb55> could I use altnet to send a tx via carrier pidgin
6712020-05-21T19:40:03  <BlueMatt> its been very effecive for signal, in fact
6722020-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
6732020-05-21T19:40:20  <instagibbs> BlueMatt, AWS got mad at them didn't hear the result of it :P
6742020-05-21T19:40:32  <BlueMatt> instagibbs: the result was to use azure
6752020-05-21T19:40:35  <BlueMatt> who did not get mad
6762020-05-21T19:40:37  <sipa> jb55: using pidgin to steganographically hide the traffic is a great idea!
6772020-05-21T19:40:40  <instagibbs> Ahhh
6782020-05-21T19:40:41  <BlueMatt> (yet)
6792020-05-21T19:40:48  *** proofofkeags has quit IRC
6802020-05-21T19:40:52  <wumpus> hehe
6812020-05-21T19:40:54  <jb55> pigeon*
6822020-05-21T19:41:01  <instagibbs> But indeed, seems to work inside China quite well considering
6832020-05-21T19:41:26  <ariard> yes if we have such generic driver framework, drivers devs may just focus on improving protocol fingerprint hidding
6842020-05-21T19:42:58  <BlueMatt> exactly. but it needs to be super flexible to support all these different crazy ideas
6852020-05-21T19:43:11  <wumpus> but not necessarily initially, it just needs to be extendable
6862020-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
6872020-05-21T19:43:30  <ariard> and come with a cleaner design proposal
6882020-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
6892020-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() :)
6902020-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
6912020-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
6922020-05-21T19:44:26  <ariard> sipa: I've been working on this the last few days, will make it public soon
6932020-05-21T19:44:41  *** proofofkeags has joined #bitcoin-core-dev
6942020-05-21T19:44:46  <ariard> wumpus: you don't want to overdesign, but let room in the design to step-by-step extend it
6952020-05-21T19:44:47  <BlueMatt> jnewbery: these types of things need only very few calls into the rest of core
6962020-05-21T19:44:53  <wumpus> ariard: yes
6972020-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
6982020-05-21T19:45:04  *** ransua has joined #bitcoin-core-dev
6992020-05-21T19:45:12  <ariard> jnewbery: the kind of changes Carl is working on to separate net_processing from validation
7002020-05-21T19:45:21  <BlueMatt> (and that branch has all 4 written, though in rust)
7012020-05-21T19:45:24  <wumpus> just trying to warn to not get overenthousiastic I've seen this before :)
7022020-05-21T19:45:32  <BlueMatt> so I really dont think separating or cleaning up net_processing is at all required here
7032020-05-21T19:45:47  <BlueMatt> in fact, I think using any parts of net_processing or even net is an anti-goal.
7042020-05-21T19:45:47  * jeremyrubin excited for audio relay so I can fill my neighborhood with the glorious sound of decentralization
7052020-05-21T19:45:54  <ariard> wumpus: I agree, that's kind of slow work like multiprocess is
7062020-05-21T19:45:54  <wumpus> jeremyrubin: ROFL
7072020-05-21T19:45:58  <BlueMatt> and validation.h is a relatively small API
7082020-05-21T19:46:01  <ariard> I'm well aware of
7092020-05-21T19:46:46  <wumpus> i'm stoked for neutrino relay, uncensorable by physics !
7102020-05-21T19:46:55  <sipa> "it's faster than C!"
7112020-05-21T19:47:02  <BlueMatt> lol
7122020-05-21T19:47:05  <wumpus> hehe
7132020-05-21T19:47:06  <ariard> jeremyrubin: receives block from space and pass headers-over-radio to your neighboors, be a good network citizen :)
7142020-05-21T19:47:33  * BlueMatt is excited for cross-ocean global radio header relay
7152020-05-21T19:47:56  <wumpus> that would be very nice
7162020-05-21T19:47:57  <BlueMatt> cause, like, some issues with using spectrum without pissing off a bunch of hams aside, is totally practical
7172020-05-21T19:48:00  <jeremyrubin> I'd just be worried that if we set up neutrino relay that we'd start getting extraterrestrial blocks
7182020-05-21T19:48:11  <sipa> 800 bytes per 10 minutes is slightly higher than 1 bit per second
7192020-05-21T19:48:17  <wumpus> jeremyrubin: win/win
7202020-05-21T19:48:18  <sipa> i wonder how much energy you need to moonbounce that
7212020-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
7222020-05-21T19:48:33  <BlueMatt> sipa: ha! I was having a conversation about moonbouncing header relay like an hour ago
7232020-05-21T19:48:47  <BlueMatt> ariard: I just have the 4 that I listed previously, all of which I think are cool.
7242020-05-21T19:48:56  <jeremyrubin> How many TXs can we fit in the latency between here and the moon?
7252020-05-21T19:49:03  *** proofofkeags has quit IRC
7262020-05-21T19:49:06  <BlueMatt> (and sufficiently variable in the features they offer that they are a good test case)
7272020-05-21T19:49:06  <jeremyrubin> MoonMemPoolTapeDeck
7282020-05-21T19:49:15  *** proofofkeags has joined #bitcoin-core-dev
7292020-05-21T19:49:17  <ariard> BlueMatt: cooool will go through this whole conv again to bookmark
7302020-05-21T19:49:44  <ariard> oh in fact i've already you branch bookmarked :) the doc starter is nice
7312020-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
7322020-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.
7332020-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
7342020-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/
7352020-05-21T19:50:57  <ariard> anyone has opinion on this ?
7362020-05-21T19:51:16  <BlueMatt> ariard: as long as its purely additive, who cares! :)
7372020-05-21T19:51:16  <ariard> and such side-effect may not be desirable
7382020-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
7392020-05-21T19:51:31  <ariard> BlueMatt: right if everything is opt-in I think that's okay
7402020-05-21T19:51:53  <jeremyrubin> I don't think it's addititive
7412020-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...)
7422020-05-21T19:51:59  <ariard> jonatack: I know review process and getting the first chunks PRs are the hardest steps :)
7432020-05-21T19:52:03  <jeremyrubin> This increases partitionability
7442020-05-21T19:52:21  <jeremyrubin> but increases availability I think?
7452020-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
7462020-05-21T19:52:36  <BlueMatt> but maybe only after having the regular p2p code make some new connections
7472020-05-21T19:52:45  <ariard> BlueMatt: exactly that's kind of the idea of having a watchdog for this
7482020-05-21T19:52:58  <BlueMatt> you dont need anything fancy to do that, though
7492020-05-21T19:53:04  <BlueMatt> only a sleep(300) :)
7502020-05-21T19:53:13  <ariard> that's hacky
7512020-05-21T19:53:16  <BlueMatt> no its not
7522020-05-21T19:53:24  <BlueMatt> its actually exactly what you want here
7532020-05-21T19:53:35  <sipa> wth are you guys talking about
7542020-05-21T19:53:38  *** FoxTrote has joined #bitcoin-core-dev
7552020-05-21T19:53:38  <BlueMatt> give net_processing a chance to figure out how to fetch the block if we're missing one
7562020-05-21T19:53:47  <ariard> BlueMatt: don't use a privacy-harming communication channel if you don't have to
7572020-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
7582020-05-21T19:54:00  <BlueMatt> right, exactly, thats why you sleep(300) :)
7592020-05-21T19:54:17  <wumpus> ~5 minutes to go
7602020-05-21T19:54:19  <jnewbery> I agree with sipa
7612020-05-21T19:54:24  <BlueMatt> sipa: if, eg, you learn a header over radio, but that source doesnt provide blocks, what do you do?
7622020-05-21T19:54:36  <BlueMatt> oh, wait, is this still a meeting? lol I'll shut up.
7632020-05-21T19:54:47  <jnewbery> perhaps this more speculative discussion is better suited to bitcoin-wizards or similar?
7642020-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
7652020-05-21T19:54:51  <sipa> sleep(300) till the end of the meeting
7662020-05-21T19:55:04  <wumpus> jnewbery: yes, though we don't have any other topics queued for today
7672020-05-21T19:55:39  <ariard> jnewbery: agree again I invite people to pursue discussion on the issue or PR, it's better suited
7682020-05-21T19:55:43  <sipa> BlueMatt: i don't know, why would you do anything?
7692020-05-21T19:56:24  <sipa> i feel like i'm missing a lot of context
7702020-05-21T19:56:26  *** promag has joined #bitcoin-core-dev
7712020-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
7722020-05-21T19:57:25  <wumpus> though it's good that you're clearly having a lot of ideas
7732020-05-21T19:57:28  <ariard> sipa: yes I will try to come with some Q&A-style of doc to inform people better
7742020-05-21T19:57:40  <wumpus> but some of us hardly follow :)
7752020-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
7762020-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 :)
7772020-05-21T19:58:16  <ariard> wumpus: thanks, I want to spend more time scoping to the minimal step but yet extendable after
7782020-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 :/
7792020-05-21T19:59:38  <BlueMatt> this all was, in fact, the rust branches.
7802020-05-21T20:00:01  *** jarthur has joined #bitcoin-core-dev
7812020-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
7822020-05-21T20:00:05  <ariard> BlueMatt: okay I see your point, but you need to dissociate cleanly 1) anomalies detection and 2) reaction
7832020-05-21T20:00:14  <ariard> reaction may happen through net_processing or alt-transports
7842020-05-21T20:00:20  <BlueMatt> wullon5: yea, no, not complaining, just providing historical context for folks
7852020-05-21T20:00:22  <BlueMatt> wumpus:
7862020-05-21T20:00:50  *** promag has quit IRC
7872020-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
7882020-05-21T20:01:06  <wumpus> wrapping up the meeting
7892020-05-21T20:01:14  <wumpus> thanks everyone for the lively discussion
7902020-05-21T20:01:22  <ariard> BlueMatt: ideally yes but I fear our internal components aren't that much clean yet
7912020-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.
7922020-05-21T20:01:41  <wumpus> #endmeeting
7932020-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)
7942020-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
7952020-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
7962020-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
7972020-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"
7982020-05-21T20:02:12  <sipa> it's additional complexity for the transport to need to care about these things
7992020-05-21T20:02:40  <ariard> BlueMatt: I spent some times thinking about anomaly detection, there is clearly a tradeoff between false positive and complexity
8002020-05-21T20:03:06  <ariard> and even worst, you may want to fine-tune depending of your second-layer timelocks...
8012020-05-21T20:03:56  <BlueMatt> ariard: right! sleep(300) is bulletproof. detecting slow chain progress is....not :)
8022020-05-21T20:04:23  <sipa> BlueMatt: by "sleep(300)" you actually mean "a fixed time-out" right, not an actual sleep in the code
8032020-05-21T20:04:31  <BlueMatt> sipa: right, sure lol
8042020-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
8052020-05-21T20:05:22  <BlueMatt> and we probaby often want it to be unidirectional
8062020-05-21T20:05:49  <sipa> BlueMatt: i just think there are distinct goals, and doing both right means doing things at a different layer
8072020-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
8082020-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
8092020-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)
8102020-05-21T20:08:34  <BlueMatt> right.
8112020-05-21T20:10:21  <ariard> sipa: but it's a layer question, 1) may rely on 2) once serialization is done?
8122020-05-21T20:11:22  <sipa> ariard: i don't know what you mean
8132020-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.
8142020-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
8152020-05-21T20:14:08  <ariard> or sorry I think I don't get your distinction laid out above, if you have concrete example
8162020-05-21T20:14:24  <BlueMatt> ariard: if you're farmiliar, (2) is tor's pluggable transport system.
8172020-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)
8182020-05-21T20:16:50  <ariard> BlueMatt: okay I see compare to blocksat where you do have your own serialization for compressing tx?
8192020-05-21T20:17:12  <BlueMatt> right, and especially where you have unidirectional coms
8202020-05-21T20:17:13  <BlueMatt> like blocksat
8212020-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)
8222020-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
8232020-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
8242020-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
8252020-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
8262020-05-21T20:21:26  <sipa> so i really think what is appropriate where is very application specific
8272020-05-21T20:21:41  <sipa> but interfaces may differ wildly between them
8282020-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?
8292020-05-21T20:23:17  <BlueMatt> right, its a question of goals
8302020-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
8312020-05-21T20:24:00  <BlueMatt> which is a very different goal from only getting around port 8333 blocking
8322020-05-21T20:24:14  <BlueMatt> ariard: those two goals have very different APIs, though.
8332020-05-21T20:24:21  *** promag has joined #bitcoin-core-dev
8342020-05-21T20:25:38  *** LucasNickle has joined #bitcoin-core-dev
8352020-05-21T20:36:49  *** EagleTM has joined #bitcoin-core-dev
8362020-05-21T20:40:43  *** jarthur has quit IRC
8372020-05-21T20:46:12  *** kristapsk has quit IRC
8382020-05-21T20:47:34  *** Chris_Stewart_5 has quit IRC
8392020-05-21T20:52:09  *** kristapsk has joined #bitcoin-core-dev
8402020-05-21T20:53:01  *** ctrlbreak_MAD has quit IRC
8412020-05-21T20:53:26  *** ctrlbreak_MAD has joined #bitcoin-core-dev
8422020-05-21T20:59:11  *** SiAnDoG has quit IRC
8432020-05-21T20:59:55  *** SiAnDoG has joined #bitcoin-core-dev
8442020-05-21T21:00:01  *** mshadle1 has quit IRC
8452020-05-21T21:00:28  *** jeremyrubin has quit IRC
8462020-05-21T21:01:12  *** jeremyrubin has joined #bitcoin-core-dev
8472020-05-21T21:09:03  *** vasild has quit IRC
8482020-05-21T21:11:43  *** vasild has joined #bitcoin-core-dev
8492020-05-21T21:12:27  *** troygiorshev has quit IRC
8502020-05-21T21:13:10  *** EagleTM has quit IRC
8512020-05-21T21:13:44  *** emilengler has quit IRC
8522020-05-21T21:22:00  *** Relis has quit IRC
8532020-05-21T21:22:02  *** jtk has joined #bitcoin-core-dev
8542020-05-21T21:25:34  *** Relis has joined #bitcoin-core-dev
8552020-05-21T21:40:03  *** shesek has quit IRC
8562020-05-21T21:43:27  *** shesek has joined #bitcoin-core-dev
8572020-05-21T21:43:39  *** Chris_Stewart_5 has joined #bitcoin-core-dev
8582020-05-21T21:45:30  *** marcoagner has quit IRC
8592020-05-21T22:00:29  *** helo has joined #bitcoin-core-dev
8602020-05-21T22:00:45  *** helo has joined #bitcoin-core-dev
8612020-05-21T22:05:05  *** waxwing has quit IRC
8622020-05-21T22:05:12  *** Guyver2 has quit IRC
8632020-05-21T22:07:25  *** FoxTrote has quit IRC
8642020-05-21T22:11:39  *** waxwing has joined #bitcoin-core-dev
8652020-05-21T22:13:20  *** bitcoin-git has joined #bitcoin-core-dev
8662020-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
8672020-05-21T22:13:21  *** bitcoin-git has left #bitcoin-core-dev
8682020-05-21T22:16:09  *** shesek has quit IRC
8692020-05-21T22:16:09  *** shesek has joined #bitcoin-core-dev
8702020-05-21T22:17:50  *** waxwing has quit IRC
8712020-05-21T22:17:50  *** waxwing has joined #bitcoin-core-dev
8722020-05-21T22:22:38  *** mdunnio has quit IRC
8732020-05-21T22:31:16  *** theStack has quit IRC
8742020-05-21T22:33:45  *** troygiorshev has joined #bitcoin-core-dev
8752020-05-21T22:51:01  *** bitcoin-git has joined #bitcoin-core-dev
8762020-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
8772020-05-21T22:51:02  *** bitcoin-git has left #bitcoin-core-dev
8782020-05-21T22:53:10  *** justanotheruser has quit IRC
8792020-05-21T22:53:16  *** ctrlbreak_MAD has quit IRC
8802020-05-21T22:53:41  *** ctrlbreak_MAD has joined #bitcoin-core-dev
8812020-05-21T22:58:35  *** bitcoin-git has joined #bitcoin-core-dev
8822020-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
8832020-05-21T22:58:37  *** bitcoin-git has left #bitcoin-core-dev
8842020-05-21T23:02:53  *** dfmb_ has quit IRC
8852020-05-21T23:09:45  *** justanotheruser has joined #bitcoin-core-dev
8862020-05-21T23:13:45  *** proofofkeags has quit IRC
8872020-05-21T23:15:37  *** proofofkeags has joined #bitcoin-core-dev
8882020-05-21T23:15:39  *** proofofkeags has quit IRC
8892020-05-21T23:15:56  *** proofofkeags has joined #bitcoin-core-dev
8902020-05-21T23:18:10  *** Dean_Guss has joined #bitcoin-core-dev
8912020-05-21T23:19:23  *** DeanWeen has quit IRC
8922020-05-21T23:20:14  *** owowo has quit IRC
8932020-05-21T23:22:15  *** ironhelix has quit IRC
8942020-05-21T23:25:02  *** bitcoin-git has joined #bitcoin-core-dev
8952020-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
8962020-05-21T23:25:03  *** bitcoin-git has left #bitcoin-core-dev
8972020-05-21T23:25:07  *** owowo has joined #bitcoin-core-dev
8982020-05-21T23:25:07  *** owowo has joined #bitcoin-core-dev
8992020-05-21T23:33:05  *** promag has quit IRC
9002020-05-21T23:33:44  *** promag has joined #bitcoin-core-dev
9012020-05-21T23:38:16  *** promag has quit IRC
9022020-05-21T23:42:09  *** AaronvanW has quit IRC
9032020-05-21T23:46:01  *** dfmb_ has joined #bitcoin-core-dev
9042020-05-21T23:49:18  *** proofofkeags has quit IRC
9052020-05-21T23:52:28  *** bitcoin-git has joined #bitcoin-core-dev
9062020-05-21T23:52:30  <bitcoin-git> [bitcoin] fanquake pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/9abed46871a7...ad3a61c5f5c9
9072020-05-21T23:52:31  <bitcoin-git> bitcoin/master d160069 gzhao408: [wallet] remove nLastResend logic
9082020-05-21T23:52:31  <bitcoin-git> bitcoin/master a7ebe48 gzhao408: [rpc] add unbroadcast info to mempool entries and getmempoolinfo
9092020-05-21T23:52:32  <bitcoin-git> bitcoin/master 9d3f7eb gzhao408: [mempool] sanity check that all unbroadcast txns are in mempool
9102020-05-21T23:52:34  *** bitcoin-git has left #bitcoin-core-dev
9112020-05-21T23:52:49  *** bitcoin-git has joined #bitcoin-core-dev
9122020-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
9132020-05-21T23:52:50  *** bitcoin-git has left #bitcoin-core-dev