1 2019-10-31T00:00:02  *** Guest18567 has quit IRC
  2 2019-10-31T00:07:40  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  3 2019-10-31T00:12:08  *** Highway61 has quit IRC
  4 2019-10-31T00:17:33  *** krazyj has joined #bitcoin-core-dev
  5 2019-10-31T00:19:05  *** mariorz has quit IRC
  6 2019-10-31T00:24:40  *** mariorz has joined #bitcoin-core-dev
  7 2019-10-31T00:30:03  * luke-jr wonders if it would help to get force-pushes announced here. otoh, might get spammy
  8 2019-10-31T00:37:02  *** Chris_Stewart_5 has quit IRC
  9 2019-10-31T00:45:42  *** arik_ has joined #bitcoin-core-dev
 10 2019-10-31T00:55:05  *** arik_ has quit IRC
 11 2019-10-31T00:56:39  *** arik_ has joined #bitcoin-core-dev
 12 2019-10-31T01:02:45  *** davterra has quit IRC
 13 2019-10-31T01:11:39  *** ddustin has quit IRC
 14 2019-10-31T01:12:16  *** captjakk has joined #bitcoin-core-dev
 15 2019-10-31T01:12:26  *** ddustin has joined #bitcoin-core-dev
 16 2019-10-31T01:15:47  *** EagleTM has joined #bitcoin-core-dev
 17 2019-10-31T01:16:19  *** oneark has joined #bitcoin-core-dev
 18 2019-10-31T01:16:37  *** ddustin has quit IRC
 19 2019-10-31T01:23:16  *** arik_ has quit IRC
 20 2019-10-31T01:49:00  *** lightlike has quit IRC
 21 2019-10-31T02:03:48  *** lowentropy has quit IRC
 22 2019-10-31T02:05:29  *** lowentropy has joined #bitcoin-core-dev
 23 2019-10-31T02:09:41  *** ajonas has quit IRC
 24 2019-10-31T02:16:21  *** jarthur has joined #bitcoin-core-dev
 25 2019-10-31T02:23:29  *** m1rror8955363887 has quit IRC
 26 2019-10-31T02:24:01  *** m1rror8955363887 has joined #bitcoin-core-dev
 27 2019-10-31T02:25:56  *** captjakk has quit IRC
 28 2019-10-31T02:31:39  *** EagleTM has quit IRC
 29 2019-10-31T02:46:03  *** TheHoliestRoger has quit IRC
 30 2019-10-31T02:48:16  *** TheHoliestRoger has joined #bitcoin-core-dev
 31 2019-10-31T02:54:49  *** sipa has quit IRC
 32 2019-10-31T03:00:01  *** krazyj has quit IRC
 33 2019-10-31T03:03:05  *** sipa has joined #bitcoin-core-dev
 34 2019-10-31T03:09:14  *** emilengler has quit IRC
 35 2019-10-31T03:09:34  *** emilengler has joined #bitcoin-core-dev
 36 2019-10-31T03:17:26  *** HaeB1 has joined #bitcoin-core-dev
 37 2019-10-31T03:19:08  *** felixfoertsch has joined #bitcoin-core-dev
 38 2019-10-31T03:20:02  *** felixfoertsch23 has quit IRC
 39 2019-10-31T03:30:57  *** jarthur has quit IRC
 40 2019-10-31T03:32:56  *** jarthur has joined #bitcoin-core-dev
 41 2019-10-31T04:13:10  *** spinza has joined #bitcoin-core-dev
 42 2019-10-31T04:16:54  <BlueMatt> uhhhh...hopefully there re exactly 0?
 43 2019-10-31T04:28:10  <jeremyrubin> I force push all the time :| How else do you rebase?
 44 2019-10-31T04:28:22  <BlueMatt> I figured he meant to the repo itself
 45 2019-10-31T05:07:07  *** jarthur has quit IRC
 46 2019-10-31T05:09:42  *** provoostenator has quit IRC
 47 2019-10-31T05:17:35  *** provoostenator has joined #bitcoin-core-dev
 48 2019-10-31T05:20:19  <sipa> jeremyrubin: what BlueMatt said
 49 2019-10-31T05:27:40  *** nosss2 has joined #bitcoin-core-dev
 50 2019-10-31T05:31:47  *** Victor_sueca has joined #bitcoin-core-dev
 51 2019-10-31T05:34:48  *** Victorsueca has quit IRC
 52 2019-10-31T05:44:47  *** rex4539 has quit IRC
 53 2019-10-31T06:00:01  *** HaeB1 has quit IRC
 54 2019-10-31T06:17:34  *** zxiiro_ has joined #bitcoin-core-dev
 55 2019-10-31T06:33:10  *** arik_ has joined #bitcoin-core-dev
 56 2019-10-31T07:00:38  *** arik_ has quit IRC
 57 2019-10-31T07:05:57  *** arik_ has joined #bitcoin-core-dev
 58 2019-10-31T07:36:53  *** timothy has joined #bitcoin-core-dev
 59 2019-10-31T07:41:06  *** arik_ has quit IRC
 60 2019-10-31T07:53:40  *** soju has quit IRC
 61 2019-10-31T08:14:56  *** marcoagner has joined #bitcoin-core-dev
 62 2019-10-31T08:24:32  <jeremyrubin> i think i was thrown off by luke saying spammy -- I thought we should see 0!
 63 2019-10-31T08:27:58  <wumpus> moneyball: so they have the requirement based on the age of the software apparently
 64 2019-10-31T08:29:21  <wumpus> luke-jr: afaik, force-pushes are announced here, at least the old bot did
 65 2019-10-31T08:29:28  <wumpus> there just aren't any, usually
 66 2019-10-31T08:45:51  *** jonatack has quit IRC
 67 2019-10-31T08:48:34  *** Guyver2 has joined #bitcoin-core-dev
 68 2019-10-31T08:51:51  <provoostenator> I'm able to install from the signed DMG just fine (overriding a previous installation)
 69 2019-10-31T08:55:23  *** provoostenator has quit IRC
 70 2019-10-31T09:00:02  *** zxiiro_ has quit IRC
 71 2019-10-31T09:06:59  *** aqquadro has joined #bitcoin-core-dev
 72 2019-10-31T09:07:19  *** provoostenator has joined #bitcoin-core-dev
 73 2019-10-31T09:12:23  <provoostenator> I suppose it's alright if Apple provides additional free malware review :-) (as long as they keep the right-click to install alternative)
 74 2019-10-31T09:15:52  *** ExtraCrispy has joined #bitcoin-core-dev
 75 2019-10-31T09:17:27  *** Mikaku1 has joined #bitcoin-core-dev
 76 2019-10-31T09:28:57  *** jonatack has joined #bitcoin-core-dev
 77 2019-10-31T09:37:28  *** diogosergio has joined #bitcoin-core-dev
 78 2019-10-31T09:55:56  *** JeremyCrookshank has joined #bitcoin-core-dev
 79 2019-10-31T09:56:51  <JeremyCrookshank> Any recommenced reading for Bitcoin Development?
 80 2019-10-31T10:08:49  *** aqquadro has quit IRC
 81 2019-10-31T10:13:20  *** kabaum has joined #bitcoin-core-dev
 82 2019-10-31T10:16:47  *** timothy has quit IRC
 83 2019-10-31T10:19:56  *** aqquadro has joined #bitcoin-core-dev
 84 2019-10-31T10:20:43  *** timothy has joined #bitcoin-core-dev
 85 2019-10-31T10:28:57  *** hebasto has quit IRC
 86 2019-10-31T10:30:25  *** Highway61 has joined #bitcoin-core-dev
 87 2019-10-31T10:35:25  *** hebasto has joined #bitcoin-core-dev
 88 2019-10-31T10:44:17  *** thaumavorio has quit IRC
 89 2019-10-31T10:46:18  *** thaumavorio has joined #bitcoin-core-dev
 90 2019-10-31T10:52:58  <luke-jr> wumpus: force-pushes to PRs?
 91 2019-10-31T10:53:08  <luke-jr> ie, rebases
 92 2019-10-31T10:55:38  *** setpill has joined #bitcoin-core-dev
 93 2019-10-31T10:57:50  *** bitcoin-git has joined #bitcoin-core-dev
 94 2019-10-31T10:57:51  <bitcoin-git> [bitcoin] jonatack opened pull request #17327: test: add rpc_fundrawtransaction logging (master...rpc_fundrawtransaction-test-logging) https://github.com/bitcoin/bitcoin/pull/17327
 95 2019-10-31T10:58:03  *** bitcoin-git has left #bitcoin-core-dev
 96 2019-10-31T11:04:03  *** mabox has joined #bitcoin-core-dev
 97 2019-10-31T11:04:48  *** mabox has quit IRC
 98 2019-10-31T11:07:17  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 99 2019-10-31T11:08:17  <jonatack> JeremyCrookshank: many resources here https://github.com/jonatack/bitcoin-development/blob/master/how-to-review-bitcoin-core-prs.md
100 2019-10-31T11:09:20  <provoostenator> Looks like #16697  is back. I'm seeing it again on master too....
101 2019-10-31T11:09:21  <gribble> https://github.com/bitcoin/bitcoin/issues/16697 | Unknown version bit fork activated warning · Issue #16697 · bitcoin/bitcoin · GitHub
102 2019-10-31T11:12:11  <wumpus> luke-jr: the bot only monitors the branches on the main repository, not every user's branches
103 2019-10-31T11:12:20  <wumpus> and it shouldn't imo
104 2019-10-31T11:12:51  *** ExtraCrispy has quit IRC
105 2019-10-31T11:14:39  <wumpus> provoostenator: I thought we deleted that code
106 2019-10-31T11:14:53  <wumpus> apparently not
107 2019-10-31T11:20:02  <provoostenator> Fun fact: downloading from internet is different than copying via SSH from a Gitian machine... for macOS
108 2019-10-31T11:24:47  <luke-jr> wumpus: it announces PR opens/closes
109 2019-10-31T11:26:14  <wumpus> JeremyCrookshank: https://bitcoin.org/en/developer-reference
110 2019-10-31T11:26:54  <luke-jr> provoostenator: what?
111 2019-10-31T11:27:03  <wumpus> luke-jr: right, I suppose it *could* track all user's branches too, but I think that would be a bad idea, I'm not interested in rebases on 294 open PRs
112 2019-10-31T11:27:42  <luke-jr> wumpus: it seems more interesting than DrahtBot's close/reopen Travis rebuilds ;)
113 2019-10-31T11:27:57  <luke-jr> wumpus: not all user branches are PRs tho
114 2019-10-31T11:28:32  <luke-jr> anyway, I just meant in terms of timely review of rebased PRs before they need rebase yet again a day later <.<
115 2019-10-31T11:28:34  <wumpus> it would be possible to filter out drahtbot actions
116 2019-10-31T11:38:21  <wumpus> provoostenator: windows does a similar thing, some kind of taint tracking with files, anything downloaded by the browser is suspect
117 2019-10-31T11:44:11  *** Chris_Stewart_5 has quit IRC
118 2019-10-31T11:49:22  <luke-jr> wget does it too, just doesn't warn you
119 2019-10-31T11:50:23  <luke-jr> getfattr -d on your downloads
120 2019-10-31T11:50:31  *** Chris_Stewart_5 has joined #bitcoin-core-dev
121 2019-10-31T11:53:26  *** aqquadro has quit IRC
122 2019-10-31T11:55:54  *** jonatack has quit IRC
123 2019-10-31T11:57:53  *** jonatack has joined #bitcoin-core-dev
124 2019-10-31T12:00:02  *** Mikaku1 has quit IRC
125 2019-10-31T12:09:20  *** JeremyCrookshank has quit IRC
126 2019-10-31T12:17:31  *** AngryAdmin has joined #bitcoin-core-dev
127 2019-10-31T12:24:11  *** pinheadmz_ has joined #bitcoin-core-dev
128 2019-10-31T12:24:26  *** bitcoin-git has joined #bitcoin-core-dev
129 2019-10-31T12:24:26  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/08e29473126d...feb1a8c03aff
130 2019-10-31T12:24:27  <bitcoin-git> bitcoin/master 3b3b931 Carl Dong: nsis: Write to correct filename in first place
131 2019-10-31T12:24:27  <bitcoin-git> bitcoin/master feb1a8c Wladimir J. van der Laan: Merge #17308: nsis: Write to correct filename in first place
132 2019-10-31T12:24:29  *** bitcoin-git has left #bitcoin-core-dev
133 2019-10-31T12:24:46  *** bitcoin-git has joined #bitcoin-core-dev
134 2019-10-31T12:24:46  <bitcoin-git> [bitcoin] laanwj merged pull request #17308: nsis: Write to correct filename in first place (master...2019-10-simplify-nsis-exe-rename) https://github.com/bitcoin/bitcoin/pull/17308
135 2019-10-31T12:24:48  *** bitcoin-git has left #bitcoin-core-dev
136 2019-10-31T12:26:37  *** pinheadmz has quit IRC
137 2019-10-31T12:26:37  *** pinheadmz_ is now known as pinheadmz
138 2019-10-31T12:29:12  *** m1rror8955363887 has quit IRC
139 2019-10-31T12:29:54  *** m1rror8955363887 has joined #bitcoin-core-dev
140 2019-10-31T12:32:25  *** JeremyCrookshank has joined #bitcoin-core-dev
141 2019-10-31T12:32:36  <JeremyCrookshank> jonatack & wumpus thank you
142 2019-10-31T12:33:02  <JeremyCrookshank> already done two basic GUI PRs just wanting to expand knowlege
143 2019-10-31T12:46:00  <JeremyCrookshank> will be reviewing #16432 soon
144 2019-10-31T12:46:02  <gribble> https://github.com/bitcoin/bitcoin/issues/16432 | qt: Add privacy to the Overview page by hebasto · Pull Request #16432 · bitcoin/bitcoin · GitHub
145 2019-10-31T12:50:04  *** Victor_sueca is now known as Victorsueca
146 2019-10-31T12:53:23  <instagibbs> luke-jr, I force push a ton to my PRs, it would be a bit much
147 2019-10-31T12:55:52  <luke-jr> hmm
148 2019-10-31T12:56:11  <luke-jr> maybe we should just try manually announcing when a rebase is ready
149 2019-10-31T12:59:47  <instagibbs> rebase is ready?
150 2019-10-31T12:59:56  <instagibbs> meaning, "it's ok to re-review now"?
151 2019-10-31T13:06:12  <luke-jr> right
152 2019-10-31T13:15:43  <instagibbs> I usually manually announce in the thread, yeah
153 2019-10-31T13:37:26  *** JeremyCrookshank has quit IRC
154 2019-10-31T13:41:24  *** JeremyCrookshank has joined #bitcoin-core-dev
155 2019-10-31T13:42:07  <provoostenator> I force push so much it bogs down Travis :-)
156 2019-10-31T13:44:37  *** ajonas has joined #bitcoin-core-dev
157 2019-10-31T13:46:08  *** jonatack has quit IRC
158 2019-10-31T13:46:45  *** lightlike has joined #bitcoin-core-dev
159 2019-10-31T13:59:12  *** xoyi- has joined #bitcoin-core-dev
160 2019-10-31T14:11:06  *** rex4539 has joined #bitcoin-core-dev
161 2019-10-31T14:12:15  *** rex4539 has quit IRC
162 2019-10-31T14:12:37  *** rex4539 has joined #bitcoin-core-dev
163 2019-10-31T14:16:40  *** bitcoin-git has joined #bitcoin-core-dev
164 2019-10-31T14:16:41  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/feb1a8c03aff...1c5e0ccabae1
165 2019-10-31T14:16:41  <bitcoin-git> bitcoin/master 9cae3d5 practicalswift: tests: Add fuzzer initialization (hold ECCVerifyHandle)
166 2019-10-31T14:16:41  <bitcoin-git> bitcoin/master 1c5e0cc MarcoFalke: Merge #17274: tests: Fix fuzzers eval_script and script_flags by re-adding...
167 2019-10-31T14:16:53  *** bitcoin-git has left #bitcoin-core-dev
168 2019-10-31T14:17:10  *** bitcoin-git has joined #bitcoin-core-dev
169 2019-10-31T14:17:11  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #17274: tests: Fix fuzzers eval_script and script_flags by re-adding ECCVerifyHandle dependency (master...fuzzer-initialization-follow-up) https://github.com/bitcoin/bitcoin/pull/17274
170 2019-10-31T14:17:23  *** bitcoin-git has left #bitcoin-core-dev
171 2019-10-31T14:24:52  *** sipa has quit IRC
172 2019-10-31T14:26:19  *** michaelfolkson has joined #bitcoin-core-dev
173 2019-10-31T14:35:44  *** mdunnio has joined #bitcoin-core-dev
174 2019-10-31T14:46:23  *** tsujp has quit IRC
175 2019-10-31T14:48:09  *** tsujp has joined #bitcoin-core-dev
176 2019-10-31T14:49:19  *** ExtraCrispy has joined #bitcoin-core-dev
177 2019-10-31T14:52:51  *** bitcoin-git has joined #bitcoin-core-dev
178 2019-10-31T14:52:52  <bitcoin-git> [bitcoin] darosior opened pull request #17328: GuessVerificationProgress: cap the ratio to 1 (master...fixup_getblockchaininfo) https://github.com/bitcoin/bitcoin/pull/17328
179 2019-10-31T14:52:52  *** bitcoin-git has left #bitcoin-core-dev
180 2019-10-31T15:00:01  *** AngryAdmin has quit IRC
181 2019-10-31T15:00:53  *** arik_ has joined #bitcoin-core-dev
182 2019-10-31T15:08:02  *** xoyi- has quit IRC
183 2019-10-31T15:10:12  *** rex4539 has quit IRC
184 2019-10-31T15:12:15  *** mdunnio has quit IRC
185 2019-10-31T15:12:34  *** mdunnio has joined #bitcoin-core-dev
186 2019-10-31T15:17:14  *** gdude2002 has joined #bitcoin-core-dev
187 2019-10-31T15:18:07  *** rex4539 has joined #bitcoin-core-dev
188 2019-10-31T15:39:30  *** mdunnio has quit IRC
189 2019-10-31T15:42:41  *** mdunnio has joined #bitcoin-core-dev
190 2019-10-31T15:42:51  *** captjakk has joined #bitcoin-core-dev
191 2019-10-31T15:44:45  *** tsujp has quit IRC
192 2019-10-31T15:46:06  *** captjakk_ has joined #bitcoin-core-dev
193 2019-10-31T15:46:31  *** captjakk has quit IRC
194 2019-10-31T15:47:52  *** michaelfolkson has quit IRC
195 2019-10-31T15:49:24  *** ViresNumeris21 has joined #bitcoin-core-dev
196 2019-10-31T15:49:30  *** tsujp has joined #bitcoin-core-dev
197 2019-10-31T15:58:41  *** bitcoin-git has joined #bitcoin-core-dev
198 2019-10-31T15:58:42  <bitcoin-git> [bitcoin] jnewbery opened pull request #17329: linter: Strip trailing / in path for git-subtree-check (master...2019-10-subtree-path) https://github.com/bitcoin/bitcoin/pull/17329
199 2019-10-31T15:58:43  *** bitcoin-git has left #bitcoin-core-dev
200 2019-10-31T16:00:25  *** jarthur has joined #bitcoin-core-dev
201 2019-10-31T16:02:19  *** Deinogalerix21 has joined #bitcoin-core-dev
202 2019-10-31T16:03:14  *** captjakk_ has quit IRC
203 2019-10-31T16:05:51  *** captjakk has joined #bitcoin-core-dev
204 2019-10-31T16:11:59  *** sipa has joined #bitcoin-core-dev
205 2019-10-31T16:14:40  *** AaronvanW has quit IRC
206 2019-10-31T16:17:20  *** timothy has quit IRC
207 2019-10-31T16:39:26  *** pinheadmz has quit IRC
208 2019-10-31T16:44:23  *** mdunnio has quit IRC
209 2019-10-31T16:48:42  *** AaronvanW has joined #bitcoin-core-dev
210 2019-10-31T16:49:55  *** Aaronvan_ has joined #bitcoin-core-dev
211 2019-10-31T16:53:14  *** AaronvanW has quit IRC
212 2019-10-31T16:53:16  <JeremyCrookshank> "Take pains to explain exactly what you’re doing and the reasoning behind"
213 2019-10-31T16:53:19  *** Deinogalerix21 has quit IRC
214 2019-10-31T16:53:25  <JeremyCrookshank> Pain? ;)
215 2019-10-31T16:53:32  *** jonatack has joined #bitcoin-core-dev
216 2019-10-31T16:57:18  *** jb55 has quit IRC
217 2019-10-31T16:59:32  *** captjakk has quit IRC
218 2019-10-31T16:59:55  *** Chris_Stewart_5 has quit IRC
219 2019-10-31T17:00:01  *** captjakk has joined #bitcoin-core-dev
220 2019-10-31T17:04:02  *** captjakk has quit IRC
221 2019-10-31T17:04:43  *** setpill has quit IRC
222 2019-10-31T17:07:44  *** captjakk has joined #bitcoin-core-dev
223 2019-10-31T17:10:25  *** Chris_Stewart_5 has joined #bitcoin-core-dev
224 2019-10-31T17:12:21  *** mdunnio has joined #bitcoin-core-dev
225 2019-10-31T17:13:43  *** diogosergio has quit IRC
226 2019-10-31T17:22:07  *** jonatack has quit IRC
227 2019-10-31T17:22:49  *** jonatack has joined #bitcoin-core-dev
228 2019-10-31T17:26:50  *** jonatack has quit IRC
229 2019-10-31T17:27:54  *** jonatack has joined #bitcoin-core-dev
230 2019-10-31T17:32:57  *** JeremyCrookshank has quit IRC
231 2019-10-31T17:33:54  *** Deacyde has joined #bitcoin-core-dev
232 2019-10-31T17:33:56  *** Deacydal has joined #bitcoin-core-dev
233 2019-10-31T17:36:48  *** Deacyde has quit IRC
234 2019-10-31T17:41:08  *** mdunnio_ has joined #bitcoin-core-dev
235 2019-10-31T17:41:57  *** jonatack has quit IRC
236 2019-10-31T17:42:05  *** lightlike has quit IRC
237 2019-10-31T17:44:26  *** mdunnio has quit IRC
238 2019-10-31T17:45:08  *** Chris_Stewart_5 has quit IRC
239 2019-10-31T17:46:14  *** jonatack has joined #bitcoin-core-dev
240 2019-10-31T17:46:34  *** Deacydal is now known as Deacyde
241 2019-10-31T17:47:47  *** Chris_Stewart_5 has joined #bitcoin-core-dev
242 2019-10-31T17:51:23  *** bsm1175321 has joined #bitcoin-core-dev
243 2019-10-31T17:56:17  *** bitcoin-git has joined #bitcoin-core-dev
244 2019-10-31T17:56:17  <bitcoin-git> [bitcoin] sdaftuar opened pull request #17330: [qa] Add shrinkdebugfile=0 to regtest bitcoin.conf (master...2019-10-shrinkdebugfile0) https://github.com/bitcoin/bitcoin/pull/17330
245 2019-10-31T17:56:17  *** mdunnio_ has quit IRC
246 2019-10-31T17:56:18  *** bitcoin-git has left #bitcoin-core-dev
247 2019-10-31T17:58:49  *** ddustin has joined #bitcoin-core-dev
248 2019-10-31T17:59:09  *** pinheadmz has joined #bitcoin-core-dev
249 2019-10-31T17:59:38  *** ddustin has joined #bitcoin-core-dev
250 2019-10-31T18:00:01  *** gdude2002 has quit IRC
251 2019-10-31T18:00:18  *** ddustin has quit IRC
252 2019-10-31T18:00:54  *** ddustin has joined #bitcoin-core-dev
253 2019-10-31T18:02:02  *** ddustin has joined #bitcoin-core-dev
254 2019-10-31T18:08:32  *** Aaronvan_ is now known as AaronvanW
255 2019-10-31T18:11:51  *** mdunnio has joined #bitcoin-core-dev
256 2019-10-31T18:15:08  *** mdunnio has quit IRC
257 2019-10-31T18:15:21  *** mdunnio has joined #bitcoin-core-dev
258 2019-10-31T18:36:59  *** lightlike has joined #bitcoin-core-dev
259 2019-10-31T18:40:25  *** xoyi- has joined #bitcoin-core-dev
260 2019-10-31T18:44:00  *** bitcoin-git has joined #bitcoin-core-dev
261 2019-10-31T18:44:02  <bitcoin-git> [bitcoin] MarcoFalke pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/1c5e0ccabae1...100fa0a62a29
262 2019-10-31T18:44:03  <bitcoin-git> bitcoin/master 52cf68f Russell Yanofsky: Refactor: Add GetLegacyScriptPubKeyMan helper
263 2019-10-31T18:44:03  <bitcoin-git> bitcoin/master 628d11b Russell Yanofsky: Add back mistakenly removed AssertLockHeld
264 2019-10-31T18:44:04  <bitcoin-git> bitcoin/master 2632b1f Russell Yanofsky: doc: Clarify WalletStorage / Wallet relation
265 2019-10-31T18:44:06  *** bitcoin-git has left #bitcoin-core-dev
266 2019-10-31T18:44:20  *** bitcoin-git has joined #bitcoin-core-dev
267 2019-10-31T18:44:21  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #17300: LegacyScriptPubKeyMan code cleanups (master...pr/keyman-cleanup) https://github.com/bitcoin/bitcoin/pull/17300
268 2019-10-31T18:44:33  *** bitcoin-git has left #bitcoin-core-dev
269 2019-10-31T18:46:51  *** Deacyde has quit IRC
270 2019-10-31T18:48:03  *** MasterdonX has quit IRC
271 2019-10-31T18:48:23  *** GsC_RuL3Z has joined #bitcoin-core-dev
272 2019-10-31T18:49:25  *** ViresNumeris21 has quit IRC
273 2019-10-31T18:50:40  *** MasterdonX has joined #bitcoin-core-dev
274 2019-10-31T18:52:11  *** bitcoin-git has joined #bitcoin-core-dev
275 2019-10-31T18:52:12  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/100fa0a62a29...811c381ab650
276 2019-10-31T18:52:13  <bitcoin-git> bitcoin/master 60582d6 John Newbery: [linter] Strip trailing / in path for git-subtree-check
277 2019-10-31T18:52:13  <bitcoin-git> bitcoin/master 811c381 fanquake: Merge #17329: linter: Strip trailing / in path for git-subtree-check
278 2019-10-31T18:52:15  *** bitcoin-git has left #bitcoin-core-dev
279 2019-10-31T18:52:31  *** bitcoin-git has joined #bitcoin-core-dev
280 2019-10-31T18:52:31  <bitcoin-git> [bitcoin] fanquake merged pull request #17329: linter: Strip trailing / in path for git-subtree-check (master...2019-10-subtree-path) https://github.com/bitcoin/bitcoin/pull/17329
281 2019-10-31T18:52:32  *** bitcoin-git has left #bitcoin-core-dev
282 2019-10-31T18:55:57  *** oneark has quit IRC
283 2019-10-31T18:57:55  *** reallll has joined #bitcoin-core-dev
284 2019-10-31T18:58:37  *** jonatack has quit IRC
285 2019-10-31T18:59:20  *** bitcoin-git has joined #bitcoin-core-dev
286 2019-10-31T18:59:21  <bitcoin-git> [bitcoin] achow101 opened pull request #17331: Use effective values throughout coin selection (master...effective-value) https://github.com/bitcoin/bitcoin/pull/17331
287 2019-10-31T18:59:21  *** bitcoin-git has left #bitcoin-core-dev
288 2019-10-31T18:59:48  <jeremyrubin> meeting?
289 2019-10-31T19:00:00  <warren> here
290 2019-10-31T19:00:05  <achow101> meeting?
291 2019-10-31T19:00:21  <wumpus> #startmeeting
292 2019-10-31T19:00:21  <lightningbot> Meeting started Thu Oct 31 19:00:21 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
293 2019-10-31T19:00:21  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
294 2019-10-31T19:00:43  <jnewbery> hi
295 2019-10-31T19:00:47  <warren> hi
296 2019-10-31T19:00:51  <kanzure> hi
297 2019-10-31T19:00:53  <achow101> hi
298 2019-10-31T19:00:56  <amiti> hi
299 2019-10-31T19:00:59  <moneyball> hi
300 2019-10-31T19:01:00  *** bitcoin-git has joined #bitcoin-core-dev
301 2019-10-31T19:01:01  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/811c381ab650...222b7d0ca795
302 2019-10-31T19:01:02  <bitcoin-git> bitcoin/master c5377ff Suhas Daftuar: [qa] Add shrinkdebugfile=0 to regtest bitcoin.conf
303 2019-10-31T19:01:02  <bitcoin-git> bitcoin/master 222b7d0 MarcoFalke: Merge #17330: test: Add shrinkdebugfile=0 to regtest bitcoin.conf
304 2019-10-31T19:01:04  *** bitcoin-git has left #bitcoin-core-dev
305 2019-10-31T19:01:13  <jeremyrubin> im unsure about DST
306 2019-10-31T19:01:14  *** belcher has quit IRC
307 2019-10-31T19:01:17  <jeremyrubin> Oh
308 2019-10-31T19:01:20  <sipa> hi
309 2019-10-31T19:01:20  *** bitcoin-git has joined #bitcoin-core-dev
310 2019-10-31T19:01:21  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #17330: test: Add shrinkdebugfile=0 to regtest bitcoin.conf (master...2019-10-shrinkdebugfile0) https://github.com/bitcoin/bitcoin/pull/17330
311 2019-10-31T19:01:22  *** bitcoin-git has left #bitcoin-core-dev
312 2019-10-31T19:01:46  <provoostenator> hi
313 2019-10-31T19:02:18  <wumpus> yes, DST in europe changed
314 2019-10-31T19:02:32  <wumpus> it's an hour earlier here
315 2019-10-31T19:03:03  *** reallll is now known as belcher
316 2019-10-31T19:03:05  <meshcollider> wumpus: don't forget to ping everyone :p
317 2019-10-31T19:03:07  <meshcollider> hi
318 2019-10-31T19:03:17  <fanquake> hi
319 2019-10-31T19:03:37  <wumpus> four proposed topics in https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a : "moneyball: follow-up on travis and #16148" "umpus: close Boost → C++11 migration project for now" "proposed by dongcarl: MacOS, notarization https://github.com/bitcoin/bitcoin/issues/15774" "jeremyrubin: epoch mempool"
320 2019-10-31T19:03:39  <gribble> https://github.com/bitcoin/bitcoin/issues/16148 | Travis timeouts · Issue #16148 · bitcoin/bitcoin · GitHub
321 2019-10-31T19:03:56  *** bitcoin-git has joined #bitcoin-core-dev
322 2019-10-31T19:03:56  <bitcoin-git> [bitcoin] sdaftuar opened pull request #17332: [p2p] Proof-of-concept: Improve DoS-resistance to low-work headers chains (master...2019-10-no-checkpoints-cleanedup) https://github.com/bitcoin/bitcoin/pull/17332
323 2019-10-31T19:03:57  *** bitcoin-git has left #bitcoin-core-dev
324 2019-10-31T19:04:01  <digi_james> Hi
325 2019-10-31T19:04:16  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james amiti fjahr
326 2019-10-31T19:04:29  <wumpus> #topic High priority for review
327 2019-10-31T19:04:47  <wumpus> currently 7 blockers, 7 chasing concept ACK
328 2019-10-31T19:04:49  <wumpus> https://github.com/bitcoin/bitcoin/projects/8
329 2019-10-31T19:05:23  <BlueMatt> plz2add #16974
330 2019-10-31T19:05:24  <gribble> https://github.com/bitcoin/bitcoin/issues/16974 | Walk pindexBestHeader back to ChainActive().Tip() if it is invalid by TheBlueMatt · Pull Request #16974 · bitcoin/bitcoin · GitHub
331 2019-10-31T19:05:27  *** xoyi- has quit IRC
332 2019-10-31T19:06:28  <wumpus> BlueMatt: added (to blocker I guess?)
333 2019-10-31T19:06:40  <BlueMatt> yea
334 2019-10-31T19:07:08  <BlueMatt> it blocks post-headers-over-dns rust progress (since I want to lean heavily on "I have a better header than blocks, but my peers dont have blocks" as a criteria for searching for alternate block download methods)
335 2019-10-31T19:07:27  <wumpus> yes, makes sense
336 2019-10-31T19:07:59  <wumpus> nothing else too add/remove?
337 2019-10-31T19:08:51  <wumpus> #topic close Boost → C++11 migration project for now (wumpus)
338 2019-10-31T19:09:23  <warren> too much change required?
339 2019-10-31T19:09:34  <wumpus> so it looks like all the low-hanging fruit for replacing boost has been picked now
340 2019-10-31T19:10:07  <wumpus> what remains is hard to replace with C++11 (results in very verbose code, locale dependent legacy C, or introduces harder to maintain platform-specific code)
341 2019-10-31T19:10:19  <jeremyrubin> It's basically just multiindex and boost::thread now right?
342 2019-10-31T19:10:22  <wumpus> it's kind of a time wasting trap for developers now (regarding PRs like #17245)
343 2019-10-31T19:10:24  <gribble> https://github.com/bitcoin/bitcoin/issues/17245 | wallet: Remove Boost from DecodeDumpTime by elichai · Pull Request #17245 · bitcoin/bitcoin · GitHub
344 2019-10-31T19:10:52  <wumpus> nah, people stumble over the sleep and date/time handling stuff every time
345 2019-10-31T19:11:21  <wumpus> #17307 might still be worthwhile
346 2019-10-31T19:11:23  <gribble> https://github.com/bitcoin/bitcoin/issues/17307 | Stop using `boost::thread_group` · Issue #17307 · bitcoin/bitcoin · GitHub
347 2019-10-31T19:11:31  <jeremyrubin> What about just checking in those specific copies of boost library code
348 2019-10-31T19:11:48  <sipa> after 17307, won't removing boost::threa dbe a lot easier?
349 2019-10-31T19:11:49  <jeremyrubin> Or are they too large/dependent on the rest of boost types
350 2019-10-31T19:11:50  <wumpus> but it needs to be focused, we don't want to close the same PRs time after time that don't really make it
351 2019-10-31T19:12:11  <wumpus> I think having that project open sends the wrong messag
352 2019-10-31T19:12:15  <wumpus> we can't replace boost right now
353 2019-10-31T19:12:36  <jeremyrubin> 17307, having worked on replacing thread_group in the checkqueue before, scares me a bit
354 2019-10-31T19:12:37  <sipa> agree there
355 2019-10-31T19:12:49  <wumpus> there's no need to replace, say, small string handling functions with our own impelentation, before we have a vision to replace the rest
356 2019-10-31T19:13:33  <sipa> right; until we have a reasonable way to remove multiindex (which i'm not sure will ever happen), getting rid of boost entirely is not really useful
357 2019-10-31T19:13:38  <dongcarl> Just so it's out there... we can maybe run bcp at some point when there's only one or two things left https://www.boost.org/doc/libs/1_71_0/tools/bcp/doc/html/index.html
358 2019-10-31T19:13:49  <jeremyrubin> dongcarl: ++
359 2019-10-31T19:13:55  <sipa> i do think there are individual improvements possible that dkn't go all the way, like removing boost::thread
360 2019-10-31T19:14:13  <jnewbery> I agree that if it's not a priority then the project should be closed. It can always be re-opened later if necessary.
361 2019-10-31T19:14:21  <wumpus> but in any case it doesn't seem like it needs a big coordinated project anymore
362 2019-10-31T19:14:25  <sipa> how many non-headers-only boost libs are we still using?
363 2019-10-31T19:14:39  <sipa> wumpus: agree
364 2019-10-31T19:14:45  <jnewbery> (leaving a comment in the project description explaining why it's been closed)
365 2019-10-31T19:14:58  <wumpus> when C++17 is allowed, it can be reopened
366 2019-10-31T19:15:28  <fanquake> Guess #13751 can be closed with the same rationale as well then.
367 2019-10-31T19:15:30  <gribble> https://github.com/bitcoin/bitcoin/issues/13751 | Utils and libraries: Drops the boost/algorithm/string/split.hpp dependency by l2a5b1 · Pull Request #13751 · bitcoin/bitcoin · GitHub
368 2019-10-31T19:15:35  <wumpus> fanquake: yes
369 2019-10-31T19:15:50  <wumpus> there's not really a reason to do that right now
370 2019-10-31T19:16:33  <warren> gitian binaries static link the libstdc++ so distro support won't change when C++17 happens right?
371 2019-10-31T19:16:35  *** jb55 has joined #bitcoin-core-dev
372 2019-10-31T19:16:39  *** captjakk has quit IRC
373 2019-10-31T19:16:43  <dongcarl> warren: Yes
374 2019-10-31T19:16:47  <wumpus> warren: correct, assumning we can keep the same GLIBC req
375 2019-10-31T19:16:50  <wumpus> (runtime)
376 2019-10-31T19:17:24  <wumpus> which I don't see why not
377 2019-10-31T19:17:58  <wumpus> statically linking using musl libc is another thing that might be considered in the future
378 2019-10-31T19:18:03  <wumpus> but that's a whole different topic
379 2019-10-31T19:18:15  <dongcarl> should be able to keep it as long as we 1. stick to Bionic 2. write new hooks, ick, or 3. use guix
380 2019-10-31T19:18:27  *** captjakk has joined #bitcoin-core-dev
381 2019-10-31T19:18:33  <cfields> Bionic?
382 2019-10-31T19:18:53  <dongcarl> cfields: bionic has 1.27, which is what we've written hooks to support up to
383 2019-10-31T19:18:57  *** captjakk has quit IRC
384 2019-10-31T19:19:02  <dongcarl> glibc 1.27 that is
385 2019-10-31T19:19:03  <sipa> i read "books" instead of hooks. was confused
386 2019-10-31T19:19:11  *** captjakk has joined #bitcoin-core-dev
387 2019-10-31T19:19:37  *** bitcoin-git has joined #bitcoin-core-dev
388 2019-10-31T19:19:38  <bitcoin-git> [bitcoin] fanquake closed pull request #13751: Utils and libraries: Drops the boost/algorithm/string/split.hpp dependency (master...patch/remove_boost_split) https://github.com/bitcoin/bitcoin/pull/13751
389 2019-10-31T19:19:39  <wumpus> hehe
390 2019-10-31T19:19:39  *** bitcoin-git has left #bitcoin-core-dev
391 2019-10-31T19:19:44  *** captjakk has quit IRC
392 2019-10-31T19:19:44  <jnewbery> Shall I go ahead and update the project description and then close?
393 2019-10-31T19:19:50  <wumpus> jnewbery: yes, thanks
394 2019-10-31T19:20:02  *** captjakk has joined #bitcoin-core-dev
395 2019-10-31T19:20:02  <jnewbery> ok done
396 2019-10-31T19:20:05  <wumpus> seems no one strongly disagrees
397 2019-10-31T19:20:20  <wumpus> #topic MacOS, notarization (dongcarl)
398 2019-10-31T19:20:21  *** captjakk has quit IRC
399 2019-10-31T19:20:31  <jnewbery> updated description is visible here: https://github.com/bitcoin/bitcoin/projects?query=is%3Aclosed
400 2019-10-31T19:20:59  <dongcarl> Right, here
401 2019-10-31T19:21:03  <wumpus>  #15774
402 2019-10-31T19:21:04  <gribble> https://github.com/bitcoin/bitcoin/issues/15774 | macOS App Notarization · Issue #15774 · bitcoin/bitcoin · GitHub
403 2019-10-31T19:21:08  <dongcarl> Info available here: https://developer.apple.com/documentation/xcode/notarizing_your_app_before_distribution/customizing_the_notarization_workflow
404 2019-10-31T19:21:11  <wumpus> jnewbery: great!
405 2019-10-31T19:21:18  <dongcarl> Mostly just to make people aware of what's going to happen
406 2019-10-31T19:21:30  <dongcarl> We're going to have a step in the release process that can only happen on a mac
407 2019-10-31T19:21:33  <cfields> dongcarl: I think we should consider rejecting Apple's new requirement.
408 2019-10-31T19:21:38  <wumpus> discntinuing MacOS binaries?
409 2019-10-31T19:21:56  <dongcarl> cfields: that's something I've thought about too
410 2019-10-31T19:22:03  <provoostenator> It depends on what the step is
411 2019-10-31T19:22:04  * dongcarl typing gimme a sec
412 2019-10-31T19:22:14  <cfields> I've been putting something together, probably best not to thought-dump here.
413 2019-10-31T19:22:18  <provoostenator> As long as it's easy to review the difference on a non-Mac I don't mind too much.
414 2019-10-31T19:22:33  <wumpus> htey make it harder and harder to distribute binaries for open source software
415 2019-10-31T19:22:41  <luke-jr> [19:16:33] <warren> gitian binaries static link the libstdc++ so distro support won't change when C++17 happens right? <-- gitian binaries don't matter in this regard
416 2019-10-31T19:22:49  <luke-jr> distro support is for NATIVE compiles
417 2019-10-31T19:23:01  <luke-jr> (also, gitian binaries *don't* work on all distros)
418 2019-10-31T19:23:02  <dongcarl> After we submit the app for notarization it is actually not NEEDED to staple it to the binary
419 2019-10-31T19:23:14  <dongcarl> Apparently GateKeeper will query the Apple servers
420 2019-10-31T19:23:18  <wumpus> luke-jr: that was last topic, but yes
421 2019-10-31T19:23:24  <dongcarl> Which is convenient, but gives them A LOT OF CONTROL
422 2019-10-31T19:23:28  <provoostenator> I'm not a huge fan of Apple getting a call from all our useres
423 2019-10-31T19:23:31  <luke-jr> oh, I missed the #topic line
424 2019-10-31T19:23:48  <provoostenator> So better to staple if it's not too difficult
425 2019-10-31T19:23:50  <cfields> the bigger issue is that it makes Apple the final arbiter of what people can run. In a potential emergency fork/uasf scenario, this puts them in charge. I think it would be unwise for us to participate in that.
426 2019-10-31T19:24:05  <luke-jr> wumpus: is Apple dropping support for unsigned binaries entirely?
427 2019-10-31T19:24:10  <cfields> (final arbiter once we start down the path, that is)
428 2019-10-31T19:24:19  <wumpus> yes, they want the same control as they have on iOS
429 2019-10-31T19:24:24  <provoostenator> What changes when we go down the path?
430 2019-10-31T19:24:24  <luke-jr> ugh
431 2019-10-31T19:24:37  <moneyball> luke-jr: no you can still install but you have to "right click open"
432 2019-10-31T19:24:51  <luke-jr> moneyball: right now, yes; but after these new changes?
433 2019-10-31T19:24:57  <cfields> I think it's a mistake to engage that, because we can't go back. And if they refuse to sign a soft-fork, presumably there'd be nothing we could do.
434 2019-10-31T19:25:10  <provoostenator> I don't understand why we can't go back
435 2019-10-31T19:25:12  <luke-jr> cfields: we could timebomb..
436 2019-10-31T19:25:22  <provoostenator> Do they change the installation rules once you notarize once?
437 2019-10-31T19:25:24  <luke-jr> Knots already expires 1-2 years after the release
438 2019-10-31T19:25:24  <dongcarl> I'm less worried about them refusing to sign
439 2019-10-31T19:25:38  <dongcarl> I'm more worried about them signing: we've audited this binary and it's malicious
440 2019-10-31T19:25:38  <moneyball> luke-jr: I run MacOS Catalina, am able to install 0.18 fine, and 0.19 RC3 I can install but need to "right click Open"
441 2019-10-31T19:25:40  <cfields> provoostenator: if we engage once, then it would be a regression not to continue.
442 2019-10-31T19:25:47  <dongcarl> That's a bad message to users
443 2019-10-31T19:26:00  <provoostenator> cfields: arguably we're just kicking that regression down the road
444 2019-10-31T19:26:16  <moneyball> If we make no changes, I think at minimum we need to communicate on the download site that one must "right click Open" otherwise many users will be perplexed as I was
445 2019-10-31T19:26:19  <wumpus> it's not a regression if we never start supporting it
446 2019-10-31T19:26:22  <provoostenator> Because Catalina users will encounter the regression (right click to install) now
447 2019-10-31T19:26:27  <provoostenator> Which we can delay
448 2019-10-31T19:26:34  <luke-jr> As long as users can run binaries w/o the notary, that sounds preferable
449 2019-10-31T19:26:40  <wumpus> I think it's a good point, for a project like us, to be principled about it
450 2019-10-31T19:26:43  <cfields> provoostenator: yes,( unpopular opinion time...) which is why it's worth considering dropping MacOs
451 2019-10-31T19:27:04  <luke-jr> cfields: why drop entirely?
452 2019-10-31T19:27:05  <cfields> I'm not saying that we should. I'm saying it's worth a discussion.
453 2019-10-31T19:27:15  <wumpus> only when they *require* this
454 2019-10-31T19:27:18  <wumpus> not right now
455 2019-10-31T19:27:26  <luke-jr> can't our DMG just tell them right click etc in the folde rview?
456 2019-10-31T19:27:31  <warren> are there other reasons aside from this?
457 2019-10-31T19:27:32  <wumpus> but it's a possiblility in the future
458 2019-10-31T19:28:03  <jeremyrubin> is there no more self-signing?
459 2019-10-31T19:28:03  <wumpus> if it really becomes a closed platform
460 2019-10-31T19:28:11  <sipa> cfields: stop supporting for release binarier, or stop supporting the platform? (i know the distinction is kinda vague for us, but we can still make sure our code compiles and runs fine, even if we're not providing binaries)
461 2019-10-31T19:28:22  <jeremyrubin> Can we have a binary which we get apple to sign which self-signs our binary?
462 2019-10-31T19:28:24  <wumpus> sipa: you can still build your own
463 2019-10-31T19:28:27  <wumpus> sipa: using homebrew
464 2019-10-31T19:28:49  <achow101> What changed between 0.18.x and 0.19 that 0.19 now triggers the warning but 0.18.x doesn't?
465 2019-10-31T19:28:54  <jeremyrubin> Then apple would only have to sign it once, and then that can self-sign future cores
466 2019-10-31T19:28:58  <wumpus> achow101: nothing in our code
467 2019-10-31T19:29:11  <cfields> sipa: yes, thanks for making the distinction. The first would be far less problematic.
468 2019-10-31T19:29:22  *** jarthur_ has joined #bitcoin-core-dev
469 2019-10-31T19:29:23  <dongcarl> Here's the risk that I see: someone takes our codesigned binaries, gives it to Apple, Apple maybe mistakingly decides that the binary is malicious, and now everyone's GateKeeper will ask Apple about that codesigned binary, which will give them a "THIS IS MALICIOUS" popup on double-click
470 2019-10-31T19:29:25  <achow101> wumpus: moneyball said that 0.18.x installs fine, but 0.19 doesn't, on the same system
471 2019-10-31T19:29:48  <wumpus> achow101: only because iti's more recent I think
472 2019-10-31T19:29:50  <sipa> cfields: devil's advocate... is this very different from say snap controlling our snap releases? sure, snap is not the only way you run bitcoind on ubuntu, but depending on the user's expertise there may not be that much difference in how much control those entities have over what consensus code gets adopted
473 2019-10-31T19:29:51  <cfields> dongcarl: yes, and that's inevitible. Because we ARE bitcoin core. You know, the thing they're scanning their binaries for :)
474 2019-10-31T19:29:55  <fanquake> I'd assume he'd already been running 0.18
475 2019-10-31T19:31:02  <moneyball> fanquake: me? as an experiment i installed 0.18 yesterday to compare to the experience installing 0.19
476 2019-10-31T19:31:06  <achow101> I think it would be worthwhile to investigate why that happens and see if we are able to avoid the warning without doing any apple special stuff
477 2019-10-31T19:31:08  <luke-jr> [19:27:31] <warren> are there other reasons aside from this? <-- macOS only works on backdoored hardware; macOS is proprietary; etc
478 2019-10-31T19:31:31  <fanquake> moneyball yea. I don't think the reinstalling 0.18 would make a difference though.
479 2019-10-31T19:31:42  <cfields> achow101: yes, agree.
480 2019-10-31T19:31:42  <wumpus> even google isn't aiming for that kind of total control of android
481 2019-10-31T19:31:48  <fanquake> Otherwise suddenly everyone who updated to 10.15's software would start breaking.
482 2019-10-31T19:31:57  <wumpus> sipa: your comparison would hold for the apple app store, not for things installed outside it
483 2019-10-31T19:32:01  <fanquake> I'd assume the new checks only apply to "new" binaries you are trying to run.
484 2019-10-31T19:32:13  <cfields> Admittedly I don't have enough info on this. But what I've read has really rubbed me the wrong way. So I'll shut up now and chime in on the issue instead :)
485 2019-10-31T19:32:16  <fanquake> So if you'd already been running 0.18 previously, I don't think reinstalling it is going to cause an issue.
486 2019-10-31T19:32:27  *** jarthur_ has quit IRC
487 2019-10-31T19:32:51  *** jarthur has quit IRC
488 2019-10-31T19:32:54  <sipa> wumpus: fair point; but even on android you need to explicitly enable non-play store apk sources; that seems fairly similar to the right click "open anyway"
489 2019-10-31T19:33:07  <fanquake> cfields: I assume your opinion is that we aren't shipping a macOS binary for 0.19 then? Assuming we're already at rc3?
490 2019-10-31T19:33:09  <cfields> sipa: I'll have to think about that. I think it's different.
491 2019-10-31T19:33:17  <provoostenator> I don't think it's very effective for a small (in terms of macOS user base) project to make a stance at this stage.
492 2019-10-31T19:33:19  <wumpus> sipa: yes; I definiely don't think we should stop with MacOS binaries as long as that's possible
493 2019-10-31T19:33:40  <dongcarl> Seems this is stirring up a lot of conversation, perhaps we can come back to this as the last topic?
494 2019-10-31T19:33:42  <cfields> provoostenator: then I suppose we'd need to involve more projects :)
495 2019-10-31T19:33:55  <ryanofsky> another danger of us not providing binaries is that someone else starts submitting and providing them, like happened with the snap store
496 2019-10-31T19:34:01  <sipa> cfields: as far as ideology goes, supporting osx release binaries without participating in the gatekeeper stuff perhaps has more impact than dropping support entirely
497 2019-10-31T19:34:02  <cfields> fanquake: Nah, for 0.19 I think we should just build/sign as before.
498 2019-10-31T19:34:07  <jeremyrubin> ryanofsky: +1
499 2019-10-31T19:34:09  <provoostenator> cfields: well, for starters it could be useful to get a bunch of projects together and try to get a physical meeting with Apple
500 2019-10-31T19:34:14  <wumpus> provoostenator: I'm not really interested in having it being effective as a political strategy in general
501 2019-10-31T19:34:20  <achow101> I can (probably) find a mac that doesn't have core installed and try
502 2019-10-31T19:34:21  <provoostenator> They might be open to actually fixing this.
503 2019-10-31T19:34:31  <wumpus> provoostenator: it would be a bad idea for bitcoin, so for bitcoin we should reject it
504 2019-10-31T19:34:33  <fanquake> cfields: with just a warning / opening instructions on the website / in the dmg?
505 2019-10-31T19:34:40  <sipa> provoostenator: i very much doubt that
506 2019-10-31T19:34:50  <fanquake> ^
507 2019-10-31T19:35:20  <sipa> provoostenator: i suspect that from their perspective, the fact that people can run unvetted binaries is a historical legacy that needs to be fixed :)
508 2019-10-31T19:35:23  <provoostenator> Well if the answer is "we don't want to fix this, we like a gated community" then that's a nice quote to start a boycott.
509 2019-10-31T19:35:54  <ryanofsky> dongcarl, if we do decide to "staple" the apple signature, is it still easily possible for a user to verify the executed code was built reproducibly & signed by us?
510 2019-10-31T19:36:25  <provoostenator> ^ that's the most important question imo
511 2019-10-31T19:36:27  <cfields> ryanofsky: that's already how it operates. We "staple" on the detached sig. It's easily auditable.
512 2019-10-31T19:36:32  <jeremyrubin> Odd question: if we ship a binary + a VM, can we just run it in the VM always?
513 2019-10-31T19:36:37  <wumpus> I'm not going to upload any binaries that aren't possible to verify in a distributed way
514 2019-10-31T19:36:40  <cfields> I assume it'd be the same here. If not, surely we could write a tool to handle it.
515 2019-10-31T19:37:10  <ryanofsky> ok, that's good at least
516 2019-10-31T19:37:21  <achow101> is it possible to "staple" without a mac?
517 2019-10-31T19:37:24  *** luke-jr has quit IRC
518 2019-10-31T19:37:47  <dongcarl> not possible to "staple" without a mac right now
519 2019-10-31T19:37:50  <fanquake> You'd need Xcode and associated tools
520 2019-10-31T19:37:51  <cfields> It's not possible to do the detached sigs without a mac either.. the tooling is our own.
521 2019-10-31T19:37:52  <sipa> is it possible to undo the stapling on non-mac?
522 2019-10-31T19:38:04  <cfields> Er, let me rephrase...
523 2019-10-31T19:38:36  <cfields> There's no supported way sign on non-mac as we do now, but that didn't stop us from hacking something together :)
524 2019-10-31T19:39:02  <achow101> someone would have to reverse engineer how it's "stapled" and write a tool for it for other platforms
525 2019-10-31T19:39:03  <cfields> So I assume we could do something similar again. Might turn into a 3-stage gitian build, though :(
526 2019-10-31T19:39:09  <dongcarl> what cfields said
527 2019-10-31T19:39:18  <fanquake> Liking something we can take away from this discussion: https://trac.torproject.org/projects/tor/ticket/30126
528 2019-10-31T19:39:22  <fanquake> *likely
529 2019-10-31T19:39:41  <sipa> cfields: what if instead of doing the stapling in the 2nd/3rd gitian stage, we write a tool that can compare a stapled binary against a deterministic one?
530 2019-10-31T19:39:49  <sipa> that could even remove the need for the 2nd stage we have now
531 2019-10-31T19:40:05  <wumpus> cfields: adding a slight delay is usually not a problem
532 2019-10-31T19:40:12  <dongcarl> sipa: A notarization strip tool?
533 2019-10-31T19:40:16  <sipa> dongcarl: yes
534 2019-10-31T19:40:37  <cfields> sipa: I don't think it's possible to be deterministic because of the timestamping, but maybe I'm misunderstanding.
535 2019-10-31T19:40:54  <sipa> let me start over
536 2019-10-31T19:40:56  <dongcarl> cfields: He's talking about our existing deterministic codesigned binary
537 2019-10-31T19:41:21  <sipa> do we actually care that the codesigning/timestamping/notarizing step is deterministic?
538 2019-10-31T19:41:26  <wumpus> yes
539 2019-10-31T19:41:37  <sipa> the point of determinism is showing that the shipped binaries match our source code
540 2019-10-31T19:41:49  <wumpus> at least the attach-signature step
541 2019-10-31T19:41:58  <warren> presumably the timestamp is part of the stapled part, while the executable part could be verified after stapling?
542 2019-10-31T19:42:11  <wumpus> the signing itself doesn't need to be determinsitic, it's only done once by one person
543 2019-10-31T19:42:21  <sipa> if you could *strip* the codesigning from a binary, and compare the result of that with the deterministic unsigned result, don't we achieve the same thing?
544 2019-10-31T19:42:42  <sipa> in that case the notarizing/codesigning could be done entirely outside of gitian, removing the 2 phase process we have now
545 2019-10-31T19:42:58  *** Highway62 has joined #bitcoin-core-dev
546 2019-10-31T19:43:02  <sipa> that of course only works if the stripping tool is easily auditable
547 2019-10-31T19:43:12  <cfields> sipa: I see. You'd have to trust the stripping tool and be able to audit the diff, but that could work.
548 2019-10-31T19:43:20  *** Highway61 has quit IRC
549 2019-10-31T19:43:21  *** Highway62 is now known as Highway61
550 2019-10-31T19:43:28  <sipa> right, it depends on how complicated the stripping is
551 2019-10-31T19:43:35  <wumpus> so instead of uploading my own gitian results, I'd have to upload the binary someone else sends me
552 2019-10-31T19:43:43  <cfields> sipa: IIRC there's a reason we didn't do it that way. Can't seem to remember though, maybe not.
553 2019-10-31T19:44:02  <dongcarl> how many people do the codesigning right now?
554 2019-10-31T19:44:11  <sipa> wumpus: you'd upload the codesigned binary, but the gitian results contain the non-codesigned hash
555 2019-10-31T19:44:23  <sipa> the comparison tool strips the codesigning, and compares with gitian
556 2019-10-31T19:44:23  <achow101> dongcarl: 2. cfields for windows, jonasschnelli for mac
557 2019-10-31T19:45:47  <dongcarl> right, if it's just one person for each platform then perhaps stripping is not too bad?
558 2019-10-31T19:46:02  <cfields> sipa: ah, at the time, it might've just been about the tooling. Easier to add than remove. That likely isn't an issue anymore though, there's better tooling now.
559 2019-10-31T19:46:33  <wumpus> at least now it's possible to look up the sha256 of the binaries from the SHA256SUMS.asc in gitian, and see they match, this would add an extra step
560 2019-10-31T19:46:39  <wumpus> I don't like it but ok...
561 2019-10-31T19:46:46  <sipa> wumpus: agreed, it's annoying; but needing to comply with ever-increasing notarization/codesigning requirements is also annoying
562 2019-10-31T19:47:13  <sipa> it's just an idea; no need to decide anything now
563 2019-10-31T19:47:37  <wumpus> this wouoldn't avoid that right?
564 2019-10-31T19:47:55  <fanquake> Apparently we wont actually need the secure timestamp or hardened runtime until January next year
565 2019-10-31T19:48:00  <fanquake> https://developer.apple.com/news/?id=09032019a
566 2019-10-31T19:48:16  <provoostenator> You can still put the sha of the signed binary in the gitian result, along with the sha of the stripped version.
567 2019-10-31T19:48:17  <cfields> Bitcoin 0.20 when? :p
568 2019-10-31T19:48:19  <wumpus> why even bother with bitcoincore.org uploads anymore, if you go through all these hoops, can't you put it on the app store directly?
569 2019-10-31T19:48:20  <achow101> that's in two months...
570 2019-10-31T19:48:24  <dongcarl> wumpus: this would avoid us having to reverse engineer each notarization/codesigning step and writing a tool to do it under our reproducible builds process
571 2019-10-31T19:48:35  <jeremyrubin> Here's a reductionist viewpoint: It's not worth jumping through too many hoops for apple users, because ultimately if the person shipping your kernel decides you don't want them running bitcoin, or a version of bitcoin, you're already, to put it lightly, fucked
572 2019-10-31T19:48:44  <fanquake> achow101 at least it means a 0.19.0 release is simpler...
573 2019-10-31T19:48:53  <fanquake> and gives us time to figure out future tooling
574 2019-10-31T19:49:05  <jeremyrubin> So this is maybe a problem we can't really solve for OSX users, short of giving them a liberated computer
575 2019-10-31T19:49:31  <sipa> back to short-term issue: are our processes already using the secure timestamp and/or hardened runtime?
576 2019-10-31T19:49:36  <provoostenator> wumpus: app stores come with additional problems though, like auto-update
577 2019-10-31T19:49:36  <sipa> or how hard is it to do so
578 2019-10-31T19:49:47  <wumpus> let's go to the next issue, already spent too much time on apple junk
579 2019-10-31T19:50:04  <wumpus> two topics left and 10 minutes
580 2019-10-31T19:50:07  <sipa> ok
581 2019-10-31T19:50:12  <wumpus> #topic follow-up on travis and #16148 (moneyball)
582 2019-10-31T19:50:13  <gribble> https://github.com/bitcoin/bitcoin/issues/16148 | Travis timeouts · Issue #16148 · bitcoin/bitcoin · GitHub
583 2019-10-31T19:50:41  *** luke-jr has joined #bitcoin-core-dev
584 2019-10-31T19:51:32  <wumpus> moneyball?
585 2019-10-31T19:51:38  <moneyball> hi
586 2019-10-31T19:51:50  <moneyball> my name is on the topic but it is from 1 month ago
587 2019-10-31T19:51:57  <instagibbs> moneyball, don't timeout in 10 minutes ;)
588 2019-10-31T19:51:57  <moneyball> when we discussed the same topic and said punt 1 month
589 2019-10-31T19:51:58  <wumpus> oh
590 2019-10-31T19:52:03  <moneyball> since then the PR was closed
591 2019-10-31T19:52:13  <moneyball> maybe MarcoFalke can discuss that?
592 2019-10-31T19:52:29  <moneyball> also we were wondering the status of jonasschnelli's related project
593 2019-10-31T19:52:58  <wumpus> ok, might be better to move to jeremyrubin's topic for now then
594 2019-10-31T19:53:03  <moneyball> sure
595 2019-10-31T19:53:09  <wumpus> #topic  epoch mempool (jeremyrubin)
596 2019-10-31T19:53:12  <jeremyrubin> Hi!
597 2019-10-31T19:53:31  <jeremyrubin> So Epoch Mempool is a relatively big upgrade to the way the mempool tracks relatives state
598 2019-10-31T19:53:44  <jeremyrubin> We replace a ton of std::sets with epoch tracking for touching txiters
599 2019-10-31T19:54:07  <sipa> yay
600 2019-10-31T19:54:21  <jeremyrubin> This is done because we have restrictive limits on the number of descendants, which is a problem for protocols like lightning or OP_STB
601 2019-10-31T19:54:43  <jeremyrubin> The PR is just a start, but it's a good checkpoint on improvement progress
602 2019-10-31T19:54:59  <jeremyrubin> (I will have follow ups that are further improvements)
603 2019-10-31T19:55:30  <sipa> it's clear to me that that approach in theory at least should be possible and improve performance; i haven't looked at the code
604 2019-10-31T19:55:30  <jeremyrubin> But the critical question is: what standard of "evidence" do we want to see to be comfortable with such an improvement not introducing regressions in performance?
605 2019-10-31T19:55:41  <instagibbs> it's also a problem for services due to simple transaction pinning
606 2019-10-31T19:55:47  <wumpus> is mempool performance a bottleneck?
607 2019-10-31T19:55:58  <sipa> wumpus: for increasing the mempool limits, it is
608 2019-10-31T19:56:12  <sipa> (package size, ancestor depth, ...)
609 2019-10-31T19:56:19  <wumpus> okay
610 2019-10-31T19:56:58  <instagibbs> sipa, is there a good writeup of "all" the reasons for the limits? There are 1 or 2 on suhas' writeup on the wiki, but likely not exhaustive of collective wisdom
611 2019-10-31T19:57:07  <sipa> instagibbs: not that i know
612 2019-10-31T19:57:08  <ariard> is this a change only in the way we traverse mempool sets or also in the way we compute entry feerate?
613 2019-10-31T19:57:18  <jeremyrubin> Traversal only as of now
614 2019-10-31T19:57:27  <jeremyrubin> The notes aren't really fully up-to-date either
615 2019-10-31T19:57:34  <sipa> instagibbs: and sdaftuar likely knows better than i do
616 2019-10-31T19:57:49  <instagibbs> I think I've hit up sdaftuar for all he currently has written done(which is better than 0!)
617 2019-10-31T19:58:08  <ariard> hmmmm did you spend time to think how we compute feerate? improving this point first could ease traversal
618 2019-10-31T19:58:34  <jeremyrubin> Feerate isn't really the chief issue here IMO
619 2019-10-31T19:58:36  <sipa> ariard: what do you mean by compute feerate?
620 2019-10-31T19:58:48  <instagibbs> https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Mempool-and-mining poached slides being referenced
621 2019-10-31T19:58:50  <jeremyrubin> But it does cause a lot of traversal-ing
622 2019-10-31T19:58:54  <ariard> tracking ancestor/descendant size/fees
623 2019-10-31T19:59:11  <instagibbs> the modified feerate you mean
624 2019-10-31T20:00:08  <jeremyrubin> In either case, the feerate stuff is easier to deal with as it (iirc) ends up being O(N)-ish if you traverse in the correct order.
625 2019-10-31T20:00:28  <jeremyrubin> But the speed of those traversals you have to pay on adding a txn or removing one
626 2019-10-31T20:00:30  <ariard> yes nModifiesFees
627 2019-10-31T20:00:33  <wumpus> let's wrap up please, it's almost time to close the meeting
628 2019-10-31T20:00:36  <jeremyrubin> Ok
629 2019-10-31T20:00:59  <jeremyrubin> I guess please review #17268
630 2019-10-31T20:01:01  <gribble> https://github.com/bitcoin/bitcoin/issues/17268 | Epoch Mempool by JeremyRubin · Pull Request #17268 · bitcoin/bitcoin · GitHub
631 2019-10-31T20:01:13  <wumpus> #action review #17268
632 2019-10-31T20:01:13  <luke-jr> jeremyrubin: 1) what is "epoch tracking" ?
633 2019-10-31T20:01:15  <gribble> https://github.com/bitcoin/bitcoin/issues/17268 | Epoch Mempool by JeremyRubin · Pull Request #17268 · bitcoin/bitcoin · GitHub
634 2019-10-31T20:01:21  <wumpus> #endmeeting
635 2019-10-31T20:01:21  <lightningbot> Meeting ended Thu Oct 31 20:01:21 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
636 2019-10-31T20:01:21  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-10-31-19.00.html
637 2019-10-31T20:01:21  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-10-31-19.00.txt
638 2019-10-31T20:01:21  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-10-31-19.00.log.html
639 2019-10-31T20:01:22  <instagibbs> new benchmark also https://github.com/bitcoin/bitcoin/pull/17292
640 2019-10-31T20:01:26  <sipa> jeremyrubin: it may make sense to give a 1-sentence summary :)
641 2019-10-31T20:01:53  <wumpus> cfields: I'll post the proposed 0.20 schedule soon, was waiting for -final, but seems we're almost there anyhow
642 2019-10-31T20:01:57  <jeremyrubin> We basically just keep track of the last time we looked at a TxMemPoolEntry
643 2019-10-31T20:02:18  <jeremyrubin> And if we've looked more recently than a given time, we ignore looking again.
644 2019-10-31T20:02:55  <cfields> wumpus: oh, that was a joke. I was saying we should put out 0.20 before January so we have another release under our belt before Apple decides it doesn't like our dmgs :)
645 2019-10-31T20:03:00  <jeremyrubin> Many of the algorithms in the mempool can be simplified greatly with this tactic
646 2019-10-31T20:03:03  <nickler> #proposedmeetingtopic security email address for bitcoin-core/secp256k1 (https://github.com/bitcoin-core/secp256k1/pull/679)
647 2019-10-31T20:03:42  <jeremyrubin> luke-jr: does that make sense?
648 2019-10-31T20:03:44  <luke-jr> jeremyrubin: as for standards, does it hurt performance when using policies other than Core's feerate-only one?
649 2019-10-31T20:03:46  <luke-jr> jeremyrubin: as for standards, does it hurt performance when using policies other than Core's feerate-only one?
650 2019-10-31T20:03:47  <luke-jr> jeremyrubin: eg, I would want someone to evalulate if it makes priority-based mining any slower or harder to implemented
651 2019-10-31T20:04:05  <jeremyrubin> luke-jr: Unless you have something odd, it should have no impact
652 2019-10-31T20:04:10  <sipa> luke-jr: that's completely orthogonal; it just speeds up all recursive algorithms over transactions
653 2019-10-31T20:04:13  <jeremyrubin> * negative impact
654 2019-10-31T20:04:47  <sipa> am i right: (a) there is a global epoch counter in the overall mempool; (b) every time we "iterate" in a recursive algorithm through a transaction, that transaction's timestamp is set to the mempool epoch and the epoch is incremented (c) when iterating, you can ignore any transaction whose timestamp is later than the epoch of when you started iterating; (d) you make sure there are no two recursive
655 2019-10-31T20:04:53  <sipa> algorithms simultaneously updating the...
656 2019-10-31T20:04:56  <sipa> timestamps
657 2019-10-31T20:05:04  <jeremyrubin> yes
658 2019-10-31T20:05:23  <jeremyrubin> Although there are specific cases where the recursive both updating is desirable
659 2019-10-31T20:05:28  <jeremyrubin> It's not used here
660 2019-10-31T20:06:06  <jeremyrubin> This also opens us up to really fancy pants stuff down the line like parallelized mempool traversals
661 2019-10-31T20:07:00  <jeremyrubin> Because the epochs are replacing data structures like std::set
662 2019-10-31T20:07:36  <jeremyrubin> sipa: but yeah your base understanding is spot on
663 2019-10-31T20:07:57  <jeremyrubin> THe other benefit is that we can now accumulate the results into better data structures, e.g., vec instead of set
664 2019-10-31T20:08:10  <luke-jr> jeremyrubin: not really, but I'm having some connection issues, so I may have missed parts
665 2019-10-31T20:08:17  <luke-jr> nickler: I wonder if it would make sense to simply have different PGP targets - it can be helpful to know a report was made even if you're not privy to the nature of it
666 2019-10-31T20:08:19  <luke-jr> eg, if Wladimir is preparing a final release when a security issue gets reported, he knows to check with sipa or someone else if it should get delayed
667 2019-10-31T20:09:39  <jeremyrubin> luke-jr: just read the pr if you haven't? It's like +300loc -200loc. It should have 0 impact on priority mining
668 2019-10-31T20:09:44  *** rex4539_ has joined #bitcoin-core-dev
669 2019-10-31T20:10:10  *** rex4539_ has quit IRC
670 2019-10-31T20:10:19  <jeremyrubin> You can look at just like the first couple commits, and then you'll get the gist
671 2019-10-31T20:10:32  <luke-jr> jeremyrubin: I'll have to re-read the log later when my connection is better
672 2019-10-31T20:10:33  <luke-jr> or the PR
673 2019-10-31T20:10:45  <luke-jr> k
674 2019-10-31T20:10:52  <jeremyrubin> https://github.com/bitcoin/bitcoin/pull/17268/commits/b01cdd429459a1db42a3c24b7bf141c6695e21de
675 2019-10-31T20:11:13  <jeremyrubin> https://github.com/bitcoin/bitcoin/pull/17268/commits/17a0a5214666871ea2fe7134d99733090f4acf4a
676 2019-10-31T20:11:38  <jeremyrubin> Just look at those two; that's the basic idea and the rest of the PR is just refinements/applications of that principal
677 2019-10-31T20:13:20  *** rex4539 has quit IRC
678 2019-10-31T20:14:56  <sipa> principle?
679 2019-10-31T20:21:16  *** rex4539 has joined #bitcoin-core-dev
680 2019-10-31T20:22:38  <jeremyrubin> yeah my bad
681 2019-10-31T20:22:44  *** rex4539 has quit IRC
682 2019-10-31T20:27:59  *** captjakk has joined #bitcoin-core-dev
683 2019-10-31T20:32:44  *** xoyi- has joined #bitcoin-core-dev
684 2019-10-31T20:33:34  *** EagleTM has joined #bitcoin-core-dev
685 2019-10-31T20:36:48  <nickler> luke-jr: good point. It seems like you're suggesting to use security@bitcoincore.org then? That has the downside of potentially (depending how it's actually set up) reaching more people when the report is unencrypted.
686 2019-10-31T20:36:50  *** rex4539 has joined #bitcoin-core-dev
687 2019-10-31T20:37:17  <nickler> Alternatively it's the responsibility of the secp256k1-security@bitcoincore.org people to warn Wladimir before making a release
688 2019-10-31T20:42:00  <jeremyrubin> So another topic; can we make the benchmarking framework support asymptotic testing too?
689 2019-10-31T20:42:05  <jeremyrubin> Or add a new one?
690 2019-10-31T20:42:28  <jeremyrubin> E.g., it would be nice to be able to run an algorithm 10 times with inputs that are powers of 10
691 2019-10-31T20:42:40  *** captjakk has quit IRC
692 2019-10-31T20:42:44  <jeremyrubin> And collect the outputs.
693 2019-10-31T20:43:05  <jeremyrubin> But this is incompatible with the current framework, which has a goal of having the test take a second or something
694 2019-10-31T20:43:09  *** captjakk has joined #bitcoin-core-dev
695 2019-10-31T20:43:45  *** captjakk has joined #bitcoin-core-dev
696 2019-10-31T20:44:36  *** captjakk has joined #bitcoin-core-dev
697 2019-10-31T20:44:58  *** captjakk has quit IRC
698 2019-10-31T20:45:13  *** captjakk has joined #bitcoin-core-dev
699 2019-10-31T20:46:01  *** captjakk has joined #bitcoin-core-dev
700 2019-10-31T20:49:24  <luke-jr> nickler: dunno, just a thought; also, would they warn me or other affected software too?
701 2019-10-31T20:49:43  *** xoyi- has quit IRC
702 2019-10-31T20:51:47  <luke-jr> probably a broader discussion of security handlign is desirable (to avoid a repeat of 17144, fix the "stuff never gets disclosed" issue, etc)
703 2019-10-31T20:53:35  *** ExtraCrispy has quit IRC
704 2019-10-31T20:54:37  *** Guyver2 has quit IRC
705 2019-10-31T20:57:33  *** jarthur has joined #bitcoin-core-dev
706 2019-10-31T21:00:02  *** GsC_RuL3Z has quit IRC
707 2019-10-31T21:00:19  <nickler> I guess that depends and having a defined process could be valuable. Also, making libsecp releases and asking people to update regularly would help. But for now just a contact address would already be a simple and effective improvement over the current situation.
708 2019-10-31T21:04:26  *** Chris_Stewart_5 has quit IRC
709 2019-10-31T21:17:35  *** sammuel86 has joined #bitcoin-core-dev
710 2019-10-31T21:22:04  *** mdunnio has quit IRC
711 2019-10-31T21:23:17  *** mdunnio has joined #bitcoin-core-dev
712 2019-10-31T21:27:11  *** rex4539 has quit IRC
713 2019-10-31T21:27:41  *** rex4539 has joined #bitcoin-core-dev
714 2019-10-31T21:32:38  *** arapaho has joined #bitcoin-core-dev
715 2019-10-31T21:38:44  *** rex4539 has quit IRC
716 2019-10-31T21:42:47  *** mdunnio has quit IRC
717 2019-10-31T22:01:31  *** arik_ has quit IRC
718 2019-10-31T22:03:13  *** EagleTM has quit IRC
719 2019-10-31T22:13:29  *** sipa has quit IRC
720 2019-10-31T22:13:44  *** sipa has joined #bitcoin-core-dev
721 2019-10-31T22:37:09  *** Chris_Stewart_5 has joined #bitcoin-core-dev
722 2019-10-31T22:47:29  *** soju has joined #bitcoin-core-dev
723 2019-10-31T22:48:54  *** arik_ has joined #bitcoin-core-dev
724 2019-10-31T22:53:10  *** ddustin has quit IRC
725 2019-10-31T22:54:03  *** ddustin has joined #bitcoin-core-dev
726 2019-10-31T23:08:52  *** astro has quit IRC
727 2019-10-31T23:10:15  *** bitcoin-git has joined #bitcoin-core-dev
728 2019-10-31T23:10:15  <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #17335: Add test for syncing blocks generated after invalidateblock. (master...2019-10-invalid-mine-test) https://github.com/bitcoin/bitcoin/pull/17335
729 2019-10-31T23:10:26  *** bitcoin-git has left #bitcoin-core-dev
730 2019-10-31T23:11:40  *** astro has joined #bitcoin-core-dev
731 2019-10-31T23:12:58  *** jarthur has quit IRC
732 2019-10-31T23:25:37  *** ddustin has quit IRC
733 2019-10-31T23:25:52  *** ddustin has joined #bitcoin-core-dev
734 2019-10-31T23:40:49  *** rabidus has quit IRC
735 2019-10-31T23:42:29  *** rabidus has joined #bitcoin-core-dev
736 2019-10-31T23:51:17  *** Chris_Stewart_5 has quit IRC
737 2019-10-31T23:54:00  *** bitcoin-git has joined #bitcoin-core-dev
738 2019-10-31T23:54:01  <bitcoin-git> [bitcoin] Rjected opened pull request #17336: scripts: search for first block file for linearize-data with some block files pruned (master...linearize) https://github.com/bitcoin/bitcoin/pull/17336
739 2019-10-31T23:54:06  *** Am3nadiel has joined #bitcoin-core-dev
740 2019-10-31T23:54:13  *** bitcoin-git has left #bitcoin-core-dev