12020-07-09T00:00:01  *** kir has quit IRC
   22020-07-09T00:05:43  *** AaronvanW has quit IRC
   32020-07-09T00:07:54  *** afk11` has quit IRC
   42020-07-09T00:08:19  *** afk11` has joined #bitcoin-core-dev
   52020-07-09T00:13:06  *** troygiorshev has quit IRC
   62020-07-09T00:14:48  *** troygiorshev has joined #bitcoin-core-dev
   72020-07-09T00:17:58  *** diogorsergio has quit IRC
   82020-07-09T00:18:07  *** bitdex has joined #bitcoin-core-dev
   92020-07-09T00:32:24  *** mdunnio has joined #bitcoin-core-dev
  102020-07-09T00:37:25  *** mdunnio has quit IRC
  112020-07-09T00:51:09  *** hegemoOn1 has joined #bitcoin-core-dev
  122020-07-09T00:53:20  *** Relis has quit IRC
  132020-07-09T01:00:46  *** mdunnio has joined #bitcoin-core-dev
  142020-07-09T01:04:46  *** diogorsergio has joined #bitcoin-core-dev
  152020-07-09T01:10:09  *** promag has quit IRC
  162020-07-09T01:19:19  *** Relis has joined #bitcoin-core-dev
  172020-07-09T01:21:26  *** Relis has quit IRC
  182020-07-09T01:23:05  *** Relis has joined #bitcoin-core-dev
  192020-07-09T02:01:25  *** mdunnio has quit IRC
  202020-07-09T02:02:03  *** Relis has quit IRC
  212020-07-09T02:02:33  *** Relis has joined #bitcoin-core-dev
  222020-07-09T02:09:11  *** arowser has quit IRC
  232020-07-09T02:09:30  *** arowser has joined #bitcoin-core-dev
  242020-07-09T02:19:36  *** Highway61 has quit IRC
  252020-07-09T02:22:05  *** shesek has quit IRC
  262020-07-09T02:22:32  *** shesek has joined #bitcoin-core-dev
  272020-07-09T02:40:19  *** Relis has quit IRC
  282020-07-09T03:00:02  *** hegemoOn1 has quit IRC
  292020-07-09T03:04:08  *** arowser has quit IRC
  302020-07-09T03:05:29  *** arowser has joined #bitcoin-core-dev
  312020-07-09T03:16:57  *** Linu741 has joined #bitcoin-core-dev
  322020-07-09T03:22:43  *** dr-orlovsky has quit IRC
  332020-07-09T03:23:19  *** dr_orlovsky has joined #bitcoin-core-dev
  342020-07-09T03:30:52  *** vasild_ has joined #bitcoin-core-dev
  352020-07-09T03:33:43  *** vasild has quit IRC
  362020-07-09T03:33:44  *** vasild_ is now known as vasild
  372020-07-09T03:43:46  *** jarthur_ has joined #bitcoin-core-dev
  382020-07-09T03:46:58  *** jarthur has quit IRC
  392020-07-09T04:55:18  *** ppisati has quit IRC
  402020-07-09T05:02:02  *** ppisati has joined #bitcoin-core-dev
  412020-07-09T05:06:08  *** gleb has joined #bitcoin-core-dev
  422020-07-09T05:11:26  *** promag has joined #bitcoin-core-dev
  432020-07-09T05:15:34  *** promag has quit IRC
  442020-07-09T05:25:16  *** jonatack has quit IRC
  452020-07-09T05:35:12  *** jonatack has joined #bitcoin-core-dev
  462020-07-09T05:38:26  *** arowser has quit IRC
  472020-07-09T05:39:33  *** arowser has joined #bitcoin-core-dev
  482020-07-09T05:54:23  *** bitcoin-git has joined #bitcoin-core-dev
  492020-07-09T05:54:23  <bitcoin-git> [bitcoin] jnewbery closed pull request #17601: Validation: Move CheckBlock() mutation guard to AcceptBlock() (master...2019-11-checkblock-in-acceptblock) https://github.com/bitcoin/bitcoin/pull/17601
  502020-07-09T05:54:24  *** bitcoin-git has left #bitcoin-core-dev
  512020-07-09T06:00:01  *** Linu741 has quit IRC
  522020-07-09T06:07:36  *** arowser has quit IRC
  532020-07-09T06:08:36  *** arowser has joined #bitcoin-core-dev
  542020-07-09T06:11:26  *** marcoagner has joined #bitcoin-core-dev
  552020-07-09T06:20:06  *** kirkland1 has joined #bitcoin-core-dev
  562020-07-09T06:21:41  *** vincenzopalazzo has quit IRC
  572020-07-09T06:40:11  *** arowser has quit IRC
  582020-07-09T06:40:45  *** arowser has joined #bitcoin-core-dev
  592020-07-09T06:55:00  *** elichai2 has quit IRC
  602020-07-09T06:55:03  *** bitdex has quit IRC
  612020-07-09T06:55:40  *** elichai2 has joined #bitcoin-core-dev
  622020-07-09T06:55:41  *** jakesyl has quit IRC
  632020-07-09T06:56:08  *** arowser has quit IRC
  642020-07-09T06:56:13  *** jakesyl has joined #bitcoin-core-dev
  652020-07-09T06:58:17  *** arowser has joined #bitcoin-core-dev
  662020-07-09T07:01:03  *** Pavlenex has joined #bitcoin-core-dev
  672020-07-09T07:11:32  *** davec has quit IRC
  682020-07-09T07:15:12  *** zaff has joined #bitcoin-core-dev
  692020-07-09T07:18:43  *** davec has joined #bitcoin-core-dev
  702020-07-09T07:19:34  *** AaronvanW has joined #bitcoin-core-dev
  712020-07-09T07:22:37  *** bitdex has joined #bitcoin-core-dev
  722020-07-09T07:23:05  *** davec has quit IRC
  732020-07-09T07:29:48  *** davec has joined #bitcoin-core-dev
  742020-07-09T07:33:18  *** bitcoin-git has joined #bitcoin-core-dev
  752020-07-09T07:33:19  <bitcoin-git> [bitcoin] hebasto opened pull request #19473: net: Add -networkactive option  (master...200709-setnet) https://github.com/bitcoin/bitcoin/pull/19473
  762020-07-09T07:33:20  *** bitcoin-git has left #bitcoin-core-dev
  772020-07-09T07:35:03  *** Guyver2 has joined #bitcoin-core-dev
  782020-07-09T07:35:31  *** vasild has quit IRC
  792020-07-09T07:35:54  *** gleb has quit IRC
  802020-07-09T07:37:24  *** Pavlenex1 has joined #bitcoin-core-dev
  812020-07-09T07:39:34  *** Pavlenex has quit IRC
  822020-07-09T07:39:34  *** Pavlenex1 is now known as Pavlenex
  832020-07-09T07:40:46  *** vasild has joined #bitcoin-core-dev
  842020-07-09T08:03:36  *** vfP56jSe has quit IRC
  852020-07-09T08:04:49  *** vfP56jSe has joined #bitcoin-core-dev
  862020-07-09T08:09:09  *** arowser has quit IRC
  872020-07-09T08:09:34  *** arowser has joined #bitcoin-core-dev
  882020-07-09T08:19:13  <fanquake> jonatack: are you using the (I assume self-built) Clang master branch for development/review?
  892020-07-09T08:21:34  <jonatack> fanquake: i changed from using debian stable to debian testing and added "deb http://apt.llvm.org/unstable/ llvm-toolchain main" to etc/apt/sources.list
  902020-07-09T08:23:08  <fanquake> Right. Why not use Clang 9/10 though?
  912020-07-09T08:25:28  <jonatack> No strong opinion yet, updated only last weekend. Which do you think is best for development/review?
  922020-07-09T08:27:16  <jonatack> My motivation was for testing the cfields' span PR with -Wdangling and have clang-format work again (it's currently broken for clang < 9)
  932020-07-09T08:27:42  <fanquake> Preferably a compiler that in not unreleased/WIP. 9 or 10 shouldn't make much difference. I was just curious after seeing your review comments.
  942020-07-09T08:29:17  <jonatack> Ok. FWIW #19454 fixes .clang-format for clang < 9, e.g. Debian stable
  952020-07-09T08:29:18  <gribble> https://github.com/bitcoin/bitcoin/issues/19454 | tools: `.clang-format` compat with clang versions < 9 by jonatack · Pull Request #19454 · bitcoin/bitcoin · GitHub
  962020-07-09T08:29:52  <jonatack> Will go for 10.
  972020-07-09T08:41:31  *** Pavlenex has quit IRC
  982020-07-09T08:51:46  *** arowser has quit IRC
  992020-07-09T08:52:51  *** arowser has joined #bitcoin-core-dev
 1002020-07-09T08:58:04  *** dr_orlovsky has quit IRC
 1012020-07-09T08:58:48  *** dr-orlovsky has joined #bitcoin-core-dev
 1022020-07-09T09:00:02  *** kirkland1 has quit IRC
 1032020-07-09T09:04:10  *** arowser has quit IRC
 1042020-07-09T09:04:29  *** arowser has joined #bitcoin-core-dev
 1052020-07-09T09:18:08  *** someone235 has joined #bitcoin-core-dev
 1062020-07-09T09:19:17  <someone235> Hi, does bitcoin core keep node ban score even if it reconnects (even if it's below the ban threshold)?
 1072020-07-09T09:19:44  <sipa> no
 1082020-07-09T09:21:49  *** bitprophet1 has joined #bitcoin-core-dev
 1092020-07-09T09:30:39  *** Highway61 has joined #bitcoin-core-dev
 1102020-07-09T09:34:10  <someone235> Thanks!
 1112020-07-09T09:34:19  <someone235> What's the reasoning behind it?
 1122020-07-09T09:35:39  <someone235> I would expect it to be kept so you reconnect each time your ban score is 90
 1132020-07-09T09:36:39  <sipa> ban score logic doesn't prevent attacks
 1142020-07-09T09:36:50  <sipa> it prevents wasting connection slots on broken software
 1152020-07-09T09:36:51  <someone235> Sorry, I mean, so you *wont* reconnect each time your ban score is 90
 1162020-07-09T09:37:19  <sipa> and i think ban scores as a concept should just go away
 1172020-07-09T09:37:41  <someone235> Why?
 1182020-07-09T09:38:17  <jonatack> someone235: good explanation why here: https://github.com/bitcoin/bitcoin/pull/19219#issuecomment-652684340
 1192020-07-09T09:38:20  <sipa> if a client miabehaves they should be disconnected and/or banned immediately
 1202020-07-09T09:38:53  <sipa> if they don't, we ahouldn't confuse things by maybe later doing that when some threshold is reached
 1212020-07-09T09:38:59  <sipa> it just obscores things for no benefit
 1222020-07-09T09:39:25  <someone235> Yeah, if we're talking about not talking with broken nodes I tend to agree
 1232020-07-09T09:39:53  <sipa> yeah see jonatack's link
 1242020-07-09T09:42:31  <someone235> But how will you deal with attackers? Like people who sends you full invalid blocks?
 1252020-07-09T09:42:39  <someone235> *send
 1262020-07-09T09:43:41  <sipa> ban them
 1272020-07-09T09:43:44  <sipa> immediately
 1282020-07-09T09:43:48  <someone235> oh right
 1292020-07-09T09:43:54  <sipa> but also
 1302020-07-09T09:43:58  <someone235> and bans are kept between reconnects
 1312020-07-09T09:44:05  <someone235> and restarts
 1322020-07-09T09:44:25  <sipa> there are plenty of ways to trivially DoS attack nodes by doing completely legitimate things
 1332020-07-09T09:44:31  <sipa> that we can't ban for
 1342020-07-09T09:45:42  <sipa> the eventual way to deal with that imho is tracking how muxh resources we spend on behalf of each peer
 1352020-07-09T09:46:06  <sipa> and if we run out, deprioritize or disconnect the worst offenders (without banning)
 1362020-07-09T09:49:10  *** promag has joined #bitcoin-core-dev
 1372020-07-09T09:52:24  *** zaff has quit IRC
 1382020-07-09T09:52:45  *** zaff has joined #bitcoin-core-dev
 1392020-07-09T10:03:22  *** Parker32Connelly has joined #bitcoin-core-dev
 1402020-07-09T10:10:39  *** Parker32Connelly has quit IRC
 1412020-07-09T10:22:50  *** promag has quit IRC
 1422020-07-09T10:23:53  *** promag has joined #bitcoin-core-dev
 1432020-07-09T10:25:12  *** arowser has quit IRC
 1442020-07-09T10:25:40  *** arowser has joined #bitcoin-core-dev
 1452020-07-09T10:28:44  *** Highway61 has quit IRC
 1462020-07-09T10:28:56  *** Highway61 has joined #bitcoin-core-dev
 1472020-07-09T10:32:14  *** harrigan has quit IRC
 1482020-07-09T10:33:12  *** harrigan has joined #bitcoin-core-dev
 1492020-07-09T10:40:31  *** bitcoin-git has joined #bitcoin-core-dev
 1502020-07-09T10:40:31  <bitcoin-git> [bitcoin] kiminuo closed pull request #19466: Use operator/ in fs::absolute to prepare for C++17 (master...feature/2020-07-08-fs-paths) https://github.com/bitcoin/bitcoin/pull/19466
 1512020-07-09T10:40:32  *** bitcoin-git has left #bitcoin-core-dev
 1522020-07-09T10:52:56  *** reallll has joined #bitcoin-core-dev
 1532020-07-09T10:55:56  *** bitcoin-git has joined #bitcoin-core-dev
 1542020-07-09T10:55:57  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f7c19e829eca...c4a44186d816
 1552020-07-09T10:55:58  <bitcoin-git> bitcoin/master e846a2a John Newbery: refactor: clean up PeriodicFlush()
 1562020-07-09T10:55:58  <bitcoin-git> bitcoin/master c4a4418 MarcoFalke: Merge #19085: Refactor: clean up PeriodicFlush()
 1572020-07-09T10:56:08  *** bitcoin-git has left #bitcoin-core-dev
 1582020-07-09T10:56:22  *** belcher_ has quit IRC
 1592020-07-09T10:56:36  *** bitcoin-git has joined #bitcoin-core-dev
 1602020-07-09T10:56:37  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #19085: Refactor: clean up PeriodicFlush() (master...2020-05-refactor-periodic-flush) https://github.com/bitcoin/bitcoin/pull/19085
 1612020-07-09T10:56:37  *** bitcoin-git has left #bitcoin-core-dev
 1622020-07-09T11:03:08  *** arowser has quit IRC
 1632020-07-09T11:03:32  *** arowser has joined #bitcoin-core-dev
 1642020-07-09T11:18:43  *** sdaftuar_ has quit IRC
 1652020-07-09T11:19:17  *** sdaftuar_ has joined #bitcoin-core-dev
 1662020-07-09T11:19:48  *** reallll is now known as belcher
 1672020-07-09T11:20:58  *** Relis has joined #bitcoin-core-dev
 1682020-07-09T11:43:10  *** arowser has quit IRC
 1692020-07-09T11:43:38  *** arowser has joined #bitcoin-core-dev
 1702020-07-09T11:47:59  *** promag has quit IRC
 1712020-07-09T11:48:35  *** promag has joined #bitcoin-core-dev
 1722020-07-09T11:56:10  *** arowser has quit IRC
 1732020-07-09T11:56:59  *** arowser has joined #bitcoin-core-dev
 1742020-07-09T11:59:43  *** bitcoin-git has joined #bitcoin-core-dev
 1752020-07-09T11:59:43  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c4a44186d816...6b48c30541e4
 1762020-07-09T11:59:44  <bitcoin-git> bitcoin/master b9253c7 Jon Atack: tools: clang-format 6 compatibility
 1772020-07-09T11:59:44  <bitcoin-git> bitcoin/master 6b48c30 fanquake: Merge #19454: tools: `.clang-format` compat with clang versions < 9
 1782020-07-09T11:59:46  *** bitcoin-git has left #bitcoin-core-dev
 1792020-07-09T12:00:01  *** bitprophet1 has quit IRC
 1802020-07-09T12:00:03  *** bitcoin-git has joined #bitcoin-core-dev
 1812020-07-09T12:00:03  <bitcoin-git> [bitcoin] fanquake merged pull request #19454: tools: `.clang-format` compat with clang versions < 9 (master...clang-6-compatibility) https://github.com/bitcoin/bitcoin/pull/19454
 1822020-07-09T12:00:04  *** bitcoin-git has left #bitcoin-core-dev
 1832020-07-09T12:08:14  *** troygiorshev has quit IRC
 1842020-07-09T12:09:14  *** troygiorshev has joined #bitcoin-core-dev
 1852020-07-09T12:22:03  *** sora_h has joined #bitcoin-core-dev
 1862020-07-09T12:30:23  *** bitcoin-git has joined #bitcoin-core-dev
 1872020-07-09T12:30:24  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/6b48c30541e4...e3b31255c5ad
 1882020-07-09T12:30:24  <bitcoin-git> bitcoin/master 0b8ba84 fanquake: banlist: log post-swept banlist size at startup
 1892020-07-09T12:30:25  <bitcoin-git> bitcoin/master e3b3125 fanquake: Merge #19470: banlist: log post-swept banlist size at startup
 1902020-07-09T12:30:34  *** bitcoin-git has left #bitcoin-core-dev
 1912020-07-09T12:30:53  *** bitcoin-git has joined #bitcoin-core-dev
 1922020-07-09T12:30:53  <bitcoin-git> [bitcoin] fanquake merged pull request #19470: banlist: log post-swept banlist size at startup (master...log_post_sweep_banlist_size) https://github.com/bitcoin/bitcoin/pull/19470
 1932020-07-09T12:30:54  *** bitcoin-git has left #bitcoin-core-dev
 1942020-07-09T12:31:12  *** bitcoin-git has joined #bitcoin-core-dev
 1952020-07-09T12:31:13  <bitcoin-git> [bitcoin] fanquake closed pull request #18239: wip: gui: Refactor to drop client and wallet models setters (master...2020-03-drop-setmodel) https://github.com/bitcoin/bitcoin/pull/18239
 1962020-07-09T12:31:24  *** bitcoin-git has left #bitcoin-core-dev
 1972020-07-09T12:36:11  *** bitdex has quit IRC
 1982020-07-09T12:39:07  *** bitcoin-git has joined #bitcoin-core-dev
 1992020-07-09T12:39:08  <bitcoin-git> [bitcoin] fanquake closed pull request #17611: gui: Make send and receive widgets extend QWidget (master...2019-11-send-receive-widgets) https://github.com/bitcoin/bitcoin/pull/17611
 2002020-07-09T12:39:08  *** bitcoin-git has left #bitcoin-core-dev
 2012020-07-09T12:44:28  *** zaff has quit IRC
 2022020-07-09T12:51:37  *** bitcoin-git has joined #bitcoin-core-dev
 2032020-07-09T12:51:38  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e3b31255c5ad...64bf5d64dfbf
 2042020-07-09T12:51:38  <bitcoin-git> bitcoin/master 1e9bfd4 Hennadii Stepanov: qt: Reset toolbar after all wallets are closed
 2052020-07-09T12:51:39  <bitcoin-git> bitcoin/master 64bf5d6 fanquake: Merge #18896: qt: Reset toolbar after all wallets are closed
 2062020-07-09T12:51:41  *** bitcoin-git has left #bitcoin-core-dev
 2072020-07-09T12:52:29  *** bitcoin-git has joined #bitcoin-core-dev
 2082020-07-09T12:52:30  <bitcoin-git> [bitcoin] fanquake merged pull request #18896: qt: Reset toolbar after all wallets are closed (master...200506-toolbar) https://github.com/bitcoin/bitcoin/pull/18896
 2092020-07-09T12:52:30  *** bitcoin-git has left #bitcoin-core-dev
 2102020-07-09T12:53:00  *** Evel-Knievel has quit IRC
 2112020-07-09T12:53:45  *** Evel-Knievel has joined #bitcoin-core-dev
 2122020-07-09T12:56:04  *** Pavlenex has joined #bitcoin-core-dev
 2132020-07-09T13:02:02  *** bitcoin-git has joined #bitcoin-core-dev
 2142020-07-09T13:02:02  <bitcoin-git> [bitcoin] fanquake closed pull request #17966: qt, refactor: Optimize signal-slot connections logic (master...20200119-gui-walletframe) https://github.com/bitcoin/bitcoin/pull/17966
 2152020-07-09T13:02:03  *** bitcoin-git has left #bitcoin-core-dev
 2162020-07-09T13:05:09  *** arowser has quit IRC
 2172020-07-09T13:05:33  *** arowser has joined #bitcoin-core-dev
 2182020-07-09T13:07:10  *** arowser has quit IRC
 2192020-07-09T13:07:36  *** arowser has joined #bitcoin-core-dev
 2202020-07-09T13:08:11  *** arowser has quit IRC
 2212020-07-09T13:08:13  *** Jackielove4u has joined #bitcoin-core-dev
 2222020-07-09T13:08:20  *** bitcoin-git has joined #bitcoin-core-dev
 2232020-07-09T13:08:20  <bitcoin-git> [bitcoin] fanquake closed pull request #18618: gui: Drop RecentRequestsTableModel dependency to WalletModel (master...2020-04-review-18608) https://github.com/bitcoin/bitcoin/pull/18618
 2242020-07-09T13:08:21  *** bitcoin-git has left #bitcoin-core-dev
 2252020-07-09T13:08:42  *** arowser has joined #bitcoin-core-dev
 2262020-07-09T13:09:10  *** arowser has quit IRC
 2272020-07-09T13:09:42  *** arowser has joined #bitcoin-core-dev
 2282020-07-09T13:10:12  *** arowser has quit IRC
 2292020-07-09T13:10:41  *** arowser has joined #bitcoin-core-dev
 2302020-07-09T13:11:09  *** arowser has quit IRC
 2312020-07-09T13:11:37  *** arowser has joined #bitcoin-core-dev
 2322020-07-09T13:11:39  *** bitcoin-git has joined #bitcoin-core-dev
 2332020-07-09T13:11:39  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/64bf5d64dfbf...21028ce9ffb8
 2342020-07-09T13:11:40  <bitcoin-git> bitcoin/master 4b5ac25 Hennadii Stepanov: Drop unused CDBWrapper methods
 2352020-07-09T13:11:40  <bitcoin-git> bitcoin/master 21028ce Wladimir J. van der Laan: Merge #19468: refactor: Drop unused CDBWrapper methods
 2362020-07-09T13:11:41  *** bitcoin-git has left #bitcoin-core-dev
 2372020-07-09T13:11:59  *** bitcoin-git has joined #bitcoin-core-dev
 2382020-07-09T13:11:59  <bitcoin-git> [bitcoin] laanwj merged pull request #19468: refactor: Drop unused CDBWrapper methods (master...200708-dbwrapper) https://github.com/bitcoin/bitcoin/pull/19468
 2392020-07-09T13:12:00  *** bitcoin-git has left #bitcoin-core-dev
 2402020-07-09T13:12:08  *** arowser has quit IRC
 2412020-07-09T13:12:36  *** arowser has joined #bitcoin-core-dev
 2422020-07-09T13:13:09  *** arowser has quit IRC
 2432020-07-09T13:13:37  *** arowser has joined #bitcoin-core-dev
 2442020-07-09T13:14:08  *** arowser has quit IRC
 2452020-07-09T13:14:39  *** arowser has joined #bitcoin-core-dev
 2462020-07-09T13:15:09  *** bitcoin-git has joined #bitcoin-core-dev
 2472020-07-09T13:15:09  <bitcoin-git> [bitcoin] fanquake closed pull request #17955: gui: Paste button in Open URI dialog (master...2020-01-paste-bitcoin-uri-button) https://github.com/bitcoin/bitcoin/pull/17955
 2482020-07-09T13:15:10  *** bitcoin-git has left #bitcoin-core-dev
 2492020-07-09T13:16:02  *** mdunnio has joined #bitcoin-core-dev
 2502020-07-09T13:17:10  *** arowser has quit IRC
 2512020-07-09T13:17:30  *** arowser has joined #bitcoin-core-dev
 2522020-07-09T13:22:35  *** bitcoin-git has joined #bitcoin-core-dev
 2532020-07-09T13:22:36  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/21028ce9ffb8...fc8da23fbe58
 2542020-07-09T13:22:37  <bitcoin-git> bitcoin/master 2894e94 Aaron Clauson: Updates msvc build to use ISO standard C++17.
 2552020-07-09T13:22:37  <bitcoin-git> bitcoin/master fc8da23 Wladimir J. van der Laan: Merge #19445: build: Update msvc build to use ISO standard C++17
 2562020-07-09T13:22:39  *** bitcoin-git has left #bitcoin-core-dev
 2572020-07-09T13:22:57  *** bitcoin-git has joined #bitcoin-core-dev
 2582020-07-09T13:22:57  <bitcoin-git> [bitcoin] laanwj merged pull request #19445: build: Update msvc build to use ISO standard C++17 (master...msvc_cpp17) https://github.com/bitcoin/bitcoin/pull/19445
 2592020-07-09T13:22:58  *** bitcoin-git has left #bitcoin-core-dev
 2602020-07-09T13:25:01  *** bitcoin-git has joined #bitcoin-core-dev
 2612020-07-09T13:25:02  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fc8da23fbe58...45f58dbc9b45
 2622020-07-09T13:25:02  <bitcoin-git> bitcoin/master 2b78a11 nsa: doc: afl fuzzing comment about afl-gcc and afl-g++
 2632020-07-09T13:25:03  <bitcoin-git> bitcoin/master 45f58db fanquake: Merge #19452: doc: afl fuzzing comment about afl-gcc and afl-g++
 2642020-07-09T13:25:05  *** bitcoin-git has left #bitcoin-core-dev
 2652020-07-09T13:25:21  *** bitcoin-git has joined #bitcoin-core-dev
 2662020-07-09T13:25:21  <bitcoin-git> [bitcoin] fanquake merged pull request #19452: doc: afl fuzzing comment about afl-gcc and afl-g++ (master...afl_gcc_0705) https://github.com/bitcoin/bitcoin/pull/19452
 2672020-07-09T13:25:22  *** bitcoin-git has left #bitcoin-core-dev
 2682020-07-09T13:31:21  *** bitcoin-git has joined #bitcoin-core-dev
 2692020-07-09T13:31:21  <bitcoin-git> [bitcoin] fanquake closed pull request #18865: gui: Refactor WalletFrame to extend QStackView (master...2020-05-walletframe) https://github.com/bitcoin/bitcoin/pull/18865
 2702020-07-09T13:31:22  *** bitcoin-git has left #bitcoin-core-dev
 2712020-07-09T13:39:01  *** promag has quit IRC
 2722020-07-09T13:39:18  *** promag has joined #bitcoin-core-dev
 2732020-07-09T13:41:50  *** promag has quit IRC
 2742020-07-09T13:42:40  *** promag has joined #bitcoin-core-dev
 2752020-07-09T13:46:38  *** dr-orlovsky has quit IRC
 2762020-07-09T13:50:43  *** Pavlenex has quit IRC
 2772020-07-09T13:52:09  *** arowser has quit IRC
 2782020-07-09T13:52:28  *** arowser has joined #bitcoin-core-dev
 2792020-07-09T13:53:09  *** arowser has quit IRC
 2802020-07-09T13:53:28  *** arowser has joined #bitcoin-core-dev
 2812020-07-09T13:55:49  *** dr-orlovsky has joined #bitcoin-core-dev
 2822020-07-09T13:56:02  *** mdunnio has quit IRC
 2832020-07-09T13:56:17  *** mdunnio has joined #bitcoin-core-dev
 2842020-07-09T14:04:10  *** bitcoin-git has joined #bitcoin-core-dev
 2852020-07-09T14:04:10  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/45f58dbc9b45...9a3c7afe290f
 2862020-07-09T14:04:10  <bitcoin-git> bitcoin/master c858302 jmorgan: Change format of log2_work for uniform output (zero-padded)
 2872020-07-09T14:04:11  <bitcoin-git> bitcoin/master 9a3c7af Wladimir J. van der Laan: Merge #19317: Add a left-justified width field to log2_work component for ...
 2882020-07-09T14:04:12  *** bitcoin-git has left #bitcoin-core-dev
 2892020-07-09T14:05:05  *** roconnor has joined #bitcoin-core-dev
 2902020-07-09T14:13:39  <willcl_ark> Is it possible to build the fuzzing harness (only) with gcc rather than clang?
 2912020-07-09T14:17:45  <MarcoFalke> willcl_ark: Yes, e.g. with afl-gcc
 2922020-07-09T14:17:54  <MarcoFalke> see doc/fuzzing.md
 2932020-07-09T14:19:04  <MarcoFalke> #19452
 2942020-07-09T14:19:05  <gribble> https://github.com/bitcoin/bitcoin/issues/19452 | doc: afl fuzzing comment about afl-gcc and afl-g++ by Crypt-iQ · Pull Request #19452 · bitcoin/bitcoin · GitHub
 2952020-07-09T14:19:43  <willcl_ark> MarcoFalke: Right. I'm looking at #19388 a bit more, and it seems to me undesirable that we'd now require e.g. afl-gcc for all the gcc builds if fuzzing harnesses were built by default.
 2962020-07-09T14:19:44  <gribble> https://github.com/bitcoin/bitcoin/issues/19388 | Build fuzz tests by default · Issue #19388 · bitcoin/bitcoin · GitHub
 2972020-07-09T14:20:18  <MarcoFalke> Oh, if you don't need instrumentation, you should be able to use any cpp compiler
 2982020-07-09T14:21:30  <MarcoFalke> The fuzz engine only provides the main function, but the individual fuzz tests don't know that. They can be compiled with any cpp compiler
 2992020-07-09T14:21:47  <willcl_ark> OK, that's what I understood too (from Practicalswift's comments in https://github.com/bitcoin/bitcoin/pull/19366#issue-438840241), but i've been struggling with gcc. If it should be possible I'll keep grappling :)
 3002020-07-09T14:21:55  <willcl_ark> My issues are mainly with the linking
 3012020-07-09T14:22:51  <MarcoFalke> Yes, there might be issues linking the main function
 3022020-07-09T14:23:14  <willcl_ark> Yeah that's the general complaint
 3032020-07-09T14:25:18  <MarcoFalke> I'd have to look at the code or failure to say more, but generally it should be possible
 3042020-07-09T14:27:23  <willcl_ark> OK thanks, perhaps I'll ping you in the issue when I have a clearer error to look at
 3052020-07-09T14:27:23  *** promag has quit IRC
 3062020-07-09T14:27:25  *** promag_ has joined #bitcoin-core-dev
 3072020-07-09T14:28:59  *** bitcoin-git has joined #bitcoin-core-dev
 3082020-07-09T14:29:00  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9a3c7afe290f...22ccc27046a8
 3092020-07-09T14:29:00  <bitcoin-git> bitcoin/master fc6a637 10xcryptodev: qt: increase console command max length
 3102020-07-09T14:29:01  <bitcoin-git> bitcoin/master 22ccc27 fanquake: Merge #18993: qt: increase console command max length
 3112020-07-09T14:29:02  *** bitcoin-git has left #bitcoin-core-dev
 3122020-07-09T14:29:18  *** murrayn has quit IRC
 3132020-07-09T14:29:37  *** murray_ has joined #bitcoin-core-dev
 3142020-07-09T14:29:40  *** bitcoin-git has joined #bitcoin-core-dev
 3152020-07-09T14:29:40  <bitcoin-git> [bitcoin] fanquake merged pull request #18993: qt: increase console command max length (master...202005-increase-console-command) https://github.com/bitcoin/bitcoin/pull/18993
 3162020-07-09T14:29:41  *** bitcoin-git has left #bitcoin-core-dev
 3172020-07-09T14:30:11  *** victorSN7 has joined #bitcoin-core-dev
 3182020-07-09T14:30:29  *** victorSN has quit IRC
 3192020-07-09T14:30:29  *** victorSN7 is now known as victorSN
 3202020-07-09T14:32:43  <fanquake> I've swapped out my current high-prio PR for #19224.
 3212020-07-09T14:32:45  <gribble> https://github.com/bitcoin/bitcoin/issues/19224 | [0.20] Backports by fanquake · Pull Request #19224 · bitcoin/bitcoin · GitHub
 3222020-07-09T14:32:52  <fanquake> Review-beg if you have a PR that is being back-ported there.
 3232020-07-09T14:44:30  *** owowo has joined #bitcoin-core-dev
 3242020-07-09T14:44:30  *** owowo has joined #bitcoin-core-dev
 3252020-07-09T14:48:25  *** nik-j has joined #bitcoin-core-dev
 3262020-07-09T14:51:06  *** bitcoin-git has joined #bitcoin-core-dev
 3272020-07-09T14:51:07  <bitcoin-git> [bitcoin] dongcarl closed pull request #17099: depends: Eliminate hard dependency on Ubuntu-ABI specific clang (master...2019-09-no-clang-download) https://github.com/bitcoin/bitcoin/pull/17099
 3282020-07-09T14:51:08  *** bitcoin-git has left #bitcoin-core-dev
 3292020-07-09T14:56:31  *** bitcoin-git has joined #bitcoin-core-dev
 3302020-07-09T14:56:33  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/22ccc27046a8...0d69fdb9a0e3
 3312020-07-09T14:56:33  <bitcoin-git> bitcoin/master 1cabbdd Aaron Hook: refactor: Use uint16_t instead of unsigned short
 3322020-07-09T14:56:33  <bitcoin-git> bitcoin/master 0d69fdb Wladimir J. van der Laan: Merge #19314: refactor: Use uint16_t instead of unsigned short
 3332020-07-09T14:56:35  *** bitcoin-git has left #bitcoin-core-dev
 3342020-07-09T14:56:51  *** bitcoin-git has joined #bitcoin-core-dev
 3352020-07-09T14:56:52  <bitcoin-git> [bitcoin] laanwj merged pull request #19314: refactor: Use uint16_t instead of unsigned short (master...akh_uint16_t) https://github.com/bitcoin/bitcoin/pull/19314
 3362020-07-09T14:56:53  *** bitcoin-git has left #bitcoin-core-dev
 3372020-07-09T14:57:33  *** nik-j has quit IRC
 3382020-07-09T14:58:55  *** nik-j has joined #bitcoin-core-dev
 3392020-07-09T15:00:02  *** sora_h has quit IRC
 3402020-07-09T15:03:54  <instagibbs> suggested topic: unified zmq stream + mempool sequence number https://github.com/bitcoin/bitcoin/pull/19462#issuecomment-656140421
 3412020-07-09T15:05:24  *** bitcoin-git has joined #bitcoin-core-dev
 3422020-07-09T15:05:24  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/0d69fdb9a0e3...cc9d09e73de0
 3432020-07-09T15:05:25  <bitcoin-git> bitcoin/master fa0540c MarcoFalke: net: Extract download permission from noban
 3442020-07-09T15:05:25  <bitcoin-git> bitcoin/master cc9d09e MarcoFalke: Merge #19191: net: Extract download permission from noban
 3452020-07-09T15:05:27  *** bitcoin-git has left #bitcoin-core-dev
 3462020-07-09T15:05:49  *** bitcoin-git has joined #bitcoin-core-dev
 3472020-07-09T15:05:49  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #19191: net: Extract download permission from noban (master...2006-netPerDow) https://github.com/bitcoin/bitcoin/pull/19191
 3482020-07-09T15:05:50  *** bitcoin-git has left #bitcoin-core-dev
 3492020-07-09T15:11:01  *** yudan has joined #bitcoin-core-dev
 3502020-07-09T15:12:56  *** bitcoin-git has joined #bitcoin-core-dev
 3512020-07-09T15:12:57  <bitcoin-git> [bitcoin] fanquake closed pull request #19001: qt: bugfix unsupported QLocale languages (master...202005-bugfix-qlocale) https://github.com/bitcoin/bitcoin/pull/19001
 3522020-07-09T15:12:58  *** bitcoin-git has left #bitcoin-core-dev
 3532020-07-09T15:16:19  *** rawtaz1 has joined #bitcoin-core-dev
 3542020-07-09T15:17:49  *** tryphe has quit IRC
 3552020-07-09T15:17:55  *** bitcoin-git has joined #bitcoin-core-dev
 3562020-07-09T15:17:55  <bitcoin-git> [bitcoin] fanquake closed pull request #18604: Display command line usage to console without requiring X Windows (master...UsageToConsoleIfNotWin32) https://github.com/bitcoin/bitcoin/pull/18604
 3572020-07-09T15:18:06  *** bitcoin-git has left #bitcoin-core-dev
 3582020-07-09T15:18:17  *** tryphe has joined #bitcoin-core-dev
 3592020-07-09T15:30:51  *** vasild_ has joined #bitcoin-core-dev
 3602020-07-09T15:34:43  *** vasild has quit IRC
 3612020-07-09T15:34:44  *** vasild_ is now known as vasild
 3622020-07-09T15:35:06  *** shuckc has joined #bitcoin-core-dev
 3632020-07-09T15:35:32  *** proofofkeags has joined #bitcoin-core-dev
 3642020-07-09T15:40:22  *** zaff has joined #bitcoin-core-dev
 3652020-07-09T15:43:59  *** Livestradamus has quit IRC
 3662020-07-09T15:44:18  *** Livestradamus has joined #bitcoin-core-dev
 3672020-07-09T15:47:01  *** jarthur_ is now known as jarthur
 3682020-07-09T15:47:19  *** Pavlenex has joined #bitcoin-core-dev
 3692020-07-09T15:47:38  *** yudan has quit IRC
 3702020-07-09T15:48:28  *** dr-orlovsky has quit IRC
 3712020-07-09T15:48:30  *** dr_orlovsky has joined #bitcoin-core-dev
 3722020-07-09T15:49:00  *** zaff has quit IRC
 3732020-07-09T15:50:57  *** bitcoin-git has joined #bitcoin-core-dev
 3742020-07-09T15:50:57  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #19474: doc: Use precise permission flags where possible (master...2007-docPerm) https://github.com/bitcoin/bitcoin/pull/19474
 3752020-07-09T15:50:58  *** bitcoin-git has left #bitcoin-core-dev
 3762020-07-09T15:53:21  *** bitcoin-git has joined #bitcoin-core-dev
 3772020-07-09T15:53:22  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/cc9d09e73de0...fd9db45c3ea1
 3782020-07-09T15:53:22  <bitcoin-git> bitcoin/master a4a3fc4 Sjors Provoost: doc: improve subtree check instructions
 3792020-07-09T15:53:23  <bitcoin-git> bitcoin/master fd9db45 Wladimir J. van der Laan: Merge #19258: doc: improve subtree check instructions
 3802020-07-09T15:53:24  *** bitcoin-git has left #bitcoin-core-dev
 3812020-07-09T15:53:42  *** bitcoin-git has joined #bitcoin-core-dev
 3822020-07-09T15:53:42  <bitcoin-git> [bitcoin] laanwj merged pull request #19258: doc: improve subtree check instructions (master...2020/06/subtree-docs) https://github.com/bitcoin/bitcoin/pull/19258
 3832020-07-09T15:53:43  *** bitcoin-git has left #bitcoin-core-dev
 3842020-07-09T15:58:08  *** arowser has quit IRC
 3852020-07-09T15:58:36  *** arowser has joined #bitcoin-core-dev
 3862020-07-09T16:05:56  *** Talkless has joined #bitcoin-core-dev
 3872020-07-09T16:08:01  *** arowser has quit IRC
 3882020-07-09T16:12:01  *** bitcoin-git has joined #bitcoin-core-dev
 3892020-07-09T16:12:01  <bitcoin-git> [bitcoin] Mohamed-94 opened pull request #19475: script: Speed up default time-out and Container CPU usage (master...patch-1) https://github.com/bitcoin/bitcoin/pull/19475
 3902020-07-09T16:12:08  *** bitcoin-git has left #bitcoin-core-dev
 3912020-07-09T16:14:31  *** arowser has joined #bitcoin-core-dev
 3922020-07-09T16:14:47  *** promag_ has quit IRC
 3932020-07-09T16:15:43  *** promag has joined #bitcoin-core-dev
 3942020-07-09T16:17:49  <luke-jr> https://twitter.com/RainDogDance/status/1281260787475021826
 3952020-07-09T16:17:54  <luke-jr> apparently there's a market for TNBTC
 3962020-07-09T16:18:26  <luke-jr> kindof.
 3972020-07-09T16:36:49  *** Pavlenex has quit IRC
 3982020-07-09T16:37:12  <instagibbs> it's hard to get your hands on large amounts unless you "know people"
 3992020-07-09T16:40:10  *** troygiorshev has quit IRC
 4002020-07-09T16:40:25  *** troygiorshev has joined #bitcoin-core-dev
 4012020-07-09T16:43:24  <phantomcircuit> instagibbs, it's extremely easy to mine a huge amount of tnbtc if you modify a stratum proxy very slightly
 4022020-07-09T16:47:16  *** justan0theruser has quit IRC
 4032020-07-09T16:47:36  *** corollari_ has joined #bitcoin-core-dev
 4042020-07-09T16:48:04  *** hebasto_ has joined #bitcoin-core-dev
 4052020-07-09T16:48:10  *** mmitech__ has joined #bitcoin-core-dev
 4062020-07-09T16:48:13  *** ryanofsky_ has joined #bitcoin-core-dev
 4072020-07-09T16:50:04  <instagibbs> someone is warp mining this morning AFAICT
 4082020-07-09T16:50:53  *** commavir_ has joined #bitcoin-core-dev
 4092020-07-09T16:50:56  *** promag has quit IRC
 4102020-07-09T16:51:03  *** filchef has joined #bitcoin-core-dev
 4112020-07-09T16:51:11  *** promag has joined #bitcoin-core-dev
 4122020-07-09T16:51:59  *** filchef has quit IRC
 4132020-07-09T16:52:16  *** Talkless has quit IRC
 4142020-07-09T16:52:32  *** Talkless has joined #bitcoin-core-dev
 4152020-07-09T16:55:15  *** meshcoll- has joined #bitcoin-core-dev
 4162020-07-09T16:55:26  *** corollari has quit IRC
 4172020-07-09T16:55:26  *** hebasto has quit IRC
 4182020-07-09T16:55:26  *** NicolasDorier has quit IRC
 4192020-07-09T16:55:26  *** mmitech_ has quit IRC
 4202020-07-09T16:55:30  *** gribble has quit IRC
 4212020-07-09T16:55:30  *** da2ce7_ has quit IRC
 4222020-07-09T16:55:30  *** meshcollider has quit IRC
 4232020-07-09T16:55:30  *** ryanofsky has quit IRC
 4242020-07-09T16:55:30  *** commavir has quit IRC
 4252020-07-09T16:55:31  *** hebasto_ is now known as hebasto
 4262020-07-09T16:55:33  *** commavir_ is now known as commavir
 4272020-07-09T16:56:45  *** mrostecki has quit IRC
 4282020-07-09T16:56:47  *** awesome-doge has quit IRC
 4292020-07-09T16:56:48  *** icota[m] has quit IRC
 4302020-07-09T16:56:51  *** SergeySherkunov[ has quit IRC
 4312020-07-09T16:56:52  *** TheFuzzStone[m] has quit IRC
 4322020-07-09T16:56:56  *** infamously[m] has quit IRC
 4332020-07-09T16:58:44  *** NicolasDorier has joined #bitcoin-core-dev
 4342020-07-09T16:58:44  *** da2ce7_ has joined #bitcoin-core-dev
 4352020-07-09T17:02:02  *** awesome-doge has joined #bitcoin-core-dev
 4362020-07-09T17:03:58  *** dr_orlovsky has quit IRC
 4372020-07-09T17:04:57  *** dr-orlovsky has joined #bitcoin-core-dev
 4382020-07-09T17:05:07  *** DeanGuss has quit IRC
 4392020-07-09T17:05:13  *** Dean_Guss has joined #bitcoin-core-dev
 4402020-07-09T17:07:06  *** kristapsk has joined #bitcoin-core-dev
 4412020-07-09T17:08:00  <cfields> jonatack: that warning has me completely stumped, and now I'm curious. Building clang from source now to play along.
 4422020-07-09T17:10:12  <jonatack> cfields: idk if it's worth it. i didn't install from source. added "deb http://apt.llvm.org/unstable/ llvm-toolchain main" to my etc/apt/sources.list
 4432020-07-09T17:10:40  <cfields> ack
 4442020-07-09T17:10:46  <jonatack> fanquake suggested this am that i move back to clang stable 9 or 10 for reviewing purposes
 4452020-07-09T17:10:47  <cfields> jonatack: do you get a ton of warnings? Or just that one?
 4462020-07-09T17:11:16  <jonatack> just the one. i agree with you that it doesn't make sense.
 4472020-07-09T17:11:36  <cfields> you actually checked out the commit, right? Didn't c/p from github?
 4482020-07-09T17:12:28  *** gribble has joined #bitcoin-core-dev
 4492020-07-09T17:12:33  <jonatack> yes, i always do. build several times with make distclean to be sure it was really doing that, and also compared with a clean gcc 9.3 build
 4502020-07-09T17:12:41  <jonatack> built*
 4512020-07-09T17:12:55  <cfields> So weird!
 4522020-07-09T17:13:11  <cfields> We'll see if I can reproduce from a git build.
 4532020-07-09T17:13:29  <sipa> jonatack: and you only get the warning on the new code introducsd to attrihutes.h?
 4542020-07-09T17:13:33  <sipa> not anywhere else?
 4552020-07-09T17:13:37  *** justan0theruser has joined #bitcoin-core-dev
 4562020-07-09T17:14:08  <jonatack> I'm afraid I've led you into a goosechase cfields. sipa: correct, but i've only been reviewing with this version of clang since sunday.
 4572020-07-09T17:14:50  <cfields> jonatack: no worries, I needed to build llvm to test recent lld anyway. That's the only reason I jumped to compile so quickly.
 4582020-07-09T17:15:02  <jonatack> i was on debian clang 6 which does not have -Wdangling and wanted to test cory's PR
 4592020-07-09T17:15:27  <jonatack> cfields: yes. LMK
 4602020-07-09T17:20:20  *** Highway62 has joined #bitcoin-core-dev
 4612020-07-09T17:21:33  <jonatack> rebuilt just now again, saw it again. but also apt-update has new clang updates. installing and rebuilding.
 4622020-07-09T17:21:54  *** Highway61 has quit IRC
 4632020-07-09T17:21:54  *** Highway62 is now known as Highway61
 4642020-07-09T17:22:40  *** TheFuzzStone[m] has joined #bitcoin-core-dev
 4652020-07-09T17:22:40  *** mrostecki has joined #bitcoin-core-dev
 4662020-07-09T17:22:41  *** SergeySherkunov[ has joined #bitcoin-core-dev
 4672020-07-09T17:22:41  *** icota[m] has joined #bitcoin-core-dev
 4682020-07-09T17:22:47  *** infamously[m] has joined #bitcoin-core-dev
 4692020-07-09T17:26:42  *** someone235 has quit IRC
 4702020-07-09T17:34:53  *** Highway61 has quit IRC
 4712020-07-09T17:35:35  *** Highway61 has joined #bitcoin-core-dev
 4722020-07-09T17:35:37  *** Evel-Knievel has quit IRC
 4732020-07-09T17:36:21  *** Evel-Knievel has joined #bitcoin-core-dev
 4742020-07-09T17:38:45  <jonatack> cfields: upgraded from 11.0.0-++20200708111116+1f84ace3c72-1~exp1~20200708091733.3345 to 11.0.0-++20200709111134+dc4a6f5db4f-1~exp1~20200709091753.3347 and the warning is gone.
 4752020-07-09T17:42:03  *** andrewtoth has quit IRC
 4762020-07-09T17:42:21  <sipa> chased goose is best goose
 4772020-07-09T17:42:32  <jonatack> :D
 4782020-07-09T17:42:50  <cfields> jonatack: heh, well that's rather unsatisfying
 4792020-07-09T17:47:19  *** nik-j has quit IRC
 4802020-07-09T17:47:27  *** Evel-Knievel has quit IRC
 4812020-07-09T17:47:56  *** nik-j has joined #bitcoin-core-dev
 4822020-07-09T17:55:02  *** nik-j has quit IRC
 4832020-07-09T18:00:01  *** rawtaz1 has quit IRC
 4842020-07-09T18:02:31  *** zaff has joined #bitcoin-core-dev
 4852020-07-09T18:06:31  <cfields> jonatack: igoring all that, thanks for jumping through hoops to test :)
 4862020-07-09T18:14:44  <jeremyrubin> #proposedmeetingtopic small clarification on the goals of the mempool project (cap at 5 mins meeting time)
 4872020-07-09T18:18:17  *** jb55 has quit IRC
 4882020-07-09T18:18:46  *** jb55 has joined #bitcoin-core-dev
 4892020-07-09T18:18:54  *** vincenzopalazzo has joined #bitcoin-core-dev
 4902020-07-09T18:20:59  *** Pavlenex has joined #bitcoin-core-dev
 4912020-07-09T18:21:04  *** Xing`1 has joined #bitcoin-core-dev
 4922020-07-09T18:26:08  *** bitcoin-git has joined #bitcoin-core-dev
 4932020-07-09T18:26:08  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fd9db45c3ea1...2aaff4813cc3
 4942020-07-09T18:26:09  <bitcoin-git> bitcoin/master fa6d5ab MarcoFalke: refactor: Remove unused BlockAssembler::pblock member var
 4952020-07-09T18:26:09  <bitcoin-git> bitcoin/master 2aaff48 MarcoFalke: Merge #19283: refactor: Remove unused BlockAssembler::pblock member var
 4962020-07-09T18:26:11  *** bitcoin-git has left #bitcoin-core-dev
 4972020-07-09T18:26:28  *** bitcoin-git has joined #bitcoin-core-dev
 4982020-07-09T18:26:28  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #19283: refactor: Remove unused BlockAssembler::pblock member var (master...2006-minerPblock) https://github.com/bitcoin/bitcoin/pull/19283
 4992020-07-09T18:26:29  *** bitcoin-git has left #bitcoin-core-dev
 5002020-07-09T18:31:21  *** nik-j has joined #bitcoin-core-dev
 5012020-07-09T18:35:34  *** nik-j has quit IRC
 5022020-07-09T18:42:59  *** Pavlenex has quit IRC
 5032020-07-09T18:43:39  *** nik-j has joined #bitcoin-core-dev
 5042020-07-09T18:46:44  *** bitcoin-git has joined #bitcoin-core-dev
 5052020-07-09T18:46:44  <bitcoin-git> [bitcoin] promag opened pull request #19476: wip, rpc: Add mempoolchanges (master...2020-07-rpc-mempoolchanges) https://github.com/bitcoin/bitcoin/pull/19476
 5062020-07-09T18:46:45  *** bitcoin-git has left #bitcoin-core-dev
 5072020-07-09T18:53:04  *** promag_ has joined #bitcoin-core-dev
 5082020-07-09T18:54:04  *** promag has quit IRC
 5092020-07-09T18:54:40  *** promag has joined #bitcoin-core-dev
 5102020-07-09T18:55:48  <promag_> instagibbs: #19476
 5112020-07-09T18:55:50  <gribble> https://github.com/bitcoin/bitcoin/issues/19476 | wip, rpc: Add mempoolchanges by promag · Pull Request #19476 · bitcoin/bitcoin · GitHub
 5122020-07-09T18:55:58  <instagibbs> promag_, yeah saw that
 5132020-07-09T18:56:08  <instagibbs> can someone give shuckc voice?
 5142020-07-09T18:56:21  *** promag has quit IRC
 5152020-07-09T18:56:25  *** promag_ is now known as promag
 5162020-07-09T18:56:56  <sipa> shuckc voice?
 5172020-07-09T18:57:10  *** promag_ has joined #bitcoin-core-dev
 5182020-07-09T18:57:10  <instagibbs> i am not irc wizard, he says he cannot say anything here
 5192020-07-09T18:57:22  <achow101> pretty sure you need to be registered
 5202020-07-09T18:57:25  <instagibbs> ah ok
 5212020-07-09T18:57:28  <aj> yeah
 5222020-07-09T18:57:32  <aj> register with nickserv
 5232020-07-09T18:58:01  *** dfmb_ has joined #bitcoin-core-dev
 5242020-07-09T18:58:18  *** dfmb_ has quit IRC
 5252020-07-09T18:59:17  <wumpus> there should be no reason to deal out voice manually here, it's not a +m channel, but yes, registering with nickserv is required
 5262020-07-09T18:59:32  <instagibbs> he's not registered, mystery solved
 5272020-07-09T18:59:36  <MarcoFalke> Can someone edit the topic to say that register with nicksers is needed?
 5282020-07-09T18:59:54  <wumpus> FWIW we've tried to remove that requirement many times and every time immediately some spam appeared
 5292020-07-09T18:59:59  <MarcoFalke> I am not an IRC wizard either and I was muted at least twice in a meeting and didn't notice
 5302020-07-09T19:00:19  <wumpus> I've been caught by that as well the feedback is pretty bad
 5312020-07-09T19:00:22  <troygiorshev> we don't have +r though, so why is that happenin?
 5322020-07-09T19:00:22  <shuckc> better?
 5332020-07-09T19:00:28  <wumpus> shuckc: yes
 5342020-07-09T19:00:31  <luke-jr> MarcoFalke: not sure topic change will help that..
 5352020-07-09T19:00:38  <instagibbs> shuckc, see you
 5362020-07-09T19:00:40  <luke-jr> MarcoFalke: especially if you don't notice the error that your msg didn't go
 5372020-07-09T19:00:45  <promag> meeting?
 5382020-07-09T19:00:49  <achow101> meeting?
 5392020-07-09T19:00:52  <wumpus> #startmeeting
 5402020-07-09T19:00:52  <lightningbot> Meeting started Thu Jul  9 19:00:52 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 5412020-07-09T19:00:52  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
 5422020-07-09T19:00:52  <MarcoFalke> ahoi
 5432020-07-09T19:00:57  <hebasto> hi
 5442020-07-09T19:00:58  <achow101> hi
 5452020-07-09T19:00:59  <troygiorshev> hi
 5462020-07-09T19:01:03  <jnewbery> hi
 5472020-07-09T19:01:07  <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
 5482020-07-09T19:01:09  <wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
 5492020-07-09T19:01:19  <jb55> hi
 5502020-07-09T19:01:20  <fjahr> hi
 5512020-07-09T19:01:22  <amiti> hi
 5522020-07-09T19:01:26  <luke-jr> ih
 5532020-07-09T19:01:37  <promag> hi
 5542020-07-09T19:01:38  <kanzure> hi
 5552020-07-09T19:01:50  <jonasschnelli> hi
 5562020-07-09T19:01:57  <jeremyrubin> hola
 5572020-07-09T19:02:12  <gwillen> hi
 5582020-07-09T19:02:21  <cfields> hi
 5592020-07-09T19:02:28  <sipa> hi
 5602020-07-09T19:02:30  <wumpus> one proposed meeting topic: small clarification on the goals of the mempool project (jeremyrubin)
 5612020-07-09T19:02:36  <wumpus> any last minute topics?
 5622020-07-09T19:02:50  <phantomcircuit> hi
 5632020-07-09T19:02:56  <sipa> another short one: can we drop gcc 4.8?
 5642020-07-09T19:02:56  *** gzhao408 has joined #bitcoin-core-dev
 5652020-07-09T19:03:06  <wumpus> ok
 5662020-07-09T19:03:25  <instagibbs> proposed topic: new zmq notifications, or something else https://github.com/bitcoin/bitcoin/pull/19462#issuecomment-656140421 and https://github.com/bitcoin/bitcoin/pull/19476
 5672020-07-09T19:03:41  <luke-jr> sipa: not sure that's a good meeting topic; it just needs someone to investigate distros?
 5682020-07-09T19:03:44  <ariard> hi
 5692020-07-09T19:03:54  <elichai2> hu
 5702020-07-09T19:04:04  <wumpus> #topic High priority for review
 5712020-07-09T19:04:16  <MarcoFalke> can i haz #19386
 5722020-07-09T19:04:17  <achow101> #19325 pls
 5732020-07-09T19:04:19  <gribble> https://github.com/bitcoin/bitcoin/issues/19386 | rpc: Assert that RPCArg names are equal to CRPCCommand ones (server) by MarcoFalke · Pull Request #19386 · bitcoin/bitcoin · GitHub
 5742020-07-09T19:04:20  <gribble> https://github.com/bitcoin/bitcoin/issues/19325 | wallet: Refactor BerkeleyDatabase to introduce DatabaseBatch abstract class by achow101 · Pull Request #19325 · bitcoin/bitcoin · GitHub
 5752020-07-09T19:04:27  <wumpus> https://github.com/bitcoin/bitcoin/projects/8  13 blockers, 1 bugfix, 3 chasing concept ACK
 5762020-07-09T19:04:36  <wumpus> please don't add any more before removing any xD
 5772020-07-09T19:04:38  <jamesob> hi
 5782020-07-09T19:04:45  <ariard> you can drop #18787, after talking with few people, a libstandardness would be more accurate
 5792020-07-09T19:04:50  <gribble> https://github.com/bitcoin/bitcoin/issues/18787 | wallet: descriptor wallet release notes and cleanups by achow101 · Pull Request #18787 · bitcoin/bitcoin · GitHub
 5802020-07-09T19:04:51  *** pinheadmz1 has joined #bitcoin-core-dev
 5812020-07-09T19:05:01  <ariard> #18797 sorry
 5822020-07-09T19:05:04  <gribble> https://github.com/bitcoin/bitcoin/issues/18797 | Export standard Script flags in bitcoinconsensus by ariard · Pull Request #18797 · bitcoin/bitcoin · GitHub
 5832020-07-09T19:05:10  <jeremyrubin> removing #18191
 5842020-07-09T19:05:13  <gribble> https://github.com/bitcoin/bitcoin/issues/18191 | Change UpdateForDescendants to use Epochs by JeremyRubin · Pull Request #18191 · bitcoin/bitcoin · GitHub
 5852020-07-09T19:05:51  *** meshcoll- has quit IRC
 5862020-07-09T19:06:17  <jonatack> hi
 5872020-07-09T19:06:22  <promag> please see #19033, its for 0.20.1
 5882020-07-09T19:06:24  <gribble> https://github.com/bitcoin/bitcoin/issues/19033 | http: Release work queue after event base finish by promag · Pull Request #19033 · bitcoin/bitcoin · GitHub
 5892020-07-09T19:06:25  *** meshcollider has joined #bitcoin-core-dev
 5902020-07-09T19:06:25  <wumpus> ariard, achow101  done
 5912020-07-09T19:07:11  <wumpus> jeremyrubin: ok
 5922020-07-09T19:07:13  <luke-jr> would be nice to get the build tarballs fixed finally too <.<
 5932020-07-09T19:07:19  <meshcollider> hi
 5942020-07-09T19:08:10  <pinheadmz1> hi
 5952020-07-09T19:09:20  <wumpus> #topic clarification on the goals of the mempool project (jeremyrubin)
 5962020-07-09T19:09:49  <jeremyrubin> Yeah just quick;
 5972020-07-09T19:10:10  <jeremyrubin> So I think that there's some confusion or at least co-mingling of concerns based on how I've presented things
 5982020-07-09T19:10:20  *** ryanofsky_ has left #bitcoin-core-dev
 5992020-07-09T19:10:24  *** ryanofsky has joined #bitcoin-core-dev
 6002020-07-09T19:10:35  <jeremyrubin> A lot of the motivation is to reduce the memory usage in the mempool
 6012020-07-09T19:10:49  <jeremyrubin> and to better bound the algorithmic complexity on functions
 6022020-07-09T19:11:09  <jeremyrubin> So that one day, maybe, we could lift some restrictions (e.g., descendents)
 6032020-07-09T19:11:42  <jeremyrubin> It's less so "make mempool faster now" performance motivation.
 6042020-07-09T19:12:09  <wumpus> ok good to know
 6052020-07-09T19:12:13  <jeremyrubin> In a lot of cases I think it would be fine to accept a *slower* score on some benchmark (or at least the same) when the goal of the PR is reducing memory
 6062020-07-09T19:12:44  <jeremyrubin> especially in cases where there may be a distant invariant which is currently protecting us from a "crash the network" style DoS
 6072020-07-09T19:12:56  <luke-jr> if those are the goals, I wonder if it might make sense to move complexity into the miner
 6082020-07-09T19:13:00  <wumpus> we could have benchmarks that measure memory usage I suppose
 6092020-07-09T19:13:08  <luke-jr> but that could interfere with compact blocks
 6102020-07-09T19:13:27  <jeremyrubin> luke-jr: this does make sense for certain things.
 6112020-07-09T19:13:49  <luke-jr> I wonder if it'd be possible to support a build without mining support that performs better
 6122020-07-09T19:14:12  <jeremyrubin> I think one of the things that is difficult in particular is that we don't have a great set of adversarial benches for the mempool
 6132020-07-09T19:14:23  <jeremyrubin> And you need both whole-system and unit tests for the functions
 6142020-07-09T19:14:30  <wumpus> I think there's something of a conflict there, miners want the block selection to be as fast as possible, while other node users would want to reduce memory usage for the mempool as much as possible
 6152020-07-09T19:14:34  <jeremyrubin> And both asymptotic and bounded size
 6162020-07-09T19:14:37  <cfields> wumpus: +1
 6172020-07-09T19:15:19  <luke-jr> wumpus: by making mining build-time-optional, we could possibly get both cheaply?
 6182020-07-09T19:15:46  <ariard> I'm not sure about reducing the memory usage, what the relation between size of your mempool and perf of fee estimation ?
 6192020-07-09T19:15:50  <luke-jr> I wonder if there's a way to change class sizes at runtime in C++
 6202020-07-09T19:16:03  <jeremyrubin> Reducing memory usage is related to DoS primarily
 6212020-07-09T19:16:06  <wumpus> that's kind of annoying for testing but yes
 6222020-07-09T19:16:24  <jeremyrubin> So the goal is to eliminate the class  of vuln
 6232020-07-09T19:16:42  <luke-jr> jeremyrubin: eh? users can always adjust their mempool size
 6242020-07-09T19:16:46  <jeremyrubin> I don't care about performance here that much, even a 2x slower mempool with less DoS surface is probably fine
 6252020-07-09T19:16:53  <wumpus> it doesn't help if only the miners would have the vulnerability though
 6262020-07-09T19:16:55  <sipa> mempool size _predictability_ is a DoS concern
 6272020-07-09T19:16:55  <jeremyrubin> luke-jr: no for the algorithms themselves
 6282020-07-09T19:16:57  <luke-jr> reducing mem usage would just mean more txs per MB
 6292020-07-09T19:17:03  <jeremyrubin> not for the mempool size itself
 6302020-07-09T19:17:04  *** Talkless has quit IRC
 6312020-07-09T19:17:20  <ariard> I think there is a confusion there with memory usage of caching data structure for update and overall mempool size
 6322020-07-09T19:17:23  <sipa> e.g. improving average memory usage on average, but worsening it under a particular edge case might constitute a vulnerability
 6332020-07-09T19:17:23  <jeremyrubin> Mostly fixing short-lived allocations
 6342020-07-09T19:17:31  <nehan> jeremyrubin: what is your expected memory usage improvement?
 6352020-07-09T19:17:50  <luke-jr> sipa: but there's no vuln with zero mempool…
 6362020-07-09T19:18:32  <jeremyrubin> nehan: it's a project with a bunch of algorithm improvements based on epochs for traversal instead of sets
 6372020-07-09T19:18:37  <aj> (5min cap exceeded fwiw)
 6382020-07-09T19:18:51  <jeremyrubin> ah yeah didn't mean to turn this into an ordeal, just trying to clarify
 6392020-07-09T19:19:05  <luke-jr> not like we have any other topics?
 6402020-07-09T19:19:10  <sipa> perhaps just document this as a summary on the relevant PRs?
 6412020-07-09T19:19:16  <jeremyrubin> happy to move on if there's other things to discuss
 6422020-07-09T19:19:17  <sipa> unless it already is
 6432020-07-09T19:19:17  <wumpus> luke-jr: we do, sipa had a topic
 6442020-07-09T19:19:21  <luke-jr> oh
 6452020-07-09T19:19:30  <sipa> nothing important
 6462020-07-09T19:19:30  <luke-jr> right
 6472020-07-09T19:19:48  <wumpus> #topic can we drop gcc 4.8 (sipa)
 6482020-07-09T19:19:51  <MarcoFalke> why?
 6492020-07-09T19:19:54  <wumpus> just something to annoy fanquake
 6502020-07-09T19:19:58  <wumpus> :)
 6512020-07-09T19:19:59  <luke-jr> lol
 6522020-07-09T19:19:59  <cfields> lol
 6532020-07-09T19:20:02  <sipa> so, i was looking at #18086 again
 6542020-07-09T19:20:05  <gribble> https://github.com/bitcoin/bitcoin/issues/18086 | Accurately account for mempool index memory by sipa · Pull Request #18086 · bitcoin/bitcoin · GitHub
 6552020-07-09T19:20:32  <sipa> and was trying to make the accounting allocator not track copies of containers, which is a feature of the C++11 allocator infrastructure
 6562020-07-09T19:20:39  <wumpus> I *really* think we should wait with bumping gcc versions until c++17 requirement
 6572020-07-09T19:20:45  <sipa> but it seems gcc 4.8 ignores it or otherwise fails to implement it correctly
 6582020-07-09T19:20:46  <wumpus> which isn't too far away, just one major version
 6592020-07-09T19:20:52  <sipa> yeah
 6602020-07-09T19:21:17  <luke-jr> sipa: not the end of the world if it's wrong?
 6612020-07-09T19:21:18  <sipa> but i've just noticed at appveyor also fails at it :s
 6622020-07-09T19:21:25  <sipa> luke-jr: could cause UB
 6632020-07-09T19:21:32  <luke-jr> hmm
 6642020-07-09T19:21:33  <sipa> if used in totally reasonable ways
 6652020-07-09T19:21:40  <sipa> (but probably not in my actual PR)
 6662020-07-09T19:21:46  <wumpus> not that I'm opposed to bumping it sooner if it's eally required for something, but it seems a waste of time to discuss minor version bumps if a big one is around the cornr :)
 6672020-07-09T19:21:59  <luke-jr> when C++20? :p
 6682020-07-09T19:22:07  <wumpus> in 2025
 6692020-07-09T19:22:11  * luke-jr found C++20 to be required for totally obvious/expected features the other day :/
 6702020-07-09T19:22:14  <sipa> luke-jr: hard to talk about things that don't exist
 6712020-07-09T19:22:42  <cfields> luke-jr: get sipa to backport for you like Span :p
 6722020-07-09T19:22:50  <luke-jr> cfields: can't backport syntax
 6732020-07-09T19:22:59  <MarcoFalke> Only 3.6 months till branch off: https://github.com/bitcoin/bitcoin/issues/18947
 6742020-07-09T19:23:07  <luke-jr> struct type var = { .a = 1, .b = 2 }
 6752020-07-09T19:23:16  <jnewbery> sipa: can you #ifdef support for accounting allocators for only certain versions of gcc until we move to c++ 17?
 6762020-07-09T19:23:30  <wumpus> jnewbery: +1!
 6772020-07-09T19:23:34  <sipa> jnewbery: ugh
 6782020-07-09T19:23:34  <aj> luke-jr: omg, don't tease things like that
 6792020-07-09T19:23:37  <sipa> that's horrendous
 6802020-07-09T19:23:51  <luke-jr> aj: it's common C99, no clue why C++ forbids it :/
 6812020-07-09T19:24:09  <cfields> luke-jr: juse use unnamed initializers ?
 6822020-07-09T19:24:17  <luke-jr> cfields: but the whole point is the names!
 6832020-07-09T19:24:18  <wumpus> I mean, accurate memory accounting is nice but not critical I suppose, not enough reason to really forbid building on a platform
 6842020-07-09T19:24:59  <luke-jr> cfields: I ended up putting defaults for every member, and just setting the ones I care about after init
 6852020-07-09T19:25:19  <sipa> wumpus: it would mean ifdefs all over to maintain to old heuristics for every data structure, plus a accounting based one
 6862020-07-09T19:25:29  <luke-jr> https://github.com/bitcoin/bitcoin/pull/19463/files#diff-b2bb174788c7409b671c46ccc86034bdR291
 6872020-07-09T19:25:33  <sipa> so i guess i'd just wait instead
 6882020-07-09T19:25:35  <wumpus> anyhow according to #16684 the minimum gcc version will go to 8.3
 6892020-07-09T19:25:38  <gribble> https://github.com/bitcoin/bitcoin/issues/16684 | Discussion: upgrading to C++17 · Issue #16684 · bitcoin/bitcoin · GitHub
 6902020-07-09T19:25:47  <sipa> or try to minimize the risk of copying
 6912020-07-09T19:25:59  <cfields> sipa: can you point to exactly what old gcc gets wrong? I'm just curious to see.
 6922020-07-09T19:26:07  <jnewbery> sipa: ah ok. If it's super invasive to do, then not worth it
 6932020-07-09T19:26:28  <sipa> cfields: have a container with an accounting allocator, encapsulated in some class
 6942020-07-09T19:26:36  <sipa> return a copy of it for public consumption
 6952020-07-09T19:26:37  <wumpus> is changing this really urgent or can it wait until after 0.21?
 6962020-07-09T19:26:56  <sipa> now any changes to that copy need to lock the origin datastructure's accounting variable
 6972020-07-09T19:27:11  <luke-jr> 8.3 sounds pretty recent; is it already a sure thing major distros will have it in their stable releases?
 6982020-07-09T19:27:11  <sipa> because they're shared
 6992020-07-09T19:27:22  <MarcoFalke> gcc 7 is enough: https://github.com/bitcoin/bitcoin/pull/19183/files#diff-0c8311709d11060c5156268e58f5f209R14
 7002020-07-09T19:27:57  <wumpus> MarcoFalke: okay maybe I'm misreading the issue then
 7012020-07-09T19:27:59  <aj> 8.3 is in debian stable as the default gcc, only gcc 6 in oldstable
 7022020-07-09T19:28:15  <luke-jr> aj: RHEL tends to be the bottleneck
 7032020-07-09T19:28:18  <wumpus> in any case there is going to be a large bump
 7042020-07-09T19:28:38  <MarcoFalke> sipa: Maybe rebase to see if msvc can compile it with C++17. If not, there is something else to look into first anyway. Pretty sure the 3 months will pass quickly ;)
 7052020-07-09T19:28:39  <aj> luke-jr: it has software collections now so you get new gcc/clang on old rhel pretty easy
 7062020-07-09T19:28:54  <sipa> RHEL8 has gcc 8.2
 7072020-07-09T19:28:57  <luke-jr> aj: oh!
 7082020-07-09T19:29:37  <sipa> RHEL7 uses gcc 4.8 by default
 7092020-07-09T19:29:53  <luke-jr> do we care about old stables now?
 7102020-07-09T19:29:53  <sipa> (we've strayed a bit from the topic, but that's ok unless someone has something else)
 7112020-07-09T19:30:01  <aj> https://www.softwarecollections.org/en/scls/rhscl/devtoolset-8/  -- gcc 8 for rhel 6 and 7
 7122020-07-09T19:30:08  <instagibbs> mempool delta notifications topic
 7132020-07-09T19:30:13  <wumpus> can always cross-compile anyway
 7142020-07-09T19:30:21  <luke-jr> wumpus: that's a bit much for most users
 7152020-07-09T19:30:34  <wumpus> #topic mempool delta notifications (instagibbs)
 7162020-07-09T19:30:56  <cfields> sipa: I was under the impression you weren't supposed to inherit from std::allocator in c++11.
 7172020-07-09T19:31:04  <cfields> ok, will look more after the meeting.
 7182020-07-09T19:31:10  <instagibbs> Ok, so recently I wrote a one-off zmq notification for mempool evictions, which are currently not covered. Other people have more exntensive ideas: https://github.com/bitcoin/bitcoin/pull/19476
 7192020-07-09T19:31:18  <instagibbs> shuckc, can you speak to motivation/usage?
 7202020-07-09T19:31:19  <wumpus> luke-jr: maybe, it's not that much more difficult, especially nowadays with the extreme availability of VMs etc
 7212020-07-09T19:31:32  <sipa> cfields: ah, i can try avoiding that
 7222020-07-09T19:31:43  <instagibbs> promag also made a WIP mempool delta RPC as another possible option https://github.com/bitcoin/bitcoin/pull/19476
 7232020-07-09T19:32:00  <cfields> sipa: no idea if that's useful, need to spend a whole lot more time understanding what you're doing :)
 7242020-07-09T19:32:53  <shuckc> We track a huge number of wallets, keeping mempool contents synchronised is tricky given incomplete notifications, and difficult to sychronise between api and zmq notifications
 7252020-07-09T19:33:35  <shuckc> seems like an opportunity to cover off a lot of the edge cases in one go
 7262020-07-09T19:33:48  <instagibbs> so ideally you could getrawmempool like once, then use zmq notifications to track delta, then maybe call getrawmempool when something drops for whatever reason, and be able to figure out "where" in that notification stream the snapshot is from
 7272020-07-09T19:33:54  <luke-jr> instagibbs: you linked the same PR twice
 7282020-07-09T19:33:58  <instagibbs> oh woops
 7292020-07-09T19:34:09  <instagibbs> https://github.com/bitcoin/bitcoin/pull/19462#issueacomment-656140421
 7302020-07-09T19:34:11  <luke-jr> instagibbs: ZMQ is very unreliable..
 7312020-07-09T19:34:38  <wumpus> instagibbs: that makes sense
 7322020-07-09T19:34:45  <wumpus> no, ZMQ is not very unreliable
 7332020-07-09T19:34:52  <instagibbs> sure luke-jr so alternative would likely look like promag pr i linked
 7342020-07-09T19:34:56  <instagibbs> maybe long polling
 7352020-07-09T19:34:59  <wumpus> only in pretty extreme circumstances it sometimes drops a packet
 7362020-07-09T19:35:02  <sipa> ZMQ has no reliability _guarantees_
 7372020-07-09T19:35:17  <wumpus> and in that case there needs to be a way to resynchronize, anyway, as instagibbs  says
 7382020-07-09T19:35:27  <luke-jr> wumpus: I used it for low traffic on a reliable network, and it still lost stuff regularly
 7392020-07-09T19:35:28  <sipa> but absent overflow conditiins, it is very reliable
 7402020-07-09T19:35:32  <wumpus> notifications have sequence numbers to be able to detect that
 7412020-07-09T19:35:38  <sipa> luke-jr: hmm, ok
 7422020-07-09T19:35:39  <instagibbs> and avoiding "lots" of getrawmempools I guess is hte biggest goal
 7432020-07-09T19:35:44  <wumpus> sipa: yes, in the general case it is very reliable
 7442020-07-09T19:35:47  <promag> the biggest problem if you have to take the client offline for a bit
 7452020-07-09T19:35:54  <shuckc> ZMQ generally work as well as any other pubsub system so long as you have the high watermark set sufficiently high, and you are not trying to consume slower than the publisher is producing. I don't see that as a particular obstancle
 7462020-07-09T19:36:11  <wumpus> unless your client is not consuming the notifications reliably: there can't be an infinite buffer
 7472020-07-09T19:36:24  <wumpus> (unless you'd spool to disk or something like that)
 7482020-07-09T19:36:47  <promag> shuckc: zmq pub doesn't hold msg if client is offline.
 7492020-07-09T19:36:51  <wumpus> but I don't think adding yet another notifications system with mail-like reliablity is really what we want
 7502020-07-09T19:37:10  <shuckc> if your client goes away, you are going to have to hit getrawmempools for sure. but would like to avoid those calls in the general case as big result set (even when brief)
 7512020-07-09T19:37:39  <wumpus> I mean there's mq systems like rabbitmq that guarantee 100% reliability
 7522020-07-09T19:37:51  <promag> the approach in #19476 avoids periodic getrawmempools
 7532020-07-09T19:37:53  <gribble> https://github.com/bitcoin/bitcoin/issues/19476 | wip, rpc: Add mempoolchanges by promag · Pull Request #19476 · bitcoin/bitcoin · GitHub
 7542020-07-09T19:38:00  <jnewbery> why not have ZMQ log every txid it sends a notification for along with seq number. If your client detects a drop it can consult the log and query the mempool for that txid?
 7552020-07-09T19:38:04  <wumpus> but I mean, how many of these things do you want to integrate with
 7562020-07-09T19:38:07  <instagibbs> promag, your rpc could be maybe generalized into block hash announcements too, connect/disconnect
 7572020-07-09T19:38:24  <instagibbs> jnewbery, it has as seq number
 7582020-07-09T19:38:36  <instagibbs> but right now it's a hodgepodge of endpoints
 7592020-07-09T19:38:41  <wumpus> yes, it has a seq number
 7602020-07-09T19:38:43  <instagibbs> and missing eviction entirely
 7612020-07-09T19:39:07  <jnewbery> right, we're talking about two things here. Let's assume that your eviction PR is merged
 7622020-07-09T19:39:11  <wumpus> all the zmq endpoints have seq numbers
 7632020-07-09T19:39:31  <shuckc> if eviction PR is merged, the remaining issues are:
 7642020-07-09T19:39:31  <wumpus> I'mnot sure these are actually useful because people keep complaining about this
 7652020-07-09T19:39:53  <promag> wumpus: you don't know at what sequence corresponds a getrawmempool response
 7662020-07-09T19:40:02  <wumpus> no, indeed you don't
 7672020-07-09T19:40:15  <shuckc> I cannot know for sure if the txn hash broadcasts are adds or block removals, as they don't specify, and I can't for sure know how it lines up with the results of getrawmempool
 7682020-07-09T19:40:16  <jnewbery> for reliability, ZMQ can log seq_num:txid to file every time a notification is sent. If a client detects a missing seq_num, you consult the log and query the mempool rpc for that file
 7692020-07-09T19:40:33  *** Evel-Knievel has joined #bitcoin-core-dev
 7702020-07-09T19:40:35  <wumpus> zmq logging to file? taht sounds really at odd with low-latency
 7712020-07-09T19:40:35  <jnewbery> *for that txid
 7722020-07-09T19:40:45  <luke-jr> wumpus: mkfifo ☺
 7732020-07-09T19:40:55  <wumpus> luke-jr: fifo is one to one, not one to many
 7742020-07-09T19:40:56  <luke-jr> not sure why ZMQ is involved at that point lol
 7752020-07-09T19:40:58  <luke-jr> true
 7762020-07-09T19:41:05  <wumpus> luke-jr: if only UNIX had a one to many notification mechanism
 7772020-07-09T19:41:13  <wumpus> except for mail
 7782020-07-09T19:41:14  <luke-jr> dbus?
 7792020-07-09T19:41:27  <sipa> wumpus: oh you can have many writers and many readers for one fifo just fine ;)    and no guarantee which write goes to which read
 7802020-07-09T19:41:29  <aj> wumpus: wall(1) :)
 7812020-07-09T19:41:32  * luke-jr is not sure dbus actually has this
 7822020-07-09T19:41:35  <luke-jr> aj: lol
 7832020-07-09T19:41:38  <wumpus> no, dbus doesn't have it either
 7842020-07-09T19:41:45  *** shuckc has quit IRC
 7852020-07-09T19:41:48  <wumpus> dbus is one to one, it has no realible multi consumer broadcase
 7862020-07-09T19:42:13  <luke-jr> I suppose you could just use a tmpfs file
 7872020-07-09T19:42:13  <wumpus> it's a difficult issue in general
 7882020-07-09T19:42:20  <wumpus> because some consumer might always be lagging
 7892020-07-09T19:42:21  <luke-jr> and punch holes at the start as desired
 7902020-07-09T19:42:29  <wumpus> this can potentially result in infinitely much storage needed
 7912020-07-09T19:42:36  <luke-jr> or store to disk and let Linux's buffers handle it
 7922020-07-09T19:42:47  <wumpus> rabbitmq is pretty good if you really need this
 7932020-07-09T19:44:28  *** shuckc has joined #bitcoin-core-dev
 7942020-07-09T19:45:10  <instagibbs> Well aside from fixing infinite buffer problems, I think it'd be good to improve where we can. When there's a failure there's always the fallback of getrawmempool for example
 7952020-07-09T19:45:11  <jnewbery> wumpus: zmq already logs (if -logging=zmq is enabled). It just doesn't log the seq num, so it's not easy for a client to tell which messages were dropped
 7962020-07-09T19:45:32  <instagibbs> I was joking that you could also do minisketch for set reconciliation of mempool views
 7972020-07-09T19:45:47  <sipa> haha
 7982020-07-09T19:45:54  <luke-jr> jnewbery: I'm not sure we want to encourage software to parse debug.log …
 7992020-07-09T19:45:58  <instagibbs> zmq to keep difference small ;)
 8002020-07-09T19:46:00  <wumpus> jnewbery: I don't think clients can ever know what message is dropped; usually, missing a sequnence number means having to resyncronize in some way (e.g.e query the entire mempool)
 8012020-07-09T19:46:11  <wumpus> luke-jr: exactly
 8022020-07-09T19:46:30  <wumpus> I don't think 'parse the log' is a good option, though it serves one-to-many notification perfectly
 8032020-07-09T19:46:37  <wumpus> mq is essentially a log
 8042020-07-09T19:46:43  <wumpus> until your disk is full
 8052020-07-09T19:46:45  <luke-jr> a dedicated, well-defined-format log might be okay
 8062020-07-09T19:47:07  <wumpus> it's also a high latency option but that might not matter
 8072020-07-09T19:47:07  <luke-jr> but something needs to do hole-punching to clean it up before disk fills
 8082020-07-09T19:47:15  <luke-jr> wumpus: why is it high latency?
 8092020-07-09T19:47:23  <wumpus> yes, but if you do tha, some clients might miss messages
 8102020-07-09T19:47:32  <sipa> luke-jr: bitcoind will already shut down when disk is full
 8112020-07-09T19:47:33  <sipa> :)
 8122020-07-09T19:47:35  <luke-jr> depends on who does it
 8132020-07-09T19:47:35  <wumpus> unless they tell you they read up until that far
 8142020-07-09T19:47:43  <luke-jr> sipa: yes, but you don't want that
 8152020-07-09T19:47:55  <wumpus> luke-jr: because disk/block devices are slow, compared to networking, latency wise
 8162020-07-09T19:48:02  <luke-jr> wumpus: Linux at least has buffers
 8172020-07-09T19:48:08  <wumpus> even with that
 8182020-07-09T19:48:11  <luke-jr> :/
 8192020-07-09T19:48:20  <luke-jr> the write/read won't even need to hit disk
 8202020-07-09T19:48:32  * luke-jr wonders if you can tell Linux to never flush to disk unless it has to
 8212020-07-09T19:48:37  <luke-jr> per-device*
 8222020-07-09T19:48:45  <luke-jr> per-file would also be nice :P
 8232020-07-09T19:49:04  <wumpus> yes, there's an option for that afaik, but it also means in case of power loss...
 8242020-07-09T19:49:08  *** gzhao408 has quit IRC
 8252020-07-09T19:49:47  <jnewbery> shuckc: it sounded like you were going to mention more issues. Was there anything else?
 8262020-07-09T19:49:50  <wumpus> reliable delivery of messages to multiple consumers is a difficult topic
 8272020-07-09T19:50:08  <sipa> we need a blockchain
 8282020-07-09T19:50:13  <wumpus> sipa: :-)
 8292020-07-09T19:50:31  <instagibbs> so i think the biggest oustanding issue(if evictions are announced and we're ok with drops once i na while) is being able to line up getrawmempool results with the notifications
 8302020-07-09T19:50:32  <wumpus> yes, at least the blockchain always allows going back i time... well unless pruning
 8312020-07-09T19:50:44  <wumpus> pruning is kind of the 'what if not all consumers have seen this yet' problem
 8322020-07-09T19:50:45  <shuckc> the sequence number on the response to getrawmempool
 8332020-07-09T19:51:09  <shuckc> obviously has backward compatibility concerns, and other suggestions?
 8342020-07-09T19:51:20  <sipa> shuckc: hmm?
 8352020-07-09T19:51:29  <luke-jr> wumpus: there is an option for that? what? :o
 8362020-07-09T19:51:32  <instagibbs> sipa, he wants to know where the mempool "snapshot" came from
 8372020-07-09T19:51:37  <sipa> does getrawmempool report a sequence number now?
 8382020-07-09T19:51:41  <instagibbs> no
 8392020-07-09T19:51:45  <wumpus> it doesn't
 8402020-07-09T19:51:49  <shuckc> no, I'm suggeting it should
 8412020-07-09T19:51:49  <sipa> and adding one would help?
 8422020-07-09T19:51:52  <shuckc> yes
 8432020-07-09T19:51:54  <sipa> oh, ok
 8442020-07-09T19:52:03  <instagibbs> so you don't know if the getrawmempool result is stale or from "future" wrt zmq reports
 8452020-07-09T19:52:05  <sipa> what would be the reason not to?
 8462020-07-09T19:52:05  <shuckc> because you can't tell which delta(s) have already been added
 8472020-07-09T19:52:09  <wumpus> I guess it could prove that there were no updates in between
 8482020-07-09T19:52:12  <sipa> adding new fields has no backward compatibility concerns
 8492020-07-09T19:52:19  <instagibbs> sipa, I think you'd have to add *all* the zmq notification seq numbers
 8502020-07-09T19:52:24  <sipa> ah
 8512020-07-09T19:52:26  <instagibbs> well it's an array result ;
 8522020-07-09T19:52:28  <instagibbs> ;)
 8532020-07-09T19:52:34  <promag> can bnly be added if verbose=true in getrawmempool
 8542020-07-09T19:52:39  <instagibbs> but like I said I think optional arg -> json object
 8552020-07-09T19:52:45  <wumpus> I wonder why every zmq message has its own sequence number
 8562020-07-09T19:52:54  <wumpus> couldn't it be just one increasing atomic?
 8572020-07-09T19:52:55  <shuckc> unless you have one single notifier that you use for all the messages you need to sync with
 8582020-07-09T19:52:56  <instagibbs> wumpus, it's a local member of hte notification, for whatever reason
 8592020-07-09T19:53:09  <promag> wumpus: a client knows if he missed anything
 8602020-07-09T19:53:18  <wumpus> promag: oh, true
 8612020-07-09T19:53:18  <shuckc> it's only a mess if need to track lots of notifiers
 8622020-07-09T19:53:32  <wumpus> yes, makes sense, a client is generally interested in only a subset of message kinds
 8632020-07-09T19:53:35  <instagibbs> shuckc, shouldn't be too bad, you just grab the one you care about
 8642020-07-09T19:53:45  <wumpus> so a global sequence number would be useless
 8652020-07-09T19:54:11  <promag> wumpus: not really, that number should be exposed in both rpc response and zmq message
 8662020-07-09T19:54:18  <wumpus> in any case getmempool would only need the mempool related numbers...
 8672020-07-09T19:54:26  <promag> but I'm not fond of that..
 8682020-07-09T19:54:42  <wumpus> it seems like some kind of layer violation
 8692020-07-09T19:54:46  <wumpus> having RPC query ZMQ
 8702020-07-09T19:54:54  <promag> because as a client, you need to use rpc AND zmq
 8712020-07-09T19:54:59  <wumpus> yes
 8722020-07-09T19:55:02  <instagibbs> otherwise you need to somehow ask for unique snapshot
 8732020-07-09T19:55:11  <promag> hence my draft PR
 8742020-07-09T19:55:11  <instagibbs> of the mempool
 8752020-07-09T19:55:33  <instagibbs> but yes, it's a light violation at least
 8762020-07-09T19:55:35  *** owowo has quit IRC
 8772020-07-09T19:55:40  <phantomcircuit> shuckc, zmq can and will silently drop messages, unless you have sequence numbers in the application layer you cannot detect that
 8782020-07-09T19:55:44  <shuckc> My suggestion includes connectblock and disconnect block notifications on the same new channel, because they allow you to keep your local mempool up to date and equally you need to know where in the stream of deltas they arrived
 8792020-07-09T19:56:00  <wumpus> of course, that could be worked around by having both RPC and ZMQ query another source for sequence numbers
 8802020-07-09T19:56:03  <jnewbery> how about if the mempool itself had a seq number that is incremented on every add/remove?
 8812020-07-09T19:56:09  <wumpus> right
 8822020-07-09T19:56:19  <instagibbs> jnewbery, that's promag's pr pretty much-ish
 8832020-07-09T19:56:20  <wumpus> I think that would make sense
 8842020-07-09T19:57:08  <instagibbs> 3 minutes
 8852020-07-09T19:57:25  <wumpus> so +1 on jnewbery/promag's idea then
 8862020-07-09T19:57:44  <shuckc> with promags suggestion, bitcoind has to keep state/buffer for each consumer, the zmq model makes it state-less, and promag you also need to poll for new messages which is something of a step backwatfs
 8872020-07-09T19:58:05  <wumpus> I didn't understand it like that
 8882020-07-09T19:58:09  <promag> note that in my PR, the "stream" will be upper bounded in size, so no OOM concerns
 8892020-07-09T19:58:10  <luke-jr> shuckc: not if he adds longpolling
 8902020-07-09T19:58:15  <wumpus> the mempool itself would keep the seq number
 8912020-07-09T19:58:24  <wumpus> not per consumer
 8922020-07-09T19:58:29  <promag> shuckc: ill add long poll
 8932020-07-09T19:58:36  <wumpus> it's kind of strange if different consumers have differnt seq ids
 8942020-07-09T19:58:41  <shuckc> do any other commands use long polling?
 8952020-07-09T19:58:45  <wumpus> because this is global state we're exposing
 8962020-07-09T19:58:46  <luke-jr> GBT
 8972020-07-09T19:58:46  <phantomcircuit> wumpus, if zmq is using a global sequence number for all messages, i'd suggest just adding that to rpc as a header or something
 8982020-07-09T19:58:46  <promag> shuckc: yes
 8992020-07-09T19:58:51  <instagibbs> getblocktemplate <--- GBT
 9002020-07-09T19:59:10  *** Evel-Knievel has quit IRC
 9012020-07-09T19:59:12  <promag> I don't like longpoll that much tbh, at least in json rpc
 9022020-07-09T19:59:33  <promag> especially because of libevent, timeouts etcetc
 9032020-07-09T19:59:51  <promag> but "poll and wait up to n secs" if fine imo
 9042020-07-09T19:59:52  <wumpus> I don't think adding a different notification mechanism will really solve the 'clients could stop consuming and keep behind'  problem
 9052020-07-09T20:00:02  <luke-jr> promag: same thing? :P
 9062020-07-09T20:00:03  <wumpus> it would mean accumulating in memory in that case?
 9072020-07-09T20:00:20  <promag> luke-jr: n secs < timeoud (:
 9082020-07-09T20:00:26  <promag> wumpus: yes
 9092020-07-09T20:00:31  <fjahr> I guess I am the hammer that sees nails everywhere, but how about a hash (muhash) for the mempool states instead of a sequence number? but not sure i grasp the problem completely yet...
 9102020-07-09T20:00:33  <promag> but thats's fine
 9112020-07-09T20:00:50  <luke-jr> fjahr: then you need to log the hash..
 9122020-07-09T20:00:55  <promag> if the client doensn't pull the stream, the stream will be terminated
 9132020-07-09T20:00:56  <wumpus> no, I don't think that's fine, if there's no limit a client could forget to connect and fill your memory entirely
 9142020-07-09T20:01:00  <instagibbs> fjahr, even more ridiculous than my minisketch idea ;P
 9152020-07-09T20:01:10  <wumpus> promag: that's just another "lose notifications" then
 9162020-07-09T20:01:17  <fjahr> hehe
 9172020-07-09T20:01:41  <luke-jr> wumpus: it's one thing to begin dropping stuff after N minutes of downtime; another to lose them randomly as a normal event
 9182020-07-09T20:01:47  <wumpus> reliable notification is really a non-trivial issue :)
 9192020-07-09T20:01:49  <promag> wumpus: no, the stream will be terminated, the client starts over and gets a fresh stream
 9202020-07-09T20:01:57  <wumpus> in any case, it's time
 9212020-07-09T20:02:09  <aj> instagibbs: (minisketch is a great idea!)
 9222020-07-09T20:02:11  <wumpus> #endmeeting
 9232020-07-09T20:02:11  <lightningbot> Meeting ended Thu Jul  9 20:02:11 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
 9242020-07-09T20:02:11  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-07-09-19.00.html
 9252020-07-09T20:02:11  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-07-09-19.00.txt
 9262020-07-09T20:02:11  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-07-09-19.00.log.html
 9272020-07-09T20:02:17  <luke-jr> promag: maybe this should be part of getrawmempool?
 9282020-07-09T20:02:26  *** owowo has joined #bitcoin-core-dev
 9292020-07-09T20:02:26  <instagibbs> aj, just need the tool in -cli, I think :D
 9302020-07-09T20:02:28  <shuckc> if the longpoll machinery all works, then I don't have any reason why not to use it. So long as it can be sequenced with repect to the getrawmempool calls and covers all the removals/additions cases
 9312020-07-09T20:02:48  <promag> luke-jr: meh, let's not overload, at least for the momemnt
 9322020-07-09T20:02:51  <wumpus> it has the same problems I think
 9332020-07-09T20:03:02  <luke-jr> promag: well, they need to interact..
 9342020-07-09T20:03:17  <instagibbs> shuckc, I think the idea would be you'd replace getrawmempool entirely with this new call
 9352020-07-09T20:03:22  <wumpus> it's another method to receive notifications but doesn't avoid any of the problems, the HTTP buffer can also be full
 9362020-07-09T20:03:22  <promag> shuckc: you won't use getrawmempool anymore
 9372020-07-09T20:03:23  <luke-jr> wumpus: forever buffer vs limited buffer vs no buffer
 9382020-07-09T20:03:29  <shuckc> I kind of like that. getrawmempool could give the snapshot and then if you've got longpool flag then it continues to stream modifications
 9392020-07-09T20:03:37  <wumpus> luke-jr: zmq has a limited buffer, like anything
 9402020-07-09T20:03:47  <luke-jr> wumpus: not in my experience
 9412020-07-09T20:03:57  <wumpus> you can even set it with some option
 9422020-07-09T20:04:00  <promag> wumpus: you call "mempoolchanges <stream id> <max enntries> <timeout>"
 9432020-07-09T20:04:26  <promag> wumpus: so you don't worry about http response size etc
 9442020-07-09T20:04:50  <luke-jr> promag: s/stream id/last update id/
 9452020-07-09T20:04:58  <wumpus> what if it exceeds the number of entries then?
 9462020-07-09T20:05:00  <promag> the concept is pretty much like postgres write-ahead-log and replication slots
 9472020-07-09T20:05:09  <luke-jr> promag: and for timeout, the client can just disconnect?
 9482020-07-09T20:05:19  <luke-jr> wumpus: then you need to get the entire mempool and start over
 9492020-07-09T20:05:26  <promag> luke-jr: no, stream id - you can have multiple clients, each with their own stream
 9502020-07-09T20:05:32  <luke-jr> (which is another reason to overload getrawmempool?)
 9512020-07-09T20:05:35  <wumpus> exactly as with zmq notifications if you miss a sequence number
 9522020-07-09T20:05:41  <luke-jr> promag: they shouldn't have separate streams
 9532020-07-09T20:06:03  <luke-jr> wumpus: except you're less likely to miss one
 9542020-07-09T20:06:06  <wumpus> I really don't see how a different notificatoin mechanism solves the underlying problems, but ok, if you belive so, go ahead
 9552020-07-09T20:06:13  <wumpus> 'less likely' is no guarantee!
 9562020-07-09T20:06:19  <promag> need to afk, please view my PR code, it's very small/simple
 9572020-07-09T20:06:37  <luke-jr> wumpus: it doesn't need to be a guarantee to work well
 9582020-07-09T20:06:53  <wumpus> if losing a notification is a critical issue, a smaller chance of it is better but still a critical problem
 9592020-07-09T20:06:57  *** promag_ has quit IRC
 9602020-07-09T20:07:13  *** promag_ has joined #bitcoin-core-dev
 9612020-07-09T20:07:15  <luke-jr> it's not critical, just something you'd prefer to avoid
 9622020-07-09T20:07:18  <instagibbs> hopefully not critical anywhere
 9632020-07-09T20:07:18  <shuckc> I'll review it promag and see if it covers all our uses
 9642020-07-09T20:07:22  <wumpus> how do you mean 'work well' then, not lose money for *most* users?
 9652020-07-09T20:07:33  <luke-jr> wumpus: it's an optimisation
 9662020-07-09T20:07:46  <luke-jr> you *could* always just getrawmempool constantly, but it'd be slow
 9672020-07-09T20:07:58  <wumpus> you need to setup your client code to handle missing notifications in any case
 9682020-07-09T20:08:13  <luke-jr> yes, and hopefully it won't happen often
 9692020-07-09T20:08:18  <wumpus> you can increase the zmq buffer size for that
 9702020-07-09T20:08:20  <instagibbs> miss message -> patch with getrawmempool-like response
 9712020-07-09T20:08:29  <instagibbs> keep that infrequent, it's a win
 9722020-07-09T20:08:44  <wumpus> people have been discussing this since 2012 or so since zmq notifications were added
 9732020-07-09T20:09:05  <instagibbs> and yet, we don't have eviction notifications at all :P
 9742020-07-09T20:09:10  <wumpus> I wish we never did fwiw
 9752020-07-09T20:09:13  <instagibbs> understood though im sure it's tiring
 9762020-07-09T20:09:14  <luke-jr> wumpus: admittedly I haven't used ZMQ since these problems, but it didn't work for me
 9772020-07-09T20:09:19  <wumpus> it's only been like this every time
 9782020-07-09T20:09:23  <wumpus> ZMQ IS UNRELIABLE
 9792020-07-09T20:09:24  <wumpus> ITS USELESS
 9802020-07-09T20:09:26  <wumpus> yeshh
 9812020-07-09T20:09:50  <wumpus> like let's just remove it
 9822020-07-09T20:09:54  <aj> could convert mempool entry's nTime to a monotonic clock, and use that as a sequence? "getrawmempool -- but only entries added since time X" maybe
 9832020-07-09T20:09:56  <instagibbs> well, it's being used in the wild, SFYL
 9842020-07-09T20:10:02  <instagibbs> LND uses it too
 9852020-07-09T20:10:11  <instagibbs> (don't know why exactly, just does)
 9862020-07-09T20:10:13  <wumpus> instagibbs: I know
 9872020-07-09T20:10:16  <promag> wumpus: too late, sorry for that honestly X)
 9882020-07-09T20:10:43  <wumpus> instagibbs: I know it's actually used by peple in production, but the discussions are always the same
 9892020-07-09T20:10:50  <instagibbs> understood
 9902020-07-09T20:10:59  <promag> #6103 :shame:
 9912020-07-09T20:11:04  <gribble> https://github.com/bitcoin/bitcoin/issues/6103 | Add ZeroMQ notifications by promag · Pull Request #6103 · bitcoin/bitcoin · GitHub
 9922020-07-09T20:11:29  <wumpus> sorry :)
 9932020-07-09T20:11:49  <promag> cheers
 9942020-07-09T20:11:58  *** promag_ has quit IRC
 9952020-07-09T20:12:32  <wumpus> I think it was like 'zmq is even used by high frequency traders and such it's probably useful for us'
 9962020-07-09T20:12:34  *** promag_ has joined #bitcoin-core-dev
 9972020-07-09T20:13:03  *** promag has quit IRC
 9982020-07-09T20:13:37  *** promag has joined #bitcoin-core-dev
 9992020-07-09T20:14:41  *** Evel-Knievel has joined #bitcoin-core-dev
10002020-07-09T20:14:50  <cfields> sipa: I suppose the old gcc issue is that the propagate_on_container_* aren't respected ?
10012020-07-09T20:15:03  <sipa> cfields: possibly
10022020-07-09T20:15:12  <sipa> but it looks like that
10032020-07-09T20:15:55  <wumpus> every time anyone mentions zmq it's: but it's unreliable!!! which is true, it's optimized for low latency, not reliability, all other mq products that historically were optimized for reliability, zmq intentionally made this trade-off
10042020-07-09T20:17:49  <jnewbery> In general, I don't think we should add yet another notification system to work around a supposed shortcoming in ZMQ. Then we just have an additional notification system to maintain
10052020-07-09T20:17:58  <wumpus> one other common reliable mq notification system nowadays is Apache Kafka
10062020-07-09T20:18:03  <jnewbery> if ZMQ is really unfit for purpose it should be removed and replaced
10072020-07-09T20:18:17  <wumpus> I agree
10082020-07-09T20:18:24  *** promag has quit IRC
10092020-07-09T20:18:33  <instagibbs> If you waved away the getrawmempool thing, I think it's probably fine enough
10102020-07-09T20:19:39  <instagibbs> block notifications are very cheap to "heal", 300MB mempool is not
10112020-07-09T20:20:01  <cfields> sipa: from libstdc++ 4.8 release docs "23.2.1	General container requirements	Partial	Only vector and forward_list meet the requirements relating to allocator use and propagation."
10122020-07-09T20:20:47  <sipa> cfields: ah
10132020-07-09T20:25:34  <cfields> sipa: if it makes you feel any better, looks like support for all standard containers didn't exist until 6.x.
10142020-07-09T20:25:36  <instagibbs> jnewbery, so I think you'd still need to make a layer violation(or replace getrawmempool with set reconciliation protocol) to smoothly use zmq, even with logging backing. I think that's two complementary improvements.
10152020-07-09T20:26:14  <instagibbs> if you're going to have to use RPC, might as well use RPC?
10162020-07-09T20:26:18  <wumpus> instagibbs: I guess it could be cheaper by using some binary format for the mempool; but in practice, losing messages should be rae, when I still used zmq for some notificaiton system I don't remember ever losing a message, just make sure that's a thread in the client that keeps reading
10172020-07-09T20:27:07  <sipa> cfields: seems i may just need to give up on the no-propagate-on-copy, and add a big disclaimer
10182020-07-09T20:28:18  <cfields> sipa: that's really a shame. I remember spending a few days banging my head against the wall trying to make scoped_allocator_adaptor do something interesting. I now see that it was probably just quietly broken under the hood the whole time.
10192020-07-09T20:28:26  <wumpus> in any case, adding a sequence number to getrawmempool to that the full dump can be reconciled with updates makes sense
10202020-07-09T20:28:37  <wumpus> independent of the notification system
10212020-07-09T20:28:39  <instagibbs> wumpus, yeah, just saying aside from mempool sync protocol I think we need to tell the consumer where raw mempool responses work
10222020-07-09T20:29:23  *** pinheadmz1 has quit IRC
10232020-07-09T20:30:01  <sipa> cfields: also now i remember the reason why i made it inherit from std::allocator
10242020-07-09T20:30:27  <sipa> old libstdc++ doesn't implement allocator_traits, so you need all dozen trivial functions and types on it
10252020-07-09T20:30:48  <cfields> oh, heh, yeah, that'd be a problem.
10262020-07-09T20:30:57  <sipa> it's just inconvenient
10272020-07-09T20:31:18  <wumpus> it's much more practical to have a system that can handle (but generally doesn't need to handle) going out of sync than something that can guarantee 100% delivery, so if adding a update sequence # to the mempool solves that that'd be preferable imo
10282020-07-09T20:31:28  <sipa> cfields: https://github.com/bitcoin/bitcoin/pull/18086/commits/378bbcd271734665b973351bf3862b3943b10ffc
10292020-07-09T20:31:34  <instagibbs> ok!
10302020-07-09T20:34:32  <cfields> sipa: when I said "you're not supposed to inherit from std::allocator in c++11", I just meant that IIRC you're supposed to lean on allocator_traits instead. So yeah, without that, I see why you just inherited.
10312020-07-09T20:36:00  <cfields> sipa: but given that support is missing from the containers themselves, I doubt that change will change anything for the better :(
10322020-07-09T20:36:13  *** justanotheruser has joined #bitcoin-core-dev
10332020-07-09T20:36:32  <cfields> sipa: also, nit, isn't std::allocator guaranteed stateless? Can't you just call its static members?
10342020-07-09T20:37:11  *** justan0theruser has quit IRC
10352020-07-09T20:41:28  <cfields> nm, obviously not.
10362020-07-09T20:41:43  *** zaff has quit IRC
10372020-07-09T20:52:43  *** proofofkeags has quit IRC
10382020-07-09T20:54:58  *** bitcoin-git has joined #bitcoin-core-dev
10392020-07-09T20:54:58  <bitcoin-git> [bitcoin] JeremyRubin opened pull request #19478: Kill mapLinks data structure in Mempool (master...epoch-mempool-clean-split-3) https://github.com/bitcoin/bitcoin/pull/19478
10402020-07-09T20:54:59  *** bitcoin-git has left #bitcoin-core-dev
10412020-07-09T20:58:11  *** Guyver2 has quit IRC
10422020-07-09T21:00:02  *** Xing`1 has quit IRC
10432020-07-09T21:02:40  *** nik-j has quit IRC
10442020-07-09T21:03:15  *** nik-j has joined #bitcoin-core-dev
10452020-07-09T21:06:30  *** nik-j has quit IRC
10462020-07-09T21:06:43  *** nik-j has joined #bitcoin-core-dev
10472020-07-09T21:14:52  *** ghost43 has quit IRC
10482020-07-09T21:15:12  *** ghost43 has joined #bitcoin-core-dev
10492020-07-09T21:17:06  *** shuckc has quit IRC
10502020-07-09T21:18:34  *** Randolf has joined #bitcoin-core-dev
10512020-07-09T21:22:33  *** KindOne1 has joined #bitcoin-core-dev
10522020-07-09T21:27:18  *** promag has joined #bitcoin-core-dev
10532020-07-09T21:29:33  *** proofofkeags has joined #bitcoin-core-dev
10542020-07-09T21:29:51  *** Randolf has quit IRC
10552020-07-09T21:31:02  <cfields> llvm's lld (in master, not released) is complete enough as of this week to link a working bitcoind for macos from linux, without having to resort to building apple's custom ld64 :)
10562020-07-09T21:31:29  <cfields> jonatack: thanks for the motivation to build llvm today, I really wanted to test ^^
10572020-07-09T21:32:27  <cfields> No idea how well at works, but "./bitcoind --help" works, at least.
10582020-07-09T21:34:43  <promag> cfields: nice, builds qt too?
10592020-07-09T21:35:53  <cfields> promag: heh, no clue. I didn't want to end up deep in qt link issues...
10602020-07-09T21:36:22  <cfields> I should though. This work is active on lld right now. Good time for us to be reporting issues/patches.
10612020-07-09T21:43:03  *** lnostdal has quit IRC
10622020-07-09T21:45:45  *** Evel-Knievel has quit IRC
10632020-07-09T21:46:10  *** Evel-Knievel has joined #bitcoin-core-dev
10642020-07-09T21:48:51  *** nik-j has quit IRC
10652020-07-09T21:54:22  *** promag has quit IRC
10662020-07-09T21:55:08  *** nik-j has joined #bitcoin-core-dev
10672020-07-09T21:55:08  *** promag has joined #bitcoin-core-dev
10682020-07-09T21:55:36  *** lnostdal has joined #bitcoin-core-dev
10692020-07-09T22:06:56  *** nik-j has quit IRC
10702020-07-09T22:07:24  *** nik-j has joined #bitcoin-core-dev
10712020-07-09T22:07:33  <cfields> promag: yeah, it doesn't know how to find .tbd frameworks yet, so no qt.
10722020-07-09T22:07:47  <cfields> I'll check to see if that _should_ be working yet and report it upstream if so.
10732020-07-09T22:13:05  *** andrewtoth has joined #bitcoin-core-dev
10742020-07-09T22:23:33  *** achow101 has quit IRC
10752020-07-09T22:25:58  *** achow101 has joined #bitcoin-core-dev
10762020-07-09T22:32:02  *** IGHOR has quit IRC
10772020-07-09T22:32:55  *** marcoagner has quit IRC
10782020-07-09T22:33:18  *** IGHOR has joined #bitcoin-core-dev
10792020-07-09T22:34:18  *** promag has quit IRC
10802020-07-09T22:34:37  *** mdunnio has quit IRC
10812020-07-09T22:35:05  *** promag has joined #bitcoin-core-dev
10822020-07-09T22:43:13  *** justanotheruser has quit IRC
10832020-07-09T22:48:01  <phantomcircuit> wumpus, you can just go to the zmq docs and see that it's not reliable, it's all about "implementing patterns" to achieve some kind of reliability
10842020-07-09T22:48:25  <phantomcircuit> i've used it before but only with the knowledge that it's basically udp
10852020-07-09T22:50:58  *** andrewtoth has quit IRC
10862020-07-09T23:00:22  *** justanotheruser has joined #bitcoin-core-dev
10872020-07-09T23:01:36  *** dr-orlovsky has quit IRC
10882020-07-09T23:08:28  *** mdunnio has joined #bitcoin-core-dev
10892020-07-09T23:13:16  *** mdunnio has quit IRC
10902020-07-09T23:22:43  *** sipa has quit IRC
10912020-07-09T23:24:55  *** justanotheruser has quit IRC
10922020-07-09T23:26:47  *** Relis has quit IRC
10932020-07-09T23:33:42  *** Relis has joined #bitcoin-core-dev
10942020-07-09T23:39:21  *** sipa has joined #bitcoin-core-dev
10952020-07-09T23:41:24  *** justanotheruser has joined #bitcoin-core-dev
10962020-07-09T23:44:06  *** arowser has quit IRC
10972020-07-09T23:44:34  *** arowser has joined #bitcoin-core-dev
10982020-07-09T23:47:13  *** promag has quit IRC
10992020-07-09T23:47:46  *** promag has joined #bitcoin-core-dev
11002020-07-09T23:51:08  *** jarthur has quit IRC
11012020-07-09T23:57:35  *** promag has quit IRC