12020-06-11T00:00:02  *** flo1 has quit IRC
  22020-06-11T00:00:08  *** bitcoin-git has joined #bitcoin-core-dev
  32020-06-11T00:00:08  <bitcoin-git> [bitcoin] luke-jr opened pull request #19241: help: Generate checkpoint height from chainparams (master...help_checkpoint_num) https://github.com/bitcoin/bitcoin/pull/19241
  42020-06-11T00:00:09  *** bitcoin-git has left #bitcoin-core-dev
  52020-06-11T00:14:37  *** proofofk_ has quit IRC
  62020-06-11T00:15:12  *** proofofkeags has joined #bitcoin-core-dev
  72020-06-11T00:16:18  *** proofofkeags has quit IRC
  82020-06-11T00:17:13  *** proofofkeags has joined #bitcoin-core-dev
  92020-06-11T00:21:03  *** pretyflaco1 has quit IRC
 102020-06-11T00:22:14  *** proofofkeags has quit IRC
 112020-06-11T00:30:05  *** proofofkeags has joined #bitcoin-core-dev
 122020-06-11T00:41:31  *** proofofkeags has quit IRC
 132020-06-11T00:42:06  *** proofofkeags has joined #bitcoin-core-dev
 142020-06-11T00:46:43  *** proofofkeags has quit IRC
 152020-06-11T00:52:24  *** S3RK has joined #bitcoin-core-dev
 162020-06-11T00:56:48  *** Eartaker has joined #bitcoin-core-dev
 172020-06-11T01:05:54  *** dfmb_ has joined #bitcoin-core-dev
 182020-06-11T01:06:03  *** dfmb_ has quit IRC
 192020-06-11T01:07:23  *** bitdex has quit IRC
 202020-06-11T01:15:45  *** AaronvanW has quit IRC
 212020-06-11T01:16:42  *** proofofkeags has joined #bitcoin-core-dev
 222020-06-11T01:21:14  *** proofofkeags has quit IRC
 232020-06-11T01:25:58  *** Relis has quit IRC
 242020-06-11T01:30:50  *** promag has joined #bitcoin-core-dev
 252020-06-11T01:32:08  *** Relis has joined #bitcoin-core-dev
 262020-06-11T01:35:35  *** promag has quit IRC
 272020-06-11T01:36:40  <sipa> fanquake: can you mark your "changes requested" as resolved on #19228 ?
 282020-06-11T01:36:41  <gribble> https://github.com/bitcoin/bitcoin/issues/19228 | Update libsecp256k1 subtree by sipa · Pull Request #19228 · bitcoin/bitcoin · GitHub
 292020-06-11T01:37:17  <fanquake> sipa: sure
 302020-06-11T01:41:45  <fanquake> Flat out confusing myself with the GH UI, but managed to get it sorted
 312020-06-11T01:43:16  <luke-jr> more like it managed to get you sorted :P
 322020-06-11T01:44:06  <fanquake> heh. Managed to re-request a review from myself
 332020-06-11T01:44:24  <luke-jr> XD
 342020-06-11T01:44:31  <sipa> fanquake is now known as aaefknqu
 352020-06-11T01:44:54  <luke-jr> lol
 362020-06-11T01:47:24  *** bitdex has joined #bitcoin-core-dev
 372020-06-11T01:57:06  *** thaumavorio has quit IRC
 382020-06-11T01:58:17  *** thaumavorio has joined #bitcoin-core-dev
 392020-06-11T02:04:28  *** Highway61 has quit IRC
 402020-06-11T02:07:16  *** proofofkeags has joined #bitcoin-core-dev
 412020-06-11T02:09:53  *** Relis has quit IRC
 422020-06-11T02:20:32  *** Highway61 has joined #bitcoin-core-dev
 432020-06-11T02:22:31  *** Relis has joined #bitcoin-core-dev
 442020-06-11T02:24:50  *** Relis has quit IRC
 452020-06-11T02:26:02  *** Relis has joined #bitcoin-core-dev
 462020-06-11T02:28:18  *** bitcoin-git has joined #bitcoin-core-dev
 472020-06-11T02:28:18  <bitcoin-git> [bitcoin] luke-jr opened pull request #19242: Add -uaappend option to append a literal string to user agent (master...uaappend) https://github.com/bitcoin/bitcoin/pull/19242
 482020-06-11T02:28:30  *** bitcoin-git has left #bitcoin-core-dev
 492020-06-11T02:33:31  <aj> luke-jr: shouldn't uaappends be separated by "; " or something?
 502020-06-11T02:50:59  *** proofofkeags has quit IRC
 512020-06-11T02:51:26  <luke-jr> aj: '/', but I'm assuming the using application knows that
 522020-06-11T02:51:32  *** proofofkeags has joined #bitcoin-core-dev
 532020-06-11T02:51:37  <luke-jr> -uaappend 'foo:1.0/'
 542020-06-11T02:51:47  <luke-jr> -uaappend 'foo:1.0/bar:9999/'
 552020-06-11T02:55:05  <aj> luke-jr: i would have expected use more like -uappend=foo:1.0 -uappend=bar:9999
 562020-06-11T02:55:27  *** justanotheruser has quit IRC
 572020-06-11T02:55:41  *** S3RK has quit IRC
 582020-06-11T02:56:02  *** proofofkeags has quit IRC
 592020-06-11T02:56:06  <aj> apparently the double-a is hard for me
 602020-06-11T02:56:25  <luke-jr> aj: but then you can't reliably predict order
 612020-06-11T02:59:22  <aj> luke-jr: sure, but don't see why order matters much? (and if it does, then allowing many uaappend's doesn't seem right?)
 622020-06-11T03:00:02  *** Eartaker has quit IRC
 632020-06-11T03:08:47  *** justanotheruser has joined #bitcoin-core-dev
 642020-06-11T03:16:32  *** Eagle[TM] has joined #bitcoin-core-dev
 652020-06-11T03:17:28  <luke-jr> aj: maybe it does, maybe not *shrug*
 662020-06-11T03:17:54  <luke-jr> we don't act on it, but others might
 672020-06-11T03:18:06  <luke-jr> probably shouldn't I guess, but it's also nice for consistency :x
 682020-06-11T03:18:26  *** EagleTM has quit IRC
 692020-06-11T03:18:28  *** justanotheruser has quit IRC
 702020-06-11T03:22:14  *** meltheadorable has joined #bitcoin-core-dev
 712020-06-11T03:22:56  *** Relis has quit IRC
 722020-06-11T03:25:46  <luke-jr> I guess always ensuring there's a / at the end makes sense
 732020-06-11T03:48:35  *** justanotheruser has joined #bitcoin-core-dev
 742020-06-11T04:20:35  *** vasild_ has joined #bitcoin-core-dev
 752020-06-11T04:21:01  *** S3RK has joined #bitcoin-core-dev
 762020-06-11T04:23:23  *** vasild has quit IRC
 772020-06-11T04:23:24  *** vasild_ is now known as vasild
 782020-06-11T04:31:55  *** ppisati has quit IRC
 792020-06-11T04:36:08  *** shesek has quit IRC
 802020-06-11T04:36:32  *** shesek has joined #bitcoin-core-dev
 812020-06-11T04:36:32  *** shesek has joined #bitcoin-core-dev
 822020-06-11T04:38:40  *** ppisati has joined #bitcoin-core-dev
 832020-06-11T04:57:06  *** afk11` has quit IRC
 842020-06-11T04:57:28  *** afk11` has joined #bitcoin-core-dev
 852020-06-11T04:58:48  *** jarthur_ has joined #bitcoin-core-dev
 862020-06-11T05:01:02  *** jarthur has quit IRC
 872020-06-11T05:03:02  *** S3RK has quit IRC
 882020-06-11T05:03:29  *** S3RK has joined #bitcoin-core-dev
 892020-06-11T05:08:09  *** S3RK has quit IRC
 902020-06-11T05:32:00  *** bitcoin-git has joined #bitcoin-core-dev
 912020-06-11T05:32:01  <bitcoin-git> [bitcoin] hebasto closed pull request #19238: refactor: Replace RecursiveMutex with Mutex in CAddrMan (master...200610-addrman-mx) https://github.com/bitcoin/bitcoin/pull/19238
 922020-06-11T05:32:01  *** bitcoin-git has left #bitcoin-core-dev
 932020-06-11T05:32:20  *** bitcoin-git has joined #bitcoin-core-dev
 942020-06-11T05:32:21  <bitcoin-git> [bitcoin] hebasto reopened pull request #19238: refactor: Replace RecursiveMutex with Mutex in CAddrMan (master...200610-addrman-mx) https://github.com/bitcoin/bitcoin/pull/19238
 952020-06-11T05:32:21  *** bitcoin-git has left #bitcoin-core-dev
 962020-06-11T05:37:47  *** endogenic has quit IRC
 972020-06-11T05:37:57  *** CodeShark___ has quit IRC
 982020-06-11T05:38:05  *** endogenic has joined #bitcoin-core-dev
 992020-06-11T05:38:15  *** CodeShark___ has joined #bitcoin-core-dev
1002020-06-11T05:38:22  *** digi_james has quit IRC
1012020-06-11T05:38:37  *** digi_james has joined #bitcoin-core-dev
1022020-06-11T06:00:02  *** meltheadorable has quit IRC
1032020-06-11T06:21:57  *** engil1 has joined #bitcoin-core-dev
1042020-06-11T06:28:19  *** sdaftuar has quit IRC
1052020-06-11T06:28:42  *** sdaftuar has joined #bitcoin-core-dev
1062020-06-11T06:30:00  *** justanotheruser has quit IRC
1072020-06-11T06:34:41  *** S3RK has joined #bitcoin-core-dev
1082020-06-11T06:39:03  *** harrigan has quit IRC
1092020-06-11T06:39:04  *** S3RK has quit IRC
1102020-06-11T06:39:44  *** harrigan has joined #bitcoin-core-dev
1112020-06-11T06:55:28  *** stackingcore21_ has joined #bitcoin-core-dev
1122020-06-11T06:56:06  *** justanotheruser has joined #bitcoin-core-dev
1132020-06-11T06:56:23  *** stackingcore21 has quit IRC
1142020-06-11T07:02:52  *** windsok has quit IRC
1152020-06-11T07:05:08  *** jarthur_ has quit IRC
1162020-06-11T07:05:42  *** windsok has joined #bitcoin-core-dev
1172020-06-11T07:05:42  *** windsok has joined #bitcoin-core-dev
1182020-06-11T07:22:58  *** bitcoin-git has joined #bitcoin-core-dev
1192020-06-11T07:22:59  <bitcoin-git> [bitcoin] luke-jr opened pull request #19243: banman: Limit resources consumed by misbehaving node deprioitisation (master...misbehaving_limit) https://github.com/bitcoin/bitcoin/pull/19243
1202020-06-11T07:23:00  *** bitcoin-git has left #bitcoin-core-dev
1212020-06-11T07:23:53  *** SiAnDoG has joined #bitcoin-core-dev
1222020-06-11T07:35:10  *** kabaum has joined #bitcoin-core-dev
1232020-06-11T07:36:41  <luke-jr> is it just me, or do we currently have a bug where a misbehaving node makes itself immune to a real/user-set ban less than 24 hours long?
1242020-06-11T07:37:28  <luke-jr> also, is there any realistic way to write functional tests for many misbehaving nodes? XD
1252020-06-11T07:37:40  <luke-jr> (or even a handful..)
1262020-06-11T07:37:50  *** Guyver2 has joined #bitcoin-core-dev
1272020-06-11T07:54:47  *** tryphe has quit IRC
1282020-06-11T07:55:13  *** tryphe has joined #bitcoin-core-dev
1292020-06-11T07:55:43  *** braydonf has quit IRC
1302020-06-11T07:57:43  *** braydonf has joined #bitcoin-core-dev
1312020-06-11T08:15:46  *** sipsorcery has quit IRC
1322020-06-11T08:22:55  *** justan0theruser has joined #bitcoin-core-dev
1332020-06-11T08:25:48  *** justanotheruser has quit IRC
1342020-06-11T08:31:19  *** Pavlenex has joined #bitcoin-core-dev
1352020-06-11T08:33:29  *** AaronvanW has joined #bitcoin-core-dev
1362020-06-11T08:37:45  *** luke-jr has quit IRC
1372020-06-11T08:38:37  *** luke-jr has joined #bitcoin-core-dev
1382020-06-11T08:38:40  *** bitcoin-git has joined #bitcoin-core-dev
1392020-06-11T08:38:42  <bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/6762a627ecb8...45a6811d36fc
1402020-06-11T08:38:42  <bitcoin-git> bitcoin/master faedb50 MarcoFalke: test: pep-8 mining_basic
1412020-06-11T08:38:44  <bitcoin-git> bitcoin/master fa98e10 MarcoFalke: test: Remove leftover comment in mining_basic
1422020-06-11T08:38:44  <bitcoin-git> bitcoin/master 45a6811 fanquake: Merge #19206: test: Remove leftover comment in mining_basic
1432020-06-11T08:38:46  *** bitcoin-git has left #bitcoin-core-dev
1442020-06-11T08:39:00  *** bitcoin-git has joined #bitcoin-core-dev
1452020-06-11T08:39:00  <bitcoin-git> [bitcoin] fanquake merged pull request #19206: test: Remove leftover comment in mining_basic (master...2006-testComment) https://github.com/bitcoin/bitcoin/pull/19206
1462020-06-11T08:39:01  *** bitcoin-git has left #bitcoin-core-dev
1472020-06-11T08:43:09  *** windsok has quit IRC
1482020-06-11T08:44:23  *** windsok has joined #bitcoin-core-dev
1492020-06-11T08:55:11  *** justan0theruser has quit IRC
1502020-06-11T08:55:19  *** justanotheruser has joined #bitcoin-core-dev
1512020-06-11T09:00:02  *** engil1 has quit IRC
1522020-06-11T09:05:39  *** jarthur has joined #bitcoin-core-dev
1532020-06-11T09:10:56  *** jarthur has quit IRC
1542020-06-11T09:21:48  *** Waithamai has joined #bitcoin-core-dev
1552020-06-11T09:22:12  *** Waithamai is now known as Guest65675
1562020-06-11T09:48:34  *** S3RK has joined #bitcoin-core-dev
1572020-06-11T09:56:41  *** S3RK has quit IRC
1582020-06-11T10:01:05  *** S3RK has joined #bitcoin-core-dev
1592020-06-11T10:05:20  *** Marie16Stracke has joined #bitcoin-core-dev
1602020-06-11T10:08:27  *** awesome-doge has joined #bitcoin-core-dev
1612020-06-11T10:10:10  *** Marie16Stracke has quit IRC
1622020-06-11T10:12:03  *** S3RK has quit IRC
1632020-06-11T10:16:10  *** promag has joined #bitcoin-core-dev
1642020-06-11T10:21:22  *** Asbestos_Vapor has joined #bitcoin-core-dev
1652020-06-11T10:25:04  *** promag has quit IRC
1662020-06-11T10:25:41  *** Mercury_Vapor has quit IRC
1672020-06-11T10:25:52  *** promag has joined #bitcoin-core-dev
1682020-06-11T10:27:53  *** promag_ has joined #bitcoin-core-dev
1692020-06-11T10:27:53  *** promag has quit IRC
1702020-06-11T10:28:23  *** S3RK has joined #bitcoin-core-dev
1712020-06-11T10:51:23  *** rafalcpp has joined #bitcoin-core-dev
1722020-06-11T10:53:11  *** Relis has joined #bitcoin-core-dev
1732020-06-11T11:02:46  *** Relis has quit IRC
1742020-06-11T11:06:16  *** Pavlenex has quit IRC
1752020-06-11T11:06:52  *** jarthur has joined #bitcoin-core-dev
1762020-06-11T11:12:03  *** jarthur has quit IRC
1772020-06-11T11:27:07  *** S3RK has quit IRC
1782020-06-11T11:27:34  *** S3RK has joined #bitcoin-core-dev
1792020-06-11T11:29:49  *** S3RK has quit IRC
1802020-06-11T11:29:56  *** S3RK has joined #bitcoin-core-dev
1812020-06-11T11:39:34  *** Relis has joined #bitcoin-core-dev
1822020-06-11T11:40:03  *** S3RK has quit IRC
1832020-06-11T11:40:05  *** bitcoin-git has joined #bitcoin-core-dev
1842020-06-11T11:40:05  <bitcoin-git> [bitcoin] kiminuo opened pull request #19245: [WIP DONOTMERGE] Replace boost::filesystem with std::filesystem (in c++17) (master...feature/2020-06-replace-boost-filesystem-with-cpp17-filesystem) https://github.com/bitcoin/bitcoin/pull/19245
1852020-06-11T11:40:06  *** bitcoin-git has left #bitcoin-core-dev
1862020-06-11T11:40:30  *** S3RK has joined #bitcoin-core-dev
1872020-06-11T11:42:30  *** Kiminuo has joined #bitcoin-core-dev
1882020-06-11T11:45:25  *** bitdex has quit IRC
1892020-06-11T11:47:05  *** S3RK has quit IRC
1902020-06-11T11:57:32  *** owowo has quit IRC
1912020-06-11T11:58:11  *** belcher has joined #bitcoin-core-dev
1922020-06-11T12:00:02  *** Guest65675 has quit IRC
1932020-06-11T12:02:25  *** owowo has joined #bitcoin-core-dev
1942020-06-11T12:09:26  *** rafalcpp has quit IRC
1952020-06-11T12:11:42  *** justanotheruser has quit IRC
1962020-06-11T12:14:05  *** Guyver2 has quit IRC
1972020-06-11T12:15:12  *** justanotheruser has joined #bitcoin-core-dev
1982020-06-11T12:22:14  *** izaki1 has joined #bitcoin-core-dev
1992020-06-11T12:25:31  *** S3RK has joined #bitcoin-core-dev
2002020-06-11T12:30:16  *** rafalcpp has joined #bitcoin-core-dev
2012020-06-11T12:32:11  *** prusnak has quit IRC
2022020-06-11T12:32:24  *** prusnak has joined #bitcoin-core-dev
2032020-06-11T12:32:40  *** hugohn has quit IRC
2042020-06-11T12:32:46  *** schmidty has quit IRC
2052020-06-11T12:32:54  *** hugohn has joined #bitcoin-core-dev
2062020-06-11T12:33:03  *** arik__ has quit IRC
2072020-06-11T12:33:04  *** schmidty has joined #bitcoin-core-dev
2082020-06-11T12:33:05  *** pierre_rochard has quit IRC
2092020-06-11T12:33:05  *** jkczyz has quit IRC
2102020-06-11T12:33:05  *** amiti has quit IRC
2112020-06-11T12:33:06  *** michagogo has quit IRC
2122020-06-11T12:33:07  *** vfP56jSe has quit IRC
2132020-06-11T12:33:25  *** arik__ has joined #bitcoin-core-dev
2142020-06-11T12:33:27  *** jkczyz has joined #bitcoin-core-dev
2152020-06-11T12:33:27  *** amiti has joined #bitcoin-core-dev
2162020-06-11T12:33:27  *** pierre_rochard has joined #bitcoin-core-dev
2172020-06-11T12:33:27  *** vfP56jSe has joined #bitcoin-core-dev
2182020-06-11T12:33:47  *** michagogo has joined #bitcoin-core-dev
2192020-06-11T12:36:14  *** S3RK has quit IRC
2202020-06-11T12:38:34  *** pretyflaco has joined #bitcoin-core-dev
2212020-06-11T12:43:38  *** troygiorshev has joined #bitcoin-core-dev
2222020-06-11T13:02:39  *** troygiorshev has quit IRC
2232020-06-11T13:02:59  *** troygiorshev has joined #bitcoin-core-dev
2242020-06-11T13:07:59  *** jarthur has joined #bitcoin-core-dev
2252020-06-11T13:11:05  *** bitcoin-git has joined #bitcoin-core-dev
2262020-06-11T13:11:06  <bitcoin-git> [bitcoin] practicalswift opened pull request #19247: tests: Add fuzzing harness for {Read,Write}{LE,BE}{16,32,64} (crypto/common.h) (master...fuzzers-crypto_common) https://github.com/bitcoin/bitcoin/pull/19247
2272020-06-11T13:11:06  *** bitcoin-git has left #bitcoin-core-dev
2282020-06-11T13:12:19  *** rafalcpp has quit IRC
2292020-06-11T13:12:48  *** jarthur has quit IRC
2302020-06-11T13:27:53  *** rafalcpp has joined #bitcoin-core-dev
2312020-06-11T13:39:39  *** dfmb_ has joined #bitcoin-core-dev
2322020-06-11T13:39:59  *** dfmb_ has quit IRC
2332020-06-11T13:54:10  *** bitcoin-git has joined #bitcoin-core-dev
2342020-06-11T13:54:11  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/45a6811d36fc...7a24cca82906
2352020-06-11T13:54:11  <bitcoin-git> bitcoin/master f42f5e5 Russell Yanofsky: refactor: Combine GetWalletForJSONRPCRequest and EnsureWalletIsAvailable f...
2362020-06-11T13:54:11  <bitcoin-git> bitcoin/master 7a24cca MarcoFalke: Merge #19100: refactor: Combine GetWalletForJSONRPCRequest and EnsureWalle...
2372020-06-11T13:54:12  *** bitcoin-git has left #bitcoin-core-dev
2382020-06-11T13:54:30  *** bitcoin-git has joined #bitcoin-core-dev
2392020-06-11T13:54:31  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #19100: refactor: Combine GetWalletForJSONRPCRequest and EnsureWalletIsAvailable functions (master...pr/ensa) https://github.com/bitcoin/bitcoin/pull/19100
2402020-06-11T13:54:31  *** bitcoin-git has left #bitcoin-core-dev
2412020-06-11T14:06:39  *** bitcoin-git has joined #bitcoin-core-dev
2422020-06-11T14:06:39  <bitcoin-git> [bitcoin] hebasto opened pull request #19249: Add means to handle negative capabilities in the Clang Thread Safety annotations (master...200611-nc) https://github.com/bitcoin/bitcoin/pull/19249
2432020-06-11T14:06:40  *** bitcoin-git has left #bitcoin-core-dev
2442020-06-11T14:09:38  *** proofofkeags has joined #bitcoin-core-dev
2452020-06-11T14:20:59  *** Kiminuo has quit IRC
2462020-06-11T14:25:13  *** bitcoin-git has joined #bitcoin-core-dev
2472020-06-11T14:25:13  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #19250: wallet: [move-only bugfix] Make RPC help compile-time static (master...2006-rpcWalletHelp) https://github.com/bitcoin/bitcoin/pull/19250
2482020-06-11T14:25:14  *** bitcoin-git has left #bitcoin-core-dev
2492020-06-11T14:34:30  *** Kiminuo has joined #bitcoin-core-dev
2502020-06-11T14:37:57  *** real_or_random has quit IRC
2512020-06-11T14:38:20  *** real_or_random has joined #bitcoin-core-dev
2522020-06-11T14:44:47  *** mol_ has quit IRC
2532020-06-11T14:49:50  *** Pavlenex has joined #bitcoin-core-dev
2542020-06-11T15:00:01  *** izaki1 has quit IRC
2552020-06-11T15:08:44  *** jarthur has joined #bitcoin-core-dev
2562020-06-11T15:13:36  *** jarthur has quit IRC
2572020-06-11T15:22:23  *** llamma1 has joined #bitcoin-core-dev
2582020-06-11T15:22:28  *** mol has joined #bitcoin-core-dev
2592020-06-11T15:22:47  *** midnight has quit IRC
2602020-06-11T15:23:17  *** jarthur has joined #bitcoin-core-dev
2612020-06-11T15:25:32  <hebasto> please remind how to propose a meeting topic in advance?
2622020-06-11T15:26:15  <achow101> hebasto: using #proposedmeetingtopic
2632020-06-11T15:26:27  <hebasto> achow101: thanks
2642020-06-11T15:27:25  <hebasto> #proposedmeetingtopic Bump minimum required Clang version to 3.5
2652020-06-11T15:27:48  <hebasto> ^ in the context of #19249
2662020-06-11T15:27:50  <gribble> https://github.com/bitcoin/bitcoin/issues/19249 | Add means to handle negative capabilities in the Clang Thread Safety annotations by hebasto · Pull Request #19249 · bitcoin/bitcoin · GitHub
2672020-06-11T15:32:59  *** Relis has quit IRC
2682020-06-11T15:34:25  *** sipsorcery has joined #bitcoin-core-dev
2692020-06-11T15:41:56  *** troygiorshev has quit IRC
2702020-06-11T15:42:30  *** jarthur has quit IRC
2712020-06-11T15:43:46  *** Relis has joined #bitcoin-core-dev
2722020-06-11T15:43:53  *** bitcoin-git has joined #bitcoin-core-dev
2732020-06-11T15:43:53  <bitcoin-git> [bitcoin] hebasto opened pull request #19251: [Do Not Merge] ci: Temporary Test Case for negative capabilities in the Clang Thread Safety annotations (master...200611-dnm-test) https://github.com/bitcoin/bitcoin/pull/19251
2742020-06-11T15:43:54  *** bitcoin-git has left #bitcoin-core-dev
2752020-06-11T15:46:13  *** justanotheruser has quit IRC
2762020-06-11T15:47:42  *** jarthur has joined #bitcoin-core-dev
2772020-06-11T15:47:48  *** midnight has joined #bitcoin-core-dev
2782020-06-11T15:52:48  *** troygiorshev has joined #bitcoin-core-dev
2792020-06-11T16:02:16  *** justanotheruser has joined #bitcoin-core-dev
2802020-06-11T16:05:36  *** Talkless has joined #bitcoin-core-dev
2812020-06-11T16:13:37  *** S3RK has joined #bitcoin-core-dev
2822020-06-11T16:20:39  *** vasild_ has joined #bitcoin-core-dev
2832020-06-11T16:23:43  *** vasild has quit IRC
2842020-06-11T16:23:44  *** vasild_ is now known as vasild
2852020-06-11T16:32:13  <wumpus> I think we should bump compiler versions after C++17, not bother witht it sooner
2862020-06-11T16:32:31  <wumpus> no need to complicate this with multiple bumps
2872020-06-11T16:38:58  <wumpus> but note that #16684 has no mention of clang versions
2882020-06-11T16:39:00  <gribble> https://github.com/bitcoin/bitcoin/issues/16684 | Discussion: upgrading to C++17 · Issue #16684 · bitcoin/bitcoin · GitHub
2892020-06-11T16:39:17  <wumpus> I think we need to determine what clang version to require as minimum then
2902020-06-11T16:39:44  *** justanotheruser has quit IRC
2912020-06-11T16:41:44  *** pretyflaco1 has joined #bitcoin-core-dev
2922020-06-11T16:41:46  <sipa> clang advertizes full c++17 support as of version 5
2932020-06-11T16:41:59  <sipa> but it seems nearly all features are present in 4
2942020-06-11T16:44:12  *** troygiorshev has quit IRC
2952020-06-11T16:44:16  *** pretyflaco has quit IRC
2962020-06-11T16:44:31  *** troygiorshev has joined #bitcoin-core-dev
2972020-06-11T16:44:48  *** guest534543 has joined #bitcoin-core-dev
2982020-06-11T16:47:21  <wumpus> right: https://clang.llvm.org/cxx_status.html#cxx17  and some (more obscure?) things are only in 9/10
2992020-06-11T16:47:24  <hebasto> wumpus: yes, C++17 is near. Do you mean 19249 should be dropped for now, or could move on without clang version bumping?
3002020-06-11T16:47:42  <wumpus> hebasto: if you can make it optional
3012020-06-11T16:48:14  *** Kiminuo has quit IRC
3022020-06-11T16:48:16  <wumpus> I think we should let the minimum version also depend on what is generally available in Linux distros' to make sure we can test against it easily
3032020-06-11T16:48:18  <hebasto> that is the problem: make it optional will clutter the code
3042020-06-11T16:48:35  <wumpus> hebasto: then I'd say delay it until a bump is needed for c++17
3052020-06-11T16:49:00  <hebasto> jessie 3.5; xenial 3.8
3062020-06-11T16:50:46  *** troygiorshev has quit IRC
3072020-06-11T16:51:06  *** troygiorshev has joined #bitcoin-core-dev
3082020-06-11T16:51:33  *** bitcoin-git has joined #bitcoin-core-dev
3092020-06-11T16:51:34  <bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/7a24cca82906...85f7db22841e
3102020-06-11T16:51:35  <bitcoin-git> bitcoin/master e380818 John Newbery: Revert "[TESTS] Move base58 to own module to break circular dependency"
3112020-06-11T16:51:36  <bitcoin-git> bitcoin/master b216b0b John Newbery: [tests] sort imports in rpc_createmultisig.py
3122020-06-11T16:51:36  <bitcoin-git> bitcoin/master 3a83a01 John Newbery: [tests] move generate_wif_key to wallet_util.py
3132020-06-11T16:51:38  *** bitcoin-git has left #bitcoin-core-dev
3142020-06-11T16:51:53  *** bitcoin-git has joined #bitcoin-core-dev
3152020-06-11T16:51:53  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #19239: tests: move generate_wif_key to wallet_util.py (master...2020-06-generate-wif-key) https://github.com/bitcoin/bitcoin/pull/19239
3162020-06-11T16:51:54  *** bitcoin-git has left #bitcoin-core-dev
3172020-06-11T16:52:24  <wumpus> hebasto: you might want to post that into the c++17 issue
3182020-06-11T16:57:20  *** roconnor has quit IRC
3192020-06-11T17:01:02  *** bitcoin-git has joined #bitcoin-core-dev
3202020-06-11T17:01:02  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/85f7db22841e...8682414d0238
3212020-06-11T17:01:02  <bitcoin-git> bitcoin/master 4a8181b practicalswift: tests: Add std::vector<uint8_t> ConsumeFixedLengthByteVector(FuzzedDataPro...
3222020-06-11T17:01:03  <bitcoin-git> bitcoin/master cf5b8f6 practicalswift: tests: Add fuzzing harness for {Read,Write}{LE,BE}{16,32,64} (crypto/commo...
3232020-06-11T17:01:03  <bitcoin-git> bitcoin/master 8682414 MarcoFalke: Merge #19247: tests: Add fuzzing harness for {Read,Write}{LE,BE}{16,32,64}...
3242020-06-11T17:01:04  *** bitcoin-git has left #bitcoin-core-dev
3252020-06-11T17:01:21  *** bitcoin-git has joined #bitcoin-core-dev
3262020-06-11T17:01:22  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #19247: tests: Add fuzzing harness for {Read,Write}{LE,BE}{16,32,64} (crypto/common.h) (master...fuzzers-crypto_common) https://github.com/bitcoin/bitcoin/pull/19247
3272020-06-11T17:01:23  *** bitcoin-git has left #bitcoin-core-dev
3282020-06-11T17:02:14  <wumpus> hebasto: thanks for doing the research though, let's discuss it further in the meeting
3292020-06-11T17:03:28  *** icota[m] has joined #bitcoin-core-dev
3302020-06-11T17:04:46  *** ExEric3 has joined #bitcoin-core-dev
3312020-06-11T17:04:49  *** troygiorshev has quit IRC
3322020-06-11T17:05:07  *** troygiorshev has joined #bitcoin-core-dev
3332020-06-11T17:08:02  *** Guyver2 has joined #bitcoin-core-dev
3342020-06-11T17:10:37  *** troygiorshev has quit IRC
3352020-06-11T17:10:51  *** troygiorshev has joined #bitcoin-core-dev
3362020-06-11T17:25:03  *** ghost43 has quit IRC
3372020-06-11T17:25:24  *** ghost43 has joined #bitcoin-core-dev
3382020-06-11T17:31:44  *** mol_ has joined #bitcoin-core-dev
3392020-06-11T17:33:05  *** troygiorshev has quit IRC
3402020-06-11T17:33:24  *** troygiorshev has joined #bitcoin-core-dev
3412020-06-11T17:34:30  *** molz_ has joined #bitcoin-core-dev
3422020-06-11T17:35:02  *** mol has quit IRC
3432020-06-11T17:35:34  *** molz_ has quit IRC
3442020-06-11T17:35:55  *** molz_ has joined #bitcoin-core-dev
3452020-06-11T17:36:09  *** rafalcpp has quit IRC
3462020-06-11T17:36:15  *** justanotheruser has joined #bitcoin-core-dev
3472020-06-11T17:37:00  *** molz_ has quit IRC
3482020-06-11T17:37:24  *** molz_ has joined #bitcoin-core-dev
3492020-06-11T17:37:41  *** proofofkeags has quit IRC
3502020-06-11T17:38:14  *** mol_ has quit IRC
3512020-06-11T17:38:16  *** proofofkeags has joined #bitcoin-core-dev
3522020-06-11T17:38:41  *** rafalcpp has joined #bitcoin-core-dev
3532020-06-11T17:39:58  *** Guyver2_ has joined #bitcoin-core-dev
3542020-06-11T17:42:32  *** Guyver2 has quit IRC
3552020-06-11T17:42:50  *** molz_ has quit IRC
3562020-06-11T17:42:56  *** proofofkeags has quit IRC
3572020-06-11T17:43:20  *** Guyver2_ is now known as Guyver2
3582020-06-11T17:44:45  *** troygiorshev has quit IRC
3592020-06-11T17:45:13  *** troygiorshev has joined #bitcoin-core-dev
3602020-06-11T17:45:32  *** isis_ is now known as isis
3612020-06-11T17:45:46  *** proofofkeags has joined #bitcoin-core-dev
3622020-06-11T17:47:44  *** rafalcpp has quit IRC
3632020-06-11T17:50:26  *** mol has joined #bitcoin-core-dev
3642020-06-11T17:51:37  *** troygiorshev has quit IRC
3652020-06-11T17:52:36  *** troygiorshev has joined #bitcoin-core-dev
3662020-06-11T17:53:50  *** dviola has quit IRC
3672020-06-11T17:54:01  *** troygiorshev has joined #bitcoin-core-dev
3682020-06-11T18:00:02  *** llamma1 has quit IRC
3692020-06-11T18:03:46  *** bitcoin-git has joined #bitcoin-core-dev
3702020-06-11T18:03:46  <bitcoin-git> [bitcoin] gzhao408 opened pull request #19252: [wip] test: wait for disconnect in disconnect_p2ps + bloomfilter test followups (master...test-disconnect-p2ps-wait) https://github.com/bitcoin/bitcoin/pull/19252
3712020-06-11T18:03:47  *** bitcoin-git has left #bitcoin-core-dev
3722020-06-11T18:07:15  *** bitcoin-git has joined #bitcoin-core-dev
3732020-06-11T18:07:15  <bitcoin-git> [bitcoin] jnewbery opened pull request #19253: Tests: tidy up address.py and segwit_addr.py (master...2020-06-addr-unit-tests) https://github.com/bitcoin/bitcoin/pull/19253
3742020-06-11T18:07:16  *** bitcoin-git has left #bitcoin-core-dev
3752020-06-11T18:13:36  *** dr-orlovsky has joined #bitcoin-core-dev
3762020-06-11T18:13:57  *** rafalcpp has joined #bitcoin-core-dev
3772020-06-11T18:16:05  *** guest534543 has quit IRC
3782020-06-11T18:16:26  *** Kiminuo has joined #bitcoin-core-dev
3792020-06-11T18:20:38  *** jtk has joined #bitcoin-core-dev
3802020-06-11T18:22:24  *** Dean_Guss has quit IRC
3812020-06-11T18:26:22  *** gleb has joined #bitcoin-core-dev
3822020-06-11T18:29:18  *** Dean_Guss has joined #bitcoin-core-dev
3832020-06-11T18:37:01  *** bitcoin-git has joined #bitcoin-core-dev
3842020-06-11T18:37:03  <bitcoin-git> [bitcoin] MarcoFalke pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/8682414d0238...b33136b6ba98
3852020-06-11T18:37:03  <bitcoin-git> bitcoin/master e8acc60 gzhao408: [test] add mempool msg test for node with bloomfilter enabled
3862020-06-11T18:37:04  <bitcoin-git> bitcoin/master 497a619 gzhao408: [test] add BIP 37 test for node with fRelay=false
3872020-06-11T18:37:05  <bitcoin-git> bitcoin/master 4ef80f0 gzhao408: [test] sending invalid msgs to node with bloomfilters=0 causes disconnect
3882020-06-11T18:37:07  *** bitcoin-git has left #bitcoin-core-dev
3892020-06-11T18:37:21  *** bitcoin-git has joined #bitcoin-core-dev
3902020-06-11T18:37:21  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #19083: test: msg_mempool, fRelay, and other bloomfilter tests (master...test-bloomfilter) https://github.com/bitcoin/bitcoin/pull/19083
3912020-06-11T18:37:22  *** bitcoin-git has left #bitcoin-core-dev
3922020-06-11T18:40:26  *** rafalcpp has quit IRC
3932020-06-11T18:47:22  *** danielyin has joined #bitcoin-core-dev
3942020-06-11T18:47:49  *** danielyi1 has joined #bitcoin-core-dev
3952020-06-11T18:52:48  *** danielyin has quit IRC
3962020-06-11T18:52:49  *** danielyi1 has quit IRC
3972020-06-11T18:53:11  *** danielyin has joined #bitcoin-core-dev
3982020-06-11T18:57:29  *** gimballock has joined #bitcoin-core-dev
3992020-06-11T18:59:36  <phantomcircuit> MarcoFalke, are you the wallet maintainer?
4002020-06-11T18:59:47  <MarcoFalke> no :shock:
4012020-06-11T18:59:51  <jonasschnelli> phantomcircuit: meshcollider
4022020-06-11T19:00:17  <meshcollider> Hi :)
4032020-06-11T19:00:18  <wumpus> #startmeeting
4042020-06-11T19:00:18  <lightningbot> Meeting started Thu Jun 11 19:00:18 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
4052020-06-11T19:00:18  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
4062020-06-11T19:00:21  <achow101> hi
4072020-06-11T19:00:24  <jonasschnelli> hi
4082020-06-11T19:00:30  <hebasto> hi
4092020-06-11T19:00:31  <kanzure> hi
4102020-06-11T19:00:34  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james amiti fjahr
4112020-06-11T19:00:34  <wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
4122020-06-11T19:00:35  <jeremyrubin> hola
4132020-06-11T19:00:37  <fjahr> hi
4142020-06-11T19:00:48  <meshcollider> hi
4152020-06-11T19:00:48  <jamesob> hi
4162020-06-11T19:01:15  <jonatack> hi
4172020-06-11T19:01:16  <amiti> hi
4182020-06-11T19:01:17  <gleb> hi
4192020-06-11T19:01:28  <wumpus> hi
4202020-06-11T19:01:33  <sipa> hi
4212020-06-11T19:01:36  <troygiorshev> hi
4222020-06-11T19:01:57  <jnewbery> hi
4232020-06-11T19:02:13  <MarcoFalke> hi
4242020-06-11T19:02:15  <gwillen> hi
4252020-06-11T19:02:54  <jkczyz> hi
4262020-06-11T19:02:55  <wumpus> one proposed topic: Bump minimum required Clang version to 3.5 (hebasto)
4272020-06-11T19:03:19  <dongcarl> hebasto: links?
4282020-06-11T19:03:21  <MarcoFalke> As I posted in the thread, debian oldoldstable is on clang-4
4292020-06-11T19:03:22  <wumpus> (you can propose topics between meetings with #proposedmeetingtopic, or now before the meeting)
4302020-06-11T19:03:42  <MarcoFalke> Not sure why this is so controversial
4312020-06-11T19:03:47  <wumpus> please wait with discussion about the topic until the topic
4322020-06-11T19:03:50  <MarcoFalke> sorry
4332020-06-11T19:03:56  <dongcarl> sry
4342020-06-11T19:04:10  <jeremyrubin> #proposedmeetingtopic feature detection API
4352020-06-11T19:04:34  <wumpus> yeah you don't have to use that tag inside the meeting we see it :)
4362020-06-11T19:04:56  <jeremyrubin> (i think it helps for grepping logs)
4372020-06-11T19:04:57  <wumpus> #topic High priority for review
4382020-06-11T19:05:16  <gleb> Could I nominate #18991 for blockers? I think it's a big improvement for p2p privacy, and it would also unlock me from further work on AddrMan.
4392020-06-11T19:05:19  <gribble> https://github.com/bitcoin/bitcoin/issues/18991 | Cache responses to GETADDR to prevent topology leaks by naumenkogs · Pull Request #18991 · bitcoin/bitcoin · GitHub
4402020-06-11T19:05:24  <wumpus> 13(!) blockers, 0 bugfixes, 3 items chasing ACK https://github.com/bitcoin/bitcoin/projects/8
4412020-06-11T19:05:40  <gleb> Oh i see....
4422020-06-11T19:06:02  <jamesob> if anyone wants to see forward motion on assumeutxo, #18637 is the one to review
4432020-06-11T19:06:05  <gribble> https://github.com/bitcoin/bitcoin/issues/18637 | coins: allow cache resize after init by jamesob · Pull Request #18637 · bitcoin/bitcoin · GitHub
4442020-06-11T19:06:22  <MarcoFalke> I'd like to add #19071
4452020-06-11T19:06:24  <gribble> https://github.com/bitcoin/bitcoin/issues/19071 | doc: Separate repository for the gui by MarcoFalke · Pull Request #19071 · bitcoin/bitcoin · GitHub
4462020-06-11T19:06:26  <MarcoFalke> Not sure what is left there
4472020-06-11T19:06:40  <wumpus> gleb: added
4482020-06-11T19:07:25  <MarcoFalke> Mine is not a blocker, so feel free to ignore ;)
4492020-06-11T19:07:46  <gleb> thank you! We need couple more eyes on #18991. It's a little code with big impact, not much prior knowledge required but it would expose you to the logic of addr relay! So really nice to review please come :)
4502020-06-11T19:07:48  *** ghost43 has quit IRC
4512020-06-11T19:07:49  <gribble> https://github.com/bitcoin/bitcoin/issues/18991 | Cache responses to GETADDR to prevent topology leaks by naumenkogs · Pull Request #18991 · bitcoin/bitcoin · GitHub
4522020-06-11T19:07:56  <wumpus> 18637 is already in there
4532020-06-11T19:08:59  <wumpus> 19071 added
4542020-06-11T19:09:04  *** proofofkeags has quit IRC
4552020-06-11T19:09:04  <jamesob> wumupus: yep just additional heads-up since people seem to ask about where the project's at from time to time
4562020-06-11T19:09:05  <jnewbery> #proposedmeetingtopic Add Really Really High Priority For Review project
4572020-06-11T19:09:08  *** ghost43 has joined #bitcoin-core-dev
4582020-06-11T19:09:12  <jamesob> haha
4592020-06-11T19:09:18  <wumpus> oh noooo
4602020-06-11T19:09:37  *** proofofkeags has joined #bitcoin-core-dev
4612020-06-11T19:09:52  <wumpus> sky high elite priority for review project
4622020-06-11T19:10:19  <gleb> Jokes aside, maybe would be useful to re-iterate on the usability/usefulness of the high-prio stuff. Maybe PRs should expire from there or somehting.
4632020-06-11T19:10:57  <jamesob> that's interesting. probably no way of doing automatic expiry with github though
4642020-06-11T19:11:04  <jamesob> maybe drahtbot?
4652020-06-11T19:11:14  *** Talkless has quit IRC
4662020-06-11T19:11:16  <MarcoFalke> I found that putting something in high prio has no effect on review activity
4672020-06-11T19:11:23  <wumpus> I don't think we need automatic expiry, let's just try to pay attention ourselves
4682020-06-11T19:11:26  <gleb> I don't think it makes sense to automate such a low-latency thing.
4692020-06-11T19:11:38  <gleb> Or rather low-bandwidth I should say.
4702020-06-11T19:11:39  <wumpus> MarcoFalke: well at least I pay more attention to it, for what it's worth
4712020-06-11T19:11:57  <gleb> I just wanted to make sure wumpus and co are comfortable with evicting things from tht list.
4722020-06-11T19:11:59  <wumpus> although, the higher the number of things on there the less it matters I'd definiltly agree
4732020-06-11T19:12:08  <jonatack> jnewbery: good point. when the list is short, i follow it. when it's long, i make my own list.
4742020-06-11T19:12:29  <jeremyrubin> although review blocked, I am happy having a project
4752020-06-11T19:12:29  <wumpus> I guess it's good that every contributor can propose something that's most important for them now
4762020-06-11T19:12:52  <jeremyrubin> So maybe letting more contributors manage a project is better than the high prior for review as it is better to sort work
4772020-06-11T19:13:02  <wumpus> I'm not sure that needs any bots or automatic expiry to be honest
4782020-06-11T19:13:09  <MarcoFalke> Agree
4792020-06-11T19:13:11  <jeremyrubin> Especially if the important-ness is blocking related, projects can help hilight the follow on work
4802020-06-11T19:13:23  <jnewbery> wumpus: I agree. At the very least, it's useful for contributors to signal "this is _my_ highest priority PR right now"
4812020-06-11T19:13:31  <hebasto> a bit more projects seems good
4822020-06-11T19:13:31  <wumpus> jnewbery: exactly
4832020-06-11T19:13:48  <gleb> jnewbery: only when people look at the list :)
4842020-06-11T19:13:49  <jnewbery> but you shouldn't assume that anyone else cares :)
4852020-06-11T19:14:04  <wumpus> if no one cares, no one cares, nothing to do about that
4862020-06-11T19:14:22  *** kvaciral has joined #bitcoin-core-dev
4872020-06-11T19:14:26  *** proofofkeags has quit IRC
4882020-06-11T19:14:47  <fjahr> I think the length is ok. Reviewers just have to take a pick and often not all of them are relevant for oneself.
4892020-06-11T19:15:02  <wumpus> it's, sometimes, kind of absurd sometimes how much money sails on this project compared to how little attention review gets, but it's only one of the many mysteries
4902020-06-11T19:15:45  <jeremyrubin> wumpus: you need to tokenize review for that
4912020-06-11T19:15:52  <MarcoFalke> For some high prio stuff I am unqualfied to review because I am lacking the background, so even forcing me to review wouldn't yield anything better than a "Concept ACK"
4922020-06-11T19:16:10  <jeremyrubin> MarcoFalke: +1
4932020-06-11T19:16:13  <wumpus> yes, I don't have any solutions either, that's what I meant
4942020-06-11T19:16:41  <gleb> maybe lists per domain: wallet p2p mining consensus etc with a maintainer would make it efficient, i dunno.
4952020-06-11T19:16:49  <jnewbery> wumpus: I expect there's more effort and time going into review on this project than at any point in the past
4962020-06-11T19:16:59  <wumpus> jnewbery: I'm happy to hear that
4972020-06-11T19:17:18  <wumpus> gleb: nah…
4982020-06-11T19:17:28  <wumpus> you can already sort issues per label, you know
4992020-06-11T19:17:31  <wumpus> and PRs
5002020-06-11T19:17:59  <gleb> Right.
5012020-06-11T19:18:07  <wumpus> I don't think high priority for review is suppsoed to become that long that it needs to be sorted into categories as well
5022020-06-11T19:18:13  <wumpus> but who knows :-)
5032020-06-11T19:18:36  <MarcoFalke> The number of open pull requests keeps growing ...
5042020-06-11T19:18:40  <wumpus> I think one problem is the huge number of different concerns and aspects in one project
5052020-06-11T19:18:46  <wumpus> but we've been over that
5062020-06-11T19:19:11  <wumpus> #topic Bump minimum required Clang version to 3.5 (hebasto)
5072020-06-11T19:19:15  <hebasto> hi
5082020-06-11T19:19:18  <hebasto> negative capabilities in clang thread safety analysis are a great tool to prevent deadlocks
5092020-06-11T19:19:36  <jonatack> I agree with it remaining ad hoc. Ideally people would not put non-blocking, non-completely review-ready PRs in the list, and pull their own PRs off if less high-priority than others.
5102020-06-11T19:19:40  <wumpus> personally, I think we should hold off doing any compiler version bumps until C++17
5112020-06-11T19:19:41  <hebasto> #19249
5122020-06-11T19:19:43  <gribble> https://github.com/bitcoin/bitcoin/issues/19249 | Add means to handle negative capabilities in the Clang Thread Safety annotations by hebasto · Pull Request #19249 · bitcoin/bitcoin · GitHub
5132020-06-11T19:19:59  <MarcoFalke> I think I misunderstood what the annotation do, so I will need to re-review the changes, but if they are useful, we shouldn't hold them back for 4 months.
5142020-06-11T19:20:01  <hebasto> example of usage: #19238
5152020-06-11T19:20:03  <gribble> https://github.com/bitcoin/bitcoin/issues/19238 | refactor: Replace RecursiveMutex with Mutex in CAddrMan by hebasto · Pull Request #19238 · bitcoin/bitcoin · GitHub
5162020-06-11T19:20:31  <hebasto> example of error catching #19251
5172020-06-11T19:20:33  <gribble> https://github.com/bitcoin/bitcoin/issues/19251 | [Do Not Merge] ci: Temporary Test Case for negative capabilities in the Clang Thread Safety annotations by hebasto · Pull Request #19251 · bitcoin/bitcoin · GitHub
5182020-06-11T19:20:34  <MarcoFalke> no distro is using this ancient version of clang, and gcc is used by default to compile  anyway
5192020-06-11T19:20:35  <wumpus> I don't think requiring *everyone* to use a newer compiler just for some annotations and checking is that great
5202020-06-11T19:20:44  <sipa> wumpus: i have no strong opinion either way; bumping to (already such an old) new clang seems fairly low friction
5212020-06-11T19:20:48  <hebasto> it requires clang 3.5+
5222020-06-11T19:21:02  <MarcoFalke> wumpus: Is any os using pre-3.5 clang?
5232020-06-11T19:21:06  <wumpus> if a few peopel compile with those annotations it aleady helps
5242020-06-11T19:21:08  <dongcarl> https://repology.org/project/clang/versions
5252020-06-11T19:21:10  <wumpus> it doesn't have to be everyone
5262020-06-11T19:21:11  *** ajonas has quit IRC
5272020-06-11T19:21:14  <sipa> but if we're going to do a big bump soon anyway, that's ok too
5282020-06-11T19:21:15  <MarcoFalke> oldoldstable debian is on clang-4
5292020-06-11T19:21:43  <sipa> clang 3.5 is from 2015
5302020-06-11T19:21:44  *** adamjonas has joined #bitcoin-core-dev
5312020-06-11T19:21:44  <wumpus> I'm not necessarily opposed to this specific bump, but I think we're spending too much time doing small bumps
5322020-06-11T19:22:03  *** dviola has joined #bitcoin-core-dev
5332020-06-11T19:22:20  <wumpus> I'd like to make an "ambitious" bump for C++17, it's a good rationale
5342020-06-11T19:22:30  <MarcoFalke> This is merely a documentation change. It should have no effect in practice
5352020-06-11T19:22:41  <hebasto> agree
5362020-06-11T19:23:11  <wumpus> ok...
5372020-06-11T19:23:18  <wumpus> I don't care strongly just update it then
5382020-06-11T19:23:32  <wumpus> please don't come back next week that you need another bump though ;)
5392020-06-11T19:23:32  <jeremyrubin> Personal note that I find the safety annotations really confusing
5402020-06-11T19:23:47  <hebasto> which way?
5412020-06-11T19:24:24  <hebasto> EXCLUSIVE_LOCKS_REQUIRED(!mutex) looks good and works well
5422020-06-11T19:24:33  <MarcoFalke> if the change doesn't make it in because it is not worthwhile, clang won't be bumped
5432020-06-11T19:25:00  <wumpus> I think it's worthwhile to check
5442020-06-11T19:25:05  <wumpus> for compilers that support it
5452020-06-11T19:25:13  <jeremyrubin> I don't quite know how to use them for some of the tasks that I would like to prove safe :) Would be interested to learn more; I have a couple examples where we over-lock and I'm not sure how to use the exclusive locks required negation to accomplish that
5462020-06-11T19:25:16  <wumpus> I do not think it's a worthwhile reason to drop compilers that don't support it
5472020-06-11T19:25:17  <jeremyrubin> We can take it offline though
5482020-06-11T19:25:42  <wumpus> then again I'm not fanatic in supporting ancient stuff either
5492020-06-11T19:26:03  <wumpus> if oldoldstable is already 4.0, let's require 4.09
5502020-06-11T19:26:13  <wumpus> 4.0*
5512020-06-11T19:26:39  <MarcoFalke> Anyway, let's first check if the annotations make sense
5522020-06-11T19:27:02  <hebasto> examples are here #19238
5532020-06-11T19:27:04  <gribble> https://github.com/bitcoin/bitcoin/issues/19238 | refactor: Replace RecursiveMutex with Mutex in CAddrMan by hebasto · Pull Request #19238 · bitcoin/bitcoin · GitHub
5542020-06-11T19:27:24  <wumpus> but my point was, we *know* we're going to drop support for old compilers with C++17, so all time spend discussing bumps before that is probably wasted
5552020-06-11T19:27:56  <hebasto> so 3.5 or 4.0 ?
5562020-06-11T19:28:15  <wumpus> MarcoFalke: yes, let's be sure of that first
5572020-06-11T19:28:32  <hebasto> ok
5582020-06-11T19:28:55  <wumpus> #topic Feature detection API (jeremyrubin)
5592020-06-11T19:29:42  <jeremyrubin> Not too much; but there was some discussion on this w.r.t. people building on top of core
5602020-06-11T19:30:01  <jeremyrubin> That detecting which RPCs are available requires firing off a batch of RPCs and seeing what error codes come back
5612020-06-11T19:30:08  <jeremyrubin> This is... suboptimal
5622020-06-11T19:30:16  *** proofofkeags has joined #bitcoin-core-dev
5632020-06-11T19:30:17  <MarcoFalke> jeremyrubin: Only with whitelists
5642020-06-11T19:30:23  <jeremyrubin> MarcoFalke: no, all the time
5652020-06-11T19:30:40  <jeremyrubin> BTCPayServer does this to detect features across versions on startup
5662020-06-11T19:30:41  <jnewbery> doesn't the help RPC list all methods?
5672020-06-11T19:30:53  <MarcoFalke> Yeah, what jnewbery said ^
5682020-06-11T19:31:29  <jeremyrubin> But there's also a need to know what semantics/arguments are available and if the semantic has changed at all
5692020-06-11T19:31:37  <wumpus> well you only have to do it once
5702020-06-11T19:31:52  <MarcoFalke> jeremyrubin: The RPC version number is used for that
5712020-06-11T19:31:54  <wumpus> it's only suboptimal if you have to do it all the time, in which case, you're probably doing something wrong
5722020-06-11T19:31:56  <MarcoFalke> or you can parse the help
5732020-06-11T19:32:18  <wumpus> yes, the RPC version number would be the thing to check for that
5742020-06-11T19:32:27  <jeremyrubin> Yeah. I think it's more that we should expose some nicer way of doing this and filtering across the whitelists.
5752020-06-11T19:32:32  <sipa> i wouldn't object to an RPC that returns all supported RPCs in JSON form
5762020-06-11T19:32:39  <sipa> if that's what we're talking about
5772020-06-11T19:32:40  <jnewbery> this seems to be part of integration testing if BTCPayServer or whatever starts using a new version
5782020-06-11T19:32:47  <sipa> we already have that information ready anyway
5792020-06-11T19:33:18  <jeremyrubin> Also the whitelists are non-interpreted, so they aren't that useful because you then need to replicate the whitelist algorithm locally from it
5802020-06-11T19:33:32  <wumpus> would be nice to have a machine-interpratable version of the RPC help in general
5812020-06-11T19:33:34  *** justanotheruser has quit IRC
5822020-06-11T19:33:40  <jeremyrubin> I think there was also a desire to have per-RPC versioning
5832020-06-11T19:33:44  <wumpus> this is an idea that has been around since 2012 or so
5842020-06-11T19:33:44  <MarcoFalke> I am working on that
5852020-06-11T19:33:50  <MarcoFalke> (the machine readable help)
5862020-06-11T19:33:53  <jeremyrubin> Which IDK if it's super useful, but it was requested
5872020-06-11T19:34:08  <dongcarl> machine-readable help would just be something like an OpenAPI spec?
5882020-06-11T19:34:14  <jeremyrubin> It is nice to know if theres a breaking RPC change that you are aware on startup that there was a change
5892020-06-11T19:34:18  <wumpus> per-rpc versioning? oh no, please don't make RPC versioning any more of a hassle as it is already
5902020-06-11T19:34:50  <MarcoFalke> wumpus the rpc is versioned on the major version of Bitcoin Core https://github.com/bitcoin/bitcoin/blob/master/doc/JSON-RPC-interface.md
5912020-06-11T19:34:53  *** proofofkeags has quit IRC
5922020-06-11T19:34:55  <jeremyrubin> don't shoot the messenger. If it's an issue I'd rather just rename RPCs rpc_name_v1 when theres a change
5932020-06-11T19:35:04  <wumpus> I don't get it, what does it pprovide on top of the global version number
5942020-06-11T19:35:05  *** proofofkeags has joined #bitcoin-core-dev
5952020-06-11T19:35:20  <MarcoFalke> oh, it is the same as the global version number
5962020-06-11T19:35:25  <wumpus> in general, only major bitcoin core versions introduce breaking RPC changes
5972020-06-11T19:35:57  <wumpus> (that's how it's supposed to be, at least, if not, I guess that's a bug in itself)
5982020-06-11T19:35:58  <MarcoFalke> dongcarl: It can be anything, even just `help(format="json")` as an RPC
5992020-06-11T19:36:08  <jeremyrubin> I think it's that a major version doesn't break *everything*
6002020-06-11T19:36:12  <MarcoFalke> wumpus: Correct, that is what the doc says
6012020-06-11T19:36:16  <jeremyrubin> So it's if you need to upgrade all your logic or not
6022020-06-11T19:36:34  <wumpus> before upgrading to a new major version you need to check the release notes for all the calls you're using in your software
6032020-06-11T19:36:51  <jeremyrubin> Well the issue is that's not a developer issue
6042020-06-11T19:36:55  <jeremyrubin> that's a userland issue
6052020-06-11T19:37:02  <jeremyrubin> unless the user is bundling the node
6062020-06-11T19:37:06  <jeremyrubin> *developer
6072020-06-11T19:37:14  <wumpus> same for client software I guess
6082020-06-11T19:38:09  <jeremyrubin> Yeah so if a user starts with an older node, BTCPayServer tries to be compatible. And every developer could write their own maps of breaking changes and what works or doesn't
6092020-06-11T19:38:16  <wumpus> what would per-RPC versioning look like in any case? like, instead of calling sendtoaddress, you'd call sendtoaddress/v4 ?
6102020-06-11T19:38:22  <jeremyrubin> But i think the request is to handle it inside of core
6112020-06-11T19:38:32  <jeremyrubin> Ah, I think it would be in the get_avail_rpcs
6122020-06-11T19:38:47  <jeremyrubin> You would get a current version, and a broken at version
6132020-06-11T19:38:55  <wumpus> there was an idea like that at one point I guess
6142020-06-11T19:39:16  <jeremyrubin> so if you're expecting something v3 compliant, but it tells you broken at v4, then you can alert the user to upgrade
6152020-06-11T19:39:22  <wumpus> e.g. have an endpoint /v2  that would expose calls with new arguments
6162020-06-11T19:39:37  <jeremyrubin> yeah. I don't have a proposal for this BTW.
6172020-06-11T19:39:47  <wumpus> but, to be honest, nothing is that organized, you really need to pay attention to the major bitcoin core release in practice
6182020-06-11T19:40:09  <jeremyrubin> That's why I think it makes a good meeting topic as it's something downstream users are complaining about, and would be good to make life easier for them.
6192020-06-11T19:40:46  <jeremyrubin> I think a JSON of rpcs and available args would be good.
6202020-06-11T19:41:07  <wumpus> I still don't see how that is better than just looking at the major version. We don't need to expose release notes information on the RPC interface.
6212020-06-11T19:41:38  <sipa> i don't think the current_version and broken_at_version idea is crazy
6222020-06-11T19:41:38  <jnewbery> I think we've generally been pretty responsible with maintaining RPC compatibility. The deprecatedrpc functionality gives clients plenty of warning when anything important changes.
6232020-06-11T19:41:56  <wumpus> yes
6242020-06-11T19:42:13  <wumpus> I'm not sure for what RPCs this is a practical problem
6252020-06-11T19:42:59  <jeremyrubin> I think the reason for putting thought into it is if we're going to do *some* feature detection, we want it to be sufficiently future proof as then future feature detection would be broken
6262020-06-11T19:43:06  <jeremyrubin> if we change the feature detection API
6272020-06-11T19:43:16  *** adamjonas has quit IRC
6282020-06-11T19:43:22  <sipa> having some examples of what RPCs have caused issues in the past would be good to know, indeed
6292020-06-11T19:43:31  <dongcarl> Sounds like if this is a downstream complaint we need to look at the specific cases and see what could be done that would solve a majority of them. jeremyrubin Are there links?
6302020-06-11T19:43:34  *** ajonas has joined #bitcoin-core-dev
6312020-06-11T19:43:37  <sipa> perhaps all we need to do is be more careful about breaking compatbility
6322020-06-11T19:43:49  <jeremyrubin> https://github.com/bitcoin/bitcoin/issues/12248
6332020-06-11T19:43:57  <wumpus> sipa: especially in cases that can pass silently
6342020-06-11T19:44:14  <jeremyrubin> https://github.com/bitcoin/bitcoin/pull/19117
6352020-06-11T19:44:18  <wumpus> maybe renaming a RPC if its fields change isn't that bad an idea
6362020-06-11T19:44:51  <dongcarl> jeremyrubin: Are there links to the downstream convo?
6372020-06-11T19:44:55  <wumpus> though in general we've been careful to keep the same patern for arguments, e.g. we *still* have a dummy argument for getbalance
6382020-06-11T19:45:12  <jeremyrubin> I think the main thing I broke is batching API when using whitelists. unaware of links for their internal issue on that
6392020-06-11T19:45:52  <jeremyrubin> Because if you're using whitelists, the method of feature discovery (calling all required RPCS) fails
6402020-06-11T19:45:59  <wumpus> I'm still confused about whitelisting tbh
6412020-06-11T19:46:12  <jeremyrubin> Which calling all RPCs to discover the features is... bad. Because RPCs can do things
6422020-06-11T19:46:28  <wumpus> I don't think RPC whitelisting should have been something that ended up in bitcoind
6432020-06-11T19:46:31  <wumpus> been anyhow
6442020-06-11T19:47:18  <wumpus> some very application-specific security requirements are finding their way in
6452020-06-11T19:47:41  <jnewbery> all of this stuff seems like it should be the responsibility of a proxy
6462020-06-11T19:47:43  <wumpus> and this has nothing to do with differences between versions
6472020-06-11T19:47:46  <wumpus> jnewbery: yes
6482020-06-11T19:47:46  <jeremyrubin> dongcarl: here's the issue https://github.com/bitcoin/bitcoin/issues/19087
6492020-06-11T19:47:55  <MarcoFalke> But then different rpcusers shouldn't be in bitcoind either?
6502020-06-11T19:48:21  <jeremyrubin> I do think that we could rip out all authentication for RPCusers
6512020-06-11T19:48:35  <MarcoFalke> Just have one authpair and the proxy can deal with users
6522020-06-11T19:48:53  <jeremyrubin> It's a lot of complexity and if the answer is to proxy it just make Bitcoind not listen by default & require SSH auth'd proxy to connect
6532020-06-11T19:49:01  <wumpus> MarcoFalke: I'm not for reverting it, just, it's not a no-holds-barred pretext to introduce all kinds of per-RPC auth mechanisms into bitcoind
6542020-06-11T19:49:47  <yevaud> I think that it gives the wrong message, that unprivileged users are an expected thing. there's already a large number of people running with RPC bound to public interfaces as it is.
6552020-06-11T19:50:02  <wumpus> wait, no, don't bind RPC to public interfaces
6562020-06-11T19:50:08  <MarcoFalke> I am not for reverting it either. Just saying that we already have more than the minimal required functionality in core
6572020-06-11T19:50:21  <wumpus> this kind of people that want this are enterprises I guess, with *very specific* security and auditing requirements
6582020-06-11T19:50:40  <yevaud> by all means it allows you to have granular control of the permissions from your service, but it is easily misinterpreted.
6592020-06-11T19:51:01  <wumpus> exposing things on the public internet is just plain dumb
6602020-06-11T19:51:25  <jeremyrubin> i think public probably means internal-public
6612020-06-11T19:51:31  <wumpus> the only interface that bitcoind provides that (hopefully) is internet-hardened is P2P
6622020-06-11T19:51:39  <wumpus> anyhow, any other topics?
6632020-06-11T19:51:42  <jnewbery> It looks to me like 19087 is the result of two features interacting badly (batching and whitelists). Adding more complexity and another feature (versioning) doesn't seem like the correct remedy.
6642020-06-11T19:52:04  <jeremyrubin> So the need for versioning exists outside of the conflict there
6652020-06-11T19:52:16  <jeremyrubin> The core issue is that people are struggling to do feature detection
6662020-06-11T19:52:23  <jeremyrubin> And are calling a list of all RPCs to do that
6672020-06-11T19:52:30  <jeremyrubin> So we should have a better paradigm for that
6682020-06-11T19:52:45  <wumpus> imo: look at the major version number of bitcoin core
6692020-06-11T19:52:51  <MarcoFalke> What about the pull request that returns the RPC methods for the current user?
6702020-06-11T19:52:52  <wumpus> if you're not sure, warn the user
6712020-06-11T19:53:07  <jeremyrubin> MarcoFalke: it returns the whitelist, not the list of RPC methods
6722020-06-11T19:53:14  <wumpus> nothing will be enough to machine-represent the subtleties of differences between versions
6732020-06-11T19:53:25  <jeremyrubin> And the whitelist can contain things that aren't currently defined RPCs
6742020-06-11T19:53:46  <wumpus> whitelist has nothing to do with this
6752020-06-11T19:53:46  <jeremyrubin> Hence the issue being, what people want is a detect-avaialble-features API
6762020-06-11T19:53:53  <MarcoFalke> why can't the whitelist be sanitized before returning it?
6772020-06-11T19:54:07  <jeremyrubin> Then it's a detect available features API
6782020-06-11T19:54:23  <jeremyrubin> Which is what the issue is about; but if we're doing that it makes sense to think it through
6792020-06-11T19:54:37  <jeremyrubin> And listen to users on what sort of feature detection things they need/want
6802020-06-11T19:54:46  <jeremyrubin> And RPC versioning came up as a request
6812020-06-11T19:54:48  <wumpus> jnewbery: it definitely seems like digging in deeper after making a mistake
6822020-06-11T19:55:23  <jeremyrubin> I'm OK with just returning a filtered RPC whitelist tho, it would work, but maybe we need a v2 feature detection later which I'd want to avoid
6832020-06-11T19:55:33  <wumpus> to be clear I applaud attempts to have machine-readable documentation for RPCs like MarcoFalke is working on
6842020-06-11T19:55:38  <jonatack> jeremyrubin: wasn't there a really good external site once that documented all the RPC API versions in detail?
6852020-06-11T19:56:07  <wumpus> and if that gives a list of available RPC calls, sure, that could be useful
6862020-06-11T19:56:08  <jnewbery> jonatack: bitcoincore.org :)
6872020-06-11T19:56:20  <yevaud> https://chainquery.com/bitcoin-cli probably.
6882020-06-11T19:56:31  <jnewbery> https://bitcoincore.org/en/doc/
6892020-06-11T19:56:47  *** rafalcpp has joined #bitcoin-core-dev
6902020-06-11T19:57:36  <jeremyrubin> Anyways I agree largely it doesn't belong in core; things like the wallet also probably shouldn't be there
6912020-06-11T19:57:52  <wumpus> yes
6922020-06-11T19:57:55  <jonatack> yes, and I knew another one that was outstanding, but don't recall what it was
6932020-06-11T19:57:58  <wumpus> too much score creep
6942020-06-11T19:58:04  <wumpus> scope creep
6952020-06-11T19:58:17  <jeremyrubin> But it's just making due with helping users/devs write secure software
6962020-06-11T19:58:22  <jeremyrubin> *making do
6972020-06-11T19:58:45  <jeremyrubin> If someone has a good proxy implementation that can be put into a sub-process maybe that would help
6982020-06-11T19:58:49  <wumpus> I think a layered approach is a better way to make secure software
6992020-06-11T19:58:53  *** justanotheruser has joined #bitcoin-core-dev
7002020-06-11T20:00:02  <sipa> *DONG*
7012020-06-11T20:00:06  <wumpus> #endmeeting
7022020-06-11T20:00:06  <lightningbot> Meeting ended Thu Jun 11 20:00:06 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
7032020-06-11T20:00:06  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-06-11-19.00.html
7042020-06-11T20:00:06  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-06-11-19.00.txt
7052020-06-11T20:00:06  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-06-11-19.00.log.html
7062020-06-11T20:00:18  <dongcarl> Perhaps a good topic for some day where there aren't many topics is: what things can we remove from bitcoin-core that would have a net-positive impact?
7072020-06-11T20:00:27  <dongcarl> sipa: yes? :P
7082020-06-11T20:00:34  <hebasto> jeremyrubin: "I have a couple examples where we over-lock..." mind sharing?\
7092020-06-11T20:00:42  <jnewbery> please don't remove sipa
7102020-06-11T20:01:01  <wumpus> dongcarl: I'm just trying to prevent adding too many things
7112020-06-11T20:01:05  <aj> jnewbery: but sipa's something that has a net-positive impact, so fits dongcarl's requirements
7122020-06-11T20:01:28  <jeremyrubin> dongcarl: russ has a great way of doing that but it requires adding something big :p
7132020-06-11T20:01:31  <dongcarl> :brainfried:
7142020-06-11T20:02:02  <sipa> *floink*
7152020-06-11T20:02:03  <wumpus> we have a kitchen_sink.cpp now, that should be enough, stop adding things please xD
7162020-06-11T20:02:11  <sipa> wut?
7172020-06-11T20:02:21  <wumpus> ./src/test/fuzz/kitchen_sink.cpp
7182020-06-11T20:02:22  <achow101> dongcarl: deep fried brains?
7192020-06-11T20:02:22  <jeremyrubin> you've been removed sipa
7202020-06-11T20:02:50  <jamesob> > *DONG*
7212020-06-11T20:02:50  <jamesob> didn't know there was a gong in here
7222020-06-11T20:02:51  <sipa> hmm does that not need some kind of voting algorithm?
7232020-06-11T20:02:53  <jeremyrubin> I like MarcoFalke's suggestion of completely getting rid of credentials in core
7242020-06-11T20:03:01  <sipa> "you are the weakest link, bye bye" style
7252020-06-11T20:03:24  <dongcarl> jeremyrubin: A proxy could be maintained in a separate repo
7262020-06-11T20:03:47  <wumpus> I don't think it's worth getting rid of now
7272020-06-11T20:03:50  <jeremyrubin> I think you probably do want it to be... shipped with and started by 'bitcoind' tho
7282020-06-11T20:04:00  <MarcoFalke> Make it opt in for now -use_rpcusers_that_is_going_to_be_removed_in_2025=1
7292020-06-11T20:04:02  <MarcoFalke> then remove
7302020-06-11T20:04:02  <wumpus> checking against 3 credentials instead of 1, is not that much overhead
7312020-06-11T20:04:15  <jeremyrubin> I kind of like a model where bitcoind is a compatible set of processes that run
7322020-06-11T20:04:16  <sipa> i think getting rid of the auth mechanism is too big a breaking change
7332020-06-11T20:04:22  <wumpus> yes
7342020-06-11T20:04:25  <yevaud> "a proxy" can just be nginx, except for the rpccookie bit.
7352020-06-11T20:04:26  <jeremyrubin> and bitcoin-node is the just network process
7362020-06-11T20:04:36  <jeremyrubin> I think it doesn't have to be breaking at all
7372020-06-11T20:04:38  <sipa> yes, dreaming is nice
7382020-06-11T20:04:43  <wumpus> you can argue it shouldn't have been introduced in the first place, but it makes no sense to remove it now
7392020-06-11T20:04:58  <wumpus> you should be careful what you PR
7402020-06-11T20:05:04  <wumpus> and what you merge
7412020-06-11T20:05:55  <wumpus> pay attention and review, also conceptually
7422020-06-11T20:06:05  <wumpus> and with regard to maintenance burden
7432020-06-11T20:06:07  <yevaud> jeremyrubin: it turns out that breaking up bitcoin into different daemons needs a comical amount of state exposed, sadly.
7442020-06-11T20:06:18  <jeremyrubin> I don't think so for RPC credentials
7452020-06-11T20:06:24  <jeremyrubin> I think it's relatively small
7462020-06-11T20:06:36  <wumpus> I'm trying to be careful but too many people just want to kitchen sink everything
7472020-06-11T20:07:28  <jeremyrubin> Is anyone opposed to work that separates out RPC credentials to a different thread, makes sure there's no state leak? Then when Russ pushes through the experimental capnproto stuff it can be forked out?
7482020-06-11T20:07:49  <wumpus> it shouldn't be a different thread, no
7492020-06-11T20:07:54  <yevaud> capnproto?
7502020-06-11T20:07:59  <sipa> i don't see how any of these things are related
7512020-06-11T20:08:04  <wumpus> agree
7522020-06-11T20:08:21  <wumpus> it sounds like complicating things even more (at least inthe repository)
7532020-06-11T20:09:02  <jeremyrubin> The idea being to make the credentialing system removed from core. Doesn't need to be a thread, just an object that can pass things to core through a proxy-like interface
7542020-06-11T20:09:13  <sipa> define "removed from core"
7552020-06-11T20:09:16  <sipa> from the codebase?
7562020-06-11T20:09:18  <sipa> from the process?
7572020-06-11T20:09:24  <sipa> from the interface?
7582020-06-11T20:09:28  <wumpus> some people are actually filtering RPC and using some external proxy to filter allowed/disallowed RPC calls
7592020-06-11T20:09:36  <wumpus> no changes to bitcoin coren eeded, at all
7602020-06-11T20:09:42  <jeremyrubin> Ah
7612020-06-11T20:09:48  <jeremyrubin> I'm not just talking about the lists
7622020-06-11T20:09:55  <jeremyrubin> I'm talking about the identities as well
7632020-06-11T20:10:01  <wumpus> they can do that as well
7642020-06-11T20:10:04  <jeremyrubin> Yep
7652020-06-11T20:10:09  <wumpus> and logging
7662020-06-11T20:10:11  <wumpus> et
7672020-06-11T20:10:16  <jeremyrubin> And by removed I mean that it could be a separate binary
7682020-06-11T20:10:31  <wumpus> yes, or a script
7692020-06-11T20:10:52  <wumpus> there's nothing we need to do for this
7702020-06-11T20:10:55  <wumpus> it's socially scalable :)
7712020-06-11T20:11:39  <jeremyrubin> wumpus: it's more if you want to 'remove the crap' from Core, you can actually get rid of the code that's there
7722020-06-11T20:11:44  <yevaud> the panacea really is getting the wallet and networking into their own daemons, but that's not going to happen any time soon.
7732020-06-11T20:11:53  <wumpus> I'm not trying to remove anything, just to prevent adding it
7742020-06-11T20:12:10  <wumpus> once added it's pretty much too late
7752020-06-11T20:12:14  *** Eagle[TM] has quit IRC
7762020-06-11T20:12:25  <jeremyrubin> Ah ok. So one thing that is in favor of feature discovery in that context
7772020-06-11T20:12:47  <jeremyrubin> Is that you can write a generic proxy that learns the features from core and not have to ever touch that program
7782020-06-11T20:13:35  <jeremyrubin> So maybe there's some minimal set of features that make writing these proxies a bit better.
7792020-06-11T20:13:39  <wumpus> the proxy should already know what is allowd and what not, that shouldn't determine on the target
7802020-06-11T20:14:10  <jeremyrubin> Allowed/disallowed differs from exists/doesn't exist and versions
7812020-06-11T20:14:30  <jeremyrubin> E.g., if I configure a proxy for v1 to be safe, but v2 adds an argument which is unsafe
7822020-06-11T20:14:35  <jeremyrubin> That's a bad situation
7832020-06-11T20:14:41  <wumpus> yes before upgrading bitcoin core (definitely the major version) you need to make sure your other software is compatible
7842020-06-11T20:15:12  <jeremyrubin> Yeah i think that's just asking a bit much of the user...
7852020-06-11T20:15:30  <jeremyrubin> but I guess they'll lose their funds sooner or later if that's the case so maybe we don't care to help them?
7862020-06-11T20:15:35  <wumpus> I don't think any general mechanism can prevent that unless you can describe *every* detail of the RPC interface programatically ,and even then
7872020-06-11T20:16:05  <wumpus> wait, I don't think we should do RPC changes that can result in losing funds in the first place?!?
7882020-06-11T20:16:26  <wumpus> we've been very careful with this, even getbalance still has a dummy argument
7892020-06-11T20:16:37  <jeremyrubin> I think that's inevitable that new flags can do stupid things
7902020-06-11T20:16:56  <jeremyrubin> E.g., adding a maxFeeRate flag that previously was set to a fixed constant
7912020-06-11T20:17:07  <wumpus> if you see any RPC change that can result in old software suddenly doing destructive things please flag it on review
7922020-06-11T20:17:44  <jeremyrubin> Herculean task :p
7932020-06-11T20:17:59  <wumpus> well if it is too much of a task to pay attention to review of things like that
7942020-06-11T20:18:37  <wumpus> it's definitely too much to expect people to update some featur detection mechanism
7952020-06-11T20:18:38  <jeremyrubin> I mean to say I'm not even aware of all of the downstream software, let alone how it handles these things
7962020-06-11T20:18:47  <wumpus> be realistic here
7972020-06-11T20:19:30  <jeremyrubin> Well I think it's sort of a case of helping the developers do the right thing.
7982020-06-11T20:19:46  <jeremyrubin> I'm growing in fondness for explicit aliases for all rpcs
7992020-06-11T20:20:22  <jeremyrubin> I think swift's mangler does something where A(foo: int, bar:String?) becomes A() and A_with_bar()
8002020-06-11T20:20:59  <wumpus> you could achieve something like that by forbidding default arguments
8012020-06-11T20:21:38  <wumpus> if some new argument is added, it needs to be specified ... then again, that completely breaks backwards compatibility, which is for most people even worse I think
8022020-06-11T20:21:59  <jeremyrubin> Well... maybe not?
8032020-06-11T20:22:05  <wumpus> there's an implicit expectation already that calling the same RPCs with the same arguments keeps doing the same
8042020-06-11T20:22:26  <wumpus> if any arguments are added their default is the same as what was done before
8052020-06-11T20:22:45  <wumpus> in any case, it would help if you have specific examples of where this went wrong in the past
8062020-06-11T20:22:56  <wumpus> where people lost funds due to RPCs changing
8072020-06-11T20:23:32  <jeremyrubin> Not off the top of my head. But I can imagine someone sanitizing a JSON for arguments by checking what's there against the old arguments, but not checking for presence of new ones
8082020-06-11T20:23:33  <wumpus> if not, this is kind of an empty discussion, something that is already avoided at all ocsts
8092020-06-11T20:23:53  <jeremyrubin> and then an attacker being able to sneak in an argument that changes the behavior.
8102020-06-11T20:24:18  <wumpus> where did the attacker come from? this was about accidental version incompatiblities right
8112020-06-11T20:24:19  <jeremyrubin> Would be prevented by explicitly destructing/rebuilding the JSON with only the desired args. Don't know how common that is tho
8122020-06-11T20:24:27  * wumpus is confused, logging off for now
8132020-06-11T20:24:37  <jeremyrubin> Yeah sorry not trying to cause a kerfuffle over it
8142020-06-11T20:25:05  <jeremyrubin> I don't know what to tell end-users other than to ship their applications with a specific bitcoind version
8152020-06-11T20:25:12  <jeremyrubin> which i think is an OK answerrt
8162020-06-11T20:26:27  *** lightlike has joined #bitcoin-core-dev
8172020-06-11T20:26:43  *** SiAnDoG has quit IRC
8182020-06-11T20:27:56  <phantomcircuit> meshcollider, i've been working on the "rescanblockchain" rpc and noticed a few oddities in the wallet logic; for example #19216
8192020-06-11T20:27:58  <gribble> https://github.com/bitcoin/bitcoin/issues/19216 | wallet: Remove first parameter to ScanForWalletTransactions start_hash by pstratem · Pull Request #19216 · bitcoin/bitcoin · GitHub
8202020-06-11T20:28:16  <sipa> jeremyrubin: i think that wumpus' point is that no matter how well we try to encode compatibilities electronically, things may be too subtle and in the end people/client developers will for production use still need to refer to the release notes
8212020-06-11T20:28:32  <jeremyrubin> sipa: agree 100%.
8222020-06-11T20:28:34  <sipa> jeremyrubin: but at the same time, solving compatibility is a much more widely scoped problem than the security side
8232020-06-11T20:28:48  <sipa> RPC changes should not impact security
8242020-06-11T20:28:49  <phantomcircuit> meshcollider, im going through other parameters looking for oddities as well
8252020-06-11T20:29:54  <harding> This is what I tell devs to do if they want to learn all the differences in RPCs between releases: https://github.com/zkSNACKs/WalletWasabi/issues/3037#issuecomment-581143233
8262020-06-11T20:29:55  <wumpus> yes, I think that's another reason I'm confused about things like whitelists and credentials, the RPC interface was never supposed to be hardened against attackers like that, it was supposed to be a trusted interface for applications
8272020-06-11T20:30:28  <jeremyrubin> sipa: in the example I was giving above I was imagining some frontend app passes a JSON of a desired RPC call. The server checks all the arguments it knows about for that rpc, and sends to the server. But a new RPC was added in the new version of core running. Then the frontend-hacker adds that parameter. And a bad RPC call accidentally gets passed.
8282020-06-11T20:31:06  <sipa> jeremyrubin: if the frontend that does the security check is compromised, i don't see how problems can be avoided?
8292020-06-11T20:31:19  <jeremyrubin> No the backend server is doing the check
8302020-06-11T20:31:42  <sipa> ok, then i don't understand the problem
8312020-06-11T20:32:16  <jeremyrubin> Ok. So imagine v1 RPC A has arg 'good'. V2 adds arg 'bad' default = 0
8322020-06-11T20:32:29  <MarcoFalke> I plan to write a feature detection in 5 lines of python and add it to the test framework. No changes to core required.
8332020-06-11T20:32:34  <sipa> jeremyrubin: that should never happen
8342020-06-11T20:32:52  <MarcoFalke> We might be over-engineering this a bit
8352020-06-11T20:32:54  <jeremyrubin> sipa: why not? We add default args all the time.
8362020-06-11T20:33:07  <sipa> and they shouldn't impact security
8372020-06-11T20:33:10  <jeremyrubin> and the 'bad' one by default does nothing
8382020-06-11T20:33:19  *** Pavlenex has quit IRC
8392020-06-11T20:33:24  <jeremyrubin> But we add ones that could impact security if set to a bad value?
8402020-06-11T20:33:41  <wumpus> sipa: exactly, that should already never happen, so there shouldn't be need to describe it
8412020-06-11T20:33:41  <jeremyrubin> things like feerates
8422020-06-11T20:33:58  <wumpus> which was my point with catching these things at review time
8432020-06-11T20:34:22  <sipa> jeremyrubin: i'm still missing part of your context
8442020-06-11T20:34:31  <sipa> "the server checks ... and sends to the server"
8452020-06-11T20:34:36  <jeremyrubin> Ah yeah I was still explaining but you told me that I was already off
8462020-06-11T20:34:37  <sipa> there are multiple servers involved?
8472020-06-11T20:34:44  <sipa> ok
8482020-06-11T20:34:48  <jeremyrubin> There's a frontend, a backend, and a core node
8492020-06-11T20:35:00  <jeremyrubin> (I'll tell you when I'm done)
8502020-06-11T20:35:22  <jeremyrubin> Frontend generates and RPC, passes it to the backend. Backend sanitizes, passes to core
8512020-06-11T20:35:40  <jeremyrubin> v1: A good. v2: A good, bad=0
8522020-06-11T20:36:04  <sipa> sounds like the backends needs to disallow parameters it does not know about
8532020-06-11T20:36:04  <jeremyrubin> the backend initially checks that A.good is 0 or 1
8542020-06-11T20:36:07  <jeremyrubin> Yes
8552020-06-11T20:36:19  <jeremyrubin> My point being that originally Core was doing this check
8562020-06-11T20:36:30  <jeremyrubin> And then when the default arg gets introduced core stops doing this
8572020-06-11T20:36:36  <wumpus> exactly, the security checking thing should be careful to only pass through what it knows about
8582020-06-11T20:36:49  <wumpus> this was always the case
8592020-06-11T20:36:50  *** Kiminuo has quit IRC
8602020-06-11T20:36:51  <jeremyrubin> So when core goes V1 -> V2 there's a potential for a security issue
8612020-06-11T20:36:53  <sipa> jeremyrubin: that's why a security-enforcing proxy needs to work with whitelisting
8622020-06-11T20:37:04  <sipa> per RPC, per parameter
8632020-06-11T20:37:20  <jeremyrubin> I don't think we're disagreeing on any of this
8642020-06-11T20:37:31  <sipa> then i don't see the problem
8652020-06-11T20:38:07  <jeremyrubin> I'm just saying I don't think it's that common that this happens, and there's an opportunity to introduce some stuff that helps prevent these bugs.
8662020-06-11T20:38:19  <jeremyrubin> I don't think it eliminates them
8672020-06-11T20:38:46  <jeremyrubin> But I think it could help reasonable app developers not have these sorts of mistake
8682020-06-11T20:38:55  <sipa> ok, i agree there - but i don't think it's worth the complexity, especially as it risks giving a false sense of security
8692020-06-11T20:39:39  <jeremyrubin> fwiw my proposal is essentially an API where you do feature detect and fail to start if it doesn't match your expected feature set
8702020-06-11T20:39:54  <sipa> changes to the RPC interface should be safe in such a way that if an RPC that worked in the past was fine, if it still exists in the new version, is still fine
8712020-06-11T20:40:32  <sipa> jeremyrubin: but how do you define feature? is a slightly different way that ping messages are scheduled a feature change? because it may be observable through the minping field
8722020-06-11T20:41:02  <sipa> and if feature changes are restricted to things that could have a security impact... the probably just shouldn't happen
8732020-06-11T20:41:32  <jeremyrubin> You know it's a good question to ask more of the app developers (e.g., LN btcpay)
8742020-06-11T20:42:11  <jeremyrubin> I think it's also an interesting question if there were a change we had to make for security, how would we make sure old software didn't do the broken thing on new nodes (hopefully never happens but you never know)
8752020-06-11T20:42:32  <jeremyrubin> Again I don't really have a concrete proposal here
8762020-06-11T20:42:34  <sipa> we could rename RPCs if we're somehow forced to change their semantics very substantially
8772020-06-11T20:42:48  <jeremyrubin> I just know that calling all the RPCs in a batch to see what's on sounds like a very wrong idea
8782020-06-11T20:43:05  <jeremyrubin> And would like to help BTCPayServer not do that
8792020-06-11T20:43:19  <sipa> yes, they should check version numbers - i agree
8802020-06-11T20:43:24  <sipa> with wumpus
8812020-06-11T20:43:30  <jeremyrubin> Maybe a good one is just an RPC where you submit a list of RPCs an arguments intended to the node
8822020-06-11T20:43:31  <sipa> and just fail to start if it's not a known one
8832020-06-11T20:44:04  <jeremyrubin> Yeah that could be the answer
8842020-06-11T20:44:21  <meshcollider> phantomcircuit: sounds good :)
8852020-06-11T20:44:59  <jeremyrubin> I do know that RPC whitelisting did expose this problem by changing what batching returns when something isn't whitelisted in the batch. So I regret that. But seems like there should be a good answer of what BTCPayServer should implement instead of that for detection
8862020-06-11T20:45:16  <jeremyrubin> NicolasDorier: ^^^ stop it :)
8872020-06-11T20:45:27  <sipa> and we could automate some things, which would mean that generally client versions will break slightly less often when facing an unknown server... but if semantics are super critical, that still risks breaking things, and they still really should just check the version number
8882020-06-11T20:45:54  *** dgenr8 has quit IRC
8892020-06-11T20:47:20  <jeremyrubin> Ah!
8902020-06-11T20:47:39  <jeremyrubin> Here's a great reason to do this; makes people more likely to upgrade their supported node version :p
8912020-06-11T20:48:19  *** dgenr8 has joined #bitcoin-core-dev
8922020-06-11T20:48:55  <jeremyrubin> But I'm basically at my depth on this issue; I don't have a current major core-dependent app dealing with compatibility issues so it is really a matter of e.g. roasbeef, NicolasDorier to chime in on it.
8932020-06-11T20:49:46  <jeremyrubin> I think in terms of the actual Bug I'm OK with wontfix if you're using batching + whitelist with non whitelisted rpcs
8942020-06-11T20:50:14  <sipa> it sounds like the batching/whitelist implementation was just broken?
8952020-06-11T20:50:23  <jeremyrubin> Not really?
8962020-06-11T20:50:42  <sipa> i'm not familiar with the issue
8972020-06-11T20:50:56  <jeremyrubin> So if you call a batch
8982020-06-11T20:51:03  <jeremyrubin> and one of the RPCs is not whitelisted
8992020-06-11T20:51:09  <jeremyrubin> It will call the prefix
9002020-06-11T20:51:21  <jeremyrubin> and then just return the RPC not found for the whole thing
9012020-06-11T20:51:30  <jeremyrubin> rather than RPC not found for that specific RPC
9022020-06-11T20:51:39  <jeremyrubin> as the batch result
9032020-06-11T20:51:44  <jeremyrubin> Was my understanding of the issue
9042020-06-11T20:51:48  <sipa> that sounds like a bug?
9052020-06-11T20:52:31  <jeremyrubin> https://github.com/bitcoin/bitcoin/issues/19087#issuecomment-636883880
9062020-06-11T20:53:08  <jeremyrubin> I mean the bigger picture issue is that this *should* have come up in review and integration testing
9072020-06-11T20:53:15  <jeremyrubin> as it seems to break btcpayserver on startup
9082020-06-11T20:53:28  <jeremyrubin> And whitelistrpc has been merged for a while
9092020-06-11T20:53:29  <sipa> and it should definitely have come up during rc testing...
9102020-06-11T20:53:47  <jeremyrubin> It's not like some corner case issue
9112020-06-11T20:54:07  <sipa> but i don't see why we can't just fix this in 0.20.1
9122020-06-11T20:54:51  <jeremyrubin> It can be fixed, but permanently 0.20 will be hard to start against for BTCPayServer if using rpcwhitelist
9132020-06-11T20:54:53  <sipa> sure, they should have a better way of doing feature detection, but it sounds like this just gratutiously broke compatibility, so we should restore it?
9142020-06-11T20:55:07  <sipa> well that's what you have bugfix releases for
9152020-06-11T20:55:32  <sipa> bugs happen, and sometimes they're detected too late
9162020-06-11T20:55:35  <jeremyrubin> Well it didn't break it thaaat gratuitously. If you don't use RPC Whitelist OR you detect features differently, it would not come up
9172020-06-11T20:55:57  <sipa> by gratuitously i don't mean that this was trivial to find; just that it comes at no benefit
9182020-06-11T20:56:10  *** promag has joined #bitcoin-core-dev
9192020-06-11T20:56:13  <sipa> as in: i don't expect anyone to (want to) rely on the new behavior
9202020-06-11T20:56:23  <jeremyrubin> Ah. Yes. Agree 100%
9212020-06-11T20:56:27  <sipa> so we should fix it
9222020-06-11T20:56:31  <jeremyrubin> The new behavior is obviously a defect
9232020-06-11T20:56:58  <sipa> the feature discovery (or version checking) discussion is orthogonal
9242020-06-11T20:57:11  <jeremyrubin> It is, which is what I've been trying to get across
9252020-06-11T20:57:35  <jeremyrubin> There's a defect. The reason we found it was doing X. X is shocking. We should fix the defect and provide a better way to X
9262020-06-11T20:58:07  <sipa> or tell people that instead of X, they should be doing Y which is already possible instead :)
9272020-06-11T20:58:14  <sipa> but we should still fix the defect
9282020-06-11T20:59:04  <sipa> is there an issue (or PR) for the fix?
9292020-06-11T20:59:06  <jeremyrubin> Sure... which is sort of the question that started this. What is Y? Is just parsing the help page sufficient? Should we JSON expose it?
9302020-06-11T20:59:12  <jeremyrubin> sipa: no, not yet.
9312020-06-11T20:59:23  <sipa> Y is checking the version number
9322020-06-11T21:00:02  *** jtk has quit IRC
9332020-06-11T21:00:20  <jeremyrubin> I think that it's sort of a 'draw the fucking owl' answer though. So check the version number and hardcode all RPCs and the arguments they can take?
9342020-06-11T21:00:46  <wumpus> also, as said, there is work underway in making the help more programatically parsable, so if that's what you want to do it's only going to become easier
9352020-06-11T21:01:29  <sipa> jeremyrubin: i mean... what are they doing with the information about which RPCs are available? presumably pretty much something like that already?
9362020-06-11T21:02:08  <wumpus> of course it's never going to be a perfect representation fully covering all changes and all subtleties, it's not there to give a false sense of security
9372020-06-11T21:03:32  <jeremyrubin> sipa: good question? Not sure. I would imagine some kind of start with assuming a base version with X features and a dispatch table of functionality that implemented inefficiently client side. See what comes back and replace the client versions with RPC versions?
9382020-06-11T21:04:00  <sipa> yes
9392020-06-11T21:04:13  <jeremyrubin> So the code is never aware of what version at all, just aware of what's allowed and adds the on-node versions as applicable.
9402020-06-11T21:04:27  <jeremyrubin> There's no mapping of version 18 has Y and version 19 has Y + Z
9412020-06-11T21:04:35  <jeremyrubin> but i'm not sure
9422020-06-11T21:04:42  <jeremyrubin> That's just a guess
9432020-06-11T21:04:45  <promag> jnewbery: https://github.com/bitcoin/bitcoin/projects/2 needs minor update
9442020-06-11T21:04:46  <sipa> i think we're grasping at straws
9452020-06-11T21:05:19  <jeremyrubin> yeah I'll defer to roasbeef and NicolasDorier who probably have the best knowledge on their use case
9462020-06-11T21:05:43  <promag> 1. replace #17457 with #18894 (which is already merged) and 2. #15202 is merged too
9472020-06-11T21:05:46  <gribble> https://github.com/bitcoin/bitcoin/issues/17457 | gui: Fix manual coin control with multiple wallets loaded by promag · Pull Request #17457 · bitcoin/bitcoin · GitHub
9482020-06-11T21:05:48  <gribble> https://github.com/bitcoin/bitcoin/issues/18894 | gui: Fix manual coin control with multiple wallets loaded by promag · Pull Request #18894 · bitcoin/bitcoin · GitHub
9492020-06-11T21:05:51  <gribble> https://github.com/bitcoin/bitcoin/issues/15202 | gui: Add Close All Wallets action by promag · Pull Request #15202 · bitcoin/bitcoin · GitHub
9502020-06-11T21:10:43  <dongcarl> jonasschnelli: Rebased your 2019/08/net_v2 branch using the commits from the latest PRs here: https://github.com/bitcoin/bitcoin/compare/master...dongcarl:2020-06-netv2-no-simplify, the netv2 test fails due to UB, is this worth pursuing or shall I wait until there's more work on the BIP?
9512020-06-11T21:11:23  <jeremyrubin> sipa: wumpus: apologies for the drawn out conversation here. It's not a particularly major thing I'm trying to get in for Core, but I just feel somewhat responsible for having introduced it to advocate for the users even if I don't really know what they want/need on this one.
9522020-06-11T21:13:42  *** Guyver2 has quit IRC
9532020-06-11T21:29:02  *** Chris_Stewart_5 has quit IRC
9542020-06-11T21:32:41  <jnewbery> promag: done. Thank you for you persistance on multiwallet!
9552020-06-11T21:36:05  <promag> jnewbery: https://imgflip.com/i/44tpti
9562020-06-11T21:42:19  *** Dali has joined #bitcoin-core-dev
9572020-06-11T21:44:51  *** Dali has left #bitcoin-core-dev
9582020-06-11T21:55:59  *** rafalcpp has quit IRC
9592020-06-11T21:56:44  *** fredy2 has joined #bitcoin-core-dev
9602020-06-11T22:02:28  *** pinheadm_ has joined #bitcoin-core-dev
9612020-06-11T22:03:56  *** danielyin has left #bitcoin-core-dev
9622020-06-11T22:04:26  *** justanotheruser has quit IRC
9632020-06-11T22:05:38  *** pinheadmz has quit IRC
9642020-06-11T22:07:26  *** danielyin has joined #bitcoin-core-dev
9652020-06-11T22:23:30  *** justanotheruser has joined #bitcoin-core-dev
9662020-06-11T22:33:09  *** lightlike has quit IRC
9672020-06-11T22:48:21  *** rafalcpp has joined #bitcoin-core-dev
9682020-06-11T22:52:59  *** AaronvanW has quit IRC
9692020-06-11T23:14:23  *** sipsorcery has quit IRC
9702020-06-11T23:36:16  *** gimballock has quit IRC
9712020-06-11T23:38:44  *** proofofkeags has quit IRC
9722020-06-11T23:39:20  *** proofofkeags has joined #bitcoin-core-dev
9732020-06-11T23:43:47  *** proofofkeags has quit IRC
9742020-06-11T23:51:58  *** rafalcpp has quit IRC
9752020-06-11T23:59:35  *** pinheadm_ has quit IRC