1 2019-01-24T00:03:36  *** Zenton has joined #bitcoin-core-dev
  2 2019-01-24T00:14:19  *** _luc_ has joined #bitcoin-core-dev
  3 2019-01-24T00:18:27  *** miknotauro has quit IRC
  4 2019-01-24T00:28:49  *** promag has joined #bitcoin-core-dev
  5 2019-01-24T00:30:32  *** ThomasLuong has quit IRC
  6 2019-01-24T00:33:20  *** promag has quit IRC
  7 2019-01-24T00:34:30  *** jarthur has quit IRC
  8 2019-01-24T00:37:49  *** AaronvanW has quit IRC
  9 2019-01-24T01:01:33  *** Randolf has joined #bitcoin-core-dev
 10 2019-01-24T01:03:05  *** AaronvanW has joined #bitcoin-core-dev
 11 2019-01-24T01:08:26  *** AaronvanW has quit IRC
 12 2019-01-24T01:10:20  *** michaelsdunn1 has joined #bitcoin-core-dev
 13 2019-01-24T01:15:00  *** pinheadmz has quit IRC
 14 2019-01-24T01:18:06  *** michaelsdunn1 has quit IRC
 15 2019-01-24T01:22:20  *** AaronvanW has joined #bitcoin-core-dev
 16 2019-01-24T01:26:39  *** AaronvanW has quit IRC
 17 2019-01-24T01:40:07  *** AaronvanW has joined #bitcoin-core-dev
 18 2019-01-24T01:40:57  *** _luc_ has quit IRC
 19 2019-01-24T01:43:54  *** _luc_ has joined #bitcoin-core-dev
 20 2019-01-24T01:44:26  *** AaronvanW has quit IRC
 21 2019-01-24T01:47:56  *** _luc_ has quit IRC
 22 2019-01-24T01:58:39  *** AaronvanW has joined #bitcoin-core-dev
 23 2019-01-24T02:00:23  *** spinza has quit IRC
 24 2019-01-24T02:02:45  *** AaronvanW has quit IRC
 25 2019-01-24T02:05:12  *** spinza has joined #bitcoin-core-dev
 26 2019-01-24T02:17:23  *** michaelsdunn1 has joined #bitcoin-core-dev
 27 2019-01-24T02:21:16  *** mistergold has joined #bitcoin-core-dev
 28 2019-01-24T02:36:08  *** Dean_Guss has joined #bitcoin-core-dev
 29 2019-01-24T02:37:13  *** pinheadmz has joined #bitcoin-core-dev
 30 2019-01-24T02:38:55  *** DeanGuss has quit IRC
 31 2019-01-24T02:43:57  *** Murch has quit IRC
 32 2019-01-24T02:50:58  *** Murch has joined #bitcoin-core-dev
 33 2019-01-24T02:53:57  *** drexl has joined #bitcoin-core-dev
 34 2019-01-24T02:55:52  *** AaronvanW has joined #bitcoin-core-dev
 35 2019-01-24T02:59:56  *** AaronvanW has quit IRC
 36 2019-01-24T03:07:18  *** promag has joined #bitcoin-core-dev
 37 2019-01-24T03:10:26  *** pinheadmz has quit IRC
 38 2019-01-24T03:10:29  *** AaronvanW has joined #bitcoin-core-dev
 39 2019-01-24T03:11:30  *** promag has quit IRC
 40 2019-01-24T03:14:38  *** AaronvanW has quit IRC
 41 2019-01-24T03:15:01  *** Murch has quit IRC
 42 2019-01-24T03:26:18  *** miknotauro has joined #bitcoin-core-dev
 43 2019-01-24T03:27:18  *** michaelsdunn1 has quit IRC
 44 2019-01-24T03:27:59  *** michaelsdunn1 has joined #bitcoin-core-dev
 45 2019-01-24T03:29:17  *** AaronvanW has joined #bitcoin-core-dev
 46 2019-01-24T03:29:44  *** _luc_ has joined #bitcoin-core-dev
 47 2019-01-24T03:33:26  *** AaronvanW has quit IRC
 48 2019-01-24T03:33:56  *** _luc_ has quit IRC
 49 2019-01-24T03:33:57  *** Ryjl_ has joined #bitcoin-core-dev
 50 2019-01-24T03:38:06  *** DougieBot5000_ has joined #bitcoin-core-dev
 51 2019-01-24T03:38:31  *** michaelsdunn1 has quit IRC
 52 2019-01-24T03:38:36  *** DougieBot5000 has quit IRC
 53 2019-01-24T03:38:37  *** DougieBot5000_ is now known as DougieBot5000
 54 2019-01-24T03:47:06  <jonasschnelli> descriptor question: is pkh([<fingerprint>/44'/0'/0']<xpub>/1/*) equivalent to pkh(<xpub>/44'/0'/0'/1/*)?
 55 2019-01-24T03:47:09  <jonasschnelli> sipa ^
 56 2019-01-24T03:48:29  <jonasschnelli> or does the xpub represent the key at /44'/0'/0'?
 57 2019-01-24T03:50:28  *** promag has joined #bitcoin-core-dev
 58 2019-01-24T03:51:14  *** ddustin has joined #bitcoin-core-dev
 59 2019-01-24T03:54:50  *** promag has quit IRC
 60 2019-01-24T03:58:00  *** pinheadmz has joined #bitcoin-core-dev
 61 2019-01-24T04:02:04  <sipa> xpub represents the key are 44'/0'/0'
 62 2019-01-24T04:02:11  <sipa> but if so, they're equivalent
 63 2019-01-24T04:15:17  *** pinheadmz has quit IRC
 64 2019-01-24T04:15:48  *** jarthur has joined #bitcoin-core-dev
 65 2019-01-24T04:18:43  *** pinheadmz has joined #bitcoin-core-dev
 66 2019-01-24T04:23:55  *** AaronvanW has joined #bitcoin-core-dev
 67 2019-01-24T04:27:56  *** AaronvanW has quit IRC
 68 2019-01-24T04:34:18  *** pinheadmz has quit IRC
 69 2019-01-24T04:41:05  *** pinheadmz has joined #bitcoin-core-dev
 70 2019-01-24T04:42:12  *** AaronvanW has joined #bitcoin-core-dev
 71 2019-01-24T04:46:26  *** AaronvanW has quit IRC
 72 2019-01-24T04:47:03  *** Ryjl_ has quit IRC
 73 2019-01-24T04:48:34  *** AaronvanW has joined #bitcoin-core-dev
 74 2019-01-24T04:52:58  *** AaronvanW has quit IRC
 75 2019-01-24T04:57:01  *** pinheadmz has quit IRC
 76 2019-01-24T05:00:42  *** AaronvanW has joined #bitcoin-core-dev
 77 2019-01-24T05:04:56  *** AaronvanW has quit IRC
 78 2019-01-24T05:09:57  *** millerti has quit IRC
 79 2019-01-24T05:20:43  *** ccook has quit IRC
 80 2019-01-24T05:34:44  *** ccook has joined #bitcoin-core-dev
 81 2019-01-24T05:37:11  *** hebasto has joined #bitcoin-core-dev
 82 2019-01-24T05:46:16  <hebasto> fanquake: hi, would you mind reviewing #13998?
 83 2019-01-24T05:46:19  <gribble> https://github.com/bitcoin/bitcoin/issues/13998 | Scripts and tools: gitian-build.py improvements and corrections by hebasto · Pull Request #13998 · bitcoin/bitcoin · GitHub
 84 2019-01-24T06:05:32  *** jarthur has quit IRC
 85 2019-01-24T06:08:29  *** booyah_ is now known as booyah
 86 2019-01-24T06:09:26  <jonasschnelli> sipa: so the [<fingerprint>/44'/0'/0'] part is pure metadata that is irrelevant to the child-key-derivation / script derivation?
 87 2019-01-24T06:11:44  <sipa> yes
 88 2019-01-24T06:15:29  *** AaronvanW has joined #bitcoin-core-dev
 89 2019-01-24T06:20:20  *** AaronvanW has quit IRC
 90 2019-01-24T06:20:51  <gkrizek> wumpus #15196 should be ready to merge
 91 2019-01-24T06:20:54  <gribble> https://github.com/bitcoin/bitcoin/issues/15196 | [test]: Update all subprocess.check_output functions to be Python 3.4 compatible by gkrizek · Pull Request #15196 · bitcoin/bitcoin · GitHub
 92 2019-01-24T06:28:36  *** pinheadmz has joined #bitcoin-core-dev
 93 2019-01-24T06:34:08  *** AaronvanW has joined #bitcoin-core-dev
 94 2019-01-24T06:38:27  *** AaronvanW has quit IRC
 95 2019-01-24T06:41:48  *** AaronvanW has joined #bitcoin-core-dev
 96 2019-01-24T06:44:20  *** bitcoin-git has joined #bitcoin-core-dev
 97 2019-01-24T06:44:20  <bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/82cf6813a4ef...73a6bac9fffa
 98 2019-01-24T06:44:20  <bitcoin-git> bitcoin/master fdf82ba Graham Krizek: Update all subprocess.check_output functions in CI scripts to be Python 3.4 compatible...
 99 2019-01-24T06:44:20  <bitcoin-git> bitcoin/master 73a6bac Jonas Schnelli: Merge #15196: [test]: Update all subprocess.check_output functions to be Python 3.4 compatible...
100 2019-01-24T06:44:20  *** bitcoin-git has left #bitcoin-core-dev
101 2019-01-24T06:44:46  *** pinheadmz has quit IRC
102 2019-01-24T06:45:05  *** lmk22 has joined #bitcoin-core-dev
103 2019-01-24T06:45:06  *** bitcoin-git has joined #bitcoin-core-dev
104 2019-01-24T06:45:06  <bitcoin-git> [bitcoin] jonasschnelli closed pull request #15196: [test]: Update all subprocess.check_output functions to be Python 3.4 compatible (master...cron-ci-fix) https://github.com/bitcoin/bitcoin/pull/15196
105 2019-01-24T06:45:06  *** bitcoin-git has left #bitcoin-core-dev
106 2019-01-24T06:45:52  *** pinheadmz has joined #bitcoin-core-dev
107 2019-01-24T06:46:12  *** AaronvanW has quit IRC
108 2019-01-24T06:49:08  <gkrizek> Thanks jonasschnelli
109 2019-01-24T06:49:21  <jonasschnelli> gkrizek: thanks for the PR
110 2019-01-24T06:52:50  *** AaronvanW has joined #bitcoin-core-dev
111 2019-01-24T06:53:48  *** owowo has quit IRC
112 2019-01-24T06:57:16  *** AaronvanW has quit IRC
113 2019-01-24T06:57:39  *** IzooooOOO has quit IRC
114 2019-01-24T06:59:08  *** owowo has joined #bitcoin-core-dev
115 2019-01-24T07:15:34  *** _luc_ has joined #bitcoin-core-dev
116 2019-01-24T07:21:00  * luke-jr realises the gitian static binaries don't actually work on non-Ubuntu systems -.-
117 2019-01-24T07:21:16  <luke-jr> bitcoin-0.17.1/bin/bitcoin-qt: relocation error: bitcoin-0.17.1/bin/bitcoin-qt: symbol __chk_fail, version GLIBC_2.3.4 not defined in file libc.so.6 with link time reference
118 2019-01-24T07:23:33  <luke-jr> apparently since 2015, which wumpus closed with no explanation? https://github.com/bitcoin/bitcoin/issues/6628
119 2019-01-24T07:27:00  *** fanquake has joined #bitcoin-core-dev
120 2019-01-24T07:27:11  <fanquake> hebasto will do
121 2019-01-24T07:29:21  *** fanquake has quit IRC
122 2019-01-24T07:30:32  *** AaronvanW has joined #bitcoin-core-dev
123 2019-01-24T07:30:38  <aj> luke-jr: looks like it was required at one point for lsb compliance https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic.html#TBL-LIBC-SYSTE-INTS
124 2019-01-24T07:30:53  *** Randolf has quit IRC
125 2019-01-24T07:31:54  *** Randolf has joined #bitcoin-core-dev
126 2019-01-24T07:34:56  *** AaronvanW has quit IRC
127 2019-01-24T07:36:02  *** rh0nj has quit IRC
128 2019-01-24T07:37:07  *** rh0nj has joined #bitcoin-core-dev
129 2019-01-24T07:42:14  *** trillhc has joined #bitcoin-core-dev
130 2019-01-24T07:46:15  *** Dean_Guss has quit IRC
131 2019-01-24T07:46:43  *** Dean_Guss has joined #bitcoin-core-dev
132 2019-01-24T07:48:23  *** AaronvanW has joined #bitcoin-core-dev
133 2019-01-24T07:49:11  *** bitcoin-git has joined #bitcoin-core-dev
134 2019-01-24T07:49:12  <bitcoin-git> [bitcoin] kallewoof opened pull request #15241: travis: add --enable-debug macos build (master...travis-enable-debug-macos) https://github.com/bitcoin/bitcoin/pull/15241
135 2019-01-24T07:49:12  *** bitcoin-git has left #bitcoin-core-dev
136 2019-01-24T07:53:27  *** AaronvanW has quit IRC
137 2019-01-24T08:03:07  *** promag has joined #bitcoin-core-dev
138 2019-01-24T08:06:39  *** AaronvanW has joined #bitcoin-core-dev
139 2019-01-24T08:07:10  <hebasto> fanquake: thanks
140 2019-01-24T08:09:13  *** promag has quit IRC
141 2019-01-24T08:11:08  *** AaronvanW has quit IRC
142 2019-01-24T08:15:38  *** _luc_ has quit IRC
143 2019-01-24T08:17:29  *** promag has joined #bitcoin-core-dev
144 2019-01-24T08:19:44  *** pinheadmz has quit IRC
145 2019-01-24T08:21:56  *** promag has quit IRC
146 2019-01-24T08:24:33  *** AaronvanW has joined #bitcoin-core-dev
147 2019-01-24T08:28:47  *** AaronvanW has quit IRC
148 2019-01-24T08:35:37  *** AaronvanW has joined #bitcoin-core-dev
149 2019-01-24T08:39:56  *** AaronvanW has quit IRC
150 2019-01-24T08:42:07  *** luke-jr has quit IRC
151 2019-01-24T08:42:40  *** AaronvanW has joined #bitcoin-core-dev
152 2019-01-24T08:46:54  *** AaronvanW has quit IRC
153 2019-01-24T08:47:16  *** luke-jr has joined #bitcoin-core-dev
154 2019-01-24T08:48:28  *** JackH has quit IRC
155 2019-01-24T08:49:17  *** Dean_Guss has quit IRC
156 2019-01-24T08:49:40  *** Dean_Guss has joined #bitcoin-core-dev
157 2019-01-24T09:00:32  *** AaronvanW has joined #bitcoin-core-dev
158 2019-01-24T09:03:30  *** setpill has joined #bitcoin-core-dev
159 2019-01-24T09:04:56  *** AaronvanW has quit IRC
160 2019-01-24T09:15:40  *** promag has joined #bitcoin-core-dev
161 2019-01-24T09:18:12  *** AaronvanW has joined #bitcoin-core-dev
162 2019-01-24T09:22:52  *** AaronvanW has quit IRC
163 2019-01-24T09:29:02  *** fanquake has joined #bitcoin-core-dev
164 2019-01-24T09:32:10  *** JackH has joined #bitcoin-core-dev
165 2019-01-24T09:35:59  *** AaronvanW has joined #bitcoin-core-dev
166 2019-01-24T09:40:28  *** AaronvanW has quit IRC
167 2019-01-24T09:54:52  *** AaronvanW has joined #bitcoin-core-dev
168 2019-01-24T09:59:07  *** AaronvanW has quit IRC
169 2019-01-24T10:03:35  *** kexkey has quit IRC
170 2019-01-24T10:18:26  *** miknotauro has quit IRC
171 2019-01-24T10:19:04  *** Guyver2 has joined #bitcoin-core-dev
172 2019-01-24T10:19:29  *** brianhoffman has quit IRC
173 2019-01-24T10:20:03  *** ExtraCrispy has joined #bitcoin-core-dev
174 2019-01-24T10:29:22  *** AaronvanW has joined #bitcoin-core-dev
175 2019-01-24T10:43:48  *** Apocalyptic has quit IRC
176 2019-01-24T10:44:52  *** Apocalyptic has joined #bitcoin-core-dev
177 2019-01-24T10:52:29  *** zshlyk has quit IRC
178 2019-01-24T10:55:07  *** zshlyk has joined #bitcoin-core-dev
179 2019-01-24T10:59:18  *** spinza has quit IRC
180 2019-01-24T11:08:24  *** spinza has joined #bitcoin-core-dev
181 2019-01-24T11:19:28  *** laurentmt has joined #bitcoin-core-dev
182 2019-01-24T11:24:44  *** laurentmt has quit IRC
183 2019-01-24T11:27:08  *** laurentmt has joined #bitcoin-core-dev
184 2019-01-24T11:32:52  *** AaronvanW has quit IRC
185 2019-01-24T11:35:27  *** AaronvanW has joined #bitcoin-core-dev
186 2019-01-24T11:52:01  *** hebasto has quit IRC
187 2019-01-24T11:52:57  *** IZooo has joined #bitcoin-core-dev
188 2019-01-24T11:53:22  <IZooo> Hello !
189 2019-01-24T11:55:42  *** dermoth has quit IRC
190 2019-01-24T11:56:10  *** dermoth has joined #bitcoin-core-dev
191 2019-01-24T11:57:44  *** AaronvanW has quit IRC
192 2019-01-24T11:58:32  *** AaronvanW has joined #bitcoin-core-dev
193 2019-01-24T12:25:41  *** laurentmt has quit IRC
194 2019-01-24T12:27:29  *** _luc_ has joined #bitcoin-core-dev
195 2019-01-24T12:31:56  *** _luc_ has quit IRC
196 2019-01-24T12:42:22  *** promag has quit IRC
197 2019-01-24T12:55:02  *** AaronvanW has quit IRC
198 2019-01-24T13:04:46  *** AaronvanW has joined #bitcoin-core-dev
199 2019-01-24T13:15:40  *** promag has joined #bitcoin-core-dev
200 2019-01-24T13:16:47  *** _luc_ has joined #bitcoin-core-dev
201 2019-01-24T13:17:12  *** AaronvanW has quit IRC
202 2019-01-24T13:18:58  *** bitcoin-git has joined #bitcoin-core-dev
203 2019-01-24T13:18:58  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/73a6bac9fffa...5eb32d23841b
204 2019-01-24T13:18:58  <bitcoin-git> bitcoin/master 5a5ea93 David A. Harding: Doc: add information about security to the JSON-RPC doc
205 2019-01-24T13:18:58  <bitcoin-git> bitcoin/master 5eb32d2 Wladimir J. van der Laan: Merge #15223: Doc: add information about security to the JSON-RPC doc...
206 2019-01-24T13:18:58  *** bitcoin-git has left #bitcoin-core-dev
207 2019-01-24T13:19:49  *** bitcoin-git has joined #bitcoin-core-dev
208 2019-01-24T13:19:49  <bitcoin-git> [bitcoin] laanwj closed pull request #15223: Doc: add information about security to the JSON-RPC doc (master...2019-01-rpc-security) https://github.com/bitcoin/bitcoin/pull/15223
209 2019-01-24T13:19:49  *** bitcoin-git has left #bitcoin-core-dev
210 2019-01-24T13:21:26  *** _luc_ has quit IRC
211 2019-01-24T13:22:32  *** qwert has joined #bitcoin-core-dev
212 2019-01-24T13:25:49  <promag> achow101: I'm getting "libc++abi.dylib: terminating with uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument" in #15225 on startup
213 2019-01-24T13:25:51  <gribble> https://github.com/bitcoin/bitcoin/issues/15225 | GUI: Change the receive button to respond to keypool state changing by achow101 · Pull Request #15225 · bitcoin/bitcoin · GitHub
214 2019-01-24T13:26:02  *** ddustin has quit IRC
215 2019-01-24T13:26:15  <promag> rebuild does't help
216 2019-01-24T13:26:41  *** ddustin has joined #bitcoin-core-dev
217 2019-01-24T13:27:00  <promag> lldb gives "frame #9: 0x000000010033d532 bitcoin-qt`(anonymous namespace)::RNGState::MixExtract(this=0x000000010269af80, out="", num=4335447936, hasher=0x00007ffeefbfc4d8, strong_seed=<unavailable>) at random.cpp:355 [opt]"
218 2019-01-24T13:27:03  <gribble> https://github.com/bitcoin/bitcoin/issues/9 | Fix for GUI on Macs and latest wxWidgets by gavinandresen · Pull Request #9 · bitcoin/bitcoin · GitHub
219 2019-01-24T13:27:15  *** qwert has quit IRC
220 2019-01-24T13:27:20  <promag> should clear ccache? :/
221 2019-01-24T13:30:53  *** ddustin has quit IRC
222 2019-01-24T13:34:14  *** laurentmt has joined #bitcoin-core-dev
223 2019-01-24T13:53:02  *** timothy has joined #bitcoin-core-dev
224 2019-01-24T13:55:46  *** brianhoffman has joined #bitcoin-core-dev
225 2019-01-24T14:24:31  *** spinza has quit IRC
226 2019-01-24T14:25:44  *** bitcoin-git has joined #bitcoin-core-dev
227 2019-01-24T14:25:44  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5eb32d23841b...72bd4ab867e3
228 2019-01-24T14:25:44  <bitcoin-git> bitcoin/master a36d97d Suhas Daftuar: Default -whitelistforcerelay to off
229 2019-01-24T14:25:44  <bitcoin-git> bitcoin/master 72bd4ab Wladimir J. van der Laan: Merge #15193: Default -whitelistforcerelay to off...
230 2019-01-24T14:25:44  *** bitcoin-git has left #bitcoin-core-dev
231 2019-01-24T14:26:24  *** bitcoin-git has joined #bitcoin-core-dev
232 2019-01-24T14:26:24  <bitcoin-git> [bitcoin] laanwj closed pull request #15193: Default -whitelistforcerelay to off (master...2019-01-forcerelayoff) https://github.com/bitcoin/bitcoin/pull/15193
233 2019-01-24T14:26:24  *** bitcoin-git has left #bitcoin-core-dev
234 2019-01-24T14:28:32  *** spinza has joined #bitcoin-core-dev
235 2019-01-24T14:30:15  *** DrOlmer has joined #bitcoin-core-dev
236 2019-01-24T14:31:44  *** promag has quit IRC
237 2019-01-24T14:34:40  *** DrOlmer has quit IRC
238 2019-01-24T14:41:35  *** fanquake_ has joined #bitcoin-core-dev
239 2019-01-24T14:43:25  *** AaronvanW has joined #bitcoin-core-dev
240 2019-01-24T14:44:19  *** fanquake has quit IRC
241 2019-01-24T14:46:42  *** spaced0ut has joined #bitcoin-core-dev
242 2019-01-24T14:49:06  *** Aaronvan_ has joined #bitcoin-core-dev
243 2019-01-24T14:51:33  *** AaronvanW has quit IRC
244 2019-01-24T14:52:22  *** fanquake_ has quit IRC
245 2019-01-24T14:57:30  *** fanquake has joined #bitcoin-core-dev
246 2019-01-24T14:57:44  <fanquake> wumpus could you block Vant13425, they are spamming at the moment
247 2019-01-24T14:57:46  *** bitcoin-git has joined #bitcoin-core-dev
248 2019-01-24T14:57:46  <bitcoin-git> [bitcoin] jnewbery opened pull request #15243: [doc] add notes on release notes (master...release_notes) https://github.com/bitcoin/bitcoin/pull/15243
249 2019-01-24T14:57:46  *** bitcoin-git has left #bitcoin-core-dev
250 2019-01-24T15:09:36  *** elichai2 has joined #bitcoin-core-dev
251 2019-01-24T15:15:32  *** hebasto has joined #bitcoin-core-dev
252 2019-01-24T15:16:30  *** promag has joined #bitcoin-core-dev
253 2019-01-24T15:19:18  *** timothy has quit IRC
254 2019-01-24T15:19:20  <promag> achow101: sorry, it's not your PR, master fails for me. Looks like the problem was introduced in #14955
255 2019-01-24T15:19:23  <gribble> https://github.com/bitcoin/bitcoin/issues/14955 | Switch all RNG code to the built-in PRNG by sipa · Pull Request #14955 · bitcoin/bitcoin · GitHub
256 2019-01-24T15:21:26  *** cubancorona has joined #bitcoin-core-dev
257 2019-01-24T15:22:19  <sipa> promag: there is already an open PR to fix it
258 2019-01-24T15:22:56  <sipa> #15223
259 2019-01-24T15:22:58  <gribble> https://github.com/bitcoin/bitcoin/issues/15223 | Doc: add information about security to the JSON-RPC doc by harding · Pull Request #15223 · bitcoin/bitcoin · GitHub
260 2019-01-24T15:23:05  <sipa> hmm, no
261 2019-01-24T15:23:10  <promag> 15233
262 2019-01-24T15:23:12  <sipa> #15233
263 2019-01-24T15:23:14  <gribble> https://github.com/bitcoin/bitcoin/issues/15233 | Prevent mutex lock fail even if --enable-debug by AkioNak · Pull Request #15233 · bitcoin/bitcoin · GitHub
264 2019-01-24T15:24:08  <promag> how come #14955 got merged with this problem?
265 2019-01-24T15:24:12  <gribble> https://github.com/bitcoin/bitcoin/issues/14955 | Switch all RNG code to the built-in PRNG by sipa · Pull Request #14955 · bitcoin/bitcoin · GitHub
266 2019-01-24T15:25:22  *** fanquake has quit IRC
267 2019-01-24T15:25:58  <promag> provoostenator: I think you test on macos?
268 2019-01-24T15:30:36  *** michaelsdunn1 has joined #bitcoin-core-dev
269 2019-01-24T15:31:09  *** michaels_ has joined #bitcoin-core-dev
270 2019-01-24T15:34:47  *** michaelsdunn1 has quit IRC
271 2019-01-24T15:35:08  *** jhfrontz has quit IRC
272 2019-01-24T15:35:35  *** jhfrontz has joined #bitcoin-core-dev
273 2019-01-24T15:40:35  <sipa> promag: it needs --enable-debug to detect
274 2019-01-24T15:41:15  <promag> right, I have configure with CPPFLAGS=-DDEBUG_LOCKORDER
275 2019-01-24T15:42:15  <provoostenator> promag: yes
276 2019-01-24T15:42:54  <promag> actually I always have that enabled
277 2019-01-24T15:44:00  <provoostenator> That's a good one to use next time, yes. Can we make Travis do that as well?
278 2019-01-24T15:44:21  <promag> it does I think
279 2019-01-24T15:44:43  <promag> it checks lock order
280 2019-01-24T15:45:04  <provoostenator> But Travis didn't fail. Is there a test that would catch this?
281 2019-01-24T15:46:40  <sipa> travis doesn't run osx, does it?
282 2019-01-24T15:47:09  <promag> not sure, looks like this is macos only?
283 2019-01-24T15:47:14  <sipa> yes
284 2019-01-24T15:48:00  <promag> I'll review the fix
285 2019-01-24T15:48:49  *** laurentmt has quit IRC
286 2019-01-24T15:49:36  <provoostenator> Travis machine 10 cross compiles to bitcoin-x86_64-apple-darwin14, but that only compiles and doesn't run tests (obviously).
287 2019-01-24T15:50:10  <provoostenator> There's this though: https://docs.travis-ci.com/user/reference/osx/ (never tried it)
288 2019-01-24T15:53:09  <promag> ok
289 2019-01-24T15:56:47  <provoostenator> See also #15241
290 2019-01-24T15:56:49  <gribble> https://github.com/bitcoin/bitcoin/issues/15241 | travis: add --enable-debug macos build by kallewoof · Pull Request #15241 · bitcoin/bitcoin · GitHub
291 2019-01-24T15:57:08  *** pinheadmz has joined #bitcoin-core-dev
292 2019-01-24T16:07:08  *** mistergold has joined #bitcoin-core-dev
293 2019-01-24T16:09:52  *** kexkey has joined #bitcoin-core-dev
294 2019-01-24T16:17:12  *** promag has quit IRC
295 2019-01-24T16:17:40  *** setpill has quit IRC
296 2019-01-24T16:23:26  *** MrPaz has quit IRC
297 2019-01-24T16:29:34  *** promag has joined #bitcoin-core-dev
298 2019-01-24T16:33:56  *** promag has quit IRC
299 2019-01-24T16:37:34  *** miknotauro has joined #bitcoin-core-dev
300 2019-01-24T16:43:22  *** Randolf has quit IRC
301 2019-01-24T17:04:46  *** promag has joined #bitcoin-core-dev
302 2019-01-24T17:05:09  *** jhfrontz has quit IRC
303 2019-01-24T17:08:50  *** Murch has joined #bitcoin-core-dev
304 2019-01-24T17:11:11  *** Murch has quit IRC
305 2019-01-24T17:15:46  *** promag has quit IRC
306 2019-01-24T17:17:56  *** JackH has quit IRC
307 2019-01-24T17:21:40  *** sfhi has joined #bitcoin-core-dev
308 2019-01-24T17:21:53  *** ThomasLuong has joined #bitcoin-core-dev
309 2019-01-24T17:26:56  *** promag has joined #bitcoin-core-dev
310 2019-01-24T17:29:24  <wumpus> did github stop turning commit ids into links?
311 2019-01-24T17:29:53  <wumpus> seeing a lot of (ut)ACKs with commit ids that stay plain text, see e.g. https://github.com/bitcoin/bitcoin/pull/15112
312 2019-01-24T17:30:25  *** ddustin has joined #bitcoin-core-dev
313 2019-01-24T17:32:51  *** cubancorona has quit IRC
314 2019-01-24T17:33:11  *** cubancorona has joined #bitcoin-core-dev
315 2019-01-24T17:33:53  *** trillhc2 has joined #bitcoin-core-dev
316 2019-01-24T17:34:38  *** ddustin has quit IRC
317 2019-01-24T17:36:16  *** trillhc has quit IRC
318 2019-01-24T17:37:35  *** mistergo1d has joined #bitcoin-core-dev
319 2019-01-24T17:38:40  *** mistergold has quit IRC
320 2019-01-24T17:42:56  <promag> wumpus: I think that's the case when the commit is garbage
321 2019-01-24T17:43:11  <promag> and is no longer available
322 2019-01-24T17:43:47  <promag> there's also the case when 7chars is not enough
323 2019-01-24T17:44:23  <promag> enough because there's multiple commits with the same 7 initial chars
324 2019-01-24T17:57:23  *** pinheadmz has quit IRC
325 2019-01-24T17:58:07  *** miknotauro has quit IRC
326 2019-01-24T18:00:08  *** JackH has joined #bitcoin-core-dev
327 2019-01-24T18:00:37  <wumpus> promag: I'm suddenly seeing it a lot though, did everyone suddenly start mispasting commit ids?
328 2019-01-24T18:01:11  <wumpus> of course I know that a garbage commit ID won't be turned into a link
329 2019-01-24T18:02:26  <promag> idk, it must be a gh problem
330 2019-01-24T18:03:01  *** sfhi has quit IRC
331 2019-01-24T18:05:24  *** Murch has joined #bitcoin-core-dev
332 2019-01-24T18:10:43  *** bitcoin-git has joined #bitcoin-core-dev
333 2019-01-24T18:10:44  <bitcoin-git> [bitcoin] instagibbs opened pull request #15244: gdb attaching to process during tests has non-sudo solution (master...gdb_ptrace) https://github.com/bitcoin/bitcoin/pull/15244
334 2019-01-24T18:10:44  *** bitcoin-git has left #bitcoin-core-dev
335 2019-01-24T18:14:19  *** promag has quit IRC
336 2019-01-24T18:17:06  *** michaelsdunn1 has joined #bitcoin-core-dev
337 2019-01-24T18:17:06  *** michaelsdunn1 has joined #bitcoin-core-dev
338 2019-01-24T18:19:07  *** michaels_ has quit IRC
339 2019-01-24T18:23:10  *** harrigan has quit IRC
340 2019-01-24T18:23:19  *** harrigan has joined #bitcoin-core-dev
341 2019-01-24T18:31:27  *** ThomasLuong has quit IRC
342 2019-01-24T18:32:55  *** ThomasLuong has joined #bitcoin-core-dev
343 2019-01-24T18:36:35  *** pinheadmz has joined #bitcoin-core-dev
344 2019-01-24T18:37:11  *** mistergold has joined #bitcoin-core-dev
345 2019-01-24T18:40:11  *** rex4539 has quit IRC
346 2019-01-24T18:40:12  *** mistergo1d has quit IRC
347 2019-01-24T18:45:01  *** rh0nj has quit IRC
348 2019-01-24T18:46:07  *** rh0nj has joined #bitcoin-core-dev
349 2019-01-24T18:52:34  *** promag has joined #bitcoin-core-dev
350 2019-01-24T18:53:23  *** promag_ has joined #bitcoin-core-dev
351 2019-01-24T18:56:56  *** promag has quit IRC
352 2019-01-24T18:57:12  *** ddustin has joined #bitcoin-core-dev
353 2019-01-24T18:59:03  *** mistergo1d has joined #bitcoin-core-dev
354 2019-01-24T19:00:13  <achow101> meeting?
355 2019-01-24T19:00:15  <jnewbery> hi
356 2019-01-24T19:00:19  <gleb> hi
357 2019-01-24T19:00:33  <sipa> hi
358 2019-01-24T19:00:54  <wumpus> #startmeeting
359 2019-01-24T19:00:54  <lightningbot> Meeting started Thu Jan 24 19:00:54 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
360 2019-01-24T19:00:54  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
361 2019-01-24T19:00:55  <provoostenator> hi
362 2019-01-24T19:01:14  <moneyball> topic proposed by jnewbery: Chaincode summer residency: looking for (remote) mentors and recommendations for residents
363 2019-01-24T19:01:20  <sipa> suggested topic: globals and initialization order
364 2019-01-24T19:01:50  <promag_> hi
365 2019-01-24T19:01:51  <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
366 2019-01-24T19:01:54  <instagibbs> hi
367 2019-01-24T19:01:55  <meshcollider> hi
368 2019-01-24T19:01:57  *** promag_ is now known as promag
369 2019-01-24T19:01:58  <jamesob> yo
370 2019-01-24T19:02:03  <gwillen> \o
371 2019-01-24T19:02:06  <marcinja> hi
372 2019-01-24T19:02:08  *** mistergold has quit IRC
373 2019-01-24T19:02:29  <wumpus> #topic High priority for review
374 2019-01-24T19:03:02  *** a__ has joined #bitcoin-core-dev
375 2019-01-24T19:03:09  <wumpus> #11082 #14491 #14711 #14897 #15153 #15226
376 2019-01-24T19:03:13  <gribble> https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
377 2019-01-24T19:03:16  <gribble> https://github.com/bitcoin/bitcoin/issues/14491 | Allow descriptor imports with importmulti by MeshCollider · Pull Request #14491 · bitcoin/bitcoin · GitHub
378 2019-01-24T19:03:21  <gribble> https://github.com/bitcoin/bitcoin/issues/14711 | Remove uses of chainActive and mapBlockIndex in wallet code by ryanofsky · Pull Request #14711 · bitcoin/bitcoin · GitHub
379 2019-01-24T19:03:23  <gribble> https://github.com/bitcoin/bitcoin/issues/14897 | randomize GETDATA(tx) request order and introduce bias toward outbound by naumenkogs · Pull Request #14897 · bitcoin/bitcoin · GitHub
380 2019-01-24T19:03:25  <gribble> https://github.com/bitcoin/bitcoin/issues/15153 | gui: Add Open Wallet menu by promag · Pull Request #15153 · bitcoin/bitcoin · GitHub
381 2019-01-24T19:03:27  <gribble> https://github.com/bitcoin/bitcoin/issues/15226 | Allow creating blank (empty) wallets (alternative) by achow101 · Pull Request #15226 · bitcoin/bitcoin · GitHub
382 2019-01-24T19:03:47  *** Dean_Guss has quit IRC
383 2019-01-24T19:03:55  <wumpus> anything to be added or removed?
384 2019-01-24T19:04:20  <achow101> can I have #15225 on hi prio?
385 2019-01-24T19:04:23  <gribble> https://github.com/bitcoin/bitcoin/issues/15225 | GUI: Change the receive button to respond to keypool state changing by achow101 · Pull Request #15225 · bitcoin/bitcoin · GitHub
386 2019-01-24T19:04:27  <promag> regarding open wallet menu - there are concerns regarding blocking GUI - is this something to avoid or can it be improved in 0.18.1?
387 2019-01-24T19:04:30  <jamesob> #15118
388 2019-01-24T19:04:33  <gribble> https://github.com/bitcoin/bitcoin/issues/15118 | Refactor block file logic by jimpo · Pull Request #15118 · bitcoin/bitcoin · GitHub
389 2019-01-24T19:04:37  <achow101> it's actually a blocker for 15226
390 2019-01-24T19:05:07  <wumpus> 14711 should be almost mergeable
391 2019-01-24T19:05:13  <jnewbery> +1 for #15118. It blocks #14121
392 2019-01-24T19:05:15  <gribble> https://github.com/bitcoin/bitcoin/issues/15118 | Refactor block file logic by jimpo · Pull Request #15118 · bitcoin/bitcoin · GitHub
393 2019-01-24T19:05:19  <gribble> https://github.com/bitcoin/bitcoin/issues/14121 | Index for BIP 157 block filters by jimpo · Pull Request #14121 · bitcoin/bitcoin · GitHub
394 2019-01-24T19:05:22  <wumpus> though promag keeps commenting so I'm not sure xD
395 2019-01-24T19:05:39  <gwillen> I am hoping for movement on #13932 but I think it needs love from achow101 more than review at present
396 2019-01-24T19:05:42  <gribble> https://github.com/bitcoin/bitcoin/issues/13932 | Additional utility RPCs for PSBT by achow101 · Pull Request #13932 · bitcoin/bitcoin · GitHub
397 2019-01-24T19:05:55  *** michaels_ has joined #bitcoin-core-dev
398 2019-01-24T19:05:57  <achow101> gwillen: oh yeah, I forgot to update that
399 2019-01-24T19:06:06  <promag> wumpus: :(
400 2019-01-24T19:06:09  <gwillen> achow101: lmk if there's any way I can help!
401 2019-01-24T19:07:16  <wumpus> promag: I don't mean that negatively! if there's issues there's issues no matter *when* you find them, just mean it postpones the merge if there's new review comments
402 2019-01-24T19:07:58  <wumpus> ok added #15225  #15118
403 2019-01-24T19:08:00  <gribble> https://github.com/bitcoin/bitcoin/issues/15225 | GUI: Change the receive button to respond to keypool state changing by achow101 · Pull Request #15225 · bitcoin/bitcoin · GitHub
404 2019-01-24T19:08:02  <gribble> https://github.com/bitcoin/bitcoin/issues/15118 | Refactor block file logic by jimpo · Pull Request #15118 · bitcoin/bitcoin · GitHub
405 2019-01-24T19:08:05  <jamesob> wumpus: thanks
406 2019-01-24T19:08:09  <wumpus> let's also try to remove (merge) a few this weke
407 2019-01-24T19:08:36  <phantomcircuit> hi
408 2019-01-24T19:09:02  <wumpus> 8 is kind of a lot to have on the list, and closer to the release the focus shifts to the milestone instead of this list
409 2019-01-24T19:09:13  *** michaelsdunn1 has quit IRC
410 2019-01-24T19:10:00  <sdaftuar> #15141 is ready for review again btw
411 2019-01-24T19:10:03  <wumpus> so 2019-02-01 is string freeze, 2019-02-15 is feature freeze for 0.18
412 2019-01-24T19:10:04  <gribble> https://github.com/bitcoin/bitcoin/issues/15141 | Rewrite DoS interface between validation and net_processing by sdaftuar · Pull Request #15141 · bitcoin/bitcoin · GitHub
413 2019-01-24T19:10:04  <sdaftuar> oops
414 2019-01-24T19:10:18  <sdaftuar> oh, wait i did type that correcly
415 2019-01-24T19:10:26  <sipa> sdaftuar: cool will review
416 2019-01-24T19:10:27  <jonasschnelli> hi
417 2019-01-24T19:11:07  <wumpus> #topic Globals and initialization order (sipa)
418 2019-01-24T19:11:21  <sipa> hi!
419 2019-01-24T19:11:56  <sipa> we currently have a bit of a mix in the codebase for dealing with initialization order of globals
420 2019-01-24T19:12:29  <sipa> some things are explicitly initialized using init functions, called from main/test startup
421 2019-01-24T19:12:42  <sipa> some things are initialized just using global initializers
422 2019-01-24T19:13:08  <sipa> and some things are using once/init-on-first-use-block-scoped-statics
423 2019-01-24T19:13:32  <sipa> and mixing them is pretty fragile
424 2019-01-24T19:14:16  <wumpus> I prefer explicit initializer functions unless it's simply setting a value, at least it's perfectly clear what the order is in which things get initialized
425 2019-01-24T19:14:37  <wumpus> which is very important if things depend on each other
426 2019-01-24T19:14:49  <wumpus> also things running before main() is quite annoying for debugging
427 2019-01-24T19:14:52  <sipa> the problem is that with explicit initializer functions, things don't work when called from global initializer
428 2019-01-24T19:16:08  <wumpus> (and things that take significant time to run certainly shouldn't be called from global initializers, as they'll delay showing even, say, the help message, which doesn't need any initialization at all)
429 2019-01-24T19:16:32  <sipa> and i think we actually had a long-standing problem with the RNG, which was used possibly before being initialized (since #14955 it uses an init-on-first use construction, which should always be fine)
430 2019-01-24T19:16:36  <gribble> https://github.com/bitcoin/bitcoin/issues/14955 | Switch all RNG code to the built-in PRNG by sipa · Pull Request #14955 · bitcoin/bitcoin · GitHub
431 2019-01-24T19:17:18  <wumpus> anyhow that's my opinion on it, I'm aware the codebase is quite crazy in that regard, we've had initialation order issues since the first release...
432 2019-01-24T19:17:44  <promag> sipa: what's your preference?
433 2019-01-24T19:17:49  <sipa> so i'm getting more and more in favor of using this init-on-first-use construction in more places
434 2019-01-24T19:17:56  *** csknk has joined #bitcoin-core-dev
435 2019-01-24T19:17:57  <wumpus> meh
436 2019-01-24T19:18:00  <sipa> since it's compatible with everything
437 2019-01-24T19:18:12  <wumpus> it's hard to reason about
438 2019-01-24T19:18:14  *** pinheadmz has quit IRC
439 2019-01-24T19:18:35  <jimpo> I also like explicit initialization of non-trivial things
440 2019-01-24T19:18:36  <wumpus> accidentally using something before something else will suddenly change the initialization order
441 2019-01-24T19:18:38  <wumpus> instead of just fail
442 2019-01-24T19:18:46  <wumpus> we've seen that with logging, for example
443 2019-01-24T19:18:58  <sipa> that's because logging using a global initialized
444 2019-01-24T19:19:01  <provoostenator> I'm in favor of having fewer globals :-) But otherwise haven't really developed a preference in C++
445 2019-01-24T19:19:28  <promag> I prefer explicit order initialization
446 2019-01-24T19:19:49  <wumpus> initializing on first use also doesn't really regard initialization dependencies
447 2019-01-24T19:19:49  <luke-jr> wumpus: in a bad way? the only time I can think of order mattering is when we're pre-config-files-loaded
448 2019-01-24T19:20:09  <sipa> wumpus: how so?
449 2019-01-24T19:20:10  <wumpus> like "we need to have the datadirectory set before writing to it"
450 2019-01-24T19:20:13  <luke-jr> (thinking RNG specifically)
451 2019-01-24T19:20:38  <sipa> oh, i'm not really talking about application level things
452 2019-01-24T19:21:09  <sipa> more things like RNG, logging objects (not actually setting the logfile, which happens later), libsecp, ...
453 2019-01-24T19:21:21  <sipa> syncronization debugging state
454 2019-01-24T19:21:31  <wumpus> if it's really only setting a value to a data structure I agree it's different, but if there's extensive work that might depend on other or OS things, it gets hairy fast
455 2019-01-24T19:21:51  <wumpus> only allocating a data structure on first use is fine...
456 2019-01-24T19:22:03  <gmaxwell> It's also important to avoid undefined behavior over and above just avoiding doing the wrong thing.
457 2019-01-24T19:22:24  <sipa> basically the RNG right now can't use the SHA module, because the RNG is invoked from global constructors (and it works fine with it), and SHA needs explicit initialzation
458 2019-01-24T19:22:46  <wumpus> but I think we agree that global constructors are bad
459 2019-01-24T19:22:49  <wumpus> that's one thing :)
460 2019-01-24T19:23:04  <sipa> so i think there are two solutions to that... avoid global constructors everywhere, or make everything work fine on first use
461 2019-01-24T19:23:55  <wumpus> (I here mean global constructors as 'runs before main', not the static initializers that run on first use)
462 2019-01-24T19:24:03  <sipa> wumpus: right
463 2019-01-24T19:24:31  <sipa> wumpus: so what's your opinion on solving this particular issue?
464 2019-01-24T19:24:35  <gmaxwell> Or make SHA module's autodetect get resolved by the linker, using the GCC extension that does that. :P
465 2019-01-24T19:25:20  <gmaxwell> (doesn't address the general question about dependencies between global constructors)
466 2019-01-24T19:25:23  <wumpus> sipa: so move to initialization on first use or explicit initialization, whatever makes sense in the case, move away from global initializers that do anything more significant than assigning a constant value
467 2019-01-24T19:25:27  <sipa> we can get rid of all globals whose construction needs randomness, but making the SHA256 code autodetect on first use seems a simpler change
468 2019-01-24T19:25:53  <wumpus> I really like how you got rid of CInit, for example
469 2019-01-24T19:26:04  <gmaxwell> The downside of autodetect on first use is that it would make every call to sha256 slightly slower. :(
470 2019-01-24T19:26:46  <gmaxwell> One way to compensate for that would be make sure that there is a batch sha256 function that does many of them and only does the detection once, and be sure to use it where possible.
471 2019-01-24T19:27:12  <sipa> gmaxwell: hmm?
472 2019-01-24T19:27:38  <sipa> i benchmarked it as a 1.8ns slowdown here to use an on-first-use construction
473 2019-01-24T19:27:49  <gmaxwell> sipa: I assume 'autodetect on first use' means "Check a synchronized variable every time the function is run".
474 2019-01-24T19:27:55  <sipa> gmaxwell: nope!
475 2019-01-24T19:28:24  <sipa> it actually compiles to both a synchronized and unsynchronized variable, and in the initialized case, only the latter is checked
476 2019-01-24T19:28:33  <gmaxwell> Okay, 1.8ns doesn't sound that terrible. What the runtime of the function on that host?
477 2019-01-24T19:28:36  <wumpus> nice
478 2019-01-24T19:28:55  <gmaxwell> sipa: how does it know its initialized?
479 2019-01-24T19:29:26  <wumpus> though this is a compiler implementation specific thing, clang and gcc might not do it the same way?
480 2019-01-24T19:29:37  <sipa> gmaxwell: it's just a boolean; when the boolean is false, it means it could be initialized or not (to be checked using synchronized primitives), if it is true, it is guaranteed to be initialized
481 2019-01-24T19:30:10  *** pinheadmz has joined #bitcoin-core-dev
482 2019-01-24T19:30:22  <sipa> from cppreference.com:If multiple threads attempt to initialize the same static local variable concurrently, the initialization occurs exactly once (similar behavior can be obtained for arbitrary functions with std::call_once).
483 2019-01-24T19:30:26  <sipa> Note: usual implementations of this feature use variants of the double-checked locking pattern, which reduces runtime overhead for already-initialized local statics to a single non-atomic boolean comparison.
484 2019-01-24T19:30:41  <wumpus> good to know
485 2019-01-24T19:31:02  <gmaxwell> in any case, I think that seems an obviously better way to handle it. Residual performance concerns could be handled by my above batching suggestion (which would be a win regardless because of function call overheads).  MOST places where we'd have this concern wouldn't be a big performance bottleneck like sha256 is.
486 2019-01-24T19:31:19  <wumpus> exactly
487 2019-01-24T19:31:25  <wumpus> maybe sha256 is just special here
488 2019-01-24T19:31:41  <wumpus> and we can at least decide for the general case
489 2019-01-24T19:31:45  <sipa> agree
490 2019-01-24T19:32:02  <sipa> enough on this topic, i think
491 2019-01-24T19:32:05  <wumpus> ok!
492 2019-01-24T19:32:23  <gmaxwell> well I could see the same problem showing up for crc32 and being worse, because 1.8ns would be like a 2x slowdown for it. :P  but otherwise I can't come up with much where a 1.8ns slowdown would matter.
493 2019-01-24T19:32:39  <wumpus> #topic Chaincode summer residency (jnewbery)
494 2019-01-24T19:32:40  <luke-jr> could have the calls be pointers that get changed on initialisation (I thought we already did?)
495 2019-01-24T19:32:45  *** Krellan has quit IRC
496 2019-01-24T19:32:56  <jnewbery> hi
497 2019-01-24T19:33:06  <wumpus> luke-jr: that means the overhead of an indirect function call every time, that's worse than checking a boolean
498 2019-01-24T19:33:19  <jnewbery> we're hosting the next iteration of the Chaincode residency this summer
499 2019-01-24T19:33:34  <jnewbery> it'll be in our new office in Midtown Manhattan
500 2019-01-24T19:33:41  <jnewbery> details are here: https://residency.chaincode.com/
501 2019-01-24T19:34:00  <wumpus> great!
502 2019-01-24T19:34:05  <jnewbery> we'll take care of sourcing residents, paying travel/accommodation/stipend and hosting them in our office
503 2019-01-24T19:34:20  <sipa> nice!
504 2019-01-24T19:34:35  <provoostenator> nice!
505 2019-01-24T19:34:48  <jnewbery> it's 2-3 weeks of seminars followed by 2 months of project work. We're expecting the residents to make really meaningful contributions to Bitcoin Core and other Bitcoin/Lightning projects while they're here
506 2019-01-24T19:35:05  <jnewbery> I bring this up here because we need help for a couple of things:
507 2019-01-24T19:35:51  <jnewbery> 1. We (Chaincode) will be doing the heavy lifting for the seminar series and hosting, but we need (remote) mentors for the 2 month project period.
508 2019-01-24T19:36:03  <kanzure> what are the responsibilities of the mentors
509 2019-01-24T19:36:12  *** Randolf has joined #bitcoin-core-dev
510 2019-01-24T19:36:31  <jnewbery> each resident will be paired with a mentor. We're looking for 1 hour per week video calls with the resident to help guide them in their project
511 2019-01-24T19:37:13  <jnewbery> obviously chaincoders and their peers will be on hand for incidental questions during the week, and the mentor will be providing overall guidance helping with the project
512 2019-01-24T19:37:28  <meshcollider> Will the peers be chosen based on areas of knowledge
513 2019-01-24T19:37:43  <instagibbs> jnewbery, what's the action item here? ping you if interested in mentoring?
514 2019-01-24T19:38:01  <jamesob> oh don't worry instagibbs, we've already signed you up
515 2019-01-24T19:38:06  <jamesob> ;)
516 2019-01-24T19:38:08  <jnewbery> We'll try to pair residents with mentors who have overlapping interests obviously
517 2019-01-24T19:38:16  <jnewbery> instagibbs - I'll be reaching out individually
518 2019-01-24T19:38:40  <instagibbs> hah
519 2019-01-24T19:38:50  <instagibbs> ok, so check e-mails DMs
520 2019-01-24T19:39:07  <jnewbery> 2. We're looking for recommendations for residents. If you know anyone who wants to immerse themselves in Bitcoin/Lightning over summer and is excited about making a real contribution to the project, please send them our way
521 2019-01-24T19:39:23  <jnewbery> Adam Jonas is taking the lead on organizing this one
522 2019-01-24T19:39:41  <jnewbery> So you can ping him or me if you have any questions
523 2019-01-24T19:40:15  <jnewbery> that's it!
524 2019-01-24T19:40:37  <wumpus> ok! thanks for organizing this
525 2019-01-24T19:40:46  <jnewbery> We're really excited about this one. The longer format means we're expecting to have a lot of great contributions from the residents
526 2019-01-24T19:41:09  <wumpus> hope so!
527 2019-01-24T19:41:43  <wumpus> any other topics?
528 2019-01-24T19:42:19  <jnewbery> one reminder: I'd encourage people to use moneyball's #proposedmeetingtopic to propose meeting topics during the week!
529 2019-01-24T19:42:33  <gmaxwell> Could I nag for review on #14929 ?  it's getting forced to rebase faster than its being reviewed...
530 2019-01-24T19:42:36  <gribble> https://github.com/bitcoin/bitcoin/issues/14929 | net: Allow connections from misbehavior banned peers by gmaxwell · Pull Request #14929 · bitcoin/bitcoin · GitHub
531 2019-01-24T19:43:06  <sdaftuar> gmaxwell: yep i'm actually in the middle of re-reviewing so i can re-ack
532 2019-01-24T19:43:18  <wumpus> #action review #14929
533 2019-01-24T19:43:19  <sipa> add to high priority?
534 2019-01-24T19:43:21  <gribble> https://github.com/bitcoin/bitcoin/issues/14929 | net: Allow connections from misbehavior banned peers by gmaxwell · Pull Request #14929 · bitcoin/bitcoin · GitHub
535 2019-01-24T19:43:35  <wumpus> ok
536 2019-01-24T19:44:32  <gmaxwell> Thanks.
537 2019-01-24T19:46:21  <wumpus> that... concludes the meeting, I guess
538 2019-01-24T19:47:19  <wumpus> #endmeeting
539 2019-01-24T19:47:19  <lightningbot> Meeting ended Thu Jan 24 19:47:19 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
540 2019-01-24T19:47:19  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-01-24-19.00.html
541 2019-01-24T19:47:19  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-01-24-19.00.txt
542 2019-01-24T19:47:19  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-01-24-19.00.log.html
543 2019-01-24T19:48:04  <achow101> does anyone have an opinion on whether encrypting a blank wallet should generate a seed for it?
544 2019-01-24T19:48:52  <luke-jr> hmm, it might be nice to have all the security-critical stuff generated at once
545 2019-01-24T19:49:26  <luke-jr> eg, so people who have a no-RNG system can make the wallet easily on one that has a RNG and then backup/restore it
546 2019-01-24T19:49:48  <luke-jr> but that may be independent of encryption or not
547 2019-01-24T19:49:57  <wumpus> is it even sensible
548 2019-01-24T19:50:06  <wumpus> to encrypt a blank wallet? encryption only protects private data, after all
549 2019-01-24T19:50:25  <achow101> the only thing I can think of is encrypting a blank wallet and then importing privat ekeys
550 2019-01-24T19:50:48  <wumpus> ah yes
551 2019-01-24T19:52:01  <gmaxwell> I like the idea that "if you have a wallet file, you can back that up, and your backup is not likely to be surprise invalidated."
552 2019-01-24T19:52:28  <gmaxwell> under that thinking: wallets should be born encrypted and also born with their master keys.
553 2019-01-24T19:52:55  <gmaxwell> If you import things, you invalidate backups, sucks to be you.  At least the import (docs) can warn you of this.
554 2019-01-24T19:53:17  <gmaxwell> I dunno if "wallet which is blank except for imported keys" is a case we should care much about supporting.
555 2019-01-24T19:54:41  <gmaxwell> luke-jr: I'd like us to have wallet loading take the high entropy data from a loaded wallet (e.g. encrypted master key, or first key in non-encrypted wallets) and hash that into the RNG state. That would achieve what you want as a side effect.
556 2019-01-24T19:54:46  <achow101> since I want blank wallets as a stepping stone to born encrypted wallets, I prefer that encrypting would generate the seed
557 2019-01-24T19:55:00  <gmaxwell> luke-jr: (similarly, we should also be hashing any rpcauth credentials into the RNG state)
558 2019-01-24T19:55:12  <gmaxwell> I see.
559 2019-01-24T19:55:59  <achow101> but other people may want blank wallets for other reasons, which is why I ask
560 2019-01-24T19:56:01  <gmaxwell> achow101: well I don't think it would be terrible to have blank wallets with no keys in them at all. At least they'd be obviously smaller? Long term though we should try to get it so that under normal workflows if there is a file there, thats the file you should be backing up.
561 2019-01-24T19:56:27  <luke-jr> achow101: consider that some wallets might never have a seed
562 2019-01-24T19:57:17  <achow101> luke-jr: we don't make non-hd wallets anymore.
563 2019-01-24T19:57:51  <luke-jr> achow101: I'm thinking watch-JBOK-only
564 2019-01-24T19:58:07  *** csknk has quit IRC
565 2019-01-24T20:01:26  <achow101> luke-jr: right. I think that's the only case to not set a seed when encrypting
566 2019-01-24T20:01:39  *** a__ has quit IRC
567 2019-01-24T20:01:52  <luke-jr> well, watch-only means encryption is meaningless
568 2019-01-24T20:01:57  <luke-jr> so nevermind that case
569 2019-01-24T20:02:16  <achow101> oh, i thought you meant importing the privkeys
570 2019-01-24T20:02:25  *** sc_ has joined #bitcoin-core-dev
571 2019-01-24T20:02:30  <luke-jr> I suppose there might be a use case for that
572 2019-01-24T20:02:46  <achow101> (that's what we were taling about earlier)
573 2019-01-24T20:02:48  *** sc_ is now known as Guest55956
574 2019-01-24T20:02:49  <luke-jr> but that seems roughly equivalent to non-HD wallets which isn't supported
575 2019-01-24T20:05:28  <gwillen> I mean, it still makes sense to have support for legacy imported non-HD wallets
576 2019-01-24T20:05:37  <luke-jr> gwillen: sure
577 2019-01-24T20:05:55  <luke-jr> but the topic is strictly new wallets AFAIK
578 2019-01-24T20:06:04  <gwillen> in fact, I think in the multiwallet world, it would make sense to split wallets into like (*) normal HD wallets, (*) watchonly wallets, (*) legacy importonly wallet
579 2019-01-24T20:06:09  <gwillen> *nods*
580 2019-01-24T20:06:30  <gwillen> but if you're going to import privkeys then you do want a blank empty wallet with no seed and encryption
581 2019-01-24T20:07:12  <gmaxwell> I don't think we generally want to support that case so much as to special case it.
582 2019-01-24T20:07:26  <gmaxwell> Having an extra seed and keys you don't use is harmless.
583 2019-01-24T20:07:49  <gwillen> well, I'm afraid of it leading to "oopses"
584 2019-01-24T20:07:53  <gmaxwell> (other than making the wallet bigger, but it's already going to be fairly big if you're importing a bunch of keys)
585 2019-01-24T20:08:06  <luke-jr> gmaxwell: well, you don't want to accidentally use one of the keys
586 2019-01-24T20:08:12  <gmaxwell> any manual private key handling already leads to oopses, which is why we already strongly discourage it.
587 2019-01-24T20:08:14  <gwillen> like, when I was testing my new offline signing stuff, it autogenerated a change address using the wallet seed that I didn't want
588 2019-01-24T20:08:18  <gwillen> and sent my change to it, oops
589 2019-01-24T20:08:40  <gmaxwell> And exactly what would an imported keys only wallet do?
590 2019-01-24T20:08:43  <gwillen> which I realized about 10 minutes before doing a live demo and frantically sent it back ;-)
591 2019-01-24T20:08:58  <gwillen> I mean, it would let you spend from your legacy keys from your old wallet
592 2019-01-24T20:09:10  <gwillen> although I guess that's messy if you don't spend all at once
593 2019-01-24T20:09:15  <luke-jr> gmaxwell: if it has no solution, throw an error
594 2019-01-24T20:09:18  <gwillen> because you still have to handle change _somehow_
595 2019-01-24T20:09:22  <achow101> gwillen: that implies address reuse, no?
596 2019-01-24T20:09:23  <gmaxwell> gwillen: right.
597 2019-01-24T20:09:36  <gmaxwell> It implies: this is just not a supported case.
598 2019-01-24T20:09:49  <luke-jr> you might have imported a keypool too
599 2019-01-24T20:10:05  <luke-jr> not sure if it's possible to mark them as such, but we do allow manually specifying change addresses
600 2019-01-24T20:10:23  <gmaxwell> If you're going to manually specify change addresses, you don't have gwillen's problem.
601 2019-01-24T20:10:45  <luke-jr> gmaxwell: if you forget to, it's better to get an exception than potentially lose funds
602 2019-01-24T20:12:07  <achow101> I think the question is really whether this is a case that happens frequently enough that it is something we should support
603 2019-01-24T20:12:28  <gmaxwell> There are 1001 other wallet features that deserve love, attention, writing, and review...  going through and breaking the design assumption that you can always get a key from a signable wallet just to support a currently unsupported and known risky usage, seems like a really bad idea. Esp when the subject of doing it came up as an excercise in thinking about how some other case is handled,
604 2019-01-24T20:12:28  <gmaxwell> rather than someone showing up and saying "it should support this and heres why"
605 2019-01-24T20:12:29  <achow101> to support it requires adding more parameters to encryptwallet and getting a born encrypted wallet needs another step
606 2019-01-24T20:12:46  <luke-jr> achow101: I can't think of a good reason to support it
607 2019-01-24T20:13:48  <luke-jr> any case where it *might* make sense can also do a watch-only wallet and provide private keys to signraw as needed I think
608 2019-01-24T20:15:57  <achow101> agreed
609 2019-01-24T20:17:18  <gmaxwell> unrelated, it would be kinda neat if there were a backupwallet rpc that made a watching wallet by playing the keypools arbritarily far forward and then writing out a wallet without private keys.
610 2019-01-24T20:19:31  *** hebasto has quit IRC
611 2019-01-24T20:21:38  <provoostenator> gmaxwell: or just use a descriptor to import whatever you want in a watch-only wallet, requires: #14075
612 2019-01-24T20:21:41  <gribble> https://github.com/bitcoin/bitcoin/issues/14075 | Import watch only pubkeys to the keypool if private keys are disabled by achow101 · Pull Request #14075 · bitcoin/bitcoin · GitHub
613 2019-01-24T20:23:11  <gmaxwell> Using a single descriptor forces you to use security toxic non-hardened keys. Plus doing that (using the descriptor at all) violates the principle that directly handling keys is risky and fault prone.
614 2019-01-24T20:23:53  <gmaxwell> Note that descriptors don't have checksums, a simple typo or copy-paste error can result in your funds blasting off into space.
615 2019-01-24T20:24:18  <provoostenator> achow: as for encrypting an empty wallet, easiest might be to just a bool param where user can decide if a seed is added
616 2019-01-24T20:24:52  <sipa> gmaxwell: the idea is for descriptor wallets to contained cached pre-expanded public keys
617 2019-01-24T20:25:03  <provoostenator> gmaxwell: you could use hardened derivation too if you include a private key in the descriptor (which is not saved)
618 2019-01-24T20:25:13  <provoostenator> (and that currently doesn't work probably)
619 2019-01-24T20:25:25  <sipa> so you can use hardened bip32 keys as descriptor; they need access to the private key to derive, but not to otherwise use
620 2019-01-24T20:26:11  <gmaxwell> provoostenator: fair on that point, doesn't address my second point... and that also means you're likely leaving private keys in your shell history.
621 2019-01-24T20:26:48  <gwillen> hrm, why do descriptors _not_ have checksums?
622 2019-01-24T20:26:59  *** promag has quit IRC
623 2019-01-24T20:27:17  <gwillen> given their intended uses it seems like maybe they should
624 2019-01-24T20:27:21  <gmaxwell> because they weren't intended to be some general construct for transporting keys around?
625 2019-01-24T20:27:21  <sipa> gwillen: they're human editable
626 2019-01-24T20:27:22  <provoostenator> gmaxwell: assuming the private keys are on a different device,  that device could return an array of descriptors, one for each pubkey, in import format.
627 2019-01-24T20:27:39  <provoostenator> As for checksums: that sounds solveable.
628 2019-01-24T20:27:56  <gmaxwell> provoostenator: sweet, then you get a multiplicative blowup in possibilities to corrupt the data and cause funds to go off into space.
629 2019-01-24T20:28:08  <sipa> gwillen: inside the wallet we could store them with a checksum, or even have a more efficient binary encoding
630 2019-01-24T20:28:14  <gwillen> *nods*
631 2019-01-24T20:28:40  <sipa> which would still be human accessible for transport, if they're intended to be treated as a black box
632 2019-01-24T20:28:56  <gmaxwell> sipa: but its when humans touch them that they're most likely to get corrupted.
633 2019-01-24T20:29:22  <gmaxwell> (as the now hundreds of millions lost in eth land due to corrupted addresses attest to...)
634 2019-01-24T20:29:38  <gmaxwell> (humans and application boundaries)
635 2019-01-24T20:30:13  <gmaxwell> The original descriptor work was largely wallet internal... it's mostly later efforts that have been turning them into a general key import/export thing.  This seems ill-advised to me.
636 2019-01-24T20:30:19  <provoostenator> So we need something to replace xpub that has a better checksum? Or does that still data corruption risk? Because something goes wrong inside of Bitcoin Core during the import?
637 2019-01-24T20:31:27  <gmaxwell> xpub actually has a checksum, it's sufficient, as it was intended for use as an address.
638 2019-01-24T20:32:29  <provoostenator> In #14912 I'm using xpubs all the way. The HWI tool (achow101) gets xpub(s) from the device.
639 2019-01-24T20:32:34  <gribble> https://github.com/bitcoin/bitcoin/issues/14912 | [WIP] External signer support (e.g. hardware wallet) by Sjors · Pull Request #14912 · bitcoin/bitcoin · GitHub
640 2019-01-24T20:32:59  <provoostenator> (though I'm not sure _how_ they are obtained from the device, that's probably worth double checking)
641 2019-01-24T20:33:10  <gmaxwell> Corruption inside bitcoin is also a concern, but a strictly less serious one than corruption by humans or across application boundaries.
642 2019-01-24T20:33:19  <provoostenator> If the device spits out a normal public key and the script converts it to an xpub then there's no point.
643 2019-01-24T20:33:33  <achow101> provoostenator: it depends on the device. some give xpubs, other give pubkeys + chaincode which then become xpubs
644 2019-01-24T20:33:39  <gmaxwell> For HWI you might want to consider an enrolling process that gets a signed message with one of the imported watch keys, to prove that the device can sign for the keys you're importing.
645 2019-01-24T20:33:59  <provoostenator> Also there's a feature to show an address on the device display. We could make that mandatory for the receive address functionality to be on the safe side.
646 2019-01-24T20:34:17  <gmaxwell> Which is analogous to the process bitcoin uses internally when generating keys: it signs a message and verifies, to make sure that the generated address/key actually work.
647 2019-01-24T20:34:42  <achow101> gmaxwell: currently we have a displayaddress command where the address for a given derivation path is shown on the device's screen (if it has one). you can then compare that to the address the wallet gives you for that path
648 2019-01-24T20:35:18  <provoostenator> Though perhaps betetr is to 1) import using xpubs and then 2) checking all imported keys with a call to the device
649 2019-01-24T20:35:20  <gmaxwell> achow101: thats good, but I think thats more effective at checking for correct pairing than checking for corruption.
650 2019-01-24T20:36:24  <gmaxwell> getting the device to sign something that you can verify is probably the gold standard for corruption checking. I'm not sure about how the devices work, but is it currently possible to import a device that you don't know the pin for, thus cannot actually sign with?
651 2019-01-24T20:37:18  <provoostenator> You can always forget the pin and lose your backup. But the normal flow is that you unlock the device with the pin before it's willing to give your computer any pubkeys.
652 2019-01-24T20:37:28  *** mistergold has joined #bitcoin-core-dev
653 2019-01-24T20:37:45  <achow101> i think for all devices you need the pin/passphrase to do anything with it
654 2019-01-24T20:38:16  <provoostenator> Capabilities vary per deivce, see this table: https://github.com/achow101/HWI#device-support
655 2019-01-24T20:39:14  <gmaxwell> Okay, thats useful. I'm not sure if there are other ways that you could export keys but turn out not to be able to sign, except a device fault.
656 2019-01-24T20:39:22  <provoostenator> Ideally we'd ask the device to sign something to prove it really has the keys. I don't know if devices can do that though, especially without user interaction.
657 2019-01-24T20:39:49  <gmaxwell> ISTM that it wouldn't be too hard for the enrollment process though to ask the device to sign a message.. you're user interacting on the import to enter the pin in any case, no?
658 2019-01-24T20:39:54  <achow101> signing anything requires user interaction
659 2019-01-24T20:40:03  <achow101> otherwise it would be a huge security hole
660 2019-01-24T20:40:07  <gmaxwell> But so does the import?
661 2019-01-24T20:40:16  *** Randolf has quit IRC
662 2019-01-24T20:40:23  <provoostenator> gmaxwell: the problem is that the device probably only signs 1 thing at a time, so checking 1000 addresses would be tedious.
663 2019-01-24T20:40:34  <gmaxwell> I don't think it's necessary to check all the addresses.
664 2019-01-24T20:40:39  <provoostenator> So then the next best thing is essentially just importing again and double checking.
665 2019-01-24T20:40:40  <gmaxwell> But it's a big gain to check at least one.
666 2019-01-24T20:41:03  <gmaxwell> provoostenator: importing again doesn't tell you that the device actually can sign, however.
667 2019-01-24T20:41:28  *** mistergo1d has quit IRC
668 2019-01-24T20:41:55  <achow101> for implementation with core, you could definitely make it import then sign a message
669 2019-01-24T20:42:05  <achow101> right now where using HWI is manual, you do that manually
670 2019-01-24T20:42:56  <gmaxwell> So for example, imagine a device doing public derrivation, botches the generation of the public key, and it caches that value (since its slow I bet all implementations store it).  Any number of imports would give keys, they'd all look fine, but the device would fail to be able to sign for any of its keys.
671 2019-01-24T20:43:05  <provoostenator> I suspect most devices don't cache public keys, and only store the seed. So if they can derive a valid address they can sign it.
672 2019-01-24T20:43:17  <gmaxwell> With public derrivation in use, I can't think of any likely issue where it could sign for one key but not another.
673 2019-01-24T20:43:23  <provoostenator> (until they can't, which is where backups become important)
674 2019-01-24T20:44:09  <gmaxwell> If they don't cache the master pubkey, then indeed multiple imports would be different under that proposed failure mode.
675 2019-01-24T20:44:37  <achow101> I don't think they cache the pubkeys, but that could change at any time and be different between devices
676 2019-01-24T20:44:43  <gmaxwell> Though a 'also try to get a signed message on import' would catch faults in both implementations.
677 2019-01-24T20:45:01  <achow101> deriving multiple keys with just different indexes is slow as fuck on all devices
678 2019-01-24T20:45:04  <gmaxwell> Basically getting a signature is a fully general test to make sure signing works.
679 2019-01-24T20:45:37  <gmaxwell> achow101: I was thinking they'd cache the master, not the child keys. but who knows, as you note it could change at any time.
680 2019-01-24T20:45:37  <provoostenator> To the degree cache exists, it might also be ephemeral, so in that case asking the user to unplug and replug, might help.
681 2019-01-24T20:45:50  <provoostenator> But this all varies per device. I agree signing would be better.
682 2019-01-24T20:46:15  <achow101> gmaxwell: they all require hardened derivation at some point IIRC, so caching the master wouldn't be particularly helpful
683 2019-01-24T20:46:15  <provoostenator> But devices don't like having code that can sign arbitrary stuff, for risk of an attacking abusing that.
684 2019-01-24T20:46:21  <gmaxwell> right. Well we can only go so far too. :)  But the standard we've set internally to bitcoin core is sign-after-generate.
685 2019-01-24T20:46:38  <provoostenator> (sign arbitrary stuff without user approving, and checking all the details)
686 2019-01-24T20:47:01  <gmaxwell> At enrollment time, a user approving one signature seems reasonsable.
687 2019-01-24T20:47:12  <provoostenator> "internally to bitcoin core is sign-after-generate" - I didn't know we did that, that seems smart.
688 2019-01-24T20:47:36  *** cubancorona has quit IRC
689 2019-01-24T20:48:05  <gmaxwell> It's a response to a real failure-- in other wallet software a few years back-- that resulted in an extreme amount funds loss (that unfortunately is non-public).
690 2019-01-24T20:48:11  <provoostenator> Even devices that don't have an official sign message feature, Bitcoin Core could just have it sign a fake transaction.
691 2019-01-24T20:48:17  <gmaxwell> Indeed.
692 2019-01-24T20:48:27  <provoostenator> (provably fake ideally)
693 2019-01-24T20:48:53  <gmaxwell> 0 value, locktimed almost-forever far in the future would be nice.
694 2019-01-24T20:49:03  <provoostenator> Or with a relative lock time after the heath death of the universe.
695 2019-01-24T20:49:21  <gmaxwell> I think it would be nice to even do more than what Bitcoin Core currently does.. but priorities,  the sign/verify after generate is a pretty general protection at least.
696 2019-01-24T20:49:28  <achow101> provoostenator: that's actually largely not possible for most devices since they verify inputs
697 2019-01-24T20:49:48  <achow101> oh, actually if you claim it's segwit that's fine
698 2019-01-24T20:49:51  <provoostenator> Ah that pesky Segwit thing, but they still sign legacy transactions...
699 2019-01-24T20:50:06  <provoostenator> Or you mean the other way around?
700 2019-01-24T20:50:25  <achow101> sign a segwit input. they don't verify those inputs
701 2019-01-24T20:51:06  <provoostenator> Ah ok, so for legacy they insist on seeing an entire transaction with inputs? That does get tedious.
702 2019-01-24T20:51:23  <achow101> yeah
703 2019-01-24T20:51:24  <provoostenator> But that could also be fake right?
704 2019-01-24T20:51:33  <provoostenator> Spending non-existing coins.
705 2019-01-24T20:51:42  <achow101> sure, but that's more work
706 2019-01-24T20:51:58  <provoostenator> Indeed
707 2019-01-24T20:56:41  <provoostenator> So I'll probably add something to my PR in the signerfetchkeys  RPC method, which imports the keys, to call sign message on the device with one of the keys, and then check the result.
708 2019-01-24T20:57:17  <provoostenator> Although there's no way to undo an import, at the RPC method would fail with a giant error telling the user to delete their new wallet and retry the import.
709 2019-01-24T20:57:31  <provoostenator> *, at least the RPC...
710 2019-01-24T20:59:22  *** Guest55956 has quit IRC
711 2019-01-24T21:07:19  *** spaced0ut has quit IRC
712 2019-01-24T21:12:41  *** promag has joined #bitcoin-core-dev
713 2019-01-24T21:13:45  *** Guyver2 has quit IRC
714 2019-01-24T21:29:30  *** molz has quit IRC
715 2019-01-24T21:29:34  *** bitcoin-git has joined #bitcoin-core-dev
716 2019-01-24T21:29:34  <bitcoin-git> [bitcoin] instagibbs opened pull request #15245: remove deprecated mentions of signrawtransaction from fundraw help (master...fundraw_signraw) https://github.com/bitcoin/bitcoin/pull/15245
717 2019-01-24T21:29:34  *** bitcoin-git has left #bitcoin-core-dev
718 2019-01-24T21:32:47  *** mistergo1d has joined #bitcoin-core-dev
719 2019-01-24T21:36:04  *** mistergold has quit IRC
720 2019-01-24T21:38:45  *** Krellan has joined #bitcoin-core-dev
721 2019-01-24T21:41:16  *** IZooo has quit IRC
722 2019-01-24T21:41:20  *** IzoooO has joined #bitcoin-core-dev
723 2019-01-24T21:42:58  *** Krellan has quit IRC
724 2019-01-24T21:45:44  *** mistergold has joined #bitcoin-core-dev
725 2019-01-24T21:49:30  *** mistergo1d has quit IRC
726 2019-01-24T21:57:47  *** elichai2 has quit IRC
727 2019-01-24T22:07:43  *** zivl has joined #bitcoin-core-dev
728 2019-01-24T22:09:26  *** bitcoin-git has joined #bitcoin-core-dev
729 2019-01-24T22:09:26  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #15246: qa: Add tests for invalid message headers (master...Mf1901-qaMsgHeader) https://github.com/bitcoin/bitcoin/pull/15246
730 2019-01-24T22:09:26  *** bitcoin-git has left #bitcoin-core-dev
731 2019-01-24T22:09:58  *** ddustin has quit IRC
732 2019-01-24T22:10:27  *** ddustin has joined #bitcoin-core-dev
733 2019-01-24T22:14:56  *** ddustin has quit IRC
734 2019-01-24T22:29:42  *** spinza has quit IRC
735 2019-01-24T22:39:57  *** spinza has joined #bitcoin-core-dev
736 2019-01-24T22:46:50  *** molz has joined #bitcoin-core-dev
737 2019-01-24T22:54:48  *** harrigan has quit IRC
738 2019-01-24T22:54:57  *** harrigan has joined #bitcoin-core-dev
739 2019-01-24T23:00:23  *** mistergo1d has joined #bitcoin-core-dev
740 2019-01-24T23:03:31  *** mistergold has quit IRC
741 2019-01-24T23:25:28  *** pinheadmz has quit IRC
742 2019-01-24T23:26:14  <meshcollider> sipa: I've been thinking about your comment here: https://github.com/bitcoin/bitcoin/pull/14491#discussion_r247192015
743 2019-01-24T23:26:54  <meshcollider> current behaviour is that all pubkeys are added as watchonly if theyre provided in the pubkeys field of importmulti, even if they appear only in subscripts
744 2019-01-24T23:27:17  <meshcollider> do we want to keep that behaviuor?
745 2019-01-24T23:29:07  <sipa> meshcollider: you can only specify pubkeys for importmulti when they're actually used as pubkey hashes
746 2019-01-24T23:29:12  <sipa> right?
747 2019-01-24T23:29:21  <sipa> and not for example a pubkey in a multisig
748 2019-01-24T23:29:41  <meshcollider> yeah but if you use pubkey hashes in a P2SH script is it intentionally that the pubkey itself becomes watched
749 2019-01-24T23:29:51  <sipa> sure
750 2019-01-24T23:29:54  <sipa> that's ok
751 2019-01-24T23:29:54  <meshcollider> ok
752 2019-01-24T23:30:00  <sipa> (and inevitable for now)
753 2019-01-24T23:30:11  <sipa> well, it's not ok - but it isn't changing policy
754 2019-01-24T23:30:41  <sipa> if you want to watch a P2WPKH you shouldn't need to also watch the corresponding P2PK and P2PKH, but for now that's inevitable
755 2019-01-24T23:30:42  <meshcollider> right
756 2019-01-24T23:30:54  <sipa> however, if you're able to spend the P2WPKH, you're also able to spend the P2PK/P2PKH
757 2019-01-24T23:31:17  <sipa> this is not the case for multisig; if you want to watch the multisig, you shouldn't also watch P2PKH for the keys in it
758 2019-01-24T23:34:00  <sipa> does that make sense?
759 2019-01-24T23:34:00  *** jb55 has quit IRC
760 2019-01-24T23:36:21  <meshcollider> yes
761 2019-01-24T23:36:39  <meshcollider> I just wanted to check the current behaviour was correct
762 2019-01-24T23:37:26  *** Zenton has quit IRC
763 2019-01-24T23:44:29  *** miknotauro has joined #bitcoin-core-dev
764 2019-01-24T23:45:06  *** mn9495 has joined #bitcoin-core-dev
765 2019-01-24T23:45:46  *** bitcoin-git has joined #bitcoin-core-dev
766 2019-01-24T23:45:46  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #15247: qa: Use wallet to retrieve raw transactions (master...Mf1901-qaWalletRaw) https://github.com/bitcoin/bitcoin/pull/15247
767 2019-01-24T23:45:46  *** bitcoin-git has left #bitcoin-core-dev
768 2019-01-24T23:46:15  *** mn9495 has quit IRC
769 2019-01-24T23:47:55  *** mn949588 has joined #bitcoin-core-dev
770 2019-01-24T23:56:14  *** mn949588 has quit IRC
771 2019-01-24T23:56:31  *** mn949588 has joined #bitcoin-core-dev
772 2019-01-24T23:57:15  *** mistergold has joined #bitcoin-core-dev