1 2017-11-30T00:05:55  *** intcat has quit IRC
   2 2017-11-30T00:06:51  *** intcat has joined #bitcoin-core-dev
   3 2017-11-30T00:13:57  *** intcat has quit IRC
   4 2017-11-30T00:15:06  *** intcat has joined #bitcoin-core-dev
   5 2017-11-30T00:17:14  *** justanotheruser has quit IRC
   6 2017-11-30T00:23:39  *** Peilin-Yang has joined #bitcoin-core-dev
   7 2017-11-30T00:31:42  *** Randolf has quit IRC
   8 2017-11-30T00:31:59  *** dqx has quit IRC
   9 2017-11-30T00:32:52  *** DvdKhl has quit IRC
  10 2017-11-30T00:33:30  *** dqx has joined #bitcoin-core-dev
  11 2017-11-30T00:38:23  *** dqx has quit IRC
  12 2017-11-30T00:41:26  *** Peilin-Yang has quit IRC
  13 2017-11-30T00:50:07  *** unholymachine has joined #bitcoin-core-dev
  14 2017-11-30T00:54:04  *** Krellan has quit IRC
  15 2017-11-30T00:54:35  *** Krellan has joined #bitcoin-core-dev
  16 2017-11-30T00:57:14  *** AaronvanW has quit IRC
  17 2017-11-30T01:14:16  *** Randolf has joined #bitcoin-core-dev
  18 2017-11-30T01:16:55  *** intcat has quit IRC
  19 2017-11-30T01:21:14  *** intcat has joined #bitcoin-core-dev
  20 2017-11-30T01:21:16  *** wxss has quit IRC
  21 2017-11-30T01:23:13  *** Randolf has quit IRC
  22 2017-11-30T01:27:17  <promag> fanquake: extended tests too? https://github.com/bitcoin/bitcoin/pull/11791#issuecomment-348052591
  23 2017-11-30T01:30:35  *** promag has quit IRC
  24 2017-11-30T01:31:59  <fanquake> promag I can run them also
  25 2017-11-30T01:36:05  *** Ylbam has quit IRC
  26 2017-11-30T01:39:18  *** roidster has joined #bitcoin-core-dev
  27 2017-11-30T01:43:23  *** Randolf has joined #bitcoin-core-dev
  28 2017-11-30T01:45:05  *** Cogito_Ergo_Sum has quit IRC
  29 2017-11-30T01:59:39  *** dqx has joined #bitcoin-core-dev
  30 2017-11-30T02:09:49  *** dqx has quit IRC
  31 2017-11-30T02:10:19  *** dqx has joined #bitcoin-core-dev
  32 2017-11-30T02:12:12  *** fanquake has left #bitcoin-core-dev
  33 2017-11-30T02:12:14  *** goatpig has quit IRC
  34 2017-11-30T02:17:21  *** bule has quit IRC
  35 2017-11-30T02:17:36  *** bule has joined #bitcoin-core-dev
  36 2017-11-30T02:20:58  *** intcat has quit IRC
  37 2017-11-30T02:23:02  *** intcat has joined #bitcoin-core-dev
  38 2017-11-30T02:23:21  *** Murch has quit IRC
  39 2017-11-30T02:29:44  *** meshcollider has quit IRC
  40 2017-11-30T02:48:31  *** Cheeseo has quit IRC
  41 2017-11-30T02:55:58  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  42 2017-11-30T03:07:34  *** Krellan has quit IRC
  43 2017-11-30T03:08:07  *** Krellan has joined #bitcoin-core-dev
  44 2017-11-30T03:15:52  *** dabura667 has joined #bitcoin-core-dev
  45 2017-11-30T03:18:56  *** intcat has quit IRC
  46 2017-11-30T03:20:49  *** intcat has joined #bitcoin-core-dev
  47 2017-11-30T03:23:30  *** dqx_ has joined #bitcoin-core-dev
  48 2017-11-30T03:27:15  *** dqx has quit IRC
  49 2017-11-30T03:31:54  *** Emcy_ has joined #bitcoin-core-dev
  50 2017-11-30T03:35:16  *** Emcy has quit IRC
  51 2017-11-30T03:35:27  *** dabura667 has quit IRC
  52 2017-11-30T03:41:33  *** Chris_Stewart_5 has quit IRC
  53 2017-11-30T03:48:17  *** Cory has quit IRC
  54 2017-11-30T03:53:57  *** Pasha has joined #bitcoin-core-dev
  55 2017-11-30T03:54:02  *** intcat has quit IRC
  56 2017-11-30T03:54:45  *** intcat has joined #bitcoin-core-dev
  57 2017-11-30T03:57:09  *** Pasha is now known as Cory
  58 2017-11-30T03:59:56  *** intcat has quit IRC
  59 2017-11-30T04:00:45  *** intcat has joined #bitcoin-core-dev
  60 2017-11-30T04:16:06  *** Emcy has joined #bitcoin-core-dev
  61 2017-11-30T04:16:57  *** intcat has quit IRC
  62 2017-11-30T04:17:45  *** intcat has joined #bitcoin-core-dev
  63 2017-11-30T04:18:26  *** Emcy_ has quit IRC
  64 2017-11-30T04:35:42  *** roidster has quit IRC
  65 2017-11-30T04:40:02  *** roidster has joined #bitcoin-core-dev
  66 2017-11-30T04:40:25  *** roidster is now known as Guest70745
  67 2017-11-30T04:40:48  *** Guest70745 is now known as roidster
  68 2017-11-30T04:44:05  *** dqx has joined #bitcoin-core-dev
  69 2017-11-30T04:46:02  *** dqx_ has quit IRC
  70 2017-11-30T05:02:20  *** ula has quit IRC
  71 2017-11-30T05:11:21  *** jouke has quit IRC
  72 2017-11-30T05:11:58  *** intcat has quit IRC
  73 2017-11-30T05:13:16  *** intcat has joined #bitcoin-core-dev
  74 2017-11-30T05:13:40  *** Krellan has quit IRC
  75 2017-11-30T05:14:37  *** Krellan has joined #bitcoin-core-dev
  76 2017-11-30T05:29:18  *** murr4y has quit IRC
  77 2017-11-30T05:29:39  *** StopAndDecrypt has quit IRC
  78 2017-11-30T05:30:03  *** StopAndDecrypt has joined #bitcoin-core-dev
  79 2017-11-30T05:30:04  *** StopAndDecrypt has quit IRC
  80 2017-11-30T05:30:04  *** StopAndDecrypt has joined #bitcoin-core-dev
  81 2017-11-30T05:35:27  *** roidster has quit IRC
  82 2017-11-30T05:46:44  *** Emcy has quit IRC
  83 2017-11-30T05:51:27  *** dqx has quit IRC
  84 2017-11-30T05:53:01  *** dqx has joined #bitcoin-core-dev
  85 2017-11-30T06:03:17  *** chjj has quit IRC
  86 2017-11-30T06:04:15  <warren> MarcoFalke: https://github.com/bitcoin-core/docs/blob/master/gitian-building/gitian-building-setup-gitian-fedora.md  nice!  how recently did you test this btw?
  87 2017-11-30T06:04:28  *** arubi_ has quit IRC
  88 2017-11-30T06:04:57  <warren> MarcoFalke: I have had python-vm-builder RPM packages for years but it broke sometime this year and couldn't figure out how to fix it. although I use only qemu-kvm, not lxc.
  89 2017-11-30T06:07:17  *** intcat has quit IRC
  90 2017-11-30T06:08:02  *** intcat has joined #bitcoin-core-dev
  91 2017-11-30T06:09:35  *** arubi has joined #bitcoin-core-dev
  92 2017-11-30T06:10:24  *** DigitalDank has joined #bitcoin-core-dev
  93 2017-11-30T06:19:37  *** DigitalDank has quit IRC
  94 2017-11-30T06:19:50  *** jouke has joined #bitcoin-core-dev
  95 2017-11-30T06:19:58  *** intcat has quit IRC
  96 2017-11-30T06:20:48  *** intcat has joined #bitcoin-core-dev
  97 2017-11-30T06:21:11  *** DigitalDank has joined #bitcoin-core-dev
  98 2017-11-30T06:24:02  *** dqx has quit IRC
  99 2017-11-30T06:25:21  *** intcat has quit IRC
 100 2017-11-30T06:26:12  *** intcat has joined #bitcoin-core-dev
 101 2017-11-30T06:28:03  *** DigitalDank has quit IRC
 102 2017-11-30T06:29:24  *** DigitalDank has joined #bitcoin-core-dev
 103 2017-11-30T06:31:04  *** meshcollider has joined #bitcoin-core-dev
 104 2017-11-30T06:35:45  *** DigitalDank has quit IRC
 105 2017-11-30T06:36:25  *** DigitalDank has joined #bitcoin-core-dev
 106 2017-11-30T06:37:43  *** DigitalDank has quit IRC
 107 2017-11-30T06:49:55  *** Ylbam has joined #bitcoin-core-dev
 108 2017-11-30T06:50:21  *** Emcy has joined #bitcoin-core-dev
 109 2017-11-30T07:00:47  *** chirayu has joined #bitcoin-core-dev
 110 2017-11-30T07:02:39  *** chirayu has quit IRC
 111 2017-11-30T07:10:07  *** DvdKhl has joined #bitcoin-core-dev
 112 2017-11-30T07:10:21  *** Murch has joined #bitcoin-core-dev
 113 2017-11-30T07:17:04  *** intcat has quit IRC
 114 2017-11-30T07:17:32  *** arubi has quit IRC
 115 2017-11-30T07:18:07  *** intcat has joined #bitcoin-core-dev
 116 2017-11-30T07:19:05  <bitcoin-git> [bitcoin] Varunram opened pull request #11793: Docs: Bump OS X version to 10.13 (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11793
 117 2017-11-30T07:19:11  *** arubi has joined #bitcoin-core-dev
 118 2017-11-30T07:19:30  *** Krellan has quit IRC
 119 2017-11-30T07:19:49  <Varunram> ^ This needn't be a standalone PR in itself, can be merged with other fixes
 120 2017-11-30T07:20:08  *** Krellan has joined #bitcoin-core-dev
 121 2017-11-30T07:23:00  *** Murch has quit IRC
 122 2017-11-30T07:25:41  *** timothy has joined #bitcoin-core-dev
 123 2017-11-30T07:27:22  *** murr4y has joined #bitcoin-core-dev
 124 2017-11-30T07:27:58  *** intcat has quit IRC
 125 2017-11-30T07:29:07  *** intcat has joined #bitcoin-core-dev
 126 2017-11-30T07:37:41  <bitcoin-git> [bitcoin] laanwj closed pull request #9254: [depends] ZeroMQ 4.2.2 (master...zeromq-4-2-0) https://github.com/bitcoin/bitcoin/pull/9254
 127 2017-11-30T07:38:07  *** BashCo has quit IRC
 128 2017-11-30T07:48:17  *** jtimon has quit IRC
 129 2017-11-30T07:53:09  *** chjj has joined #bitcoin-core-dev
 130 2017-11-30T07:55:05  *** dabura667 has joined #bitcoin-core-dev
 131 2017-11-30T07:57:58  *** intcat has quit IRC
 132 2017-11-30T07:58:43  *** intcat has joined #bitcoin-core-dev
 133 2017-11-30T07:59:51  *** BashCo has joined #bitcoin-core-dev
 134 2017-11-30T08:00:56  *** intcat has quit IRC
 135 2017-11-30T08:01:48  *** intcat has joined #bitcoin-core-dev
 136 2017-11-30T08:05:00  *** intcat has quit IRC
 137 2017-11-30T08:06:06  *** intcat has joined #bitcoin-core-dev
 138 2017-11-30T08:12:17  *** JackH has quit IRC
 139 2017-11-30T08:13:32  *** bule has quit IRC
 140 2017-11-30T08:22:15  *** Guyver2 has joined #bitcoin-core-dev
 141 2017-11-30T08:26:09  *** JackH has joined #bitcoin-core-dev
 142 2017-11-30T08:28:28  *** owowo has quit IRC
 143 2017-11-30T08:42:30  *** owowo has joined #bitcoin-core-dev
 144 2017-11-30T08:55:39  *** unholymachine has quit IRC
 145 2017-11-30T08:56:18  *** laurentmt has joined #bitcoin-core-dev
 146 2017-11-30T08:57:15  *** d9b4bef9 has quit IRC
 147 2017-11-30T08:57:31  *** unholymachine has joined #bitcoin-core-dev
 148 2017-11-30T08:58:22  *** d9b4bef9 has joined #bitcoin-core-dev
 149 2017-11-30T09:01:29  *** wxss has joined #bitcoin-core-dev
 150 2017-11-30T09:05:57  *** intcat has quit IRC
 151 2017-11-30T09:08:07  *** intcat has joined #bitcoin-core-dev
 152 2017-11-30T09:09:53  *** DvdKhl has quit IRC
 153 2017-11-30T09:16:24  *** Guyver2 has quit IRC
 154 2017-11-30T09:17:51  *** chjj has quit IRC
 155 2017-11-30T09:28:31  *** AaronvanW has joined #bitcoin-core-dev
 156 2017-11-30T09:29:18  *** Aaronvan_ has joined #bitcoin-core-dev
 157 2017-11-30T09:32:47  *** AaronvanW has quit IRC
 158 2017-11-30T09:38:12  *** Krellan has quit IRC
 159 2017-11-30T09:39:13  *** cdecker_ has joined #bitcoin-core-dev
 160 2017-11-30T09:39:36  *** unholymachine has quit IRC
 161 2017-11-30T09:39:36  *** cdecker has quit IRC
 162 2017-11-30T09:39:36  *** Masaomi[m] has quit IRC
 163 2017-11-30T09:39:37  *** nickler has quit IRC
 164 2017-11-30T09:39:37  *** _flow_ has quit IRC
 165 2017-11-30T09:39:38  *** berndj has quit IRC
 166 2017-11-30T09:39:38  *** cdecker_ is now known as cdecker
 167 2017-11-30T09:39:43  *** Krellan has joined #bitcoin-core-dev
 168 2017-11-30T09:39:48  *** [b__b] has quit IRC
 169 2017-11-30T09:39:55  *** nickler has joined #bitcoin-core-dev
 170 2017-11-30T09:40:04  *** unholymachine has joined #bitcoin-core-dev
 171 2017-11-30T09:40:05  *** [b__b] has joined #bitcoin-core-dev
 172 2017-11-30T09:40:48  *** meshcollider has quit IRC
 173 2017-11-30T09:41:47  *** berndj has joined #bitcoin-core-dev
 174 2017-11-30T09:42:29  *** _flow_ has joined #bitcoin-core-dev
 175 2017-11-30T09:42:52  *** Victorsueca has quit IRC
 176 2017-11-30T09:44:09  *** Victorsueca has joined #bitcoin-core-dev
 177 2017-11-30T09:45:45  *** Masaomi[m] has joined #bitcoin-core-dev
 178 2017-11-30T09:55:07  *** meshcollider has joined #bitcoin-core-dev
 179 2017-11-30T09:55:12  *** shesek has quit IRC
 180 2017-11-30T10:04:38  *** Ylbam has quit IRC
 181 2017-11-30T10:06:53  <bitcoin-git> [bitcoin] laanwj closed pull request #11793: Docs: Bump OS X version to 10.13 (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11793
 182 2017-11-30T10:08:30  *** dabura667 has quit IRC
 183 2017-11-30T10:09:49  *** lysobit_ has joined #bitcoin-core-dev
 184 2017-11-30T10:09:57  *** meshcollider has quit IRC
 185 2017-11-30T10:09:57  *** musalbas has quit IRC
 186 2017-11-30T10:09:57  *** qrestlove has quit IRC
 187 2017-11-30T10:09:57  *** windsok has quit IRC
 188 2017-11-30T10:09:59  *** Dyaheon has quit IRC
 189 2017-11-30T10:10:16  *** lysobit_ is now known as musalbas
 190 2017-11-30T10:12:11  *** intcat has quit IRC
 191 2017-11-30T10:12:27  *** Randolf has quit IRC
 192 2017-11-30T10:13:10  *** intcat has joined #bitcoin-core-dev
 193 2017-11-30T10:15:26  *** meshcollider has joined #bitcoin-core-dev
 194 2017-11-30T10:15:26  *** qrestlove has joined #bitcoin-core-dev
 195 2017-11-30T10:15:26  *** windsok has joined #bitcoin-core-dev
 196 2017-11-30T10:15:26  *** Dyaheon has joined #bitcoin-core-dev
 197 2017-11-30T10:20:48  *** Randolf has joined #bitcoin-core-dev
 198 2017-11-30T10:21:58  *** intcat has quit IRC
 199 2017-11-30T10:23:06  *** intcat has joined #bitcoin-core-dev
 200 2017-11-30T10:27:54  <aj> jnewbery: apparently github detects merge conflicts even when git merge and rebase both work fine, so i've split the preliminary changes from #11774 into #11796; hopefully 11796 can be easily merged once acked, since it shouldn't break any pending PRs
 201 2017-11-30T10:27:56  <gribble> https://github.com/bitcoin/bitcoin/issues/11774 | [WIP] [tests] Rename functional tests by ajtowns · Pull Request #11774 · bitcoin/bitcoin · GitHub
 202 2017-11-30T10:27:57  <gribble> https://github.com/bitcoin/bitcoin/issues/11796 | [tests] Functional test naming convention by ajtowns · Pull Request #11796 · bitcoin/bitcoin · GitHub
 203 2017-11-30T10:28:46  <wumpus> github is really sensitive with regard to merges, more than the stock git commands
 204 2017-11-30T10:29:08  <wumpus> might be so that at least no one blames them for merges going wrong
 205 2017-11-30T10:30:29  <aj> wumpus: yeah, it does make sense. bit weird not being able to tell quite what github thinks the conflict is though
 206 2017-11-30T10:30:33  <wumpus> at a company I used to work for the integration dept had a similar rule. Two changes affect the same file? let the devs sort it out
 207 2017-11-30T10:31:10  <wumpus> yeah it could use some better reporting
 208 2017-11-30T10:33:48  <wumpus> something I'd really like on github would be a graph of which open PRs collide with which other PRs
 209 2017-11-30T10:34:19  <wumpus> would help a lot in finding the optimal merge order, as well as notify authors early if their PR is going to need to be rebased
 210 2017-11-30T10:35:04  <sipa> that would be very useful
 211 2017-11-30T10:35:18  <sipa> n^2 complexity though in the number of PRs, i think
 212 2017-11-30T10:37:50  <wumpus> worst case, though the n^2 could be filtered by excluding PRs that affect completely distinct files
 213 2017-11-30T10:38:41  <wumpus> also one'd want to avoid recomputing the whole thing, just incrementally take opens/closes into account
 214 2017-11-30T10:40:02  <wumpus> (ugh, and PRs that are re-pushed)
 215 2017-11-30T10:40:46  <aj> that just makes it O(n) for each PR change though
 216 2017-11-30T10:41:19  <wumpus> which is reasonable, you can do it in the background, not at the time someone opens the graph
 217 2017-11-30T10:42:22  <aj> yeah, n isn't /that/ large
 218 2017-11-30T10:43:19  <wumpus> though yeah if github wants to do it for all projects it could get bad for them
 219 2017-11-30T10:43:42  <wumpus> I don't really care if it would be a paid-only feature or such
 220 2017-11-30T10:43:51  *** murchandamus has quit IRC
 221 2017-11-30T10:45:10  *** murchandamus has joined #bitcoin-core-dev
 222 2017-11-30T11:00:13  <wumpus> I've changed "Docs and output" label to just "Docs", it is only for documentation, for logging changes and such please use "Utils/logging/libs" instead.
 223 2017-11-30T11:00:53  *** fanquake has joined #bitcoin-core-dev
 224 2017-11-30T11:00:59  <wumpus> I think lumping everything output-related in one issue was a bit confusing
 225 2017-11-30T11:01:15  <wumpus> in one label*
 226 2017-11-30T11:02:19  *** Krellan has quit IRC
 227 2017-11-30T11:02:48  *** Krellan has joined #bitcoin-core-dev
 228 2017-11-30T11:02:51  *** JackH has quit IRC
 229 2017-11-30T11:05:28  *** gitju has joined #bitcoin-core-dev
 230 2017-11-30T11:05:42  *** gitju_ has joined #bitcoin-core-dev
 231 2017-11-30T11:07:01  *** Krellan has quit IRC
 232 2017-11-30T11:07:29  *** Krellan has joined #bitcoin-core-dev
 233 2017-11-30T11:08:59  *** unholymachine has quit IRC
 234 2017-11-30T11:09:52  *** Randolf has quit IRC
 235 2017-11-30T11:10:01  *** qrestlove has quit IRC
 236 2017-11-30T11:10:12  *** commavir has quit IRC
 237 2017-11-30T11:10:43  *** unholymachine has joined #bitcoin-core-dev
 238 2017-11-30T11:10:58  *** intcat has quit IRC
 239 2017-11-30T11:11:10  *** commavir has joined #bitcoin-core-dev
 240 2017-11-30T11:13:00  *** intcat has joined #bitcoin-core-dev
 241 2017-11-30T11:13:03  *** Emcy has quit IRC
 242 2017-11-30T11:14:09  *** kewde[m] has quit IRC
 243 2017-11-30T11:14:24  *** herzmeister[m] has quit IRC
 244 2017-11-30T11:14:24  *** Masaomi[m] has quit IRC
 245 2017-11-30T11:14:47  *** griswaalt[m] has quit IRC
 246 2017-11-30T11:15:03  *** qrestlove has joined #bitcoin-core-dev
 247 2017-11-30T11:16:56  *** gitju_ has quit IRC
 248 2017-11-30T11:17:50  *** Randolf has joined #bitcoin-core-dev
 249 2017-11-30T11:22:11  <aj> wumpus: had a quick play, and it seems like you can get somewhere with detecting PR conflicts using git locally. for xa in $tsts; do a=pull/origin/$xa; if (git reset --hard origin/master && git merge $a -m "merge $a to master") >/dev/null; then for xb in $tsts; do if [ "$xa" -ge "$xb" ]; then continue; fi; b=pull/origin/$xb; (git format-patch $(git merge-base $a $b)..$b --stdout | git apply --check
 250 2017-11-30T11:22:12  <aj> -) > APPLY_${xa}_${xb} 2>&1 && echo "no conflict between $xa $xb" || echo "merge conflict $xa $xb ?"; done; else echo "conflict with $a and master"; fi; done > CONFLICT
 251 2017-11-30T11:22:14  <aj> gah
 252 2017-11-30T11:22:42  <aj> wumpus: had a quick play, and it seems like you can get somewhere with detecting PR conflicts using git locally.  -- was what i was trying to say
 253 2017-11-30T11:22:53  <aj> wumpus: https://gist.github.com/ajtowns/d0cf97678dc83efdf3f6cbf7083a35a0 -- was what i was trying to paste
 254 2017-11-30T11:22:56  <wumpus> awesome!
 255 2017-11-30T11:24:10  <wumpus> pretty clever that you manage to avoid touching the working tree
 256 2017-11-30T11:24:42  <wumpus> but yes seems I won't get around to setting up a git tree that pulls all the PRs locally
 257 2017-11-30T11:25:45  <aj> wumpus: hmm? pulling all the PRs locally is easy and awesome though?
 258 2017-11-30T11:26:43  <wumpus> yeah no problem, just don't do it at the moment to avoid cluttering my tree further, I have 858 branches of my own at this point :)
 259 2017-11-30T11:27:09  <fanquake> git branch -D *
 260 2017-11-30T11:28:22  <aj> wumpus: the pull requests don't show up in git branch -av for me, so i don't even notice (actually, i don't even know how to get a list of them...)
 261 2017-11-30T11:28:53  <wumpus> fanquake: git branch -D doesn't take a pattern :-) you'd need something like git branch | xargs git branch -D
 262 2017-11-30T11:29:22  <wumpus> aj: interesting, I'd have expected them to show up
 263 2017-11-30T11:31:22  <wumpus> (I regularly do 'git branch --list 'pull/*' | xargs git branch -D' to get rid of the temporary branches left behind by github-merge.py in some cases)
 264 2017-11-30T11:31:54  <aj> ah, "git remote show origin" will at least give me a list of them
 265 2017-11-30T11:32:08  <wumpus> apart from that I use a single repository with worktrees for persistent branches like 0.15
 266 2017-11-30T11:33:02  <wumpus> anyhow it works pretty well, I think it will still work pretty will with 231 more branches; will have to find something to clean up closed PRs though
 267 2017-11-30T11:33:10  <aj> updated that gist with the compatible and conflicts graphs for a handful of recent PRs
 268 2017-11-30T11:33:38  <wumpus> or does that automatically remove removed branches at the gh side as well?
 269 2017-11-30T11:34:35  <wumpus> aj: oh wow
 270 2017-11-30T11:36:29  <aj> wumpus: the only thing i can think of to make it useful is dumping data into python to work out which collections of PRs have complete subgraphs of compatability
 271 2017-11-30T11:36:34  <wumpus> so a connection means a conflict? why do 11790 and 11741 conflict?
 272 2017-11-30T11:37:27  <wumpus> 11741 only changes two files, yet conflicts with 9 PRs or so
 273 2017-11-30T11:37:36  <wumpus> it's possible :)
 274 2017-11-30T11:38:35  *** BGL has quit IRC
 275 2017-11-30T11:40:44  <aj> yeah, they merge fine manually; git apply --check complains about multiwallet.py, rpc/rawtransaction.cpp and test/txvalidation_tests.cpp
 276 2017-11-30T11:41:53  <aj> ah, i'm trying to apply patches from master twice
 277 2017-11-30T11:41:54  <wumpus> but 11741 touches neither of those
 278 2017-11-30T11:42:26  <wumpus> hehe okay
 279 2017-11-30T11:45:33  <fanquake> nice
 280 2017-11-30T11:48:41  <wumpus> oope, so fetch = +refs/pull/*/head:refs/pull/origin/*  doesn't just fetch *open* pull requests
 281 2017-11-30T11:49:34  <wumpus> whee tracking 8288 branches now
 282 2017-11-30T11:49:52  <aj> https://gist.github.com/ajtowns/d0cf97678dc83efdf3f6cbf7083a35a0 -- conflict graph looks better now
 283 2017-11-30T11:50:08  <wumpus> happy I did it in a temporary repo :)
 284 2017-11-30T11:52:04  <wumpus> aj: great
 285 2017-11-30T11:56:44  <Varunram> aj: thanks for the gist :)
 286 2017-11-30T11:58:14  <aj> probably needs to work out which PR branched off from master most recently and use that as a base
 287 2017-11-30T12:06:58  *** intcat has quit IRC
 288 2017-11-30T12:08:09  *** intcat has joined #bitcoin-core-dev
 289 2017-11-30T12:17:58  *** intcat has quit IRC
 290 2017-11-30T12:20:48  *** meshcollider has quit IRC
 291 2017-11-30T12:22:59  *** intcat has joined #bitcoin-core-dev
 292 2017-11-30T12:25:09  *** griswaalt[m] has joined #bitcoin-core-dev
 293 2017-11-30T12:29:25  *** SopaXorzTaker has joined #bitcoin-core-dev
 294 2017-11-30T12:34:32  *** kewde[m] has joined #bitcoin-core-dev
 295 2017-11-30T12:34:32  *** herzmeister[m] has joined #bitcoin-core-dev
 296 2017-11-30T12:34:33  *** Masaomi[m] has joined #bitcoin-core-dev
 297 2017-11-30T12:41:06  *** BGL has joined #bitcoin-core-dev
 298 2017-11-30T12:42:12  *** Victorsueca has quit IRC
 299 2017-11-30T12:43:19  *** d9b4bef9 has quit IRC
 300 2017-11-30T12:43:24  *** Victorsueca has joined #bitcoin-core-dev
 301 2017-11-30T12:44:02  *** niska has quit IRC
 302 2017-11-30T12:44:27  *** d9b4bef9 has joined #bitcoin-core-dev
 303 2017-11-30T12:46:26  *** d9b4bef9 has joined #bitcoin-core-dev
 304 2017-11-30T12:50:20  *** intcat has quit IRC
 305 2017-11-30T12:52:30  *** Emcy has joined #bitcoin-core-dev
 306 2017-11-30T12:54:28  *** niska has joined #bitcoin-core-dev
 307 2017-11-30T12:55:29  *** intcat has joined #bitcoin-core-dev
 308 2017-11-30T13:14:57  *** intcat has quit IRC
 309 2017-11-30T13:15:45  *** intcat has joined #bitcoin-core-dev
 310 2017-11-30T13:21:30  *** Krellan has quit IRC
 311 2017-11-30T13:22:55  *** Krellan has joined #bitcoin-core-dev
 312 2017-11-30T13:28:18  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 313 2017-11-30T13:34:26  *** frostbyte1982 has quit IRC
 314 2017-11-30T13:41:15  *** Emcy has quit IRC
 315 2017-11-30T13:48:25  *** promag has joined #bitcoin-core-dev
 316 2017-11-30T13:48:27  *** fanquake has quit IRC
 317 2017-11-30T13:57:09  *** zxsanny has joined #bitcoin-core-dev
 318 2017-11-30T14:00:02  *** jack__ has joined #bitcoin-core-dev
 319 2017-11-30T14:01:17  *** zxsanny has quit IRC
 320 2017-11-30T14:07:41  *** Chris_Stewart_5 has quit IRC
 321 2017-11-30T14:19:13  *** wordsToLiveBy has joined #bitcoin-core-dev
 322 2017-11-30T14:19:30  <wordsToLiveBy> I'm reading the bitcoin white paper, and in section 11 Satoshi gives the calculations for how you can prove with probability that an attacker can't outpace the combined processing power of the rest of the nodes, but I am not quite getting the math being used.
 323 2017-11-30T14:19:34  *** wordsToLiveBy has quit IRC
 324 2017-11-30T14:25:00  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 325 2017-11-30T14:26:35  *** Victorsueca has quit IRC
 326 2017-11-30T14:27:54  *** Victorsueca has joined #bitcoin-core-dev
 327 2017-11-30T14:31:15  *** goatpig has joined #bitcoin-core-dev
 328 2017-11-30T14:38:52  *** SopaXorzTaker has quit IRC
 329 2017-11-30T14:39:38  *** arubi has quit IRC
 330 2017-11-30T14:40:01  *** arubi has joined #bitcoin-core-dev
 331 2017-11-30T14:42:07  *** Chris_Stewart_5 has quit IRC
 332 2017-11-30T14:43:49  *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
 333 2017-11-30T14:43:49  *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
 334 2017-11-30T14:55:40  <andytoshi> #bitcoin please, this is just about software development
 335 2017-11-30T14:55:52  *** Giszmo has quit IRC
 336 2017-11-30T15:04:21  *** Giszmo has joined #bitcoin-core-dev
 337 2017-11-30T15:08:18  <jnewbery> aj: thanks. I've reviewed #11796. It should be an easy review/merge for others.
 338 2017-11-30T15:08:19  <gribble> https://github.com/bitcoin/bitcoin/issues/11796 | [tests] Functional test naming convention by ajtowns · Pull Request #11796 · bitcoin/bitcoin · GitHub
 339 2017-11-30T15:21:11  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 340 2017-11-30T15:24:08  *** saint_ has joined #bitcoin-core-dev
 341 2017-11-30T15:24:57  <aj> jnewbery: ugh, what sort of person points out a bug and says not to fix it /o\
 342 2017-11-30T15:27:02  <saint_> any idea why can't bitcoin core download the blockchain on a remote NAS drive ?
 343 2017-11-30T15:27:19  <wumpus> saint_: ask in #bitcoin please, will answer there
 344 2017-11-30T15:27:23  <saint_> okay
 345 2017-11-30T15:28:10  *** Krellan has quit IRC
 346 2017-11-30T15:29:23  *** Krellan has joined #bitcoin-core-dev
 347 2017-11-30T15:40:47  *** arubi has quit IRC
 348 2017-11-30T15:41:07  *** arubi has joined #bitcoin-core-dev
 349 2017-11-30T15:43:34  *** owowo has quit IRC
 350 2017-11-30T15:48:14  *** owowo has joined #bitcoin-core-dev
 351 2017-11-30T15:49:01  *** ghost43 has quit IRC
 352 2017-11-30T15:49:28  *** Emcy has joined #bitcoin-core-dev
 353 2017-11-30T15:49:44  *** Emcy has quit IRC
 354 2017-11-30T15:49:44  *** Emcy has joined #bitcoin-core-dev
 355 2017-11-30T15:51:33  *** jtimon has joined #bitcoin-core-dev
 356 2017-11-30T16:02:15  *** Emcy has quit IRC
 357 2017-11-30T16:03:08  *** ghost43 has joined #bitcoin-core-dev
 358 2017-11-30T16:03:10  *** Emcy has joined #bitcoin-core-dev
 359 2017-11-30T16:06:42  *** Murch has joined #bitcoin-core-dev
 360 2017-11-30T16:08:14  *** Emcy has quit IRC
 361 2017-11-30T16:11:32  *** Emcy has joined #bitcoin-core-dev
 362 2017-11-30T16:12:03  *** Emcy has quit IRC
 363 2017-11-30T16:12:31  *** Emcy has joined #bitcoin-core-dev
 364 2017-11-30T16:12:42  *** dqx has joined #bitcoin-core-dev
 365 2017-11-30T16:16:02  <jnewbery> aj: I wanted to get in before someone else pointed it out and told you to fix it :)
 366 2017-11-30T16:16:12  <jnewbery> I don't think it matters since the next PR should remove that code anyway
 367 2017-11-30T16:25:08  *** Emcy_ has joined #bitcoin-core-dev
 368 2017-11-30T16:25:38  *** Emcy has quit IRC
 369 2017-11-30T16:25:47  *** DvdKhl has joined #bitcoin-core-dev
 370 2017-11-30T16:30:25  *** dqx has quit IRC
 371 2017-11-30T16:41:26  *** alreadylate has joined #bitcoin-core-dev
 372 2017-11-30T16:44:50  *** Victorsueca has quit IRC
 373 2017-11-30T16:46:10  *** Victorsueca has joined #bitcoin-core-dev
 374 2017-11-30T16:46:28  *** Vimalraj has joined #bitcoin-core-dev
 375 2017-11-30T16:52:28  *** promag has quit IRC
 376 2017-11-30T16:52:40  *** Vimalraj has quit IRC
 377 2017-11-30T16:53:51  *** quantbot_ has quit IRC
 378 2017-11-30T16:54:18  *** quantbot has joined #bitcoin-core-dev
 379 2017-11-30T16:55:49  *** Randolf has quit IRC
 380 2017-11-30T17:02:37  *** quantbot_ has joined #bitcoin-core-dev
 381 2017-11-30T17:03:35  *** Murch has quit IRC
 382 2017-11-30T17:03:57  *** quantbot has quit IRC
 383 2017-11-30T17:09:53  *** esotericnonsense has quit IRC
 384 2017-11-30T17:10:45  *** esotericnonsense has joined #bitcoin-core-dev
 385 2017-11-30T17:10:50  *** Murch has joined #bitcoin-core-dev
 386 2017-11-30T17:11:01  *** ula has joined #bitcoin-core-dev
 387 2017-11-30T17:21:51  *** Randolf has joined #bitcoin-core-dev
 388 2017-11-30T17:22:58  *** Dizzle has joined #bitcoin-core-dev
 389 2017-11-30T17:24:15  *** laurentmt has quit IRC
 390 2017-11-30T17:25:36  <achow101> is the github git notifier dead?
 391 2017-11-30T17:26:38  *** anon has joined #bitcoin-core-dev
 392 2017-11-30T17:27:01  *** anon is now known as Guest18586
 393 2017-11-30T17:32:15  *** lvmbdv has quit IRC
 394 2017-11-30T17:35:37  *** Krellan has quit IRC
 395 2017-11-30T17:35:52  *** alreadylate has quit IRC
 396 2017-11-30T17:36:34  *** bule has joined #bitcoin-core-dev
 397 2017-11-30T17:37:13  *** BashCo has quit IRC
 398 2017-11-30T17:37:18  *** Krellan has joined #bitcoin-core-dev
 399 2017-11-30T17:48:53  *** esotericnonsense has quit IRC
 400 2017-11-30T17:51:13  *** esotericnonsense has joined #bitcoin-core-dev
 401 2017-11-30T17:51:50  *** bule2 has joined #bitcoin-core-dev
 402 2017-11-30T17:53:48  <wumpus> achow101: intermittently, yes
 403 2017-11-30T17:54:01  <wumpus> achow101: it seems incredibly unreliable
 404 2017-11-30T17:54:52  *** bule has quit IRC
 405 2017-11-30T18:01:14  *** kexkey has joined #bitcoin-core-dev
 406 2017-11-30T18:02:18  *** BashCo has joined #bitcoin-core-dev
 407 2017-11-30T18:09:53  *** Giszmo has quit IRC
 408 2017-11-30T18:13:57  *** esotericnonsense has quit IRC
 409 2017-11-30T18:27:24  *** Giszmo has joined #bitcoin-core-dev
 410 2017-11-30T18:27:42  *** esotericnonsense has joined #bitcoin-core-dev
 411 2017-11-30T18:39:52  *** ajtowns[m] has joined #bitcoin-core-dev
 412 2017-11-30T18:40:59  <jonasschnelli> I wonder how the Twitter commit feed works... I expect them polling
 413 2017-11-30T18:42:33  <wumpus> I think it must be; it isn't a webhook that we set up
 414 2017-11-30T18:43:08  <wumpus> we only have a slack webhook, and the IRC integration
 415 2017-11-30T18:43:16  *** timothy has quit IRC
 416 2017-11-30T18:43:55  *** ExtraCrispy has joined #bitcoin-core-dev
 417 2017-11-30T18:52:21  <wumpus> so having ruled out that it listens on IRC, it must either be listening on slack or polling
 418 2017-11-30T18:52:39  <wumpus> not sure whether the slack notiifications do go through
 419 2017-11-30T18:53:59  *** nanomouse has joined #bitcoin-core-dev
 420 2017-11-30T18:54:49  <wumpus> if the normal webhook works we could set up our own IRC bot
 421 2017-11-30T18:56:56  <jonasschnelli> wumpus: slack works...
 422 2017-11-30T18:57:26  *** meshcollider has joined #bitcoin-core-dev
 423 2017-11-30T18:57:32  <wumpus> jonasschnelli: great, so we isolated it to a problem with their IRC bot, not their notifications in general
 424 2017-11-30T18:57:44  <instagibbs> meeting in 3?
 425 2017-11-30T18:57:46  <instagibbs> or am i off
 426 2017-11-30T18:57:46  <jonasschnelli> Looks like
 427 2017-11-30T18:58:25  <wumpus> you're right
 428 2017-11-30T18:59:24  <wumpus> if the bot stays flaky like this tomorrow I'll contact github support, it's already been for a few days
 429 2017-11-30T19:00:03  <wumpus> #startmeeting
 430 2017-11-30T19:00:03  <lightningbot> Meeting started Thu Nov 30 19:00:03 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 431 2017-11-30T19:00:03  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
 432 2017-11-30T19:00:23  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag
 433 2017-11-30T19:00:32  <cfields> hi
 434 2017-11-30T19:00:35  <sipa> hi
 435 2017-11-30T19:00:36  <CodeShark> hello
 436 2017-11-30T19:00:44  <achow101> hi
 437 2017-11-30T19:00:46  <Provoostenator> hi
 438 2017-11-30T19:00:51  <instagibbs> hi
 439 2017-11-30T19:00:55  <jonasschnelli> hi
 440 2017-11-30T19:00:59  <wumpus> #topic high priority for review
 441 2017-11-30T19:01:01  <meshcollider> hi
 442 2017-11-30T19:01:16  <luke-jr> hi
 443 2017-11-30T19:01:20  <wumpus> 8 PRs have been tagged for https://github.com/bitcoin/bitcoin/projects/8
 444 2017-11-30T19:01:39  <BlueMatt> why does cfields have 2?
 445 2017-11-30T19:01:44  <wumpus> I added cfields's BanMan last week as it's blocking his further net refactoring
 446 2017-11-30T19:01:59  <cfields> BlueMatt: wasn't me, but i'll take it :)
 447 2017-11-30T19:02:06  <wumpus> ohh is it unfair?
 448 2017-11-30T19:02:09  * jonasschnelli also have two :|
 449 2017-11-30T19:02:18  <instagibbs> achow101, i see you rebased yours? we shooting for post-0.16?
 450 2017-11-30T19:02:21  <BlueMatt> i think we try to have only one per person
 451 2017-11-30T19:02:24  <jtimon> hi
 452 2017-11-30T19:02:34  <BlueMatt> well i suggested we include jonasschnelli's other one as its kinda a segwit-wallet-blocker imo
 453 2017-11-30T19:02:38  <BlueMatt> or at least in-same-release
 454 2017-11-30T19:02:42  <achow101> instagibbs: I'm shooting for 0.16
 455 2017-11-30T19:02:47  <achow101> but it may not make it
 456 2017-11-30T19:03:04  <instagibbs> ok, I can give it more love, though I think I've given a lot already, probably needs others....
 457 2017-11-30T19:03:17  *** karelb has joined #bitcoin-core-dev
 458 2017-11-30T19:03:21  <achow101> still some segwit related things to do and runn1ng wants simulations
 459 2017-11-30T19:03:31  <achow101> also been busy with exams and classwork
 460 2017-11-30T19:03:37  <wumpus> well, good solution for that, review and merge one of cfields's PRs and there will be only one left :)
 461 2017-11-30T19:03:44  <karelb> achow101: I came just in time :) yes I wanted some simulations
 462 2017-11-30T19:03:51  <jonasschnelli> wumpus: heh
 463 2017-11-30T19:03:57  <sipa> so i think we're maybe unintentionally moving from a "we release regularly with whatever is finished" to "X is a blocker for release Y"
 464 2017-11-30T19:04:10  <BlueMatt> oh, wait, i dont have one...hmmmm, I'd say #10279
 465 2017-11-30T19:04:13  <wumpus> sipa: segwit is the only exception to that
 466 2017-11-30T19:04:14  <cfields> i have no problem with removing one of mine if it's an issue. But yes, I think 11363 is ready/easy to review
 467 2017-11-30T19:04:15  <gribble> https://github.com/bitcoin/bitcoin/issues/10279 | Add a CChainState class to validation.cpp to take another step towards clarifying internal interfaces by TheBlueMatt · Pull Request #10279 · bitcoin/bitcoin · GitHub
 468 2017-11-30T19:04:23  <BlueMatt> sipa: I think we'll go back to that post-segwit-wallet, no?
 469 2017-11-30T19:04:25  <wumpus> sipa: for the rest, releases are only ever blocked on bugfixes not features
 470 2017-11-30T19:04:29  <achow101> sipa: I think 0.16 is the exception? because segwit wallet
 471 2017-11-30T19:04:35  <wumpus> yes
 472 2017-11-30T19:04:36  <jtimon> sipa: what is the blocker for 0.16 ?
 473 2017-11-30T19:04:41  <sipa> okay, that's fine - i'm not saying it's a bad thing
 474 2017-11-30T19:04:50  <instagibbs> i think it's openly acknowledged
 475 2017-11-30T19:04:55  <wumpus> and segwit wallet is not intended as a *blocker* for 0.16
 476 2017-11-30T19:04:59  *** SopaXorzTaker has joined #bitcoin-core-dev
 477 2017-11-30T19:05:07  <wumpus> we intend to release 0.16 early after that's in
 478 2017-11-30T19:05:13  <wumpus> so it's more like a trigger
 479 2017-11-30T19:05:13  <sipa> fair enough
 480 2017-11-30T19:05:20  <sipa> but it still changes prioritization a bit
 481 2017-11-30T19:05:28  <BlueMatt> indeed
 482 2017-11-30T19:05:32  <instagibbs> i think the segwit pr is shaping up nicely at least
 483 2017-11-30T19:05:34  <wumpus> if segwit wallet takes longer than the 0.16 release window, then IMO we should release 0.16 without it
 484 2017-11-30T19:05:43  <wumpus> but I don't expect that
 485 2017-11-30T19:05:48  <BlueMatt> wumpus: agreed
 486 2017-11-30T19:06:09  <jtimon> oh, I see, we want to release 0.16 soon after segwit wallet gets in
 487 2017-11-30T19:06:14  <wumpus> jtimon: yep
 488 2017-11-30T19:06:26  <sipa> i'm about to push some review fixes to #11403
 489 2017-11-30T19:06:30  <gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
 490 2017-11-30T19:06:31  <wumpus> jtimon: seems more advisable than trying to backport the whole lot + dependencies to 0.15
 491 2017-11-30T19:06:34  <cfields> sipa: not sure if you've clarified somewhere, do you consider all of the listed TODOs in 11403 blockers for release as well?
 492 2017-11-30T19:06:53  <jtimon> wumpus: yeah, I think I suggested that, eithe way it makes sense to me
 493 2017-11-30T19:07:18  <wumpus> jtimon: thanks in that case :)
 494 2017-11-30T19:07:26  <luke-jr> branch 0.15 into 0.16 ;)
 495 2017-11-30T19:07:32  <sipa> cfields: yes
 496 2017-11-30T19:07:48  <cfields> ok, thanks
 497 2017-11-30T19:08:03  <gmaxwell> So, segwit-wallet is done?
 498 2017-11-30T19:08:15  <jtimon> I'm not following review on the segwit wallet pr, how is it going?
 499 2017-11-30T19:08:31  <sipa> i think #11403 is pretty much done - just nits in command line option handling and output
 500 2017-11-30T19:08:34  <gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
 501 2017-11-30T19:08:45  <jtimon> great
 502 2017-11-30T19:08:55  <achow101> I tried reviewing it but it's big and scary
 503 2017-11-30T19:09:10  <wumpus> awesome
 504 2017-11-30T19:09:23  <sipa> we may want to discuss what to do with things like how dumpprivkey and signmessage should work in a post-segwit world
 505 2017-11-30T19:09:29  * Randolf congratulates achow101 for trying
 506 2017-11-30T19:09:30  <cfields> i found it reasonable review on a per-commit basis
 507 2017-11-30T19:09:37  <instagibbs> cfields, same
 508 2017-11-30T19:09:40  <sipa> as i believe some projects have come up with formats on their own
 509 2017-11-30T19:09:41  <cfields> *to review
 510 2017-11-30T19:09:55  <achow101> sipa: trezor has implemented their own segwit message signing thing
 511 2017-11-30T19:09:59  <jtimon> I guess I need tofix the nits in #8994 and #10757 if I want them to have a chance to get merged before 0.16 then
 512 2017-11-30T19:10:02  <gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
 513 2017-11-30T19:10:03  <achow101> I think that might be the only one though
 514 2017-11-30T19:10:07  <gribble> https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub
 515 2017-11-30T19:10:22  <sipa> achow101: perhaps we can just adopt that
 516 2017-11-30T19:10:25  <jtimon> what are we referring to by "soon after"?
 517 2017-11-30T19:10:30  <wumpus> sipa: well if other project's import/export formats make sense, it'd be good to use them for interchangeability
 518 2017-11-30T19:10:45  <achow101> sipa: I don't think it's documented anywhere though
 519 2017-11-30T19:10:48  <meshcollider> Should there be a BIP to formalise it
 520 2017-11-30T19:10:48  <achow101> at least not yet
 521 2017-11-30T19:10:52  <Provoostenator> Is there a good standard for message signing?
 522 2017-11-30T19:10:53  <sipa> longer term i think a script-based signing would nice, but i don't think we're ready to adopt something like that
 523 2017-11-30T19:10:59  <gmaxwell> I thought they did but backed it out because it wasn't standardized yet. What they did didn't seem to awful, though I feel a little uneasy about the mutability between keytypes.
 524 2017-11-30T19:11:00  <karelb> sipa: ad sign message - in trezor we changed v constant - https://github.com/bitcoin/bitcoin/issues/10542#issuecomment-316032523 - no BIP, no time :(
 525 2017-11-30T19:11:13  <sipa> karelb: ok, i'll have a look
 526 2017-11-30T19:11:22  <sipa> the original bitcoin core message signing doesn't have a bip either
 527 2017-11-30T19:11:33  <luke-jr> Provoostenator: no
 528 2017-11-30T19:11:40  <wumpus> a BIP is not a requirement for us implementing it, though in parallel it'd be nice
 529 2017-11-30T19:11:43  <BlueMatt> sipa: it probably should if we change it, though
 530 2017-11-30T19:11:45  <achow101> sipa: perhaps it should? retcon one :p
 531 2017-11-30T19:11:56  <sipa> seems reasonable
 532 2017-11-30T19:11:57  <wumpus> good to already have implementations and the BIP just formalizes it
 533 2017-11-30T19:12:08  <gmaxwell> Well, signmessage is generally not very good; but fixing it should be a longer term thing.
 534 2017-11-30T19:12:09  <Provoostenator> I vaguely remember trying to implement / refactor signing and being not amused by the lack of a standard.
 535 2017-11-30T19:12:16  <luke-jr> current signed messages get very little real use, and most "usage" is based on misconceptions
 536 2017-11-30T19:12:23  <karelb> sipa yes good point. I wanted to write up a document that describes both current and segwit message signing, but I got stuck on how ecdsa signing actually works :)
 537 2017-11-30T19:12:24  <wumpus> luke-jr: agree
 538 2017-11-30T19:12:26  <luke-jr> IMO it'd make sense to just deprecate it until a better replacement is made
 539 2017-11-30T19:12:29  <wumpus> luke-jr: it's not a priority at least
 540 2017-11-30T19:12:33  <instagibbs> luke-jr, it's used for airdrops :P
 541 2017-11-30T19:12:40  <sipa> luke-jr: i agree it's not all that useful
 542 2017-11-30T19:12:44  <Provoostenator> Can it be made coin-agnostic as well?
 543 2017-11-30T19:12:48  <wumpus> certainly shouldn't be a blocker for 0.16
 544 2017-11-30T19:12:50  <luke-jr> instagibbs: that's a misuse, since it doesn't prove you have funds ;)
 545 2017-11-30T19:12:51  <gmaxwell> Provoostenator: no.
 546 2017-11-30T19:13:09  <karelb> we didn't have segwit message signing in web wallet, but users repeatedly demanded it
 547 2017-11-30T19:13:12  <instagibbs> luke-jr, but i profit from it, how can it be misuse ;P
 548 2017-11-30T19:13:19  <instagibbs> +1 tho
 549 2017-11-30T19:13:21  *** ExtraCrispy has quit IRC
 550 2017-11-30T19:13:21  <gmaxwell> The fact that it's inherently incompatible with multisig is a real bummer.
 551 2017-11-30T19:13:22  <luke-jr> karelb: for what, though?
 552 2017-11-30T19:13:27  <achow101> instagibbs: lol
 553 2017-11-30T19:13:31  <gmaxwell> luke-jr: airdrops
 554 2017-11-30T19:13:35  <luke-jr> XD
 555 2017-11-30T19:13:49  <wumpus> using bitcoin keys for anything else than signing transactions continues to make me uneasy
 556 2017-11-30T19:13:50  <jtimon> yeah, +1 to move to signing messages based on scripts
 557 2017-11-30T19:14:09  <luke-jr> MAST-based signmessage would be a sensible replacement
 558 2017-11-30T19:14:14  <Provoostenator> jtimon: what would that look like?
 559 2017-11-30T19:14:44  <wumpus> do hardware wallets even support it?
 560 2017-11-30T19:14:51  <luke-jr> Provoostenator: you could have a MAST if-branch that is always false for transactions, and then true for meta uses
 561 2017-11-30T19:14:53  <gmaxwell> wumpus: If I were to it again, I'd make signmessage work by just creating a transaction which is inherently unminable. It would make it a lot more compatible, though somewhat larger.
 562 2017-11-30T19:14:53  <CodeShark> gmaxwell: a general solution for airdrops seems extremely difficult
 563 2017-11-30T19:15:29  <jtimon> Provoostenator: like we sign txs but signing any message, in elements we sign blocks so perhaps you want to take a look (since there's generic functions to sign stuff, but they're not exposed and only used for blocks)
 564 2017-11-30T19:15:30  <gmaxwell> In elements sipa wrote a patch for a script based signmessage; but we ran into ... challenges.. with how softforks would be handled.
 565 2017-11-30T19:15:48  *** nanymouse has joined #bitcoin-core-dev
 566 2017-11-30T19:15:50  <wumpus> gmaxwell: that'd have been better; at least the keys would only be used to sign things in one format
 567 2017-11-30T19:15:56  <gmaxwell> Segwit script versioning would fix those challenges.
 568 2017-11-30T19:15:57  <CodeShark> yes, two chains might have very different redemption conditions for the same utxo
 569 2017-11-30T19:16:00  *** nanomouse has quit IRC
 570 2017-11-30T19:16:02  <Provoostenator> Hah, so you can do multisig messages? :-)
 571 2017-11-30T19:16:07  <sipa> Provoostenator: yes
 572 2017-11-30T19:16:15  <sipa> Provoostenator: and timelocked signatures :p
 573 2017-11-30T19:16:16  <Provoostenator> Or even partial messages?
 574 2017-11-30T19:16:20  <jtimon> gmaxwell: I think they should be handled with flags
 575 2017-11-30T19:16:43  <sipa> jtimon: yes, but the general property of softforks doesn't apply
 576 2017-11-30T19:16:45  <jtimon> oh, right, script versioning solves it too
 577 2017-11-30T19:16:56  <sipa> you don't want a "oh, i don't know this signature version! it's valid!!"
 578 2017-11-30T19:17:01  <gmaxwell> jtimon: the 'pubkey' needs to commit to the rules. pre-segwit style softforks don't.
 579 2017-11-30T19:17:16  <gmaxwell> Well you can tristate:  Valid, invalid, unknown public key version.
 580 2017-11-30T19:17:48  <wumpus> right
 581 2017-11-30T19:17:50  <luke-jr> sipa: that's a risk for txs too, though
 582 2017-11-30T19:17:54  <jtimon> sipa: sure, I mean, this is out of the blockchain, so you just need to know which flags to use when validating...what gmaxwell said, commit to the rules
 583 2017-11-30T19:18:06  <gmaxwell> prior to having the explicit versions we couldn't do that, which is why we never even merged the patch in elements, much less brought it to bitcoin.
 584 2017-11-30T19:18:07  <luke-jr> why sighash flags can't fail valid
 585 2017-11-30T19:18:24  <gmaxwell> luke-jr: attacker controls signature side flags.
 586 2017-11-30T19:18:29  *** nanymouse has quit IRC
 587 2017-11-30T19:18:32  <luke-jr> gmaxwell: right, that's my point
 588 2017-11-30T19:18:49  *** nanymouse has joined #bitcoin-core-dev
 589 2017-11-30T19:19:15  <gmaxwell> same reason sighash flags can fail valid in bitcoin: If I pick an out of range sighash flag I could forge signatures for your pubkeys.
 590 2017-11-30T19:19:38  <sipa> ?
 591 2017-11-30T19:20:24  <CodeShark> I also don't follow
 592 2017-11-30T19:20:32  *** Krellan has quit IRC
 593 2017-11-30T19:20:49  <luke-jr> [19:16:56] <sipa> you don't want a "oh, i don't know this signature version! it's valid‼" <-- this is a problem for transactions just as much as for signed messages
 594 2017-11-30T19:20:50  <wumpus> are there any topics we really want to discuss in this meeting? I think we're drifting off a bit
 595 2017-11-30T19:21:00  <gmaxwell> You cannot trigger "unknown behavior, I'll let it pass" based on sighash flags like you can based on the content of public keys.
 596 2017-11-30T19:21:06  <cfields> next (quick) topic suggestion: codesigning keys update
 597 2017-11-30T19:21:07  <jnewbery> Other PRs I'd love to see merged for v0.16 are #10583 #10579 #11415 . They're all removing wallet dependencies from server, but are API changes so have a one release deprecation lag time before the dependency can actually be removed.
 598 2017-11-30T19:21:10  <gribble> https://github.com/bitcoin/bitcoin/issues/10583 | [RPC] Split part of validateaddress into getaddressinfo by achow101 · Pull Request #10583 · bitcoin/bitcoin · GitHub
 599 2017-11-30T19:21:14  <gribble> https://github.com/bitcoin/bitcoin/issues/10579 | [RPC] Split signrawtransaction into wallet and non-wallet RPC command by achow101 · Pull Request #10579 · bitcoin/bitcoin · GitHub
 600 2017-11-30T19:21:17  <gribble> https://github.com/bitcoin/bitcoin/issues/11415 | [RPC] Disallow using addresses in createmultisig by achow101 · Pull Request #11415 · bitcoin/bitcoin · GitHub
 601 2017-11-30T19:21:18  <jtimon> yeah, how about what "shortly after" means for 0.16 ?
 602 2017-11-30T19:21:24  <jonasschnelli> Two topic proposals: 1) review "nits" reduction, 2) bitcoin core code signing assoc.
 603 2017-11-30T19:21:39  <jonasschnelli> 2) goes in hand with cfields topicp.
 604 2017-11-30T19:22:07  <wumpus> jnewbery: thanks, I think adding all of them to high priority is a bit much, but we could add one
 605 2017-11-30T19:22:09  <wumpus> #topic codesigning
 606 2017-11-30T19:22:17  <cfields> I just wanted to point out that after researching for a bit, there's no painless way to renew our osx cert (without involving the btcf), so I think it's prudent that we explore other options.
 607 2017-11-30T19:22:22  * cfields passes the mic to jonasschnelli
 608 2017-11-30T19:22:28  <jonasschnelli> https://github.com/bitcoincore-codesigning-association
 609 2017-11-30T19:22:44  <achow101> wumpus: it seems like some of those are ready to be merged. they have utACKs and no comments left
 610 2017-11-30T19:22:45  <jonasschnelli> https://bitcoincorecodesigning.org
 611 2017-11-30T19:22:45  <jonasschnelli> The association stands and apple has accepted the entity
 612 2017-11-30T19:22:57  <jonasschnelli> Code sining certificates are ready (need to setup the key)
 613 2017-11-30T19:23:12  <cfields> jonasschnelli: oh that's fantastic! nice work :)
 614 2017-11-30T19:23:15  <wumpus> achow101: if they're ready for merge even better, please notify me of those things outside the meeting
 615 2017-11-30T19:23:16  <jnewbery> wumpus: thanks. I think they're all pretty much ready for merge. achow101 has been doing a great job maintaining and rebasing them - perhaps just a bit more ACKing and they can go in
 616 2017-11-30T19:23:47  <jonasschnelli> We need a windows code signing cert... have never done that but I'm ready to order if someone gives instructions where and how
 617 2017-11-30T19:24:00  <wumpus> PSA: if something is ready for merge just let me know here instead of waiting for me to stumble on it accidentally :)
 618 2017-11-30T19:24:17  <BlueMatt> jnewbery: afaict only maybe the last is ready? the second only has one ack?
 619 2017-11-30T19:24:22  <achow101> wumpus: ok!
 620 2017-11-30T19:24:25  <BlueMatt> jonasschnelli: that was fast!
 621 2017-11-30T19:24:36  <wumpus> jonasschnelli: oh great!
 622 2017-11-30T19:24:37  <achow101> jonasschnelli: https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/get-a-code-signing-certificate
 623 2017-11-30T19:25:15  <cfields> achow101: note that a driver cert is different. More requirements.
 624 2017-11-30T19:25:28  <wumpus> getting a driver cert is much more difficult
 625 2017-11-30T19:25:42  <achow101> oh, didn't see that that was for drivers
 626 2017-11-30T19:25:47  <wumpus> I guess it should be, with the privilege level it operates at
 627 2017-11-30T19:26:01  <jonasschnelli> The question is if we want to try that distributed RSA key
 628 2017-11-30T19:26:09  <wumpus> we do
 629 2017-11-30T19:26:26  <BlueMatt> gmaxwell: mic?
 630 2017-11-30T19:26:48  <BlueMatt> or who was it who said they were gonna look into hooking it into a reasonable way to use it?
 631 2017-11-30T19:26:54  <cfields> I'll work on the CSR handling as promised. I assume we'll just have to shove the result back into the expected format.
 632 2017-11-30T19:27:21  <gmaxwell> I didn't think we were going to bother to do it for the first one. but this is going faster than expected! :)
 633 2017-11-30T19:27:22  <jonasschnelli> cfields: Yeah. Apple needs that -----BEGIN CERTIFICATE REQUEST-----
 634 2017-11-30T19:27:23  <achow101> BlueMatt: that was gmaxwell. I also wanted to take a look at it. it looked painful
 635 2017-11-30T19:27:58  <gmaxwell> it's not so painful but we need a process for converting raw RSA numbers into csrs and what not, which cfields was going to look into.
 636 2017-11-30T19:28:30  <gmaxwell> The easiest thing to do may be to just do trusted setup: generate the key normally on an offline machine, and we can split it after the the fact.
 637 2017-11-30T19:28:48  <BlueMatt> ugh
 638 2017-11-30T19:28:50  <gmaxwell> the MPC signing is radically simple and faster than MPC key generation.
 639 2017-11-30T19:29:01  <BlueMatt> i thought the mpc generation was implemented?
 640 2017-11-30T19:29:08  <gmaxwell> Though the stuff I linked to does both. (though it's setup for only three parties atm)
 641 2017-11-30T19:29:17  <BlueMatt> i mean thats probably fine?
 642 2017-11-30T19:29:22  <BlueMatt> 3/3, I assume?
 643 2017-11-30T19:29:22  <achow101> gmaxwell: can it be done faster than what is already implemented?
 644 2017-11-30T19:29:35  <gmaxwell> achow101: of course, but do we care if it takes hours?
 645 2017-11-30T19:30:12  <wumpus> if it's a one-time thing we don't
 646 2017-11-30T19:30:15  <cfields> jonasschnelli: let's talk after the meeting. It'd be great if we could get a dummy to test with.
 647 2017-11-30T19:30:16  *** laurentmt has joined #bitcoin-core-dev
 648 2017-11-30T19:30:19  <gmaxwell> BlueMatt: yes 3/3. Generation you'd always do as n/n then potentially reshare to a different threshold.
 649 2017-11-30T19:30:25  <jonasschnelli> cfields: sure
 650 2017-11-30T19:30:27  <BlueMatt> its not like this is holding a zksnark trusted-setup for all btc
 651 2017-11-30T19:30:37  <gmaxwell> How big are the keys they use for these things? 2kbit or 4kbit?
 652 2017-11-30T19:31:02  <Provoostenator> BlueMatt: would be nice to get another blog from P
 653 2017-11-30T19:31:02  <Provoostenator> l
 654 2017-11-30T19:31:11  <sipa> ?
 655 2017-11-30T19:31:13  <BlueMatt> ?
 656 2017-11-30T19:31:19  <Provoostenator> Peter todd riding down Canada to generate his signing key.
 657 2017-11-30T19:31:29  <jonasschnelli> gmaxwell: 2048 is what my apple RSA keys are
 658 2017-11-30T19:31:33  <Provoostenator> And then bragging that's more secure than Zcash
 659 2017-11-30T19:31:36  <wumpus> indeed, it's just code signing, for one OS, if something is signed that is not validated by the gitian process that's discovered soon enough anyway
 660 2017-11-30T19:31:38  <gmaxwell> Provoostenator: it's totally unrelated.
 661 2017-11-30T19:31:58  <jonasschnelli> Code signing won't give a lot of additional security...
 662 2017-11-30T19:32:02  <jonasschnelli> It's just a UX thing IMO
 663 2017-11-30T19:32:07  <gmaxwell> zcash has a backdoor for the whole system, this is just some code signing crud.
 664 2017-11-30T19:32:25  <wumpus> right
 665 2017-11-30T19:32:29  <Provoostenator> I know.
 666 2017-11-30T19:32:43  <gmaxwell> the users shouldn't care AT ALL about the MPC we use for it, the purpose of the MPC is to protect the developers personally from being implicated in the unfortunate case their own computers get hacked.
 667 2017-11-30T19:32:53  <sipa> does the MPC generation have a trusted setup?
 668 2017-11-30T19:32:59  <gmaxwell> sipa: no.
 669 2017-11-30T19:33:07  <sipa> i assume not - if you're fine with trusted setup, just generate a single key and split it layer
 670 2017-11-30T19:33:13  <sipa> ok, so it is entirely unrelated
 671 2017-11-30T19:33:15  * jtimon is curious about the "review nits reduction" topic...
 672 2017-11-30T19:33:25  <wumpus> yes it's just to prevent the person doing the code signing from becoming a specific target
 673 2017-11-30T19:34:12  <jonasschnelli> review nit reduction topic?
 674 2017-11-30T19:34:25  <gmaxwell> sipa: it just uses paillier, and lots of roundtrips. it's pretty simple.
 675 2017-11-30T19:34:48  <wumpus> #topic review nit reduction
 676 2017-11-30T19:35:10  <jonasschnelli> I just feel that we spend a lot of time in finding code-style nits, fixing code-style nits and some of the PRs are almost a single wall of nits... It doesn't seem to be efficient... I think..
 677 2017-11-30T19:35:30  <jonasschnelli> We should enforce the rules... ( I know I already brought that up )
 678 2017-11-30T19:36:02  *** nanymouse has quit IRC
 679 2017-11-30T19:36:03  <jonasschnelli> The libcurl project does that... it won't compile (make) if the code style doesn't matches
 680 2017-11-30T19:36:10  <jonasschnelli> It would reduce the review time a lot...
 681 2017-11-30T19:36:20  <jonasschnelli> And we apperently fixing the nits anyways at some point in time
 682 2017-11-30T19:36:52  <jtimon> you mean getting travis to complain about style nits?
 683 2017-11-30T19:36:56  <Provoostenator> Currently we're only running whitespace linter?
 684 2017-11-30T19:37:10  <jonasschnelli> jtimon: travis already does this... (whitespace)
 685 2017-11-30T19:37:18  <BlueMatt> if there were an easy way to apply it to new code only, I'd say thats probably fine
 686 2017-11-30T19:37:27  <jonasschnelli> I just want to get the code styling nits away from github comments
 687 2017-11-30T19:37:28  * jtimon nods
 688 2017-11-30T19:37:33  <BlueMatt> but it was my impression we were not able to find a way to do so
 689 2017-11-30T19:37:42  <jonasschnelli> BlueMatt: only new code. Yes.
 690 2017-11-30T19:37:47  <jtimon> BlueMatt: that was my understanding too
 691 2017-11-30T19:38:03  <wumpus> so have e.g. clang-format check the diff of pull requests?
 692 2017-11-30T19:38:12  <sipa> jonasschnelli: (brainstorming) or we could have a bot that marks a PR ready for review only after all nits are fixed
 693 2017-11-30T19:38:15  <jonasschnelli> wumpus: Yes. Can we enforce that somehow?
 694 2017-11-30T19:38:28  <jonasschnelli> sipa: Would also be something.. yes.
 695 2017-11-30T19:38:31  <sipa> so that people know not to look at something while there is still automated review going on
 696 2017-11-30T19:38:32  <wumpus> jonasschnelli: I don't know...
 697 2017-11-30T19:38:33  <Provoostenator> It would also help to offer some hints for developers how to run linters in their editor. I'll add an entry for OSX Atom once I figure it out myself.
 698 2017-11-30T19:38:35  <jtimon> didn't someone wrote something like that at some point?
 699 2017-11-30T19:38:41  <wumpus> sipa: as long as it doesn't generate noise (posts) that's ok with me
 700 2017-11-30T19:38:55  <wumpus> sipa: so if it works like travis, just adds another cross to the status
 701 2017-11-30T19:38:59  <jonasschnelli> Would something speak against enforcing the clang-format-diff check during make?
 702 2017-11-30T19:39:02  <wumpus> w/ a link to the list of problems
 703 2017-11-30T19:39:02  <sipa> wumpus: right,t hat would be nice
 704 2017-11-30T19:39:08  <meshcollider> BlueMatt: adding new linters to Travis would only affect PRs now since #11699
 705 2017-11-30T19:39:10  <gribble> https://github.com/bitcoin/bitcoin/issues/11699 | [travis-ci] Only run linters on Pull Requests by jnewbery · Pull Request #11699 · bitcoin/bitcoin · GitHub
 706 2017-11-30T19:39:14  <wumpus> but I don't want any bots that generate notifications in my mail
 707 2017-11-30T19:39:32  <sipa> right
 708 2017-11-30T19:39:33  <jonasschnelli> wumpus: Yes, That would disturb even more
 709 2017-11-30T19:39:46  <jonasschnelli> Just an indication if its ready to review...
 710 2017-11-30T19:39:59  <jonasschnelli> And so we can have less of those "brackets, spaces missing blabla"
 711 2017-11-30T19:40:32  * BlueMatt was always in favor, did we find out if we could get a reasonably stable output out of clang-format?
 712 2017-11-30T19:40:38  <BlueMatt> or was it always very version-dependant?
 713 2017-11-30T19:40:47  <jonasschnelli> It just feels some reviews are more or less a "clang-format diff output"
 714 2017-11-30T19:40:52  <wumpus> I like how golang handles that, they just have one true style
 715 2017-11-30T19:41:12  <wumpus> and their linter can be safely used in e.g. pull request checks, w/ no ambiguity
 716 2017-11-30T19:41:14  <jtimon> jonasschnelli: wouldn't we need to comply with clang format in the whole project before doing the clang check in make? has anyone seen haw many changes trying to apply clang-format to the whole project produces right now?
 717 2017-11-30T19:41:29  <morcos> do we have good developer documentation on how to do the right thing locally (not what the rules are, but how to check them?)
 718 2017-11-30T19:41:32  <sipa> you can apply clang-format on just the diffs
 719 2017-11-30T19:41:37  <meshcollider> jtimon: not if it's only run on the diff
 720 2017-11-30T19:41:44  <jonasschnelli> yes
 721 2017-11-30T19:41:47  <sipa> but clang-format only checks whitespace/newlines
 722 2017-11-30T19:41:47  <wumpus> morcos: good point!
 723 2017-11-30T19:41:55  <sipa> it doesn't check variable names etc
 724 2017-11-30T19:41:56  <jonasschnelli> morcos: we should focus on that
 725 2017-11-30T19:41:57  <gmaxwell> A small amount of code style nits on github are probably good for teamwork.
 726 2017-11-30T19:42:03  <wumpus> sipa: I think that's fine, those are the ones we want out of the way
 727 2017-11-30T19:42:04  <jonasschnelli> sipa: not sure if that is possible
 728 2017-11-30T19:42:06  <jtimon> meshcollider: right, only for pr diffs, yeah, I thought he meant every time you build locally
 729 2017-11-30T19:42:11  <wumpus> sipa: variable names are more of a human thing anyhow
 730 2017-11-30T19:42:17  <wumpus> sipa: so it's fine if humans comment on them
 731 2017-11-30T19:42:29  <morcos> i'd be happy to do more locally, i'm sure my PR's are disasters, but it would be nice if a good workflow was spelled out
 732 2017-11-30T19:42:44  <jonasschnelli> morcos: Indeed
 733 2017-11-30T19:42:48  <meshcollider> Scripted diffs will probably regularly require style change commits too to keep Travis happy
 734 2017-11-30T19:42:57  <jtimon> gmaxwell: there's always style nits that go beyond clang-format
 735 2017-11-30T19:43:05  <wumpus> I mean it could check basic things like is_this_snake_case for variable names in theory, but not whether it's a good name in the first place...
 736 2017-11-30T19:43:13  <sipa> sur
 737 2017-11-30T19:43:16  <jonasschnelli> yes
 738 2017-11-30T19:43:35  <jonasschnelli> It's more about the naming convenction (m_, snake_case, CONSTANTS, etc,)
 739 2017-11-30T19:43:36  <wumpus> and the latter is much more important for maintainablility :-)
 740 2017-11-30T19:43:48  <kanzure> do we have a clang-format file
 741 2017-11-30T19:43:49  <MarcoFalke> meshcollider: I'd prefer if we didn't use clang-format in scripted diffs. Makes it impossible to reproduce ...
 742 2017-11-30T19:43:50  <gmaxwell> jtimon: yes true enough, I guess my point was that they're not all bad.
 743 2017-11-30T19:43:52  <wumpus> kanzure: yes
 744 2017-11-30T19:43:53  <jonasschnelli> kanzure: yes
 745 2017-11-30T19:44:15  <wumpus> contrib/devtools/clang-format-diff.py
 746 2017-11-30T19:44:15  <wumpus> src/.clang-format
 747 2017-11-30T19:44:25  <kanzure> ah thanks.
 748 2017-11-30T19:44:39  <cfields> i assume it'd be possible to setup a git alias that shows the current diff, diff'd against the clang-format result
 749 2017-11-30T19:44:43  * cfields plays around
 750 2017-11-30T19:44:44  <jonasschnelli> MarcoFalke: are you up to write a higher level documentation for the clang-format-diff.py workflow?
 751 2017-11-30T19:44:49  * MarcoFalke proposed to add '.style.yapf' and hides
 752 2017-11-30T19:44:56  <jtimon> wumpus: right, that's what I remember being written
 753 2017-11-30T19:44:57  <MarcoFalke> jonasschnelli: I did
 754 2017-11-30T19:45:06  <MarcoFalke> git diff | cfd
 755 2017-11-30T19:45:18  <wumpus> yapf?
 756 2017-11-30T19:45:19  *** jointek has joined #bitcoin-core-dev
 757 2017-11-30T19:45:23  <gmaxwell> general problem with clang format is that it isn't stable across versions, or at least hasn't been historically. In general we don't have a highly consistent enviroment htat people contribute from.
 758 2017-11-30T19:45:29  <ryanofsky> fwiw, i am not bothered by nits whatsoever. at the very least they mean somebody is actually looking at my pr. i also use clang-format and clang-format diff all the time
 759 2017-11-30T19:45:36  <wumpus> gmaxwell: right, that has always bothered about it
 760 2017-11-30T19:45:37  <jonasschnelli> gmaxwell: yeah. that
 761 2017-11-30T19:45:39  <MarcoFalke> also what gmaxwell said
 762 2017-11-30T19:45:44  *** jointek has left #bitcoin-core-dev
 763 2017-11-30T19:45:51  <MarcoFalke> wumpus: The same thing for python
 764 2017-11-30T19:45:59  <jtimon> well, the version can be fixed on travis, though
 765 2017-11-30T19:46:02  <wumpus> MarcoFalke: that's not very shocking
 766 2017-11-30T19:46:21  <jonasschnelli> ryanofsky: nits should still remain... just not stuff that computers can find and are covered by our code styling rules
 767 2017-11-30T19:46:23  <sipa> jtimon: right, but that makes travis effectively part of your workflow, which is unfortunate
 768 2017-11-30T19:46:42  <wumpus> you need to be able to run any checks that travis does locally
 769 2017-11-30T19:46:43  <sipa> jtimon: as in, you won't really know a PR is acceptable before pushing and waiting for travis
 770 2017-11-30T19:46:47  <gmaxwell> We could give developers a VM image or equivilent, but it's asking a lot.
 771 2017-11-30T19:46:48  <jtimon> sipa: right, or the concrete version if I want to run it locally first
 772 2017-11-30T19:47:19  <luke-jr> Travis is slow, too
 773 2017-11-30T19:47:30  <sipa> maybe someone should investigate how stable clang-format/ clang-tidy/ iwyu/ ... are
 774 2017-11-30T19:47:33  <morcos> my issue with the nits on PR's is it leads to sloppier review.  When nits get fixed and potentially rebased.  Prior reviewers can get sloppy about assuming that the final version is well reviewed, especially if its happened repeatedly
 775 2017-11-30T19:47:39  <jonasschnelli> Could we not do a check with clang-format-diff.py during "make" and at least place a bold warning (or even refuse to compile *duck*)
 776 2017-11-30T19:48:00  <achow101> jonasschnelli: it would blow up on existing code
 777 2017-11-30T19:48:07  <sipa> jonasschnelli: the problem is that different clang-format versions say different things
 778 2017-11-30T19:48:20  <jonasschnelli> sipa: significant?
 779 2017-11-30T19:48:26  <sipa> jonasschnelli: irrelevant, i think
 780 2017-11-30T19:48:29  <wumpus> jonasschnelli: 'make lint' would be nice
 781 2017-11-30T19:48:45  <sipa> and making something work on your own system, and then seeing travis complain about the exact same things but requiring something else would be pretty demotivating
 782 2017-11-30T19:48:49  <wumpus> jonasschnelli: that would just run all the checks, for C/C++, for python, for whitespace in docs, etc
 783 2017-11-30T19:48:49  <cfields> wumpus: +1
 784 2017-11-30T19:48:57  <gmaxwell> morcos: that is more a problem with the intermixing of nits and serious review, and also how github handles tracking comments (them magically vanishing when the code changes)
 785 2017-11-30T19:49:08  <jonasschnelli> wumpus: Maybe it should by bypassable, but the novice contributor should get warned if he uses invalid code-styling
 786 2017-11-30T19:49:15  <sipa> gmaxwell: that's no longer true with the 'review' function
 787 2017-11-30T19:49:28  <gmaxwell> Obviously we should just pull clang into our code tree and ship it too. :P
 788 2017-11-30T19:49:28  <sipa> you can see all former review comments, and the code they apply on
 789 2017-11-30T19:49:30  <wumpus> jonasschnelli: well, travis and the person that merge can also check
 790 2017-11-30T19:49:37  <jtimon> sipa: oh, that's what is for...
 791 2017-11-30T19:49:37  <instagibbs> sipa, interesting, more reason to use it
 792 2017-11-30T19:49:38  <wumpus> jonasschnelli: it just should be possible to do it locally too
 793 2017-11-30T19:49:49  <morcos> gmaxwell: yes, i'd argue that once serious review stars, nits should not be squashed, but should be left as a cleanup commit at the end.  (at least of some kinds)
 794 2017-11-30T19:49:51  <sipa> jtimon: yes, you should use it :)
 795 2017-11-30T19:49:54  <wumpus> jonasschnelli: I'm not so much concerned with forcing people to run it but making it easy
 796 2017-11-30T19:50:08  <jonasschnelli> wumpus: yes. Travis code style check is not what we want in the first place (it helps,.. but you want to catch it before)
 797 2017-11-30T19:50:33  <wumpus> jonasschnelli: well if you don't do it before, travis will stop you and you need to wait longer, simple as that :)
 798 2017-11-30T19:50:33  <sipa> something i have noticed is that sometimes 'nit' reviews start on PRs which are far from certain they'll be even concept ACKed
 799 2017-11-30T19:50:39  <instagibbs> morcos, we might need to have guidelines for "ACK lockin"
 800 2017-11-30T19:50:44  <jonasschnelli> Okay... I'll have a look at lint and something simple within the make-process
 801 2017-11-30T19:50:46  <jonasschnelli> sipa: that also
 802 2017-11-30T19:50:52  <cfields> morcos: i have no problem with squashing nits as the pre/post-squash can be diff'd locally. It's rebasing to master that makes re-review a challenge imo.
 803 2017-11-30T19:51:05  <wumpus> sipa: yeah... then it adds even more nosie
 804 2017-11-30T19:51:07  <instagibbs> cfields, can be diffed if you locally checked
 805 2017-11-30T19:51:20  <sipa> cfields: right, i try to avoid rebasing, but i pretty liberally squash nits
 806 2017-11-30T19:51:21  <instagibbs> many times im just reading off of github(lazy)
 807 2017-11-30T19:51:36  <sipa> cfields: and i don't mind others doing that too, except for very complicated PRs
 808 2017-11-30T19:51:38  <instagibbs> unless it's a particularly intense series of commits
 809 2017-11-30T19:51:41  <achow101> instagibbs: that kind of breaks when there's lots of merge conflicts
 810 2017-11-30T19:51:51  <wumpus> sometimes I wish 'git fetch' could fetch by commit id to fetch individual commits, unfortunately that doesn't work
 811 2017-11-30T19:52:00  <cfields> pretty sure github can show the diff from a squash a well, you just have to come up with the url for it
 812 2017-11-30T19:52:03  <gmaxwell> well we have contributors who don't feel comfortable (or just don't have the expirence) to do much other than nit reviews. Their contributions are usually pretty helpful and I wouldn't want to ask most of them to stop. We could perhaps ask them to wait a day on new PRs so that there is at least time for Concept NAKs to show up first.
 813 2017-11-30T19:52:05  <wumpus> it can only be used with branch names
 814 2017-11-30T19:52:38  <wumpus> github can give you the patch for an arbitrary commit id though, but it's kind of annoying to do automatically
 815 2017-11-30T19:52:54  <gmaxwell> it is a little sad for someone to show up with a change, and then have two cycles on trivial changes before someone more expirenced comes in and says no-way-because-x.
 816 2017-11-30T19:53:02  <wumpus> gmaxwell: yeah...
 817 2017-11-30T19:53:04  <aj> gmaxwell: might be helpful to tag PRs as looking for concept acks vs looking for nits and style vs looking for tested acks and merging?
 818 2017-11-30T19:53:08  <MarcoFalke> wumpus: We could set up a bot to create branches for each utACK that is posted to gh
 819 2017-11-30T19:53:13  <instagibbs> not nitting a PR that doens't have any ACKs of any kind seems like a decent rule
 820 2017-11-30T19:53:16  <MarcoFalke> on a separate repo that is
 821 2017-11-30T19:53:23  <wumpus> MarcoFalke: that'd be kind of nice
 822 2017-11-30T19:53:28  <jtimon> cfields: at the same time rebasing is often good, for example, #8994 could unexpectedly start failing tests even if no new conflicts appear and github says it's all ready to merge it
 823 2017-11-30T19:53:32  <gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
 824 2017-11-30T19:53:48  <wumpus> rebasing is often necessary
 825 2017-11-30T19:53:52  <jonasschnelli> Yes. What aj says. The things is just, unenforced user rules tend to get ignored. :)
 826 2017-11-30T19:53:54  <Provoostenator> gmaxwell: as long as you learn something from the nits, it's not the end of the world having them concept-nacked later, imo
 827 2017-11-30T19:54:00  <MarcoFalke> then `git fetch bitcoin_reviewed_commits` will get you all the reviews
 828 2017-11-30T19:54:01  <gmaxwell> sometimes you don't know what you're going to do when you read it.. there are certantly PRs where I read them and then come away with no real opinions on it other than "you missed some braces here and there"
 829 2017-11-30T19:54:13  <wumpus> some files are hotspots and generate a lot of merge conflicts
 830 2017-11-30T19:54:28  <wumpus> although it's better now that main.cpp is dead
 831 2017-11-30T19:54:32  <gmaxwell> Provoostenator: no, but some people find it demotivating; 'they made me do more work then threw it out'. :)
 832 2017-11-30T19:54:52  <Provoostenator> True
 833 2017-11-30T19:54:53  *** karelb has quit IRC
 834 2017-11-30T19:55:09  *** ghost43 has quit IRC
 835 2017-11-30T19:55:10  <wumpus> Provoostenator: these are not the kind of nits that help you learn btter programming :)
 836 2017-11-30T19:55:30  <gmaxwell> Provoostenator: that can be resolved with a better perspective; bitcoin development is a distributed process, your effort is your contribution not the fact that it was merged, etc.
 837 2017-11-30T19:55:32  *** ghost43 has joined #bitcoin-core-dev
 838 2017-11-30T19:55:48  <jonasschnelli> gmaxwell: indeed
 839 2017-11-30T19:55:52  <gmaxwell> Provoostenator: but we can't really send every new contributor to a zen mastery class before they contribute.
 840 2017-11-30T19:56:10  <Provoostenator> Well, we could... but that would be flagged as spam :-)
 841 2017-11-30T19:56:11  <wumpus> Provoostenator: if it's a nit like 'it's better to use build in function X' or 'the loop can be more efficiently written like this' then I think it's great
 842 2017-11-30T19:57:17  <cfields> a slightly different work-flow might be: create a "fixed nits" commit on top of the branch, and squash all nits into that as they arise. Then merge that in without squashing.
 843 2017-11-30T19:57:40  <cfields> it makes for ugly commits getting merged in, but avoids the re-review after squash-for-nits issue.
 844 2017-11-30T19:57:41  <Provoostenator> So far I find most of the nits I received useful. They either taught me to look up coding practices, or motivated me to figure out how to run a linter.
 845 2017-11-30T19:57:44  <gmaxwell> a challenge with that is that we do get new contributions from people with zero git expirence.
 846 2017-11-30T19:58:10  <sipa> who think they need to open a new PR to fix a nit :)
 847 2017-11-30T19:58:10  <wumpus> the git basics stuff is explained pretty well in the contributing doc nowadays
 848 2017-11-30T19:58:27  <aj> do people think the +1, +0, -1, concept nak/ack thing from https://github.com/bitcoin/bitcoin/pull/11426#issuecomment-334091207 is good btw?
 849 2017-11-30T19:58:29  <wumpus> I've not gotten the question on how to squash a commit for a long time now
 850 2017-11-30T19:58:39  *** SopaXorzTaker has quit IRC
 851 2017-11-30T19:58:41  <gmaxwell> wumpus: I've noticed that, I wondered why.
 852 2017-11-30T19:59:03  <instagibbs> oh that's where -0 came from
 853 2017-11-30T19:59:03  <Provoostenator> Some projects make a giant squashed merge commit and just point to the original PR (e.g. AngularJS), but that's not ideal for other reasons.
 854 2017-11-30T19:59:33  <BlueMatt> aj: yes, I'm a fan
 855 2017-11-30T19:59:37  <wumpus> Provoostenator: we only want to encourage squashing when it's iterative changes, not atomic separate changes
 856 2017-11-30T19:59:40  <jtimon> aj: I would have preffered that BlueMatt had maintained a nack but answered my questions/rebute, to be honest
 857 2017-11-30T19:59:42  <BlueMatt> specifically caues we end up with lots of need for concept review
 858 2017-11-30T20:00:13  <BlueMatt> we have lots of prs where lots of folks are +0/-0 and dont think its worth review
 859 2017-11-30T20:00:16  <BlueMatt> but they sit open for months
 860 2017-11-30T20:00:17  <BlueMatt> which is bad
 861 2017-11-30T20:00:24  <MarcoFalke> +0 on end meeting
 862 2017-11-30T20:00:29  <BlueMatt> +1
 863 2017-11-30T20:00:29  <instagibbs> -0
 864 2017-11-30T20:00:31  <wumpus> oh, it's that time already
 865 2017-11-30T20:00:33  <wumpus> #endmeeting
 866 2017-11-30T20:00:33  <lightningbot> Meeting ended Thu Nov 30 20:00:33 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
 867 2017-11-30T20:00:33  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-30-19.00.html
 868 2017-11-30T20:00:33  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-30-19.00.txt
 869 2017-11-30T20:00:33  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-30-19.00.log.html
 870 2017-11-30T20:01:00  <instagibbs> so hold on, the numbers are for what? pre-ACK reflection on idea?
 871 2017-11-30T20:01:13  <BlueMatt> generally, ive been usint them as that, yea
 872 2017-11-30T20:01:19  <MarcoFalke> warren: I tested it in august. Should still work, as the vm-builder is compiled from source
 873 2017-11-30T20:01:21  <BlueMatt> see aj's link
 874 2017-11-30T20:01:21  <wumpus> did we just spend an hour talking about nits and code signing, oh - also the signmessage thing :-)
 875 2017-11-30T20:01:28  <BlueMatt> yes :(
 876 2017-11-30T20:01:34  <jtimon> BlueMatt: if they are worth merging I don't think it's bad they sit open for months, even if a couple of  folks said -0
 877 2017-11-30T20:01:35  <instagibbs> wumpus, 0.16 release too
 878 2017-11-30T20:01:38  <BlueMatt> spent an hour talking about how we waste time on nits
 879 2017-11-30T20:01:42  <MarcoFalke> warren: We do that on debian and ubuntu, so I sticked with it
 880 2017-11-30T20:01:42  <wumpus> BlueMatt: lol!
 881 2017-11-30T20:01:46  <wumpus> instagibbs: yes, you're right
 882 2017-11-30T20:01:48  <morcos> didn't you guys have a libevent topic
 883 2017-11-30T20:01:50  <aj> instagibbs: https://www.apache.org/foundation/voting.html#expressing-votes-1-0-1-and-fractions is the apache link
 884 2017-11-30T20:01:53  <instagibbs> BlueMatt, more irc meetings until throughput increases
 885 2017-11-30T20:01:57  <BlueMatt> wumpus: <BlueMatt> oh, wait, i dont have one...hmmmm, I'd say #10279
 886 2017-11-30T20:02:00  <gribble> https://github.com/bitcoin/bitcoin/issues/10279 | Add a CChainState class to validation.cpp to take another step towards clarifying internal interfaces by TheBlueMatt · Pull Request #10279 · bitcoin/bitcoin · GitHub
 887 2017-11-30T20:02:11  <jtimon> so, yeah, how long is "shortly after" for 0.16 ?
 888 2017-11-30T20:02:11  <Provoostenator> Is there a safe way to make Travis cache more stuff? It's insanely slow.
 889 2017-11-30T20:02:28  <BlueMatt> fuck, we forgot to talk about cfields' libevent question :(
 890 2017-11-30T20:02:33  <BlueMatt> that actually mattered
 891 2017-11-30T20:02:42  <instagibbs> feel free to talk on it
 892 2017-11-30T20:02:47  <morcos> well if you, wumpus and cfields are here, you can still talk
 893 2017-11-30T20:02:48  <cfields> it's ok, I'm still investigating something locally
 894 2017-11-30T20:02:57  <gmaxwell> too bad we're not allowed to talk about things except in meetings :(
 895 2017-11-30T20:03:07  <Dizzle> Has libevent merged pass-in-your-own-socket yet?
 896 2017-11-30T20:03:10  <cfields> heh
 897 2017-11-30T20:03:32  <cfields> The specific issue is how to deal with #11785
 898 2017-11-30T20:03:33  <gribble> https://github.com/bitcoin/bitcoin/issues/11785 | Prevent file-descriptor exhaustion from RPC layer by vii · Pull Request #11785 · bitcoin/bitcoin · GitHub
 899 2017-11-30T20:03:42  <wumpus> Dizzle: I don't think so
 900 2017-11-30T20:03:45  *** clarkmoody has joined #bitcoin-core-dev
 901 2017-11-30T20:04:07  <wumpus> Dizzle: at least not for the http client, if you mean that, there's ton of ways to pass your own socket but not there
 902 2017-11-30T20:04:29  <cfields> I'm not convinced that we can fix it entirely, so it remains unclear what to do about it
 903 2017-11-30T20:04:49  <Dizzle> wumpus: thanks, that's what I was wondering about. stratum wallet and stratum mining projects are looking forward to unix socket RPC
 904 2017-11-30T20:04:50  <gmaxwell> well we could always merge some code that tries to increase our FD count, but thats not a fix.
 905 2017-11-30T20:05:01  <instagibbs> aj I still don't see the exact relationship between the numbers and ACKs.
 906 2017-11-30T20:05:18  <wumpus> BlueMatt: you mean #10279 for high priority for review?
 907 2017-11-30T20:05:21  <gribble> https://github.com/bitcoin/bitcoin/issues/10279 | Add a CChainState class to validation.cpp to take another step towards clarifying internal interfaces by TheBlueMatt · Pull Request #10279 · bitcoin/bitcoin · GitHub
 908 2017-11-30T20:05:21  <BlueMatt> yes
 909 2017-11-30T20:05:22  <instagibbs> seems to be concept ACK on sliding scale
 910 2017-11-30T20:05:43  <wumpus> Dizzle: do you need it to be in bitcoin-cli for that?
 911 2017-11-30T20:05:52  <cfields> gmaxwell: the second part of the PR does that, but that makes me really nervous :(
 912 2017-11-30T20:06:00  <aj> instagibbs: +1 -1 = concept ack / concept nak; in between is "leaning this way or not, but not decided either way"
 913 2017-11-30T20:06:11  <wumpus> Dizzle: we could just merge the server side, then you can use it from your own code, just not the command line
 914 2017-11-30T20:06:13  <Dizzle> wumpus: nope, most pools and electrum servers use json-rpc themselves for that.
 915 2017-11-30T20:06:21  <Dizzle> that would be neat!
 916 2017-11-30T20:06:24  <instagibbs> aj ok so it is a replacement for concept acks... that makes more sense
 917 2017-11-30T20:06:30  <BlueMatt> mostly I love -0 - I dont think this is worth anyone's time to review, but if others want to, fine
 918 2017-11-30T20:06:54  <instagibbs> wumpus, speaking of merge ready, 10677
 919 2017-11-30T20:06:55  *** esotericnonsense has quit IRC
 920 2017-11-30T20:06:56  <Dizzle> BTW, if anyone's curious how Electrum implements message signatures on native segwit addrs, we just iterate through the possible address types until there's match: https://github.com/spesmilo/electrum/blob/66cce115ef93c913d65ef5c7d781c8065f79bbaf/lib/bitcoin.py#L632
 921 2017-11-30T20:06:58  *** instagibbs has left #bitcoin-core-dev
 922 2017-11-30T20:07:00  <gmaxwell> cfields: don't we have to eliminate the use of select before we go increasing the default maximum beyond FD_SETSIZE?
 923 2017-11-30T20:07:08  *** instagibbs has joined #bitcoin-core-dev
 924 2017-11-30T20:07:10  <wumpus> Dizzle: I don't think it's awfully useful in bitcoin-cli anyhow though it's useful for testing (though OTOH, the patch also changed the RPC testing framework to be able to use UNIX sockets)
 925 2017-11-30T20:07:25  <wumpus> instagibbs: ok
 926 2017-11-30T20:07:40  <cfields> gmaxwell: I believe the limit becomes FD_SETSIZE*2 if you're using 2 select loops?
 927 2017-11-30T20:07:52  *** esotericnonsense has joined #bitcoin-core-dev
 928 2017-11-30T20:07:53  *** photonclock_ has quit IRC
 929 2017-11-30T20:08:04  <wumpus> cfields: no
 930 2017-11-30T20:08:10  <gmaxwell> to my great shame I seem to have forgotten how select is implemented internally. :P
 931 2017-11-30T20:08:24  <wumpus> cfields: select limits the max fd, using multiple selects doesn't change that
 932 2017-11-30T20:08:45  <wumpus> we should probably have switched to poll a long time ago
 933 2017-11-30T20:09:23  <wumpus> IIRC there have been PRs for that, but rejected because libevent P2P was just around the corner...
 934 2017-11-30T20:09:27  <gmaxwell> cfields: we've been waiting forever for the great networking refactors to eliminate the use of select, but perhaps this is a mistake-- select on windows scales fine, and switchin to poll on *nix is a couple line patch IIRC.
 935 2017-11-30T20:09:29  <cfields> well regardless, libevent is using epoll/kqueue/etc. here, so the select limits don't (or shouldn't) apply to rpc
 936 2017-11-30T20:09:49  *** dermoth has quit IRC
 937 2017-11-30T20:09:51  <wumpus> cfields: no, but the fd's used might be in select's limit!
 938 2017-11-30T20:10:06  <wumpus> cfields: if 1024 fd's are used, then select is dead, no matter who claimed them
 939 2017-11-30T20:10:13  <gmaxwell> cfields: yes, but if we increase the process FD count, we're going to end up with FDs with high numbers which I thought broke select but as mentioned since I seem to have forgotten how it works internally I could be confused.
 940 2017-11-30T20:10:25  <wumpus> gmaxwell: you're right
 941 2017-11-30T20:10:51  <wumpus> cfields: you're right that RPC itself won't be affected, but it still messes up P2P nevertheless
 942 2017-11-30T20:10:51  <cfields> ok, i was confused about the limit then.
 943 2017-11-30T20:11:18  <gmaxwell> cfields: basically as-i-fake-recall the FD number itself is converted into a position in the array, so if you only have 8 FD's monitored but one of them has number 21318 you're going to be in trouble.
 944 2017-11-30T20:11:37  <wumpus> gmaxwell: yup the fd number is converted to a bit position in the array
 945 2017-11-30T20:11:52  <wumpus> which is also what makes it so inefficient
 946 2017-11-30T20:12:00  <wumpus> if it is a sparse array....
 947 2017-11-30T20:12:12  *** photonclock_ has joined #bitcoin-core-dev
 948 2017-11-30T20:12:24  *** Ylbam has joined #bitcoin-core-dev
 949 2017-11-30T20:12:35  <gmaxwell> I believe bluematt wrote a very small patch to change bitcoin to poll.  We could take, that and wrap it in ifdefs so we still select on windows, and call that sub-issue done.
 950 2017-11-30T20:12:55  <BlueMatt> none of these things solve the problem....
 951 2017-11-30T20:13:00  <BlueMatt> the issue ends up being in eg leveldb
 952 2017-11-30T20:13:09  <gmaxwell> BlueMatt: no but it lets you increase the process limit above 1024.
 953 2017-11-30T20:13:10  <BlueMatt> i mean it'll blow up our p2p first, but mostly thats not a big deal
 954 2017-11-30T20:13:14  <wumpus> does leveldb use select?
 955 2017-11-30T20:13:16  *** Guyver2 has joined #bitcoin-core-dev
 956 2017-11-30T20:13:22  <gmaxwell> since when does leveldb use select?
 957 2017-11-30T20:13:24  <wumpus> I don't hink so
 958 2017-11-30T20:13:28  <BlueMatt> wumpus: no, in this case we literally ran out of process fds
 959 2017-11-30T20:13:34  <wumpus> leveldb only croaks if you run out of all process fds
 960 2017-11-30T20:13:49  <wumpus> which is what vii's patch more or less solves
 961 2017-11-30T20:13:53  <gmaxwell> As I said above: increasing the count isn't a _fix_; ... but it's a pretty good mitigation.
 962 2017-11-30T20:14:22  <wumpus> at least the obvious 'attack RPC with tons of separate connections' doesn't work as an exhaustion attack anymore after that
 963 2017-11-30T20:14:24  <BlueMatt> increasing the count also mostly doesnt break p2p, p2p will just keep opening new sockets until it gets a low numbered one
 964 2017-11-30T20:14:28  <cfields> wumpus: unfortunately, it doesn't :(
 965 2017-11-30T20:14:33  <wumpus> cfields: oh?
 966 2017-11-30T20:14:35  <BlueMatt> its smart enough to handle it
 967 2017-11-30T20:14:49  <gmaxwell> BlueMatt: really? what? lol.
 968 2017-11-30T20:15:00  <cfields> wumpus: nah, i can still exhaust the FDs with little effort.
 969 2017-11-30T20:15:02  <BlueMatt> i mean its not *that* smart, eg it will fail each connection
 970 2017-11-30T20:15:09  <BlueMatt> but it wil lkeep trying to make connections
 971 2017-11-30T20:15:16  <wumpus> cfields: so we really need a fix at the libevent side?
 972 2017-11-30T20:15:20  <gmaxwell> BlueMatt: so if an incoming connection has a high FD number it just drops it?
 973 2017-11-30T20:15:24  <BlueMatt> yes
 974 2017-11-30T20:15:46  <wumpus> it's interesting as I did load tests when I started using libevent and never stumbled on this
 975 2017-11-30T20:16:08  <gmaxwell> thats really ugly, and doesn't let us increase the maximum, consider, we make the maximum 65536... and the most of your connections start getting dropped. :)
 976 2017-11-30T20:16:15  <cfields> wumpus: yes. Problem is that it does while(something){accept()...}
 977 2017-11-30T20:16:16  <wumpus> if I only had known its http server was so crappy :(
 978 2017-11-30T20:16:32  <cfields> so if you manage to make a shitload of connections while it's in that loop, it'll keep swallowing 'em
 979 2017-11-30T20:16:34  <BlueMatt> gmaxwell: i mean if your rpc is getting flooded you probably want to drop most connections :p
 980 2017-11-30T20:16:45  <BlueMatt> cause you're already overloaded
 981 2017-11-30T20:16:51  <wumpus> BlueMatt: yes, you want to drop them
 982 2017-11-30T20:17:05  <wumpus> BlueMatt: that would be the right solution, not hoard file descriptors
 983 2017-11-30T20:17:15  <gmaxwell> BlueMatt: yea sure but I think the FD assignment is next highest in range until it hits the maximum, not lowest available.
 984 2017-11-30T20:17:38  <wumpus> AFAIK fd assignment is lowest available on many OSes
 985 2017-11-30T20:17:47  <BlueMatt> hmm, my node doesnt seem to break and i run with high fd limit
 986 2017-11-30T20:17:49  <gmaxwell> okay, I needed to be wrong about at least one thing.
 987 2017-11-30T20:17:52  <BlueMatt> so....dont think so on linux?
 988 2017-11-30T20:17:57  <gmaxwell> BlueMatt: without the poll patch?
 989 2017-11-30T20:18:00  <BlueMatt> yes, without
 990 2017-11-30T20:18:05  <wumpus> try to close stdout and the next fd you open :-)
 991 2017-11-30T20:18:11  <BlueMatt> i stopped using it and you can still get something like 800 maxonncections
 992 2017-11-30T20:18:22  <gmaxwell> gessh comeone we should just switch to poll, if its *nix only it should be a dozen line patch.
 993 2017-11-30T20:18:29  <gmaxwell> wumpus: lol.
 994 2017-11-30T20:18:39  * BlueMatt 's point is that it is almost entirely irrelevant to this issue
 995 2017-11-30T20:19:10  <wumpus> it's still relevant though
 996 2017-11-30T20:19:12  <gmaxwell> well increasing the fd count would change the urgency.
 997 2017-11-30T20:19:35  * BlueMatt 's point is we can increase fd count today
 998 2017-11-30T20:19:38  <BlueMatt> without poll
 999 2017-11-30T20:19:52  <wumpus> maybe not for this specific issue, but there's no good reason at all we're still using select, it only has drawbacks
1000 2017-11-30T20:20:00  <BlueMatt> fair
1001 2017-11-30T20:20:03  <gmaxwell> I really don't want to troubleshoot mysterious connection failures from "your FD was too high"
1002 2017-11-30T20:20:10  <Dizzle> Does select do ok on macOS? If not, would need to add kqueue polling to those 12 lines of code.
1003 2017-11-30T20:20:44  <gmaxwell> oh right osx poll is broken isn't it?
1004 2017-11-30T20:21:02  <wumpus> how is poll broken on osx?
1005 2017-11-30T20:21:29  <gmaxwell> https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/
1006 2017-11-30T20:22:00  <gmaxwell> sounds like they've fixed it, broken it again, and fixed it.
1007 2017-11-30T20:22:08  <wumpus> lol I'm not surprised, even validating the root password seems to be too difficult for them
1008 2017-11-30T20:22:24  <cfields> iirc they're just flip-flopping on undefined return values?
1009 2017-11-30T20:23:09  <gmaxwell> yea, it seems like that the case discussed there should be easy to avoid.
1010 2017-11-30T20:23:15  <wumpus> they took poor old freebsd and turned it to crap
1011 2017-11-30T20:23:55  <Dizzle> Of note, in addition to the issue that blog mentions, macOS' poll doesn't work on devices.
1012 2017-11-30T20:24:06  <gmaxwell> but shiny plastic crap
1013 2017-11-30T20:24:12  <gmaxwell> we only need it on sockets.
1014 2017-11-30T20:24:53  <wumpus> indeed, that doesn't matter
1015 2017-11-30T20:25:20  <wumpus> windows can't do select on devices or files either,we don't use that
1016 2017-11-30T20:26:03  <gmaxwell> BlueMatt: where is that poll patch?
1017 2017-11-30T20:26:26  <BlueMatt> uhhhh, lost?
1018 2017-11-30T20:26:28  <BlueMatt> i dunno
1019 2017-11-30T20:27:29  <Dizzle> I feel like ifdefing kqueue isn't a big stretch if we're already ifdefing poll. Python project ended up with a selector selector API on top of all this: https://docs.python.org/3/library/selectors.html#selectors.DefaultSelector
1020 2017-11-30T20:27:57  *** esotericnonsense has quit IRC
1021 2017-11-30T20:28:11  <gmaxwell> Dizzle: no probably not but whats the gain?
1022 2017-11-30T20:28:27  <Dizzle> performance and it works on those few versions of OS X with the broken poll
1023 2017-11-30T20:28:46  <gmaxwell> the performance differences are negligible for our sorts of usage.
1024 2017-11-30T20:29:03  <cfields> Dizzle: there's an abstraction that's done-ish, waiting on pre-requisites to go in. It uses epoll/kqueue/poll/etc. The poll discussion here arose because presumably it'd be simple.
1025 2017-11-30T20:29:05  <wumpus> on the fd assignment, this prints "0" on linux 4.10.0 https://gist.github.com/laanwj/8125d4971728dcfe85f6f5bd09dd572f , so at least anecdotally linux seems to assign the first available fd
1026 2017-11-30T20:29:30  <wumpus> Dizzle: that's why the goal is to move P2P to libevent, it already handles all those polling methods
1027 2017-11-30T20:29:30  <Dizzle> cfields: this abstraction on libevent or bitcoin core?
1028 2017-11-30T20:29:38  <cfields> yea
1029 2017-11-30T20:29:45  <Dizzle> OK, great. Sorry for the noise then :)
1030 2017-11-30T20:30:06  <wumpus> we really don't want to replicate all of that
1031 2017-11-30T20:30:08  <gmaxwell> the general problem with more ifdef paths is less coverage, the majority of the developers are are on linux, as are the majority of serious technical users who will try strange things and actually report results.
1032 2017-11-30T20:30:09  <cfields> #11227
1033 2017-11-30T20:30:11  <gribble> https://github.com/bitcoin/bitcoin/issues/11227 | WIP: switch to libevent for node socket handling by theuni · Pull Request #11227 · bitcoin/bitcoin · GitHub
1034 2017-11-30T20:30:56  <gmaxwell> so we should have a strong general preference to minimize platform ifdefs just on the basis that if we introduce a bug in one of them, it may take a long time to discover and fix.
1035 2017-11-30T20:31:00  <cfields> wumpus: as a data point, even with #11785, i can exhaust all handles via rpc in a minute or two.
1036 2017-11-30T20:31:01  <gribble> https://github.com/bitcoin/bitcoin/issues/11785 | Prevent file-descriptor exhaustion from RPC layer by vii · Pull Request #11785 · bitcoin/bitcoin · GitHub
1037 2017-11-30T20:31:02  <wumpus> at least the low-level libevent stuff is well tested
1038 2017-11-30T20:31:18  <gmaxwell> yes, at least libevent gets testing by other people.
1039 2017-11-30T20:31:19  <cfields> So I'm not sure that it's worth adding work-around hacks
1040 2017-11-30T20:31:48  <wumpus> cfields: so what can we do? (except say "don't do this")
1041 2017-11-30T20:31:57  <wumpus> I mean it's kind of sad to DoS yourself
1042 2017-11-30T20:32:13  <bitcoin-git> [bitcoin] luke-jr opened pull request #11803: Bugfix: RPC/Wallet: Include HD key metadata in dumpwallet (master...bugfix_dumpwallet_hdkeypath) https://github.com/bitcoin/bitcoin/pull/11803
1043 2017-11-30T20:32:17  <wumpus> and outside of localhost I doubt you'll ever accomplish such a rate
1044 2017-11-30T20:32:31  <gmaxwell> Though I think our general expirence with dependencies (including, sadly, libevent) is that we still run into bugs in them... in part because everything everywhere is broken, and small brokenness in most things is just background noise. ... so the fact that dependency foo is widely used helps less than we might guess.
1045 2017-11-30T20:32:45  <wumpus> that's just a fact of life, everything has bugs
1046 2017-11-30T20:33:01  <cfields> wumpus: yea, i'm not really sure
1047 2017-11-30T20:33:18  <gmaxwell> split rpc into another process. :P
1048 2017-11-30T20:33:19  <wumpus> I mean we even find gcc bugs
1049 2017-11-30T20:33:37  *** Krellan has joined #bitcoin-core-dev
1050 2017-11-30T20:33:42  <wumpus> if anything should be well-tested...
1051 2017-11-30T20:33:44  <gmaxwell> wumpus: yea, well I used to comment that I was worried about our testing because we weren't finding GCC bugs. Glad thats fixed now. :)
1052 2017-11-30T20:34:01  <cfields> gmaxwell: yea, i expected some opposition, especially as these bugs crop up. I'd be ok with doing our own abstractions if it came down to it.
1053 2017-11-30T20:34:12  <wumpus> cfields: could we patch it at the libevent side?
1054 2017-11-30T20:34:26  <wumpus> cfields: I think trying to fix it in bitcoind is looking at it the wrong way
1055 2017-11-30T20:34:33  <gmaxwell> I think we should fix libevent.
1056 2017-11-30T20:34:34  <wumpus> cfields: it's a libevent bug
1057 2017-11-30T20:34:45  <cfields> wumpus: yea, pretty easily I believe
1058 2017-11-30T20:35:11  <wumpus> cfields: trying to work around upstream issues (at least permanently) instead of fixing them is pretty not done in open source
1059 2017-11-30T20:35:21  <cfields> through it might kill performance in some applications, so I'm not sure they'd want it upstream
1060 2017-11-30T20:35:22  <gmaxwell> and in the short term apply some mitigations in bitcoin, like increasing the FD count (ugh but I really don't like counting on FD magnitude sniffing)
1061 2017-11-30T20:35:40  <cfields> *though
1062 2017-11-30T20:35:46  <gmaxwell> cfields: surely exausting a processes' FDs isn't a cool move.
1063 2017-11-30T20:35:47  <wumpus> cfields: I don't think they care about performance in the http server
1064 2017-11-30T20:36:31  <cfields> wumpus: well it's in the listener, which is intended to be generic. The http server is just a user
1065 2017-11-30T20:36:37  <cfields> but yes, I'll do up a patch
1066 2017-11-30T20:36:38  <Randolf> [Syntax]:  That's a nice way to encourage people.  I like that.
1067 2017-11-30T20:36:42  <gmaxwell> among other things, it can contribute to amazing security vulns and remote crashes when it makes it impossible to open /dev/urandom to get randomness.
1068 2017-11-30T20:36:46  <Randolf> Whoops, sorry, wrong channel.
1069 2017-11-30T20:37:16  <wumpus> cfields: so the bug is deeper than just the http server, and woudl affect other clients (such as tor) as well?
1070 2017-11-30T20:37:19  <wumpus> cfields: now I'm interested :)
1071 2017-11-30T20:37:46  <cfields> wumpus: I'm unsure who/what else uses the listener
1072 2017-11-30T20:37:49  <BlueMatt> cfields: having a limited queue is a simple patch upstream *should* do
1073 2017-11-30T20:38:04  <cfields> i assume their dns server, as a quick example
1074 2017-11-30T20:38:51  <BlueMatt> so you can crash their dns server with enough tcp traffic?
1075 2017-11-30T20:39:15  <cfields> sec, checking
1076 2017-11-30T20:39:32  <gmaxwell> FWIW speaking of urandom, we'll assert if the open fails, so if you didn't know it this exhaust issue probably also causes (safe) crashes for us.
1077 2017-11-30T20:40:08  <wumpus> gmaxwell: yes luckily we check for that
1078 2017-11-30T20:41:06  <cfields> ok no, they only use the listener internally for http
1079 2017-11-30T20:41:24  <BlueMatt> what else uses libevent's http server?
1080 2017-11-30T20:41:25  *** andrelam has joined #bitcoin-core-dev
1081 2017-11-30T20:41:26  <wumpus> cfields: I have a tor checkout here, anything I can easily grep for to see if they use it?
1082 2017-11-30T20:41:28  <BlueMatt> anything should be crashable
1083 2017-11-30T20:41:40  <cfields> wumpus: evconnlistener
1084 2017-11-30T20:42:08  <wumpus> cfields: no matches
1085 2017-11-30T20:42:23  <cfields> whew :)
1086 2017-11-30T20:43:23  <wumpus> they also don't use evhttp
1087 2017-11-30T20:45:08  *** andrelam has quit IRC
1088 2017-11-30T20:45:08  <wumpus> they do have a http client in src/or/directory.c but apparently they rolled their own there
1089 2017-11-30T20:45:31  <wumpus> eh not that the client would suffer from this
1090 2017-11-30T20:46:41  *** andrelam has joined #bitcoin-core-dev
1091 2017-11-30T20:49:35  <wumpus> still, there might be tons of things out there that use it
1092 2017-11-30T20:50:08  <wumpus> so if this can be triggered over the network it might still be reasonably serious
1093 2017-11-30T20:50:34  *** Hen_ has joined #bitcoin-core-dev
1094 2017-11-30T20:51:59  <wumpus> gah why are code search engines so useless
1095 2017-11-30T20:52:50  <wumpus> find 1000 forks of libevent, of course they have that string
1096 2017-11-30T20:53:00  *** Hen_ has quit IRC
1097 2017-11-30T20:53:23  <cfields> testing a patch
1098 2017-11-30T20:54:13  <wumpus> cfields: cool
1099 2017-11-30T20:55:56  *** jack__ has quit IRC
1100 2017-11-30T20:56:11  *** alreadylate has joined #bitcoin-core-dev
1101 2017-11-30T21:00:19  *** Ahia has joined #bitcoin-core-dev
1102 2017-11-30T21:02:18  *** Cheeseo has joined #bitcoin-core-dev
1103 2017-11-30T21:05:00  *** Victorsueca has quit IRC
1104 2017-11-30T21:06:10  *** Victorsueca has joined #bitcoin-core-dev
1105 2017-11-30T21:16:23  *** JackH has joined #bitcoin-core-dev
1106 2017-11-30T21:20:19  *** gitju has quit IRC
1107 2017-11-30T21:21:03  *** jtimon has quit IRC
1108 2017-11-30T21:25:16  *** andrelam has quit IRC
1109 2017-11-30T21:25:33  *** andrelam has joined #bitcoin-core-dev
1110 2017-11-30T21:33:52  *** owowo has quit IRC
1111 2017-11-30T21:39:10  *** jezeba has joined #bitcoin-core-dev
1112 2017-11-30T21:39:15  *** alreadylate has quit IRC
1113 2017-11-30T21:40:49  *** Giszmo has quit IRC
1114 2017-11-30T21:41:11  *** alreadylate has joined #bitcoin-core-dev
1115 2017-11-30T21:42:46  *** alreadylate has quit IRC
1116 2017-11-30T21:43:15  *** jezeba has quit IRC
1117 2017-11-30T21:44:20  *** Ahia has quit IRC
1118 2017-11-30T21:44:26  *** promag has joined #bitcoin-core-dev
1119 2017-11-30T21:46:50  *** Giszmo has joined #bitcoin-core-dev
1120 2017-11-30T21:48:13  *** Cheeseo has quit IRC
1121 2017-11-30T21:49:57  *** clarkmoody has quit IRC
1122 2017-11-30T21:50:28  *** Chris_Stewart_5 has quit IRC
1123 2017-11-30T21:51:56  *** andrelam has quit IRC
1124 2017-11-30T21:52:09  *** alreadylate has joined #bitcoin-core-dev
1125 2017-11-30T21:55:39  *** Cheeseo has joined #bitcoin-core-dev
1126 2017-11-30T21:56:55  *** promag has quit IRC
1127 2017-11-30T21:57:15  *** alreadylate has quit IRC
1128 2017-11-30T22:03:08  *** Cheeseo has quit IRC
1129 2017-11-30T22:05:29  *** jtimon has joined #bitcoin-core-dev
1130 2017-11-30T22:05:34  *** warxhead has quit IRC
1131 2017-11-30T22:11:35  *** Aaronvan_ has quit IRC
1132 2017-11-30T22:11:37  *** AaronvanW has joined #bitcoin-core-dev
1133 2017-11-30T22:12:20  *** Aaronvan_ has joined #bitcoin-core-dev
1134 2017-11-30T22:12:27  *** laurentmt has quit IRC
1135 2017-11-30T22:13:15  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9e38d357447e...fbce66a98267
1136 2017-11-30T22:13:15  <bitcoin-git> bitcoin/master 680bc2c practicalswift: Use range-based for loops (C++11) when looping over map elements...
1137 2017-11-30T22:13:15  <bitcoin-git> bitcoin/master fbce66a MarcoFalke: Merge #10493: Use range-based for loops (C++11) when looping over map elements...
1138 2017-11-30T22:15:35  *** AaronvanW has quit IRC
1139 2017-11-30T22:22:21  *** Vision has joined #bitcoin-core-dev
1140 2017-11-30T22:23:11  <Vision> where are the proxy settings stored for bitcoin-qt?   I cleared the proxy settings in the Options dialog, and now entering the settings dialog causes a crash.  definitely a bug.
1141 2017-11-30T22:23:17  *** AaronvanW has joined #bitcoin-core-dev
1142 2017-11-30T22:24:31  <meshcollider> Vision: what operating system?
1143 2017-11-30T22:24:41  <Vision> meshcollider: windows
1144 2017-11-30T22:25:00  *** Aaronvan_ has quit IRC
1145 2017-11-30T22:25:58  <meshcollider> Vision: in that case, the options will be in the registry, under HKEY_CURRENT_USER\Software\Bitcoin\Bitcoin-Qt iirc
1146 2017-11-30T22:26:04  <wumpus> Vision: what version?
1147 2017-11-30T22:26:08  <wumpus> (of bitcoin core)
1148 2017-11-30T22:26:24  <Vision> 15.1 64-bit
1149 2017-11-30T22:26:28  <wumpus> there was a bug in 0.15.0 which caused crashes in the settings dialog, this was fixed in 0.15.0.1 and 0.15.1
1150 2017-11-30T22:26:29  <wumpus> ok
1151 2017-11-30T22:26:34  <meshcollider> Vision: please let us know what values are in the registry before you modify them
1152 2017-11-30T22:26:38  <Vision> will do
1153 2017-11-30T22:26:48  <Vision> cuz yeah this is kinda catastrophic
1154 2017-11-30T22:26:55  <wumpus> it's better to use the flag to clear the gui settings
1155 2017-11-30T22:27:00  <wumpus> it will automatically make a backup
1156 2017-11-30T22:27:16  <meshcollider> wumpus: depends if he wants to clear all settings or just fix the proxy issue manually though :)
1157 2017-11-30T22:27:16  <wumpus> run  bitcoin-qt with -resetguisettings
1158 2017-11-30T22:27:51  <wumpus> this resets the settings and creates a guisettings.ini.bak with the old settings for troubleshooting
1159 2017-11-30T22:27:51  <Vision> looks like addrProxy is :10
1160 2017-11-30T22:27:58  <Vision> lemme change that alone and see if that fixes
1161 2017-11-30T22:28:00  <achow101> start with -resetguisettings and then drop the backup file here
1162 2017-11-30T22:28:11  <wumpus> how did you manage to get :10 in there?
1163 2017-11-30T22:28:19  <meshcollider> just :10 with no IP?
1164 2017-11-30T22:28:21  <Vision> wumpus: clearing the boxes.
1165 2017-11-30T22:28:33  <Vision> I think :10 was the port
1166 2017-11-30T22:28:50  <Vision> maybe I left the port in
1167 2017-11-30T22:28:55  <Vision> and cleared just the IP
1168 2017-11-30T22:29:03  <Vision> meshcollider: indeed
1169 2017-11-30T22:29:05  <achow101> oh, I know how it crashed
1170 2017-11-30T22:29:10  <wumpus> strange, it shouldn't save in that case, but yeah possible
1171 2017-11-30T22:29:20  <Vision> oh it saved alright.
1172 2017-11-30T22:29:38  <achow101> it splits on the colon and does [0] and [1] to get the right params. that'll be an index out of bounds
1173 2017-11-30T22:29:53  <achow101> if there's no IP and just :port
1174 2017-11-30T22:30:06  <Vision> aha :D sounds like a culprit achow101.
1175 2017-11-30T22:30:16  <Vision> yeah I guess I just cleared the IP and not port
1176 2017-11-30T22:30:26  <Vision> and fixing that in the registry DID clear up the cache.
1177 2017-11-30T22:30:36  <Vision> CRASH*
1178 2017-11-30T22:30:41  <Vision> wtf. I swear I'm not retarded.
1179 2017-11-30T22:30:42  <achow101> I don't know how it let that save though
1180 2017-11-30T22:31:18  <Vision> once I finish what I was doing I may try to replicate it
1181 2017-11-30T22:31:54  <Vision> I swear I saw the '10' jump into the IP box before the dialog closed.
1182 2017-11-30T22:31:57  <Vision> if that helps
1183 2017-11-30T22:32:58  *** Randolf has quit IRC
1184 2017-11-30T22:33:53  <Vision> aaaand I think it crashed instantly at that point.
1185 2017-11-30T22:36:05  <wumpus> it's clearly possible, though it might be that you stumbled on a very unlikely race condition. The parsing code really shouldn't crash on invalid input anyhow.
1186 2017-11-30T22:36:54  <Vision> aye
1187 2017-11-30T22:38:03  <meshcollider> Vision: were you using port 10 before you tried to clear it or is that number completely random
1188 2017-11-30T22:38:37  <Vision> yep I was
1189 2017-11-30T22:38:39  <Vision> not random
1190 2017-11-30T22:40:37  <Vision> oh yeah well that's easy to replicate
1191 2017-11-30T22:40:56  <Vision> have 'connect through socks5 proxy' checked, have an ip and port in the box, clear IP and hit OK
1192 2017-11-30T22:40:57  <Vision> instant crash
1193 2017-11-30T22:41:42  <Vision> and :port gets saved to registry
1194 2017-11-30T22:42:20  *** Guyver2 has quit IRC
1195 2017-11-30T22:44:05  <wumpus> the code here https://github.com/bitcoin/bitcoin/blob/master/src/qt/optionsmodel.cpp#L231 for ProxyIP and ProxyPORT needs to catch the condition where the list is empty, or not long enough
1196 2017-11-30T22:44:27  <meshcollider> Yep I have replicated the issue on 0.15.1
1197 2017-11-30T22:45:06  <meshcollider> wumpus: I believe that is the part where it is loaded from the registry, we should deal with this when it is saved I think
1198 2017-11-30T22:45:48  <wumpus> meshcollider: yes but the parsing should be fixed too, it'd be two lines of code or so
1199 2017-11-30T22:46:30  <wumpus> meshcollider: this is the so-manieth time we run into crashes there for one reason or another
1200 2017-11-30T22:46:46  <meshcollider> wumpus: yeah :/
1201 2017-11-30T22:47:13  <Vision> [0] days since last crash
1202 2017-11-30T22:47:13  <meshcollider> why would this validator return true for an empty string: https://github.com/bitcoin/bitcoin/blob/master/src/qt/optionsdialog.cpp#L337
1203 2017-11-30T22:50:37  <Vision> why is 9050 hardcoded in that
1204 2017-11-30T22:51:17  <meshcollider> it is the default port
1205 2017-11-30T22:51:23  <meshcollider> if no port is specified
1206 2017-11-30T22:51:33  <Vision> ah.
1207 2017-11-30T22:52:11  <Vision> just seems an odd place for it
1208 2017-11-30T22:52:20  <wumpus> that's tor's default
1209 2017-11-30T22:54:03  <Vision> (cuz it looks like it's already in src/qt/optionsmodel.cpp as default)
1210 2017-11-30T22:54:58  <wumpus> yeah, feel free to send a patch that makes it a constant instead
1211 2017-11-30T23:03:11  *** Randolf has joined #bitcoin-core-dev
1212 2017-11-30T23:10:02  *** dqx has joined #bitcoin-core-dev
1213 2017-11-30T23:11:18  *** Dizzle has quit IRC
1214 2017-11-30T23:18:49  *** promag has joined #bitcoin-core-dev
1215 2017-11-30T23:34:10  *** Cogito_Ergo_Sum has quit IRC
1216 2017-11-30T23:38:26  *** dqx has quit IRC
1217 2017-11-30T23:39:02  *** dqx has joined #bitcoin-core-dev
1218 2017-11-30T23:39:22  *** promag has quit IRC
1219 2017-11-30T23:39:25  *** titim has joined #bitcoin-core-dev
1220 2017-11-30T23:39:30  <titim> Hi
1221 2017-11-30T23:40:03  <titim> lapoda lapoda
1222 2017-11-30T23:40:17  *** titim has quit IRC
1223 2017-11-30T23:41:02  *** chjj has joined #bitcoin-core-dev
1224 2017-11-30T23:41:53  *** vicenteH has quit IRC
1225 2017-11-30T23:44:14  *** dqx has quit IRC
1226 2017-11-30T23:45:30  *** DigitalDank has joined #bitcoin-core-dev
1227 2017-11-30T23:51:48  *** DigitalDank has quit IRC
1228 2017-11-30T23:52:19  *** DigitalDank has joined #bitcoin-core-dev
1229 2017-11-30T23:57:10  *** promag has joined #bitcoin-core-dev
1230 2017-11-30T23:58:07  *** DigitalDank has quit IRC
1231 2017-11-30T23:58:42  *** bule2 has quit IRC
1232 2017-11-30T23:59:23  *** DigitalDank has joined #bitcoin-core-dev