1 2020-07-09T00:00:01  *** kir has quit IRC
   2 2020-07-09T00:05:43  *** AaronvanW has quit IRC
   3 2020-07-09T00:07:54  *** afk11` has quit IRC
   4 2020-07-09T00:08:19  *** afk11` has joined #bitcoin-core-dev
   5 2020-07-09T00:13:06  *** troygiorshev has quit IRC
   6 2020-07-09T00:14:48  *** troygiorshev has joined #bitcoin-core-dev
   7 2020-07-09T00:17:58  *** diogorsergio has quit IRC
   8 2020-07-09T00:18:07  *** bitdex has joined #bitcoin-core-dev
   9 2020-07-09T00:32:24  *** mdunnio has joined #bitcoin-core-dev
  10 2020-07-09T00:37:25  *** mdunnio has quit IRC
  11 2020-07-09T00:51:09  *** hegemoOn1 has joined #bitcoin-core-dev
  12 2020-07-09T00:53:20  *** Relis has quit IRC
  13 2020-07-09T01:00:46  *** mdunnio has joined #bitcoin-core-dev
  14 2020-07-09T01:04:46  *** diogorsergio has joined #bitcoin-core-dev
  15 2020-07-09T01:10:09  *** promag has quit IRC
  16 2020-07-09T01:19:19  *** Relis has joined #bitcoin-core-dev
  17 2020-07-09T01:21:26  *** Relis has quit IRC
  18 2020-07-09T01:23:05  *** Relis has joined #bitcoin-core-dev
  19 2020-07-09T02:01:25  *** mdunnio has quit IRC
  20 2020-07-09T02:02:03  *** Relis has quit IRC
  21 2020-07-09T02:02:33  *** Relis has joined #bitcoin-core-dev
  22 2020-07-09T02:09:11  *** arowser has quit IRC
  23 2020-07-09T02:09:30  *** arowser has joined #bitcoin-core-dev
  24 2020-07-09T02:19:36  *** Highway61 has quit IRC
  25 2020-07-09T02:22:05  *** shesek has quit IRC
  26 2020-07-09T02:22:32  *** shesek has joined #bitcoin-core-dev
  27 2020-07-09T02:40:19  *** Relis has quit IRC
  28 2020-07-09T03:00:02  *** hegemoOn1 has quit IRC
  29 2020-07-09T03:04:08  *** arowser has quit IRC
  30 2020-07-09T03:05:29  *** arowser has joined #bitcoin-core-dev
  31 2020-07-09T03:16:57  *** Linu741 has joined #bitcoin-core-dev
  32 2020-07-09T03:22:43  *** dr-orlovsky has quit IRC
  33 2020-07-09T03:23:19  *** dr_orlovsky has joined #bitcoin-core-dev
  34 2020-07-09T03:30:52  *** vasild_ has joined #bitcoin-core-dev
  35 2020-07-09T03:33:43  *** vasild has quit IRC
  36 2020-07-09T03:33:44  *** vasild_ is now known as vasild
  37 2020-07-09T03:43:46  *** jarthur_ has joined #bitcoin-core-dev
  38 2020-07-09T03:46:58  *** jarthur has quit IRC
  39 2020-07-09T04:55:18  *** ppisati has quit IRC
  40 2020-07-09T05:02:02  *** ppisati has joined #bitcoin-core-dev
  41 2020-07-09T05:06:08  *** gleb has joined #bitcoin-core-dev
  42 2020-07-09T05:11:26  *** promag has joined #bitcoin-core-dev
  43 2020-07-09T05:15:34  *** promag has quit IRC
  44 2020-07-09T05:25:16  *** jonatack has quit IRC
  45 2020-07-09T05:35:12  *** jonatack has joined #bitcoin-core-dev
  46 2020-07-09T05:38:26  *** arowser has quit IRC
  47 2020-07-09T05:39:33  *** arowser has joined #bitcoin-core-dev
  48 2020-07-09T05:54:23  *** bitcoin-git has joined #bitcoin-core-dev
  49 2020-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
  50 2020-07-09T05:54:24  *** bitcoin-git has left #bitcoin-core-dev
  51 2020-07-09T06:00:01  *** Linu741 has quit IRC
  52 2020-07-09T06:07:36  *** arowser has quit IRC
  53 2020-07-09T06:08:36  *** arowser has joined #bitcoin-core-dev
  54 2020-07-09T06:11:26  *** marcoagner has joined #bitcoin-core-dev
  55 2020-07-09T06:20:06  *** kirkland1 has joined #bitcoin-core-dev
  56 2020-07-09T06:21:41  *** vincenzopalazzo has quit IRC
  57 2020-07-09T06:40:11  *** arowser has quit IRC
  58 2020-07-09T06:40:45  *** arowser has joined #bitcoin-core-dev
  59 2020-07-09T06:55:00  *** elichai2 has quit IRC
  60 2020-07-09T06:55:03  *** bitdex has quit IRC
  61 2020-07-09T06:55:40  *** elichai2 has joined #bitcoin-core-dev
  62 2020-07-09T06:55:41  *** jakesyl has quit IRC
  63 2020-07-09T06:56:08  *** arowser has quit IRC
  64 2020-07-09T06:56:13  *** jakesyl has joined #bitcoin-core-dev
  65 2020-07-09T06:58:17  *** arowser has joined #bitcoin-core-dev
  66 2020-07-09T07:01:03  *** Pavlenex has joined #bitcoin-core-dev
  67 2020-07-09T07:11:32  *** davec has quit IRC
  68 2020-07-09T07:15:12  *** zaff has joined #bitcoin-core-dev
  69 2020-07-09T07:18:43  *** davec has joined #bitcoin-core-dev
  70 2020-07-09T07:19:34  *** AaronvanW has joined #bitcoin-core-dev
  71 2020-07-09T07:22:37  *** bitdex has joined #bitcoin-core-dev
  72 2020-07-09T07:23:05  *** davec has quit IRC
  73 2020-07-09T07:29:48  *** davec has joined #bitcoin-core-dev
  74 2020-07-09T07:33:18  *** bitcoin-git has joined #bitcoin-core-dev
  75 2020-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
  76 2020-07-09T07:33:20  *** bitcoin-git has left #bitcoin-core-dev
  77 2020-07-09T07:35:03  *** Guyver2 has joined #bitcoin-core-dev
  78 2020-07-09T07:35:31  *** vasild has quit IRC
  79 2020-07-09T07:35:54  *** gleb has quit IRC
  80 2020-07-09T07:37:24  *** Pavlenex1 has joined #bitcoin-core-dev
  81 2020-07-09T07:39:34  *** Pavlenex has quit IRC
  82 2020-07-09T07:39:34  *** Pavlenex1 is now known as Pavlenex
  83 2020-07-09T07:40:46  *** vasild has joined #bitcoin-core-dev
  84 2020-07-09T08:03:36  *** vfP56jSe has quit IRC
  85 2020-07-09T08:04:49  *** vfP56jSe has joined #bitcoin-core-dev
  86 2020-07-09T08:09:09  *** arowser has quit IRC
  87 2020-07-09T08:09:34  *** arowser has joined #bitcoin-core-dev
  88 2020-07-09T08:19:13  <fanquake> jonatack: are you using the (I assume self-built) Clang master branch for development/review?
  89 2020-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
  90 2020-07-09T08:23:08  <fanquake> Right. Why not use Clang 9/10 though?
  91 2020-07-09T08:25:28  <jonatack> No strong opinion yet, updated only last weekend. Which do you think is best for development/review?
  92 2020-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)
  93 2020-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.
  94 2020-07-09T08:29:17  <jonatack> Ok. FWIW #19454 fixes .clang-format for clang < 9, e.g. Debian stable
  95 2020-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
  96 2020-07-09T08:29:52  <jonatack> Will go for 10.
  97 2020-07-09T08:41:31  *** Pavlenex has quit IRC
  98 2020-07-09T08:51:46  *** arowser has quit IRC
  99 2020-07-09T08:52:51  *** arowser has joined #bitcoin-core-dev
 100 2020-07-09T08:58:04  *** dr_orlovsky has quit IRC
 101 2020-07-09T08:58:48  *** dr-orlovsky has joined #bitcoin-core-dev
 102 2020-07-09T09:00:02  *** kirkland1 has quit IRC
 103 2020-07-09T09:04:10  *** arowser has quit IRC
 104 2020-07-09T09:04:29  *** arowser has joined #bitcoin-core-dev
 105 2020-07-09T09:18:08  *** someone235 has joined #bitcoin-core-dev
 106 2020-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)?
 107 2020-07-09T09:19:44  <sipa> no
 108 2020-07-09T09:21:49  *** bitprophet1 has joined #bitcoin-core-dev
 109 2020-07-09T09:30:39  *** Highway61 has joined #bitcoin-core-dev
 110 2020-07-09T09:34:10  <someone235> Thanks!
 111 2020-07-09T09:34:19  <someone235> What's the reasoning behind it?
 112 2020-07-09T09:35:39  <someone235> I would expect it to be kept so you reconnect each time your ban score is 90
 113 2020-07-09T09:36:39  <sipa> ban score logic doesn't prevent attacks
 114 2020-07-09T09:36:50  <sipa> it prevents wasting connection slots on broken software
 115 2020-07-09T09:36:51  <someone235> Sorry, I mean, so you *wont* reconnect each time your ban score is 90
 116 2020-07-09T09:37:19  <sipa> and i think ban scores as a concept should just go away
 117 2020-07-09T09:37:41  <someone235> Why?
 118 2020-07-09T09:38:17  <jonatack> someone235: good explanation why here: https://github.com/bitcoin/bitcoin/pull/19219#issuecomment-652684340
 119 2020-07-09T09:38:20  <sipa> if a client miabehaves they should be disconnected and/or banned immediately
 120 2020-07-09T09:38:53  <sipa> if they don't, we ahouldn't confuse things by maybe later doing that when some threshold is reached
 121 2020-07-09T09:38:59  <sipa> it just obscores things for no benefit
 122 2020-07-09T09:39:25  <someone235> Yeah, if we're talking about not talking with broken nodes I tend to agree
 123 2020-07-09T09:39:53  <sipa> yeah see jonatack's link
 124 2020-07-09T09:42:31  <someone235> But how will you deal with attackers? Like people who sends you full invalid blocks?
 125 2020-07-09T09:42:39  <someone235> *send
 126 2020-07-09T09:43:41  <sipa> ban them
 127 2020-07-09T09:43:44  <sipa> immediately
 128 2020-07-09T09:43:48  <someone235> oh right
 129 2020-07-09T09:43:54  <sipa> but also
 130 2020-07-09T09:43:58  <someone235> and bans are kept between reconnects
 131 2020-07-09T09:44:05  <someone235> and restarts
 132 2020-07-09T09:44:25  <sipa> there are plenty of ways to trivially DoS attack nodes by doing completely legitimate things
 133 2020-07-09T09:44:31  <sipa> that we can't ban for
 134 2020-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
 135 2020-07-09T09:46:06  <sipa> and if we run out, deprioritize or disconnect the worst offenders (without banning)
 136 2020-07-09T09:49:10  *** promag has joined #bitcoin-core-dev
 137 2020-07-09T09:52:24  *** zaff has quit IRC
 138 2020-07-09T09:52:45  *** zaff has joined #bitcoin-core-dev
 139 2020-07-09T10:03:22  *** Parker32Connelly has joined #bitcoin-core-dev
 140 2020-07-09T10:10:39  *** Parker32Connelly has quit IRC
 141 2020-07-09T10:22:50  *** promag has quit IRC
 142 2020-07-09T10:23:53  *** promag has joined #bitcoin-core-dev
 143 2020-07-09T10:25:12  *** arowser has quit IRC
 144 2020-07-09T10:25:40  *** arowser has joined #bitcoin-core-dev
 145 2020-07-09T10:28:44  *** Highway61 has quit IRC
 146 2020-07-09T10:28:56  *** Highway61 has joined #bitcoin-core-dev
 147 2020-07-09T10:32:14  *** harrigan has quit IRC
 148 2020-07-09T10:33:12  *** harrigan has joined #bitcoin-core-dev
 149 2020-07-09T10:40:31  *** bitcoin-git has joined #bitcoin-core-dev
 150 2020-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
 151 2020-07-09T10:40:32  *** bitcoin-git has left #bitcoin-core-dev
 152 2020-07-09T10:52:56  *** reallll has joined #bitcoin-core-dev
 153 2020-07-09T10:55:56  *** bitcoin-git has joined #bitcoin-core-dev
 154 2020-07-09T10:55:57  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f7c19e829eca...c4a44186d816
 155 2020-07-09T10:55:58  <bitcoin-git> bitcoin/master e846a2a John Newbery: refactor: clean up PeriodicFlush()
 156 2020-07-09T10:55:58  <bitcoin-git> bitcoin/master c4a4418 MarcoFalke: Merge #19085: Refactor: clean up PeriodicFlush()
 157 2020-07-09T10:56:08  *** bitcoin-git has left #bitcoin-core-dev
 158 2020-07-09T10:56:22  *** belcher_ has quit IRC
 159 2020-07-09T10:56:36  *** bitcoin-git has joined #bitcoin-core-dev
 160 2020-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
 161 2020-07-09T10:56:37  *** bitcoin-git has left #bitcoin-core-dev
 162 2020-07-09T11:03:08  *** arowser has quit IRC
 163 2020-07-09T11:03:32  *** arowser has joined #bitcoin-core-dev
 164 2020-07-09T11:18:43  *** sdaftuar_ has quit IRC
 165 2020-07-09T11:19:17  *** sdaftuar_ has joined #bitcoin-core-dev
 166 2020-07-09T11:19:48  *** reallll is now known as belcher
 167 2020-07-09T11:20:58  *** Relis has joined #bitcoin-core-dev
 168 2020-07-09T11:43:10  *** arowser has quit IRC
 169 2020-07-09T11:43:38  *** arowser has joined #bitcoin-core-dev
 170 2020-07-09T11:47:59  *** promag has quit IRC
 171 2020-07-09T11:48:35  *** promag has joined #bitcoin-core-dev
 172 2020-07-09T11:56:10  *** arowser has quit IRC
 173 2020-07-09T11:56:59  *** arowser has joined #bitcoin-core-dev
 174 2020-07-09T11:59:43  *** bitcoin-git has joined #bitcoin-core-dev
 175 2020-07-09T11:59:43  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c4a44186d816...6b48c30541e4
 176 2020-07-09T11:59:44  <bitcoin-git> bitcoin/master b9253c7 Jon Atack: tools: clang-format 6 compatibility
 177 2020-07-09T11:59:44  <bitcoin-git> bitcoin/master 6b48c30 fanquake: Merge #19454: tools: `.clang-format` compat with clang versions < 9
 178 2020-07-09T11:59:46  *** bitcoin-git has left #bitcoin-core-dev
 179 2020-07-09T12:00:01  *** bitprophet1 has quit IRC
 180 2020-07-09T12:00:03  *** bitcoin-git has joined #bitcoin-core-dev
 181 2020-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
 182 2020-07-09T12:00:04  *** bitcoin-git has left #bitcoin-core-dev
 183 2020-07-09T12:08:14  *** troygiorshev has quit IRC
 184 2020-07-09T12:09:14  *** troygiorshev has joined #bitcoin-core-dev
 185 2020-07-09T12:22:03  *** sora_h has joined #bitcoin-core-dev
 186 2020-07-09T12:30:23  *** bitcoin-git has joined #bitcoin-core-dev
 187 2020-07-09T12:30:24  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/6b48c30541e4...e3b31255c5ad
 188 2020-07-09T12:30:24  <bitcoin-git> bitcoin/master 0b8ba84 fanquake: banlist: log post-swept banlist size at startup
 189 2020-07-09T12:30:25  <bitcoin-git> bitcoin/master e3b3125 fanquake: Merge #19470: banlist: log post-swept banlist size at startup
 190 2020-07-09T12:30:34  *** bitcoin-git has left #bitcoin-core-dev
 191 2020-07-09T12:30:53  *** bitcoin-git has joined #bitcoin-core-dev
 192 2020-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
 193 2020-07-09T12:30:54  *** bitcoin-git has left #bitcoin-core-dev
 194 2020-07-09T12:31:12  *** bitcoin-git has joined #bitcoin-core-dev
 195 2020-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
 196 2020-07-09T12:31:24  *** bitcoin-git has left #bitcoin-core-dev
 197 2020-07-09T12:36:11  *** bitdex has quit IRC
 198 2020-07-09T12:39:07  *** bitcoin-git has joined #bitcoin-core-dev
 199 2020-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
 200 2020-07-09T12:39:08  *** bitcoin-git has left #bitcoin-core-dev
 201 2020-07-09T12:44:28  *** zaff has quit IRC
 202 2020-07-09T12:51:37  *** bitcoin-git has joined #bitcoin-core-dev
 203 2020-07-09T12:51:38  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e3b31255c5ad...64bf5d64dfbf
 204 2020-07-09T12:51:38  <bitcoin-git> bitcoin/master 1e9bfd4 Hennadii Stepanov: qt: Reset toolbar after all wallets are closed
 205 2020-07-09T12:51:39  <bitcoin-git> bitcoin/master 64bf5d6 fanquake: Merge #18896: qt: Reset toolbar after all wallets are closed
 206 2020-07-09T12:51:41  *** bitcoin-git has left #bitcoin-core-dev
 207 2020-07-09T12:52:29  *** bitcoin-git has joined #bitcoin-core-dev
 208 2020-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
 209 2020-07-09T12:52:30  *** bitcoin-git has left #bitcoin-core-dev
 210 2020-07-09T12:53:00  *** Evel-Knievel has quit IRC
 211 2020-07-09T12:53:45  *** Evel-Knievel has joined #bitcoin-core-dev
 212 2020-07-09T12:56:04  *** Pavlenex has joined #bitcoin-core-dev
 213 2020-07-09T13:02:02  *** bitcoin-git has joined #bitcoin-core-dev
 214 2020-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
 215 2020-07-09T13:02:03  *** bitcoin-git has left #bitcoin-core-dev
 216 2020-07-09T13:05:09  *** arowser has quit IRC
 217 2020-07-09T13:05:33  *** arowser has joined #bitcoin-core-dev
 218 2020-07-09T13:07:10  *** arowser has quit IRC
 219 2020-07-09T13:07:36  *** arowser has joined #bitcoin-core-dev
 220 2020-07-09T13:08:11  *** arowser has quit IRC
 221 2020-07-09T13:08:13  *** Jackielove4u has joined #bitcoin-core-dev
 222 2020-07-09T13:08:20  *** bitcoin-git has joined #bitcoin-core-dev
 223 2020-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
 224 2020-07-09T13:08:21  *** bitcoin-git has left #bitcoin-core-dev
 225 2020-07-09T13:08:42  *** arowser has joined #bitcoin-core-dev
 226 2020-07-09T13:09:10  *** arowser has quit IRC
 227 2020-07-09T13:09:42  *** arowser has joined #bitcoin-core-dev
 228 2020-07-09T13:10:12  *** arowser has quit IRC
 229 2020-07-09T13:10:41  *** arowser has joined #bitcoin-core-dev
 230 2020-07-09T13:11:09  *** arowser has quit IRC
 231 2020-07-09T13:11:37  *** arowser has joined #bitcoin-core-dev
 232 2020-07-09T13:11:39  *** bitcoin-git has joined #bitcoin-core-dev
 233 2020-07-09T13:11:39  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/64bf5d64dfbf...21028ce9ffb8
 234 2020-07-09T13:11:40  <bitcoin-git> bitcoin/master 4b5ac25 Hennadii Stepanov: Drop unused CDBWrapper methods
 235 2020-07-09T13:11:40  <bitcoin-git> bitcoin/master 21028ce Wladimir J. van der Laan: Merge #19468: refactor: Drop unused CDBWrapper methods
 236 2020-07-09T13:11:41  *** bitcoin-git has left #bitcoin-core-dev
 237 2020-07-09T13:11:59  *** bitcoin-git has joined #bitcoin-core-dev
 238 2020-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
 239 2020-07-09T13:12:00  *** bitcoin-git has left #bitcoin-core-dev
 240 2020-07-09T13:12:08  *** arowser has quit IRC
 241 2020-07-09T13:12:36  *** arowser has joined #bitcoin-core-dev
 242 2020-07-09T13:13:09  *** arowser has quit IRC
 243 2020-07-09T13:13:37  *** arowser has joined #bitcoin-core-dev
 244 2020-07-09T13:14:08  *** arowser has quit IRC
 245 2020-07-09T13:14:39  *** arowser has joined #bitcoin-core-dev
 246 2020-07-09T13:15:09  *** bitcoin-git has joined #bitcoin-core-dev
 247 2020-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
 248 2020-07-09T13:15:10  *** bitcoin-git has left #bitcoin-core-dev
 249 2020-07-09T13:16:02  *** mdunnio has joined #bitcoin-core-dev
 250 2020-07-09T13:17:10  *** arowser has quit IRC
 251 2020-07-09T13:17:30  *** arowser has joined #bitcoin-core-dev
 252 2020-07-09T13:22:35  *** bitcoin-git has joined #bitcoin-core-dev
 253 2020-07-09T13:22:36  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/21028ce9ffb8...fc8da23fbe58
 254 2020-07-09T13:22:37  <bitcoin-git> bitcoin/master 2894e94 Aaron Clauson: Updates msvc build to use ISO standard C++17.
 255 2020-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
 256 2020-07-09T13:22:39  *** bitcoin-git has left #bitcoin-core-dev
 257 2020-07-09T13:22:57  *** bitcoin-git has joined #bitcoin-core-dev
 258 2020-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
 259 2020-07-09T13:22:58  *** bitcoin-git has left #bitcoin-core-dev
 260 2020-07-09T13:25:01  *** bitcoin-git has joined #bitcoin-core-dev
 261 2020-07-09T13:25:02  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fc8da23fbe58...45f58dbc9b45
 262 2020-07-09T13:25:02  <bitcoin-git> bitcoin/master 2b78a11 nsa: doc: afl fuzzing comment about afl-gcc and afl-g++
 263 2020-07-09T13:25:03  <bitcoin-git> bitcoin/master 45f58db fanquake: Merge #19452: doc: afl fuzzing comment about afl-gcc and afl-g++
 264 2020-07-09T13:25:05  *** bitcoin-git has left #bitcoin-core-dev
 265 2020-07-09T13:25:21  *** bitcoin-git has joined #bitcoin-core-dev
 266 2020-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
 267 2020-07-09T13:25:22  *** bitcoin-git has left #bitcoin-core-dev
 268 2020-07-09T13:31:21  *** bitcoin-git has joined #bitcoin-core-dev
 269 2020-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
 270 2020-07-09T13:31:22  *** bitcoin-git has left #bitcoin-core-dev
 271 2020-07-09T13:39:01  *** promag has quit IRC
 272 2020-07-09T13:39:18  *** promag has joined #bitcoin-core-dev
 273 2020-07-09T13:41:50  *** promag has quit IRC
 274 2020-07-09T13:42:40  *** promag has joined #bitcoin-core-dev
 275 2020-07-09T13:46:38  *** dr-orlovsky has quit IRC
 276 2020-07-09T13:50:43  *** Pavlenex has quit IRC
 277 2020-07-09T13:52:09  *** arowser has quit IRC
 278 2020-07-09T13:52:28  *** arowser has joined #bitcoin-core-dev
 279 2020-07-09T13:53:09  *** arowser has quit IRC
 280 2020-07-09T13:53:28  *** arowser has joined #bitcoin-core-dev
 281 2020-07-09T13:55:49  *** dr-orlovsky has joined #bitcoin-core-dev
 282 2020-07-09T13:56:02  *** mdunnio has quit IRC
 283 2020-07-09T13:56:17  *** mdunnio has joined #bitcoin-core-dev
 284 2020-07-09T14:04:10  *** bitcoin-git has joined #bitcoin-core-dev
 285 2020-07-09T14:04:10  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/45f58dbc9b45...9a3c7afe290f
 286 2020-07-09T14:04:10  <bitcoin-git> bitcoin/master c858302 jmorgan: Change format of log2_work for uniform output (zero-padded)
 287 2020-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 ...
 288 2020-07-09T14:04:12  *** bitcoin-git has left #bitcoin-core-dev
 289 2020-07-09T14:05:05  *** roconnor has joined #bitcoin-core-dev
 290 2020-07-09T14:13:39  <willcl_ark> Is it possible to build the fuzzing harness (only) with gcc rather than clang?
 291 2020-07-09T14:17:45  <MarcoFalke> willcl_ark: Yes, e.g. with afl-gcc
 292 2020-07-09T14:17:54  <MarcoFalke> see doc/fuzzing.md
 293 2020-07-09T14:19:04  <MarcoFalke> #19452
 294 2020-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
 295 2020-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.
 296 2020-07-09T14:19:44  <gribble> https://github.com/bitcoin/bitcoin/issues/19388 | Build fuzz tests by default · Issue #19388 · bitcoin/bitcoin · GitHub
 297 2020-07-09T14:20:18  <MarcoFalke> Oh, if you don't need instrumentation, you should be able to use any cpp compiler
 298 2020-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
 299 2020-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 :)
 300 2020-07-09T14:21:55  <willcl_ark> My issues are mainly with the linking
 301 2020-07-09T14:22:51  <MarcoFalke> Yes, there might be issues linking the main function
 302 2020-07-09T14:23:14  <willcl_ark> Yeah that's the general complaint
 303 2020-07-09T14:25:18  <MarcoFalke> I'd have to look at the code or failure to say more, but generally it should be possible
 304 2020-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
 305 2020-07-09T14:27:23  *** promag has quit IRC
 306 2020-07-09T14:27:25  *** promag_ has joined #bitcoin-core-dev
 307 2020-07-09T14:28:59  *** bitcoin-git has joined #bitcoin-core-dev
 308 2020-07-09T14:29:00  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9a3c7afe290f...22ccc27046a8
 309 2020-07-09T14:29:00  <bitcoin-git> bitcoin/master fc6a637 10xcryptodev: qt: increase console command max length
 310 2020-07-09T14:29:01  <bitcoin-git> bitcoin/master 22ccc27 fanquake: Merge #18993: qt: increase console command max length
 311 2020-07-09T14:29:02  *** bitcoin-git has left #bitcoin-core-dev
 312 2020-07-09T14:29:18  *** murrayn has quit IRC
 313 2020-07-09T14:29:37  *** murray_ has joined #bitcoin-core-dev
 314 2020-07-09T14:29:40  *** bitcoin-git has joined #bitcoin-core-dev
 315 2020-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
 316 2020-07-09T14:29:41  *** bitcoin-git has left #bitcoin-core-dev
 317 2020-07-09T14:30:11  *** victorSN7 has joined #bitcoin-core-dev
 318 2020-07-09T14:30:29  *** victorSN has quit IRC
 319 2020-07-09T14:30:29  *** victorSN7 is now known as victorSN
 320 2020-07-09T14:32:43  <fanquake> I've swapped out my current high-prio PR for #19224.
 321 2020-07-09T14:32:45  <gribble> https://github.com/bitcoin/bitcoin/issues/19224 | [0.20] Backports by fanquake · Pull Request #19224 · bitcoin/bitcoin · GitHub
 322 2020-07-09T14:32:52  <fanquake> Review-beg if you have a PR that is being back-ported there.
 323 2020-07-09T14:44:30  *** owowo has joined #bitcoin-core-dev
 324 2020-07-09T14:44:30  *** owowo has joined #bitcoin-core-dev
 325 2020-07-09T14:48:25  *** nik-j has joined #bitcoin-core-dev
 326 2020-07-09T14:51:06  *** bitcoin-git has joined #bitcoin-core-dev
 327 2020-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
 328 2020-07-09T14:51:08  *** bitcoin-git has left #bitcoin-core-dev
 329 2020-07-09T14:56:31  *** bitcoin-git has joined #bitcoin-core-dev
 330 2020-07-09T14:56:33  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/22ccc27046a8...0d69fdb9a0e3
 331 2020-07-09T14:56:33  <bitcoin-git> bitcoin/master 1cabbdd Aaron Hook: refactor: Use uint16_t instead of unsigned short
 332 2020-07-09T14:56:33  <bitcoin-git> bitcoin/master 0d69fdb Wladimir J. van der Laan: Merge #19314: refactor: Use uint16_t instead of unsigned short
 333 2020-07-09T14:56:35  *** bitcoin-git has left #bitcoin-core-dev
 334 2020-07-09T14:56:51  *** bitcoin-git has joined #bitcoin-core-dev
 335 2020-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
 336 2020-07-09T14:56:53  *** bitcoin-git has left #bitcoin-core-dev
 337 2020-07-09T14:57:33  *** nik-j has quit IRC
 338 2020-07-09T14:58:55  *** nik-j has joined #bitcoin-core-dev
 339 2020-07-09T15:00:02  *** sora_h has quit IRC
 340 2020-07-09T15:03:54  <instagibbs> suggested topic: unified zmq stream + mempool sequence number https://github.com/bitcoin/bitcoin/pull/19462#issuecomment-656140421
 341 2020-07-09T15:05:24  *** bitcoin-git has joined #bitcoin-core-dev
 342 2020-07-09T15:05:24  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/0d69fdb9a0e3...cc9d09e73de0
 343 2020-07-09T15:05:25  <bitcoin-git> bitcoin/master fa0540c MarcoFalke: net: Extract download permission from noban
 344 2020-07-09T15:05:25  <bitcoin-git> bitcoin/master cc9d09e MarcoFalke: Merge #19191: net: Extract download permission from noban
 345 2020-07-09T15:05:27  *** bitcoin-git has left #bitcoin-core-dev
 346 2020-07-09T15:05:49  *** bitcoin-git has joined #bitcoin-core-dev
 347 2020-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
 348 2020-07-09T15:05:50  *** bitcoin-git has left #bitcoin-core-dev
 349 2020-07-09T15:11:01  *** yudan has joined #bitcoin-core-dev
 350 2020-07-09T15:12:56  *** bitcoin-git has joined #bitcoin-core-dev
 351 2020-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
 352 2020-07-09T15:12:58  *** bitcoin-git has left #bitcoin-core-dev
 353 2020-07-09T15:16:19  *** rawtaz1 has joined #bitcoin-core-dev
 354 2020-07-09T15:17:49  *** tryphe has quit IRC
 355 2020-07-09T15:17:55  *** bitcoin-git has joined #bitcoin-core-dev
 356 2020-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
 357 2020-07-09T15:18:06  *** bitcoin-git has left #bitcoin-core-dev
 358 2020-07-09T15:18:17  *** tryphe has joined #bitcoin-core-dev
 359 2020-07-09T15:30:51  *** vasild_ has joined #bitcoin-core-dev
 360 2020-07-09T15:34:43  *** vasild has quit IRC
 361 2020-07-09T15:34:44  *** vasild_ is now known as vasild
 362 2020-07-09T15:35:06  *** shuckc has joined #bitcoin-core-dev
 363 2020-07-09T15:35:32  *** proofofkeags has joined #bitcoin-core-dev
 364 2020-07-09T15:40:22  *** zaff has joined #bitcoin-core-dev
 365 2020-07-09T15:43:59  *** Livestradamus has quit IRC
 366 2020-07-09T15:44:18  *** Livestradamus has joined #bitcoin-core-dev
 367 2020-07-09T15:47:01  *** jarthur_ is now known as jarthur
 368 2020-07-09T15:47:19  *** Pavlenex has joined #bitcoin-core-dev
 369 2020-07-09T15:47:38  *** yudan has quit IRC
 370 2020-07-09T15:48:28  *** dr-orlovsky has quit IRC
 371 2020-07-09T15:48:30  *** dr_orlovsky has joined #bitcoin-core-dev
 372 2020-07-09T15:49:00  *** zaff has quit IRC
 373 2020-07-09T15:50:57  *** bitcoin-git has joined #bitcoin-core-dev
 374 2020-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
 375 2020-07-09T15:50:58  *** bitcoin-git has left #bitcoin-core-dev
 376 2020-07-09T15:53:21  *** bitcoin-git has joined #bitcoin-core-dev
 377 2020-07-09T15:53:22  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/cc9d09e73de0...fd9db45c3ea1
 378 2020-07-09T15:53:22  <bitcoin-git> bitcoin/master a4a3fc4 Sjors Provoost: doc: improve subtree check instructions
 379 2020-07-09T15:53:23  <bitcoin-git> bitcoin/master fd9db45 Wladimir J. van der Laan: Merge #19258: doc: improve subtree check instructions
 380 2020-07-09T15:53:24  *** bitcoin-git has left #bitcoin-core-dev
 381 2020-07-09T15:53:42  *** bitcoin-git has joined #bitcoin-core-dev
 382 2020-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
 383 2020-07-09T15:53:43  *** bitcoin-git has left #bitcoin-core-dev
 384 2020-07-09T15:58:08  *** arowser has quit IRC
 385 2020-07-09T15:58:36  *** arowser has joined #bitcoin-core-dev
 386 2020-07-09T16:05:56  *** Talkless has joined #bitcoin-core-dev
 387 2020-07-09T16:08:01  *** arowser has quit IRC
 388 2020-07-09T16:12:01  *** bitcoin-git has joined #bitcoin-core-dev
 389 2020-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
 390 2020-07-09T16:12:08  *** bitcoin-git has left #bitcoin-core-dev
 391 2020-07-09T16:14:31  *** arowser has joined #bitcoin-core-dev
 392 2020-07-09T16:14:47  *** promag_ has quit IRC
 393 2020-07-09T16:15:43  *** promag has joined #bitcoin-core-dev
 394 2020-07-09T16:17:49  <luke-jr> https://twitter.com/RainDogDance/status/1281260787475021826
 395 2020-07-09T16:17:54  <luke-jr> apparently there's a market for TNBTC
 396 2020-07-09T16:18:26  <luke-jr> kindof.
 397 2020-07-09T16:36:49  *** Pavlenex has quit IRC
 398 2020-07-09T16:37:12  <instagibbs> it's hard to get your hands on large amounts unless you "know people"
 399 2020-07-09T16:40:10  *** troygiorshev has quit IRC
 400 2020-07-09T16:40:25  *** troygiorshev has joined #bitcoin-core-dev
 401 2020-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
 402 2020-07-09T16:47:16  *** justan0theruser has quit IRC
 403 2020-07-09T16:47:36  *** corollari_ has joined #bitcoin-core-dev
 404 2020-07-09T16:48:04  *** hebasto_ has joined #bitcoin-core-dev
 405 2020-07-09T16:48:10  *** mmitech__ has joined #bitcoin-core-dev
 406 2020-07-09T16:48:13  *** ryanofsky_ has joined #bitcoin-core-dev
 407 2020-07-09T16:50:04  <instagibbs> someone is warp mining this morning AFAICT
 408 2020-07-09T16:50:53  *** commavir_ has joined #bitcoin-core-dev
 409 2020-07-09T16:50:56  *** promag has quit IRC
 410 2020-07-09T16:51:03  *** filchef has joined #bitcoin-core-dev
 411 2020-07-09T16:51:11  *** promag has joined #bitcoin-core-dev
 412 2020-07-09T16:51:59  *** filchef has quit IRC
 413 2020-07-09T16:52:16  *** Talkless has quit IRC
 414 2020-07-09T16:52:32  *** Talkless has joined #bitcoin-core-dev
 415 2020-07-09T16:55:15  *** meshcoll- has joined #bitcoin-core-dev
 416 2020-07-09T16:55:26  *** corollari has quit IRC
 417 2020-07-09T16:55:26  *** hebasto has quit IRC
 418 2020-07-09T16:55:26  *** NicolasDorier has quit IRC
 419 2020-07-09T16:55:26  *** mmitech_ has quit IRC
 420 2020-07-09T16:55:30  *** gribble has quit IRC
 421 2020-07-09T16:55:30  *** da2ce7_ has quit IRC
 422 2020-07-09T16:55:30  *** meshcollider has quit IRC
 423 2020-07-09T16:55:30  *** ryanofsky has quit IRC
 424 2020-07-09T16:55:30  *** commavir has quit IRC
 425 2020-07-09T16:55:31  *** hebasto_ is now known as hebasto
 426 2020-07-09T16:55:33  *** commavir_ is now known as commavir
 427 2020-07-09T16:56:45  *** mrostecki has quit IRC
 428 2020-07-09T16:56:47  *** awesome-doge has quit IRC
 429 2020-07-09T16:56:48  *** icota[m] has quit IRC
 430 2020-07-09T16:56:51  *** SergeySherkunov[ has quit IRC
 431 2020-07-09T16:56:52  *** TheFuzzStone[m] has quit IRC
 432 2020-07-09T16:56:56  *** infamously[m] has quit IRC
 433 2020-07-09T16:58:44  *** NicolasDorier has joined #bitcoin-core-dev
 434 2020-07-09T16:58:44  *** da2ce7_ has joined #bitcoin-core-dev
 435 2020-07-09T17:02:02  *** awesome-doge has joined #bitcoin-core-dev
 436 2020-07-09T17:03:58  *** dr_orlovsky has quit IRC
 437 2020-07-09T17:04:57  *** dr-orlovsky has joined #bitcoin-core-dev
 438 2020-07-09T17:05:07  *** DeanGuss has quit IRC
 439 2020-07-09T17:05:13  *** Dean_Guss has joined #bitcoin-core-dev
 440 2020-07-09T17:07:06  *** kristapsk has joined #bitcoin-core-dev
 441 2020-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.
 442 2020-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
 443 2020-07-09T17:10:40  <cfields> ack
 444 2020-07-09T17:10:46  <jonatack> fanquake suggested this am that i move back to clang stable 9 or 10 for reviewing purposes
 445 2020-07-09T17:10:47  <cfields> jonatack: do you get a ton of warnings? Or just that one?
 446 2020-07-09T17:11:16  <jonatack> just the one. i agree with you that it doesn't make sense.
 447 2020-07-09T17:11:36  <cfields> you actually checked out the commit, right? Didn't c/p from github?
 448 2020-07-09T17:12:28  *** gribble has joined #bitcoin-core-dev
 449 2020-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
 450 2020-07-09T17:12:41  <jonatack> built*
 451 2020-07-09T17:12:55  <cfields> So weird!
 452 2020-07-09T17:13:11  <cfields> We'll see if I can reproduce from a git build.
 453 2020-07-09T17:13:29  <sipa> jonatack: and you only get the warning on the new code introducsd to attrihutes.h?
 454 2020-07-09T17:13:33  <sipa> not anywhere else?
 455 2020-07-09T17:13:37  *** justan0theruser has joined #bitcoin-core-dev
 456 2020-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.
 457 2020-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.
 458 2020-07-09T17:15:02  <jonatack> i was on debian clang 6 which does not have -Wdangling and wanted to test cory's PR
 459 2020-07-09T17:15:27  <jonatack> cfields: yes. LMK
 460 2020-07-09T17:20:20  *** Highway62 has joined #bitcoin-core-dev
 461 2020-07-09T17:21:33  <jonatack> rebuilt just now again, saw it again. but also apt-update has new clang updates. installing and rebuilding.
 462 2020-07-09T17:21:54  *** Highway61 has quit IRC
 463 2020-07-09T17:21:54  *** Highway62 is now known as Highway61
 464 2020-07-09T17:22:40  *** TheFuzzStone[m] has joined #bitcoin-core-dev
 465 2020-07-09T17:22:40  *** mrostecki has joined #bitcoin-core-dev
 466 2020-07-09T17:22:41  *** SergeySherkunov[ has joined #bitcoin-core-dev
 467 2020-07-09T17:22:41  *** icota[m] has joined #bitcoin-core-dev
 468 2020-07-09T17:22:47  *** infamously[m] has joined #bitcoin-core-dev
 469 2020-07-09T17:26:42  *** someone235 has quit IRC
 470 2020-07-09T17:34:53  *** Highway61 has quit IRC
 471 2020-07-09T17:35:35  *** Highway61 has joined #bitcoin-core-dev
 472 2020-07-09T17:35:37  *** Evel-Knievel has quit IRC
 473 2020-07-09T17:36:21  *** Evel-Knievel has joined #bitcoin-core-dev
 474 2020-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.
 475 2020-07-09T17:42:03  *** andrewtoth has quit IRC
 476 2020-07-09T17:42:21  <sipa> chased goose is best goose
 477 2020-07-09T17:42:32  <jonatack> :D
 478 2020-07-09T17:42:50  <cfields> jonatack: heh, well that's rather unsatisfying
 479 2020-07-09T17:47:19  *** nik-j has quit IRC
 480 2020-07-09T17:47:27  *** Evel-Knievel has quit IRC
 481 2020-07-09T17:47:56  *** nik-j has joined #bitcoin-core-dev
 482 2020-07-09T17:55:02  *** nik-j has quit IRC
 483 2020-07-09T18:00:01  *** rawtaz1 has quit IRC
 484 2020-07-09T18:02:31  *** zaff has joined #bitcoin-core-dev
 485 2020-07-09T18:06:31  <cfields> jonatack: igoring all that, thanks for jumping through hoops to test :)
 486 2020-07-09T18:14:44  <jeremyrubin> #proposedmeetingtopic small clarification on the goals of the mempool project (cap at 5 mins meeting time)
 487 2020-07-09T18:18:17  *** jb55 has quit IRC
 488 2020-07-09T18:18:46  *** jb55 has joined #bitcoin-core-dev
 489 2020-07-09T18:18:54  *** vincenzopalazzo has joined #bitcoin-core-dev
 490 2020-07-09T18:20:59  *** Pavlenex has joined #bitcoin-core-dev
 491 2020-07-09T18:21:04  *** Xing`1 has joined #bitcoin-core-dev
 492 2020-07-09T18:26:08  *** bitcoin-git has joined #bitcoin-core-dev
 493 2020-07-09T18:26:08  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fd9db45c3ea1...2aaff4813cc3
 494 2020-07-09T18:26:09  <bitcoin-git> bitcoin/master fa6d5ab MarcoFalke: refactor: Remove unused BlockAssembler::pblock member var
 495 2020-07-09T18:26:09  <bitcoin-git> bitcoin/master 2aaff48 MarcoFalke: Merge #19283: refactor: Remove unused BlockAssembler::pblock member var
 496 2020-07-09T18:26:11  *** bitcoin-git has left #bitcoin-core-dev
 497 2020-07-09T18:26:28  *** bitcoin-git has joined #bitcoin-core-dev
 498 2020-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
 499 2020-07-09T18:26:29  *** bitcoin-git has left #bitcoin-core-dev
 500 2020-07-09T18:31:21  *** nik-j has joined #bitcoin-core-dev
 501 2020-07-09T18:35:34  *** nik-j has quit IRC
 502 2020-07-09T18:42:59  *** Pavlenex has quit IRC
 503 2020-07-09T18:43:39  *** nik-j has joined #bitcoin-core-dev
 504 2020-07-09T18:46:44  *** bitcoin-git has joined #bitcoin-core-dev
 505 2020-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
 506 2020-07-09T18:46:45  *** bitcoin-git has left #bitcoin-core-dev
 507 2020-07-09T18:53:04  *** promag_ has joined #bitcoin-core-dev
 508 2020-07-09T18:54:04  *** promag has quit IRC
 509 2020-07-09T18:54:40  *** promag has joined #bitcoin-core-dev
 510 2020-07-09T18:55:48  <promag_> instagibbs: #19476
 511 2020-07-09T18:55:50  <gribble> https://github.com/bitcoin/bitcoin/issues/19476 | wip, rpc: Add mempoolchanges by promag · Pull Request #19476 · bitcoin/bitcoin · GitHub
 512 2020-07-09T18:55:58  <instagibbs> promag_, yeah saw that
 513 2020-07-09T18:56:08  <instagibbs> can someone give shuckc voice?
 514 2020-07-09T18:56:21  *** promag has quit IRC
 515 2020-07-09T18:56:25  *** promag_ is now known as promag
 516 2020-07-09T18:56:56  <sipa> shuckc voice?
 517 2020-07-09T18:57:10  *** promag_ has joined #bitcoin-core-dev
 518 2020-07-09T18:57:10  <instagibbs> i am not irc wizard, he says he cannot say anything here
 519 2020-07-09T18:57:22  <achow101> pretty sure you need to be registered
 520 2020-07-09T18:57:25  <instagibbs> ah ok
 521 2020-07-09T18:57:28  <aj> yeah
 522 2020-07-09T18:57:32  <aj> register with nickserv
 523 2020-07-09T18:58:01  *** dfmb_ has joined #bitcoin-core-dev
 524 2020-07-09T18:58:18  *** dfmb_ has quit IRC
 525 2020-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
 526 2020-07-09T18:59:32  <instagibbs> he's not registered, mystery solved
 527 2020-07-09T18:59:36  <MarcoFalke> Can someone edit the topic to say that register with nicksers is needed?
 528 2020-07-09T18:59:54  <wumpus> FWIW we've tried to remove that requirement many times and every time immediately some spam appeared
 529 2020-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
 530 2020-07-09T19:00:19  <wumpus> I've been caught by that as well the feedback is pretty bad
 531 2020-07-09T19:00:22  <troygiorshev> we don't have +r though, so why is that happenin?
 532 2020-07-09T19:00:22  <shuckc> better?
 533 2020-07-09T19:00:28  <wumpus> shuckc: yes
 534 2020-07-09T19:00:31  <luke-jr> MarcoFalke: not sure topic change will help that..
 535 2020-07-09T19:00:38  <instagibbs> shuckc, see you
 536 2020-07-09T19:00:40  <luke-jr> MarcoFalke: especially if you don't notice the error that your msg didn't go
 537 2020-07-09T19:00:45  <promag> meeting?
 538 2020-07-09T19:00:49  <achow101> meeting?
 539 2020-07-09T19:00:52  <wumpus> #startmeeting
 540 2020-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.
 541 2020-07-09T19:00:52  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
 542 2020-07-09T19:00:52  <MarcoFalke> ahoi
 543 2020-07-09T19:00:57  <hebasto> hi
 544 2020-07-09T19:00:58  <achow101> hi
 545 2020-07-09T19:00:59  <troygiorshev> hi
 546 2020-07-09T19:01:03  <jnewbery> hi
 547 2020-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
 548 2020-07-09T19:01:09  <wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
 549 2020-07-09T19:01:19  <jb55> hi
 550 2020-07-09T19:01:20  <fjahr> hi
 551 2020-07-09T19:01:22  <amiti> hi
 552 2020-07-09T19:01:26  <luke-jr> ih
 553 2020-07-09T19:01:37  <promag> hi
 554 2020-07-09T19:01:38  <kanzure> hi
 555 2020-07-09T19:01:50  <jonasschnelli> hi
 556 2020-07-09T19:01:57  <jeremyrubin> hola
 557 2020-07-09T19:02:12  <gwillen> hi
 558 2020-07-09T19:02:21  <cfields> hi
 559 2020-07-09T19:02:28  <sipa> hi
 560 2020-07-09T19:02:30  <wumpus> one proposed meeting topic: small clarification on the goals of the mempool project (jeremyrubin)
 561 2020-07-09T19:02:36  <wumpus> any last minute topics?
 562 2020-07-09T19:02:50  <phantomcircuit> hi
 563 2020-07-09T19:02:56  <sipa> another short one: can we drop gcc 4.8?
 564 2020-07-09T19:02:56  *** gzhao408 has joined #bitcoin-core-dev
 565 2020-07-09T19:03:06  <wumpus> ok
 566 2020-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
 567 2020-07-09T19:03:41  <luke-jr> sipa: not sure that's a good meeting topic; it just needs someone to investigate distros?
 568 2020-07-09T19:03:44  <ariard> hi
 569 2020-07-09T19:03:54  <elichai2> hu
 570 2020-07-09T19:04:04  <wumpus> #topic High priority for review
 571 2020-07-09T19:04:16  <MarcoFalke> can i haz #19386
 572 2020-07-09T19:04:17  <achow101> #19325 pls
 573 2020-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
 574 2020-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
 575 2020-07-09T19:04:27  <wumpus> https://github.com/bitcoin/bitcoin/projects/8  13 blockers, 1 bugfix, 3 chasing concept ACK
 576 2020-07-09T19:04:36  <wumpus> please don't add any more before removing any xD
 577 2020-07-09T19:04:38  <jamesob> hi
 578 2020-07-09T19:04:45  <ariard> you can drop #18787, after talking with few people, a libstandardness would be more accurate
 579 2020-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
 580 2020-07-09T19:04:51  *** pinheadmz1 has joined #bitcoin-core-dev
 581 2020-07-09T19:05:01  <ariard> #18797 sorry
 582 2020-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
 583 2020-07-09T19:05:10  <jeremyrubin> removing #18191
 584 2020-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
 585 2020-07-09T19:05:51  *** meshcoll- has quit IRC
 586 2020-07-09T19:06:17  <jonatack> hi
 587 2020-07-09T19:06:22  <promag> please see #19033, its for 0.20.1
 588 2020-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
 589 2020-07-09T19:06:25  *** meshcollider has joined #bitcoin-core-dev
 590 2020-07-09T19:06:25  <wumpus> ariard, achow101  done
 591 2020-07-09T19:07:11  <wumpus> jeremyrubin: ok
 592 2020-07-09T19:07:13  <luke-jr> would be nice to get the build tarballs fixed finally too <.<
 593 2020-07-09T19:07:19  <meshcollider> hi
 594 2020-07-09T19:08:10  <pinheadmz1> hi
 595 2020-07-09T19:09:20  <wumpus> #topic clarification on the goals of the mempool project (jeremyrubin)
 596 2020-07-09T19:09:49  <jeremyrubin> Yeah just quick;
 597 2020-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
 598 2020-07-09T19:10:20  *** ryanofsky_ has left #bitcoin-core-dev
 599 2020-07-09T19:10:24  *** ryanofsky has joined #bitcoin-core-dev
 600 2020-07-09T19:10:35  <jeremyrubin> A lot of the motivation is to reduce the memory usage in the mempool
 601 2020-07-09T19:10:49  <jeremyrubin> and to better bound the algorithmic complexity on functions
 602 2020-07-09T19:11:09  <jeremyrubin> So that one day, maybe, we could lift some restrictions (e.g., descendents)
 603 2020-07-09T19:11:42  <jeremyrubin> It's less so "make mempool faster now" performance motivation.
 604 2020-07-09T19:12:09  <wumpus> ok good to know
 605 2020-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
 606 2020-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
 607 2020-07-09T19:12:56  <luke-jr> if those are the goals, I wonder if it might make sense to move complexity into the miner
 608 2020-07-09T19:13:00  <wumpus> we could have benchmarks that measure memory usage I suppose
 609 2020-07-09T19:13:08  <luke-jr> but that could interfere with compact blocks
 610 2020-07-09T19:13:27  <jeremyrubin> luke-jr: this does make sense for certain things.
 611 2020-07-09T19:13:49  <luke-jr> I wonder if it'd be possible to support a build without mining support that performs better
 612 2020-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
 613 2020-07-09T19:14:23  <jeremyrubin> And you need both whole-system and unit tests for the functions
 614 2020-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
 615 2020-07-09T19:14:34  <jeremyrubin> And both asymptotic and bounded size
 616 2020-07-09T19:14:37  <cfields> wumpus: +1
 617 2020-07-09T19:15:19  <luke-jr> wumpus: by making mining build-time-optional, we could possibly get both cheaply?
 618 2020-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 ?
 619 2020-07-09T19:15:50  <luke-jr> I wonder if there's a way to change class sizes at runtime in C++
 620 2020-07-09T19:16:03  <jeremyrubin> Reducing memory usage is related to DoS primarily
 621 2020-07-09T19:16:06  <wumpus> that's kind of annoying for testing but yes
 622 2020-07-09T19:16:24  <jeremyrubin> So the goal is to eliminate the class  of vuln
 623 2020-07-09T19:16:42  <luke-jr> jeremyrubin: eh? users can always adjust their mempool size
 624 2020-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
 625 2020-07-09T19:16:53  <wumpus> it doesn't help if only the miners would have the vulnerability though
 626 2020-07-09T19:16:55  <sipa> mempool size _predictability_ is a DoS concern
 627 2020-07-09T19:16:55  <jeremyrubin> luke-jr: no for the algorithms themselves
 628 2020-07-09T19:16:57  <luke-jr> reducing mem usage would just mean more txs per MB
 629 2020-07-09T19:17:03  <jeremyrubin> not for the mempool size itself
 630 2020-07-09T19:17:04  *** Talkless has quit IRC
 631 2020-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
 632 2020-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
 633 2020-07-09T19:17:23  <jeremyrubin> Mostly fixing short-lived allocations
 634 2020-07-09T19:17:31  <nehan> jeremyrubin: what is your expected memory usage improvement?
 635 2020-07-09T19:17:50  <luke-jr> sipa: but there's no vuln with zero mempool…
 636 2020-07-09T19:18:32  <jeremyrubin> nehan: it's a project with a bunch of algorithm improvements based on epochs for traversal instead of sets
 637 2020-07-09T19:18:37  <aj> (5min cap exceeded fwiw)
 638 2020-07-09T19:18:51  <jeremyrubin> ah yeah didn't mean to turn this into an ordeal, just trying to clarify
 639 2020-07-09T19:19:05  <luke-jr> not like we have any other topics?
 640 2020-07-09T19:19:10  <sipa> perhaps just document this as a summary on the relevant PRs?
 641 2020-07-09T19:19:16  <jeremyrubin> happy to move on if there's other things to discuss
 642 2020-07-09T19:19:17  <sipa> unless it already is
 643 2020-07-09T19:19:17  <wumpus> luke-jr: we do, sipa had a topic
 644 2020-07-09T19:19:21  <luke-jr> oh
 645 2020-07-09T19:19:30  <sipa> nothing important
 646 2020-07-09T19:19:30  <luke-jr> right
 647 2020-07-09T19:19:48  <wumpus> #topic can we drop gcc 4.8 (sipa)
 648 2020-07-09T19:19:51  <MarcoFalke> why?
 649 2020-07-09T19:19:54  <wumpus> just something to annoy fanquake
 650 2020-07-09T19:19:58  <wumpus> :)
 651 2020-07-09T19:19:59  <luke-jr> lol
 652 2020-07-09T19:19:59  <cfields> lol
 653 2020-07-09T19:20:02  <sipa> so, i was looking at #18086 again
 654 2020-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
 655 2020-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
 656 2020-07-09T19:20:39  <wumpus> I *really* think we should wait with bumping gcc versions until c++17 requirement
 657 2020-07-09T19:20:45  <sipa> but it seems gcc 4.8 ignores it or otherwise fails to implement it correctly
 658 2020-07-09T19:20:46  <wumpus> which isn't too far away, just one major version
 659 2020-07-09T19:20:52  <sipa> yeah
 660 2020-07-09T19:21:17  <luke-jr> sipa: not the end of the world if it's wrong?
 661 2020-07-09T19:21:18  <sipa> but i've just noticed at appveyor also fails at it :s
 662 2020-07-09T19:21:25  <sipa> luke-jr: could cause UB
 663 2020-07-09T19:21:32  <luke-jr> hmm
 664 2020-07-09T19:21:33  <sipa> if used in totally reasonable ways
 665 2020-07-09T19:21:40  <sipa> (but probably not in my actual PR)
 666 2020-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 :)
 667 2020-07-09T19:21:59  <luke-jr> when C++20? :p
 668 2020-07-09T19:22:07  <wumpus> in 2025
 669 2020-07-09T19:22:11  * luke-jr found C++20 to be required for totally obvious/expected features the other day :/
 670 2020-07-09T19:22:14  <sipa> luke-jr: hard to talk about things that don't exist
 671 2020-07-09T19:22:42  <cfields> luke-jr: get sipa to backport for you like Span :p
 672 2020-07-09T19:22:50  <luke-jr> cfields: can't backport syntax
 673 2020-07-09T19:22:59  <MarcoFalke> Only 3.6 months till branch off: https://github.com/bitcoin/bitcoin/issues/18947
 674 2020-07-09T19:23:07  <luke-jr> struct type var = { .a = 1, .b = 2 }
 675 2020-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?
 676 2020-07-09T19:23:30  <wumpus> jnewbery: +1!
 677 2020-07-09T19:23:34  <sipa> jnewbery: ugh
 678 2020-07-09T19:23:34  <aj> luke-jr: omg, don't tease things like that
 679 2020-07-09T19:23:37  <sipa> that's horrendous
 680 2020-07-09T19:23:51  <luke-jr> aj: it's common C99, no clue why C++ forbids it :/
 681 2020-07-09T19:24:09  <cfields> luke-jr: juse use unnamed initializers ?
 682 2020-07-09T19:24:17  <luke-jr> cfields: but the whole point is the names!
 683 2020-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
 684 2020-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
 685 2020-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
 686 2020-07-09T19:25:29  <luke-jr> https://github.com/bitcoin/bitcoin/pull/19463/files#diff-b2bb174788c7409b671c46ccc86034bdR291
 687 2020-07-09T19:25:33  <sipa> so i guess i'd just wait instead
 688 2020-07-09T19:25:35  <wumpus> anyhow according to #16684 the minimum gcc version will go to 8.3
 689 2020-07-09T19:25:38  <gribble> https://github.com/bitcoin/bitcoin/issues/16684 | Discussion: upgrading to C++17 · Issue #16684 · bitcoin/bitcoin · GitHub
 690 2020-07-09T19:25:47  <sipa> or try to minimize the risk of copying
 691 2020-07-09T19:25:59  <cfields> sipa: can you point to exactly what old gcc gets wrong? I'm just curious to see.
 692 2020-07-09T19:26:07  <jnewbery> sipa: ah ok. If it's super invasive to do, then not worth it
 693 2020-07-09T19:26:28  <sipa> cfields: have a container with an accounting allocator, encapsulated in some class
 694 2020-07-09T19:26:36  <sipa> return a copy of it for public consumption
 695 2020-07-09T19:26:37  <wumpus> is changing this really urgent or can it wait until after 0.21?
 696 2020-07-09T19:26:56  <sipa> now any changes to that copy need to lock the origin datastructure's accounting variable
 697 2020-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?
 698 2020-07-09T19:27:11  <sipa> because they're shared
 699 2020-07-09T19:27:22  <MarcoFalke> gcc 7 is enough: https://github.com/bitcoin/bitcoin/pull/19183/files#diff-0c8311709d11060c5156268e58f5f209R14
 700 2020-07-09T19:27:57  <wumpus> MarcoFalke: okay maybe I'm misreading the issue then
 701 2020-07-09T19:27:59  <aj> 8.3 is in debian stable as the default gcc, only gcc 6 in oldstable
 702 2020-07-09T19:28:15  <luke-jr> aj: RHEL tends to be the bottleneck
 703 2020-07-09T19:28:18  <wumpus> in any case there is going to be a large bump
 704 2020-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 ;)
 705 2020-07-09T19:28:39  <aj> luke-jr: it has software collections now so you get new gcc/clang on old rhel pretty easy
 706 2020-07-09T19:28:54  <sipa> RHEL8 has gcc 8.2
 707 2020-07-09T19:28:57  <luke-jr> aj: oh!
 708 2020-07-09T19:29:37  <sipa> RHEL7 uses gcc 4.8 by default
 709 2020-07-09T19:29:53  <luke-jr> do we care about old stables now?
 710 2020-07-09T19:29:53  <sipa> (we've strayed a bit from the topic, but that's ok unless someone has something else)
 711 2020-07-09T19:30:01  <aj> https://www.softwarecollections.org/en/scls/rhscl/devtoolset-8/  -- gcc 8 for rhel 6 and 7
 712 2020-07-09T19:30:08  <instagibbs> mempool delta notifications topic
 713 2020-07-09T19:30:13  <wumpus> can always cross-compile anyway
 714 2020-07-09T19:30:21  <luke-jr> wumpus: that's a bit much for most users
 715 2020-07-09T19:30:34  <wumpus> #topic mempool delta notifications (instagibbs)
 716 2020-07-09T19:30:56  <cfields> sipa: I was under the impression you weren't supposed to inherit from std::allocator in c++11.
 717 2020-07-09T19:31:04  <cfields> ok, will look more after the meeting.
 718 2020-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
 719 2020-07-09T19:31:18  <instagibbs> shuckc, can you speak to motivation/usage?
 720 2020-07-09T19:31:19  <wumpus> luke-jr: maybe, it's not that much more difficult, especially nowadays with the extreme availability of VMs etc
 721 2020-07-09T19:31:32  <sipa> cfields: ah, i can try avoiding that
 722 2020-07-09T19:31:43  <instagibbs> promag also made a WIP mempool delta RPC as another possible option https://github.com/bitcoin/bitcoin/pull/19476
 723 2020-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 :)
 724 2020-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
 725 2020-07-09T19:33:35  <shuckc> seems like an opportunity to cover off a lot of the edge cases in one go
 726 2020-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
 727 2020-07-09T19:33:54  <luke-jr> instagibbs: you linked the same PR twice
 728 2020-07-09T19:33:58  <instagibbs> oh woops
 729 2020-07-09T19:34:09  <instagibbs> https://github.com/bitcoin/bitcoin/pull/19462#issueacomment-656140421
 730 2020-07-09T19:34:11  <luke-jr> instagibbs: ZMQ is very unreliable..
 731 2020-07-09T19:34:38  <wumpus> instagibbs: that makes sense
 732 2020-07-09T19:34:45  <wumpus> no, ZMQ is not very unreliable
 733 2020-07-09T19:34:52  <instagibbs> sure luke-jr so alternative would likely look like promag pr i linked
 734 2020-07-09T19:34:56  <instagibbs> maybe long polling
 735 2020-07-09T19:34:59  <wumpus> only in pretty extreme circumstances it sometimes drops a packet
 736 2020-07-09T19:35:02  <sipa> ZMQ has no reliability _guarantees_
 737 2020-07-09T19:35:17  <wumpus> and in that case there needs to be a way to resynchronize, anyway, as instagibbs  says
 738 2020-07-09T19:35:27  <luke-jr> wumpus: I used it for low traffic on a reliable network, and it still lost stuff regularly
 739 2020-07-09T19:35:28  <sipa> but absent overflow conditiins, it is very reliable
 740 2020-07-09T19:35:32  <wumpus> notifications have sequence numbers to be able to detect that
 741 2020-07-09T19:35:38  <sipa> luke-jr: hmm, ok
 742 2020-07-09T19:35:39  <instagibbs> and avoiding "lots" of getrawmempools I guess is hte biggest goal
 743 2020-07-09T19:35:44  <wumpus> sipa: yes, in the general case it is very reliable
 744 2020-07-09T19:35:47  <promag> the biggest problem if you have to take the client offline for a bit
 745 2020-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
 746 2020-07-09T19:36:11  <wumpus> unless your client is not consuming the notifications reliably: there can't be an infinite buffer
 747 2020-07-09T19:36:24  <wumpus> (unless you'd spool to disk or something like that)
 748 2020-07-09T19:36:47  <promag> shuckc: zmq pub doesn't hold msg if client is offline.
 749 2020-07-09T19:36:51  <wumpus> but I don't think adding yet another notifications system with mail-like reliablity is really what we want
 750 2020-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)
 751 2020-07-09T19:37:39  <wumpus> I mean there's mq systems like rabbitmq that guarantee 100% reliability
 752 2020-07-09T19:37:51  <promag> the approach in #19476 avoids periodic getrawmempools
 753 2020-07-09T19:37:53  <gribble> https://github.com/bitcoin/bitcoin/issues/19476 | wip, rpc: Add mempoolchanges by promag · Pull Request #19476 · bitcoin/bitcoin · GitHub
 754 2020-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?
 755 2020-07-09T19:38:04  <wumpus> but I mean, how many of these things do you want to integrate with
 756 2020-07-09T19:38:07  <instagibbs> promag, your rpc could be maybe generalized into block hash announcements too, connect/disconnect
 757 2020-07-09T19:38:24  <instagibbs> jnewbery, it has as seq number
 758 2020-07-09T19:38:36  <instagibbs> but right now it's a hodgepodge of endpoints
 759 2020-07-09T19:38:41  <wumpus> yes, it has a seq number
 760 2020-07-09T19:38:43  <instagibbs> and missing eviction entirely
 761 2020-07-09T19:39:07  <jnewbery> right, we're talking about two things here. Let's assume that your eviction PR is merged
 762 2020-07-09T19:39:11  <wumpus> all the zmq endpoints have seq numbers
 763 2020-07-09T19:39:31  <shuckc> if eviction PR is merged, the remaining issues are:
 764 2020-07-09T19:39:31  <wumpus> I'mnot sure these are actually useful because people keep complaining about this
 765 2020-07-09T19:39:53  <promag> wumpus: you don't know at what sequence corresponds a getrawmempool response
 766 2020-07-09T19:40:02  <wumpus> no, indeed you don't
 767 2020-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
 768 2020-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
 769 2020-07-09T19:40:33  *** Evel-Knievel has joined #bitcoin-core-dev
 770 2020-07-09T19:40:35  <wumpus> zmq logging to file? taht sounds really at odd with low-latency
 771 2020-07-09T19:40:35  <jnewbery> *for that txid
 772 2020-07-09T19:40:45  <luke-jr> wumpus: mkfifo ☺
 773 2020-07-09T19:40:55  <wumpus> luke-jr: fifo is one to one, not one to many
 774 2020-07-09T19:40:56  <luke-jr> not sure why ZMQ is involved at that point lol
 775 2020-07-09T19:40:58  <luke-jr> true
 776 2020-07-09T19:41:05  <wumpus> luke-jr: if only UNIX had a one to many notification mechanism
 777 2020-07-09T19:41:13  <wumpus> except for mail
 778 2020-07-09T19:41:14  <luke-jr> dbus?
 779 2020-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
 780 2020-07-09T19:41:29  <aj> wumpus: wall(1) :)
 781 2020-07-09T19:41:32  * luke-jr is not sure dbus actually has this
 782 2020-07-09T19:41:35  <luke-jr> aj: lol
 783 2020-07-09T19:41:38  <wumpus> no, dbus doesn't have it either
 784 2020-07-09T19:41:45  *** shuckc has quit IRC
 785 2020-07-09T19:41:48  <wumpus> dbus is one to one, it has no realible multi consumer broadcase
 786 2020-07-09T19:42:13  <luke-jr> I suppose you could just use a tmpfs file
 787 2020-07-09T19:42:13  <wumpus> it's a difficult issue in general
 788 2020-07-09T19:42:20  <wumpus> because some consumer might always be lagging
 789 2020-07-09T19:42:21  <luke-jr> and punch holes at the start as desired
 790 2020-07-09T19:42:29  <wumpus> this can potentially result in infinitely much storage needed
 791 2020-07-09T19:42:36  <luke-jr> or store to disk and let Linux's buffers handle it
 792 2020-07-09T19:42:47  <wumpus> rabbitmq is pretty good if you really need this
 793 2020-07-09T19:44:28  *** shuckc has joined #bitcoin-core-dev
 794 2020-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
 795 2020-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
 796 2020-07-09T19:45:32  <instagibbs> I was joking that you could also do minisketch for set reconciliation of mempool views
 797 2020-07-09T19:45:47  <sipa> haha
 798 2020-07-09T19:45:54  <luke-jr> jnewbery: I'm not sure we want to encourage software to parse debug.log …
 799 2020-07-09T19:45:58  <instagibbs> zmq to keep difference small ;)
 800 2020-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)
 801 2020-07-09T19:46:11  <wumpus> luke-jr: exactly
 802 2020-07-09T19:46:30  <wumpus> I don't think 'parse the log' is a good option, though it serves one-to-many notification perfectly
 803 2020-07-09T19:46:37  <wumpus> mq is essentially a log
 804 2020-07-09T19:46:43  <wumpus> until your disk is full
 805 2020-07-09T19:46:45  <luke-jr> a dedicated, well-defined-format log might be okay
 806 2020-07-09T19:47:07  <wumpus> it's also a high latency option but that might not matter
 807 2020-07-09T19:47:07  <luke-jr> but something needs to do hole-punching to clean it up before disk fills
 808 2020-07-09T19:47:15  <luke-jr> wumpus: why is it high latency?
 809 2020-07-09T19:47:23  <wumpus> yes, but if you do tha, some clients might miss messages
 810 2020-07-09T19:47:32  <sipa> luke-jr: bitcoind will already shut down when disk is full
 811 2020-07-09T19:47:33  <sipa> :)
 812 2020-07-09T19:47:35  <luke-jr> depends on who does it
 813 2020-07-09T19:47:35  <wumpus> unless they tell you they read up until that far
 814 2020-07-09T19:47:43  <luke-jr> sipa: yes, but you don't want that
 815 2020-07-09T19:47:55  <wumpus> luke-jr: because disk/block devices are slow, compared to networking, latency wise
 816 2020-07-09T19:48:02  <luke-jr> wumpus: Linux at least has buffers
 817 2020-07-09T19:48:08  <wumpus> even with that
 818 2020-07-09T19:48:11  <luke-jr> :/
 819 2020-07-09T19:48:20  <luke-jr> the write/read won't even need to hit disk
 820 2020-07-09T19:48:32  * luke-jr wonders if you can tell Linux to never flush to disk unless it has to
 821 2020-07-09T19:48:37  <luke-jr> per-device*
 822 2020-07-09T19:48:45  <luke-jr> per-file would also be nice :P
 823 2020-07-09T19:49:04  <wumpus> yes, there's an option for that afaik, but it also means in case of power loss...
 824 2020-07-09T19:49:08  *** gzhao408 has quit IRC
 825 2020-07-09T19:49:47  <jnewbery> shuckc: it sounded like you were going to mention more issues. Was there anything else?
 826 2020-07-09T19:49:50  <wumpus> reliable delivery of messages to multiple consumers is a difficult topic
 827 2020-07-09T19:50:08  <sipa> we need a blockchain
 828 2020-07-09T19:50:13  <wumpus> sipa: :-)
 829 2020-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
 830 2020-07-09T19:50:32  <wumpus> yes, at least the blockchain always allows going back i time... well unless pruning
 831 2020-07-09T19:50:44  <wumpus> pruning is kind of the 'what if not all consumers have seen this yet' problem
 832 2020-07-09T19:50:45  <shuckc> the sequence number on the response to getrawmempool
 833 2020-07-09T19:51:09  <shuckc> obviously has backward compatibility concerns, and other suggestions?
 834 2020-07-09T19:51:20  <sipa> shuckc: hmm?
 835 2020-07-09T19:51:29  <luke-jr> wumpus: there is an option for that? what? :o
 836 2020-07-09T19:51:32  <instagibbs> sipa, he wants to know where the mempool "snapshot" came from
 837 2020-07-09T19:51:37  <sipa> does getrawmempool report a sequence number now?
 838 2020-07-09T19:51:41  <instagibbs> no
 839 2020-07-09T19:51:45  <wumpus> it doesn't
 840 2020-07-09T19:51:49  <shuckc> no, I'm suggeting it should
 841 2020-07-09T19:51:49  <sipa> and adding one would help?
 842 2020-07-09T19:51:52  <shuckc> yes
 843 2020-07-09T19:51:54  <sipa> oh, ok
 844 2020-07-09T19:52:03  <instagibbs> so you don't know if the getrawmempool result is stale or from "future" wrt zmq reports
 845 2020-07-09T19:52:05  <sipa> what would be the reason not to?
 846 2020-07-09T19:52:05  <shuckc> because you can't tell which delta(s) have already been added
 847 2020-07-09T19:52:09  <wumpus> I guess it could prove that there were no updates in between
 848 2020-07-09T19:52:12  <sipa> adding new fields has no backward compatibility concerns
 849 2020-07-09T19:52:19  <instagibbs> sipa, I think you'd have to add *all* the zmq notification seq numbers
 850 2020-07-09T19:52:24  <sipa> ah
 851 2020-07-09T19:52:26  <instagibbs> well it's an array result ;
 852 2020-07-09T19:52:28  <instagibbs> ;)
 853 2020-07-09T19:52:34  <promag> can bnly be added if verbose=true in getrawmempool
 854 2020-07-09T19:52:39  <instagibbs> but like I said I think optional arg -> json object
 855 2020-07-09T19:52:45  <wumpus> I wonder why every zmq message has its own sequence number
 856 2020-07-09T19:52:54  <wumpus> couldn't it be just one increasing atomic?
 857 2020-07-09T19:52:55  <shuckc> unless you have one single notifier that you use for all the messages you need to sync with
 858 2020-07-09T19:52:56  <instagibbs> wumpus, it's a local member of hte notification, for whatever reason
 859 2020-07-09T19:53:09  <promag> wumpus: a client knows if he missed anything
 860 2020-07-09T19:53:18  <wumpus> promag: oh, true
 861 2020-07-09T19:53:18  <shuckc> it's only a mess if need to track lots of notifiers
 862 2020-07-09T19:53:32  <wumpus> yes, makes sense, a client is generally interested in only a subset of message kinds
 863 2020-07-09T19:53:35  <instagibbs> shuckc, shouldn't be too bad, you just grab the one you care about
 864 2020-07-09T19:53:45  <wumpus> so a global sequence number would be useless
 865 2020-07-09T19:54:11  <promag> wumpus: not really, that number should be exposed in both rpc response and zmq message
 866 2020-07-09T19:54:18  <wumpus> in any case getmempool would only need the mempool related numbers...
 867 2020-07-09T19:54:26  <promag> but I'm not fond of that..
 868 2020-07-09T19:54:42  <wumpus> it seems like some kind of layer violation
 869 2020-07-09T19:54:46  <wumpus> having RPC query ZMQ
 870 2020-07-09T19:54:54  <promag> because as a client, you need to use rpc AND zmq
 871 2020-07-09T19:54:59  <wumpus> yes
 872 2020-07-09T19:55:02  <instagibbs> otherwise you need to somehow ask for unique snapshot
 873 2020-07-09T19:55:11  <promag> hence my draft PR
 874 2020-07-09T19:55:11  <instagibbs> of the mempool
 875 2020-07-09T19:55:33  <instagibbs> but yes, it's a light violation at least
 876 2020-07-09T19:55:35  *** owowo has quit IRC
 877 2020-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
 878 2020-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
 879 2020-07-09T19:56:00  <wumpus> of course, that could be worked around by having both RPC and ZMQ query another source for sequence numbers
 880 2020-07-09T19:56:03  <jnewbery> how about if the mempool itself had a seq number that is incremented on every add/remove?
 881 2020-07-09T19:56:09  <wumpus> right
 882 2020-07-09T19:56:19  <instagibbs> jnewbery, that's promag's pr pretty much-ish
 883 2020-07-09T19:56:20  <wumpus> I think that would make sense
 884 2020-07-09T19:57:08  <instagibbs> 3 minutes
 885 2020-07-09T19:57:25  <wumpus> so +1 on jnewbery/promag's idea then
 886 2020-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
 887 2020-07-09T19:58:05  <wumpus> I didn't understand it like that
 888 2020-07-09T19:58:09  <promag> note that in my PR, the "stream" will be upper bounded in size, so no OOM concerns
 889 2020-07-09T19:58:10  <luke-jr> shuckc: not if he adds longpolling
 890 2020-07-09T19:58:15  <wumpus> the mempool itself would keep the seq number
 891 2020-07-09T19:58:24  <wumpus> not per consumer
 892 2020-07-09T19:58:29  <promag> shuckc: ill add long poll
 893 2020-07-09T19:58:36  <wumpus> it's kind of strange if different consumers have differnt seq ids
 894 2020-07-09T19:58:41  <shuckc> do any other commands use long polling?
 895 2020-07-09T19:58:45  <wumpus> because this is global state we're exposing
 896 2020-07-09T19:58:46  <luke-jr> GBT
 897 2020-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
 898 2020-07-09T19:58:46  <promag> shuckc: yes
 899 2020-07-09T19:58:51  <instagibbs> getblocktemplate <--- GBT
 900 2020-07-09T19:59:10  *** Evel-Knievel has quit IRC
 901 2020-07-09T19:59:12  <promag> I don't like longpoll that much tbh, at least in json rpc
 902 2020-07-09T19:59:33  <promag> especially because of libevent, timeouts etcetc
 903 2020-07-09T19:59:51  <promag> but "poll and wait up to n secs" if fine imo
 904 2020-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
 905 2020-07-09T20:00:02  <luke-jr> promag: same thing? :P
 906 2020-07-09T20:00:03  <wumpus> it would mean accumulating in memory in that case?
 907 2020-07-09T20:00:20  <promag> luke-jr: n secs < timeoud (:
 908 2020-07-09T20:00:26  <promag> wumpus: yes
 909 2020-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...
 910 2020-07-09T20:00:33  <promag> but thats's fine
 911 2020-07-09T20:00:50  <luke-jr> fjahr: then you need to log the hash..
 912 2020-07-09T20:00:55  <promag> if the client doensn't pull the stream, the stream will be terminated
 913 2020-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
 914 2020-07-09T20:01:00  <instagibbs> fjahr, even more ridiculous than my minisketch idea ;P
 915 2020-07-09T20:01:10  <wumpus> promag: that's just another "lose notifications" then
 916 2020-07-09T20:01:17  <fjahr> hehe
 917 2020-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
 918 2020-07-09T20:01:47  <wumpus> reliable notification is really a non-trivial issue :)
 919 2020-07-09T20:01:49  <promag> wumpus: no, the stream will be terminated, the client starts over and gets a fresh stream
 920 2020-07-09T20:01:57  <wumpus> in any case, it's time
 921 2020-07-09T20:02:09  <aj> instagibbs: (minisketch is a great idea!)
 922 2020-07-09T20:02:11  <wumpus> #endmeeting
 923 2020-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)
 924 2020-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
 925 2020-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
 926 2020-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
 927 2020-07-09T20:02:17  <luke-jr> promag: maybe this should be part of getrawmempool?
 928 2020-07-09T20:02:26  *** owowo has joined #bitcoin-core-dev
 929 2020-07-09T20:02:26  <instagibbs> aj, just need the tool in -cli, I think :D
 930 2020-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
 931 2020-07-09T20:02:48  <promag> luke-jr: meh, let's not overload, at least for the momemnt
 932 2020-07-09T20:02:51  <wumpus> it has the same problems I think
 933 2020-07-09T20:03:02  <luke-jr> promag: well, they need to interact..
 934 2020-07-09T20:03:17  <instagibbs> shuckc, I think the idea would be you'd replace getrawmempool entirely with this new call
 935 2020-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
 936 2020-07-09T20:03:22  <promag> shuckc: you won't use getrawmempool anymore
 937 2020-07-09T20:03:23  <luke-jr> wumpus: forever buffer vs limited buffer vs no buffer
 938 2020-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
 939 2020-07-09T20:03:37  <wumpus> luke-jr: zmq has a limited buffer, like anything
 940 2020-07-09T20:03:47  <luke-jr> wumpus: not in my experience
 941 2020-07-09T20:03:57  <wumpus> you can even set it with some option
 942 2020-07-09T20:04:00  <promag> wumpus: you call "mempoolchanges <stream id> <max enntries> <timeout>"
 943 2020-07-09T20:04:26  <promag> wumpus: so you don't worry about http response size etc
 944 2020-07-09T20:04:50  <luke-jr> promag: s/stream id/last update id/
 945 2020-07-09T20:04:58  <wumpus> what if it exceeds the number of entries then?
 946 2020-07-09T20:05:00  <promag> the concept is pretty much like postgres write-ahead-log and replication slots
 947 2020-07-09T20:05:09  <luke-jr> promag: and for timeout, the client can just disconnect?
 948 2020-07-09T20:05:19  <luke-jr> wumpus: then you need to get the entire mempool and start over
 949 2020-07-09T20:05:26  <promag> luke-jr: no, stream id - you can have multiple clients, each with their own stream
 950 2020-07-09T20:05:32  <luke-jr> (which is another reason to overload getrawmempool?)
 951 2020-07-09T20:05:35  <wumpus> exactly as with zmq notifications if you miss a sequence number
 952 2020-07-09T20:05:41  <luke-jr> promag: they shouldn't have separate streams
 953 2020-07-09T20:06:03  <luke-jr> wumpus: except you're less likely to miss one
 954 2020-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
 955 2020-07-09T20:06:13  <wumpus> 'less likely' is no guarantee!
 956 2020-07-09T20:06:19  <promag> need to afk, please view my PR code, it's very small/simple
 957 2020-07-09T20:06:37  <luke-jr> wumpus: it doesn't need to be a guarantee to work well
 958 2020-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
 959 2020-07-09T20:06:57  *** promag_ has quit IRC
 960 2020-07-09T20:07:13  *** promag_ has joined #bitcoin-core-dev
 961 2020-07-09T20:07:15  <luke-jr> it's not critical, just something you'd prefer to avoid
 962 2020-07-09T20:07:18  <instagibbs> hopefully not critical anywhere
 963 2020-07-09T20:07:18  <shuckc> I'll review it promag and see if it covers all our uses
 964 2020-07-09T20:07:22  <wumpus> how do you mean 'work well' then, not lose money for *most* users?
 965 2020-07-09T20:07:33  <luke-jr> wumpus: it's an optimisation
 966 2020-07-09T20:07:46  <luke-jr> you *could* always just getrawmempool constantly, but it'd be slow
 967 2020-07-09T20:07:58  <wumpus> you need to setup your client code to handle missing notifications in any case
 968 2020-07-09T20:08:13  <luke-jr> yes, and hopefully it won't happen often
 969 2020-07-09T20:08:18  <wumpus> you can increase the zmq buffer size for that
 970 2020-07-09T20:08:20  <instagibbs> miss message -> patch with getrawmempool-like response
 971 2020-07-09T20:08:29  <instagibbs> keep that infrequent, it's a win
 972 2020-07-09T20:08:44  <wumpus> people have been discussing this since 2012 or so since zmq notifications were added
 973 2020-07-09T20:09:05  <instagibbs> and yet, we don't have eviction notifications at all :P
 974 2020-07-09T20:09:10  <wumpus> I wish we never did fwiw
 975 2020-07-09T20:09:13  <instagibbs> understood though im sure it's tiring
 976 2020-07-09T20:09:14  <luke-jr> wumpus: admittedly I haven't used ZMQ since these problems, but it didn't work for me
 977 2020-07-09T20:09:19  <wumpus> it's only been like this every time
 978 2020-07-09T20:09:23  <wumpus> ZMQ IS UNRELIABLE
 979 2020-07-09T20:09:24  <wumpus> ITS USELESS
 980 2020-07-09T20:09:26  <wumpus> yeshh
 981 2020-07-09T20:09:50  <wumpus> like let's just remove it
 982 2020-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
 983 2020-07-09T20:09:56  <instagibbs> well, it's being used in the wild, SFYL
 984 2020-07-09T20:10:02  <instagibbs> LND uses it too
 985 2020-07-09T20:10:11  <instagibbs> (don't know why exactly, just does)
 986 2020-07-09T20:10:13  <wumpus> instagibbs: I know
 987 2020-07-09T20:10:16  <promag> wumpus: too late, sorry for that honestly X)
 988 2020-07-09T20:10:43  <wumpus> instagibbs: I know it's actually used by peple in production, but the discussions are always the same
 989 2020-07-09T20:10:50  <instagibbs> understood
 990 2020-07-09T20:10:59  <promag> #6103 :shame:
 991 2020-07-09T20:11:04  <gribble> https://github.com/bitcoin/bitcoin/issues/6103 | Add ZeroMQ notifications by promag · Pull Request #6103 · bitcoin/bitcoin · GitHub
 992 2020-07-09T20:11:29  <wumpus> sorry :)
 993 2020-07-09T20:11:49  <promag> cheers
 994 2020-07-09T20:11:58  *** promag_ has quit IRC
 995 2020-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'
 996 2020-07-09T20:12:34  *** promag_ has joined #bitcoin-core-dev
 997 2020-07-09T20:13:03  *** promag has quit IRC
 998 2020-07-09T20:13:37  *** promag has joined #bitcoin-core-dev
 999 2020-07-09T20:14:41  *** Evel-Knievel has joined #bitcoin-core-dev
1000 2020-07-09T20:14:50  <cfields> sipa: I suppose the old gcc issue is that the propagate_on_container_* aren't respected ?
1001 2020-07-09T20:15:03  <sipa> cfields: possibly
1002 2020-07-09T20:15:12  <sipa> but it looks like that
1003 2020-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
1004 2020-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
1005 2020-07-09T20:17:58  <wumpus> one other common reliable mq notification system nowadays is Apache Kafka
1006 2020-07-09T20:18:03  <jnewbery> if ZMQ is really unfit for purpose it should be removed and replaced
1007 2020-07-09T20:18:17  <wumpus> I agree
1008 2020-07-09T20:18:24  *** promag has quit IRC
1009 2020-07-09T20:18:33  <instagibbs> If you waved away the getrawmempool thing, I think it's probably fine enough
1010 2020-07-09T20:19:39  <instagibbs> block notifications are very cheap to "heal", 300MB mempool is not
1011 2020-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."
1012 2020-07-09T20:20:47  <sipa> cfields: ah
1013 2020-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.
1014 2020-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.
1015 2020-07-09T20:26:14  <instagibbs> if you're going to have to use RPC, might as well use RPC?
1016 2020-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
1017 2020-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
1018 2020-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.
1019 2020-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
1020 2020-07-09T20:28:37  <wumpus> independent of the notification system
1021 2020-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
1022 2020-07-09T20:29:23  *** pinheadmz1 has quit IRC
1023 2020-07-09T20:30:01  <sipa> cfields: also now i remember the reason why i made it inherit from std::allocator
1024 2020-07-09T20:30:27  <sipa> old libstdc++ doesn't implement allocator_traits, so you need all dozen trivial functions and types on it
1025 2020-07-09T20:30:48  <cfields> oh, heh, yeah, that'd be a problem.
1026 2020-07-09T20:30:57  <sipa> it's just inconvenient
1027 2020-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
1028 2020-07-09T20:31:28  <sipa> cfields: https://github.com/bitcoin/bitcoin/pull/18086/commits/378bbcd271734665b973351bf3862b3943b10ffc
1029 2020-07-09T20:31:34  <instagibbs> ok!
1030 2020-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.
1031 2020-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 :(
1032 2020-07-09T20:36:13  *** justanotheruser has joined #bitcoin-core-dev
1033 2020-07-09T20:36:32  <cfields> sipa: also, nit, isn't std::allocator guaranteed stateless? Can't you just call its static members?
1034 2020-07-09T20:37:11  *** justan0theruser has quit IRC
1035 2020-07-09T20:41:28  <cfields> nm, obviously not.
1036 2020-07-09T20:41:43  *** zaff has quit IRC
1037 2020-07-09T20:52:43  *** proofofkeags has quit IRC
1038 2020-07-09T20:54:58  *** bitcoin-git has joined #bitcoin-core-dev
1039 2020-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
1040 2020-07-09T20:54:59  *** bitcoin-git has left #bitcoin-core-dev
1041 2020-07-09T20:58:11  *** Guyver2 has quit IRC
1042 2020-07-09T21:00:02  *** Xing`1 has quit IRC
1043 2020-07-09T21:02:40  *** nik-j has quit IRC
1044 2020-07-09T21:03:15  *** nik-j has joined #bitcoin-core-dev
1045 2020-07-09T21:06:30  *** nik-j has quit IRC
1046 2020-07-09T21:06:43  *** nik-j has joined #bitcoin-core-dev
1047 2020-07-09T21:14:52  *** ghost43 has quit IRC
1048 2020-07-09T21:15:12  *** ghost43 has joined #bitcoin-core-dev
1049 2020-07-09T21:17:06  *** shuckc has quit IRC
1050 2020-07-09T21:18:34  *** Randolf has joined #bitcoin-core-dev
1051 2020-07-09T21:22:33  *** KindOne1 has joined #bitcoin-core-dev
1052 2020-07-09T21:27:18  *** promag has joined #bitcoin-core-dev
1053 2020-07-09T21:29:33  *** proofofkeags has joined #bitcoin-core-dev
1054 2020-07-09T21:29:51  *** Randolf has quit IRC
1055 2020-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 :)
1056 2020-07-09T21:31:29  <cfields> jonatack: thanks for the motivation to build llvm today, I really wanted to test ^^
1057 2020-07-09T21:32:27  <cfields> No idea how well at works, but "./bitcoind --help" works, at least.
1058 2020-07-09T21:34:43  <promag> cfields: nice, builds qt too?
1059 2020-07-09T21:35:53  <cfields> promag: heh, no clue. I didn't want to end up deep in qt link issues...
1060 2020-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.
1061 2020-07-09T21:43:03  *** lnostdal has quit IRC
1062 2020-07-09T21:45:45  *** Evel-Knievel has quit IRC
1063 2020-07-09T21:46:10  *** Evel-Knievel has joined #bitcoin-core-dev
1064 2020-07-09T21:48:51  *** nik-j has quit IRC
1065 2020-07-09T21:54:22  *** promag has quit IRC
1066 2020-07-09T21:55:08  *** nik-j has joined #bitcoin-core-dev
1067 2020-07-09T21:55:08  *** promag has joined #bitcoin-core-dev
1068 2020-07-09T21:55:36  *** lnostdal has joined #bitcoin-core-dev
1069 2020-07-09T22:06:56  *** nik-j has quit IRC
1070 2020-07-09T22:07:24  *** nik-j has joined #bitcoin-core-dev
1071 2020-07-09T22:07:33  <cfields> promag: yeah, it doesn't know how to find .tbd frameworks yet, so no qt.
1072 2020-07-09T22:07:47  <cfields> I'll check to see if that _should_ be working yet and report it upstream if so.
1073 2020-07-09T22:13:05  *** andrewtoth has joined #bitcoin-core-dev
1074 2020-07-09T22:23:33  *** achow101 has quit IRC
1075 2020-07-09T22:25:58  *** achow101 has joined #bitcoin-core-dev
1076 2020-07-09T22:32:02  *** IGHOR has quit IRC
1077 2020-07-09T22:32:55  *** marcoagner has quit IRC
1078 2020-07-09T22:33:18  *** IGHOR has joined #bitcoin-core-dev
1079 2020-07-09T22:34:18  *** promag has quit IRC
1080 2020-07-09T22:34:37  *** mdunnio has quit IRC
1081 2020-07-09T22:35:05  *** promag has joined #bitcoin-core-dev
1082 2020-07-09T22:43:13  *** justanotheruser has quit IRC
1083 2020-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
1084 2020-07-09T22:48:25  <phantomcircuit> i've used it before but only with the knowledge that it's basically udp
1085 2020-07-09T22:50:58  *** andrewtoth has quit IRC
1086 2020-07-09T23:00:22  *** justanotheruser has joined #bitcoin-core-dev
1087 2020-07-09T23:01:36  *** dr-orlovsky has quit IRC
1088 2020-07-09T23:08:28  *** mdunnio has joined #bitcoin-core-dev
1089 2020-07-09T23:13:16  *** mdunnio has quit IRC
1090 2020-07-09T23:22:43  *** sipa has quit IRC
1091 2020-07-09T23:24:55  *** justanotheruser has quit IRC
1092 2020-07-09T23:26:47  *** Relis has quit IRC
1093 2020-07-09T23:33:42  *** Relis has joined #bitcoin-core-dev
1094 2020-07-09T23:39:21  *** sipa has joined #bitcoin-core-dev
1095 2020-07-09T23:41:24  *** justanotheruser has joined #bitcoin-core-dev
1096 2020-07-09T23:44:06  *** arowser has quit IRC
1097 2020-07-09T23:44:34  *** arowser has joined #bitcoin-core-dev
1098 2020-07-09T23:47:13  *** promag has quit IRC
1099 2020-07-09T23:47:46  *** promag has joined #bitcoin-core-dev
1100 2020-07-09T23:51:08  *** jarthur has quit IRC
1101 2020-07-09T23:57:35  *** promag has quit IRC