12019-02-13T00:05:10 <moneyball> does anyone know how to find all open PRs that modify a particular file (ie validation.cpp)?
22019-02-13T00:06:17 <pinheadmz> github you can view history of a single file
32019-02-13T00:06:21 <pinheadmz> or check the "blame"
42019-02-13T00:10:28 *** DeanGuss has joined #bitcoin-core-dev
52019-02-13T00:32:46 *** booyah_ has quit IRC
62019-02-13T00:33:41 *** rhavar_ has joined #bitcoin-core-dev
72019-02-13T00:33:44 *** booyah_ has joined #bitcoin-core-dev
82019-02-13T00:34:03 *** rhavar_ has quit IRC
92019-02-13T00:34:22 *** rhavar_ has joined #bitcoin-core-dev
102019-02-13T00:35:09 *** rhavar_ has quit IRC
112019-02-13T00:35:42 *** jarthur has quit IRC
122019-02-13T00:36:07 *** rhavar has joined #bitcoin-core-dev
132019-02-13T00:38:48 *** booyah_ has quit IRC
142019-02-13T00:39:34 *** booyah_ has joined #bitcoin-core-dev
152019-02-13T00:39:37 *** DeanGuss has quit IRC
162019-02-13T00:42:53 <moneyball> pinheadmz thanks but that only shows history/merged PRs and not open PRs, right?
172019-02-13T00:44:41 <booyah_> why bitcoin uses ECDSA on secp256k1 instead of Ed25519, any arguments for/against?
182019-02-13T00:47:41 *** Karyon has quit IRC
192019-02-13T00:48:16 <sipa> booyah_: ask satoshi
202019-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
212019-02-13T00:50:11 <sipa> (and probably more on topic in #bitcoin-wizards)
222019-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?
232019-02-13T00:54:02 <sipa> i don't see good reasons to change it
242019-02-13T00:54:14 <MarcoFalke> moneyball: could be an idea for bitcoinacks by pierre_rochard
252019-02-13T00:54:34 <sipa> booyah_: it would be slower, introduce new review burden, and any change of that kind is risky
262019-02-13T00:54:41 <gmaxwell> ed25519 is unambigiously less secure too, though not in an amount that would matter.
272019-02-13T00:55:03 <sipa> by about 1-1.5 bits or so, yeah
282019-02-13T00:55:40 <gmaxwell> and re cofactor, several cryptocurrencies have had serious vulnerabilities due to using ed25519.
292019-02-13T00:56:09 <gmaxwell> E.g. monero/cryptonote/etc. had an unbounded inflation bug due to cofactor handling.
302019-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.
312019-02-13T00:58:28 <sipa> https://twitter.com/hdevalence/status/1093684731500146688
322019-02-13T00:59:18 <booyah_> gmaxwell: which attack works on ed25519 but not on secp?
332019-02-13T00:59:59 <sipa> booyah_: i would hope none!
342019-02-13T01:00:12 <sipa> it's just harder to get complex protocols on top right
352019-02-13T01:00:46 <gmaxwell> booyah_: cofactor attacks, as I mentioned.
362019-02-13T01:00:48 <sipa> ed25519 is a digital signature system, and when used as just that - it's perfectly fine
372019-02-13T01:01:39 <sipa> but something like bip32 is already somewhat harder to do for ed25519
382019-02-13T01:02:37 <gmaxwell> and ... has been done wrong multiple times.
392019-02-13T01:05:04 *** booyah_ is now known as booyah
402019-02-13T01:12:11 *** Karyon has joined #bitcoin-core-dev
412019-02-13T01:15:26 *** pinheadmz has quit IRC
422019-02-13T01:17:49 <echeveria> people generally misunderstand that ed25519 is not a single show signature, due to the marketing.
432019-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.
442019-02-13T01:18:52 <sipa> i think you mean "unique" instead of "single show"
452019-02-13T01:18:58 *** davec has quit IRC
462019-02-13T01:20:25 <booyah> what is single show signature?
472019-02-13T01:20:36 *** davec has joined #bitcoin-core-dev
482019-02-13T01:20:53 <sipa> a signature that leaks the private key as soon as you sign two different messages with the same key
492019-02-13T01:21:36 <echeveria> sipa: yeah, wrong terminology I think.
502019-02-13T01:21:59 <sipa> a unique signature is one where every message/pubkey pair has exactly one valid signature
512019-02-13T01:22:19 <booyah> hmm?? ed25519 (nor secp256k1) are not single-show right? lamport is
522019-02-13T01:22:57 <sipa> correct
532019-02-13T01:23:10 <sipa> which is why i think echeveria meant unique signature, not single show
542019-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.
552019-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)
562019-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.
572019-02-13T01:27:20 <booyah> what would be signature being unique, and being deterministic, in this context?
582019-02-13T01:27:38 <booyah> deterministic = for same cleartext, and same privkey, it produces identical signature?
592019-02-13T01:27:43 <sipa> deterministic is a property of a signing implementation, not a property of the signature scheme
602019-02-13T01:27:57 <sipa> unique means that the only possible implementation is deterministic
612019-02-13T01:28:12 <sipa> BLS for example is unique
622019-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.
632019-02-13T01:29:20 <sipa> wellll.... (/me wonders off into ZKP land)
642019-02-13T01:29:34 <booyah> echeveria: neat. makes sense
652019-02-13T01:32:03 *** IGHOR has quit IRC
662019-02-13T01:35:18 *** IGHOR has joined #bitcoin-core-dev
672019-02-13T01:45:04 *** Karyon has quit IRC
682019-02-13T01:50:09 *** twistedline_ has quit IRC
692019-02-13T01:57:06 *** AaronvanW has quit IRC
702019-02-13T02:15:38 *** pinheadmz has joined #bitcoin-core-dev
712019-02-13T02:33:03 *** twistedline has joined #bitcoin-core-dev
722019-02-13T02:34:20 *** twistedline has quit IRC
732019-02-13T02:47:35 *** Karyon has joined #bitcoin-core-dev
742019-02-13T02:58:01 *** pinheadmz has quit IRC
752019-02-13T03:21:02 *** pinheadmz has joined #bitcoin-core-dev
762019-02-13T03:22:06 *** jasonzhouu has quit IRC
772019-02-13T03:24:00 *** jasonzhouu has joined #bitcoin-core-dev
782019-02-13T03:36:59 *** pinheadmz has quit IRC
792019-02-13T03:41:26 *** Murch has quit IRC
802019-02-13T03:43:48 *** DeanGuss has joined #bitcoin-core-dev
812019-02-13T03:51:25 *** Karyon has quit IRC
822019-02-13T03:57:09 *** sakalli_ has joined #bitcoin-core-dev
832019-02-13T03:59:32 *** sakalli_ has quit IRC
842019-02-13T04:00:11 *** jimmysong has joined #bitcoin-core-dev
852019-02-13T04:00:16 *** jimmysong_ has joined #bitcoin-core-dev
862019-02-13T04:09:37 *** spinza has quit IRC
872019-02-13T04:14:55 *** spinza has joined #bitcoin-core-dev
882019-02-13T04:17:08 *** shesek`` has quit IRC
892019-02-13T04:34:16 *** kallewoof has joined #bitcoin-core-dev
902019-02-13T04:45:07 *** pinheadmz has joined #bitcoin-core-dev
912019-02-13T05:03:48 *** shesek`` has joined #bitcoin-core-dev
922019-02-13T05:06:10 *** sakalli_ has joined #bitcoin-core-dev
932019-02-13T05:08:39 *** sakalli_ has quit IRC
942019-02-13T05:26:21 *** skyikot has quit IRC
952019-02-13T05:45:20 *** pinheadmz has quit IRC
962019-02-13T05:52:55 *** StopAndDecrypt has quit IRC
972019-02-13T06:06:33 *** bralyclo_ has joined #bitcoin-core-dev
982019-02-13T06:10:18 *** bralyclow has quit IRC
992019-02-13T06:18:53 *** pinheadmz has joined #bitcoin-core-dev
1002019-02-13T06:33:42 *** jtimon has quit IRC
1012019-02-13T06:35:23 *** pinheadmz has quit IRC
1022019-02-13T06:41:17 *** pinheadmz has joined #bitcoin-core-dev
1032019-02-13T06:55:31 *** rex4539 has quit IRC
1042019-02-13T06:56:52 *** pinheadmz has quit IRC
1052019-02-13T06:57:40 *** Randolf has quit IRC
1062019-02-13T07:38:32 *** bitcoin-git has joined #bitcoin-core-dev
1072019-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
1082019-02-13T07:38:39 *** bitcoin-git has left #bitcoin-core-dev
1092019-02-13T07:42:30 *** pinheadmz has joined #bitcoin-core-dev
1102019-02-13T07:44:49 *** pinheadmz has quit IRC
1112019-02-13T07:46:08 *** jimmysong has quit IRC
1122019-02-13T07:48:20 *** jimmysong has joined #bitcoin-core-dev
1132019-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.
1142019-02-13T08:12:38 *** rhavar has quit IRC
1152019-02-13T08:17:15 <promag> review beg in #15195
1162019-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
1172019-02-13T08:17:54 <promag> this one is really small
1182019-02-13T08:19:43 <promag> maybe add it to hp
1192019-02-13T08:19:46 *** promag has quit IRC
1202019-02-13T08:54:03 *** niska has quit IRC
1212019-02-13T08:59:13 *** niska has joined #bitcoin-core-dev
1222019-02-13T09:03:57 *** ghost43 has quit IRC
1232019-02-13T09:06:43 *** niska has quit IRC
1242019-02-13T09:08:38 *** setpill has joined #bitcoin-core-dev
1252019-02-13T09:09:21 *** ghost43 has joined #bitcoin-core-dev
1262019-02-13T09:12:01 *** rh0nj has quit IRC
1272019-02-13T09:13:08 *** rh0nj has joined #bitcoin-core-dev
1282019-02-13T09:17:58 *** niska has joined #bitcoin-core-dev
1292019-02-13T09:32:40 *** timothy has joined #bitcoin-core-dev
1302019-02-13T09:34:30 *** jungly has joined #bitcoin-core-dev
1312019-02-13T09:44:40 *** Karyon has joined #bitcoin-core-dev
1322019-02-13T09:47:28 <gwillen> the wallet unloading logic is uh, intricate
1332019-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.
1342019-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
1352019-02-13T09:55:07 *** TX1683 has quit IRC
1362019-02-13T09:56:57 *** TX1683 has joined #bitcoin-core-dev
1372019-02-13T10:01:38 *** spinza has quit IRC
1382019-02-13T10:04:03 *** Randolf has joined #bitcoin-core-dev
1392019-02-13T10:04:41 *** promag has joined #bitcoin-core-dev
1402019-02-13T10:09:25 *** spinza has joined #bitcoin-core-dev
1412019-02-13T10:27:08 *** phwalkr has quit IRC
1422019-02-13T10:29:14 *** phwalkr has joined #bitcoin-core-dev
1432019-02-13T10:29:50 *** phwalkr has quit IRC
1442019-02-13T10:33:27 *** phwalkr has joined #bitcoin-core-dev
1452019-02-13T10:39:37 *** Karyon has quit IRC
1462019-02-13T11:06:19 *** phwalkr has quit IRC
1472019-02-13T11:14:23 *** promag has quit IRC
1482019-02-13T11:30:07 *** AaronvanW has joined #bitcoin-core-dev
1492019-02-13T11:32:19 *** murrayn has quit IRC
1502019-02-13T11:33:09 *** siom has joined #bitcoin-core-dev
1512019-02-13T11:55:36 *** phwalkr has joined #bitcoin-core-dev
1522019-02-13T12:02:58 *** Randolf has quit IRC
1532019-02-13T12:03:23 *** Randolf has joined #bitcoin-core-dev
1542019-02-13T12:04:42 *** phwalkr has quit IRC
1552019-02-13T12:07:59 *** phwalkr has joined #bitcoin-core-dev
1562019-02-13T12:08:41 *** setpill has quit IRC
1572019-02-13T12:09:01 *** setpill has joined #bitcoin-core-dev
1582019-02-13T12:18:27 *** promag has joined #bitcoin-core-dev
1592019-02-13T12:20:12 *** phwalkr_ has joined #bitcoin-core-dev
1602019-02-13T12:21:49 *** phwalkr has quit IRC
1612019-02-13T12:23:02 *** phwalkr has joined #bitcoin-core-dev
1622019-02-13T12:26:30 *** phwalkr_ has quit IRC
1632019-02-13T12:40:00 *** phwalkr_ has joined #bitcoin-core-dev
1642019-02-13T12:43:36 *** phwalkr has quit IRC
1652019-02-13T12:44:55 *** phwalkr_ has quit IRC
1662019-02-13T12:45:26 *** phwalkr has joined #bitcoin-core-dev
1672019-02-13T12:53:58 *** spinza has quit IRC
1682019-02-13T12:56:36 *** phwalkr_ has joined #bitcoin-core-dev
1692019-02-13T12:57:24 *** phwalkr_ has joined #bitcoin-core-dev
1702019-02-13T12:59:38 *** phwalkr has quit IRC
1712019-02-13T13:01:54 *** phwalkr_ has quit IRC
1722019-02-13T13:03:28 *** phwalkr has joined #bitcoin-core-dev
1732019-02-13T13:04:36 *** phwalkr_ has joined #bitcoin-core-dev
1742019-02-13T13:07:55 *** phwalkr has quit IRC
1752019-02-13T13:08:58 *** phwalkr_ has quit IRC
1762019-02-13T13:11:54 *** spinza has joined #bitcoin-core-dev
1772019-02-13T13:14:31 *** promag has quit IRC
1782019-02-13T13:46:11 *** promag has joined #bitcoin-core-dev
1792019-02-13T13:50:27 *** promag has quit IRC
1802019-02-13T13:53:32 *** csknk has joined #bitcoin-core-dev
1812019-02-13T14:04:33 *** bralyclow has joined #bitcoin-core-dev
1822019-02-13T14:07:46 *** bralyclo_ has quit IRC
1832019-02-13T14:16:20 *** paulje has joined #bitcoin-core-dev
1842019-02-13T14:16:43 *** zander has joined #bitcoin-core-dev
1852019-02-13T14:17:32 *** paulje has quit IRC
1862019-02-13T14:17:40 *** zander has quit IRC
1872019-02-13T14:24:16 *** promag has joined #bitcoin-core-dev
1882019-02-13T14:26:02 *** bitcoin-git has joined #bitcoin-core-dev
1892019-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
1902019-02-13T14:26:14 *** bitcoin-git has left #bitcoin-core-dev
1912019-02-13T14:32:18 *** phwalkr has joined #bitcoin-core-dev
1922019-02-13T14:42:11 *** jtimon has joined #bitcoin-core-dev
1932019-02-13T14:46:30 *** promag has quit IRC
1942019-02-13T14:47:14 *** jio has joined #bitcoin-core-dev
1952019-02-13T14:47:14 *** promag has joined #bitcoin-core-dev
1962019-02-13T14:52:48 *** bitcoin-git has joined #bitcoin-core-dev
1972019-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
1982019-02-13T14:52:50 *** bitcoin-git has left #bitcoin-core-dev
1992019-02-13T14:53:35 *** shesek`` has quit IRC
2002019-02-13T14:56:24 *** bralyclow has quit IRC
2012019-02-13T14:57:37 <luke-jr> provoostenator: cpp-subprocess doesn't seem to be available on Gentoo at all, FWIW
2022019-02-13T14:57:57 <luke-jr> easily changed, but I'd check availability in Debian/RHEL since those are slower
2032019-02-13T14:58:11 <provoostenator> Why? It's included as a subtree.
2042019-02-13T14:58:51 <wumpus> should probably be configurable whether to use the OS-installed one or the subtree
2052019-02-13T14:59:42 <wumpus> unless we require a specifically patched version like with tinyformat
2062019-02-13T15:01:04 <promag> I still don´t understand how can cpp-subprocess be an option without win support
2072019-02-13T15:01:37 <wumpus> why no win support?
2082019-02-13T15:02:02 <wumpus> is it impossible? or just no one had the time or motivation to write it yet
2092019-02-13T15:02:39 <promag> I guess so
2102019-02-13T15:02:41 <wumpus> after the walletnotify escaping issue I'm kind of sad about any kind of external process support
2112019-02-13T15:03:08 <wumpus> though at least that problem is avoided by passing the data via stdin/stdout and not the command line :<
2122019-02-13T15:03:14 *** ccook_ is now known as ccook
2132019-02-13T15:04:27 <promag> wumpus: that makes sense when you "pipe" to the subprocess
2142019-02-13T15:04:43 <promag> I really like the idea of env vars
2152019-02-13T15:05:27 <luke-jr> provoostenator: it should not be included as a subtree
2162019-02-13T15:05:41 <wumpus> piping is definitely preferable for any significant amount of data, certainly if it's supposed to be binary clean
2172019-02-13T15:06:19 <wumpus> but environment variables can be useful for some things, sure
2182019-02-13T15:06:37 <luke-jr> subtrees are a bad practice
2192019-02-13T15:07:10 <promag> wumpus: exactly, and don't require changing the conf, only the script
2202019-02-13T15:07:17 <gmaxwell> what is using cpp-subprocess?
2212019-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.
2222019-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());
2232019-02-13T15:08:15 <wumpus> gmaxwell: #15382
2242019-02-13T15:08:16 <luke-jr> provoostenator: maybe there isn't - that would be a reason not to use it
2252019-02-13T15:08:17 <gribble> https://github.com/bitcoin/bitcoin/issues/15382 | WIP [util] add runCommandParseJSON by Sjors · Pull Request #15382 · bitcoin/bitcoin · GitHub
2262019-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.
2272019-02-13T15:09:18 <provoostenator> But if boost:process already works with Windows I will probably switch to that anyway.
2282019-02-13T15:09:24 <gmaxwell> welp jgarzik on that pr. pressing close. best of luck to you.
2292019-02-13T15:09:49 <promag> ?
2302019-02-13T15:10:04 <wumpus> the biggest criterion is "please don't introduce any security bugs"
2312019-02-13T15:10:22 <luke-jr> biggest criterion != only criterion
2322019-02-13T15:10:35 <promag> another one: use stable dependencies?
2332019-02-13T15:11:27 <gmaxwell> more like avoid dependencies entirely, unless they provide a lot of value.
2342019-02-13T15:12:12 <luke-jr> dependencies > NIH reinvention
2352019-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.
2362019-02-13T15:12:17 <gmaxwell> (with 'a lot' depending on how universally used they are.)
2372019-02-13T15:12:24 <gmaxwell> provoostenator: yeah
2382019-02-13T15:12:37 <provoostenator> You'd think 40+ years of C development would have solved that...
2392019-02-13T15:13:18 <luke-jr> well, commands are inherently external to C
2402019-02-13T15:13:20 <luke-jr> iirc
2412019-02-13T15:13:28 <wumpus> provoostenator: +100
2422019-02-13T15:13:48 <wumpus> so rust implementation of bitcoin core when?
2432019-02-13T15:14:05 <luke-jr> Rust compiler that can be safely bootstrapped when? :/
2442019-02-13T15:14:49 <luke-jr> I guess the problem with popen is Windows
2452019-02-13T15:15:18 <rafalcpp> provoostenator: well you can just run command easily, but boost process just handles more options in it
2462019-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?
2472019-02-13T15:15:40 <luke-jr> boost::process is newer than our current minimum version it seems; wonder if we can just bump it
2482019-02-13T15:15:43 <wumpus> gmaxwell: was about to say that
2492019-02-13T15:16:13 <wumpus> so can boost::process do the required thing on windows?
2502019-02-13T15:16:32 <wumpus> I kind of hate to introduce a new boost dependency but I think I hate the alternative even more
2512019-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.
2522019-02-13T15:16:55 <wumpus> right
2532019-02-13T15:17:03 <wumpus> especially as boost tends to be picked up in future c++
2542019-02-13T15:17:14 <gmaxwell> Also there is at least some chance that the boost thing shows up in C++24 or whatever.
2552019-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)
2562019-02-13T15:17:49 <rafalcpp> what do you require of bp?
2572019-02-13T15:18:03 <luke-jr> boost::process is new in 1.64.0; Debian is at 1.62 :/
2582019-02-13T15:18:15 <provoostenator> rafacpp: run a command, process its std::out
2592019-02-13T15:18:31 <rafalcpp> wait I think I did that in debian stable
2602019-02-13T15:18:40 <provoostenator> (and parse that if it's valid JSON, otherwise fail)
2612019-02-13T15:18:41 <luke-jr> RHEL is at 1.53 x.x
2622019-02-13T15:19:09 <wumpus> eh that JSON parsing we can handle ourselves
2632019-02-13T15:19:22 <wumpus> the depenency just needs to be able to provide stdin data and give us stdout data
2642019-02-13T15:19:22 <provoostenator> wumpus: correct, UniValue does that
2652019-02-13T15:19:38 <wumpus> like python's subprocess has been able to do, what, 20 years?
2662019-02-13T15:19:49 <provoostenator> Yes
2672019-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.
2682019-02-13T15:20:21 <provoostenator> *evil
2692019-02-13T15:20:24 <wumpus> oh no
2702019-02-13T15:20:41 <wumpus> we're going do this properly or not at all
2712019-02-13T15:20:56 <provoostenator> Indeed. And it shouldn't be that hard.
2722019-02-13T15:21:25 <provoostenator> The test suite uses a hack along these lines to the notification code by the way.
2732019-02-13T15:21:31 <provoostenator> But that's just a test suite.
2742019-02-13T15:21:33 <wumpus> that's fine
2752019-02-13T15:21:35 *** bralyclow has joined #bitcoin-core-dev
2762019-02-13T15:21:35 <wumpus> right
2772019-02-13T15:22:03 <luke-jr> https://github.com/eidheim/tiny-process-library might be another option, but also no packages it seems
2782019-02-13T15:22:11 <wumpus> and maybe that can be replaced too when have a way to do it better
2792019-02-13T15:22:47 <promag> one important thing, that we don't handle right, is thread safety - boost::process isn't thread safe also
2802019-02-13T15:22:56 <wumpus> promag: what???
2812019-02-13T15:23:00 <luke-jr> ^
2822019-02-13T15:23:03 <gmaxwell> what do you mean by "thread safe" in this context?
2832019-02-13T15:23:18 <wumpus> making new processes should be about the most thread safe thing ever
2842019-02-13T15:23:23 <promag> we launch a thread that will call system(cmd)
2852019-02-13T15:23:29 <promag> this is not thread safe
2862019-02-13T15:23:36 <wumpus> how is it not?
2872019-02-13T15:24:24 <promag> iiuc it can mess file descriptors of one process to other if concurrent systems are called?
2882019-02-13T15:25:11 <gmaxwell> system() is prefertly multithread safe.
2892019-02-13T15:25:19 <rafalcpp> Stroustrup *invents C++*
2902019-02-13T15:25:38 <rafalcpp> 40 years passes. hEy guYs mayBE we shOUld have clAssEs to do ProcESSes and shit
2912019-02-13T15:25:53 <gmaxwell> (at least the C function is)
2922019-02-13T15:25:54 <luke-jr> I'm shocked there isn't an obviously good solution to this
2932019-02-13T15:26:32 <rafalcpp> maybe reimplement mininmal version of boost process and include it
2942019-02-13T15:26:50 *** michaels_ has joined #bitcoin-core-dev
2952019-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)
2962019-02-13T15:27:08 <promag> gmaxwell: I read different opinions, I don't have deep knowledge here
2972019-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
2982019-02-13T15:27:44 <promag> https://stackoverflow.com/questions/13471489/is-it-safe-to-call-system3-from-multi-threaded-process
2992019-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
3002019-02-13T15:28:27 <luke-jr> eh? my system(3) manpage says it's MT-safe
3012019-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
3022019-02-13T15:28:48 <wumpus> system() â Thread safety â MT-Safe
3032019-02-13T15:28:54 <wumpus> oh you're right luke-jr
3042019-02-13T15:29:00 <luke-jr> of course, this is just glibc
3052019-02-13T15:29:07 *** dviola has joined #bitcoin-core-dev
3062019-02-13T15:29:17 <wumpus> well yes but ...
3072019-02-13T15:29:51 <promag> wumpus: setenv is not thread safe :(
3082019-02-13T15:30:06 <wumpus> "fix your libc this is not 1995 anymore"
3092019-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.
3102019-02-13T15:30:11 <wumpus> promag: I know
3112019-02-13T15:30:23 <wumpus> promag: that's why you do it *after* forking
3122019-02-13T15:30:43 <luke-jr> Windows has no fork :P
3132019-02-13T15:30:49 *** pinheadmz has joined #bitcoin-core-dev
3142019-02-13T15:30:51 <wumpus> windows is completely differnt
3152019-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.
3162019-02-13T15:31:03 <wumpus> in *any case* you can pass a new environment to the spawn call
3172019-02-13T15:31:04 <gmaxwell> Calling plain libc functions and syscalls is fine, however.
3182019-02-13T15:31:06 <wumpus> both on windows and linux
3192019-02-13T15:31:16 <wumpus> but yeah not with system() which is kind of limited
3202019-02-13T15:31:19 <promag> wumpus: how=
3212019-02-13T15:31:36 <wumpus> sometimes I think the only real use of system() system call left is to spawn shells in exploits
3222019-02-13T15:32:07 <gmaxwell> lol
3232019-02-13T15:32:33 <gmaxwell> "Highly optimized for return only programming."
3242019-02-13T15:32:40 <wumpus> :-)
3252019-02-13T15:32:48 <promag> btw, could we just support %w on non-win?
3262019-02-13T15:33:07 <promag> ..for now.. X)
3272019-02-13T15:33:39 <rafalcpp> hould we write own minimal process library?
3282019-02-13T15:33:41 <achow101> why not boost::process?
3292019-02-13T15:33:48 <rafalcpp> achow101: too new
3302019-02-13T15:33:50 <promag> is there anyone using *notify commands on windows?
3312019-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?
3322019-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.
3332019-02-13T15:34:36 <wumpus> promag: for example `execve` has a envp argument, you should really never have to use setenv()
3342019-02-13T15:34:43 <luke-jr> it's not ideal, but better than the alternatives I guess
3352019-02-13T15:35:06 <rafalcpp> gmaxwell: might be too dependant on other boost
3362019-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)
3372019-02-13T15:35:16 <luke-jr> rafalcpp: might be, but probably not
3382019-02-13T15:35:20 <gmaxwell> ^
3392019-02-13T15:35:22 * rafalcpp bjam's it
3402019-02-13T15:35:24 <luke-jr> rafalcpp: prior to inclusion in boost, it was separate in fact
3412019-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
3422019-02-13T15:36:04 <wumpus> luke-jr: unless it uses new boost features
3432019-02-13T15:36:07 <luke-jr> true
3442019-02-13T15:36:22 <wumpus> (which could be expected if it's new code)
3452019-02-13T15:36:25 <luke-jr> but then we can just embed a copy of an older boost::process before it got merged
3462019-02-13T15:36:31 <luke-jr> assuming it's compatible
3472019-02-13T15:36:43 *** jio has quit IRC
3482019-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?
3492019-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
3502019-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
3512019-02-13T15:38:06 <wumpus> I think it's pointless to re-invent boost::process
3522019-02-13T15:38:37 <luke-jr> achow101: as we're learning with walletnotify, a single command is a mess
3532019-02-13T15:39:02 <luke-jr> so I think stdin would be preferred?
3542019-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"
3552019-02-13T15:39:17 <wumpus> I like waiting and doing nothing more
3562019-02-13T15:39:17 <promag> what does pyhton subprocess uses in windows?
3572019-02-13T15:39:21 <luke-jr> wumpus: just a limited copy used when boost is old, IMO
3582019-02-13T15:39:25 <rafalcpp> " long attempt to get a boost.process library, which is going on since 2006. " wow.
3592019-02-13T15:39:25 <achow101> luke-jr: it was the only way I could have every device have a consistent interface
3602019-02-13T15:39:37 <luke-jr> promag: Python is a giant blob
3612019-02-13T15:39:40 <achow101> otherwise some would require stdin for some thigns and others wouldn't
3622019-02-13T15:39:58 <luke-jr> achow101: ?
3632019-02-13T15:40:09 <wumpus> it's absurd that something simple like this is giving so much problems
3642019-02-13T15:40:12 <wumpus> bring back the 80's please
3652019-02-13T15:40:15 <luke-jr> anything you can do with a command line, you can do with stdin..
3662019-02-13T15:40:36 <gmaxwell> achow101: commandline lengths are limited, unfortunately. (also... not private)
3672019-02-13T15:40:41 <achow101> luke-jr: trezor asks for a scrambled pin. no other device does that
3682019-02-13T15:40:57 <luke-jr> achow101: so?
3692019-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
3702019-02-13T15:41:27 <luke-jr> achow101: I'm saying do EVERYTHING over stdin
3712019-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.
3722019-02-13T15:41:56 <luke-jr> gmaxwell: on Windows, the command line has no standard quoting
3732019-02-13T15:41:59 <gmaxwell> I'd always assumed this stuff would use stdin exclusively.
3742019-02-13T15:42:09 <rafalcpp> so many ways to snoop on cmd args from other local users
3752019-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
3762019-02-13T15:42:37 <rafalcpp> how about creating a tmp file (chmod for privacy), and pass it's name in arg?
3772019-02-13T15:42:44 *** Murch has joined #bitcoin-core-dev
3782019-02-13T15:42:51 <luke-jr> rafalcpp: â¦why?
3792019-02-13T15:43:01 <wumpus> nOoooOooo *screams*
3802019-02-13T15:43:04 <gmaxwell> rafalcpp: there be dragons, decades of security disasters from that..
3812019-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?
3822019-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 ...
3832019-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.
3842019-02-13T15:43:55 <wumpus> we really can't afford stupid mistakes here
3852019-02-13T15:44:15 <wumpus> gmaxwell: as well as shell escaping issues
3862019-02-13T15:44:21 <wumpus> this is like bug paradise
3872019-02-13T15:44:21 <rafalcpp> just chmod it? and mktemp exists for atomic creation of unique file?
3882019-02-13T15:45:03 <wumpus> *cries*
3892019-02-13T15:45:34 <gmaxwell> rafalcpp: it's an ugly rathole. Stdin is a straight forward, clean solution.
3902019-02-13T15:45:44 <gmaxwell> It would be a 4-line no brainer except for windows.
3912019-02-13T15:45:50 <rafalcpp> btw, how about IPC or RPC?
3922019-02-13T15:46:00 <wumpus> chmod also isn't available on windows, or at least, very different
3932019-02-13T15:46:07 <gmaxwell> but it sounds like the boost thing handles windows fine.
3942019-02-13T15:46:17 <gmaxwell> rafalcpp: also a security disaster.
3952019-02-13T15:46:18 <wumpus> IPC or RPC is *more difficult* than stdin and stdout handling
3962019-02-13T15:46:27 <wumpus> it's also highly platform specific
3972019-02-13T15:46:44 <wumpus> especially if you want only the child process to be able to access it
3982019-02-13T15:46:45 <gmaxwell> (consider the recently published rpc cve in bitcoin that we basically cannot fix...)
3992019-02-13T15:47:02 *** kallul has joined #bitcoin-core-dev
4002019-02-13T15:48:16 <rafalcpp> you're right, stdin is most secure
4012019-02-13T15:48:26 *** pinheadmz has quit IRC
4022019-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?
4032019-02-13T15:50:25 <wumpus> not more hacks
4042019-02-13T15:50:30 <wumpus> stop this
4052019-02-13T15:51:01 <promag> right, thanks
4062019-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)
4072019-02-13T15:53:29 <gmaxwell> I know, we could embed a SMTP mail user agent, and send email to the other process.
4082019-02-13T15:55:07 <gmaxwell> oh oh oh, I know. I know. We could use ... A BLOCKCHAIN.
4092019-02-13T15:55:12 <luke-jr> lol
4102019-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
4112019-02-13T15:55:25 <gmaxwell> first we'll issue utility tokens for interprocess communications....
4122019-02-13T15:55:37 <promag> smart processes? lgtm
4132019-02-13T15:57:03 <wumpus> yes dunno build a IoT toilet plunger that changes color on a new transaction for notification
4142019-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.
4152019-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
4162019-02-13T15:59:07 <wumpus> soo
4172019-02-13T15:59:14 <wumpus> my proposal would be: first build this with boost::process
4182019-02-13T15:59:23 <gmaxwell> achow101: presumably you lack tests with large PSBTs right now then. :)
4192019-02-13T15:59:26 *** setpill has quit IRC
4202019-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
4212019-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
4222019-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
4232019-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
4242019-02-13T16:01:48 <wumpus> luke-jr: +1
4252019-02-13T16:02:17 *** pinheadmz has joined #bitcoin-core-dev
4262019-02-13T16:02:58 <gmaxwell> wumpus: or put in efforts to extract boost-process from boost and package it as a compat.
4272019-02-13T16:03:15 <wumpus> gmaxwell: right
4282019-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 :)
4292019-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.
4302019-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
4312019-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.
4322019-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 :-)
4332019-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
4342019-02-13T16:08:54 <wumpus> passing the information to the notify script through stdin would be a future option too I guess...
4352019-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.
4362019-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
4372019-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
4382019-02-13T16:10:22 *** bitcoin-git has joined #bitcoin-core-dev
4392019-02-13T16:10:23 <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/0d1160e42185...cbe7efe9ea6c
4402019-02-13T16:10:23 <bitcoin-git> bitcoin/master 5039e4b Julian Fleischer: Remove unnecessary const_cast
4412019-02-13T16:10:24 <bitcoin-git> bitcoin/master cbe7efe Wladimir J. van der Laan: Merge #15389: Remove unnecessary const_cast
4422019-02-13T16:10:26 *** bitcoin-git has left #bitcoin-core-dev
4432019-02-13T16:10:46 <wumpus> provoostenator: yep; I see those are both already on the milestone
4442019-02-13T16:10:58 <wumpus> oh #14075 isn't
4452019-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
4462019-02-13T16:11:15 *** bitcoin-git has joined #bitcoin-core-dev
4472019-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
4482019-02-13T16:11:17 *** bitcoin-git has left #bitcoin-core-dev
4492019-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?)
4502019-02-13T16:15:44 <provoostenator> If so we'd still have to bump the minimum version and/or disable this feature for older versions.
4512019-02-13T16:20:17 *** mistergold has joined #bitcoin-core-dev
4522019-02-13T16:20:44 <achow101> what's the first version of boost with process?
4532019-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
4542019-02-13T16:20:50 <MarcoFalke> 1.64
4552019-02-13T16:20:59 <wumpus> yes, please just use boost::process for now we'll worry about the dependency stuff alter
4562019-02-13T16:21:13 <wumpus> let's spend time on desigining interesting features instead of crawling in the dependency mud
4572019-02-13T16:22:12 *** mistergold has quit IRC
4582019-02-13T16:22:45 <wumpus> what's up with the last-minute qt bump?
4592019-02-13T16:22:51 <wumpus> #15393
4602019-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
4612019-02-13T16:23:02 <MarcoFalke> It was an open issue for months
4622019-02-13T16:23:23 <MarcoFalke> It never compiled on anything less for all those months anyway
4632019-02-13T16:23:57 <wumpus> so you mean, currently depends doesn't build?
4642019-02-13T16:24:10 <provoostenator> Depends works fine, it's at 5.9
4652019-02-13T16:24:10 <MarcoFalke> no system qt
4662019-02-13T16:24:18 <wumpus> OHH
4672019-02-13T16:24:22 <wumpus> sorry I misread the PR title
4682019-02-13T16:24:29 <wumpus> I thought this was a depends bump
4692019-02-13T16:24:32 <MarcoFalke> Ah
4702019-02-13T16:25:31 <provoostenator> jnewbery: is there a way to skip a test on Windows (or AppVeyor)?
4712019-02-13T16:25:42 <MarcoFalke> --exclude test_name
4722019-02-13T16:25:45 <provoostenator> Or at least to detect the OS.
4732019-02-13T16:25:55 <MarcoFalke> Oh, wait
4742019-02-13T16:26:17 <MarcoFalke> Just do it similar to how the wallet tests are skipped
4752019-02-13T16:27:07 <provoostenator> Yeah, putting --exclude test_name in the appveyor script seems a bit brittle and easy to miss.
4762019-02-13T16:27:17 <MarcoFalke> def skip_test_if_missing_module
4772019-02-13T16:27:29 <MarcoFalke> Just consider Windows a "module" ;)
4782019-02-13T16:27:37 <MarcoFalke> or the os
4792019-02-13T16:27:53 <provoostenator> def skip_if_windows I guess
4802019-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.
4812019-02-13T16:28:30 *** Aaronvan_ has joined #bitcoin-core-dev
4822019-02-13T16:31:41 *** AaronvanW has quit IRC
4832019-02-13T16:41:48 <wumpus> is #14289 something that needs to be solved before 0.18 release?
4842019-02-13T16:41:50 <gribble> https://github.com/bitcoin/bitcoin/issues/14289 | Unbounded growth of scheduler queue · Issue #14289 · bitcoin/bitcoin · GitHub
4852019-02-13T16:42:33 <wumpus> (if so, is anyone working on it?)
4862019-02-13T16:43:46 *** bitcoin-git has joined #bitcoin-core-dev
4872019-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
4882019-02-13T16:43:47 *** bitcoin-git has left #bitcoin-core-dev
4892019-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.
4902019-02-13T16:46:03 <gmaxwell> it also screws up the usability of invalidateblock/reconsider block for testing.
4912019-02-13T16:46:16 <wumpus> yes, it's a bad issue, there's just not that much time left
4922019-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
4932019-02-13T16:47:42 <wumpus> I noticed it again because it has a 0.18.0 milestone
4942019-02-13T16:49:27 <gmaxwell> :(
4952019-02-13T16:49:52 <wumpus> same for #13103 unless the windows encoding changes already merged solve it
4962019-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
4972019-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
4982019-02-13T16:52:38 <wumpus> #13129 seems irrelevant to have tagged for 0.18
4992019-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
5002019-02-13T16:56:45 *** pbase has joined #bitcoin-core-dev
5012019-02-13T17:03:53 *** pinheadmz has quit IRC
5022019-02-13T17:04:40 *** jungly has quit IRC
5032019-02-13T17:06:29 *** promag has quit IRC
5042019-02-13T17:07:14 *** promag has joined #bitcoin-core-dev
5052019-02-13T17:14:04 *** jarthur has joined #bitcoin-core-dev
5062019-02-13T17:54:51 *** traizzl has joined #bitcoin-core-dev
5072019-02-13T17:58:43 *** pinheadmz has joined #bitcoin-core-dev
5082019-02-13T17:59:21 *** mistergold has joined #bitcoin-core-dev
5092019-02-13T17:59:56 *** traizzl has quit IRC
5102019-02-13T18:03:55 <provoostenator> Switching to boost::process was pretty easy (so far). Let's see if it actually works in Windows...
5112019-02-13T18:08:24 *** phwalkr has quit IRC
5122019-02-13T18:09:45 *** rex4539 has joined #bitcoin-core-dev
5132019-02-13T18:14:58 *** Karyon has joined #bitcoin-core-dev
5142019-02-13T18:19:33 <wumpus> provoostenator: that's good news, hope so!
5152019-02-13T18:19:48 *** Randolf has quit IRC
5162019-02-13T18:22:01 *** pbase has quit IRC
5172019-02-13T18:24:32 <wumpus> does anyone have a CPU with rdrand/rdseed support? (it will show in /proc/cpuinfo) please help test #15250
5182019-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
5192019-02-13T18:26:32 *** csknk has quit IRC
5202019-02-13T18:26:41 <gmaxwell> or, without them. :)
5212019-02-13T18:34:46 *** michaels_ has quit IRC
5222019-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
5232019-02-13T18:35:02 <sipa> wumpus: yes, it works for me :p
5242019-02-13T18:35:04 <wumpus> I've also checked that gcc does in fact generate them
5252019-02-13T18:35:21 <sipa> (at least, it reports "Using RdSeed as an additional randomness source")
5262019-02-13T18:35:29 <wumpus> good!
5272019-02-13T18:35:36 <sipa> i also have a system which supports rdrand but not rdseed
5282019-02-13T18:35:40 <sipa> i'll test on that
5292019-02-13T18:36:34 *** michaels_ has joined #bitcoin-core-dev
5302019-02-13T18:40:08 *** fabianfabian has joined #bitcoin-core-dev
5312019-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."
5322019-02-13T18:43:39 <sipa> ha
5332019-02-13T18:43:55 <sipa> i hadn't even considered that the pause instruction might have been a compatibility issue
5342019-02-13T18:46:02 <wumpus> :D
5352019-02-13T18:46:13 <gmaxwell> I had.
5362019-02-13T18:46:15 <gmaxwell> :P
5372019-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
5382019-02-13T18:49:15 *** ovovo has joined #bitcoin-core-dev
5392019-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
5402019-02-13T18:50:36 <provoostenator> And those logs are useless
5412019-02-13T18:50:53 <wumpus> yeh Appveyor logs are quite useless usually
5422019-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?
5432019-02-13T18:51:46 <jarthur> Build sipa's branch and check the debug.log?
5442019-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
5452019-02-13T18:52:15 <jarthur> thanks
5462019-02-13T18:52:22 <wumpus> and ofc check if the unit tests and functional test suite pass
5472019-02-13T18:52:48 <wumpus> I'm honestly not sure how to test reliability of random number generation otherwise
5482019-02-13T18:53:28 *** owowo has quit IRC
5492019-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.
5502019-02-13T18:54:59 <wumpus> there isn't, at the moment
5512019-02-13T18:56:48 *** Karyon has quit IRC
5522019-02-13T18:57:47 *** spinza has quit IRC
5532019-02-13T19:06:15 *** mistergold has quit IRC
5542019-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
5552019-02-13T19:10:07 <gribble> https://github.com/bitcoin/bitcoin/issues/14241 | appveyor: script improvement by ken2812221 · Pull Request #14241 · bitcoin/bitcoin · GitHub
5562019-02-13T19:19:43 <wumpus> oh yes msvc windows-land is like that, mingw-w64 windows-land should just work
5572019-02-13T19:21:26 *** bitcoin-git has joined #bitcoin-core-dev
5582019-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
5592019-02-13T19:21:30 *** bitcoin-git has left #bitcoin-core-dev
5602019-02-13T19:24:12 <sipa> wumpus: seems to work fine on rdrand-not-rdseed
5612019-02-13T19:25:22 *** siom has quit IRC
5622019-02-13T19:25:53 *** Aaronvan_ has quit IRC
5632019-02-13T19:31:17 *** dviola has quit IRC
5642019-02-13T19:33:06 *** michaels_ has quit IRC
5652019-02-13T19:33:30 <wumpus> sipa: nice!
5662019-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.
5672019-02-13T19:37:54 *** spinza has joined #bitcoin-core-dev
5682019-02-13T19:40:39 <jarthur> Tested fine on rdrand-and-rdseed, either way
5692019-02-13T19:43:46 *** AaronvanW has joined #bitcoin-core-dev
5702019-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.
5712019-02-13T19:45:03 *** Guyver2 has joined #bitcoin-core-dev
5722019-02-13T19:46:43 *** Apocalyptic has quit IRC
5732019-02-13T19:48:22 *** AaronvanW has quit IRC
5742019-02-13T19:49:20 *** Apocalyptic has joined #bitcoin-core-dev
5752019-02-13T19:53:43 <wumpus> jarthur: on P2P? I don't think that's a known issue
5762019-02-13T19:55:04 <wumpus> if you can reproduce it, please open an issue
5772019-02-13T19:55:19 *** michaels_ has joined #bitcoin-core-dev
5782019-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
5792019-02-13T19:57:26 <instagibbs> and it'll only happen once
5802019-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
5812019-02-13T19:57:43 <instagibbs> less stressful than running a single "listunspent"
5822019-02-13T19:59:29 *** AaronvanW has joined #bitcoin-core-dev
5832019-02-13T19:59:34 *** copumpkin has quit IRC
5842019-02-13T20:01:53 <jarthur> wumpus: will do, probably tonight or tomorrow
5852019-02-13T20:03:55 *** fabianfabian has quit IRC
5862019-02-13T20:04:10 *** AaronvanW has quit IRC
5872019-02-13T20:09:24 <achow101> instagibbs: while thinking about that problem. i realized that current master is also broken in the same way
5882019-02-13T20:09:46 <instagibbs> what specifically?
5892019-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
5902019-02-13T20:10:11 <instagibbs> ah
5912019-02-13T20:10:19 <instagibbs> welp
5922019-02-13T20:12:19 <achow101> if we do it on first unlock, a user could make a psbt that has a bogus fingerprint
5932019-02-13T20:15:29 <achow101> i guess we could make walletprocesspsbt throw an error if the key metadata isn't updated?
5942019-02-13T20:18:34 *** millerti has quit IRC
5952019-02-13T20:21:19 *** pinheadmz has quit IRC
5962019-02-13T20:22:14 *** pinheadmz has joined #bitcoin-core-dev
5972019-02-13T20:24:21 *** promag has quit IRC
5982019-02-13T20:24:35 *** promag has joined #bitcoin-core-dev
5992019-02-13T20:30:38 *** AaronvanW has joined #bitcoin-core-dev
6002019-02-13T20:31:01 <wumpus> jarthur: thanks
6012019-02-13T20:34:32 *** marcoagner has joined #bitcoin-core-dev
6022019-02-13T20:35:10 *** AaronvanW has quit IRC
6032019-02-13T20:38:39 *** x4b1d has joined #bitcoin-core-dev
6042019-02-13T20:39:25 <x4b1d> Anyone seen good code examples of offline signing outside of using bitcoind?
6052019-02-13T20:40:56 *** promag has quit IRC
6062019-02-13T20:41:29 <wumpus> maybe some FOSS hw wallet firmware like the trezor one?
6072019-02-13T20:41:36 *** promag has joined #bitcoin-core-dev
6082019-02-13T20:45:54 *** AaronvanW has joined #bitcoin-core-dev
6092019-02-13T20:48:19 *** DeanGuss has quit IRC
6102019-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!
6112019-02-13T20:49:59 *** bitcoin-git has joined #bitcoin-core-dev
6122019-02-13T20:50:00 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/cbe7efe9ea6c...9c4a90040dd3
6132019-02-13T20:50:00 <bitcoin-git> bitcoin/master 318b1f7 John Newbery: [wallet] Close bdb when flushing wallet.
6142019-02-13T20:50:01 <bitcoin-git> bitcoin/master 9c4a900 MarcoFalke: Merge #15390: [wallet-tool] Close bdb when flushing wallet
6152019-02-13T20:50:03 *** bitcoin-git has left #bitcoin-core-dev
6162019-02-13T20:50:38 *** AaronvanW has quit IRC
6172019-02-13T20:50:46 *** bitcoin-git has joined #bitcoin-core-dev
6182019-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
6192019-02-13T20:50:54 *** bitcoin-git has left #bitcoin-core-dev
6202019-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
6212019-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
6222019-02-13T20:53:49 *** Karyon has joined #bitcoin-core-dev
6232019-02-13T20:54:25 <achow101> x4b1d: maybe have a look at armory? it's entire goal is to do offline signing
6242019-02-13T20:55:30 <echeveria> achow101: armory is highly is advisable.
6252019-02-13T20:55:58 <echeveria> inadvisable. it has long standing implementation issues and a history of losing money. itâs not strongly maintained.
6262019-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
6272019-02-13T20:57:13 <x4b1d> doesn't armory just rpc into bitcoind ?
6282019-02-13T20:57:30 <wumpus> achow101: calling into a centralized server is kinda meh though I agree
6292019-02-13T20:57:32 <sipa> #bitcoin
6302019-02-13T20:57:46 <achow101> x4b1d: no. it only uses bitcoind for connection to the network
6312019-02-13T21:02:04 <wumpus> yea #bitcoin is better for questions like this as they don't involve bitcoin core development
6322019-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
6332019-02-13T21:06:02 <wumpus> well *that* would be on topic
6342019-02-13T21:06:49 <wumpus> FWIW I think that would be a good idea
6352019-02-13T21:07:43 <wumpus> the RPC pure utility functions (that don't need a node, wallet) could be a library
6362019-02-13T21:07:56 <x4b1d> god I wish I had that
6372019-02-13T21:08:20 <sipa> libwally has a bunch of functions
6382019-02-13T21:09:30 <wumpus> yes, that one is used by clightning for example
6392019-02-13T21:09:30 <sipa> but a standalone library/tool that can do psbt signing would be pretty nice
6402019-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
6412019-02-13T21:11:05 <x4b1d> would be so happy to see that as a development
6422019-02-13T21:19:10 <achow101> what's up with travis? the linter target is failing since python 3.4 couldn't be downloaded
6432019-02-13T21:19:54 <wumpus> achow101: haven't noticed yet, where is that?
6442019-02-13T21:20:41 <achow101> https://travis-ci.org/bitcoin/bitcoin/jobs/492915824
6452019-02-13T21:21:08 *** AaronvanW has joined #bitcoin-core-dev
6462019-02-13T21:21:18 <wumpus> -restarted
6472019-02-13T21:21:20 <achow101> seems to have just became a problem within the last hour
6482019-02-13T21:21:37 <achow101> (i've tried restarting already and it didn't fix it)
6492019-02-13T21:21:42 <wumpus> ohh
6502019-02-13T21:22:10 <wumpus> dead python 3.4 then
6512019-02-13T21:22:27 <achow101> rip
6522019-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
6532019-02-13T21:23:38 <wumpus> $ curl -sSf -o python-3.4.tar.bz2 ${archive_url}
6542019-02-13T21:23:41 <wumpus> curl: (22) The requested URL returned error: 403 Forbidden
6552019-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
6562019-02-13T21:25:52 *** AaronvanW has quit IRC
6572019-02-13T21:26:54 <wumpus> it's *before* our script takes action so nothing we can do I think
6582019-02-13T21:27:56 <achow101> yeah... i'll contact their support
6592019-02-13T21:29:16 <wumpus> thanks !
6602019-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.
6612019-02-13T21:31:09 <jarthur> wumpus Did a little bit of due-dilligence and filed the p2p_invalid_messages issue as #15400
6622019-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
6632019-02-13T21:31:32 <wumpus> jarthur: interesting
6642019-02-13T21:32:33 <wumpus> we've certainly run into problems with this before, with tests failing simply due to unexpected stderr output
6652019-02-13T21:34:00 <wumpus> okay this is definitely something else it happens in python itself
6662019-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.
6672019-02-13T21:38:43 *** Guyver2 has quit IRC
6682019-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
6692019-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
6702019-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
6712019-02-13T21:43:03 <sipa> agree
6722019-02-13T21:43:11 <sipa> (in general, i haven't looked at the pr)
6732019-02-13T21:43:46 <wumpus> it's been open for a while but I think it just WTFs everyone
6742019-02-13T21:45:42 <wumpus> (and I don't think the issue with it was indentation)
6752019-02-13T21:47:54 *** Murch has quit IRC
6762019-02-13T21:48:26 *** bitcoin-git has joined #bitcoin-core-dev
6772019-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
6782019-02-13T21:48:31 *** bitcoin-git has left #bitcoin-core-dev
6792019-02-13T21:52:11 *** bitcoin-git has joined #bitcoin-core-dev
6802019-02-13T21:52:11 <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9c4a90040dd3...9c93f5d9fc93
6812019-02-13T21:52:12 <bitcoin-git> bitcoin/master a4b92e4 Hennadii Stepanov: Log full paths for wallets
6822019-02-13T21:52:12 <bitcoin-git> bitcoin/master 9c93f5d Wladimir J. van der Laan: Merge #15334: wallet: Log absolute paths for the wallets
6832019-02-13T21:52:14 *** AaronvanW has joined #bitcoin-core-dev
6842019-02-13T21:52:23 *** bitcoin-git has left #bitcoin-core-dev
6852019-02-13T21:52:54 *** bitcoin-git has joined #bitcoin-core-dev
6862019-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
6872019-02-13T21:53:07 *** bitcoin-git has left #bitcoin-core-dev
6882019-02-13T21:54:01 <wumpus> "throw help" hehe
6892019-02-13T21:56:38 *** AaronvanW has quit IRC
6902019-02-13T21:58:30 *** bralyclo_ has joined #bitcoin-core-dev
6912019-02-13T21:58:31 <MarcoFalke> I don't understand what #15140 is trying to do
6922019-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
6932019-02-13T21:58:46 <wumpus> same
6942019-02-13T21:59:03 <MarcoFalke> A comment with "//---------><----- cut here"
6952019-02-13T21:59:37 * MarcoFalke takes scissors and cuts the monitor
6962019-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
6972019-02-13T22:01:05 *** skyikot has joined #bitcoin-core-dev
6982019-02-13T22:01:19 <sipa> oh, i get it
6992019-02-13T22:01:32 <sipa> the test is broken
7002019-02-13T22:01:44 *** elichai2 has joined #bitcoin-core-dev
7012019-02-13T22:01:54 *** bralyclow has quit IRC
7022019-02-13T22:02:15 <wumpus> oh!
7032019-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)
7042019-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
7052019-02-13T22:02:47 <sipa> and the cut thing is because he gives 2 versions
7062019-02-13T22:03:28 <wumpus> that's where it gets confusing
7072019-02-13T22:03:58 *** spinza has quit IRC
7082019-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
7092019-02-13T22:04:28 <sipa> that's what his first version does
7102019-02-13T22:04:40 <wumpus> right
7112019-02-13T22:13:32 <wumpus> so that would seem to be enough
7122019-02-13T22:23:56 <wumpus> #15257 really has a crapload of changes just to make the new version of the python linter happy
7132019-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
7142019-02-13T22:29:44 <achow101> travis seems to have fixed itself
7152019-02-13T22:30:08 <wumpus> good, problems that fix themselves just by waiting are the best
7162019-02-13T22:31:03 *** spinza has joined #bitcoin-core-dev
7172019-02-13T22:32:17 <wumpus> hopefully it's not a transient issue that will come back, e.g. because of changing IP
7182019-02-13T22:33:29 *** AaronvanW has joined #bitcoin-core-dev
7192019-02-13T22:33:44 *** shesek`` has joined #bitcoin-core-dev
7202019-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.
7212019-02-13T22:40:24 *** michaels_ has quit IRC
7222019-02-13T22:44:01 *** mistergold has joined #bitcoin-core-dev
7232019-02-13T22:50:01 *** michaels_ has joined #bitcoin-core-dev
7242019-02-13T22:54:24 *** michaels_ has quit IRC
7252019-02-13T22:54:46 *** promag has quit IRC
7262019-02-13T22:54:59 *** promag has joined #bitcoin-core-dev
7272019-02-13T23:00:21 *** skyikot has quit IRC
7282019-02-13T23:06:22 <MarcoFalke> Eh, the travis issue (failed to fetch py3.4) is transient
7292019-02-13T23:06:29 <MarcoFalke> I've seen it for weeks
7302019-02-13T23:07:09 <wumpus> we both tried restarting and that didn't solve it
7312019-02-13T23:18:33 <wumpus> could be that simply restarting doesn't re-assign the ip
7322019-02-13T23:19:34 *** mave has joined #bitcoin-core-dev
7332019-02-13T23:19:37 <mave> hi
7342019-02-13T23:19:41 <jarthur> 'lo
7352019-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)
7362019-02-13T23:20:47 <mryandao> you have to tell it
7372019-02-13T23:20:59 <mryandao> or it creates a new $HOME/.bitcoin/
7382019-02-13T23:21:14 <mave> I'm not telling it and it's finding my /disco-dos/bitcoin-data/ directory :o
7392019-02-13T23:21:26 <mave> I'm confused as to how
7402019-02-13T23:21:28 <mryandao> o.O
7412019-02-13T23:21:39 <mave> I just start it up with bitcoin-qt
7422019-02-13T23:21:46 <mave> with an empty $HOME/.bitcoin
7432019-02-13T23:21:56 <mave> and it correctly finds my datadir
7442019-02-13T23:21:57 <jarthur> What platform? And is it in finding the wallet in there? Blockchain data, all of the above?
7452019-02-13T23:22:05 <mave> ubuntu
7462019-02-13T23:22:14 <mave> bitcoind
7472019-02-13T23:22:21 <mave> compiled from source recently
7482019-02-13T23:22:52 <mave> yes, it is finding everything correctly (which is unexpected as I deleted $HOME/.bitcoin on purpose)
7492019-02-13T23:22:59 <luke-jr> mave: bitcoind or bitcoin-qt?
7502019-02-13T23:23:14 <mave> I compiled both
7512019-02-13T23:23:19 <luke-jr> which are you using?
7522019-02-13T23:23:22 <mave> the one that's surprising me is bitcoin-qt
7532019-02-13T23:23:35 <luke-jr> cat ~/.config/Bitcoin/Bitcoin-Qt.conf
7542019-02-13T23:23:36 <mave> for this use case it's bitcoin-qt
7552019-02-13T23:24:26 <mave> aah, so it has a different set of config files
7562019-02-13T23:24:49 <mave> I thought it would read from $HOME/.bitcoin/bitcoin.conf
7572019-02-13T23:25:04 <luke-jr> it will read that too
7582019-02-13T23:25:15 <luke-jr> well, if $HOME/.bitcoin is your datadir ;)
7592019-02-13T23:25:33 <mave> my datadir I specify manually when starting bitcoind
7602019-02-13T23:25:41 <mave> but I don't when starting bitcoin-qt
7612019-02-13T23:25:42 *** michaels_ has joined #bitcoin-core-dev
7622019-02-13T23:25:54 <mave> hence my surprise to see that bitcoin-qt could find my datadir
7632019-02-13T23:26:39 <mave> I now understand that bitcoin-qt has some other set of config files under $HOME/.config/Bitcoin
7642019-02-13T23:26:51 <mave> however looking into them I don't find any pointer to my datadir
7652019-02-13T23:28:17 <jarthur> What do you see for "Default data directory" and "Using data directory" in debug.log for the -Qt session?
7662019-02-13T23:29:32 *** DeanGuss has joined #bitcoin-core-dev
7672019-02-13T23:30:23 <mave> Default data directory /home/roge/.bitcoin
7682019-02-13T23:30:40 *** michaels_ has quit IRC
7692019-02-13T23:31:06 <mave> which is my $HOME/.bitcoin
7702019-02-13T23:31:13 <mave> and is different from my datadir
7712019-02-13T23:32:48 *** timothy has quit IRC
7722019-02-13T23:33:20 *** murrayn has joined #bitcoin-core-dev
7732019-02-13T23:33:20 *** murrayn has joined #bitcoin-core-dev
7742019-02-13T23:33:32 * mave sits back
7752019-02-13T23:35:22 <jarthur> So it says "Using data directory /disco-dos/bitcoin-data/" shortly after that?
7762019-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?
7772019-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
7782019-02-13T23:36:21 <mave> 2019-02-13 23:34:57 Bitcoin Core version v0.16.0 (release build)
7792019-02-13T23:36:31 <mave> 2019-02-13 23:34:57 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
7802019-02-13T23:36:38 <mave> 2019-02-13 23:34:57 Assuming ancestors of block 0000000002e9e7b00e1f6dc5123a04aad68dd0f0968d8c7aa45f6640795c37b1 have valid signatures.
7812019-02-13T23:36:45 <mave> 2019-02-13 23:34:57 Setting nMinimumChainWork=00000000000000000000000000000000000000000000002830dab7f76dbb7d63
7822019-02-13T23:36:51 <mave> 2019-02-13 23:34:57 Using the 'sse4' SHA256 implementation
7832019-02-13T23:36:57 <mave> 2019-02-13 23:34:57 Using RdRand as an additional entropy source
7842019-02-13T23:37:04 <mave> 2019-02-13 23:34:57 Default data directory /home/roge/.bitcoin
7852019-02-13T23:37:11 <mave> 2019-02-13 23:34:57 Using data directory /disco-dos/bitcoin-data/testnet3
7862019-02-13T23:37:18 <mave> 2019-02-13 23:34:57 Using config file /disco-dos/bitcoin-data/bitcoin.conf
7872019-02-13T23:37:41 <mave> it says it's using /home/roge/.bitcoin as default data dir
7882019-02-13T23:37:41 <sipa> mave: please don't spam the channel
7892019-02-13T23:37:45 <mave> this dir is empty
7902019-02-13T23:38:09 <sipa> copy-pasting more than 3 lines is considered impolite on IRC
7912019-02-13T23:38:13 <mave> @sipa, sorry, I'm new here
7922019-02-13T23:38:40 <mave> I just wanted to answer luke-jr's question
7932019-02-13T23:38:42 *** Aaronva__ has joined #bitcoin-core-dev
7942019-02-13T23:38:54 <sipa> mave: ok, use a pastebin site next time
7952019-02-13T23:39:05 <promag> use https://pastebin.com/
7962019-02-13T23:39:08 <luke-jr> I only asked for 2 lines -.-
7972019-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
7982019-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
7992019-02-13T23:40:04 <jarthur> Alright, how are you opening Bitcoin-Qt, and are you passing it that conf file at the command line?
8002019-02-13T23:40:27 <mave> nope, I'm running it from shell just using the command bitcoin-qt, no params
8012019-02-13T23:40:38 *** AaronvanW has quit IRC
8022019-02-13T23:41:05 <sipa> is the datadir maybe stored in the Qt config?
8032019-02-13T23:41:48 <mave> there is no qt-config that I am aware of aside from bitcoin.conf
8042019-02-13T23:42:26 <sipa> bitcoin-qt has its own config, but i don't know the details
8052019-02-13T23:43:18 <luke-jr> sipa: assuming you mean ~/.config/Bitcoin/Bitcoin-Qt.conf , he said he already checked it
8062019-02-13T23:43:30 <sipa> ah
8072019-02-13T23:43:32 <sipa> yes
8082019-02-13T23:43:41 <mave> yes, I checked those files and there is no ref to my datadir
8092019-02-13T23:44:51 <mave> never mind
8102019-02-13T23:44:54 <mave> I found it
8112019-02-13T23:44:56 <luke-jr> where?
8122019-02-13T23:45:01 <mave> you were right luke-jr
8132019-02-13T23:45:13 <mave> grep disco-dos * found it for me
8142019-02-13T23:45:18 <mave> it was as you said
8152019-02-13T23:45:27 <mave> under .config/Bitcoin/Bitcoin-QT.conf
8162019-02-13T23:45:35 <mave> strDataDir=
8172019-02-13T23:45:41 <mave> mistery solved :)
8182019-02-13T23:45:41 <jarthur> Cool. I hate mysteries.
8192019-02-13T23:45:51 <luke-jr> I was about to suggest strace <.<
8202019-02-13T23:45:56 <mave> haha
8212019-02-13T23:46:11 <mave> thanks for the welcome help
8222019-02-13T23:46:15 <promag> jarthur: The End
8232019-02-13T23:46:25 <mave> cool irc channel :)
8242019-02-13T23:47:22 *** mistergold has quit IRC
8252019-02-13T23:47:47 <jarthur> :)
8262019-02-13T23:59:17 *** mave has quit IRC