1 2017-08-31T00:01:59  *** RoyceX has quit IRC
  2 2017-08-31T00:03:21  *** Evel-Knievel has quit IRC
  3 2017-08-31T00:12:02  *** jtimon has quit IRC
  4 2017-08-31T00:12:34  *** jtimon has joined #bitcoin-core-dev
  5 2017-08-31T00:24:09  *** randy-waterhouse has joined #bitcoin-core-dev
  6 2017-08-31T00:24:26  *** randy-waterhouse has joined #bitcoin-core-dev
  7 2017-08-31T00:39:25  *** CubicEar_ has joined #bitcoin-core-dev
  8 2017-08-31T00:41:13  <bitcoin-git> [bitcoin] achow101 opened pull request #11200: Allow for aborting rescans and canceling showProgress dialogs (master...gui-recan-abort) https://github.com/bitcoin/bitcoin/pull/11200
  9 2017-08-31T00:42:12  *** CubicEarth has quit IRC
 10 2017-08-31T00:55:43  *** meshcollider has quit IRC
 11 2017-08-31T00:57:43  *** JackH has quit IRC
 12 2017-08-31T00:58:16  *** dabura667 has joined #bitcoin-core-dev
 13 2017-08-31T01:26:56  *** CubicEar_ has quit IRC
 14 2017-08-31T01:27:32  *** CubicEarth has joined #bitcoin-core-dev
 15 2017-08-31T01:37:15  *** Aaronvan_ has quit IRC
 16 2017-08-31T01:41:24  *** randy-waterhouse has quit IRC
 17 2017-08-31T01:42:09  *** randy-waterhouse has joined #bitcoin-core-dev
 18 2017-08-31T01:44:30  *** randy-waterhouse has quit IRC
 19 2017-08-31T01:48:53  *** Terrance has joined #bitcoin-core-dev
 20 2017-08-31T01:49:04  *** Terrance has quit IRC
 21 2017-08-31T01:59:33  *** CubicEarth has quit IRC
 22 2017-08-31T02:06:57  *** sam_c has quit IRC
 23 2017-08-31T02:08:01  *** Giszmo has quit IRC
 24 2017-08-31T02:08:12  *** sam_c has joined #bitcoin-core-dev
 25 2017-08-31T02:24:29  *** btcdrak has joined #bitcoin-core-dev
 26 2017-08-31T02:24:39  *** RubenSomsen has joined #bitcoin-core-dev
 27 2017-08-31T02:30:53  <achow101> I don't suppose it is possible to lock the comments on the first commit?
 28 2017-08-31T02:39:05  *** Giszmo has joined #bitcoin-core-dev
 29 2017-08-31T02:44:43  *** chjj has quit IRC
 30 2017-08-31T02:45:17  <sipa> achow101: i don't see an option to do that
 31 2017-08-31T02:45:29  <achow101> darn
 32 2017-08-31T02:55:02  <jl2012> i have a question about this line: https://github.com/bitcoin/bitcoin/blob/master/src/validation.h#L376 . Is is same as std::swap(scriptPubKey, check.scriptPubKey); ?
 33 2017-08-31T03:01:05  *** goatpig has joined #bitcoin-core-dev
 34 2017-08-31T03:02:06  <sipa> jl2012: yes
 35 2017-08-31T03:02:25  <sipa> std::swap also works for primitive types
 36 2017-08-31T03:04:08  <jl2012> thanks sipa. I have another question about my patch here: https://github.com/bitcoin/bitcoin/pull/10953/files#diff-349fbb003d5ae550a2e8fa658e475880L368 .
 37 2017-08-31T03:04:08  <jl2012> As I replace amount+scriptPubKey with CTxOut, the default value of amount becomes -1. It should be ok?
 38 2017-08-31T03:05:19  <sipa> sounds fine
 39 2017-08-31T03:05:50  <sipa> perhaps add an assert to check that it's not -1 for any actual validation
 40 2017-08-31T03:05:51  <sipa> or at least not for a witness validation
 41 2017-08-31T03:10:22  <jl2012> sipa: it sounds already like a serious bug if the validation would use the default value, 0 or -1. Maybe -1 is actually better because it must be invalid
 42 2017-08-31T03:19:26  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 43 2017-08-31T03:22:10  *** meshcollider has joined #bitcoin-core-dev
 44 2017-08-31T03:27:02  *** d9b4bef9 has quit IRC
 45 2017-08-31T03:28:08  *** d9b4bef9 has joined #bitcoin-core-dev
 46 2017-08-31T03:35:41  *** Giszmo has quit IRC
 47 2017-08-31T03:38:13  *** justanotheruser has quit IRC
 48 2017-08-31T03:47:55  *** chjj has joined #bitcoin-core-dev
 49 2017-08-31T03:48:35  *** Giszmo has joined #bitcoin-core-dev
 50 2017-08-31T03:49:00  *** Chris_Stewart_5 has quit IRC
 51 2017-08-31T03:54:41  *** Giszmo has quit IRC
 52 2017-08-31T03:56:08  *** justanotheruser has joined #bitcoin-core-dev
 53 2017-08-31T04:07:44  *** arubi has joined #bitcoin-core-dev
 54 2017-08-31T04:16:29  *** Giszmo has joined #bitcoin-core-dev
 55 2017-08-31T04:19:13  <bitcoin-git> [bitcoin] justicz opened pull request #11201: [RPC] Add verifyrawtransaction RPC (master...maxj_add_verify_tx_rpc) https://github.com/bitcoin/bitcoin/pull/11201
 56 2017-08-31T04:50:41  *** justanotheruser has quit IRC
 57 2017-08-31T05:02:21  *** chjj has quit IRC
 58 2017-08-31T05:06:56  *** justanotheruser has joined #bitcoin-core-dev
 59 2017-08-31T05:44:19  *** Victor_sueca is now known as Victorsueca
 60 2017-08-31T05:46:50  *** Gunnie has joined #bitcoin-core-dev
 61 2017-08-31T06:06:22  *** ula has joined #bitcoin-core-dev
 62 2017-08-31T06:19:35  *** clarkmoody has quit IRC
 63 2017-08-31T06:49:13  *** BashCo has quit IRC
 64 2017-08-31T06:55:43  *** meshcollider has quit IRC
 65 2017-08-31T07:01:28  *** Evel-Knievel has joined #bitcoin-core-dev
 66 2017-08-31T07:01:57  *** RubenSomsen has quit IRC
 67 2017-08-31T07:06:08  *** Gunnie has quit IRC
 68 2017-08-31T07:06:58  *** SopaXorzTaker has joined #bitcoin-core-dev
 69 2017-08-31T07:14:17  *** BashCo has joined #bitcoin-core-dev
 70 2017-08-31T07:17:35  *** jtimon has quit IRC
 71 2017-08-31T07:18:16  *** RubenSomsen has joined #bitcoin-core-dev
 72 2017-08-31T07:25:46  *** sltrain_ has joined #bitcoin-core-dev
 73 2017-08-31T07:32:15  *** sltrain_ has quit IRC
 74 2017-08-31T07:32:21  *** dermoth has joined #bitcoin-core-dev
 75 2017-08-31T07:42:45  <jl2012> is there any easy way to list all segwit txs in the mempool?
 76 2017-08-31T07:44:32  *** praxeology has joined #bitcoin-core-dev
 77 2017-08-31T07:46:39  *** clarkmoody has joined #bitcoin-core-dev
 78 2017-08-31T07:46:40  *** praxeology1 has quit IRC
 79 2017-08-31T08:07:23  *** timothy has joined #bitcoin-core-dev
 80 2017-08-31T08:18:14  *** [b__b] has quit IRC
 81 2017-08-31T08:20:11  *** [b__b] has joined #bitcoin-core-dev
 82 2017-08-31T08:22:13  *** praxeology has quit IRC
 83 2017-08-31T08:22:13  *** praxeology has joined #bitcoin-core-dev
 84 2017-08-31T08:22:18  *** JackH has joined #bitcoin-core-dev
 85 2017-08-31T08:28:18  *** laurentmt has joined #bitcoin-core-dev
 86 2017-08-31T08:31:21  *** Guyver2 has joined #bitcoin-core-dev
 87 2017-08-31T08:41:17  *** Giszmo has quit IRC
 88 2017-08-31T08:54:17  *** AaronvanW has joined #bitcoin-core-dev
 89 2017-08-31T08:55:50  *** Giszmo has joined #bitcoin-core-dev
 90 2017-08-31T08:56:05  *** JackH has quit IRC
 91 2017-08-31T09:13:47  *** justanotheruser has quit IRC
 92 2017-08-31T09:15:30  *** justanotheruser has joined #bitcoin-core-dev
 93 2017-08-31T09:47:05  *** shesek has quit IRC
 94 2017-08-31T09:49:35  *** shesek has joined #bitcoin-core-dev
 95 2017-08-31T09:50:11  *** wvr has joined #bitcoin-core-dev
 96 2017-08-31T10:07:23  *** JackH has joined #bitcoin-core-dev
 97 2017-08-31T10:16:40  *** dabura667 has quit IRC
 98 2017-08-31T10:24:49  *** RubenSomsen has quit IRC
 99 2017-08-31T10:34:32  *** laurentmt has quit IRC
100 2017-08-31T10:35:35  *** shesek has quit IRC
101 2017-08-31T10:45:41  *** RubenSomsen has joined #bitcoin-core-dev
102 2017-08-31T10:52:23  *** str4d has joined #bitcoin-core-dev
103 2017-08-31T10:56:33  *** Aaronvan_ has joined #bitcoin-core-dev
104 2017-08-31T10:57:37  *** AaronvanW has quit IRC
105 2017-08-31T11:08:35  *** Gunnie has joined #bitcoin-core-dev
106 2017-08-31T11:16:21  *** meshcollider_ has joined #bitcoin-core-dev
107 2017-08-31T11:18:10  *** SopaXorzTaker has quit IRC
108 2017-08-31T11:18:22  *** str4d has quit IRC
109 2017-08-31T11:18:53  *** SopaXorzTaker has joined #bitcoin-core-dev
110 2017-08-31T11:19:45  *** Aaronvan_ is now known as AaronvanW
111 2017-08-31T11:26:05  *** justan0theruser has joined #bitcoin-core-dev
112 2017-08-31T11:28:00  *** justanotheruser has quit IRC
113 2017-08-31T11:39:41  *** justan0theruser has quit IRC
114 2017-08-31T11:40:08  *** justanotheruser has joined #bitcoin-core-dev
115 2017-08-31T11:43:12  *** Giszmo has quit IRC
116 2017-08-31T11:44:46  *** ChesterVal has joined #bitcoin-core-dev
117 2017-08-31T11:57:08  *** laurentmt has joined #bitcoin-core-dev
118 2017-08-31T12:00:42  *** AaronvanW has quit IRC
119 2017-08-31T12:00:50  *** laurentmt has quit IRC
120 2017-08-31T12:00:54  *** Giszmo has joined #bitcoin-core-dev
121 2017-08-31T12:01:47  *** AaronvanW has joined #bitcoin-core-dev
122 2017-08-31T12:32:55  *** Chris_Stewart_5 has joined #bitcoin-core-dev
123 2017-08-31T12:43:41  *** To7 has joined #bitcoin-core-dev
124 2017-08-31T13:01:30  <wumpus> I won't be at the dev meeting today - just getting settled in here at SF and have a few days holiday
125 2017-08-31T13:02:02  *** bitsegwit has quit IRC
126 2017-08-31T13:07:28  <instagibbs> Synced rc3 in 5 hours on my laptop with default dbcache, very tame IO use. Very nice work!
127 2017-08-31T13:10:02  *** Dyaheon has quit IRC
128 2017-08-31T13:11:26  *** Dyaheon has joined #bitcoin-core-dev
129 2017-08-31T13:12:32  *** shesek has joined #bitcoin-core-dev
130 2017-08-31T13:33:39  *** Chris_Stewart_5 has quit IRC
131 2017-08-31T13:35:05  *** Chris_Stewart_5 has joined #bitcoin-core-dev
132 2017-08-31T13:36:05  *** shesek has quit IRC
133 2017-08-31T13:43:37  <bitcoin-git> [bitcoin] sdaftuar opened pull request #11203: RPC: add wtxid to mempool entry output (master...2017-08-add-wtxid-to-mempool-entry) https://github.com/bitcoin/bitcoin/pull/11203
134 2017-08-31T13:44:49  <sdaftuar> jl2012: i don't see an easy way to list all segwit tx's in the mempool currently, but i just opened #11203 which would make it pretty straightforward (just compare txid to wtxid)
135 2017-08-31T13:54:32  *** meshcollider_ has quit IRC
136 2017-08-31T14:15:08  *** sstone has joined #bitcoin-core-dev
137 2017-08-31T14:18:01  *** Chris_Stewart_5 has quit IRC
138 2017-08-31T14:27:52  *** riemann has joined #bitcoin-core-dev
139 2017-08-31T14:29:33  *** Chris_Stewart_5 has joined #bitcoin-core-dev
140 2017-08-31T14:39:52  *** esotericnonsense has quit IRC
141 2017-08-31T14:40:01  *** sturles has quit IRC
142 2017-08-31T14:40:01  *** Chris_Stewart_5 has quit IRC
143 2017-08-31T14:40:30  *** esotericnonsense has joined #bitcoin-core-dev
144 2017-08-31T14:47:35  *** adiabat has quit IRC
145 2017-08-31T14:53:40  *** Chris_Stewart_5 has joined #bitcoin-core-dev
146 2017-08-31T14:58:24  *** adiabat has joined #bitcoin-core-dev
147 2017-08-31T14:59:44  *** riemann has quit IRC
148 2017-08-31T15:03:31  *** sturles has joined #bitcoin-core-dev
149 2017-08-31T15:07:43  <gmaxwell> sdaftuar: this should work: ./bitcoin-cli getblocktemplate | jq '.transactions | .[] | select(.hash != .txid) | .txid'
150 2017-08-31T15:07:57  <gmaxwell> but that only does it with the blocktemplate.
151 2017-08-31T15:09:58  <sdaftuar> gmaxwell: yeah so that only gets segwit tx's in the top of the mempool, rather than the whole mempool
152 2017-08-31T15:10:10  <sdaftuar> btw you just improved my life substantially by teaching me about jq
153 2017-08-31T15:12:11  <sstone> hi, I have a question about SPV nodes: does bitcoin core include tx witness data in filtered blocks sent to SPV client ?
154 2017-08-31T15:13:19  <sdaftuar> sstone: not currently, though there's an open PR on that topic.  see #10350
155 2017-08-31T15:13:31  <bitcoin-git> [bitcoin] santyraghavan opened pull request #11204: Merge pull request #1 from bitcoin/master (master...master) https://github.com/bitcoin/bitcoin/pull/11204
156 2017-08-31T15:16:30  <sstone> sdaftuar: thanks !
157 2017-08-31T15:19:48  *** shesek has joined #bitcoin-core-dev
158 2017-08-31T15:22:28  <gmaxwell> sstone: if you have a usecase for that I'd like to learn more. I understand codeshark's and I assume we'll do it for his but his is kind of weird and obscure.
159 2017-08-31T15:26:20  *** Gunnie has quit IRC
160 2017-08-31T15:26:35  *** shesek has quit IRC
161 2017-08-31T15:27:27  <sstone> our use case is light-weight (mobile for example) LN compatible wallets. There are cases when you will want to monitor the blockchain and extract preimages from witness data
162 2017-08-31T15:28:56  *** Chris_Stewart_5 has quit IRC
163 2017-08-31T15:39:13  *** Giszmo has quit IRC
164 2017-08-31T15:41:39  *** Chris_Stewart_5 has joined #bitcoin-core-dev
165 2017-08-31T15:51:38  *** Giszmo has joined #bitcoin-core-dev
166 2017-08-31T15:54:45  *** BashCo has quit IRC
167 2017-08-31T15:55:23  *** BashCo has joined #bitcoin-core-dev
168 2017-08-31T15:55:58  *** praxeology has quit IRC
169 2017-08-31T15:59:32  *** BashCo has quit IRC
170 2017-08-31T16:07:35  *** RubenSomsen has quit IRC
171 2017-08-31T16:08:43  *** Yogaqueef has quit IRC
172 2017-08-31T16:10:04  *** chjj has joined #bitcoin-core-dev
173 2017-08-31T16:14:48  *** BashCo has joined #bitcoin-core-dev
174 2017-08-31T16:24:01  *** laurentmt has joined #bitcoin-core-dev
175 2017-08-31T16:25:09  *** sstone has quit IRC
176 2017-08-31T16:34:04  *** blznblzn2 has joined #bitcoin-core-dev
177 2017-08-31T16:46:26  <bitcoin-git> [bitcoin] jnewbery closed pull request #10591: [tests] make pruning.py faster (master...fastprune) https://github.com/bitcoin/bitcoin/pull/10591
178 2017-08-31T16:53:43  *** RubenSomsen has joined #bitcoin-core-dev
179 2017-08-31T16:56:09  *** SopaXorzTaker has quit IRC
180 2017-08-31T17:01:50  *** Chris_Stewart_5 has quit IRC
181 2017-08-31T17:02:45  *** abpa has joined #bitcoin-core-dev
182 2017-08-31T17:13:41  *** timothy has quit IRC
183 2017-08-31T17:14:04  *** illpadrino has joined #bitcoin-core-dev
184 2017-08-31T17:14:19  <illpadrino> hello all
185 2017-08-31T17:14:52  <illpadrino> Does anyone have experience with Bitcoin ATM? I am thinking to put one in Paraguay
186 2017-08-31T17:16:17  *** Chris_Stewart_5 has joined #bitcoin-core-dev
187 2017-08-31T17:23:04  <Lauda> Wrong chat, go to #bitcoin.
188 2017-08-31T17:23:27  *** klkk has joined #bitcoin-core-dev
189 2017-08-31T17:28:48  <warren> https://github.com/bitcoincore/  is this associated with anyone here?
190 2017-08-31T17:29:22  <gmaxwell> warren: IIRC it's controlled by a github employee and they refused to give it up.
191 2017-08-31T17:32:44  * sturles thinks you should rename Bitcoin Core back to Bitcoin.
192 2017-08-31T17:36:18  * esotericnonsense agrees
193 2017-08-31T17:41:35  *** Chris_Stewart_5 has quit IRC
194 2017-08-31T17:44:28  *** Guyver2 has quit IRC
195 2017-08-31T17:44:31  *** Murch has joined #bitcoin-core-dev
196 2017-08-31T17:45:31  *** shesek has joined #bitcoin-core-dev
197 2017-08-31T17:47:35  *** JackH has quit IRC
198 2017-08-31T17:55:33  * luke-jr disagrees.
199 2017-08-31T17:56:25  <luke-jr> it was annoying to have to constantly explain to people that Core is not Bitcoin
200 2017-08-31T17:58:33  *** karelb has quit IRC
201 2017-08-31T17:59:59  *** Chris_Stewart_5 has joined #bitcoin-core-dev
202 2017-08-31T18:00:00  *** rjak2 has joined #bitcoin-core-dev
203 2017-08-31T18:00:00  *** rjak has quit IRC
204 2017-08-31T18:00:05  <warren> Could rename it to Badger? (only half joking)
205 2017-08-31T18:00:15  *** rjak2 is now known as rjak
206 2017-08-31T18:00:21  *** JackH has joined #bitcoin-core-dev
207 2017-08-31T18:00:36  <warren> jonasschnelli: https://github.com/bitcoin/bitcoin/pull/9483  will you be able to rebase this soon?
208 2017-08-31T18:02:14  <instagibbs> luke-jr, NotBitcoin
209 2017-08-31T18:02:20  <instagibbs> agreed with luke-jr
210 2017-08-31T18:19:11  *** Giszmo has quit IRC
211 2017-08-31T18:20:06  *** praxeology has joined #bitcoin-core-dev
212 2017-08-31T18:20:29  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #11204: Merge pull request #1 from bitcoin/master (master...master) https://github.com/bitcoin/bitcoin/pull/11204
213 2017-08-31T18:25:34  <bitcoin-git> [bitcoin] danra opened pull request #11205: Make fixed CAmounts and related sanity function constexpr (master...refactor/constexpr-amount) https://github.com/bitcoin/bitcoin/pull/11205
214 2017-08-31T18:29:46  *** jtimon has joined #bitcoin-core-dev
215 2017-08-31T18:31:19  *** asimplecoder has joined #bitcoin-core-dev
216 2017-08-31T18:31:24  <asimplecoder> hey
217 2017-08-31T18:31:30  <asimplecoder> anyone online?
218 2017-08-31T18:34:07  *** Chris_Stewart_5 has quit IRC
219 2017-08-31T18:34:45  *** Giszmo has joined #bitcoin-core-dev
220 2017-08-31T18:35:51  <sipa> no
221 2017-08-31T18:37:56  <bitcoin-git> [bitcoin] polyetilen opened pull request #11206: Update optionsdialog.ui (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11206
222 2017-08-31T18:40:18  *** Veseli_Zagorec has joined #bitcoin-core-dev
223 2017-08-31T18:47:12  *** belcher has quit IRC
224 2017-08-31T18:54:25  *** Aaronvan_ has joined #bitcoin-core-dev
225 2017-08-31T18:56:30  *** AaronvanW has quit IRC
226 2017-08-31T18:57:18  *** luke-jr has quit IRC
227 2017-08-31T18:58:10  *** meshcollider_ has joined #bitcoin-core-dev
228 2017-08-31T18:58:45  *** meshcollider_ is now known as meshcollider
229 2017-08-31T19:00:52  *** luke-jr has joined #bitcoin-core-dev
230 2017-08-31T19:01:45  <achow101> Meeting?
231 2017-08-31T19:02:11  <sdaftuar> here
232 2017-08-31T19:02:15  <jnewbery> hello
233 2017-08-31T19:02:22  <meshcollider> hi
234 2017-08-31T19:02:35  <sipa> hi
235 2017-08-31T19:02:53  <cfields> hi
236 2017-08-31T19:04:09  <sdaftuar> wumpus said above that he'd be skipping today
237 2017-08-31T19:04:45  <achow101> Oh
238 2017-08-31T19:05:09  <cfields> well we can still discuss :)
239 2017-08-31T19:05:10  <luke-jr> hi
240 2017-08-31T19:05:14  <cfields> gmaxwell: have your mass ping handy?
241 2017-08-31T19:05:34  <achow101> Whatever shall we do without our fearless leader? :P
242 2017-08-31T19:05:49  <luke-jr> someone should do the startmeeting command
243 2017-08-31T19:05:53  <luke-jr> (and chair)
244 2017-08-31T19:05:54  <sipa> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
245 2017-08-31T19:05:58  <sipa> #startmeeting
246 2017-08-31T19:05:58  <lightningbot> Meeting started Thu Aug 31 19:05:58 2017 UTC.  The chair is sipa. Information about MeetBot at http://wiki.debian.org/MeetBot.
247 2017-08-31T19:05:58  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
248 2017-08-31T19:06:13  <sipa> I'm not sure whether gmaxwell is available right now
249 2017-08-31T19:06:26  <sipa> topics?
250 2017-08-31T19:06:39  <meshcollider> it still lists wumpus as present lol
251 2017-08-31T19:07:12  <achow101> Anything with 0.15.0?
252 2017-08-31T19:07:16  <luke-jr> meshcollider: it's not a list of present people, just a mention to wake them up
253 2017-08-31T19:07:18  <gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101
254 2017-08-31T19:07:23  <gmaxwell> I'm not really here.
255 2017-08-31T19:07:27  <kanzure> hi.
256 2017-08-31T19:07:44  <luke-jr> achow101: there's a string issue, but not sure it matters much
257 2017-08-31T19:07:49  <luke-jr> the debug log tooltip IIRC
258 2017-08-31T19:07:56  <cfields> any observed 0.15 bugs?
259 2017-08-31T19:07:57  <sipa> what is up with #11198?
260 2017-08-31T19:08:08  <kanzure> next meeting unlikely to be on irc
261 2017-08-31T19:08:23  <achow101> (I'm not really here, hard to irc on a bike)
262 2017-08-31T19:09:01  <gmaxwell> cfields: there was someone complaining rc3 is crashing on windows
263 2017-08-31T19:09:09  <luke-jr> what is #11198? (I'm stuck at CLI)
264 2017-08-31T19:09:13  <morcos> heh, i am here, for a change
265 2017-08-31T19:09:14  *** Roger2x has joined #bitcoin-core-dev
266 2017-08-31T19:09:17  <sipa> #topic 0.15.0
267 2017-08-31T19:09:18  <cfields> sipa: heh, that hardly seems like something worth waiting for
268 2017-08-31T19:09:22  <gmaxwell> achow101 was going to try reproducing.
269 2017-08-31T19:09:25  <sipa> luke-jr: Fix display of package name on 'open config file' tooltip
270 2017-08-31T19:09:32  <cfields> gmaxwell: hmm, link? or discussion?
271 2017-08-31T19:09:47  <achow101> The rc3 problem was fixed with iirc
272 2017-08-31T19:09:57  *** laurentmt has quit IRC
273 2017-08-31T19:09:58  <achow101> (the windows crash thing)
274 2017-08-31T19:10:03  <instagibbs> present
275 2017-08-31T19:10:11  <gmaxwell> cfields: https://bitcointalk.org/index.php?topic=2132893.0
276 2017-08-31T19:10:19  <instagibbs> gmaxwell, running fine here on windows fwiw
277 2017-08-31T19:10:21  <gmaxwell> ohcrap this again:
278 2017-08-31T19:10:22  <luke-jr> IMO a tooltip doesn't need to block final, but since we're waiting a week anyway, might as well do a RC with it? (maybe merge in the -acceptnonstdtxn fix too)
279 2017-08-31T19:10:23  <gmaxwell> Problem solved!  Running bitcoin-qt with the '-resetguisettings' switch fixed it.  Thanks to MeshCollider on github for the fix! Smiley
280 2017-08-31T19:10:36  <gmaxwell> ^ that is now the third person I've seen screwed by this.
281 2017-08-31T19:10:44  <gmaxwell> did we change something that created this problem
282 2017-08-31T19:10:47  <luke-jr> gmaxwell: that's the crash?
283 2017-08-31T19:10:48  *** Chris_Stewart_5 has joined #bitcoin-core-dev
284 2017-08-31T19:10:54  <gmaxwell> luke-jr: apparently it wasn't actually a crash
285 2017-08-31T19:11:07  <gmaxwell> the symptom is you start bitcoin and it vanishes after the splash
286 2017-08-31T19:11:11  <sipa> just the window appearing in an offscreen location?
287 2017-08-31T19:11:17  <luke-jr> ah
288 2017-08-31T19:11:20  <sipa> can we add a test for that?
289 2017-08-31T19:11:32  <luke-jr> sipa: we do already IIRC
290 2017-08-31T19:11:35  <sipa> (if window is beyond screen coordinates, reset gui settings automatically)
291 2017-08-31T19:11:38  <sipa> jonasschnelli: ^
292 2017-08-31T19:11:58  <gmaxwell> 16:19 < gmaxwell> jonasschnelli: I just had someone on IRC that had their GUI not displaying after upgrading to 0.14.2 ... this fixed it https://github.com/bitcoin/bitcoin/issues/7869#issuecomment-209265754  is there some underlying bug we need to fix?
293 2017-08-31T19:12:02  <gmaxwell> 11:19 < jonasschnelli> gmaxwell: most possible problem of a not-appearing GUI is probably persisted windows coordinates outside of the screen boundaries.
294 2017-08-31T19:12:05  <gmaxwell> 11:20 < jonasschnelli> could be fixed by checking the screen bounds against the QSettings coords
295 2017-08-31T19:12:08  <gmaxwell> 11:21 < jonasschnelli> -resetguisettings will just evict all user based Qt overrides (and things like window coordinates)
296 2017-08-31T19:12:12  <meshcollider> #11171 for reference
297 2017-08-31T19:12:16  <sipa> thnaks
298 2017-08-31T19:12:36  *** Veseli_Zagorec has quit IRC
299 2017-08-31T19:12:54  <gmaxwell> it worries me that I've never seen this complain before and now three in a few weeks, all with people testing 0.15rc
300 2017-08-31T19:13:04  <gmaxwell> complaint*
301 2017-08-31T19:13:10  <luke-jr> gmaxwell: could it be the Qt version bump?
302 2017-08-31T19:13:22  <gmaxwell> thats beyond my pay grade to speculate.
303 2017-08-31T19:14:06  <cfields> gmaxwell: all windows complaints?
304 2017-08-31T19:14:11  <gmaxwell> yes
305 2017-08-31T19:14:12  <luke-jr> a shame the users have done the workaround..
306 2017-08-31T19:14:28  <gmaxwell> it's a pretty bad failure mode, silently gone...
307 2017-08-31T19:14:32  <luke-jr> if we can get it reproduced again, it'd be nice to get the registry entries involved
308 2017-08-31T19:14:36  <cfields> i wonder if they're all multi-monitor
309 2017-08-31T19:14:49  <gmaxwell> luke-jr: well I told one to do it because it was a hail mary... I had no idea it would actually fix it.
310 2017-08-31T19:14:53  <luke-jr> cfields: hmm, monitors of different sizes maybe?
311 2017-08-31T19:15:15  <gmaxwell> we can ask.
312 2017-08-31T19:15:22  <cfields> luke-jr: i was thinking: bitcoin-qt on monitor 2, shutdown, restart with only monitor 1
313 2017-08-31T19:15:30  <luke-jr> I could totally see different-sized monitors confusing this
314 2017-08-31T19:15:46  <luke-jr> cfields: am I wrong that we don't check for visible coordinates?
315 2017-08-31T19:15:51  <luke-jr> err, that we do*
316 2017-08-31T19:16:16  <luke-jr> (which would probably fail if the monitors are different sizes, due to blocked-off regions within the total dimensions)
317 2017-08-31T19:16:21  <cfields> luke-jr: no clue
318 2017-08-31T19:16:38  *** belcher has joined #bitcoin-core-dev
319 2017-08-31T19:17:20  <achow101> Gmaxwell: I believe it's a registry problem
320 2017-08-31T19:17:40  <achow101> Since qsettings stores things in registry
321 2017-08-31T19:18:04  <sipa> achow101: i think the registry is just a storage medium
322 2017-08-31T19:18:27  <gmaxwell> did we just start doing this... or
323 2017-08-31T19:18:51  <sipa> i think bitcoin-qt has done that since forver, and nothing changed wrt to that now
324 2017-08-31T19:18:55  <achow101> Gmaxwell: I don't think so. It's been reported a few times before with older versions
325 2017-08-31T19:19:12  <meshcollider> relevant code? https://github.com/bitcoin/bitcoin/blob/master/src/qt/guiutil.cpp#L852
326 2017-08-31T19:20:15  <BlueMatt> we always see a flood of reports of old issues upon new rc's
327 2017-08-31T19:20:36  <gmaxwell> yea, okay!
328 2017-08-31T19:21:27  <MarcoFalke> The "Fix for issues with startup and multiple monitors on windows." is already included https://github.com/bitcoin/bitcoin/commit/e9ff818b69c2f8ce4a151d1a81a3e22a4319c93d
329 2017-08-31T19:22:24  <ryanofsky> that doesn't seem like a sufficient fix if x and y are just outside screen geometry
330 2017-08-31T19:22:33  <jtimon> anything else regarding 0.15 ?
331 2017-08-31T19:22:41  <luke-jr> MarcoFalke: new in 0.15?
332 2017-08-31T19:22:46  <MarcoFalke> jup
333 2017-08-31T19:22:47  <luke-jr> maybe it's the problem..?
334 2017-08-31T19:23:04  <MarcoFalke> Yes, I think the fix is not sufficient
335 2017-08-31T19:24:01  <ryanofsky> would need to add || pos.x() > screen.width() || pos.y() > screen.height()
336 2017-08-31T19:24:16  <gmaxwell> from that code it looks obvious how to fix this.
337 2017-08-31T19:24:19  <gmaxwell> what ryanofsky said
338 2017-08-31T19:24:32  <gmaxwell> well almost obvious
339 2017-08-31T19:24:46  <luke-jr> that won't work for the different-sizes scenario, but sure
340 2017-08-31T19:24:48  <achow101> replicated the problem. will write up how in the issue after this class I am in
341 2017-08-31T19:24:49  <gmaxwell> ryanofsky: that one will lets the window be at width(),height(). :P
342 2017-08-31T19:24:54  <BlueMatt> yea, no idea what QApplication::desktop()->screenNumber(parent) == -1 does, but guess it doesnt work on win....someone able to test?
343 2017-08-31T19:25:05  <achow101> tl;dr look at the registry for qsettings for nWindowPos
344 2017-08-31T19:25:20  <ryanofsky> BlueMatt, that is probably the check for no longer connected multimonitor
345 2017-08-31T19:25:47  <meshcollider> ^^ if its -1 means the screen doesn't exist
346 2017-08-31T19:25:49  <achow101> if the setting is for an off screen point, nothing will show
347 2017-08-31T19:25:58  <gmaxwell> yea but it may do nothing on windows, perhaps on windows the window is just off screen.
348 2017-08-31T19:26:08  <BlueMatt> ryanofsky: yea, but that should work if you're on no screen? no idea
349 2017-08-31T19:26:19  <BlueMatt> anyway, I'll stop speculating above my paygrade
350 2017-08-31T19:26:38  <sipa> can someone open a bug?
351 2017-08-31T19:26:51  <BlueMatt> ^ that
352 2017-08-31T19:27:14  <gmaxwell> just reopen 7869 perhaps
353 2017-08-31T19:27:20  <jtimon> perhaps also PR ryanofsky's potential solution ?
354 2017-08-31T19:27:23  <sipa> i don't think we need to solve this problem in this meeting (though there seem few other topics)
355 2017-08-31T19:27:32  <ryanofsky> i think achow101 said he would write it up?
356 2017-08-31T19:27:40  <luke-jr> so that's 3 things for an rc4 I guess?
357 2017-08-31T19:27:46  <sipa> luke-jr: 3?
358 2017-08-31T19:27:51  <achow101> I'll make a new issue with the thing I just found
359 2017-08-31T19:27:51  <gmaxwell> We should talk about progress for full segwit support.
360 2017-08-31T19:27:53  <meshcollider> whats the 3rd?
361 2017-08-31T19:27:57  <instagibbs> gmaxwell, ack
362 2017-08-31T19:28:06  <sipa> achow101: thanks!
363 2017-08-31T19:28:06  <luke-jr> sipa: 1) positioning; 2) debug log tooltip; 3) acceptnonstdtxn help
364 2017-08-31T19:28:28  <morcos> i know i'm the cause of rc3, but i actually advocate for drawing the line somewhere
365 2017-08-31T19:28:31  <luke-jr> maybe 4) Polish translation update
366 2017-08-31T19:28:41  <morcos> it wasn't clear to me if we have to wait 2 weeks now until we have a new RC
367 2017-08-31T19:28:52  <luke-jr> morcos: IMO the positioning issue is sufficient to warrant rc4
368 2017-08-31T19:28:55  <morcos> if so i think none of those are maybe sufficient for RC4
369 2017-08-31T19:28:59  <sipa> morcos: let's discuss this when wumpus is available
370 2017-08-31T19:29:21  <luke-jr> especially if users are encountering it
371 2017-08-31T19:29:26  <morcos> ok. at the very least lets, note that its a question, instead of a conclusion that there will be RC4
372 2017-08-31T19:29:27  <meshcollider> yeah and first lets make sure the fix for the positioning issue actually solves the problem lol
373 2017-08-31T19:29:32  <morcos> luke-jr: but there is a workaround no?
374 2017-08-31T19:29:46  <morcos> how much valuable info do you lose my resetguisettings
375 2017-08-31T19:29:46  <sipa> meshcollider: indeed
376 2017-08-31T19:29:51  <luke-jr> morcos: not a nice one - you lose all your other GUI settings
377 2017-08-31T19:29:58  <achow101> morcos: all gui settings
378 2017-08-31T19:30:06  <achow101> it can also be fixed with regedt
379 2017-08-31T19:30:11  <sipa> achow101 said he'd open a bug with relevant information - let's discuss there when we have that
380 2017-08-31T19:30:22  <luke-jr> k
381 2017-08-31T19:30:26  <sipa> #topic full segwit support
382 2017-08-31T19:31:37  <sipa> i have a question: should we 1) automatically add witness redeem scripts for newly generated addresses, or 2) bypass the restriction that the redeemscript must be available for P2WPKH when the pubkey itself is available?
383 2017-08-31T19:32:07  <morcos> sipa: could you explain that a bit more thoroughly
384 2017-08-31T19:32:20  <BlueMatt> sipa: #1
385 2017-08-31T19:32:21  <sipa> the downside of 2) is that we'd accept segwit payments to converted-p2pkh-to-p2wpkh addresses (which i think is a bad property), but that it significantly reduced the overhead of adding a key
386 2017-08-31T19:32:29  <meshcollider> I'd say 1 is better
387 2017-08-31T19:33:06  <BlueMatt> i guess drawback of 1 is you cant receive via segwit to old addresses?
388 2017-08-31T19:33:09  <BlueMatt> I'm ok with that
389 2017-08-31T19:33:19  <sipa> BlueMatt: i would call that an advantage
390 2017-08-31T19:33:23  <BlueMatt> agreed
391 2017-08-31T19:33:29  <sipa> ideally we don't accept anything to an address that wasn't given out
392 2017-08-31T19:33:41  <sdaftuar> ^ that
393 2017-08-31T19:33:41  <gmaxwell> we should really try to avoid accepting an address that we'd never issue if at all possible, it's very dangerous if people think they can do that and have it work.
394 2017-08-31T19:33:49  <meshcollider> I guess there'd still be a way to manually do it if you wanted to though right?
395 2017-08-31T19:33:51  <luke-jr> indeed, if we accept segwit to non-segwit addresses, people might get a false impression it's supported, and lose money
396 2017-08-31T19:33:53  <Chris_Stewart_5> is #1 really that expensive?
397 2017-08-31T19:34:01  <sipa> alternatively, we can also have a boolean in the key meta data saying that the "corresponding" address is segwit
398 2017-08-31T19:34:20  <sipa> in which case we bypass the need-redeemscript property, but just for keys with that flag set
399 2017-08-31T19:34:40  <sipa> but at the cost of extra complexity
400 2017-08-31T19:34:44  <morcos> sipa: is hte issue wiht 1) bloat?
401 2017-08-31T19:34:48  <luke-jr> but when generating an address, it should only automatically add it if the user wants a witness address; we need to support at least P2SH-wrapper addresses until Bech32 adoption is widespread..
402 2017-08-31T19:34:50  <sipa> morcos: yes, just bloat
403 2017-08-31T19:34:55  <gmaxwell> manually sure, it's like importing a key.
404 2017-08-31T19:35:32  <sipa> luke-jr: that brings us to another question - my view is that we shouldn't support choosing on a per-address basis whether it should be segwit or not; just a wallet-wide flag that you now want segwit
405 2017-08-31T19:35:40  <luke-jr> sipa: I like the key metadata approach; that lets us refuse non-segwit payments to segwit keys
406 2017-08-31T19:35:43  <sipa> the reason for that is for interaction with hd auto topup
407 2017-08-31T19:35:49  <gmaxwell> ^ I think so to, wallet wide because of recovery.
408 2017-08-31T19:35:53  <instagibbs> i think wallets make a lot more sense if by default you do one or the other, and support importing otherwise
409 2017-08-31T19:35:53  <morcos> sipa: +1 on no per-address choosing
410 2017-08-31T19:36:04  <luke-jr> sipa: then nobody can reasonably use p2wpkh until support for bech32 is universal? :/
411 2017-08-31T19:36:06  <gmaxwell> importing one shows that violate the wallet wide is fine.
412 2017-08-31T19:36:07  <morcos> the whole point of segwit (well one of them) is we think thats the right way to do transactions)
413 2017-08-31T19:36:18  <BlueMatt> sipa: we could also do that on-disk, but in-memory keep the bloat-y version?
414 2017-08-31T19:36:29  <sdaftuar> how will the migration to bech32 work?
415 2017-08-31T19:36:42  <instagibbs> luke-jr, is there any reason we cant return multiple address types? thinking out loud :)
416 2017-08-31T19:36:48  <sipa> luke-jr: i think we'll be forced to support bech32 as an optional thing and treat bech32 and its p2sh embdeed version identially
417 2017-08-31T19:36:49  <luke-jr> also, doesn't this mean you can't upgrade existing wallets?
418 2017-08-31T19:36:49  <gmaxwell> sdaftuar: send to it first, and when ~everyone can send it it, we start generating addresses.
419 2017-08-31T19:36:51  <instagibbs> if we're doing a hard switchover, we can break api a bit?
420 2017-08-31T19:37:04  <luke-jr> instagibbs: eww :(
421 2017-08-31T19:37:06  <gmaxwell> sipa: ugh.
422 2017-08-31T19:37:19  <sipa> gmaxwell: there's no way we can switch over an entire wallet to bech32
423 2017-08-31T19:37:26  <sipa> at least not the first ... year?
424 2017-08-31T19:37:26  <gmaxwell> certantly not today!
425 2017-08-31T19:37:33  <gmaxwell> yes sure. and
426 2017-08-31T19:37:33  <instagibbs> luke-jr, elaborate the ew
427 2017-08-31T19:37:35  <luke-jr> sipa: that's why per-address is useful
428 2017-08-31T19:37:49  <sipa> luke-jr: but per-address is inherently incompatible with hd auto topup
429 2017-08-31T19:37:52  <gmaxwell> luke-jr: per-address is not backup durable.
430 2017-08-31T19:38:07  <luke-jr> hmm
431 2017-08-31T19:38:18  <luke-jr> what if we use separate HD chains for each type?
432 2017-08-31T19:38:21  <gmaxwell> why are we expanding scope to recieve BIP173 addresses. I think we should not make this scope expansion now.
433 2017-08-31T19:38:32  <morcos> gmaxwell: what did you not like, having bech32 and p2sh both supported together?
434 2017-08-31T19:38:37  <sipa> i think we have two options (which apply to both segwit/legacy and to p2sh/bech32): treat them as identical and accept payments to both, or switch over the wallet entirely
435 2017-08-31T19:38:37  <BlueMatt> <luke-jr> also, doesn't this mean you can't upgrade existing wallets? <-- yea. this. the discussion about hd-upgrade kinda devolved (I've been mia for a week so may be behind), but it seems to me with the current disk structure we need hd-upgrade before we can do segwit-upgrade unless we want to start forking the -upgradewallet stuff
436 2017-08-31T19:39:00  <gmaxwell> morcos: because then people can randomly turn your addresses to the other kind which you've never given out and pay you.
437 2017-08-31T19:39:47  <BlueMatt> yea, I think its unacceptable to do that cause we have shit like breaking uncompressed keys, so we really, really dont want to support people blindly converting addresses, sets a terrible understanding
438 2017-08-31T19:39:48  <sipa> my view is that we should treat bech32 and p2sh as identical - because, by design, they are identical - every segwit version is supposed to work in both
439 2017-08-31T19:39:52  <luke-jr> BlueMatt: even the ability to upgrade an existing HD wallet to a segwit+HD wallet would be nice
440 2017-08-31T19:39:52  <gmaxwell> the pre-segwit vs segwit version of that question is incredibly dangerous.   p2sh-embed vs not, is perhaps less so.
441 2017-08-31T19:39:59  <sipa> but we should not treat segwit and p2pkh as identical
442 2017-08-31T19:39:59  <morcos> so we can do this in 2 stages?  switch whole wallet to p2sh embedded segwit, and then in 6-12 mos switch whole wallet to bech32?
443 2017-08-31T19:40:00  *** Cheeseo has joined #bitcoin-core-dev
444 2017-08-31T19:40:05  *** asimplecoder has quit IRC
445 2017-08-31T19:40:16  *** Dyaheon has quit IRC
446 2017-08-31T19:40:18  <gmaxwell> sipa: we should have specified this as part of the segwit bips then. :(  but okay, it could be done.
447 2017-08-31T19:40:21  <BlueMatt> sipa: I'm ok with that
448 2017-08-31T19:40:38  <gmaxwell> morcos: that was my expectation, and we will have to do is regardless at least in terms of what addresses we return.
449 2017-08-31T19:40:41  <jtimon> sipa: well, we could , for example switch over enterily for segwit/legacy but treat identical for p2sh/bech32, no?
450 2017-08-31T19:40:52  <sipa> jtimon: that's exactly what i'm suggesting
451 2017-08-31T19:40:58  <BlueMatt> morcos: i think sipa is advocating for (and I like) - switch wallet over to "segwit" and give users the addresses in p2sh-embedded form, but really thats a ui-level thing
452 2017-08-31T19:41:07  * jtimon nods
453 2017-08-31T19:41:09  <BlueMatt> and maybe a flag for "i gave this address out as version X"
454 2017-08-31T19:41:11  <sipa> however, the bech32 question is not very urgent now
455 2017-08-31T19:41:21  <sipa> while switchover the segwit is
456 2017-08-31T19:41:43  <sipa> i guess there are a) support both for our own keys b) use separate hd chains for segwit c) switchover wallet as a whole
457 2017-08-31T19:41:46  <morcos> BlueMatt: right so we'd be capable of receiving a bech32 payment, but we would not give those out for some time?
458 2017-08-31T19:41:52  <sipa> i think (c) is best
459 2017-08-31T19:41:59  <BlueMatt> morcos: yes
460 2017-08-31T19:42:22  <instagibbs> BlueMatt, and send I hope?
461 2017-08-31T19:42:22  <BlueMatt> sipa: wait, I'm  confused...does c include a and b?
462 2017-08-31T19:42:24  <luke-jr> (c) will slow adoption
463 2017-08-31T19:42:24  *** Dyaheon has joined #bitcoin-core-dev
464 2017-08-31T19:42:37  <sipa> BlueMatt: they are 3 distinct possibilities
465 2017-08-31T19:43:01  <achow101> (c) works well with multi wallet
466 2017-08-31T19:43:10  <sipa> (c) means there is a wallet-wide flag that says "SEGWIT: YES", and if so, all new addresses are generated as segwit, and integrated with hd topup
467 2017-08-31T19:43:24  <sipa> but no separate chains for segwit or not
468 2017-08-31T19:43:25  <instagibbs> achow101, right, my ledger support will likely simply utilize multiwallet for crossover
469 2017-08-31T19:43:31  <gmaxwell> sipa: and if we wanted to convert an old wallet we could just import all the keys.
470 2017-08-31T19:43:32  <BlueMatt> sipa: ah, yes, back to my previous question...what form does that flag take
471 2017-08-31T19:43:41  <sipa> BlueMatt: i see
472 2017-08-31T19:43:45  <BlueMatt> sipa: cause its damn-dirty to add a flag like that and not use our versioning stuff
473 2017-08-31T19:43:50  <achow101> If we do that, we can also implement the optional features thing for wallets
474 2017-08-31T19:43:54  <BlueMatt> but using our versioning stuff means we need hd-upgrade
475 2017-08-31T19:44:01  <sipa> BlueMatt: i want to get rid of the version stuff and have feature flags
476 2017-08-31T19:44:02  <BlueMatt> which i think we need, but may delay things
477 2017-08-31T19:44:20  <BlueMatt> sipa: but exponential blowup of feature options :(
478 2017-08-31T19:44:35  <sipa> BlueMatt: yes...
479 2017-08-31T19:45:03  <sipa> so perhaps the question is: is there any reason why wallets shouldn't have that segwit flag (apart from backup reasons)
480 2017-08-31T19:45:10  * BlueMatt sees no reason to *not* use existing versioning, but only question is possible delay
481 2017-08-31T19:45:32  <instagibbs> BlueMatt, sorry delay how
482 2017-08-31T19:45:42  <BlueMatt> sipa: yes, like anything else in the wallet, if user doesnt say -upgradewallet, we'd prefer to not break their backward compat
483 2017-08-31T19:45:53  <BlueMatt> instagibbs: because if we use the versioning stuff, hd-upgrade must happen first
484 2017-08-31T19:46:00  <morcos> Someone should write up a more comprehensive wallet plan.  The only thing that's clear is we need to support any kind of wallet that has existed in the past
485 2017-08-31T19:46:02  <instagibbs> Ah, user delay, noted
486 2017-08-31T19:46:19  <meshcollider> well it would only happen when they choose to upgrade to segwit only, so you can just give them a warning then right
487 2017-08-31T19:46:19  <jtimon> sipa: what if the payer can't pay to segwit ? I think that's why luke wants to be able to genreate legacy for receiving, no?
488 2017-08-31T19:46:21  <instagibbs> morcos, some people will be in person in a few days.... would be a good time to review such a doc
489 2017-08-31T19:46:22  <morcos> But we don't need to support any possible combination..  So we shouldn't have segwit non-HD chain split wallets for example
490 2017-08-31T19:46:28  <sipa> jtimon: every wallet can send to P2SH
491 2017-08-31T19:46:29  <morcos> so lets make sure there is no way to create that
492 2017-08-31T19:46:32  <BlueMatt> morcos: we've generally supported opening new wallets with old versions as long as they are un-upgraded, too
493 2017-08-31T19:46:40  <jtimon> sipa: , oh, right, never mind
494 2017-08-31T19:46:52  <gmaxwell> for upgrading I think we'd set the flag, start exploring the segwit address chain from 0 and import all the old keys as whatever they are.
495 2017-08-31T19:47:09  <sipa> BlueMatt: yes, understood, but apart from that, is there any reason why someone would not want their wallet to construct segwit outputs?
496 2017-08-31T19:47:09  <sipa> *addresses
497 2017-08-31T19:47:09  <BlueMatt> morcos: yes, well then we need a "list of acceptable feature flag combinations" against which we check the wallet on load.... :/
498 2017-08-31T19:47:16  <gmaxwell> sipa: no, only wallets that are trying to stay unupgraded.
499 2017-08-31T19:47:27  <morcos> or for instance having segwit implies HD-chain split...
500 2017-08-31T19:47:29  <BlueMatt> sipa: not to my knowledge, no
501 2017-08-31T19:47:30  <sipa> so do we need a flag at all?
502 2017-08-31T19:47:40  <sipa> as opposed to just start doing it automatically in a new version
503 2017-08-31T19:47:43  <BlueMatt> only upgrade, to me
504 2017-08-31T19:47:56  <BlueMatt> well we'd need users to do a -walletupgrade
505 2017-08-31T19:48:01  <sipa> i don't think so
506 2017-08-31T19:48:11  <BlueMatt> errr, I'm not a fan of that
507 2017-08-31T19:48:29  <meshcollider> If you give them the setting somewhere in Qt then it can give them a compat warning when they go to upgrade it
508 2017-08-31T19:48:30  <BlueMatt> that'd be the first time we break opening new wallets with an old version by default (and have no way to not break it!)
509 2017-08-31T19:48:32  <sipa> maybe i'm missing something, but i see no failure scenario
510 2017-08-31T19:48:39  <BlueMatt> i guess if we do that we should switch to bdb 5
511 2017-08-31T19:48:47  <gmaxwell> if there is a reason we're unaware of the user can stay on the old version until we add support for whatever we want.
512 2017-08-31T19:48:48  <luke-jr> sipa: downgrading
513 2017-08-31T19:48:53  <sipa> luke-jr: elaborate
514 2017-08-31T19:49:06  <sipa> old versions will produce old addresses, and not add the witness redeem script
515 2017-08-31T19:49:08  <luke-jr> sipa: if I take my wallet, use it with 0.16, I should be able to use the same wallet with 0.12 again
516 2017-08-31T19:49:10  <jtimon> do we want to support downgrading wallets?
517 2017-08-31T19:49:25  <luke-jr> until I use -walletupgrade ofc
518 2017-08-31T19:49:25  <BlueMatt> sipa: its always been the case that you can pretty easily run your wallet with an old version as long as it is not upgraded
519 2017-08-31T19:49:30  <BlueMatt> with no significant feature loss
520 2017-08-31T19:49:34  <sipa> new versions will produce new address, add their redeemscript, and when downgrading, those addresses will keep working
521 2017-08-31T19:49:37  <BlueMatt> and definitely not with missing transactions
522 2017-08-31T19:49:38  <sipa> BlueMatt: i don't see a problem
523 2017-08-31T19:49:45  <achow101> So upgrade it with a version number
524 2017-08-31T19:49:48  <luke-jr> sipa: old versions don't know how to sign for segwit UTXOs..
525 2017-08-31T19:49:51  <BlueMatt> sipa: missing transactions
526 2017-08-31T19:49:58  <sipa> BlueMatt: ?
527 2017-08-31T19:50:12  <sipa> segwit address will work fine in older versions, if we use the redeemscript add construction
528 2017-08-31T19:50:13  <BlueMatt> if you receive a payment using segwit and then open that wallet with an old version, it will not be there
529 2017-08-31T19:50:20  <sipa> yes it will be
530 2017-08-31T19:50:24  <sipa> at least down to 0.13.0
531 2017-08-31T19:50:30  <luke-jr> sipa: and it will spend?
532 2017-08-31T19:50:34  <sipa> luke-jr: yes
533 2017-08-31T19:50:41  <sipa> luke-jr: the signing code for segwit works fine
534 2017-08-31T19:50:48  <BlueMatt> mm, fair, though will fail for native segwit, I suppose?
535 2017-08-31T19:50:51  <sipa> yes
536 2017-08-31T19:50:58  <sipa> but ignore bech32 for now
537 2017-08-31T19:51:02  <jtimon> dow we want to support wallet downgrade beyond 0.13 ?
538 2017-08-31T19:51:08  <luke-jr> sipa: okay, so how does this all work for people who actively do not wish to use segwit transactions?
539 2017-08-31T19:51:10  <sipa> jtimon: that's a good question
540 2017-08-31T19:51:16  <BlueMatt> ohhhhhhhhhh, wait, errrrrr, wont everythin break anyway cause it wont deserialize segwit-formatted txn in the wallet pre-0.13.0?
541 2017-08-31T19:51:22  <sipa> BlueMatt: yes
542 2017-08-31T19:51:30  <BlueMatt> lol, ok, well we're not fixing that one
543 2017-08-31T19:51:34  <BlueMatt> so I dont care
544 2017-08-31T19:51:39  <morcos> we're talking about 2 different things...  are you saying if i open an 0.12 wallet in 0.16, then i can't reopen it in 0.12
545 2017-08-31T19:51:41  <sipa> i guess BlueMatt answered jtimon's question
546 2017-08-31T19:51:43  <morcos> that sounds like a terrible idea
547 2017-08-31T19:51:49  <gmaxwell> I think it's fine if use of segwit makes the wallet 0.15.1+
548 2017-08-31T19:51:51  <sipa> morcos: that's already the case...
549 2017-08-31T19:51:53  <morcos> if you upgrade it, then yeah of course you don't need to be able to go backwards
550 2017-08-31T19:52:01  <BlueMatt> gmaxwell: I'm not ok with that, I think
551 2017-08-31T19:52:02  <luke-jr> sipa: why?
552 2017-08-31T19:52:02  <morcos> sipa: huh?
553 2017-08-31T19:52:10  <gmaxwell> wut
554 2017-08-31T19:52:11  <sipa> morcos: because of what BlueMatt says
555 2017-08-31T19:52:12  <morcos> i don't think so at all
556 2017-08-31T19:52:18  <BlueMatt> gmaxwell: I'm fine with it being 0.13.0, which it already is
557 2017-08-31T19:52:22  <morcos> hmm.
558 2017-08-31T19:52:25  <sipa> you can receive a segwit transaction that pays you (via legacy output)
559 2017-08-31T19:52:29  <morcos> i don't think so
560 2017-08-31T19:52:29  <BlueMatt> gmaxwell: do we have any need to make it 0.15.1?
561 2017-08-31T19:52:31  <sipa> that will be stored as a segwit txn in your wallet
562 2017-08-31T19:52:33  <gmaxwell> I bet it doesn't work for 0.13.0
563 2017-08-31T19:52:35  <BlueMatt> do we get any features from that, really?
564 2017-08-31T19:52:36  <sipa> which 0.12 won't open
565 2017-08-31T19:52:37  <morcos> oh maybe
566 2017-08-31T19:52:38  <morcos> durn
567 2017-08-31T19:52:44  <luke-jr> ugh
568 2017-08-31T19:52:51  <meshcollider> Not if you just open the wallet without generating new addresses though ?
569 2017-08-31T19:52:57  <gmaxwell> BlueMatt: how about testing resources if nothing else... but also you'll corrupt your wallet, when it doesn't know how to extend the keypool.
570 2017-08-31T19:53:07  <luke-jr> does that mean if 0.12 receives a segwit tx, it will break newer??
571 2017-08-31T19:53:19  <sipa> meshcollider: there can be a segwit address that pays you via a plain old p2pkh address
572 2017-08-31T19:53:19  <BlueMatt> gmaxwell: if the wallet is un-upgraded it wont break?
573 2017-08-31T19:53:30  <BlueMatt> gmaxwell: obviously if its an hd wallet old versions will refuse to open
574 2017-08-31T19:53:38  <gmaxwell> BlueMatt: if it's unupgraded it's not giving out segwit addresses.
575 2017-08-31T19:53:48  <BlueMatt> gmaxwell: though testing resources are obviously always an issue
576 2017-08-31T19:54:02  <BlueMatt> gmaxwell: sipa was proposing that it give out segwit addresses even if it is unupgraded
577 2017-08-31T19:54:30  <luke-jr> what happens right now, if we have a segwit tx in the wallet without witness data? :/
578 2017-08-31T19:54:31  <gmaxwell> BlueMatt: how the heck does this even work for HD chains.
579 2017-08-31T19:54:32  <instagibbs> 6 minutes
580 2017-08-31T19:54:49  <meshcollider> sipa
581 2017-08-31T19:54:58  <sipa> gmaxwell: it will work fine, unless you downgrade at the same time as you recover
582 2017-08-31T19:55:00  <BlueMatt> gmaxwell: hd doesnt matter...wait, sipa was saying no new hd chain, maybe we should reopen that part of the discussion :p
583 2017-08-31T19:55:01  <meshcollider> isnt that only the case if you gave out the address
584 2017-08-31T19:55:07  <sipa> meshcollider: no
585 2017-08-31T19:55:14  <sipa> 19:53:19 < sipa> meshcollider: there can be a segwit address that pays you via a plain old p2pkh address
586 2017-08-31T19:55:28  <sipa> ^ in that case you don't ever generated a segwit address
587 2017-08-31T19:55:29  <meshcollider> Can anyone generate that themselves?
588 2017-08-31T19:55:42  <jtimon> in any case, is the question adding a new wallet version or not?
589 2017-08-31T19:55:42  <BlueMatt> lol, sounds like we've got a lot to discuss next week
590 2017-08-31T19:55:50  <BlueMatt> homework: everyone go farmiliarize yourself with wallet
591 2017-08-31T19:55:53  <BlueMatt> ALL OF WALLET =D
592 2017-08-31T19:55:54  <achow101> I'm horribly confused now
593 2017-08-31T19:56:09  <sipa> meshcollider: no, but the sender can be segwit enabled while you aren't
594 2017-08-31T19:56:13  <luke-jr> BlueMatt: every time I do that, I get the inclination to throw it all away and start from scratch :x
595 2017-08-31T19:56:33  <cfields> heh, we desperately need to break this discussion up into chunks
596 2017-08-31T19:56:40  <BlueMatt> cfields: yes
597 2017-08-31T19:56:51  <instagibbs> can someone whip up a table or something of concerns
598 2017-08-31T19:56:56  <instagibbs> action item?
599 2017-08-31T19:57:01  <luke-jr> kanzure has one
600 2017-08-31T19:57:06  <luke-jr> just needs updating
601 2017-08-31T19:57:08  <achow101> Kanzure: add to list?
602 2017-08-31T19:57:15  <meshcollider> oh I see yeah, true
603 2017-08-31T19:57:21  <instagibbs> oh, for that too, if you're in SF next week
604 2017-08-31T19:57:24  <cfields> kanzure: and update it so that it's backwards compatible to the last list, please.
605 2017-08-31T19:57:36  <achow101> Lol
606 2017-08-31T19:57:54  <sipa> a) how to deal with 0.13.1 through 0.15.0 receiving a segwit transaction and then downgrading to 0.12.x or below
607 2017-08-31T19:58:05  <sipa> b) how to switch to generating segwit addresses
608 2017-08-31T19:58:11  <sipa> c) how to switch to generating bech32 addresses
609 2017-08-31T19:58:39  <jtimon> I won't go this time :( have productive discussions there, and fun too!
610 2017-08-31T19:58:44  <BlueMatt> d) how to deal with 0.15.1 downgradingg to 0.13.1 (in both hd and non-hd modes)
611 2017-08-31T19:59:05  <BlueMatt> e) whether to use a new hd chain for segwit addresses
612 2017-08-31T19:59:13  <sipa> e falls under b
613 2017-08-31T19:59:18  <BlueMatt> err, ok
614 2017-08-31T19:59:21  <gmaxwell> BlueMatt: please just don't support that. It makes no sense to back and revalidate segwit wallet support in old versions.
615 2017-08-31T19:59:43  <gmaxwell> we will not manage to adequately test it and it will sharply constrain our implementation choices.
616 2017-08-31T19:59:45  <sipa> any last minute short topic?
617 2017-08-31T19:59:46  <BlueMatt> gmaxwell: then we should explicitly break it...but, anyway, lets have this discussion next week
618 2017-08-31T19:59:48  <gmaxwell> and lead to weird corner case bugs.
619 2017-08-31T20:00:01  <instagibbs> sipa, activate schnorr?
620 2017-08-31T20:00:02  <sipa> #endmeeting
621 2017-08-31T20:00:02  <lightningbot> Meeting ended Thu Aug 31 20:00:02 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
622 2017-08-31T20:00:02  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-31-19.05.html
623 2017-08-31T20:00:02  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-31-19.05.txt
624 2017-08-31T20:00:02  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-31-19.05.log.html
625 2017-08-31T20:00:04  <instagibbs> too late, over
626 2017-08-31T20:00:05  <jtimon> gmaxwell: besides, is downgrading such an important use case?
627 2017-08-31T20:00:12  <BlueMatt> if we dont support downgrading, I very, very strongly support switching to bdb5 for wallet
628 2017-08-31T20:00:14  <gmaxwell> instagibbs: schnorr is cancled.
629 2017-08-31T20:00:21  <instagibbs> gmaxwell, ah shite.
630 2017-08-31T20:00:28  <chainhead> aggregated signatures
631 2017-08-31T20:00:38  <gmaxwell> Yea, AggSig.
632 2017-08-31T20:00:40  <luke-jr> BlueMatt: what does bdb5 have over 4?
633 2017-08-31T20:00:52  <meshcollider> eventually we want to remove bdb entirely right
634 2017-08-31T20:00:59  <sipa> nothing we care about, except likely being slightly longer supported in OSes
635 2017-08-31T20:01:02  <achow101> luke-jr it's actually in package managers by default
636 2017-08-31T20:01:09  <BlueMatt> luke-jr: not having every goddamned distro build with the backward-compat-break option?
637 2017-08-31T20:01:09  <esotericnonsense> is there a specific goal in mind with regard to downgrading? a 'support period' as such? it seems to me that defining that would be useful. say, 1 major version back, otherwise all bets are off.
638 2017-08-31T20:01:26  <BlueMatt> luke-jr: its purely a make-distros-keep-our-wallets-sane thing
639 2017-08-31T20:01:41  <sipa> esotericnonsense: https://bitcoincore.org/en/lifecycle/
640 2017-08-31T20:01:54  <luke-jr> sipa: that's never applied to wallets though
641 2017-08-31T20:01:56  <sipa> 0.12 is EOL
642 2017-08-31T20:02:02  <luke-jr> wallets were supposed to remain compat to 0.3 even :/
643 2017-08-31T20:02:31  <sipa> we still stupport wallet files from 0.3.0 (and even lower, i think)
644 2017-08-31T20:02:31  <BlueMatt> luke-jr: well the second segwit activated that broke - we can now put transactions in the wallet (today) that have witnesses and those versions will fail to deserialize, I presume
645 2017-08-31T20:02:47  <BlueMatt> er, yes, but loading them should still be fine
646 2017-08-31T20:02:51  <luke-jr> BlueMatt: sounds like a bug :(
647 2017-08-31T20:02:53  <sipa> downgrading that far back is probably broken in multiple other ways too
648 2017-08-31T20:03:17  <luke-jr> BlueMatt: why don't we store them stripped?
649 2017-08-31T20:03:25  <sipa> luke-jr: iirc, no
650 2017-08-31T20:03:42  <luke-jr> sipa: ?
651 2017-08-31T20:03:56  <sipa> if i recall correctly, we do not store wallet transactions stripped
652 2017-08-31T20:03:58  <luke-jr> "why?" is not a boolean question :p
653 2017-08-31T20:04:08  * sipa lunch
654 2017-08-31T20:04:24  <esotericnonsense> i would be curious to know how many users actually express a desire to downgrade significantly (i.e. beyond some sort of emergency 'we found out .15.1 is broken, go back to .15' scenario). but I feel that I'm interrupting and so will shuffle off.
655 2017-08-31T20:04:39  <jtimon> so our goal is to make 0.15.1 wallets dongradeable to 0.12 ? that's I think too ambitious...
656 2017-08-31T20:04:47  <BlueMatt> esotericnonsense: I think its really just an "emergency-need-to-downgrade" support thing
657 2017-08-31T20:05:00  <BlueMatt> which, realistically, just means you need to be able to downgrade to the latest stable of the previous version
658 2017-08-31T20:05:05  <morcos> we have to stop using confusing technology
659 2017-08-31T20:05:11  <morcos> we don't support any downgrading now do we
660 2017-08-31T20:05:17  <morcos> we just support not-upgrading
661 2017-08-31T20:05:18  <BlueMatt> jtimon: I dont think thats possible, 0.13.1 may be possible, but, indeed, is also ambitious
662 2017-08-31T20:05:25  <morcos> or at least we used to
663 2017-08-31T20:05:29  <BlueMatt> morcos: i think you can create an old-version wallet
664 2017-08-31T20:05:33  <luke-jr> morcos: we've always supported downgrading 0.X wallets back to 0.X
665 2017-08-31T20:05:45  <morcos> why are you calling downgrading it
666 2017-08-31T20:05:49  <BlueMatt> morcos: we theoretically try to avoid breaking downgrading if you did not explicitly upgrade your wallet
667 2017-08-31T20:05:53  <BlueMatt> (with -walletupgrade)
668 2017-08-31T20:06:02  *** Roger2x has quit IRC
669 2017-08-31T20:06:07  <morcos> if you take 0.10 wallet and run it in 0.14, it doesn't get upgraded automatically does it, its still a 0.10 wallet
670 2017-08-31T20:06:14  <luke-jr> morcos: that's the goal, yes
671 2017-08-31T20:06:16  <BlueMatt> correct
672 2017-08-31T20:06:17  <morcos> so you don't have to downgrade it to use it in 0.10
673 2017-08-31T20:06:24  <luke-jr> morcos: apparently we broke that in 0.13.1
674 2017-08-31T20:06:24  <morcos> you never upgraded it
675 2017-08-31T20:06:26  <BlueMatt> grrr, terminology
676 2017-08-31T20:06:28  <morcos> yes i understand
677 2017-08-31T20:06:31  <morcos> but stop saying downgrade
678 2017-08-31T20:06:39  <BlueMatt> you downgraded your node
679 2017-08-31T20:06:54  <morcos> that implies you take a bech32 segwit hd-split schnorr sig aggregation wallet with tons of txs and convert it back to some old format
680 2017-08-31T20:06:58  <luke-jr> it sounds like a simple fix would be to just store txs stripped in the wallet
681 2017-08-31T20:07:03  <sipa> luke-jr: a reason to not stre wallet txn as stripped: if you rebroadcast an unconfirmed tx, it needs to include the witness
682 2017-08-31T20:07:12  <morcos> not that you were using an old format wallet in a new piece of software but not using any of those features
683 2017-08-31T20:07:15  <jtimon> BlueMatt: right, to 14.2 sounds reasonable " just means you need to be able to downgrade to the latest stable of the previous version"
684 2017-08-31T20:07:20  <luke-jr> sipa: does this break right now, if we received the tx with 0.12?
685 2017-08-31T20:07:39  * BlueMatt -> food
686 2017-08-31T20:07:45  <GAit> jnewbery: want me to just squash or rebase too?
687 2017-08-31T20:07:48  <BlueMatt> to-be-continued next week :)
688 2017-08-31T20:07:58  <luke-jr> BlueMatt: kk
689 2017-08-31T20:08:17  <luke-jr> I need to get back to something too, so next week sgtm
690 2017-08-31T20:09:16  <meshcollider> next week is sf right? will you guys have a meeting summary online or something for those that aren't going
691 2017-08-31T20:09:30  <kanzure> i will type things
692 2017-08-31T20:09:39  <meshcollider> awesome thanks :)
693 2017-08-31T20:12:05  <achow101> What about doing a voice recording?
694 2017-08-31T20:12:11  *** chjj has quit IRC
695 2017-08-31T20:12:15  <kanzure> nah
696 2017-08-31T20:12:44  <kanzure> https://bitcoincore.org/logs/2016-05-zurich-meeting-notes.html
697 2017-08-31T20:14:41  <jnewbery> GAit: no need to rebase if there are no merge conflicts
698 2017-08-31T20:15:26  <GAit> jnewbery: didn't rebase - however last time while there was no merge conflict the semantic changed and broke the tests :)
699 2017-08-31T20:15:37  <GAit> thanks
700 2017-08-31T20:17:45  <kanzure> cfields: please clarify if that was a joke or not
701 2017-08-31T20:17:53  <cfields> kanzure: heh, yes
702 2017-08-31T20:18:10  <kanzure> oh sipa's list?
703 2017-08-31T20:18:19  <kanzure> "yes" to an "or" tsk tsk
704 2017-08-31T20:19:12  <bitcoin-git> [bitcoin] MeshCollider opened pull request #11208: Fixing offscreen GUI issue (master...201709_offscreen_fix) https://github.com/bitcoin/bitcoin/pull/11208
705 2017-08-31T20:20:10  <kanzure> added.
706 2017-08-31T20:23:15  *** tuberculo has joined #bitcoin-core-dev
707 2017-08-31T20:24:17  *** c40d9b0743a91f40 has joined #bitcoin-core-dev
708 2017-08-31T20:30:15  *** klkk has quit IRC
709 2017-08-31T20:31:06  *** dermoth_ has joined #bitcoin-core-dev
710 2017-08-31T20:31:23  *** dermoth has quit IRC
711 2017-08-31T20:31:25  *** dermoth_ is now known as dermoth
712 2017-08-31T20:32:44  *** RoyceX has joined #bitcoin-core-dev
713 2017-08-31T20:33:45  *** Cheeseo has quit IRC
714 2017-08-31T20:36:03  *** tuberculo has quit IRC
715 2017-08-31T20:36:34  <gmaxwell> sipa: can you propose a BIP modification to say that anything that accepts p2sh embedded segwit should also accept the non-embedded form  or something
716 2017-08-31T20:36:48  <gmaxwell> I can buy your argument that it's reasonable to support both forms.
717 2017-08-31T20:36:55  <gmaxwell> But it's weird if if its totally adhoc.
718 2017-08-31T20:39:53  <luke-jr> seems a bit late for that
719 2017-08-31T20:40:18  <luke-jr> do other wallets support it?
720 2017-08-31T20:40:21  *** Chris_Stewart_5 has quit IRC
721 2017-08-31T20:40:39  <gmaxwell> ::sigh::
722 2017-08-31T20:40:43  <gmaxwell> it's bad if its inconsistent.
723 2017-08-31T20:40:56  <gmaxwell> "I converted this address, and it worked, I converted that address and the funds vanished into space"
724 2017-08-31T20:41:26  <luke-jr> people shouldn't try to "convert" addresses anyway. :/
725 2017-08-31T20:42:56  <gmaxwell> indeed, which is why I think it's bad to add both key types.
726 2017-08-31T20:42:58  <kanzure> yep, wallets should only be expected to receive whatever was given
727 2017-08-31T20:43:11  <kanzure> (by getnewaddress etc)
728 2017-08-31T20:43:16  <gmaxwell> but we do end up with another migration problem with the later switch to bech32, which would be sad.
729 2017-08-31T20:54:02  <sipa> luke-jr, gmaxwell: unfortunately, that means we'll be forced to have a separate chain for bech32 addresses
730 2017-08-31T20:54:06  <sipa> perhaps that's the best solution
731 2017-08-31T20:56:46  <instagibbs> sipa, in the case of migrating again?
732 2017-08-31T20:56:49  <luke-jr> probably more future-proof too
733 2017-08-31T20:59:08  <gmaxwell> sipa: that is what I expected us to do
734 2017-08-31T20:59:43  <gmaxwell> we'll also have this same thing for future sig versions like a v1 with aggsig.
735 2017-08-31T21:00:18  <gmaxwell> as an aside the masterkey lines in our dumps should include flags for this stuff
736 2017-08-31T21:00:40  <gmaxwell> but I coudl also buy the parallel for v0 and p2sh embedded... it would have some migration advantages.
737 2017-08-31T21:01:26  <gmaxwell> (I'm worried that we shouldn't do anything to delay supporting this though.)
738 2017-08-31T21:10:33  <morcos> I'm not sure I understand why you have to switch to a new chain.  Why can't you just "upgrade" your old chain to support a new address type.. or is the idea that once you support bech32 you'll no longer support the p2sh version
739 2017-08-31T21:10:36  <morcos> or that a new bech32 chain won't i mean
740 2017-08-31T21:11:44  <sipa> morcos: if we want to be strict, and only accept payments to bech32 when a bech32 addr was given out, and p2sh/p2wpkh when that was given out, they need to be separate chains, or you need to drop support for one of them entirely
741 2017-08-31T21:11:47  <gmaxwell> so if you are adding keys for both types, it means that people can 'convert' your addresses and have it work, which is a funds loss risk when they do it someplace where it doesn't work.
742 2017-08-31T21:11:52  <sipa> otherwise you can't know when rescanning which is one
743 2017-08-31T21:13:17  <gmaxwell> We could take a position that we'll always do dual p2sh embedded and native (at least for the forseeable future) in parallel... but that will still be a risk for every wallet that isn't us, and for bitcoin core users with explicitly imported keys, when something thinks it can convert.
744 2017-08-31T21:13:56  <gmaxwell> and we cannot do dual-addresses for pre-segwit+segwit because of things like uncompressed keys.
745 2017-08-31T21:15:54  <gmaxwell> Because as sipa points out p2sh embedding would work for _all_ segwit, we could realistically do dual support there.
746 2017-08-31T21:16:23  <morcos> I don't know.  I guess I'm not 100% sold on the philosophy.   It kind of seems to me that if someone does pay you to an address you didn't give them.. You're going to want to find some way to recover those funds no?
747 2017-08-31T21:17:10  <morcos> I mean I get why we don't want to encourage a culture of loosey-goosey hide the key in your backyard or however you put it gmaxwell
748 2017-08-31T21:17:19  <gmaxwell> morcos: thats kind of the issue... then your keys are embedded in an HSM and it's virtually impossible for you to do that... or to do so you need to do dangerous crap with private keys,
749 2017-08-31T21:18:11  <gmaxwell> So basically if this is supported as a reasonable and customary practice, then it creates an effective obligation to do it.
750 2017-08-31T21:18:52  <morcos> But to me there is a tenous link btwn the fact that the wallet would be smart enough to accept it and people actually being encouraged to do it
751 2017-08-31T21:19:14  <instagibbs> also doesn't this basically require someone to understand bech32, but decide to wrap in p2sh?
752 2017-08-31T21:19:26  <morcos> You could even add some sort of flag or warning on txs that were received using unexpected address types
753 2017-08-31T21:19:42  <luke-jr> if someone pays to an address I didn't give them, they burned the bitcoins. they didn't pay me.
754 2017-08-31T21:19:44  <instagibbs> most cases should be the sender simply not understanding the bech32?
755 2017-08-31T21:19:49  <gmaxwell> morcos: things that work are what people do, this is the lesson from history  -- in bitcoin but also in every internet protocol.  If we make it work we need to be ready to support it.
756 2017-08-31T21:20:33  <gmaxwell> People deciding what to do don't read specs, they try them out and they do whatever works.
757 2017-08-31T21:21:02  <gmaxwell> I think we could reasonably support p2sh-embedded and segwit duality. Sipa points out that it'll work universally.
758 2017-08-31T21:21:03  <morcos> well perhaps we could solve the problem i'm more concerned with in a different way by making different paths in the HD wallet
759 2017-08-31T21:21:10  <morcos> so the same key never was used for both
760 2017-08-31T21:21:15  <morcos> but you don't have to change master keys
761 2017-08-31T21:21:24  <gmaxwell> morcos: you do that by using a different path.
762 2017-08-31T21:21:31  <morcos> the issue i don't like is invalidating peoples backups
763 2017-08-31T21:21:36  <gmaxwell> Which is what other wallets are also doing for segwit suppot, fwiw.
764 2017-08-31T21:21:48  <morcos> so when we're talking about switching to a new chain for bech32, we'r ejust talking about a new path?
765 2017-08-31T21:22:00  <sipa> morcos: yes
766 2017-08-31T21:22:01  <morcos> that seems much more reasonable to me
767 2017-08-31T21:22:17  <gmaxwell> I assume but the backup is somewhat invalidated because the backup doesn't have the metadata to tell it what paths are used. This is also true for the hdsplit.
768 2017-08-31T21:22:17  <sipa> and perhaps if we plan to do that, we should do the same for p2sh-p2wpkh
769 2017-08-31T21:22:51  <morcos> ignore my objections then...   seems like we should do a quick online survey of other wallet providers and assess whether most have expected that p2sh wrapped == bech32, that is if you accept one you accept the other
770 2017-08-31T21:22:51  <sipa> there is a distinction in that bech32 or not is probably something we do want to do on a per-key basis
771 2017-08-31T21:22:58  <morcos> and unless thats nearly universal, we shouldn't introduce it
772 2017-08-31T21:23:00  <luke-jr> gmaxwell: backups can be expected invalidated when -walletupgrade is used
773 2017-08-31T21:23:20  <gmaxwell> Esp for BIP173; the transition can't really be done abruptly unless its seriously delayed.
774 2017-08-31T21:23:35  <instagibbs> morcos, most are doing bip49 I think, which only is about nested
775 2017-08-31T21:23:36  <morcos> luke-jr: why?  shouldn't you just be able to -upgrade your backup
776 2017-08-31T21:23:45  <gmaxwell> while if we do dual embedded and native then probably I can use bech32 on day one, e.g. my exchange supports it, so I have it pay me via a 173 address.
777 2017-08-31T21:23:46  <instagibbs> not sure what they're expecting to do with bech32
778 2017-08-31T21:24:04  <sipa> morcos: that doesn't work for upgrading to hd, to hd split, nor for adding new chains
779 2017-08-31T21:24:13  <gmaxwell> morcos: just the backup doesn't know where and when the pathing change happened.
780 2017-08-31T21:24:23  <luke-jr> morcos: hmm, it might work in this case, but IMO we shouldn't *expect* it to
781 2017-08-31T21:24:32  <gmaxwell> i suppose you could replay the same actions and have it work, but it's tricky and easy to screw up.
782 2017-08-31T21:25:20  <gmaxwell> e.g. backup your wallet on day 0 with no segwith, use 100,000 keys... upgrade it later... use another 10000 keys... erase wallet... now how do you reproduce this...
783 2017-08-31T21:25:41  <gmaxwell> you need to know to expand the keypool 100,000 keys, then switch...
784 2017-08-31T21:25:42  <luke-jr> gmaxwell: if segwit uses a new path/chain, this would just work I guess
785 2017-08-31T21:26:14  <morcos> well, i was assuming the path branch happened at the beginning, but maybe that was a bad assumption
786 2017-08-31T21:26:18  <morcos> in which case you'd just look ahead whatever the number of keys is on all paths
787 2017-08-31T21:26:31  <gmaxwell> yes, it should happen at the beggin... how do we know to go to 100,000...
788 2017-08-31T21:26:33  <gmaxwell> okay, thats a more keypools solution.
789 2017-08-31T21:26:48  <luke-jr> gmaxwell: start monitoring both chains at their beginning, and extend each as needed
790 2017-08-31T21:26:51  <morcos> the same way we know to go to 100k if we never did anything and you backedup your wallet with nothing in it
791 2017-08-31T21:26:55  <gmaxwell> perhaps... this has some other tradeoffs.
792 2017-08-31T21:27:34  <morcos> i don't understand how you don't have to do that anyway
793 2017-08-31T21:27:34  <gmaxwell> e.g. say we have 4 segwit versions, and so now we have 10 keypools.
794 2017-08-31T21:27:34  <gmaxwell> but only one of them has ever been used.
795 2017-08-31T21:28:10  <morcos> so what happens when you upgrade your wallet?  don't you have to still keep keypools for your old chains anyway?
796 2017-08-31T21:28:40  <morcos> or are you suggesting the upgrade is the user saying, i have no pending payments forever in the future for any address i've ever given out
797 2017-08-31T21:29:13  *** Cheeseo has joined #bitcoin-core-dev
798 2017-08-31T21:29:17  <gmaxwell> yep. that was my thinking.. just import all the keys that are already used.
799 2017-08-31T21:29:24  <luke-jr> gmaxwell: if we're worried about it, we should just stop using keypools?
800 2017-08-31T21:29:28  <adiabat> not to complicate things further, but my wallet software supports bech32 / p2wpkh but ignores nested completely
801 2017-08-31T21:29:30  <gmaxwell> it's not even clear to me that we should support upgrading.
802 2017-08-31T21:30:14  <gmaxwell> for something that changes your key paths perhaps we should only support that for new wallets.   If you want old keys in it, you can import.
803 2017-08-31T21:30:17  <sipa> gmaxwell: there is no 'import'
804 2017-08-31T21:30:24  <gmaxwell> importmulti
805 2017-08-31T21:30:33  <sipa> gmaxwell: the effect of an import is exactly the same as just adding a key
806 2017-08-31T21:30:43  <sipa> gmaxwell: i mean that every key we generate is implicitly 'imported'
807 2017-08-31T21:30:54  <gmaxwell> import doesn't have anything to do with maintaining a keypool.
808 2017-08-31T21:30:55  <gmaxwell> yes, it's that PLUS keypool management.
809 2017-08-31T21:31:01  <luke-jr> time to reboot, bbl
810 2017-08-31T21:31:05  *** luke-jr has quit IRC
811 2017-08-31T21:31:13  <sipa> gmaxwell: i just mean that is what we already doing
812 2017-08-31T21:31:39  <sipa> gmaxwell: saying "switching to a new keypool and treating all the existing keys as imported" is exactly the same as "switching to a new keypool"
813 2017-08-31T21:32:15  <gmaxwell> yes, but it's distinct from following all keypools which is what I was discussing with morcos.
814 2017-08-31T21:32:46  <morcos> gmaxwell: yeah i think if i understand what sipa is saying, once you've made the decision to start giving out addresses on a new chain, you no longer need to maintain a keypool for your old chain
815 2017-08-31T21:32:48  <sipa> ok, s/switching to/adding/g in my above statement
816 2017-08-31T21:33:03  <sipa> still same thing - the 'importing' thing is besides the point
817 2017-08-31T21:33:03  <morcos> youv've already got the current keypool as keys in your wallet, and its exactly as if you imported
818 2017-08-31T21:33:09  <gmaxwell> morcos: right thats an option, but it's not 'backup durable'
819 2017-08-31T21:33:18  <morcos> why not?
820 2017-08-31T21:33:37  <gmaxwell> because you restore a backup then don't do the upgrade or do instantly before scanning all the keys
821 2017-08-31T21:33:50  *** illpadrino has quit IRC
822 2017-08-31T21:34:00  <morcos> hmm.. i see, its just more complicated to get it right i suppose
823 2017-08-31T21:34:07  <gmaxwell> and when we do the upgrade to we trigger a full (pruning incompatible multihour long) rescan
824 2017-08-31T21:34:16  <morcos> but the advantage of supporting 2 keypools is we can start issuing bech32 earlier
825 2017-08-31T21:34:21  <morcos> which seems a big gain
826 2017-08-31T21:34:48  <gmaxwell> Or we could just do dual-embedded and bech32.
827 2017-08-31T21:35:03  <morcos> hmm
828 2017-08-31T21:35:05  <gmaxwell> in which case it's just one keypool and we could use bech32 all the time, but there is a risk of people converting.
829 2017-08-31T21:35:16  <gmaxwell> For rapid bech32 deployment that is best by far.
830 2017-08-31T21:35:31  <morcos> but also means we can't ever easily stop supporting the old style
831 2017-08-31T21:35:36  <gmaxwell> because it lets you immediately use bech32 when you have a counterparty that supports it.
832 2017-08-31T21:35:59  <gmaxwell> morcos: right, we could for newer wallet 3 years from now, except for the risk of 'conversion'
833 2017-08-31T21:36:33  <sipa> just in case that isn't clear: if you currently use addwitnessaddress, you'll accept both p2sh and native-witness outputs to that address
834 2017-08-31T21:37:06  *** RubenSomsen has quit IRC
835 2017-08-31T21:37:07  <morcos> and if you don't you'll accept neither?
836 2017-08-31T21:37:22  <sipa> yes
837 2017-08-31T21:38:27  <morcos> well i do think it makes sense to think about this comprehensively in the context of legacy -> hd -> hd-split -> p2shsegwit -> bech32 -> future witness versions
838 2017-08-31T21:38:38  <morcos> there are different issues for each of those
839 2017-08-31T21:39:12  <morcos> but i think we want the design to be something where people don't get confused understanding how it works
840 2017-08-31T21:41:29  <gmaxwell> we really cannot do legacy and segwit doppleganging due to the uncompressed key issue.
841 2017-08-31T21:41:35  <morcos> Imagine that each of those is considered a different path or whatever, and we introduced some concept of whether a path is active or not (meaning we are still potentially giving out addresses on it)  and once it's not active we don't need to maintain keypools anymore, we just have the historical keys
842 2017-08-31T21:41:44  <sipa> gmaxwell: easy enough with a bit in the metadata
843 2017-08-31T21:41:50  <gmaxwell> I think we can realistically do native + embedded doppleganging and support it forever.
844 2017-08-31T21:41:53  <sipa> or just the addwitness approach
845 2017-08-31T21:42:04  <gmaxwell> bit in the metadata is a backup disaster.
846 2017-08-31T21:42:05  <morcos> When you upgrade you need to specify which ones you are still active on..  And there is a way to deactivate old types
847 2017-08-31T21:42:18  <sipa> gmaxwell: it would also be added during hd topup
848 2017-08-31T21:42:30  <gmaxwell> sipa: I don't understand how that works.
849 2017-08-31T21:42:37  <gmaxwell> I mean where do the bits come from
850 2017-08-31T21:43:01  <sipa> gmaxwell: once your wallet is segwit-enabled, you add it for every newly generated key (including auto topup)
851 2017-08-31T21:43:15  <sipa> it means you can't recover with an old version anymore, but that's inevitable
852 2017-08-31T21:44:25  <gmaxwell> but then you recover an old backup with a new wallet... will it then set the bit for everything
853 2017-08-31T21:44:31  *** Dyaheon has quit IRC
854 2017-08-31T21:44:39  <sipa> ah, i see
855 2017-08-31T21:44:54  <gmaxwell> I'm sorry, I think this is all confused; or I am all confused.  Esp since we don't even really know if we are recovering or not at any point in time.
856 2017-08-31T21:47:31  *** Dyaheon has joined #bitcoin-core-dev
857 2017-08-31T21:48:39  <morcos> gmaxwell: I think when you said "that's a more keypools solution", I took that as a negative, but i'm not sure why it has to be a negative.   Have a keypool for every path / type of address.  Who cares?
858 2017-08-31T21:50:43  <morcos> I don't think it causes any wallet bloat if you're comparing it to importing your keys to a new wallet as you upgrade.  It it causes in-memory bloat, that seems easy enough to optimize away, by leaving most of unlikely to be used keypools on disk.
859 2017-08-31T21:51:38  <gmaxwell> two keypools, technically.  ends up being a megabyte of keypool for each or whatever with our current inefficient storage...
860 2017-08-31T21:53:17  <gmaxwell> (change and not change, is the two pools)
861 2017-08-31T21:53:36  *** Giszmo has quit IRC
862 2017-08-31T21:54:14  *** btcdrak has quit IRC
863 2017-08-31T21:54:15  <morcos> Yes, but don't you get that anyway, if you import to each version in turn as you're importing all the prior keypool keys
864 2017-08-31T21:54:44  <gmaxwell> We could do that.  Also slower accepting blocks, because you now have a lot more keys to scan... but thats something that generally may need to be optimized.
865 2017-08-31T21:55:05  <gmaxwell> morcos: if you do that, but most users eventually will have just started eventually with vXX and won't have any old ones
866 2017-08-31T21:55:32  <morcos> yes, and so then you don't create the old ones
867 2017-08-31T21:55:57  <gmaxwell> so then there is key metadata which says the oldest kind to build, and we build all later ones.
868 2017-08-31T22:00:01  *** c40d9b0743a91f40 has quit IRC
869 2017-08-31T22:17:31  *** meshcollider has quit IRC
870 2017-08-31T22:20:23  *** c40d9b0743a91f40 has joined #bitcoin-core-dev
871 2017-08-31T22:23:17  *** tloriato has joined #bitcoin-core-dev
872 2017-08-31T22:23:17  *** Giszmo has joined #bitcoin-core-dev
873 2017-08-31T22:26:54  <tloriato> Hello. I was testing the development of some ideas using the BitcoinCore wallet and the CLI's commands, and I came across the move command. Unfortunately the Docs states that "move will be removed in a later version of Bitcoin Core. " Does another command fulfils its duty? I've read the documentation on the official webpage and came out with empty hands. I don't want to develop an architecture around a command that will be e
874 2017-08-31T22:28:05  <sipa> tloriato: the whole accounts subsystem is deprecated
875 2017-08-31T22:28:19  <sipa> there won't be a replacement for move, as there would be nothing to observe its effect
876 2017-08-31T22:29:18  <sipa> addresses will be able to have labels, and you'll be able to query for payments to specific labels, but labels don't have their own balance
877 2017-08-31T22:30:31  <tloriato> i see it
878 2017-08-31T22:30:46  <tloriato> well, thanks for the answer and clarification
879 2017-08-31T22:31:30  <tloriato> i'd assume that the parameter to GetNewAddress would be the label instead of account when that happens?
880 2017-08-31T22:31:40  <sipa> indeed
881 2017-08-31T22:32:22  <tloriato> that's alright then! thank you
882 2017-08-31T22:32:28  *** tloriato has quit IRC
883 2017-08-31T22:38:01  *** Giszmo has quit IRC
884 2017-08-31T22:55:56  *** luke-jr has joined #bitcoin-core-dev
885 2017-08-31T23:05:24  *** Giszmo has joined #bitcoin-core-dev
886 2017-08-31T23:07:51  *** JackH has quit IRC
887 2017-08-31T23:15:21  *** JackH has joined #bitcoin-core-dev
888 2017-08-31T23:16:08  *** JackH has quit IRC
889 2017-08-31T23:16:11  *** vicenteH has quit IRC
890 2017-08-31T23:17:09  *** jannes has quit IRC
891 2017-08-31T23:17:14  *** JackH has joined #bitcoin-core-dev
892 2017-08-31T23:25:06  *** Deadhand has quit IRC
893 2017-08-31T23:26:34  *** Cheeseo has quit IRC
894 2017-08-31T23:30:48  *** Deadhand has joined #bitcoin-core-dev
895 2017-08-31T23:45:05  *** Giszmo has quit IRC
896 2017-08-31T23:51:01  *** Dyaheon has quit IRC
897 2017-08-31T23:52:40  *** Dyaheon has joined #bitcoin-core-dev
898 2017-08-31T23:57:30  *** Chris_Stewart_5 has joined #bitcoin-core-dev
899 2017-08-31T23:59:46  *** abpa has quit IRC