1 2019-02-13T00:05:10  <moneyball> does anyone know how to find all open PRs that modify a particular file (ie validation.cpp)?
  2 2019-02-13T00:06:17  <pinheadmz> github you can view history of a single file
  3 2019-02-13T00:06:21  <pinheadmz> or check the "blame"
  4 2019-02-13T00:10:28  *** DeanGuss has joined #bitcoin-core-dev
  5 2019-02-13T00:32:46  *** booyah_ has quit IRC
  6 2019-02-13T00:33:41  *** rhavar_ has joined #bitcoin-core-dev
  7 2019-02-13T00:33:44  *** booyah_ has joined #bitcoin-core-dev
  8 2019-02-13T00:34:03  *** rhavar_ has quit IRC
  9 2019-02-13T00:34:22  *** rhavar_ has joined #bitcoin-core-dev
 10 2019-02-13T00:35:09  *** rhavar_ has quit IRC
 11 2019-02-13T00:35:42  *** jarthur has quit IRC
 12 2019-02-13T00:36:07  *** rhavar has joined #bitcoin-core-dev
 13 2019-02-13T00:38:48  *** booyah_ has quit IRC
 14 2019-02-13T00:39:34  *** booyah_ has joined #bitcoin-core-dev
 15 2019-02-13T00:39:37  *** DeanGuss has quit IRC
 16 2019-02-13T00:42:53  <moneyball> pinheadmz thanks but that only shows history/merged PRs and not open PRs, right?
 17 2019-02-13T00:44:41  <booyah_> why bitcoin uses ECDSA on secp256k1 instead of Ed25519, any arguments for/against?
 18 2019-02-13T00:47:41  *** Karyon has quit IRC
 19 2019-02-13T00:48:16  <sipa> booyah_: ask satoshi
 20 2019-02-13T00:49:55  <sipa> as for why it hasn't changed since: they're similar in performance, changing is hard, ed25519's cofactors are annoying to build more complex constructions on
 21 2019-02-13T00:50:11  <sipa> (and probably more on topic in #bitcoin-wizards)
 22 2019-02-13T00:53:31  <booyah_> sipa: ok then implementation question, secp256k1 support is home-made and probably will remain so, as opposed to eg using a general library like nacl/sodium?
 23 2019-02-13T00:54:02  <sipa> i don't see good reasons to change it
 24 2019-02-13T00:54:14  <MarcoFalke> moneyball: could be an idea for bitcoinacks by pierre_rochard
 25 2019-02-13T00:54:34  <sipa> booyah_: it would be slower, introduce new review burden, and any change of that kind is risky
 26 2019-02-13T00:54:41  <gmaxwell> ed25519 is unambigiously less secure too, though not in an amount that would matter.
 27 2019-02-13T00:55:03  <sipa> by about 1-1.5 bits or so, yeah
 28 2019-02-13T00:55:40  <gmaxwell> and re cofactor, several cryptocurrencies have had serious vulnerabilities due to using ed25519.
 29 2019-02-13T00:56:09  <gmaxwell> E.g. monero/cryptonote/etc. had an unbounded inflation bug due to cofactor handling.
 30 2019-02-13T00:58:11  <gmaxwell> basically, the ed25519 stuff in general is okay, it makes its own tradeoffs, but it extremely overhyped with a lot of misleading marketing.
 31 2019-02-13T00:58:28  <sipa> https://twitter.com/hdevalence/status/1093684731500146688
 32 2019-02-13T00:59:18  <booyah_> gmaxwell: which attack works on ed25519 but not on secp?
 33 2019-02-13T00:59:59  <sipa> booyah_: i would hope none!
 34 2019-02-13T01:00:12  <sipa> it's just harder to get complex protocols on top right
 35 2019-02-13T01:00:46  <gmaxwell> booyah_: cofactor attacks, as I mentioned.
 36 2019-02-13T01:00:48  <sipa> ed25519 is a digital signature system, and when used as just that - it's perfectly fine
 37 2019-02-13T01:01:39  <sipa> but something like bip32 is already somewhat harder to do for ed25519
 38 2019-02-13T01:02:37  <gmaxwell> and ... has been done wrong multiple times.
 39 2019-02-13T01:05:04  *** booyah_ is now known as booyah
 40 2019-02-13T01:12:11  *** Karyon has joined #bitcoin-core-dev
 41 2019-02-13T01:15:26  *** pinheadmz has quit IRC
 42 2019-02-13T01:17:49  <echeveria> people generally misunderstand that ed25519 is not a single show signature, due to the marketing.
 43 2019-02-13T01:18:32  <echeveria> this has resulted in vulnerabilities as well. it’s deterministic as secp256k1 is, with rfc6979, but this is not a method of making signatures single show.
 44 2019-02-13T01:18:52  <sipa> i think you mean "unique" instead of "single show"
 45 2019-02-13T01:18:58  *** davec has quit IRC
 46 2019-02-13T01:20:25  <booyah> what is single show signature?
 47 2019-02-13T01:20:36  *** davec has joined #bitcoin-core-dev
 48 2019-02-13T01:20:53  <sipa> a signature that leaks the private key as soon as you sign two different messages with the same key
 49 2019-02-13T01:21:36  <echeveria> sipa: yeah, wrong terminology I think.
 50 2019-02-13T01:21:59  <sipa> a unique signature is one where every message/pubkey pair has exactly one valid signature
 51 2019-02-13T01:22:19  <booyah> hmm?? ed25519 (nor secp256k1) are not single-show right? lamport is
 52 2019-02-13T01:22:57  <sipa> correct
 53 2019-02-13T01:23:10  <sipa> which is why i think echeveria meant unique signature, not single show
 54 2019-02-13T01:23:25  <echeveria> booyah: right. a well known altcoins uses this “property” of ed25519 to protect against stake grinding attacks. their misunderstanding of the description of ed25519 make them believe the output was unique, where the text suggested the outputs were deterministic.
 55 2019-02-13T01:23:55  <sipa> (neither ed25519 nor secp256k1 are unique, but due to the deterministic signing constructing in ed25519 people sometimes think it is - but it's no different than using rfc6979 with secp256k1)
 56 2019-02-13T01:25:44  <echeveria> yes. the text just meant the reference library was 6979 by default. bizarrely a lot of ecdsa libraries still aren’t.
 57 2019-02-13T01:27:20  <booyah> what would be signature being unique, and being deterministic, in this context?
 58 2019-02-13T01:27:38  <booyah> deterministic = for same cleartext, and same privkey, it produces identical signature?
 59 2019-02-13T01:27:43  <sipa> deterministic is a property of a signing implementation, not a property of the signature scheme
 60 2019-02-13T01:27:57  <sipa> unique means that the only possible implementation is deterministic
 61 2019-02-13T01:28:12  <sipa> BLS for example is unique
 62 2019-02-13T01:28:50  <echeveria> in the context of the signer, they choose their nonce based on the H(message + privkey) rather than choosing random bytes. it is impossible to prove this happened to an untrusted observer.
 63 2019-02-13T01:29:20  <sipa> wellll.... (/me wonders off into ZKP land)
 64 2019-02-13T01:29:34  <booyah> echeveria: neat. makes sense
 65 2019-02-13T01:32:03  *** IGHOR has quit IRC
 66 2019-02-13T01:35:18  *** IGHOR has joined #bitcoin-core-dev
 67 2019-02-13T01:45:04  *** Karyon has quit IRC
 68 2019-02-13T01:50:09  *** twistedline_ has quit IRC
 69 2019-02-13T01:57:06  *** AaronvanW has quit IRC
 70 2019-02-13T02:15:38  *** pinheadmz has joined #bitcoin-core-dev
 71 2019-02-13T02:33:03  *** twistedline has joined #bitcoin-core-dev
 72 2019-02-13T02:34:20  *** twistedline has quit IRC
 73 2019-02-13T02:47:35  *** Karyon has joined #bitcoin-core-dev
 74 2019-02-13T02:58:01  *** pinheadmz has quit IRC
 75 2019-02-13T03:21:02  *** pinheadmz has joined #bitcoin-core-dev
 76 2019-02-13T03:22:06  *** jasonzhouu has quit IRC
 77 2019-02-13T03:24:00  *** jasonzhouu has joined #bitcoin-core-dev
 78 2019-02-13T03:36:59  *** pinheadmz has quit IRC
 79 2019-02-13T03:41:26  *** Murch has quit IRC
 80 2019-02-13T03:43:48  *** DeanGuss has joined #bitcoin-core-dev
 81 2019-02-13T03:51:25  *** Karyon has quit IRC
 82 2019-02-13T03:57:09  *** sakalli_ has joined #bitcoin-core-dev
 83 2019-02-13T03:59:32  *** sakalli_ has quit IRC
 84 2019-02-13T04:00:11  *** jimmysong has joined #bitcoin-core-dev
 85 2019-02-13T04:00:16  *** jimmysong_ has joined #bitcoin-core-dev
 86 2019-02-13T04:09:37  *** spinza has quit IRC
 87 2019-02-13T04:14:55  *** spinza has joined #bitcoin-core-dev
 88 2019-02-13T04:17:08  *** shesek`` has quit IRC
 89 2019-02-13T04:34:16  *** kallewoof has joined #bitcoin-core-dev
 90 2019-02-13T04:45:07  *** pinheadmz has joined #bitcoin-core-dev
 91 2019-02-13T05:03:48  *** shesek`` has joined #bitcoin-core-dev
 92 2019-02-13T05:06:10  *** sakalli_ has joined #bitcoin-core-dev
 93 2019-02-13T05:08:39  *** sakalli_ has quit IRC
 94 2019-02-13T05:26:21  *** skyikot has quit IRC
 95 2019-02-13T05:45:20  *** pinheadmz has quit IRC
 96 2019-02-13T05:52:55  *** StopAndDecrypt has quit IRC
 97 2019-02-13T06:06:33  *** bralyclo_ has joined #bitcoin-core-dev
 98 2019-02-13T06:10:18  *** bralyclow has quit IRC
 99 2019-02-13T06:18:53  *** pinheadmz has joined #bitcoin-core-dev
100 2019-02-13T06:33:42  *** jtimon has quit IRC
101 2019-02-13T06:35:23  *** pinheadmz has quit IRC
102 2019-02-13T06:41:17  *** pinheadmz has joined #bitcoin-core-dev
103 2019-02-13T06:55:31  *** rex4539 has quit IRC
104 2019-02-13T06:56:52  *** pinheadmz has quit IRC
105 2019-02-13T06:57:40  *** Randolf has quit IRC
106 2019-02-13T07:38:32  *** bitcoin-git has joined #bitcoin-core-dev
107 2019-02-13T07:38:32  <bitcoin-git> [bitcoin] yunchiri opened pull request #15396: Update build-windows.md (master...patch-1) https://github.com/bitcoin/bitcoin/pull/15396
108 2019-02-13T07:38:39  *** bitcoin-git has left #bitcoin-core-dev
109 2019-02-13T07:42:30  *** pinheadmz has joined #bitcoin-core-dev
110 2019-02-13T07:44:49  *** pinheadmz has quit IRC
111 2019-02-13T07:46:08  *** jimmysong has quit IRC
112 2019-02-13T07:48:20  *** jimmysong has joined #bitcoin-core-dev
113 2019-02-13T07:57:12  <provoostenator> luke-jr: I'm still open to either cpp-subprocess or boost::process or something else; need to study them more. It shouldn't be too hard to swap them in my PR.
114 2019-02-13T08:12:38  *** rhavar has quit IRC
115 2019-02-13T08:17:15  <promag> review beg in #15195
116 2019-02-13T08:17:17  <gribble> https://github.com/bitcoin/bitcoin/issues/15195 | gui: Add Close Wallet action by promag · Pull Request #15195 · bitcoin/bitcoin · GitHub
117 2019-02-13T08:17:54  <promag> this one is really small
118 2019-02-13T08:19:43  <promag> maybe add it to hp
119 2019-02-13T08:19:46  *** promag has quit IRC
120 2019-02-13T08:54:03  *** niska has quit IRC
121 2019-02-13T08:59:13  *** niska has joined #bitcoin-core-dev
122 2019-02-13T09:03:57  *** ghost43 has quit IRC
123 2019-02-13T09:06:43  *** niska has quit IRC
124 2019-02-13T09:08:38  *** setpill has joined #bitcoin-core-dev
125 2019-02-13T09:09:21  *** ghost43 has joined #bitcoin-core-dev
126 2019-02-13T09:12:01  *** rh0nj has quit IRC
127 2019-02-13T09:13:08  *** rh0nj has joined #bitcoin-core-dev
128 2019-02-13T09:17:58  *** niska has joined #bitcoin-core-dev
129 2019-02-13T09:32:40  *** timothy has joined #bitcoin-core-dev
130 2019-02-13T09:34:30  *** jungly has joined #bitcoin-core-dev
131 2019-02-13T09:44:40  *** Karyon has joined #bitcoin-core-dev
132 2019-02-13T09:47:28  <gwillen> the wallet unloading logic is uh, intricate
133 2019-02-13T09:48:11  <gwillen> the thing #15195 is doing seems safe to me, but I don't know how long a wallet can take to unload; if it's a long time it could definitely be confusing.
134 2019-02-13T09:48:13  <gribble> https://github.com/bitcoin/bitcoin/issues/15195 | gui: Add Close Wallet action by promag · Pull Request #15195 · bitcoin/bitcoin · GitHub
135 2019-02-13T09:55:07  *** TX1683 has quit IRC
136 2019-02-13T09:56:57  *** TX1683 has joined #bitcoin-core-dev
137 2019-02-13T10:01:38  *** spinza has quit IRC
138 2019-02-13T10:04:03  *** Randolf has joined #bitcoin-core-dev
139 2019-02-13T10:04:41  *** promag has joined #bitcoin-core-dev
140 2019-02-13T10:09:25  *** spinza has joined #bitcoin-core-dev
141 2019-02-13T10:27:08  *** phwalkr has quit IRC
142 2019-02-13T10:29:14  *** phwalkr has joined #bitcoin-core-dev
143 2019-02-13T10:29:50  *** phwalkr has quit IRC
144 2019-02-13T10:33:27  *** phwalkr has joined #bitcoin-core-dev
145 2019-02-13T10:39:37  *** Karyon has quit IRC
146 2019-02-13T11:06:19  *** phwalkr has quit IRC
147 2019-02-13T11:14:23  *** promag has quit IRC
148 2019-02-13T11:30:07  *** AaronvanW has joined #bitcoin-core-dev
149 2019-02-13T11:32:19  *** murrayn has quit IRC
150 2019-02-13T11:33:09  *** siom has joined #bitcoin-core-dev
151 2019-02-13T11:55:36  *** phwalkr has joined #bitcoin-core-dev
152 2019-02-13T12:02:58  *** Randolf has quit IRC
153 2019-02-13T12:03:23  *** Randolf has joined #bitcoin-core-dev
154 2019-02-13T12:04:42  *** phwalkr has quit IRC
155 2019-02-13T12:07:59  *** phwalkr has joined #bitcoin-core-dev
156 2019-02-13T12:08:41  *** setpill has quit IRC
157 2019-02-13T12:09:01  *** setpill has joined #bitcoin-core-dev
158 2019-02-13T12:18:27  *** promag has joined #bitcoin-core-dev
159 2019-02-13T12:20:12  *** phwalkr_ has joined #bitcoin-core-dev
160 2019-02-13T12:21:49  *** phwalkr has quit IRC
161 2019-02-13T12:23:02  *** phwalkr has joined #bitcoin-core-dev
162 2019-02-13T12:26:30  *** phwalkr_ has quit IRC
163 2019-02-13T12:40:00  *** phwalkr_ has joined #bitcoin-core-dev
164 2019-02-13T12:43:36  *** phwalkr has quit IRC
165 2019-02-13T12:44:55  *** phwalkr_ has quit IRC
166 2019-02-13T12:45:26  *** phwalkr has joined #bitcoin-core-dev
167 2019-02-13T12:53:58  *** spinza has quit IRC
168 2019-02-13T12:56:36  *** phwalkr_ has joined #bitcoin-core-dev
169 2019-02-13T12:57:24  *** phwalkr_ has joined #bitcoin-core-dev
170 2019-02-13T12:59:38  *** phwalkr has quit IRC
171 2019-02-13T13:01:54  *** phwalkr_ has quit IRC
172 2019-02-13T13:03:28  *** phwalkr has joined #bitcoin-core-dev
173 2019-02-13T13:04:36  *** phwalkr_ has joined #bitcoin-core-dev
174 2019-02-13T13:07:55  *** phwalkr has quit IRC
175 2019-02-13T13:08:58  *** phwalkr_ has quit IRC
176 2019-02-13T13:11:54  *** spinza has joined #bitcoin-core-dev
177 2019-02-13T13:14:31  *** promag has quit IRC
178 2019-02-13T13:46:11  *** promag has joined #bitcoin-core-dev
179 2019-02-13T13:50:27  *** promag has quit IRC
180 2019-02-13T13:53:32  *** csknk has joined #bitcoin-core-dev
181 2019-02-13T14:04:33  *** bralyclow has joined #bitcoin-core-dev
182 2019-02-13T14:07:46  *** bralyclo_ has quit IRC
183 2019-02-13T14:16:20  *** paulje has joined #bitcoin-core-dev
184 2019-02-13T14:16:43  *** zander has joined #bitcoin-core-dev
185 2019-02-13T14:17:32  *** paulje has quit IRC
186 2019-02-13T14:17:40  *** zander has quit IRC
187 2019-02-13T14:24:16  *** promag has joined #bitcoin-core-dev
188 2019-02-13T14:26:02  *** bitcoin-git has joined #bitcoin-core-dev
189 2019-02-13T14:26:02  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #15395: test: Remove TODO comments to remove -txindex option (master...Mf1902-qaNoTodo) https://github.com/bitcoin/bitcoin/pull/15395
190 2019-02-13T14:26:14  *** bitcoin-git has left #bitcoin-core-dev
191 2019-02-13T14:32:18  *** phwalkr has joined #bitcoin-core-dev
192 2019-02-13T14:42:11  *** jtimon has joined #bitcoin-core-dev
193 2019-02-13T14:46:30  *** promag has quit IRC
194 2019-02-13T14:47:14  *** jio has joined #bitcoin-core-dev
195 2019-02-13T14:47:14  *** promag has joined #bitcoin-core-dev
196 2019-02-13T14:52:48  *** bitcoin-git has joined #bitcoin-core-dev
197 2019-02-13T14:52:48  <bitcoin-git> [bitcoin] instagibbs opened pull request #15397: Remove manual byte editing in wallet_tx_clone func test (master...wallet_clone_magic) https://github.com/bitcoin/bitcoin/pull/15397
198 2019-02-13T14:52:50  *** bitcoin-git has left #bitcoin-core-dev
199 2019-02-13T14:53:35  *** shesek`` has quit IRC
200 2019-02-13T14:56:24  *** bralyclow has quit IRC
201 2019-02-13T14:57:37  <luke-jr> provoostenator: cpp-subprocess doesn't seem to be available on Gentoo at all, FWIW
202 2019-02-13T14:57:57  <luke-jr> easily changed, but I'd check availability in Debian/RHEL since those are slower
203 2019-02-13T14:58:11  <provoostenator> Why? It's included as a subtree.
204 2019-02-13T14:58:51  <wumpus> should probably be configurable whether to use the OS-installed one or the subtree
205 2019-02-13T14:59:42  <wumpus> unless we require a specifically patched version like with tinyformat
206 2019-02-13T15:01:04  <promag> I still don´t understand how can cpp-subprocess be an option without win support
207 2019-02-13T15:01:37  <wumpus> why no win support?
208 2019-02-13T15:02:02  <wumpus> is it impossible? or just no one had the time or motivation to write it yet
209 2019-02-13T15:02:39  <promag> I guess so
210 2019-02-13T15:02:41  <wumpus> after the walletnotify escaping issue I'm kind of sad about any kind of external process support
211 2019-02-13T15:03:08  <wumpus> though at least that problem is avoided by passing the data via stdin/stdout and not the command line :<
212 2019-02-13T15:03:14  *** ccook_ is now known as ccook
213 2019-02-13T15:04:27  <promag> wumpus: that makes sense when you "pipe" to the subprocess
214 2019-02-13T15:04:43  <promag> I really like the idea of env vars
215 2019-02-13T15:05:27  <luke-jr> provoostenator: it should not be included as a subtree
216 2019-02-13T15:05:41  <wumpus> piping is definitely preferable for any significant amount of data, certainly if it's supposed to be binary clean
217 2019-02-13T15:06:19  <wumpus> but environment variables can be useful for some things, sure
218 2019-02-13T15:06:37  <luke-jr> subtrees are a bad practice
219 2019-02-13T15:07:10  <promag> wumpus: exactly, and don't require changing the conf, only the script
220 2019-02-13T15:07:17  <gmaxwell> what is using cpp-subprocess?
221 2019-02-13T15:07:43  <provoostenator> I didn't even know there was a package for cpp-subprocess. I assumed it didn't since there were no Github tags or makefiles.
222 2019-02-13T15:08:15  <promag> wumpus: with boost process it's something like: bp::system(cmd, bp::env["TXID"]=txid, bp::env["WALLET"]=wallet.GetName());
223 2019-02-13T15:08:15  <wumpus> gmaxwell: #15382
224 2019-02-13T15:08:16  <luke-jr> provoostenator: maybe there isn't - that would be a reason not to use it
225 2019-02-13T15:08:17  <gribble> https://github.com/bitcoin/bitcoin/issues/15382 | WIP [util] add runCommandParseJSON by Sjors · Pull Request #15382 · bitcoin/bitcoin · GitHub
226 2019-02-13T15:08:59  <provoostenator> luke-jr: why would absense of a package be reason not to use something? I would say the biggest criterium is quality.
227 2019-02-13T15:09:18  <provoostenator> But if boost:process already works with Windows I will probably switch to that anyway.
228 2019-02-13T15:09:24  <gmaxwell> welp jgarzik on that pr. pressing close. best of luck to you.
229 2019-02-13T15:09:49  <promag> ?
230 2019-02-13T15:10:04  <wumpus> the biggest criterion is "please don't introduce any security bugs"
231 2019-02-13T15:10:22  <luke-jr> biggest criterion != only criterion
232 2019-02-13T15:10:35  <promag> another one: use stable dependencies?
233 2019-02-13T15:11:27  <gmaxwell> more like avoid dependencies entirely, unless they provide a lot of value.
234 2019-02-13T15:12:12  <luke-jr> dependencies > NIH reinvention
235 2019-02-13T15:12:15  <provoostenator> I can't believe we even need dependencies for something as basic as running a command and getting the result.
236 2019-02-13T15:12:17  <gmaxwell> (with 'a lot' depending on how universally used they are.)
237 2019-02-13T15:12:24  <gmaxwell> provoostenator: yeah
238 2019-02-13T15:12:37  <provoostenator> You'd think 40+ years of C development would have solved that...
239 2019-02-13T15:13:18  <luke-jr> well, commands are inherently external to C
240 2019-02-13T15:13:20  <luke-jr> iirc
241 2019-02-13T15:13:28  <wumpus> provoostenator: +100
242 2019-02-13T15:13:48  <wumpus> so rust implementation of bitcoin core when?
243 2019-02-13T15:14:05  <luke-jr> Rust compiler that can be safely bootstrapped when? :/
244 2019-02-13T15:14:49  <luke-jr> I guess the problem with popen is Windows
245 2019-02-13T15:15:18  <rafalcpp> provoostenator: well you can just run command easily, but boost process just handles more options in it
246 2019-02-13T15:15:33  <gmaxwell> provoostenator: it's trivial to do in standard C on unix,  ... the thing I'd expect a dependency to handle is windows.  But it sounds like this one doesn't do windows?
247 2019-02-13T15:15:40  <luke-jr> boost::process is newer than our current minimum version it seems; wonder if we can just bump it
248 2019-02-13T15:15:43  <wumpus> gmaxwell: was about to say that
249 2019-02-13T15:16:13  <wumpus> so can boost::process do the required thing on windows?
250 2019-02-13T15:16:32  <wumpus> I kind of hate to introduce a new boost dependency but I think I hate the alternative even more
251 2019-02-13T15:16:49  <gmaxwell> Certantly if we do need to add a dep for this (E.g. to get windows support) I'd rather take boost than some obscure package.
252 2019-02-13T15:16:55  <wumpus> right
253 2019-02-13T15:17:03  <wumpus> especially as boost tends to be picked up in future c++
254 2019-02-13T15:17:14  <gmaxwell> Also there is at least some chance that the boost thing shows up in C++24 or whatever.
255 2019-02-13T15:17:20  <provoostenator> I haven't checked yet. I spent most of yesterday dealing with make exploding over the order in which UniValue and Util were loaded (since this methods a UniValue)
256 2019-02-13T15:17:49  <rafalcpp> what do you require of bp?
257 2019-02-13T15:18:03  <luke-jr> boost::process is new in 1.64.0; Debian is at 1.62 :/
258 2019-02-13T15:18:15  <provoostenator> rafacpp: run a command, process its std::out
259 2019-02-13T15:18:31  <rafalcpp> wait I think I did that in debian stable
260 2019-02-13T15:18:40  <provoostenator> (and parse that if it's valid JSON, otherwise fail)
261 2019-02-13T15:18:41  <luke-jr> RHEL is at 1.53 x.x
262 2019-02-13T15:19:09  <wumpus> eh that JSON parsing we can handle ourselves
263 2019-02-13T15:19:22  <wumpus> the depenency just needs to be able to provide stdin data and give us stdout data
264 2019-02-13T15:19:22  <provoostenator> wumpus: correct, UniValue does that
265 2019-02-13T15:19:38  <wumpus> like python's subprocess has been able to do, what, 20 years?
266 2019-02-13T15:19:49  <provoostenator> Yes
267 2019-02-13T15:20:17  <provoostenator> One even hack would be to use the existing code for a calling a command, have it pipe the result to a file and then poll the filesystem for it. But I'd rather not.
268 2019-02-13T15:20:21  <provoostenator> *evil
269 2019-02-13T15:20:24  <wumpus> oh no
270 2019-02-13T15:20:41  <wumpus> we're going do this properly or not at all
271 2019-02-13T15:20:56  <provoostenator> Indeed. And it shouldn't be that hard.
272 2019-02-13T15:21:25  <provoostenator> The test suite uses a hack along these lines to the notification code by the way.
273 2019-02-13T15:21:31  <provoostenator> But that's just a test suite.
274 2019-02-13T15:21:33  <wumpus> that's fine
275 2019-02-13T15:21:35  *** bralyclow has joined #bitcoin-core-dev
276 2019-02-13T15:21:35  <wumpus> right
277 2019-02-13T15:22:03  <luke-jr> https://github.com/eidheim/tiny-process-library might be another option, but also no packages it seems
278 2019-02-13T15:22:11  <wumpus> and maybe that can be replaced too when have a way to do it better
279 2019-02-13T15:22:47  <promag> one important thing, that we don't handle right, is thread safety - boost::process isn't thread safe also
280 2019-02-13T15:22:56  <wumpus> promag: what???
281 2019-02-13T15:23:00  <luke-jr> ^
282 2019-02-13T15:23:03  <gmaxwell> what do you mean by "thread safe" in this context?
283 2019-02-13T15:23:18  <wumpus> making new processes should be about the most thread safe thing ever
284 2019-02-13T15:23:23  <promag> we launch a thread that will call system(cmd)
285 2019-02-13T15:23:29  <promag> this is not thread safe
286 2019-02-13T15:23:36  <wumpus> how is it not?
287 2019-02-13T15:24:24  <promag> iiuc it can mess file descriptors of one process to other if concurrent systems are called?
288 2019-02-13T15:25:11  <gmaxwell> system() is prefertly multithread safe.
289 2019-02-13T15:25:19  <rafalcpp> Stroustrup  *invents C++*
290 2019-02-13T15:25:38  <rafalcpp> 40 years passes.  hEy guYs mayBE we shOUld have clAssEs to do ProcESSes and shit
291 2019-02-13T15:25:53  <gmaxwell> (at least the C function is)
292 2019-02-13T15:25:54  <luke-jr> I'm shocked there isn't an obviously good solution to this
293 2019-02-13T15:26:32  <rafalcpp> maybe reimplement mininmal version of boost process and include it
294 2019-02-13T15:26:50  *** michaels_ has joined #bitcoin-core-dev
295 2019-02-13T15:27:06  <rafalcpp> or build own boost process on our own by copying the code (assuming it doesn't have other boost deps goind too deep)
296 2019-02-13T15:27:08  <promag> gmaxwell: I read different opinions, I don't have deep knowledge here
297 2019-02-13T15:27:10  <wumpus> rafalcpp: similarly I'm surprised there is no standardized networking between platforms yet, certainly the async stuff, I mean, TCP/IP is not exactly an experimental toy anymore, decennia later
298 2019-02-13T15:27:44  <promag> https://stackoverflow.com/questions/13471489/is-it-safe-to-call-system3-from-multi-threaded-process
299 2019-02-13T15:27:48  <wumpus> promag: this isn't about opinions, either that call is thread-safe or it is not, I can't find anythingabout thread safety on the manpage at least
300 2019-02-13T15:28:27  <luke-jr> eh? my system(3) manpage says it's MT-safe
301 2019-02-13T15:28:30  <wumpus> it has *tons* of problems, for example escaping security issues, but I don't think thread safety s one of them
302 2019-02-13T15:28:48  <wumpus> system()  │ Thread safety │ MT-Safe
303 2019-02-13T15:28:54  <wumpus> oh you're right luke-jr
304 2019-02-13T15:29:00  <luke-jr> of course, this is just glibc
305 2019-02-13T15:29:07  *** dviola has joined #bitcoin-core-dev
306 2019-02-13T15:29:17  <wumpus> well yes but ...
307 2019-02-13T15:29:51  <promag> wumpus: setenv is not thread safe :(
308 2019-02-13T15:30:06  <wumpus> "fix your libc this is not 1995 anymore"
309 2019-02-13T15:30:09  <gmaxwell> The SO answer also supports it being safe in general-- points out its safe on linux, the only counter example it gives is solaris but there the only issue is changes to signal handlers.
310 2019-02-13T15:30:11  <wumpus> promag: I know
311 2019-02-13T15:30:23  <wumpus> promag: that's why you do it *after* forking
312 2019-02-13T15:30:43  <luke-jr> Windows has no fork :P
313 2019-02-13T15:30:49  *** pinheadmz has joined #bitcoin-core-dev
314 2019-02-13T15:30:51  <wumpus> windows is completely differnt
315 2019-02-13T15:30:52  <gmaxwell> essentially, when you fork, you lose your other threads, so you can't do anything that will interact with them.
316 2019-02-13T15:31:03  <wumpus> in *any case* you can pass a new environment to the spawn call
317 2019-02-13T15:31:04  <gmaxwell> Calling plain libc functions and syscalls is fine, however.
318 2019-02-13T15:31:06  <wumpus> both on windows and linux
319 2019-02-13T15:31:16  <wumpus> but yeah not with system() which is kind of limited
320 2019-02-13T15:31:19  <promag> wumpus: how=
321 2019-02-13T15:31:36  <wumpus> sometimes I think the only real use of system() system call left is to spawn shells in exploits
322 2019-02-13T15:32:07  <gmaxwell> lol
323 2019-02-13T15:32:33  <gmaxwell> "Highly optimized for return only programming."
324 2019-02-13T15:32:40  <wumpus> :-)
325 2019-02-13T15:32:48  <promag> btw, could we just support %w on non-win?
326 2019-02-13T15:33:07  <promag> ..for now.. X)
327 2019-02-13T15:33:39  <rafalcpp> hould we write own minimal process library?
328 2019-02-13T15:33:41  <achow101> why not boost::process?
329 2019-02-13T15:33:48  <rafalcpp> achow101: too new
330 2019-02-13T15:33:50  <promag> is there anyone using *notify commands on windows?
331 2019-02-13T15:34:33  <luke-jr> if it does what we need, maybe we can just embed a copy of boost::process used when the OS lacks a new enough version?
332 2019-02-13T15:34:34  <gmaxwell> if boost process being too new is the only issue with it and its otherwise attractive and handles window, we could also potentially just copy it temporarily into the codebase.
333 2019-02-13T15:34:36  <wumpus> promag: for example `execve` has a envp argument, you should really never have to use setenv()
334 2019-02-13T15:34:43  <luke-jr> it's not ideal, but better than the alternatives I guess
335 2019-02-13T15:35:06  <rafalcpp> gmaxwell: might be too dependant on other boost
336 2019-02-13T15:35:08  <gmaxwell> (though in the past I've found that its hard to copy out just parts of boost, because boot itself is a full on boost koolaid drinker)
337 2019-02-13T15:35:16  <luke-jr> rafalcpp: might be, but probably not
338 2019-02-13T15:35:20  <gmaxwell> ^
339 2019-02-13T15:35:22  * rafalcpp bjam's it
340 2019-02-13T15:35:24  <luke-jr> rafalcpp: prior to inclusion in boost, it was separate in fact
341 2019-02-13T15:35:53  <luke-jr> gmaxwell: even if it's on boost koolaid, we use boost anyway, so that shouldn't be a big issue
342 2019-02-13T15:36:04  <wumpus> luke-jr: unless it uses new boost features
343 2019-02-13T15:36:07  <luke-jr> true
344 2019-02-13T15:36:22  <wumpus> (which could be expected if it's new code)
345 2019-02-13T15:36:25  <luke-jr> but then we can just embed a copy of an older boost::process before it got merged
346 2019-02-13T15:36:31  <luke-jr> assuming it's compatible
347 2019-02-13T15:36:43  *** jio has quit IRC
348 2019-02-13T15:36:54  <rafalcpp> luke-jr: soo yeah... let's just find the base library for process, review it based on boost::process experience and use that?
349 2019-02-13T15:37:45  <rafalcpp> I'm interested, because on project done with my friend I have similar problem, so we also could use/help with such process lib if we can
350 2019-02-13T15:38:03  <achow101> also we probably won't need to have to be able to send things over stdin. hwi is designed to have everything entered in a single command
351 2019-02-13T15:38:06  <wumpus> I think it's pointless to re-invent boost::process
352 2019-02-13T15:38:37  <luke-jr> achow101: as we're learning with walletnotify, a single command is a mess
353 2019-02-13T15:39:02  <luke-jr> so I think stdin would be preferred?
354 2019-02-13T15:39:03  <wumpus> like "this already exists in a newer verison of boost but we need to write our own anyway *just* for other distributions, a problem that will automatically go away with waiting"
355 2019-02-13T15:39:17  <wumpus> I like waiting and doing nothing more
356 2019-02-13T15:39:17  <promag> what does pyhton subprocess uses in windows?
357 2019-02-13T15:39:21  <luke-jr> wumpus: just a limited copy used when boost is old, IMO
358 2019-02-13T15:39:25  <rafalcpp>  " long attempt to get a boost.process library, which is going on since 2006. "  wow.
359 2019-02-13T15:39:25  <achow101> luke-jr: it was the only way I could have every device have a consistent interface
360 2019-02-13T15:39:37  <luke-jr> promag: Python is a giant blob
361 2019-02-13T15:39:40  <achow101> otherwise some would require stdin for some thigns and others wouldn't
362 2019-02-13T15:39:58  <luke-jr> achow101: ?
363 2019-02-13T15:40:09  <wumpus> it's absurd that something simple like this is giving so much problems
364 2019-02-13T15:40:12  <wumpus> bring back the 80's please
365 2019-02-13T15:40:15  <luke-jr> anything you can do with a command line, you can do with stdin..
366 2019-02-13T15:40:36  <gmaxwell> achow101: commandline lengths are limited, unfortunately. (also... not private)
367 2019-02-13T15:40:41  <achow101> luke-jr: trezor asks for a scrambled pin. no other device does that
368 2019-02-13T15:40:57  <luke-jr> achow101: so?
369 2019-02-13T15:41:09  <achow101> you could enter it over stdin, but then you have to special case for the trezor to know to send it something over stdin
370 2019-02-13T15:41:27  <luke-jr> achow101: I'm saying do EVERYTHING over stdin
371 2019-02-13T15:41:41  <gmaxwell> certantly it would be nice to not need stdin, but I believe the maximum size of a transaction is above the commandline limit even on bog standard linux.
372 2019-02-13T15:41:56  <luke-jr> gmaxwell: on Windows, the command line has no standard quoting
373 2019-02-13T15:41:59  <gmaxwell> I'd always assumed this stuff would use stdin exclusively.
374 2019-02-13T15:42:09  <rafalcpp> so many ways to snoop on cmd args from other local users
375 2019-02-13T15:42:27  <luke-jr> gmaxwell: the %w promag keeps bringing up is a mess because apparently we want to escape the wallet name
376 2019-02-13T15:42:37  <rafalcpp> how about creating a tmp file (chmod for privacy), and pass it's name in arg?
377 2019-02-13T15:42:44  *** Murch has joined #bitcoin-core-dev
378 2019-02-13T15:42:51  <luke-jr> rafalcpp: …why?
379 2019-02-13T15:43:01  <wumpus> nOoooOooo *screams*
380 2019-02-13T15:43:04  <gmaxwell> rafalcpp: there be dragons,  decades of security disasters from that..
381 2019-02-13T15:43:35  <rafalcpp> hmm to hide the text from ps aux, and at same time not require stdin/out process library...?  what security disasters, when done right?
382 2019-02-13T15:43:37  <wumpus> please do the sane thing and have some protocol over stdin/stdout, don't try to do hacks with command lines, or temporary files, or env variables, or ...
383 2019-02-13T15:43:51  <gmaxwell> I think insecure tmp files is probably neck and neck with buffer overflows for the origin of the most CVEs.
384 2019-02-13T15:43:55  <wumpus> we really can't afford stupid mistakes here
385 2019-02-13T15:44:15  <wumpus> gmaxwell: as well as shell escaping issues
386 2019-02-13T15:44:21  <wumpus> this is like bug paradise
387 2019-02-13T15:44:21  <rafalcpp> just chmod it? and mktemp exists for atomic creation of unique file?
388 2019-02-13T15:45:03  <wumpus> *cries*
389 2019-02-13T15:45:34  <gmaxwell> rafalcpp: it's an ugly rathole. Stdin is a straight forward, clean solution.
390 2019-02-13T15:45:44  <gmaxwell> It would be a 4-line no brainer except for windows.
391 2019-02-13T15:45:50  <rafalcpp> btw, how about IPC or RPC?
392 2019-02-13T15:46:00  <wumpus> chmod also isn't available on windows, or at least, very different
393 2019-02-13T15:46:07  <gmaxwell> but it sounds like the boost thing handles windows fine.
394 2019-02-13T15:46:17  <gmaxwell> rafalcpp: also a security disaster.
395 2019-02-13T15:46:18  <wumpus> IPC or RPC is *more difficult* than stdin and stdout handling
396 2019-02-13T15:46:27  <wumpus> it's also highly platform specific
397 2019-02-13T15:46:44  <wumpus> especially if you want only the child process to be able to access it
398 2019-02-13T15:46:45  <gmaxwell> (consider the recently published rpc cve in bitcoin that we basically cannot fix...)
399 2019-02-13T15:47:02  *** kallul has joined #bitcoin-core-dev
400 2019-02-13T15:48:16  <rafalcpp> you're right, stdin is most secure
401 2019-02-13T15:48:26  *** pinheadmz has quit IRC
402 2019-02-13T15:49:48  <promag> what if we assign a unique id to the wallet - which is passed to cmd - and then the cmd can use that to know more details?
403 2019-02-13T15:50:25  <wumpus> not more hacks
404 2019-02-13T15:50:30  <wumpus> stop this
405 2019-02-13T15:51:01  <promag> right, thanks
406 2019-02-13T15:51:25  <rafalcpp> boost process seems to be getting bugfixes as recent as a month ago.  I guess best to use that version (insted of going back to old version before move into part of boost)
407 2019-02-13T15:53:29  <gmaxwell> I know, we could embed a SMTP mail user agent, and send email to the other process.
408 2019-02-13T15:55:07  <gmaxwell> oh oh oh, I know. I know. We could use ... A BLOCKCHAIN.
409 2019-02-13T15:55:12  <luke-jr> lol
410 2019-02-13T15:55:18  <wumpus> gmaxwell: sometimes I feel we've reached the point where it's trivial to spin up a complete host environmet including mail server and website, but impossible to do even basic things like spin up a process and interface with it
411 2019-02-13T15:55:25  <gmaxwell> first we'll issue utility tokens for interprocess communications....
412 2019-02-13T15:55:37  <promag> smart processes? lgtm
413 2019-02-13T15:57:03  <wumpus> yes dunno build a IoT toilet plunger that changes color on a new transaction for notification
414 2019-02-13T15:57:24  <provoostenator> gmaxwell: there is no maximum length for PSBT either... and if you'r spending legacy stuff to a very careful (and powerful) device, stdin might indeed be very useful.
415 2019-02-13T15:58:28  <achow101> we can add an option to hwi to send all arguments over stdin. right now it's completely command line based
416 2019-02-13T15:59:07  <wumpus> soo
417 2019-02-13T15:59:14  <wumpus> my proposal would be: first build this with boost::process
418 2019-02-13T15:59:23  <gmaxwell> achow101: presumably you lack tests with large PSBTs right now then. :)
419 2019-02-13T15:59:26  *** setpill has quit IRC
420 2019-02-13T15:59:47  <wumpus> if, by the time this gets merged, the availability of that is still a problem, we can put in the effort to make something ourselves or adapt something
421 2019-02-13T16:00:53  <wumpus> but please let's not take design shortcuts because of short-term easy availability of libraries, you'll hate yourself for that later, promised
422 2019-02-13T16:01:00  <achow101> gmaxwell: the tests currently don't use the cli directly (as in use subprocess). so late psbts probably wouldn't trigger a problem in current tests anyways
423 2019-02-13T16:01:41  <luke-jr> wumpus: good point, this can be an optional feature for newer boost versions for the initial PR, and then address that separately
424 2019-02-13T16:01:48  <wumpus> luke-jr: +1
425 2019-02-13T16:02:17  *** pinheadmz has joined #bitcoin-core-dev
426 2019-02-13T16:02:58  <gmaxwell> wumpus: or put in efforts to extract boost-process from boost and package it as a compat.
427 2019-02-13T16:03:15  <wumpus> gmaxwell: right
428 2019-02-13T16:05:18  <wumpus> promag: as for your case, I don't think there's any option on windows, if you want to pass the wallet name on the system() command line, than to use an encoding like base64. It's inconvenient for the receiving process, but it's better than nothing (I guess) and then again it's their fault for using a broken OS :)
429 2019-02-13T16:05:27  <provoostenator> achow101: the tests in #14912 (which is still based on popen) send a real (regtest) PSBT to a real command.
430 2019-02-13T16:05:29  <gribble> https://github.com/bitcoin/bitcoin/issues/14912 | [WIP] External signer support (e.g. hardware wallet) by Sjors · Pull Request #14912 · bitcoin/bitcoin · GitHub
431 2019-02-13T16:05:53  <provoostenator> But a rather small one, so I 'd have have to generate a bigger one in the functional test suite.
432 2019-02-13T16:07:01  <provoostenator> I created a seperate PR to figure out how to properly call an external command and process the result because I had a feeling it would otherwise overwhelm the main PR :-)
433 2019-02-13T16:07:25  <wumpus> promag: I know I was originally against the idea of using an encoding but I had never expected to be like this
434 2019-02-13T16:08:54  <wumpus> passing the information to the notify script through stdin would be a future option too I guess...
435 2019-02-13T16:09:23  <provoostenator> As for v0.18 I'd be quite contend if #14021 and #14075 merged, so the HWI Python scripts can be used without compiling a custom branch.
436 2019-02-13T16:09:28  <gribble> https://github.com/bitcoin/bitcoin/issues/14021 | Import key origin data through descriptors in importmulti by achow101 · Pull Request #14021 · bitcoin/bitcoin · GitHub
437 2019-02-13T16:09:30  <gribble> https://github.com/bitcoin/bitcoin/issues/14075 | Import watch only pubkeys to the keypool if private keys are disabled by achow101 · Pull Request #14075 · bitcoin/bitcoin · GitHub
438 2019-02-13T16:10:22  *** bitcoin-git has joined #bitcoin-core-dev
439 2019-02-13T16:10:23  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/0d1160e42185...cbe7efe9ea6c
440 2019-02-13T16:10:23  <bitcoin-git> bitcoin/master 5039e4b Julian Fleischer: Remove unnecessary const_cast
441 2019-02-13T16:10:24  <bitcoin-git> bitcoin/master cbe7efe Wladimir J. van der Laan: Merge #15389: Remove unnecessary const_cast
442 2019-02-13T16:10:26  *** bitcoin-git has left #bitcoin-core-dev
443 2019-02-13T16:10:46  <wumpus> provoostenator: yep; I see those are both already on the milestone
444 2019-02-13T16:10:58  <wumpus> oh #14075 isn't
445 2019-02-13T16:11:01  <gribble> https://github.com/bitcoin/bitcoin/issues/14075 | Import watch only pubkeys to the keypool if private keys are disabled by achow101 · Pull Request #14075 · bitcoin/bitcoin · GitHub
446 2019-02-13T16:11:15  *** bitcoin-git has joined #bitcoin-core-dev
447 2019-02-13T16:11:15  <bitcoin-git> [bitcoin] laanwj merged pull request #15389: Remove unnecessary const_cast (master...patch-1) https://github.com/bitcoin/bitcoin/pull/15389
448 2019-02-13T16:11:17  *** bitcoin-git has left #bitcoin-core-dev
449 2019-02-13T16:14:36  <provoostenator> We use Boost 1.64 in depends, which it seems already has process: https://github.com/boostorg/process/tree/boost-1.64.0 (though maybe unreleased?)
450 2019-02-13T16:15:44  <provoostenator> If so we'd still have to bump the minimum version and/or disable this feature for older versions.
451 2019-02-13T16:20:17  *** mistergold has joined #bitcoin-core-dev
452 2019-02-13T16:20:44  <achow101> what's the first version of boost with process?
453 2019-02-13T16:20:44  <MarcoFalke> I'd feel a bit bad if we had everyone on xenial to force to use depends: https://packages.ubuntu.com/xenial/libboost-thread-dev
454 2019-02-13T16:20:50  <MarcoFalke> 1.64
455 2019-02-13T16:20:59  <wumpus> yes, please just use boost::process for now we'll worry about the dependency stuff alter
456 2019-02-13T16:21:13  <wumpus> let's spend time on desigining interesting features instead of crawling in the dependency mud
457 2019-02-13T16:22:12  *** mistergold has quit IRC
458 2019-02-13T16:22:45  <wumpus> what's up with the last-minute qt bump?
459 2019-02-13T16:22:51  <wumpus> #15393
460 2019-02-13T16:22:53  <gribble> https://github.com/bitcoin/bitcoin/issues/15393 | build: Bump minimum Qt version to 5.5.1 by Sjors · Pull Request #15393 · bitcoin/bitcoin · GitHub
461 2019-02-13T16:23:02  <MarcoFalke> It was an open issue for months
462 2019-02-13T16:23:23  <MarcoFalke> It never compiled on anything less for all those months anyway
463 2019-02-13T16:23:57  <wumpus> so you mean, currently depends doesn't build?
464 2019-02-13T16:24:10  <provoostenator> Depends works fine, it's at 5.9
465 2019-02-13T16:24:10  <MarcoFalke> no system qt
466 2019-02-13T16:24:18  <wumpus> OHH
467 2019-02-13T16:24:22  <wumpus> sorry I misread the PR title
468 2019-02-13T16:24:29  <wumpus> I thought this was a depends bump
469 2019-02-13T16:24:32  <MarcoFalke> Ah
470 2019-02-13T16:25:31  <provoostenator> jnewbery: is there a way to skip a test on Windows (or AppVeyor)?
471 2019-02-13T16:25:42  <MarcoFalke> --exclude test_name
472 2019-02-13T16:25:45  <provoostenator> Or at least to detect the OS.
473 2019-02-13T16:25:55  <MarcoFalke> Oh, wait
474 2019-02-13T16:26:17  <MarcoFalke> Just do it similar to how the wallet tests are skipped
475 2019-02-13T16:27:07  <provoostenator> Yeah, putting --exclude test_name in the appveyor script seems a bit brittle and easy to miss.
476 2019-02-13T16:27:17  <MarcoFalke> def skip_test_if_missing_module
477 2019-02-13T16:27:29  <MarcoFalke> Just consider Windows a "module" ;)
478 2019-02-13T16:27:37  <MarcoFalke> or the os
479 2019-02-13T16:27:53  <provoostenator> def skip_if_windows I guess
480 2019-02-13T16:28:13  <provoostenator> Actually I won't even need that if I just switch to Boost, but I'll keep it in mind.
481 2019-02-13T16:28:30  *** Aaronvan_ has joined #bitcoin-core-dev
482 2019-02-13T16:31:41  *** AaronvanW has quit IRC
483 2019-02-13T16:41:48  <wumpus> is #14289 something that needs to be solved before 0.18 release?
484 2019-02-13T16:41:50  <gribble> https://github.com/bitcoin/bitcoin/issues/14289 | Unbounded growth of scheduler queue · Issue #14289 · bitcoin/bitcoin · GitHub
485 2019-02-13T16:42:33  <wumpus> (if so, is anyone working on it?)
486 2019-02-13T16:43:46  *** bitcoin-git has joined #bitcoin-core-dev
487 2019-02-13T16:43:46  <bitcoin-git> [bitcoin] ken2812221 opened pull request #15398: msvc: add rapid check property tests (master...appveyor-rapid-check) https://github.com/bitcoin/bitcoin/pull/15398
488 2019-02-13T16:43:47  *** bitcoin-git has left #bitcoin-core-dev
489 2019-02-13T16:45:14  <provoostenator> Afaik it's only a problem when there is a ginormous reorg. A fix also needs to be backported, since this issue has been around for some time.
490 2019-02-13T16:46:03  <gmaxwell> it also screws up the usability of invalidateblock/reconsider block for testing.
491 2019-02-13T16:46:16  <wumpus> yes, it's a bad issue, there's just not that much time left
492 2019-02-13T16:47:04  <wumpus> I mean, unless someone opens a PR for it in the next few days, there's very little chance for a fix to make it into 0.18
493 2019-02-13T16:47:42  <wumpus> I noticed it again because it has a 0.18.0 milestone
494 2019-02-13T16:49:27  <gmaxwell> :(
495 2019-02-13T16:49:52  <wumpus> same for #13103 unless the windows encoding changes already merged solve it
496 2019-02-13T16:49:53  <gribble> https://github.com/bitcoin/bitcoin/issues/13103 | Invalid wallet path with Chinese characters in windows · Issue #13103 · bitcoin/bitcoin · GitHub
497 2019-02-13T16:50:36  <wumpus> there's a lot of PRs to merge before 0.18 but only few of them also solve issues tagged 0.18 :o
498 2019-02-13T16:52:38  <wumpus> #13129 seems irrelevant to have tagged for 0.18
499 2019-02-13T16:52:39  <gribble> https://github.com/bitcoin/bitcoin/issues/13129 | Meta-issue: Add Clang thread safety analysis annotations · Issue #13129 · bitcoin/bitcoin · GitHub
500 2019-02-13T16:56:45  *** pbase has joined #bitcoin-core-dev
501 2019-02-13T17:03:53  *** pinheadmz has quit IRC
502 2019-02-13T17:04:40  *** jungly has quit IRC
503 2019-02-13T17:06:29  *** promag has quit IRC
504 2019-02-13T17:07:14  *** promag has joined #bitcoin-core-dev
505 2019-02-13T17:14:04  *** jarthur has joined #bitcoin-core-dev
506 2019-02-13T17:54:51  *** traizzl has joined #bitcoin-core-dev
507 2019-02-13T17:58:43  *** pinheadmz has joined #bitcoin-core-dev
508 2019-02-13T17:59:21  *** mistergold has joined #bitcoin-core-dev
509 2019-02-13T17:59:56  *** traizzl has quit IRC
510 2019-02-13T18:03:55  <provoostenator> Switching to boost::process was pretty easy (so far). Let's see if it actually works in Windows...
511 2019-02-13T18:08:24  *** phwalkr has quit IRC
512 2019-02-13T18:09:45  *** rex4539 has joined #bitcoin-core-dev
513 2019-02-13T18:14:58  *** Karyon has joined #bitcoin-core-dev
514 2019-02-13T18:19:33  <wumpus> provoostenator: that's good news, hope so!
515 2019-02-13T18:19:48  *** Randolf has quit IRC
516 2019-02-13T18:22:01  *** pbase has quit IRC
517 2019-02-13T18:24:32  <wumpus> does anyone have a CPU with rdrand/rdseed support? (it will show in /proc/cpuinfo) please help test #15250
518 2019-02-13T18:24:34  <gribble> https://github.com/bitcoin/bitcoin/issues/15250 | Use RdSeed when available, and reduce RdRand load by sipa · Pull Request #15250 · bitcoin/bitcoin · GitHub
519 2019-02-13T18:26:32  *** csknk has quit IRC
520 2019-02-13T18:26:41  <gmaxwell> or, without them. :)
521 2019-02-13T18:34:46  *** michaels_ has quit IRC
522 2019-02-13T18:34:52  <wumpus> yes that's worthwhile to test too, at least here it seems to detect the fact that the instructions aren't available correctly
523 2019-02-13T18:35:02  <sipa> wumpus: yes, it works for me :p
524 2019-02-13T18:35:04  <wumpus> I've also checked that gcc does in fact generate them
525 2019-02-13T18:35:21  <sipa> (at least, it reports "Using RdSeed as an additional randomness source")
526 2019-02-13T18:35:29  <wumpus> good!
527 2019-02-13T18:35:36  <sipa> i also have a system which supports rdrand but not rdseed
528 2019-02-13T18:35:40  <sipa> i'll test on that
529 2019-02-13T18:36:34  *** michaels_ has joined #bitcoin-core-dev
530 2019-02-13T18:40:08  *** fabianfabian has joined #bitcoin-core-dev
531 2019-02-13T18:42:08  <wumpus> TIL "This instruction was introduced in the Pentium 4 processors, but is backward compatible with all IA-32 processors. In earlier IA-32 processors, the PAUSE instruction operates like a NOP instruction."
532 2019-02-13T18:43:39  <sipa> ha
533 2019-02-13T18:43:55  <sipa> i hadn't even considered that the pause instruction might have been a compatibility issue
534 2019-02-13T18:46:02  <wumpus> :D
535 2019-02-13T18:46:13  <gmaxwell> I had.
536 2019-02-13T18:46:15  <gmaxwell> :P
537 2019-02-13T18:48:46  <wumpus> I guess it's also worth testing this on x86_32, I mean, it's quite an unlikely scenario for someone with a processor that supports these instructions to run a 32-bit OS
538 2019-02-13T18:49:15  *** ovovo has joined #bitcoin-core-dev
539 2019-02-13T18:50:22  <provoostenator> Travis is happy, but AppVeyor seems to need additional magic to find boost::process : https://ci.appveyor.com/project/DrahtBot/bitcoin/builds/22347238
540 2019-02-13T18:50:36  <provoostenator> And those logs are useless
541 2019-02-13T18:50:53  <wumpus> yeh Appveyor logs are quite useless usually
542 2019-02-13T18:51:19  <jarthur> I'm on an x86_64 macOS 10.13.6 box w/ RDRAND and RDSEED. How to test this, wumpus?
543 2019-02-13T18:51:46  <jarthur> Build sipa's branch and check the debug.log?
544 2019-02-13T18:51:58  <wumpus> jarthur: the basic thing to test would be that if you run bitcoind that you see that it's being used in the debug log
545 2019-02-13T18:52:15  <jarthur> thanks
546 2019-02-13T18:52:22  <wumpus> and ofc check if the unit tests and functional test suite pass
547 2019-02-13T18:52:48  <wumpus> I'm honestly not sure how to test reliability of random number generation otherwise
548 2019-02-13T18:53:28  *** owowo has quit IRC
549 2019-02-13T18:53:36  <jarthur> We may be able to add some entropy scoring in the functional tests if there isn't already something like that.
550 2019-02-13T18:54:59  <wumpus> there isn't, at the moment
551 2019-02-13T18:56:48  *** Karyon has quit IRC
552 2019-02-13T18:57:47  *** spinza has quit IRC
553 2019-02-13T19:06:15  *** mistergold has quit IRC
554 2019-02-13T19:10:05  <provoostenator> Looks like in Windows land you need individual vcpkg packages for each(?) boost component. We'll find out when it next runs... see e.g. how #14241 removed boost-interprocess
555 2019-02-13T19:10:07  <gribble> https://github.com/bitcoin/bitcoin/issues/14241 | appveyor: script improvement by ken2812221 · Pull Request #14241 · bitcoin/bitcoin · GitHub
556 2019-02-13T19:19:43  <wumpus> oh yes msvc windows-land is like that, mingw-w64 windows-land should just work
557 2019-02-13T19:21:26  *** bitcoin-git has joined #bitcoin-core-dev
558 2019-02-13T19:21:27  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #15399: fuzz: Script validation flags (master...Mf1902-fuzzSoft) https://github.com/bitcoin/bitcoin/pull/15399
559 2019-02-13T19:21:30  *** bitcoin-git has left #bitcoin-core-dev
560 2019-02-13T19:24:12  <sipa> wumpus: seems to work fine on rdrand-not-rdseed
561 2019-02-13T19:25:22  *** siom has quit IRC
562 2019-02-13T19:25:53  *** Aaronvan_ has quit IRC
563 2019-02-13T19:31:17  *** dviola has quit IRC
564 2019-02-13T19:33:06  *** michaels_ has quit IRC
565 2019-02-13T19:33:30  <wumpus> sipa: nice!
566 2019-02-13T19:36:21  <jarthur> Is p2p_invalid_messages.py test known to be broken on macOS? Got a Protocol wrong type for socket error.
567 2019-02-13T19:37:54  *** spinza has joined #bitcoin-core-dev
568 2019-02-13T19:40:39  <jarthur> Tested fine on rdrand-and-rdseed, either way
569 2019-02-13T19:43:46  *** AaronvanW has joined #bitcoin-core-dev
570 2019-02-13T19:44:38  <jarthur> looks like p2p_invalid_messages failure was from node closing sooner than expected and a subsequent write realizing the RST error.
571 2019-02-13T19:45:03  *** Guyver2 has joined #bitcoin-core-dev
572 2019-02-13T19:46:43  *** Apocalyptic has quit IRC
573 2019-02-13T19:48:22  *** AaronvanW has quit IRC
574 2019-02-13T19:49:20  *** Apocalyptic has joined #bitcoin-core-dev
575 2019-02-13T19:53:43  <wumpus> jarthur: on P2P? I don't think that's a known issue
576 2019-02-13T19:55:04  <wumpus> if you can reproduce it, please open an issue
577 2019-02-13T19:55:19  *** michaels_ has joined #bitcoin-core-dev
578 2019-02-13T19:57:17  <instagibbs> provoostenator, achow101  re: #14021 I suppose my performance point is moot, considering most wallet operations will take a long time if hte wallet is gigantic
579 2019-02-13T19:57:26  <instagibbs> and it'll only happen once
580 2019-02-13T19:57:35  <gribble> https://github.com/bitcoin/bitcoin/issues/14021 | Import key origin data through descriptors in importmulti by achow101 · Pull Request #14021 · bitcoin/bitcoin · GitHub
581 2019-02-13T19:57:43  <instagibbs> less stressful than running a single "listunspent"
582 2019-02-13T19:59:29  *** AaronvanW has joined #bitcoin-core-dev
583 2019-02-13T19:59:34  *** copumpkin has quit IRC
584 2019-02-13T20:01:53  <jarthur> wumpus: will do, probably tonight or tomorrow
585 2019-02-13T20:03:55  *** fabianfabian has quit IRC
586 2019-02-13T20:04:10  *** AaronvanW has quit IRC
587 2019-02-13T20:09:24  <achow101> instagibbs: while thinking about that problem. i realized that current master is also broken in the same way
588 2019-02-13T20:09:46  <instagibbs> what specifically?
589 2019-02-13T20:10:00  <achow101> CWallet::GetKeyOrigin also does the GetKey thing and if the wallet is not unlocked, it will write a bogus master key fingerprint to the psbt
590 2019-02-13T20:10:11  <instagibbs> ah
591 2019-02-13T20:10:19  <instagibbs> welp
592 2019-02-13T20:12:19  <achow101> if we do it on first unlock, a user could make a psbt that has a bogus fingerprint
593 2019-02-13T20:15:29  <achow101> i guess we could make walletprocesspsbt throw an error if the key metadata isn't updated?
594 2019-02-13T20:18:34  *** millerti has quit IRC
595 2019-02-13T20:21:19  *** pinheadmz has quit IRC
596 2019-02-13T20:22:14  *** pinheadmz has joined #bitcoin-core-dev
597 2019-02-13T20:24:21  *** promag has quit IRC
598 2019-02-13T20:24:35  *** promag has joined #bitcoin-core-dev
599 2019-02-13T20:30:38  *** AaronvanW has joined #bitcoin-core-dev
600 2019-02-13T20:31:01  <wumpus> jarthur: thanks
601 2019-02-13T20:34:32  *** marcoagner has joined #bitcoin-core-dev
602 2019-02-13T20:35:10  *** AaronvanW has quit IRC
603 2019-02-13T20:38:39  *** x4b1d has joined #bitcoin-core-dev
604 2019-02-13T20:39:25  <x4b1d> Anyone seen good code examples of offline signing outside of using bitcoind?
605 2019-02-13T20:40:56  *** promag has quit IRC
606 2019-02-13T20:41:29  <wumpus> maybe some FOSS hw wallet firmware like the trezor one?
607 2019-02-13T20:41:36  *** promag has joined #bitcoin-core-dev
608 2019-02-13T20:45:54  *** AaronvanW has joined #bitcoin-core-dev
609 2019-02-13T20:48:19  *** DeanGuss has quit IRC
610 2019-02-13T20:49:27  <achow101> wumpus: funny thing about the trezor is that the python lib's default behavior was/is(?) to call back to trezor servers to fetch prevtxs. so not offline at all!
611 2019-02-13T20:49:59  *** bitcoin-git has joined #bitcoin-core-dev
612 2019-02-13T20:50:00  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/cbe7efe9ea6c...9c4a90040dd3
613 2019-02-13T20:50:00  <bitcoin-git> bitcoin/master 318b1f7 John Newbery: [wallet] Close bdb when flushing wallet.
614 2019-02-13T20:50:01  <bitcoin-git> bitcoin/master 9c4a900 MarcoFalke: Merge #15390: [wallet-tool] Close bdb when flushing wallet
615 2019-02-13T20:50:03  *** bitcoin-git has left #bitcoin-core-dev
616 2019-02-13T20:50:38  *** AaronvanW has quit IRC
617 2019-02-13T20:50:46  *** bitcoin-git has joined #bitcoin-core-dev
618 2019-02-13T20:50:47  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15390: [wallet-tool] Close bdb when flushing wallet (master...wallet_flush) https://github.com/bitcoin/bitcoin/pull/15390
619 2019-02-13T20:50:54  *** bitcoin-git has left #bitcoin-core-dev
620 2019-02-13T20:52:51  <x4b1d> wumpus: achow101 yeah I haven't actually seen a lot of offline signing functionality anywhee that seems to conform since 2014
621 2019-02-13T20:53:42  <wumpus> achow101: fair enough, but that's also true when you use bitcoind for offline signing, you have to provide the previous outputs yourself
622 2019-02-13T20:53:49  *** Karyon has joined #bitcoin-core-dev
623 2019-02-13T20:54:25  <achow101> x4b1d: maybe have a look at armory? it's entire goal is to do offline signing
624 2019-02-13T20:55:30  <echeveria> achow101: armory is highly is advisable.
625 2019-02-13T20:55:58  <echeveria> inadvisable. it has long standing implementation issues and a history of losing money. it’s not strongly maintained.
626 2019-02-13T20:56:25  <wumpus> achow101: you can't assume anything that is offline keeps up with the chain, after all, so you basically need a watch-only wallet to keep track of the utxos
627 2019-02-13T20:57:13  <x4b1d> doesn't armory just rpc into bitcoind ?
628 2019-02-13T20:57:30  <wumpus> achow101: calling into a centralized server is kinda meh though I agree
629 2019-02-13T20:57:32  <sipa> #bitcoin
630 2019-02-13T20:57:46  <achow101> x4b1d: no. it only uses bitcoind for connection to the network
631 2019-02-13T21:02:04  <wumpus> yea #bitcoin is better for questions like this as they don't involve bitcoin core development
632 2019-02-13T21:05:48  <x4b1d> Fair, I wish that I could break the offline functions into a seperate set of libs provided by bitcoin core but yeah more ot
633 2019-02-13T21:06:02  <wumpus> well *that* would be on topic
634 2019-02-13T21:06:49  <wumpus> FWIW I think that would be a good idea
635 2019-02-13T21:07:43  <wumpus> the RPC pure utility functions (that don't need a node, wallet) could be a library
636 2019-02-13T21:07:56  <x4b1d> god I wish I had that
637 2019-02-13T21:08:20  <sipa> libwally has a bunch of functions
638 2019-02-13T21:09:30  <wumpus> yes, that one is used by clightning for example
639 2019-02-13T21:09:30  <sipa> but a standalone library/tool that can do psbt signing would be pretty nice
640 2019-02-13T21:09:31  <x4b1d> sipa: yeah I've been working with libwally. But it's opinionated to support elements and I'm at the mercy of libwally to keep the standard
641 2019-02-13T21:11:05  <x4b1d> would be so happy to see that as a development
642 2019-02-13T21:19:10  <achow101> what's up with travis? the linter target is failing since python 3.4 couldn't be downloaded
643 2019-02-13T21:19:54  <wumpus> achow101: haven't noticed yet, where is that?
644 2019-02-13T21:20:41  <achow101> https://travis-ci.org/bitcoin/bitcoin/jobs/492915824
645 2019-02-13T21:21:08  *** AaronvanW has joined #bitcoin-core-dev
646 2019-02-13T21:21:18  <wumpus> -restarted
647 2019-02-13T21:21:20  <achow101> seems to have just became a problem within the last hour
648 2019-02-13T21:21:37  <achow101> (i've tried restarting already and it didn't fix it)
649 2019-02-13T21:21:42  <wumpus> ohh
650 2019-02-13T21:22:10  <wumpus> dead python 3.4 then
651 2019-02-13T21:22:27  <achow101> rip
652 2019-02-13T21:23:36  <wumpus> Downloading archive: https://s3.amazonaws.com/travis-python-archives/binaries/ubuntu/16.04/x86_64/python-3.4.tar.bz2
653 2019-02-13T21:23:38  <wumpus> $ curl -sSf -o python-3.4.tar.bz2 ${archive_url}
654 2019-02-13T21:23:41  <wumpus> curl: (22) The requested URL returned error: 403 Forbidden
655 2019-02-13T21:25:17  <wumpus> 'forbidden' is a kind of strange error to return here, given hat it's a request from travis to travis' own archive, might be simply a access list configuration error on their end
656 2019-02-13T21:25:52  *** AaronvanW has quit IRC
657 2019-02-13T21:26:54  <wumpus> it's *before* our script takes action so nothing we can do I think
658 2019-02-13T21:27:56  <achow101> yeah... i'll contact their support
659 2019-02-13T21:29:16  <wumpus> thanks !
660 2019-02-13T21:31:05  <jarthur> AWS recently made it harder to grant public access to s3 resources. Have seen a few projects face perms issues on account of it.
661 2019-02-13T21:31:09  <jarthur> wumpus Did a little bit of due-dilligence and filed the p2p_invalid_messages issue as #15400
662 2019-02-13T21:31:10  <gribble> https://github.com/bitcoin/bitcoin/issues/15400 | p2p_invalid_messages test can fail in runner due to stderr text when socket write buffer flushed · Issue #15400 · bitcoin/bitcoin · GitHub
663 2019-02-13T21:31:32  <wumpus> jarthur: interesting
664 2019-02-13T21:32:33  <wumpus> we've certainly run into problems with this before, with tests failing simply due to unexpected stderr output
665 2019-02-13T21:34:00  <wumpus> okay this is definitely something else it happens in python itself
666 2019-02-13T21:37:21  <jarthur> Yea. Always hard to catch socket conditions that happen on writes, given Python's asyncio buffers the writes, then kernel buffers the transmission. We can tell asyncio to not buffer if kernel is letting us buffer everything, but kernels don't really give us any kind of guarantee.
667 2019-02-13T21:38:43  *** Guyver2 has quit IRC
668 2019-02-13T21:41:45  <wumpus> I'm still confused about #15140, I don't think we should be telling people to run clang-format if we're not even sure about that change
669 2019-02-13T21:41:47  <gribble> https://github.com/bitcoin/bitcoin/issues/15140 | test: fix script_p2sh_tests OP_PUSHBACK2/4 missing by kodslav · Pull Request #15140 · bitcoin/bitcoin · GitHub
670 2019-02-13T21:42:44  <wumpus> like sometimes people are told to go through iteration after iteration of small nits while it's deeply unclear if it should be merged in the first place
671 2019-02-13T21:43:03  <sipa> agree
672 2019-02-13T21:43:11  <sipa> (in general, i haven't looked at the pr)
673 2019-02-13T21:43:46  <wumpus> it's been open for a while but I think it just WTFs everyone
674 2019-02-13T21:45:42  <wumpus> (and I don't think the issue with it was indentation)
675 2019-02-13T21:47:54  *** Murch has quit IRC
676 2019-02-13T21:48:26  *** bitcoin-git has joined #bitcoin-core-dev
677 2019-02-13T21:48:26  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #15401: rpc: Actually throw help when passed invalid number of params (master...Mf1902-rpcNumArgs) https://github.com/bitcoin/bitcoin/pull/15401
678 2019-02-13T21:48:31  *** bitcoin-git has left #bitcoin-core-dev
679 2019-02-13T21:52:11  *** bitcoin-git has joined #bitcoin-core-dev
680 2019-02-13T21:52:11  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9c4a90040dd3...9c93f5d9fc93
681 2019-02-13T21:52:12  <bitcoin-git> bitcoin/master a4b92e4 Hennadii Stepanov: Log full paths for wallets
682 2019-02-13T21:52:12  <bitcoin-git> bitcoin/master 9c93f5d Wladimir J. van der Laan: Merge #15334: wallet: Log absolute paths for the wallets
683 2019-02-13T21:52:14  *** AaronvanW has joined #bitcoin-core-dev
684 2019-02-13T21:52:23  *** bitcoin-git has left #bitcoin-core-dev
685 2019-02-13T21:52:54  *** bitcoin-git has joined #bitcoin-core-dev
686 2019-02-13T21:52:54  <bitcoin-git> [bitcoin] laanwj merged pull request #15334: wallet: Log absolute paths for the wallets (master...20190203-wallet-env-log) https://github.com/bitcoin/bitcoin/pull/15334
687 2019-02-13T21:53:07  *** bitcoin-git has left #bitcoin-core-dev
688 2019-02-13T21:54:01  <wumpus> "throw help" hehe
689 2019-02-13T21:56:38  *** AaronvanW has quit IRC
690 2019-02-13T21:58:30  *** bralyclo_ has joined #bitcoin-core-dev
691 2019-02-13T21:58:31  <MarcoFalke> I don't understand what #15140 is trying to do
692 2019-02-13T21:58:33  <gribble> https://github.com/bitcoin/bitcoin/issues/15140 | test: fix script_p2sh_tests OP_PUSHBACK2/4 missing by kodslav · Pull Request #15140 · bitcoin/bitcoin · GitHub
693 2019-02-13T21:58:46  <wumpus> same
694 2019-02-13T21:59:03  <MarcoFalke> A comment with "//---------><----- cut here"
695 2019-02-13T21:59:37  * MarcoFalke takes scissors and cuts the monitor
696 2019-02-13T21:59:52  <wumpus> I mean I'm slightly worried that there's an actual problem (whether they address it in the fix or not, I don't know) otherwise I'd have closed it already
697 2019-02-13T22:01:05  *** skyikot has joined #bitcoin-core-dev
698 2019-02-13T22:01:19  <sipa> oh, i get it
699 2019-02-13T22:01:32  <sipa> the test is broken
700 2019-02-13T22:01:44  *** elichai2 has joined #bitcoin-core-dev
701 2019-02-13T22:01:54  *** bralyclow has quit IRC
702 2019-02-13T22:02:15  <wumpus> oh!
703 2019-02-13T22:02:17  <sipa> it's testing that pushing a script hash using the OP_PUSHDATA opcodes doesn't cause it to be detected as P2SH (because BIP16 gives the exact encoding)
704 2019-02-13T22:02:40  <sipa> but the OP_PUSHDATA2 and OP_PUSHDATA4 opcodes are missing from the test; so they correctly fail, but for the wrong reason
705 2019-02-13T22:02:47  <sipa> and the cut thing is because he gives 2 versions
706 2019-02-13T22:03:28  <wumpus> that's where it gets confusing
707 2019-02-13T22:03:58  *** spinza has quit IRC
708 2019-02-13T22:04:06  <wumpus> if the opcodes are missing, the fix would seem to be to add the opcodes, not duplicate the entire test
709 2019-02-13T22:04:28  <sipa> that's what his first version does
710 2019-02-13T22:04:40  <wumpus> right
711 2019-02-13T22:13:32  <wumpus> so that would seem to be enough
712 2019-02-13T22:23:56  <wumpus>  #15257 really has a crapload of changes just to make the new version of the python linter happy
713 2019-02-13T22:23:58  <gribble> https://github.com/bitcoin/bitcoin/issues/15257 | Scripts and tools: Bump flake8 to 3.6.0 by Empact · Pull Request #15257 · bitcoin/bitcoin · GitHub
714 2019-02-13T22:29:44  <achow101> travis seems to have fixed itself
715 2019-02-13T22:30:08  <wumpus> good, problems that fix themselves just by waiting are the best
716 2019-02-13T22:31:03  *** spinza has joined #bitcoin-core-dev
717 2019-02-13T22:32:17  <wumpus> hopefully it's not a transient issue that will come back, e.g. because of changing IP
718 2019-02-13T22:33:29  *** AaronvanW has joined #bitcoin-core-dev
719 2019-02-13T22:33:44  *** shesek`` has joined #bitcoin-core-dev
720 2019-02-13T22:39:31  <jarthur> Empact: re the runtime \n embedding, should this literal now be a raw-string or escaped slash?: https://github.com/bitcoin/bitcoin/pull/15257/files#diff-dc87c4c96fc5f98c3734a2c16504eb30R88 I only ask since it replaced ones you had changed to be raw in earlier version of the PR.
721 2019-02-13T22:40:24  *** michaels_ has quit IRC
722 2019-02-13T22:44:01  *** mistergold has joined #bitcoin-core-dev
723 2019-02-13T22:50:01  *** michaels_ has joined #bitcoin-core-dev
724 2019-02-13T22:54:24  *** michaels_ has quit IRC
725 2019-02-13T22:54:46  *** promag has quit IRC
726 2019-02-13T22:54:59  *** promag has joined #bitcoin-core-dev
727 2019-02-13T23:00:21  *** skyikot has quit IRC
728 2019-02-13T23:06:22  <MarcoFalke> Eh, the travis issue (failed to fetch  py3.4) is transient
729 2019-02-13T23:06:29  <MarcoFalke> I've seen it for weeks
730 2019-02-13T23:07:09  <wumpus> we both tried restarting and that didn't solve it
731 2019-02-13T23:18:33  <wumpus> could be that simply restarting doesn't re-assign the ip
732 2019-02-13T23:19:34  *** mave has joined #bitcoin-core-dev
733 2019-02-13T23:19:37  <mave> hi
734 2019-02-13T23:19:41  <jarthur> 'lo
735 2019-02-13T23:20:33  <mave> noob question, I've deleted $HOME/.bitcoin/, how does bitcoin-qt know where to find my other datadir correctly? (it does to my surprise)
736 2019-02-13T23:20:47  <mryandao> you have to tell it
737 2019-02-13T23:20:59  <mryandao> or it creates a new $HOME/.bitcoin/
738 2019-02-13T23:21:14  <mave> I'm not telling it and it's finding my /disco-dos/bitcoin-data/ directory :o
739 2019-02-13T23:21:26  <mave> I'm confused as to how
740 2019-02-13T23:21:28  <mryandao> o.O
741 2019-02-13T23:21:39  <mave> I just start it up with bitcoin-qt
742 2019-02-13T23:21:46  <mave> with an empty $HOME/.bitcoin
743 2019-02-13T23:21:56  <mave> and it correctly finds my datadir
744 2019-02-13T23:21:57  <jarthur> What platform? And is it in finding the wallet in there? Blockchain data, all of the above?
745 2019-02-13T23:22:05  <mave> ubuntu
746 2019-02-13T23:22:14  <mave> bitcoind
747 2019-02-13T23:22:21  <mave> compiled from source recently
748 2019-02-13T23:22:52  <mave> yes, it is finding everything correctly (which is unexpected as I deleted $HOME/.bitcoin on purpose)
749 2019-02-13T23:22:59  <luke-jr> mave: bitcoind or bitcoin-qt?
750 2019-02-13T23:23:14  <mave> I compiled both
751 2019-02-13T23:23:19  <luke-jr> which are you using?
752 2019-02-13T23:23:22  <mave> the one that's surprising me is bitcoin-qt
753 2019-02-13T23:23:35  <luke-jr> cat ~/.config/Bitcoin/Bitcoin-Qt.conf
754 2019-02-13T23:23:36  <mave> for this use case it's bitcoin-qt
755 2019-02-13T23:24:26  <mave> aah, so it has a different set of config files
756 2019-02-13T23:24:49  <mave> I thought it would read from $HOME/.bitcoin/bitcoin.conf
757 2019-02-13T23:25:04  <luke-jr> it will read that too
758 2019-02-13T23:25:15  <luke-jr> well, if $HOME/.bitcoin is your datadir ;)
759 2019-02-13T23:25:33  <mave> my datadir I specify manually when starting bitcoind
760 2019-02-13T23:25:41  <mave> but I don't when starting bitcoin-qt
761 2019-02-13T23:25:42  *** michaels_ has joined #bitcoin-core-dev
762 2019-02-13T23:25:54  <mave> hence my surprise to see that bitcoin-qt could find my datadir
763 2019-02-13T23:26:39  <mave> I now understand that bitcoin-qt has some other set of config files under $HOME/.config/Bitcoin
764 2019-02-13T23:26:51  <mave> however looking into them I don't find any pointer to my datadir
765 2019-02-13T23:28:17  <jarthur> What do you see for "Default data directory" and "Using data directory" in debug.log for the -Qt session?
766 2019-02-13T23:29:32  *** DeanGuss has joined #bitcoin-core-dev
767 2019-02-13T23:30:23  <mave> Default data directory /home/roge/.bitcoin
768 2019-02-13T23:30:40  *** michaels_ has quit IRC
769 2019-02-13T23:31:06  <mave> which is my $HOME/.bitcoin
770 2019-02-13T23:31:13  <mave> and is different from my datadir
771 2019-02-13T23:32:48  *** timothy has quit IRC
772 2019-02-13T23:33:20  *** murrayn has joined #bitcoin-core-dev
773 2019-02-13T23:33:20  *** murrayn has joined #bitcoin-core-dev
774 2019-02-13T23:33:32  * mave sits back
775 2019-02-13T23:35:22  <jarthur> So it says "Using data directory /disco-dos/bitcoin-data/" shortly after that?
776 2019-02-13T23:35:22  <luke-jr> [23:28:17] <jarthur> What do you see for "Default data directory" and "Using data directory" in debug.log for the -Qt session?
777 2019-02-13T23:35:39  <mave> 2019-02-13 23:34:57 Bitcoin Core version v0.16.0 (release build)                 2019-02-13 23:34:57 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1 2019-02-13 23:34:57 Assuming ancestors of block 0000000002e9e7b00e1f6dc5123a04aad68dd0f0968d8c7aa45f6640795c37b1 have valid signatures. 2019-02-13 23:34:57 Setting nMinimumChainWork=00000000000000000000000000000000000000000000002
778 2019-02-13T23:36:21  <mave> 2019-02-13 23:34:57 Bitcoin Core version v0.16.0 (release build)
779 2019-02-13T23:36:31  <mave> 2019-02-13 23:34:57 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
780 2019-02-13T23:36:38  <mave> 2019-02-13 23:34:57 Assuming ancestors of block 0000000002e9e7b00e1f6dc5123a04aad68dd0f0968d8c7aa45f6640795c37b1 have valid signatures.
781 2019-02-13T23:36:45  <mave> 2019-02-13 23:34:57 Setting nMinimumChainWork=00000000000000000000000000000000000000000000002830dab7f76dbb7d63
782 2019-02-13T23:36:51  <mave> 2019-02-13 23:34:57 Using the 'sse4' SHA256 implementation
783 2019-02-13T23:36:57  <mave> 2019-02-13 23:34:57 Using RdRand as an additional entropy source
784 2019-02-13T23:37:04  <mave> 2019-02-13 23:34:57 Default data directory /home/roge/.bitcoin
785 2019-02-13T23:37:11  <mave> 2019-02-13 23:34:57 Using data directory /disco-dos/bitcoin-data/testnet3
786 2019-02-13T23:37:18  <mave> 2019-02-13 23:34:57 Using config file /disco-dos/bitcoin-data/bitcoin.conf
787 2019-02-13T23:37:41  <mave> it says it's using /home/roge/.bitcoin  as default data dir
788 2019-02-13T23:37:41  <sipa> mave: please don't spam the channel
789 2019-02-13T23:37:45  <mave> this dir is empty
790 2019-02-13T23:38:09  <sipa> copy-pasting more than 3 lines is considered impolite on IRC
791 2019-02-13T23:38:13  <mave> @sipa, sorry, I'm new here
792 2019-02-13T23:38:40  <mave> I just wanted to answer luke-jr's question
793 2019-02-13T23:38:42  *** Aaronva__ has joined #bitcoin-core-dev
794 2019-02-13T23:38:54  <sipa> mave: ok, use a pastebin site next time
795 2019-02-13T23:39:05  <promag> use https://pastebin.com/
796 2019-02-13T23:39:08  <luke-jr> I only asked for 2 lines -.-
797 2019-02-13T23:39:34  <mave> so, the debug.log says it's using as default data dir /home/roge/.bitcoin which is empty on purpose
798 2019-02-13T23:39:57  <mave> and on the next debug.log line it says it's using as datadir /disco-dos/bitcoin-data/testnet3 which is correct
799 2019-02-13T23:40:04  <jarthur> Alright, how are you opening Bitcoin-Qt, and are you passing it that conf file at the command line?
800 2019-02-13T23:40:27  <mave> nope, I'm running it from shell just using the command bitcoin-qt, no params
801 2019-02-13T23:40:38  *** AaronvanW has quit IRC
802 2019-02-13T23:41:05  <sipa> is the datadir maybe stored in the Qt config?
803 2019-02-13T23:41:48  <mave> there is no qt-config that I am aware of aside from bitcoin.conf
804 2019-02-13T23:42:26  <sipa> bitcoin-qt has its own config, but i don't know the details
805 2019-02-13T23:43:18  <luke-jr> sipa: assuming you mean ~/.config/Bitcoin/Bitcoin-Qt.conf , he said he already checked it
806 2019-02-13T23:43:30  <sipa> ah
807 2019-02-13T23:43:32  <sipa> yes
808 2019-02-13T23:43:41  <mave> yes, I checked those files and there is no ref to my datadir
809 2019-02-13T23:44:51  <mave> never mind
810 2019-02-13T23:44:54  <mave> I found it
811 2019-02-13T23:44:56  <luke-jr> where?
812 2019-02-13T23:45:01  <mave> you were right luke-jr
813 2019-02-13T23:45:13  <mave> grep disco-dos * found it for me
814 2019-02-13T23:45:18  <mave> it was as you said
815 2019-02-13T23:45:27  <mave> under .config/Bitcoin/Bitcoin-QT.conf
816 2019-02-13T23:45:35  <mave> strDataDir=
817 2019-02-13T23:45:41  <mave> mistery solved :)
818 2019-02-13T23:45:41  <jarthur> Cool. I hate mysteries.
819 2019-02-13T23:45:51  <luke-jr> I was about to suggest strace <.<
820 2019-02-13T23:45:56  <mave> haha
821 2019-02-13T23:46:11  <mave> thanks for the welcome help
822 2019-02-13T23:46:15  <promag> jarthur: The End
823 2019-02-13T23:46:25  <mave> cool irc channel :)
824 2019-02-13T23:47:22  *** mistergold has quit IRC
825 2019-02-13T23:47:47  <jarthur> :)
826 2019-02-13T23:59:17  *** mave has quit IRC