1 2019-02-19T00:02:30  *** jarthur has quit IRC
  2 2019-02-19T00:03:27  *** jarthur_ has quit IRC
  3 2019-02-19T00:11:48  *** schmidty has joined #bitcoin-core-dev
  4 2019-02-19T00:16:49  *** schmidty has quit IRC
  5 2019-02-19T00:24:10  *** shesek has joined #bitcoin-core-dev
  6 2019-02-19T00:24:10  *** shesek has joined #bitcoin-core-dev
  7 2019-02-19T00:33:44  *** schmidty has joined #bitcoin-core-dev
  8 2019-02-19T00:33:58  *** kexkey has quit IRC
  9 2019-02-19T00:37:07  *** audvonslack has joined #bitcoin-core-dev
 10 2019-02-19T00:38:33  *** schmidty has quit IRC
 11 2019-02-19T01:20:19  *** zhangzf has joined #bitcoin-core-dev
 12 2019-02-19T01:23:52  *** audvonslack has quit IRC
 13 2019-02-19T01:24:49  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 14 2019-02-19T01:31:26  *** IGHOR has quit IRC
 15 2019-02-19T01:34:35  *** IGHOR has joined #bitcoin-core-dev
 16 2019-02-19T01:36:21  *** Chris_Stewart_5 has quit IRC
 17 2019-02-19T01:46:25  *** schmidty has joined #bitcoin-core-dev
 18 2019-02-19T01:51:18  *** schmidty has quit IRC
 19 2019-02-19T02:06:02  *** schmidty has joined #bitcoin-core-dev
 20 2019-02-19T02:07:20  *** Aaronvan_ has quit IRC
 21 2019-02-19T02:11:03  *** schmidty has quit IRC
 22 2019-02-19T02:14:32  *** schmidty has joined #bitcoin-core-dev
 23 2019-02-19T02:19:04  *** schmidty has quit IRC
 24 2019-02-19T02:22:47  *** m8tion has quit IRC
 25 2019-02-19T02:25:17  <midnightmagic> ˆ/w 3
 26 2019-02-19T02:41:57  <sipa> agree.
 27 2019-02-19T02:43:38  <midnightmagic> :-)
 28 2019-02-19T02:49:47  *** Madars has quit IRC
 29 2019-02-19T03:10:48  *** Madars has joined #bitcoin-core-dev
 30 2019-02-19T03:40:09  *** drexl has quit IRC
 31 2019-02-19T04:03:58  *** dviola has quit IRC
 32 2019-02-19T04:12:46  *** spinza has quit IRC
 33 2019-02-19T04:15:20  *** schmidty has joined #bitcoin-core-dev
 34 2019-02-19T04:17:15  *** kexkey has joined #bitcoin-core-dev
 35 2019-02-19T04:24:04  *** kexkey has quit IRC
 36 2019-02-19T04:41:36  *** skyikot has joined #bitcoin-core-dev
 37 2019-02-19T04:44:55  *** spinza has joined #bitcoin-core-dev
 38 2019-02-19T05:08:48  *** schmidty has quit IRC
 39 2019-02-19T05:15:35  *** ap4lmtree has quit IRC
 40 2019-02-19T06:11:28  *** pinheadmz has quit IRC
 41 2019-02-19T06:13:33  *** pinheadmz has joined #bitcoin-core-dev
 42 2019-02-19T06:26:18  *** Skirmant has quit IRC
 43 2019-02-19T07:05:54  *** schmidty has joined #bitcoin-core-dev
 44 2019-02-19T07:06:22  *** ap4lmtree has joined #bitcoin-core-dev
 45 2019-02-19T07:15:50  *** Skirmant has joined #bitcoin-core-dev
 46 2019-02-19T07:24:19  *** Skirmant has quit IRC
 47 2019-02-19T07:30:01  *** fanquake has joined #bitcoin-core-dev
 48 2019-02-19T07:32:24  *** promag has joined #bitcoin-core-dev
 49 2019-02-19T07:35:55  *** promag has quit IRC
 50 2019-02-19T07:43:29  <provoostenator> promag: regarding create wallet UI, I created a really professional mockup :-) See slide 7-10: https://github.com/Sjors/presentations/blob/master/2019-02-08%20London%20-%20Advancing%20Bitcoin/2019-02%20London%20Advancing%20Bitcoin.pdf
 51 2019-02-19T07:45:22  <provoostenator> Tl&dr it would be nice to have a dialog for wallet creation which check boxes for what we have now, i.e. "watch-only" and "blank", so that we can later expand that.
 52 2019-02-19T07:47:05  <provoostenator> In addition I think the same or a similar dialog can be used to recover wallets. Could be loading a wallet dump file, entering some descriptors or even bip39 phrases.
 53 2019-02-19T07:48:11  <provoostenator> Such a recovery also needs some room, e.g. we would could ask the earliest usage day for rescan purposes. We could even ask if the user knows a few random addresses, so we can guess the derivation paths, but that might be a bit too fancy.
 54 2019-02-19T07:50:14  <provoostenator> For using existing hardware wallets I imagine the HWI scripts will give hints of what derivation paths to use, so the UI doesn't have to. Maybe some devices even know what date they were initialized.
 55 2019-02-19T07:52:13  *** MyNickName6390 has joined #bitcoin-core-dev
 56 2019-02-19T07:53:19  *** MyNickName6390 has quit IRC
 57 2019-02-19T07:53:26  *** schmidty has quit IRC
 58 2019-02-19T07:56:14  *** Guyver2 has joined #bitcoin-core-dev
 59 2019-02-19T08:03:25  *** pinheadmz has quit IRC
 60 2019-02-19T08:50:00  *** bitcoin-git has joined #bitcoin-core-dev
 61 2019-02-19T08:50:00  <bitcoin-git> [bitcoin] AkioNak opened pull request #15439: tests: remove byte.hex() to keep compatibility (master...keep_compatiblity) https://github.com/bitcoin/bitcoin/pull/15439
 62 2019-02-19T08:50:01  *** bitcoin-git has left #bitcoin-core-dev
 63 2019-02-19T09:11:55  *** siom has joined #bitcoin-core-dev
 64 2019-02-19T09:21:50  *** jungly has joined #bitcoin-core-dev
 65 2019-02-19T09:22:50  <wumpus> provoostenator: yes, such a dialog would be nice to have, though probably shouldn't be thrown in the user's face by default (to overwhelm them with choices), more like an 'advanced' wallet creation dialog
 66 2019-02-19T09:24:28  <gmaxwell> A general UI design principle is that if the developer doesn't know, the user also doesn't know. Also if you force the user user to choices they don't understand, they'll frequently set them randomly.  If they want to accomplish something specific, they'll go looking for it, and try using the first thing that sounds like it.
 67 2019-02-19T09:25:47  <wumpus> I mean, it would be for people that do know the functionality and want to choose themselves
 68 2019-02-19T09:27:28  <gmaxwell> absolutely. sorry.
 69 2019-02-19T09:28:00  <gmaxwell> My point is that if your usecase is something where the user will know they want it, it's fine to bury it... just make sure they won't find something else first while looking for it.
 70 2019-02-19T09:29:48  *** promag has joined #bitcoin-core-dev
 71 2019-02-19T09:30:24  <wumpus> I'm also a bit skeptical about, say, the GNOME user interface design where the developer always makes the choices and settings and such are buried deeply in some kind of gconf nightmare tree
 72 2019-02-19T09:31:02  <wumpus> the "all GUI users are idiots" philosophy
 73 2019-02-19T09:31:33  <gmaxwell> oy. "you can edit the code if you are a power user" is not a great UI design principle. :P
 74 2019-02-19T09:31:45  <wumpus> yesss that's what I mean
 75 2019-02-19T09:31:51  <wumpus> even worse :P
 76 2019-02-19T09:31:58  <gmaxwell> (gconf is pretty much that... gconf settings aren't stable across versions... almost as bad as carrying patches)
 77 2019-02-19T09:32:21  <gmaxwell> The user uses the software specifically to avoid writing it and maintaining it themselves. :P
 78 2019-02-19T09:34:03  *** promag has quit IRC
 79 2019-02-19T09:34:04  *** setpill has joined #bitcoin-core-dev
 80 2019-02-19T09:35:12  <gmaxwell> I am just imagining a create dialog with a text entry box where you can enter a seed, and then confused users not realizing they can ignore it, googling bitcoin seed and entering in some example they found online.. :P
 81 2019-02-19T09:37:35  <wumpus> that'd be a good example of terribly unsafe GUI design, yes, meant as useful functionality but it only serves as a trap for the unknowing
 82 2019-02-19T09:38:07  *** timothy has joined #bitcoin-core-dev
 83 2019-02-19T09:43:01  *** rh0nj has quit IRC
 84 2019-02-19T09:44:05  *** promag has joined #bitcoin-core-dev
 85 2019-02-19T09:45:08  *** promag has quit IRC
 86 2019-02-19T09:50:24  *** schmidty has joined #bitcoin-core-dev
 87 2019-02-19T09:50:24  *** promag has joined #bitcoin-core-dev
 88 2019-02-19T10:22:07  *** skyikot has quit IRC
 89 2019-02-19T10:34:53  *** zhangzf has quit IRC
 90 2019-02-19T10:36:27  *** spinza has quit IRC
 91 2019-02-19T10:38:48  *** schmidty has quit IRC
 92 2019-02-19T11:07:13  *** darosior has joined #bitcoin-core-dev
 93 2019-02-19T11:07:41  *** fanquake has quit IRC
 94 2019-02-19T11:08:09  <provoostenator> It helps not to cram too much on a single screen. Instead you can e.g. have a button "Recover an existing wallet" which takes you to another screen which then handles the various options.
 95 2019-02-19T11:08:27  *** fanquake has joined #bitcoin-core-dev
 96 2019-02-19T11:09:36  *** shesek has quit IRC
 97 2019-02-19T11:10:37  *** spinza has joined #bitcoin-core-dev
 98 2019-02-19T11:16:35  *** schmidty has joined #bitcoin-core-dev
 99 2019-02-19T11:21:18  *** schmidty has quit IRC
100 2019-02-19T11:37:30  *** drexl has joined #bitcoin-core-dev
101 2019-02-19T11:39:05  *** promag has quit IRC
102 2019-02-19T11:41:01  *** AaronvanW has joined #bitcoin-core-dev
103 2019-02-19T11:48:08  *** Chris_Stewart_5 has joined #bitcoin-core-dev
104 2019-02-19T11:55:40  *** DougieBot5000_ has joined #bitcoin-core-dev
105 2019-02-19T11:58:23  *** DougieBot5000 has quit IRC
106 2019-02-19T12:04:02  *** Aaronvan_ has joined #bitcoin-core-dev
107 2019-02-19T12:05:23  *** mmgen has joined #bitcoin-core-dev
108 2019-02-19T12:07:14  *** AaronvanW has quit IRC
109 2019-02-19T12:26:21  *** m8tion has joined #bitcoin-core-dev
110 2019-02-19T12:30:24  *** zhangzf has joined #bitcoin-core-dev
111 2019-02-19T12:33:04  *** fanquake has quit IRC
112 2019-02-19T12:45:45  *** mmgen has quit IRC
113 2019-02-19T12:45:56  *** mmgen has joined #bitcoin-core-dev
114 2019-02-19T12:47:35  *** Karyon has joined #bitcoin-core-dev
115 2019-02-19T12:51:36  *** Chris_Stewart_5 has quit IRC
116 2019-02-19T13:02:18  *** justanotheruser has quit IRC
117 2019-02-19T13:05:03  *** Chris_Stewart_5 has joined #bitcoin-core-dev
118 2019-02-19T13:13:56  *** promag has joined #bitcoin-core-dev
119 2019-02-19T13:17:33  *** schmidty has joined #bitcoin-core-dev
120 2019-02-19T13:27:34  *** bitcoin-git has joined #bitcoin-core-dev
121 2019-02-19T13:27:35  <bitcoin-git> [bitcoin] Sjors opened pull request #15441: [doc] build: warn against spaces in working directory (master...2019/02/build_discourage_space) https://github.com/bitcoin/bitcoin/pull/15441
122 2019-02-19T13:27:47  *** bitcoin-git has left #bitcoin-core-dev
123 2019-02-19T13:43:51  *** zhangzf has quit IRC
124 2019-02-19T13:47:38  *** Karyon has quit IRC
125 2019-02-19T13:49:09  *** zhangzf has joined #bitcoin-core-dev
126 2019-02-19T13:53:16  *** Chris_Stewart_5 has quit IRC
127 2019-02-19T13:55:16  *** AaronvanW has joined #bitcoin-core-dev
128 2019-02-19T13:58:04  *** Aaronvan_ has quit IRC
129 2019-02-19T14:02:33  *** sipa has quit IRC
130 2019-02-19T14:09:27  <wumpus> eek, kinda unbelievable that spaces in directory names is still a problem in 2019 :/
131 2019-02-19T14:10:10  <wumpus> this means there's some very unygyenic code somewhere
132 2019-02-19T14:10:26  <wumpus> unhygienic*
133 2019-02-19T14:10:32  *** schmidty has quit IRC
134 2019-02-19T14:12:07  <luke-jr> maybe we need to use it in test dirs in addition to unicode
135 2019-02-19T14:12:32  <wumpus> I'd much prefer that solution to "put a warning in all docs", this really doesn't look good on us
136 2019-02-19T14:14:19  *** sipa has joined #bitcoin-core-dev
137 2019-02-19T14:15:19  *** Karyon has joined #bitcoin-core-dev
138 2019-02-19T14:15:58  *** kexkey has joined #bitcoin-core-dev
139 2019-02-19T14:38:49  *** Guyver2 has quit IRC
140 2019-02-19T14:39:01  *** Guyver2 has joined #bitcoin-core-dev
141 2019-02-19T14:46:11  *** dermoth has quit IRC
142 2019-02-19T14:46:55  *** schmidty has joined #bitcoin-core-dev
143 2019-02-19T14:49:22  *** schmidty has quit IRC
144 2019-02-19T14:49:48  *** Chris_Stewart_5 has joined #bitcoin-core-dev
145 2019-02-19T14:49:58  *** schmidty has joined #bitcoin-core-dev
146 2019-02-19T14:50:59  *** dermoth has joined #bitcoin-core-dev
147 2019-02-19T14:51:43  *** spaced0ut has joined #bitcoin-core-dev
148 2019-02-19T14:54:56  *** schmidty has quit IRC
149 2019-02-19T14:56:47  <promag> why this fails? getdescriptorinfo('pk(xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8)')
150 2019-02-19T14:58:13  <wumpus> what error do you get ?
151 2019-02-19T14:58:19  <promag> Invalid descriptor
152 2019-02-19T14:58:53  <promag> thats straight from doc/descriptors.md
153 2019-02-19T14:59:05  *** jarthur has joined #bitcoin-core-dev
154 2019-02-19T15:01:48  <wumpus> might be it's for the wrong network (regtest/testnet or mainnet)
155 2019-02-19T15:03:18  *** achow101 has quit IRC
156 2019-02-19T15:03:56  <harding> promag: works for me via bitcoin-cli on mainnet using commit 4064d048d6 (master from Sunday).  Rebuilding now to try on latest.
157 2019-02-19T15:04:22  <promag> ok then it's what wumpus said
158 2019-02-19T15:04:53  *** dermoth has quit IRC
159 2019-02-19T15:05:32  <wumpus> might be useful to mention the network that was used for the example, in descriptors.md
160 2019-02-19T15:07:43  *** mildly_risky has joined #bitcoin-core-dev
161 2019-02-19T15:08:27  *** Evel-Knievel has quit IRC
162 2019-02-19T15:09:19  *** Evel-Knievel has joined #bitcoin-core-dev
163 2019-02-19T15:09:40  *** dermoth has joined #bitcoin-core-dev
164 2019-02-19T15:11:53  <instagibbs> GAit, I'd be willing to champion 10823 if you don't have the time
165 2019-02-19T15:15:24  *** achow101 has joined #bitcoin-core-dev
166 2019-02-19T15:16:09  *** ap4lmtree has quit IRC
167 2019-02-19T15:16:50  <sipa> promag: xpub is for mainnet
168 2019-02-19T15:17:37  <provoostenator> Ideally we would have a way for RPC help to spit out correct examples for mainnet, testnet and regtest.
169 2019-02-19T15:17:44  <provoostenator> I've made this mistake a few times too.
170 2019-02-19T15:18:28  *** bitcoin-git has joined #bitcoin-core-dev
171 2019-02-19T15:18:28  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/904308dca3ff...3e4fd4075381
172 2019-02-19T15:18:29  <bitcoin-git> bitcoin/master e3e1a56 Sjors Provoost: [test] functional: set cwd of nodes to tmpdir
173 2019-02-19T15:18:29  <bitcoin-git> bitcoin/master 3e4fd40 MarcoFalke: Merge #15415: [test] functional: allow custom cwd, use tmpdir as default
174 2019-02-19T15:18:34  *** bitcoin-git has left #bitcoin-core-dev
175 2019-02-19T15:19:11  *** bitcoin-git has joined #bitcoin-core-dev
176 2019-02-19T15:19:11  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15415: [test] functional: allow custom cwd, use tmpdir as default (master...2019/02/test_cwd) https://github.com/bitcoin/bitcoin/pull/15415
177 2019-02-19T15:19:13  *** ap4lmtree has joined #bitcoin-core-dev
178 2019-02-19T15:19:23  *** bitcoin-git has left #bitcoin-core-dev
179 2019-02-19T15:19:36  <wumpus> a more specific error might be nice too
180 2019-02-19T15:20:11  *** dermoth has quit IRC
181 2019-02-19T15:20:49  *** darosior has quit IRC
182 2019-02-19T15:20:57  *** dermoth has joined #bitcoin-core-dev
183 2019-02-19T15:23:39  *** dermoth has quit IRC
184 2019-02-19T15:24:07  *** dermoth has joined #bitcoin-core-dev
185 2019-02-19T15:25:24  *** bitcoin-git has joined #bitcoin-core-dev
186 2019-02-19T15:25:25  <bitcoin-git> [bitcoin] promag opened pull request #15443: qa: Add getdescriptorinfo functional test (master...2019-02-qa-feature-descriptor) https://github.com/bitcoin/bitcoin/pull/15443
187 2019-02-19T15:25:38  *** bitcoin-git has left #bitcoin-core-dev
188 2019-02-19T15:28:02  *** dermoth has quit IRC
189 2019-02-19T15:28:27  *** dermoth has joined #bitcoin-core-dev
190 2019-02-19T15:32:54  *** bitcoin-git has joined #bitcoin-core-dev
191 2019-02-19T15:32:55  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3e4fd4075381...38429c4b6228
192 2019-02-19T15:32:55  <bitcoin-git> bitcoin/master 8e4b4f6 Amiti Uttarwar: Address test todos by removing -txindex to nodes.
193 2019-02-19T15:32:56  <bitcoin-git> bitcoin/master 38429c4 Wladimir J. van der Laan: Merge #15404: [test] Remove -txindex to start nodes
194 2019-02-19T15:32:59  *** bitcoin-git has left #bitcoin-core-dev
195 2019-02-19T15:33:24  *** bitcoin-git has joined #bitcoin-core-dev
196 2019-02-19T15:33:25  <bitcoin-git> [bitcoin] laanwj merged pull request #15404: [test] Remove -txindex to start nodes (master...remove_txindex) https://github.com/bitcoin/bitcoin/pull/15404
197 2019-02-19T15:33:31  *** bitcoin-git has left #bitcoin-core-dev
198 2019-02-19T15:36:04  *** skyikot has joined #bitcoin-core-dev
199 2019-02-19T15:41:44  *** riordant has joined #bitcoin-core-dev
200 2019-02-19T15:42:52  *** riordant has left #bitcoin-core-dev
201 2019-02-19T15:42:54  *** riordant has joined #bitcoin-core-dev
202 2019-02-19T15:43:27  <riordant> Hello, I have a question about this commit: https://github.com/bitcoin/bitcoin/commit/d6712db
203 2019-02-19T15:43:48  <riordant> Why was the pid file creation explicitly removed for Windows?
204 2019-02-19T15:44:05  <wumpus> there was never PID file creation for windows
205 2019-02-19T15:44:29  *** ap4lmtree has quit IRC
206 2019-02-19T15:44:35  <wumpus> it requires pid_t type which doesn't exist there
207 2019-02-19T15:44:42  <wumpus> and getpid()
208 2019-02-19T15:45:54  *** kexkey has quit IRC
209 2019-02-19T15:46:12  *** ap4lmtree has joined #bitcoin-core-dev
210 2019-02-19T15:47:25  <wumpus> (if you look at the state before that commit, the CreatePidFile was already in #ifndef WIN32 before that)
211 2019-02-19T15:48:31  <riordant> Ok sure, thanks. How is process identification handled on Windows in that case?
212 2019-02-19T15:49:00  <wumpus> tbh I have no idea, but if you figure that out you could add PID file functionality for windows
213 2019-02-19T15:50:42  *** schmidty has joined #bitcoin-core-dev
214 2019-02-19T15:51:18  <wumpus> fairly sure that windows does have process ids, but the API to figure them out is different
215 2019-02-19T15:55:36  *** setpill has quit IRC
216 2019-02-19T15:58:12  *** shesek has joined #bitcoin-core-dev
217 2019-02-19T15:58:12  *** shesek has joined #bitcoin-core-dev
218 2019-02-19T15:59:28  *** rex4539 has joined #bitcoin-core-dev
219 2019-02-19T16:02:13  *** zhangzf has quit IRC
220 2019-02-19T16:02:33  *** rex4539 has quit IRC
221 2019-02-19T16:04:49  <instagibbs> provoostenator, I don't think it'd be crazy to dynamically generate key-related material for help
222 2019-02-19T16:05:25  <instagibbs> then you just call EncodeDestination() etc
223 2019-02-19T16:05:32  <wumpus> I do think the help should be deterministic, as it's used to generate webpages and such
224 2019-02-19T16:05:40  <instagibbs> It can be
225 2019-02-19T16:05:43  <wumpus> so please no random examples that change every time
226 2019-02-19T16:06:31  <wumpus> yes, I'm not trying to say that you were intending that, but just thought it needed saying just in case :)
227 2019-02-19T16:06:33  <luke-jr> if only rwconf were allowed to modify bitcoin.conf directly, we could have a nice key/value config editor.. https://twitter.com/kakabakasa/status/1097764863168909313
228 2019-02-19T16:06:52  <instagibbs> :) only returns a result if vanitygen returns something starting with `1Example`
229 2019-02-19T16:07:11  <luke-jr> otoh, maybe a key/value editor that changes bitcoin_rw.conf would be sufficient? dunno
230 2019-02-19T16:07:25  <wumpus> well bitcoin_rw.conf overrides bitcoin.conf so...
231 2019-02-19T16:07:37  <wumpus> could be used for exactly the same
232 2019-02-19T16:08:52  <luke-jr> yeah, I guess it would work
233 2019-02-19T16:09:27  <luke-jr> on another note, I wonder if we actually need txindex to require reindex anymore.. now that it's separate, I guess as long as the user hasn't pruned, it could probably be built post-hoc
234 2019-02-19T16:09:47  <wumpus> that would be nice
235 2019-02-19T16:09:55  <luke-jr> (and destroying post-hoc seems trivial)
236 2019-02-19T16:10:01  <wumpus> yes
237 2019-02-19T16:10:35  <wumpus> there's no conceptual reason why making an index requires wiping all indices, this is just how it happens to be right now
238 2019-02-19T16:11:06  *** siom_ has joined #bitcoin-core-dev
239 2019-02-19T16:13:27  *** siom has quit IRC
240 2019-02-19T16:13:36  <luke-jr> I guess -txindex=0 shouldn't destroy an existing index, maybe -txindex=delete
241 2019-02-19T16:14:40  <wumpus> I'm not sure it's worth changing that at this point
242 2019-02-19T16:17:12  <wumpus> in principle, if it wasn't bound to reindex, the action of creating/destroying an transaction could even be an RPC command instead of a command line option
243 2019-02-19T16:17:28  <wumpus> s/an transction/an index/
244 2019-02-19T16:17:39  <luke-jr> oh, someone already did this
245 2019-02-19T16:17:49  <wumpus> oh
246 2019-02-19T16:18:04  *** bitcoin-git has joined #bitcoin-core-dev
247 2019-02-19T16:18:04  <bitcoin-git> [bitcoin] Sjors opened pull request #15444: [docs] Additional productivity tips (master...2019/02/typo-productivity) https://github.com/bitcoin/bitcoin/pull/15444
248 2019-02-19T16:18:05  *** bitcoin-git has left #bitcoin-core-dev
249 2019-02-19T16:19:02  *** kexkey has joined #bitcoin-core-dev
250 2019-02-19T16:29:15  *** mildly_risky has quit IRC
251 2019-02-19T16:33:49  *** promag has quit IRC
252 2019-02-19T16:35:08  *** dviola has joined #bitcoin-core-dev
253 2019-02-19T16:37:55  *** justanotheruser has joined #bitcoin-core-dev
254 2019-02-19T16:39:46  *** schmidty has quit IRC
255 2019-02-19T16:45:04  *** schmidty has joined #bitcoin-core-dev
256 2019-02-19T16:47:27  *** dqx has joined #bitcoin-core-dev
257 2019-02-19T16:50:04  *** schmidty has quit IRC
258 2019-02-19T16:54:35  *** pinheadmz has joined #bitcoin-core-dev
259 2019-02-19T16:57:02  *** justanotheruser has quit IRC
260 2019-02-19T16:57:08  *** rh0nj has joined #bitcoin-core-dev
261 2019-02-19T17:14:24  *** siom_ has quit IRC
262 2019-02-19T17:15:37  *** elichai2 has joined #bitcoin-core-dev
263 2019-02-19T17:16:46  *** schmidty has joined #bitcoin-core-dev
264 2019-02-19T17:21:42  *** schmidty has quit IRC
265 2019-02-19T17:21:47  *** kexkey has quit IRC
266 2019-02-19T17:26:01  *** Lauda has quit IRC
267 2019-02-19T17:28:27  <cjd> What was the reason for aa21a9ed ?   Just some bytes which are unlikely to collide with anything ?
268 2019-02-19T17:28:32  *** owowo has quit IRC
269 2019-02-19T17:29:06  *** Lauda has joined #bitcoin-core-dev
270 2019-02-19T17:33:21  *** skyikot has quit IRC
271 2019-02-19T17:33:55  *** riordant has quit IRC
272 2019-02-19T17:34:44  <provoostenator> cjd: which aa21a9ed?
273 2019-02-19T17:35:02  <cjd> segwit root hash magic
274 2019-02-19T17:35:04  *** copumpkin has quit IRC
275 2019-02-19T17:35:23  <provoostenator> Oh ok, I thought it was a commit that accidentally collided with that :-)
276 2019-02-19T17:38:18  *** Karyon has quit IRC
277 2019-02-19T17:40:16  *** Murch has joined #bitcoin-core-dev
278 2019-02-19T17:40:53  <cjd> oh yeah, without context it can definitely look like a git short hash
279 2019-02-19T17:41:26  *** Chris_Stewart_5 has quit IRC
280 2019-02-19T17:41:48  <provoostenator> sipa says it's random: https://bitcoin.stackexchange.com/questions/59299/why-is-the-bytestring-0xaa21a9ed-used-as-the-witness-commitment-header-in-segwit
281 2019-02-19T17:42:36  <provoostenator> But not how the random thing was chosen :-) But yes it seems to have been to make collision unlikely enough, but blocks not much bigger.
282 2019-02-19T17:43:01  *** schmidty has joined #bitcoin-core-dev
283 2019-02-19T17:44:55  *** jtimon has joined #bitcoin-core-dev
284 2019-02-19T17:47:58  *** schmidty has quit IRC
285 2019-02-19T17:48:09  <cjd> ahh cool
286 2019-02-19T17:48:20  *** hebasto has joined #bitcoin-core-dev
287 2019-02-19T17:51:26  *** Karyon has joined #bitcoin-core-dev
288 2019-02-19T17:56:19  <luke-jr> eh, outputs aren't random. a collision is avoided by just not colliding.
289 2019-02-19T17:56:46  <luke-jr> so long as there's *some* 32 bits there, other proposals just avoid using the same 32-bit value
290 2019-02-19T17:56:47  <provoostenator> luke-jr the 0xaa21a9ed prefix is random
291 2019-02-19T17:56:55  <luke-jr> provoostenator: it doesn't need to be, is my point
292 2019-02-19T17:58:52  <jarthur> I've been meaning to ask about the witness reserved value. BIP 141 seems to indicate that it can be anything, and yet also that it might have future consensus meaning. Is there any way to pick a witness reserved value that won't collide with future soft forks without knowing how those soft forks will use the field?
293 2019-02-19T17:59:23  <sipa> jarthur: just don't use it for anything and you're fine
294 2019-02-19T17:59:44  <jarthur> sipa: but if I'm a miner, what should I set it to in my new blocks?
295 2019-02-19T17:59:48  <sipa> whatever.
296 2019-02-19T18:00:14  <sipa> that comment means that it shouldn't be used to convey any meaning, because that meaning may be constrained in the future
297 2019-02-19T18:00:25  <sipa> just set it to zeroes
298 2019-02-19T18:00:32  <sipa> or to "blahblahblahblah"
299 2019-02-19T18:01:05  <luke-jr> well, if it's constrained in the future, setting it non-zero may make blocks invalid, no?
300 2019-02-19T18:01:06  <provoostenator> Oh, the way I read BIP-141 is that it must be exactly 0xaa21a9ed.
301 2019-02-19T18:01:19  <sipa> provoostenator: jarthur is asking about something unrelated
302 2019-02-19T18:01:20  <luke-jr> provoostenator: the topic changed
303 2019-02-19T18:01:36  <sipa> (witness reserved value vs witness coinbase commitment)
304 2019-02-19T18:03:19  <jarthur> sipa, if we need to constrain its meaning in the future, will we need to look back what what values have been used by miners to make sure there's no collision? Could a miner troll us by incrementing it like a nonce over years to ensure there are less available reserved values for soft-forking purposes?
305 2019-02-19T18:03:29  <sipa> jarthur: no?
306 2019-02-19T18:03:56  <provoostenator> jarthur: I assume a future soft fork won't care about historical values before it was activated
307 2019-02-19T18:03:57  <sipa> the softfork will obviously only affect future values, not ones in the past
308 2019-02-19T18:04:11  <jarthur> OK, great, thanks :)
309 2019-02-19T18:06:12  <luke-jr> well, it'd potentially make the code cleaner after the softfork activates, if we can just have it unconditional
310 2019-02-19T18:06:44  <luke-jr> so it'd be *nice* of miners didn't make blocks with potentially-conflicting values :p
311 2019-02-19T18:07:10  <sipa> sure
312 2019-02-19T18:07:16  <sipa> but if they do, so be it
313 2019-02-19T18:07:25  * luke-jr nods
314 2019-02-19T18:13:46  *** DougieBot5000_ is now known as DougieBot5000
315 2019-02-19T18:36:38  *** Chris_Stewart_5 has joined #bitcoin-core-dev
316 2019-02-19T18:39:21  *** jcorgan has joined #bitcoin-core-dev
317 2019-02-19T18:39:34  *** schmidty has joined #bitcoin-core-dev
318 2019-02-19T18:41:46  *** fabianfabian has joined #bitcoin-core-dev
319 2019-02-19T18:44:07  *** schmidty has quit IRC
320 2019-02-19T19:20:11  *** promag has joined #bitcoin-core-dev
321 2019-02-19T19:24:46  *** promag has quit IRC
322 2019-02-19T19:30:16  *** AaronvanW has quit IRC
323 2019-02-19T19:30:32  *** schmidty has joined #bitcoin-core-dev
324 2019-02-19T19:35:10  *** schmidty has quit IRC
325 2019-02-19T19:37:06  *** bigcookie101 has joined #bitcoin-core-dev
326 2019-02-19T19:38:48  *** owowo has joined #bitcoin-core-dev
327 2019-02-19T19:41:33  *** schmidty has joined #bitcoin-core-dev
328 2019-02-19T19:41:55  *** bigcookie101 has quit IRC
329 2019-02-19T19:42:15  *** bigcookie101 has joined #bitcoin-core-dev
330 2019-02-19T19:43:06  *** bigcookie101 has joined #bitcoin-core-dev
331 2019-02-19T19:43:23  *** mmgen has quit IRC
332 2019-02-19T19:45:49  *** bigcookie101 has quit IRC
333 2019-02-19T19:46:12  *** bigcookie101 has joined #bitcoin-core-dev
334 2019-02-19T19:46:26  *** schmidty has quit IRC
335 2019-02-19T19:56:42  *** bigcookie101 has quit IRC
336 2019-02-19T19:57:04  *** bigcookie101 has joined #bitcoin-core-dev
337 2019-02-19T19:58:13  *** jarthur_ has joined #bitcoin-core-dev
338 2019-02-19T20:01:36  *** jarthur has quit IRC
339 2019-02-19T20:07:40  *** owowo has quit IRC
340 2019-02-19T20:12:54  *** owowo has joined #bitcoin-core-dev
341 2019-02-19T20:15:55  *** jarthur_ is now known as jarthur
342 2019-02-19T20:16:05  *** riordant has joined #bitcoin-core-dev
343 2019-02-19T20:16:48  *** bigcookie101 has quit IRC
344 2019-02-19T20:17:15  *** bigcookie101 has joined #bitcoin-core-dev
345 2019-02-19T20:20:48  *** bigcookie101 has quit IRC
346 2019-02-19T20:23:24  *** bigcookie101 has joined #bitcoin-core-dev
347 2019-02-19T20:30:01  *** jarthur has quit IRC
348 2019-02-19T20:30:49  *** Karyon has quit IRC
349 2019-02-19T20:32:08  *** promag has joined #bitcoin-core-dev
350 2019-02-19T20:34:35  *** EagleTM has joined #bitcoin-core-dev
351 2019-02-19T20:37:39  *** bitcoin-git has joined #bitcoin-core-dev
352 2019-02-19T20:37:39  <bitcoin-git> [bitcoin] hebasto opened pull request #15445: [0.17] backport #14409 (0.17...20190219-backport-pr14409) https://github.com/bitcoin/bitcoin/pull/15445
353 2019-02-19T20:37:52  *** bitcoin-git has left #bitcoin-core-dev
354 2019-02-19T20:39:06  *** promag has quit IRC
355 2019-02-19T20:42:25  *** schmidty has joined #bitcoin-core-dev
356 2019-02-19T20:43:21  *** shesek has quit IRC
357 2019-02-19T20:46:41  *** sdaftuar has quit IRC
358 2019-02-19T20:46:41  *** sdaftuar has joined #bitcoin-core-dev
359 2019-02-19T20:55:39  *** DeanWeen has quit IRC
360 2019-02-19T20:58:44  *** AaronvanW has joined #bitcoin-core-dev
361 2019-02-19T21:02:23  *** bitcoin-git has joined #bitcoin-core-dev
362 2019-02-19T21:02:24  <bitcoin-git> [bitcoin] dongcarl opened pull request #15446: Improve depends debuggability (master...2019-02-improve-depends-debuggability) https://github.com/bitcoin/bitcoin/pull/15446
363 2019-02-19T21:02:26  *** bitcoin-git has left #bitcoin-core-dev
364 2019-02-19T21:02:39  *** dviola has quit IRC
365 2019-02-19T21:04:03  <luke-jr> jl2012: I don't understand your last email. My point is, if you don't want NOINPUT, it should be sufficient to just not sign with NOINPUT..
366 2019-02-19T21:05:22  *** hebasto has quit IRC
367 2019-02-19T21:09:32  *** Guyver2 has quit IRC
368 2019-02-19T21:09:48  <gmaxwell> luke-jr: unfortunately no. If noinput can show up anywhere, then if you cannot _guarentee_ that you'll never pay to an address twice (e.g. splitting a payment in two in order to pay from both a hot and cold wallet) then you can only pay to 1xxx addresses.  Otherwise you risk paying, having the payee noinput spend, and then having funds get lost.  Then they get embroiled in some stupid lawsuit
369 2019-02-19T21:09:48  <gmaxwell> overwhos fault it was.   That kind of footgun isn't what you expect from bitcoin engineering, it sounds like something ethereum would do.
370 2019-02-19T21:10:44  <gmaxwell> (also are you responding to messages that aren't on the list? -- I don't see any really recent message from jl2012)
371 2019-02-19T21:12:05  <luke-jr> gmaxwell: I guess the list copies are waiting for moderation
372 2019-02-19T21:12:40  <luke-jr> sending twice to the same address is always the sender's fault and should be considered undefined behaviour
373 2019-02-19T21:13:00  <gmaxwell> personally I prefer noinput be dropped from the proposal for now-- it's basically caused months of delays now at this point. And the initial schnorr support already doesn't support aggregation or graftroot, so we know there needs to be a subsiquent version regardless.
374 2019-02-19T21:14:04  <gmaxwell> luke-jr: Perhaps, but thats not relevant.  It is bad engineering to make a small (and fundimentally very hard to avoid mistake) into a reckless one.  Look at all the extreme money losing things that we've mocked in eth land, almost all of them also involved mistakes on the user's part.
375 2019-02-19T21:14:16  <gmaxwell> Good engineering isn't just building something that works if you use it perfectly.
376 2019-02-19T21:14:24  <luke-jr> gmaxwell: it's already reckless. there's no guarantee it works today.
377 2019-02-19T21:14:29  <gmaxwell> It's also about building something that fails gracefully.
378 2019-02-19T21:15:58  <luke-jr> IMO it's not much different from accidentally sending with the wrong fee
379 2019-02-19T21:16:22  <luke-jr> these are things user applications can try to protect, but not things the protocol should be trying to second-guess
380 2019-02-19T21:16:35  <gmaxwell> and we worked hard to make that less possible, e.g. segwit inputs sign the input amounts now.
381 2019-02-19T21:17:09  <gmaxwell> luke-jr: and reuse is fundimentally hard to guarentee never happens, you essentially need a consensus system to do so.
382 2019-02-19T21:17:22  *** morcos has quit IRC
383 2019-02-19T21:17:52  <luke-jr> you could avoid wrong fee without signing input amounts - the benefit there was to avoid the extra data needed for it
384 2019-02-19T21:18:20  <luke-jr> a person can easily avoid sending to the same address twice, and since addresses aren't meant to be reused, no more than one person should ever be on the sender side
385 2019-02-19T21:18:24  *** skyikot has joined #bitcoin-core-dev
386 2019-02-19T21:18:37  <luke-jr> you don't need a consensus system to coordinate a single sender's actions
387 2019-02-19T21:19:09  <luke-jr> (and if someone sees the address on the network and sends to it too - there are obvious ways to deal with that)
388 2019-02-19T21:19:27  <gmaxwell> People do accidentally double pay, today. It happens, it's not conjecture.  People also do intentionally split one payment into two txouts.
389 2019-02-19T21:19:45  <gmaxwell> "obvious ways to deal with that" is handwaving.
390 2019-02-19T21:20:29  <luke-jr> you just display only the higher value one as confirmed; or spend them all together and ignore future outputs to that key; etc
391 2019-02-19T21:20:48  <harding> luke-jr: let's say you design a wallet to always sign noinput, as you've proposed.  Alice sends a large payment to Bob with a low fee, accepting that it'll take several days to confirm.  Griefer Mallory sees that tx in the mempool and sends a tiny payment with a high fee to the same address.  Your wallet receives Mallory's payment and happens to respend it with noinput before Alice's payment confirms.  Now Alice's payment can be
392 2019-02-19T21:20:48  <harding> stolen even though Alice herself didn't engage in address reuse.
393 2019-02-19T21:21:29  <gmaxwell> If you've even seen the 'higher one' yet.  (so your 'obvious way' requires as a starting premise that wallets ignore all unconfirmed transactions, and arguable all non-deeply confirmed transactions, since there still could be a reorg)
394 2019-02-19T21:21:29  <luke-jr> harding: you're assuming Bob is offline at the time and doesn't see Alice's until after spending Griefer's?
395 2019-02-19T21:21:56  <harding> luke-jr: we can't guarantee Bob has a complete view of all possible mempools in any case.
396 2019-02-19T21:22:12  <luke-jr> gmaxwell: I don't see why you say ignoring unconfirmed; just not showing them as confirmed, since they aren't
397 2019-02-19T21:22:43  <gmaxwell> because if you spend the wrong one you'll burn money. not showing them as confirmed isn't enough.
398 2019-02-19T21:22:45  <luke-jr> harding: okay, I see how that can be a concern; but it's one easily addressed by just not implementing a wallet using NOINPUT that way
399 2019-02-19T21:23:00  *** booyah_ is now known as booyah
400 2019-02-19T21:23:12  <luke-jr> arguably if you do so anyway, it's the same as picking the wrong fee would be
401 2019-02-19T21:23:14  <gmaxwell> (to be clear, I want to have the functionality eventually, but it clearly has risky implications and has now added months of delay to an otherwise mostly complete proposal)
402 2019-02-19T21:23:53  <gmaxwell> (which was exactly the reason that graftroot and aggregation were left out)
403 2019-02-19T21:24:33  <luke-jr> harding: (also, actually, since the value in signed, I think I can argue your threat model is not a real issue, but that's beside the main point: that these limits shouldn't be at the protocol level)
404 2019-02-19T21:25:09  <luke-jr> is signed*
405 2019-02-19T21:25:41  <gmaxwell> value being signed is just one of the first protections that were added to make this not a complete disaster proposal...
406 2019-02-19T21:25:43  <luke-jr> (because even if Griefer's UTXO is the one that gets seen/spent first, it still paid the correct amount to the address given to Alice, so it doesn't actually matter if Alice's UTXO gets lost)
407 2019-02-19T21:26:34  <gmaxwell> unfortunately there are still a lot of really easy loss vectors even with that mitigation. Months have now been spent trying to cook up better mitigations.
408 2019-02-19T21:26:43  *** schmidty has quit IRC
409 2019-02-19T21:27:19  <luke-jr> gmaxwell: but my point is that for a protocol level feature, just saying "don't do that" is a reasonable mitigation
410 2019-02-19T21:27:39  <luke-jr> these things can/should be addressed by the wallet software
411 2019-02-19T21:31:23  *** lucky8277 has joined #bitcoin-core-dev
412 2019-02-19T21:31:40  *** elichai2 has quit IRC
413 2019-02-19T21:33:02  *** AaronvanW has quit IRC
414 2019-02-19T21:34:55  *** lucky8277 has quit IRC
415 2019-02-19T21:50:10  *** Murch has quit IRC
416 2019-02-19T21:51:12  *** Murch has joined #bitcoin-core-dev
417 2019-02-19T21:52:03  *** TheRec has quit IRC
418 2019-02-19T22:01:56  *** cornfeedhobo has quit IRC
419 2019-02-19T22:02:26  *** AaronvanW has joined #bitcoin-core-dev
420 2019-02-19T22:07:32  *** AaronvanW has quit IRC
421 2019-02-19T22:09:30  *** TheRec has joined #bitcoin-core-dev
422 2019-02-19T22:09:30  *** TheRec has joined #bitcoin-core-dev
423 2019-02-19T22:12:17  *** cornfeedhobo has joined #bitcoin-core-dev
424 2019-02-19T22:16:01  *** ap4lmtree has quit IRC
425 2019-02-19T22:17:56  *** fabianfabian has quit IRC
426 2019-02-19T22:18:06  *** Chris_Stewart_5 has quit IRC
427 2019-02-19T22:21:49  *** spinza has quit IRC
428 2019-02-19T22:26:03  *** Murch has quit IRC
429 2019-02-19T22:27:43  *** spinza has joined #bitcoin-core-dev
430 2019-02-19T22:28:12  *** bigcookie101 has quit IRC
431 2019-02-19T22:29:07  <gmaxwell> luke-jr: thats like saying ECDSA as it originally was because "use a strong random number and don't repeat it" is a reasonable mitigation.
432 2019-02-19T22:29:19  *** Murch has joined #bitcoin-core-dev
433 2019-02-19T22:29:20  <gmaxwell> In reality that approach causes failure after failure after failure.
434 2019-02-19T22:29:56  <gmaxwell> At some point the designer of a system cannot credibly fob off fault onto the users.
435 2019-02-19T22:30:24  <gmaxwell> We build systems to be used by real people, not platonic errorless perfectly knowledgable people.
436 2019-02-19T22:31:14  <gmaxwell> We do know how to make noinput safer but it has been slowing down the work on this functionality.
437 2019-02-19T22:31:54  <gmaxwell> We already set aside graftroot and aggregation, both of which are significanly more valuable than no input, in the interest of focus and time.
438 2019-02-19T22:33:37  <sipa> the argument why it was included in the first place also disappears if we're aimimg for output tagging (because doing it separately would inherently require a "tag" as in a separate witness version)
439 2019-02-19T22:34:41  <luke-jr> gmaxwell: yet we don't try to enforce random number strength in the consensus protocol
440 2019-02-19T22:34:56  *** spinza has quit IRC
441 2019-02-19T22:35:57  <sipa> luke-jr: can we?
442 2019-02-19T22:36:06  <gmaxwell> luke-jr: we would if we could but we can't so we don't.
443 2019-02-19T22:36:11  <luke-jr> sipa: you would know better than me, but not that I'm aware of
444 2019-02-19T22:36:37  <gmaxwell> But bip schnorr proscibes a secure procedure-- which can be easily followed, it doesn't just say "this has to be random, good luck!"
445 2019-02-19T22:36:53  <luke-jr> gmaxwell: why don't we enforce the absurd fee policy as a consensus rule?
446 2019-02-19T22:37:03  <booyah> uhm is this not typical for crypto protocols to start with "we assume you can provide good, unique, randomness"?
447 2019-02-19T22:37:12  <gmaxwell> luke-jr: because it has to change over time, otherwise I would say we probably should.
448 2019-02-19T22:37:52  <gmaxwell> booyah: For an academic analysis, sure. For a pratical engineered system for people to actually use-- only incompetent ones that cause misery to their users.
449 2019-02-19T22:37:55  <booyah> and as separate consideration we could provide algorithms to try to improve on OS-provided random
450 2019-02-19T22:38:28  <gmaxwell> you won't find any crypto apps that just prompts there user to proide randomness or some such stupid thing. :)
451 2019-02-19T22:38:33  <booyah> is bitcoin somehow improving strength of normal random as provided by OS specific api?
452 2019-02-19T22:38:42  <gmaxwell> (or to the extent that they do, like brainwallets tools, they cause continual failure)
453 2019-02-19T22:38:51  <gmaxwell> booyah: yes, though you're offtopic.
454 2019-02-19T22:38:52  <booyah> gmaxwell: well not user, I mean the OS random source
455 2019-02-19T22:39:45  <gmaxwell> booyah: bip-schnorr doesn't need any randomness for signing at all.  (nor does our ecdsa implementation... but clasical by the book ECDSA does, and as a result is an ocean of failure)
456 2019-02-19T22:40:02  <luke-jr> there are lots of easy ways to make mistakes that we can't prevent. I don't see why preventing a few unusual cases by limiting functionality is a good idea.
457 2019-02-19T22:40:50  <gmaxwell> Whats being limited? there is no way to noinput today. The system was designed otherwise, and having it really throughly breaks assumptions.
458 2019-02-19T22:40:51  <luke-jr> in this case, going out of the way to prevent me from using NOINPUT the way I intend to
459 2019-02-19T22:41:05  <gmaxwell> oh so sad poor luke
460 2019-02-19T22:41:49  * booyah quietly pulls out a violin
461 2019-02-19T22:43:27  <sipa> luke-jr: what do you hope to gain from using noinput as you intend to?
462 2019-02-19T22:44:08  *** spinza has joined #bitcoin-core-dev
463 2019-02-19T22:44:46  <luke-jr> sipa: eg, keeping txids for later spends (of unconfirmed change) the same even if the transaction producing the change needs a fee bump; without keeping an exponential number of signed transactions prepared
464 2019-02-19T22:46:22  <gmaxwell> that only works right if all subsiquent transactions are themselves no-input.
465 2019-02-19T22:46:41  <gmaxwell> so a katamari of replay attack vulnerablity. :)
466 2019-02-19T22:46:43  <luke-jr> which they would be in such a wallet where everything is noinput
467 2019-02-19T22:46:55  <gmaxwell> luke-jr: not the recipents spends.
468 2019-02-19T22:47:53  <luke-jr> the recipient of the fee-bumped one would be affected, but nothing else?
469 2019-02-19T22:48:32  <luke-jr> or, what do you mean?
470 2019-02-19T22:48:32  <gmaxwell> the whole chain is invalidated unless all txn in it use noinput for all of their inputs.
471 2019-02-19T22:48:49  <luke-jr> but the recipients aren't in the chain of change
472 2019-02-19T22:50:44  <gmaxwell> they get the payments, not the change itself. (obviously thats why you have change: you made payments)
473 2019-02-19T22:51:03  <luke-jr> but that doesn't break the chain of change
474 2019-02-19T22:51:20  <luke-jr> the next transaction would have an unchanged txid
475 2019-02-19T22:52:18  <luke-jr> (also, unrelated to a mere simple wallet: what if you want someone paying you, to send directly into a smart contract that relies on NOINPUT?)
476 2019-02-19T22:52:38  *** AaronvanW has joined #bitcoin-core-dev
477 2019-02-19T22:53:04  <gmaxwell> luke-jr: no input doesn't keep the inputs out of the txids.  so if you pay1->pay2->pay3->pay4  all with no input and alter pay2 the txids of all the subsiquent txn (pay3/pay4/ and all their children) change too.
478 2019-02-19T22:53:10  *** jarthur has joined #bitcoin-core-dev
479 2019-02-19T22:53:36  <luke-jr> hmm, right
480 2019-02-19T22:55:07  <luke-jr> that only messes up the recipients not using noinput wallets, though
481 2019-02-19T22:55:39  <gmaxwell> 14:46:41 < gmaxwell> so a katamari of replay attack vulnerablity. :)
482 2019-02-19T22:56:12  <luke-jr> another use case: if the person paying me does some fee bumping, using noinput avoids resigning
483 2019-02-19T22:56:26  <gmaxwell> Ethereum has better replay prevention than no input, and still replay there has caused massive funds loss, annoying DOS, etc.
484 2019-02-19T22:56:48  <luke-jr> but in this case, replay isn't a problem since addresses aren't reused
485 2019-02-19T22:57:00  <gmaxwell> basically noinput = accounts model, instead of utxo model; with the tradeoffs that implies.
486 2019-02-19T22:57:12  <luke-jr> or unique-script UTXO model
487 2019-02-19T22:58:48  <gmaxwell> one coulde use ethereum accounts exactly once. but because the system doesn't guarentee it, you can't count on it.
488 2019-02-19T22:59:31  <luke-jr> since NOINPUT still commits to the amount, it's basically harmless to count on it
489 2019-02-19T23:01:01  <gmaxwell> that kind of thinking is why it is so unsafe.
490 2019-02-19T23:01:05  <gmaxwell> So thanks for making the point.
491 2019-02-19T23:02:13  <luke-jr> am I wrong?
492 2019-02-19T23:02:30  *** unknown-os has joined #bitcoin-core-dev
493 2019-02-19T23:03:06  *** timothy has quit IRC
494 2019-02-19T23:03:26  *** DeanGuss has joined #bitcoin-core-dev
495 2019-02-19T23:03:34  *** unknown-os has left #bitcoin-core-dev
496 2019-02-19T23:04:23  <gmaxwell> Yes. So for example, the not that uncommon pattern of splitting a payment in half to pay from two different wallets. wham 50% funds loss.
497 2019-02-19T23:04:56  <gmaxwell> that isn't even 'reuse' thats just two outputs at effectively the same time.  That has never before been a problem in the system, so it's a new footgun behavior that arises out of nowhere.
498 2019-02-19T23:05:48  <luke-jr> that's reuse and undefined behaviour..
499 2019-02-19T23:06:01  <gmaxwell> according to _you_.
500 2019-02-19T23:06:09  <gmaxwell> Not according to how bitcoin has always worked.
501 2019-02-19T23:06:21  <gmaxwell> And certantly not according to what people already do.
502 2019-02-19T23:06:40  <gmaxwell> Advisable or not, reuse is ubiquitous. The majority of circulating bitcoins are stored in reused addresses.
503 2019-02-19T23:06:52  *** justanotheruser has joined #bitcoin-core-dev
504 2019-02-19T23:07:13  <gmaxwell> You are saying that it's just fine to turn something that people ubiquitously do today into a massive footgun.
505 2019-02-19T23:07:20  <gmaxwell> I can't abide by that.
506 2019-02-19T23:07:42  <luke-jr> it's already a footgun.
507 2019-02-19T23:07:58  <gmaxwell> Worse, instead of saying "yes, I know its dangerous and it will cause funds loss, it's worth it" -- instead you argue that it's "basically harmless".
508 2019-02-19T23:08:04  <luke-jr> nothing obliges the recipient to acknowledge the second payment to the same address
509 2019-02-19T23:08:46  <gmaxwell> Although its theoretically possible, I am aware of _no_ instance where funds have been loss due to a near term reuse.  (like sending again on the same day)
510 2019-02-19T23:09:22  <luke-jr> that's like when people say light wallets are okay because nobody's ever lost funds due to their lack of security
511 2019-02-19T23:09:25  <booyah> are you talking about two people sending e.g. 1 btc, on same day, to same one e.g. donation address of someone?
512 2019-02-19T23:10:11  *** schmidty has joined #bitcoin-core-dev
513 2019-02-19T23:10:23  <gmaxwell> luke-jr: I am not saying that reuse is good. It's inadvisable in most cases.  But there is a big difference between something being inadvisable and rigging it to explode.
514 2019-02-19T23:11:14  <luke-jr> gmaxwell: I've seen it very nearly explode at least once personally.
515 2019-02-19T23:11:19  <luke-jr> without NOINPUT
516 2019-02-19T23:12:09  <gmaxwell> luke-jr: you've had years where you could have also written wallet features in bitcoin core to do stuff like pop up a message saying "You're paying to an address you've paid to before. Is this a mistake? Address reuse can be a symptom of a mistaken double payment and can lead to privacy or funds loss".   but apparently it wasn't important enough to you to bother.
517 2019-02-19T23:12:55  <gmaxwell> But now it's important enough to you that you think it's no concern to adjust the consensus rules so that behavior will actually lead to funds loss, and not just a fringe risk.
518 2019-02-19T23:13:18  *** schmidty has quit IRC
519 2019-02-19T23:13:32  <gmaxwell> (or likewise, inbound payments that reused your addresses could get frowny red recycle icons)
520 2019-02-19T23:15:13  <booyah> I guess, if it is that Alice twice pays to same address of Bob, then it might be impossible to detect in some cases, especially if due to crash and recover from backup she lost local information that she is sending to Bob, and if when she restored then first transaction is in someone's mempool but not yet in block and not visible to it(?)
521 2019-02-19T23:15:26  <gmaxwell> indeed.
522 2019-02-19T23:15:47  <aj> luke-jr: noinput sigs sign the amount, so if you feebump the change will be a different value and the noinput sig spending that change will be invalid
523 2019-02-19T23:15:54  <luke-jr> booyah: that's not a new problem with noinput
524 2019-02-19T23:16:09  <gmaxwell> luke-jr: but it does invalidate the case you gave for it.
525 2019-02-19T23:16:44  <gmaxwell> booyah: it's difficult to guarentee that a double payment _never_ happen even if you're trying.
526 2019-02-19T23:17:09  <gmaxwell> booyah: and in bitcoin today users generally assume addresses can be reused. It's not a great assumption.
527 2019-02-19T23:17:19  <booyah> I guess instant backups, kind of like watchtowers in a way, could help, where you commit to them first, and on restart of client it queries them to make sure
528 2019-02-19T23:17:27  <gmaxwell> They also assume you can go pull an address out of a block explorer and pay to it.
529 2019-02-19T23:17:51  <gmaxwell> booyah: right, with enough protection and complexity you can make it arbritarily rare.
530 2019-02-19T23:17:52  <luke-jr> gmaxwell: maybe there's too much focus on a specific use case? are you really saying that there is no situation where it would be useful to receive a payment directly into a multi-transaction smart contract that needs noinput?
531 2019-02-19T23:18:36  <gmaxwell> It's not clear to me that it would, at least the lightning stuff proposed can't work that way.
532 2019-02-19T23:18:55  <gmaxwell> But even if it is useful, that utility has to be weighed against the risk increase for all other usage.
533 2019-02-19T23:19:08  <luke-jr> the only reason you can't have someone pay directly into a Lightning channel in such a manner, is because of non-segwit inputs, right?
534 2019-02-19T23:19:30  <gmaxwell> luke-jr: no, because they have to be able to resign if the transaction fails (even with no-input)
535 2019-02-19T23:20:15  <gmaxwell> (also, if it became justified to do that, it could be done later... along with whatever was needed to make it safer)
536 2019-02-19T23:20:30  <luke-jr> gmaxwell: I'm probably not going to object to a neutered noinput being softforked, but I predict in some years we will learn it was a mistake and desire to change it
537 2019-02-19T23:21:04  <sipa> that's ok
538 2019-02-19T23:21:11  <luke-jr> (and since we *can* change it in a later softfork, I suppose it isn't worth trying to brainstorm all the possible ideas today; and as you point out, there are things we can do in the meantime to prepare for that being safer by then)
539 2019-02-19T23:21:11  <sipa> we can learn from experience
540 2019-02-19T23:21:49  <gmaxwell> luke-jr: as I was pointing out before, we already know the initial v1 segwit script will be not a forever thing.
541 2019-02-19T23:21:57  <gmaxwell> We've already dropped headline features from it.
542 2019-02-19T23:22:11  <gmaxwell> including the major source of public hype for it (aggregation).
543 2019-02-19T23:22:42  <luke-jr> yes, admittedly those are bigger unfortunate-delays
544 2019-02-19T23:23:08  <gmaxwell> my argument isn't that it's terrible and should never be done, only that there is too much risk that it's terrible and shouldn't be done, and not enough time yet given into how it could best be derisked... and it sould be seperated because it can be seperated.
545 2019-02-19T23:23:34  <gmaxwell> it's certantly a lot easier to add it later than to deal with the consequence of adding it and wish we could take it back.
546 2019-02-19T23:23:51  <gmaxwell> e.g. if its added, it can never be removed without risk of confsciating funds.
547 2019-02-19T23:24:05  <luke-jr> that's a good point
548 2019-02-19T23:25:09  <gmaxwell> (I mean it could be added with warnings that its provisional and you shouldn't setup things so that you'll lose funds if its turned off... but thats a footgun. which is better avoided)
549 2019-02-19T23:25:36  <gmaxwell> and the main usecase for it is lightning stuff that ... has a lot of other development work to do anyways.
550 2019-02-19T23:25:41  <luke-jr> I suppose in theory, a new address format could always also be added later to set the tx version or whatever without another softfork
551 2019-02-19T23:26:43  <luke-jr> although that runs the risk of getting current addresses labelled "reusable"
552 2019-02-19T23:26:49  <gmaxwell> luke-jr: Right, at least my preference at the moment is that it just get a different segwit script version so that you know what you're dealing with.
553 2019-02-19T23:27:44  <luke-jr> well, another script ver number wouldn't be obviously distinguishable in Bech32, would it?
554 2019-02-19T23:28:02  <gmaxwell> luke-jr: considering that they're already reused by most users (including you, fwiw https://www.blockchain.com/btc/address/134dV6U7gQ6wCFbfHUz2CMh6Dth72oGpgH ) the horse is kind of out of the barn on that.
555 2019-02-19T23:28:13  <gmaxwell> luke-jr: it would be a different third character.
556 2019-02-19T23:28:22  <gmaxwell> er forth.
557 2019-02-19T23:28:30  <sipa> fourth.
558 2019-02-19T23:28:32  <luke-jr> I suspect most users wouldn't notice that, and it might not accomplish the intended goal
559 2019-02-19T23:28:36  <gmaxwell> the fourth character is the version number.
560 2019-02-19T23:28:45  <gmaxwell> luke-jr: no but their software could.
561 2019-02-19T23:30:04  <luke-jr> existing software doesn't; but since I don't really agree with the intended goal, I'm not going to argue too hard that the mechanism here is insufficient ;)
562 2019-02-19T23:31:43  *** schmidty has joined #bitcoin-core-dev
563 2019-02-19T23:33:34  *** tripleslash has quit IRC
564 2019-02-19T23:35:53  *** schmidty has quit IRC
565 2019-02-19T23:45:09  *** palfun has quit IRC
566 2019-02-19T23:49:38  *** captjakk has joined #bitcoin-core-dev
567 2019-02-19T23:55:38  *** riordant has quit IRC