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