--- Log opened Wed Feb 13 00:00:49 2019
00:12 -!- rhavar [uid237883@gateway/web/irccloud.com/x-vnmvhcjasgoekejs] has quit [Quit: Connection closed for inactivity]
00:17 < promag> review beg in #15195
00:17 < gribble> https://github.com/bitcoin/bitcoin/issues/15195 | gui: Add Close Wallet action by promag · Pull Request #15195 · bitcoin/bitcoin · GitHub
00:17 < promag> this one is really small
00:19 < promag> maybe add it to hp
00:19 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection]
00:54 -!- niska [~niska@68.ip-149-56-14.net] has quit [Quit: Leaving]
00:59 -!- niska [~niska@68.ip-149-56-14.net] has joined #bitcoin-core-dev
01:03 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 256 seconds]
01:06 -!- niska [~niska@68.ip-149-56-14.net] has quit [Quit: Leaving]
01:08 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev
01:09 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev
01:12 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Remote host closed the connection]
01:13 -!- rh0nj [~rh0nj@88.99.167.175] has joined #bitcoin-core-dev
01:17 -!- niska [~niska@68.ip-149-56-14.net] has joined #bitcoin-core-dev
01:32 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
01:34 -!- jungly [~quassel@79.8.200.97] has joined #bitcoin-core-dev
01:44 -!- Karyon [~karyon@unaffiliated/karyon] has joined #bitcoin-core-dev
01:47 < gwillen> the wallet unloading logic is uh, intricate
01:48 < 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.
01:48 < gribble> https://github.com/bitcoin/bitcoin/issues/15195 | gui: Add Close Wallet action by promag · Pull Request #15195 · bitcoin/bitcoin · GitHub
01:55 -!- TX1683 [~TX1683@unaffiliated/tx1683] has quit [Ping timeout: 268 seconds]
01:56 -!- TX1683 [~TX1683@unaffiliated/tx1683] has joined #bitcoin-core-dev
02:01 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
02:04 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev
02:04 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev
02:09 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
02:27 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has quit [Read error: Connection reset by peer]
02:29 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
02:29 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has quit [Remote host closed the connection]
02:33 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
02:39 -!- Karyon [~karyon@unaffiliated/karyon] has quit [Ping timeout: 250 seconds]
03:06 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has quit [Remote host closed the connection]
03:14 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]
03:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
03:32 -!- murrayn [~murrayn@unaffiliated/murrayn] has quit [Read error: Connection reset by peer]
03:33 -!- siom [~siom@31.13.191.152] has joined #bitcoin-core-dev
03:55 -!- phwalkr [~phwalkr@194.210.89.97] has joined #bitcoin-core-dev
04:02 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 245 seconds]
04:03 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev
04:04 -!- phwalkr [~phwalkr@194.210.89.97] has quit [Ping timeout: 250 seconds]
04:07 -!- phwalkr [~phwalkr@194.210.89.97] has joined #bitcoin-core-dev
04:08 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
04:09 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev
04:18 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev
04:20 -!- phwalkr_ [~phwalkr@194.210.89.97] has joined #bitcoin-core-dev
04:21 -!- phwalkr [~phwalkr@194.210.89.97] has quit [Read error: Connection reset by peer]
04:23 -!- phwalkr [~phwalkr@87.196.81.93] has joined #bitcoin-core-dev
04:26 -!- phwalkr_ [~phwalkr@194.210.89.97] has quit [Ping timeout: 246 seconds]
04:40 -!- phwalkr_ [~phwalkr@fwalunos-vip.estig.ipb.pt] has joined #bitcoin-core-dev
04:43 -!- phwalkr [~phwalkr@87.196.81.93] has quit [Ping timeout: 258 seconds]
04:44 -!- phwalkr_ [~phwalkr@fwalunos-vip.estig.ipb.pt] has quit [Read error: Connection reset by peer]
04:45 -!- phwalkr [~phwalkr@fwalunos-vip.estig.ipb.pt] has joined #bitcoin-core-dev
04:53 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
04:56 -!- phwalkr_ [~phwalkr@194.210.89.194] has joined #bitcoin-core-dev
04:56 -!- phwalkr_ [~phwalkr@194.210.89.194] has quit [Remote host closed the connection]
04:57 -!- phwalkr_ [~phwalkr@194.210.89.194] has joined #bitcoin-core-dev
04:59 -!- phwalkr [~phwalkr@fwalunos-vip.estig.ipb.pt] has quit [Ping timeout: 245 seconds]
05:01 -!- phwalkr_ [~phwalkr@194.210.89.194] has quit [Ping timeout: 250 seconds]
05:03 -!- phwalkr [~phwalkr@194.210.89.194] has joined #bitcoin-core-dev
05:04 -!- phwalkr_ [~phwalkr@fwalunos-vip.estig.ipb.pt] has joined #bitcoin-core-dev
05:07 -!- phwalkr [~phwalkr@194.210.89.194] has quit [Ping timeout: 246 seconds]
05:08 -!- phwalkr_ [~phwalkr@fwalunos-vip.estig.ipb.pt] has quit [Ping timeout: 246 seconds]
05:11 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
05:14 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]
05:46 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
05:50 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Ping timeout: 240 seconds]
05:53 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-dev
06:04 -!- bralyclow [bralyclow@gateway/vpn/protonvpn/bralyclow] has joined #bitcoin-core-dev
06:07 -!- bralyclo_ [bralyclow@gateway/vpn/protonvpn/bralyclow] has quit [Ping timeout: 246 seconds]
06:16 -!- paulje [892b6aa8@gateway/web/freenode/ip.137.43.106.168] has joined #bitcoin-core-dev
06:16 -!- zander [892bc4a4@gateway/web/freenode/ip.137.43.196.164] has joined #bitcoin-core-dev
06:17 -!- paulje [892b6aa8@gateway/web/freenode/ip.137.43.106.168] has quit [Client Quit]
06:17 -!- zander [892bc4a4@gateway/web/freenode/ip.137.43.196.164] has quit [Client Quit]
06:24 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
06:26 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:26 < 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
06:26 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:32 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
06:42 -!- jtimon [~quassel@92.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
06:46 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit []
06:47 -!- jio [892bc4a4@gateway/web/freenode/ip.137.43.196.164] has joined #bitcoin-core-dev
06:47 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
06:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:52 < 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
06:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:53 -!- shesek`` [~shesek@141.226.217.238] has quit [Ping timeout: 268 seconds]
06:56 -!- bralyclow [bralyclow@gateway/vpn/protonvpn/bralyclow] has quit []
06:57 < luke-jr> provoostenator: cpp-subprocess doesn't seem to be available on Gentoo at all, FWIW
06:57 < luke-jr> easily changed, but I'd check availability in Debian/RHEL since those are slower
06:58 < provoostenator> Why? It's included as a subtree.
06:58 < wumpus> should probably be configurable whether to use the OS-installed one or the subtree
06:59 < wumpus> unless we require a specifically patched version like with tinyformat
07:01 < promag> I still don´t understand how can cpp-subprocess be an option without win support
07:01 < wumpus> why no win support?
07:02 < wumpus> is it impossible? or just no one had the time or motivation to write it yet
07:02 < promag> I guess so
07:02 < wumpus> after the walletnotify escaping issue I'm kind of sad about any kind of external process support
07:03 < wumpus> though at least that problem is avoided by passing the data via stdin/stdout and not the command line :<
07:03 -!- ccook_ is now known as ccook
07:04 < promag> wumpus: that makes sense when you "pipe" to the subprocess
07:04 < promag> I really like the idea of env vars
07:05 < luke-jr> provoostenator: it should not be included as a subtree
07:05 < wumpus> piping is definitely preferable for any significant amount of data, certainly if it's supposed to be binary clean
07:06 < wumpus> but environment variables can be useful for some things, sure
07:06 < luke-jr> subtrees are a bad practice
07:07 < promag> wumpus: exactly, and don't require changing the conf, only the script
07:07 < gmaxwell> what is using cpp-subprocess?
07:07 < 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.
07:08 < promag> wumpus: with boost process it's something like: bp::system(cmd, bp::env["TXID"]=txid, bp::env["WALLET"]=wallet.GetName());
07:08 < wumpus> gmaxwell: #15382
07:08 < luke-jr> provoostenator: maybe there isn't - that would be a reason not to use it
07:08 < gribble> https://github.com/bitcoin/bitcoin/issues/15382 | WIP [util] add runCommandParseJSON by Sjors · Pull Request #15382 · bitcoin/bitcoin · GitHub
07:08 < provoostenator> luke-jr: why would absense of a package be reason not to use something? I would say the biggest criterium is quality.
07:09 < provoostenator> But if boost:process already works with Windows I will probably switch to that anyway.
07:09 < gmaxwell> welp jgarzik on that pr. pressing close. best of luck to you.
07:09 < promag> ?
07:10 < wumpus> the biggest criterion is "please don't introduce any security bugs"
07:10 < luke-jr> biggest criterion != only criterion
07:10 < promag> another one: use stable dependencies?
07:11 < gmaxwell> more like avoid dependencies entirely, unless they provide a lot of value.
07:12 < luke-jr> dependencies > NIH reinvention
07:12 < provoostenator> I can't believe we even need dependencies for something as basic as running a command and getting the result.
07:12 < gmaxwell> (with 'a lot' depending on how universally used they are.)
07:12 < gmaxwell> provoostenator: yeah
07:12 < provoostenator> You'd think 40+ years of C development would have solved that...
07:13 < luke-jr> well, commands are inherently external to C
07:13 < luke-jr> iirc
07:13 < wumpus> provoostenator: +100
07:13 < wumpus> so rust implementation of bitcoin core when?
07:14 < luke-jr> Rust compiler that can be safely bootstrapped when? :/
07:14 < luke-jr> I guess the problem with popen is Windows
07:15 < rafalcpp> provoostenator: well you can just run command easily, but boost process just handles more options in it
07:15 < 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?
07:15 < luke-jr> boost::process is newer than our current minimum version it seems; wonder if we can just bump it
07:15 < wumpus> gmaxwell: was about to say that
07:16 < wumpus> so can boost::process do the required thing on windows?
07:16 < wumpus> I kind of hate to introduce a new boost dependency but I think I hate the alternative even more
07:16 < 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.
07:16 < wumpus> right
07:17 < wumpus> especially as boost tends to be picked up in future c++
07:17 < gmaxwell> Also there is at least some chance that the boost thing shows up in C++24 or whatever.
07:17 < 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)
07:17 < rafalcpp> what do you require of bp?
07:18 < luke-jr> boost::process is new in 1.64.0; Debian is at 1.62 :/
07:18 < provoostenator> rafacpp: run a command, process its std::out
07:18 < rafalcpp> wait I think I did that in debian stable
07:18 < provoostenator> (and parse that if it's valid JSON, otherwise fail)
07:18 < luke-jr> RHEL is at 1.53 x.x
07:19 < wumpus> eh that JSON parsing we can handle ourselves
07:19 < wumpus> the depenency just needs to be able to provide stdin data and give us stdout data
07:19 < provoostenator> wumpus: correct, UniValue does that
07:19 < wumpus> like python's subprocess has been able to do, what, 20 years?
07:19 < provoostenator> Yes
07:20 < 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. 
07:20 < provoostenator> *evil
07:20 < wumpus> oh no
07:20 < wumpus> we're going do this properly or not at all
07:20 < provoostenator> Indeed. And it shouldn't be that hard.
07:21 < provoostenator> The test suite uses a hack along these lines to the notification code by the way.
07:21 < provoostenator> But that's just a test suite.
07:21 < wumpus> that's fine
07:21 -!- bralyclow [bralyclow@gateway/vpn/protonvpn/bralyclow] has joined #bitcoin-core-dev
07:21 < wumpus> right
07:22 < luke-jr> https://github.com/eidheim/tiny-process-library might be another option, but also no packages it seems
07:22 < wumpus> and maybe that can be replaced too when have a way to do it better
07:22 < promag> one important thing, that we don't handle right, is thread safety - boost::process isn't thread safe also
07:22 < wumpus> promag: what???
07:23 < luke-jr> ^
07:23 < gmaxwell> what do you mean by "thread safe" in this context?
07:23 < wumpus> making new processes should be about the most thread safe thing ever
07:23 < promag> we launch a thread that will call system(cmd)
07:23 < promag> this is not thread safe
07:23 < wumpus> how is it not?
07:24 < promag> iiuc it can mess file descriptors of one process to other if concurrent systems are called? 
07:25 < gmaxwell> system() is prefertly multithread safe. 
07:25 < rafalcpp> Stroustrup  *invents C++*
07:25 < rafalcpp> 40 years passes.  hEy guYs mayBE we shOUld have clAssEs to do ProcESSes and shit
07:25 < gmaxwell> (at least the C function is)
07:25 < luke-jr> I'm shocked there isn't an obviously good solution to this
07:26 < rafalcpp> maybe reimplement mininmal version of boost process and include it
07:26 -!- michaels_ [~michaelsd@208.59.170.5] has joined #bitcoin-core-dev
07:27 < rafalcpp> or build own boost process on our own by copying the code (assuming it doesn't have other boost deps goind too deep)
07:27 < promag> gmaxwell: I read different opinions, I don't have deep knowledge here
07:27 < 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
07:27 < promag> https://stackoverflow.com/questions/13471489/is-it-safe-to-call-system3-from-multi-threaded-process
07:27 < 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
07:28 < luke-jr> eh? my system(3) manpage says it's MT-safe
07:28 < wumpus> it has *tons* of problems, for example escaping security issues, but I don't think thread safety s one of them
07:28 < wumpus> system()  │ Thread safety │ MT-Safe 
07:28 < wumpus> oh you're right luke-jr 
07:29 < luke-jr> of course, this is just glibc
07:29 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev
07:29 < wumpus> well yes but ...
07:29 < promag> wumpus: setenv is not thread safe :(
07:30 < wumpus> "fix your libc this is not 1995 anymore"
07:30 < 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.
07:30 < wumpus> promag: I know
07:30 < wumpus> promag: that's why you do it *after* forking
07:30 < luke-jr> Windows has no fork :P
07:30 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
07:30 < wumpus> windows is completely differnt
07:30 < gmaxwell> essentially, when you fork, you lose your other threads, so you can't do anything that will interact with them.
07:31 < wumpus> in *any case* you can pass a new environment to the spawn call
07:31 < gmaxwell> Calling plain libc functions and syscalls is fine, however.
07:31 < wumpus> both on windows and linux
07:31 < wumpus> but yeah not with system() which is kind of limited
07:31 < promag> wumpus: how=
07:31 < wumpus> sometimes I think the only real use of system() system call left is to spawn shells in exploits
07:32 < gmaxwell> lol
07:32 < gmaxwell> "Highly optimized for return only programming."
07:32 < wumpus> :-)
07:32 < promag> btw, could we just support %w on non-win?
07:33 < promag> ..for now.. X)
07:33 < rafalcpp> hould we write own minimal process library?
07:33 < achow101> why not boost::process?
07:33 < rafalcpp> achow101: too new
07:33 < promag> is there anyone using *notify commands on windows?
07:34 < 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?
07: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.
07:34 < wumpus> promag: for example `execve` has a envp argument, you should really never have to use setenv()
07:34 < luke-jr> it's not ideal, but better than the alternatives I guess
07:35 < rafalcpp> gmaxwell: might be too dependant on other boost 
07:35 < 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)
07:35 < luke-jr> rafalcpp: might be, but probably not
07:35 < gmaxwell> ^
07:35  * rafalcpp bjam's it
07:35 < luke-jr> rafalcpp: prior to inclusion in boost, it was separate in fact
07:35 < luke-jr> gmaxwell: even if it's on boost koolaid, we use boost anyway, so that shouldn't be a big issue
07:36 < wumpus> luke-jr: unless it uses new boost features 
07:36 < luke-jr> true
07:36 < wumpus> (which could be expected if it's new code)
07:36 < luke-jr> but then we can just embed a copy of an older boost::process before it got merged
07:36 < luke-jr> assuming it's compatible
07:36 -!- jio [892bc4a4@gateway/web/freenode/ip.137.43.196.164] has quit [Ping timeout: 256 seconds]
07:36 < rafalcpp> luke-jr: soo yeah... let's just find the base library for process, review it based on boost::process experience and use that?
07:37 < 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
07:38 < 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
07:38 < wumpus> I think it's pointless to re-invent boost::process
07:38 < luke-jr> achow101: as we're learning with walletnotify, a single command is a mess
07:39 < luke-jr> so I think stdin would be preferred?
07:39 < 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"
07:39 < wumpus> I like waiting and doing nothing more
07:39 < promag> what does pyhton subprocess uses in windows?
07:39 < luke-jr> wumpus: just a limited copy used when boost is old, IMO
07:39 < rafalcpp>  " long attempt to get a boost.process library, which is going on since 2006. "  wow.
07:39 < achow101> luke-jr: it was the only way I could have every device have a consistent interface
07:39 < luke-jr> promag: Python is a giant blob
07:39 < achow101> otherwise some would require stdin for some thigns and others wouldn't
07:39 < luke-jr> achow101: ?
07:40 < wumpus> it's absurd that something simple like this is giving so much problems
07:40 < wumpus> bring back the 80's please
07:40 < luke-jr> anything you can do with a command line, you can do with stdin..
07:40 < gmaxwell> achow101: commandline lengths are limited, unfortunately. (also... not private)
07:40 < achow101> luke-jr: trezor asks for a scrambled pin. no other device does that
07:40 < luke-jr> achow101: so?
07:41 < 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
07:41 < luke-jr> achow101: I'm saying do EVERYTHING over stdin
07: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.
07:41 < luke-jr> gmaxwell: on Windows, the command line has no standard quoting
07:41 < gmaxwell> I'd always assumed this stuff would use stdin exclusively. 
07:42 < rafalcpp> so many ways to snoop on cmd args from other local users
07:42 < luke-jr> gmaxwell: the %w promag keeps bringing up is a mess because apparently we want to escape the wallet name
07:42 < rafalcpp> how about creating a tmp file (chmod for privacy), and pass it's name in arg?
07:42 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
07:42 < luke-jr> rafalcpp: …why?
07:43 < wumpus> nOoooOooo *screams*
07:43 < gmaxwell> rafalcpp: there be dragons,  decades of security disasters from that..
07:43 < 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?
07:43 < 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 ...
07:43 < gmaxwell> I think insecure tmp files is probably neck and neck with buffer overflows for the origin of the most CVEs.
07:43 < wumpus> we really can't afford stupid mistakes here
07:44 < wumpus> gmaxwell: as well as shell escaping issues
07:44 < wumpus> this is like bug paradise
07:44 < rafalcpp> just chmod it? and mktemp exists for atomic creation of unique file?
07:45 < wumpus> *cries*
07:45 < gmaxwell> rafalcpp: it's an ugly rathole. Stdin is a straight forward, clean solution.
07:45 < gmaxwell> It would be a 4-line no brainer except for windows.
07:45 < rafalcpp> btw, how about IPC or RPC?
07:46 < wumpus> chmod also isn't available on windows, or at least, very different
07:46 < gmaxwell> but it sounds like the boost thing handles windows fine.
07:46 < gmaxwell> rafalcpp: also a security disaster.
07:46 < wumpus> IPC or RPC is *more difficult* than stdin and stdout handling
07:46 < wumpus> it's also highly platform specific
07:46 < wumpus> especially if you want only the child process to be able to access it
07:46 < gmaxwell> (consider the recently published rpc cve in bitcoin that we basically cannot fix...)
07:47 -!- kallul [675b8056@gateway/web/freenode/ip.103.91.128.86] has joined #bitcoin-core-dev
07:47 -!- kallul [675b8056@gateway/web/freenode/ip.103.91.128.86] has quit [Client Quit]
07:48 < rafalcpp> you're right, stdin is most secure
07:48 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
07:49 < 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?
07:50 < wumpus> not more hacks
07:50 < wumpus> stop this
07:51 < promag> right, thanks
07:51 < 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)
07:53 < gmaxwell> I know, we could embed a SMTP mail user agent, and send email to the other process.
07:55 < gmaxwell> oh oh oh, I know. I know. We could use ... A BLOCKCHAIN.
07:55 < luke-jr> lol
07:55 < 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
07:55 < gmaxwell> first we'll issue utility tokens for interprocess communications....
07:55 < promag> smart processes? lgtm
07:57 < wumpus> yes dunno build a IoT toilet plunger that changes color on a new transaction for notification
07:57 < 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. 
07:58 < achow101> we can add an option to hwi to send all arguments over stdin. right now it's completely command line based
07:59 < wumpus> soo
07:59 < wumpus> my proposal would be: first build this with boost::process
07:59 < gmaxwell> achow101: presumably you lack tests with large PSBTs right now then. :)
07:59 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
07:59 < 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
08:00 < 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
08:01 < 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
08:01 < luke-jr> wumpus: good point, this can be an optional feature for newer boost versions for the initial PR, and then address that separately
08:01 < wumpus> luke-jr: +1
08:02 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
08:02 < gmaxwell> wumpus: or put in efforts to extract boost-process from boost and package it as a compat.
08:03 < wumpus> gmaxwell: right
08:05 < 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 :)
08:05 < provoostenator> achow101: the tests in #14912 (which is still based on popen) send a real (regtest) PSBT to a real command.
08:05 < gribble> https://github.com/bitcoin/bitcoin/issues/14912 | [WIP] External signer support (e.g. hardware wallet) by Sjors · Pull Request #14912 · bitcoin/bitcoin · GitHub
08:05 < provoostenator> But a rather small one, so I 'd have have to generate a bigger one in the functional test suite.
08:07 < 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 :-)
08:07 < wumpus> promag: I know I was originally against the idea of using an encoding but I had never expected to be like this
08:08 < wumpus> passing the information to the notify script through stdin would be a future option too I guess...
08:09 < 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.
08:09 < gribble> https://github.com/bitcoin/bitcoin/issues/14021 | Import key origin data through descriptors in importmulti by achow101 · Pull Request #14021 · bitcoin/bitcoin · GitHub
08:09 < 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
08:10 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:10 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/0d1160e42185...cbe7efe9ea6c
08:10 < bitcoin-git> bitcoin/master 5039e4b Julian Fleischer: Remove unnecessary const_cast
08:10 < bitcoin-git> bitcoin/master cbe7efe Wladimir J. van der Laan: Merge #15389: Remove unnecessary const_cast
08:10 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:10 < wumpus> provoostenator: yep; I see those are both already on the milestone
08:10 < wumpus> oh #14075 isn't
08:11 < 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
08:11 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:11 < bitcoin-git> [bitcoin] laanwj merged pull request #15389: Remove unnecessary const_cast (master...patch-1) https://github.com/bitcoin/bitcoin/pull/15389
08:11 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:14 < 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?)
08:15 < provoostenator> If so we'd still have to bump the minimum version and/or disable this feature for older versions.
08:20 -!- mistergold [~mistergol@77.243.25.26] has joined #bitcoin-core-dev
08:20 < achow101> what's the first version of boost with process?
08:20 < 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
08:20 < MarcoFalke> 1.64
08:20 < wumpus> yes, please just use boost::process for now we'll worry about the dependency stuff alter
08:21 < wumpus> let's spend time on desigining interesting features instead of crawling in the dependency mud
08:22 -!- mistergold [~mistergol@77.243.25.26] has quit [Read error: Connection reset by peer]
08:22 < wumpus> what's up with the last-minute qt bump?
08:22 < wumpus> #15393
08:22 < 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
08:23 < MarcoFalke> It was an open issue for months
08:23 < MarcoFalke> It never compiled on anything less for all those months anyway
08:23 < wumpus> so you mean, currently depends doesn't build?
08:24 < provoostenator> Depends works fine, it's at 5.9
08:24 < MarcoFalke> no system qt
08:24 < wumpus> OHH
08:24 < wumpus> sorry I misread the PR title
08:24 < wumpus> I thought this was a depends bump
08:24 < MarcoFalke> Ah
08:25 < provoostenator> jnewbery: is there a way to skip a test on Windows (or AppVeyor)?
08:25 < MarcoFalke> --exclude test_name
08:25 < provoostenator> Or at least to detect the OS.
08:25 < MarcoFalke> Oh, wait
08:26 < MarcoFalke> Just do it similar to how the wallet tests are skipped
08:27 < provoostenator> Yeah, putting --exclude test_name in the appveyor script seems a bit brittle and easy to miss.
08:27 < MarcoFalke> def skip_test_if_missing_module
08:27 < MarcoFalke> Just consider Windows a "module" ;)
08:27 < MarcoFalke> or the os
08:27 < provoostenator> def skip_if_windows I guess
08:28 < provoostenator> Actually I won't even need that if I just switch to Boost, but I'll keep it in mind.
08:28 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
08:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 258 seconds]
08:41 < wumpus> is #14289 something that needs to be solved before 0.18 release?
08:41 < gribble> https://github.com/bitcoin/bitcoin/issues/14289 | Unbounded growth of scheduler queue · Issue #14289 · bitcoin/bitcoin · GitHub
08:42 < wumpus> (if so, is anyone working on it?)
08:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:43 < 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
08:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:45 < 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.
08:46 < gmaxwell> it also screws up the usability of invalidateblock/reconsider block for testing.
08:46 < wumpus> yes, it's a bad issue, there's just not that much time left
08:47 < 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
08:47 < wumpus> I noticed it again because it has a 0.18.0 milestone
08:49 < gmaxwell> :(
08:49 < wumpus> same for #13103 unless the windows encoding changes already merged solve it
08:49 < gribble> https://github.com/bitcoin/bitcoin/issues/13103 | Invalid wallet path with Chinese characters in windows · Issue #13103 · bitcoin/bitcoin · GitHub
08:50 < wumpus> there's a lot of PRs to merge before 0.18 but only few of them also solve issues tagged 0.18 :o
08:52 < wumpus> #13129 seems irrelevant to have tagged for 0.18
08:52 < gribble> https://github.com/bitcoin/bitcoin/issues/13129 | Meta-issue: Add Clang thread safety analysis annotations · Issue #13129 · bitcoin/bitcoin · GitHub
08:56 -!- pbase [~pbase@unaffiliated/pbase] has joined #bitcoin-core-dev
09:03 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
09:04 -!- jungly [~quassel@79.8.200.97] has quit [Remote host closed the connection]
09:06 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection]
09:07 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
09:14 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev
09:54 -!- traizzl [892b2013@gateway/web/freenode/ip.137.43.32.19] has joined #bitcoin-core-dev
09:58 -!- pinheadmz [~matthewzi@104-56-112-203.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
09:59 -!- mistergold [~mistergol@77.243.25.26] has joined #bitcoin-core-dev
09:59 -!- traizzl [892b2013@gateway/web/freenode/ip.137.43.32.19] has quit [Quit: Page closed]
10:03 < provoostenator> Switching to boost::process was pretty easy (so far). Let's see if it actually works in Windows...
10:08 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has quit [Quit: Leaving...]
10:09 -!- rex4539 [~rex4539@ppp-2-84-161-162.home.otenet.gr] has joined #bitcoin-core-dev
10:14 -!- Karyon [~karyon@unaffiliated/karyon] has joined #bitcoin-core-dev
10:19 < wumpus> provoostenator: that's good news, hope so!
10:19 -!- Randolf [~randolf@96.53.47.42] has quit [Quit: Leaving]
10:22 -!- pbase [~pbase@unaffiliated/pbase] has quit [Ping timeout: 268 seconds]
10:24 < wumpus> does anyone have a CPU with rdrand/rdseed support? (it will show in /proc/cpuinfo) please help test #15250
10:24 < gribble> https://github.com/bitcoin/bitcoin/issues/15250 | Use RdSeed when available, and reduce RdRand load by sipa · Pull Request #15250 · bitcoin/bitcoin · GitHub
10:26 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving]
10:26 < gmaxwell> or, without them. :)
10:34 -!- michaels_ [~michaelsd@208.59.170.5] has quit [Remote host closed the connection]
10:34 < wumpus> yes that's worthwhile to test too, at least here it seems to detect the fact that the instructions aren't available correctly
10:35 < sipa> wumpus: yes, it works for me :p
10:35 < wumpus> I've also checked that gcc does in fact generate them
10:35 < sipa> (at least, it reports "Using RdSeed as an additional randomness source")
10:35 < wumpus> good!
10:35 < sipa> i also have a system which supports rdrand but not rdseed
10:35 < sipa> i'll test on that
10:36 -!- michaels_ [~michaelsd@208.59.170.5] has joined #bitcoin-core-dev
10:40 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has joined #bitcoin-core-dev
10:42 < 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."
10:43 < sipa> ha
10:43 < sipa> i hadn't even considered that the pause instruction might have been a compatibility issue
10:46 < wumpus> :D
10:46 < gmaxwell> I had.
10:46 < gmaxwell> :P
10:48 < 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
10:49 -!- ovovo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
10:50 < provoostenator> Travis is happy, but AppVeyor seems to need additional magic to find boost::process : https://ci.appveyor.com/project/DrahtBot/bitcoin/builds/22347238
10:50 < provoostenator> And those logs are useless
10:50 < wumpus> yeh Appveyor logs are quite useless usually
10:51 < jarthur> I'm on an x86_64 macOS 10.13.6 box w/ RDRAND and RDSEED. How to test this, wumpus?
10:51 < jarthur> Build sipa's branch and check the debug.log?
10:51 < 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
10:52 < jarthur> thanks
10:52 < wumpus> and ofc check if the unit tests and functional test suite pass
10:52 < wumpus> I'm honestly not sure how to test reliability of random number generation otherwise
10:53 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 268 seconds]
10:53 < jarthur> We may be able to add some entropy scoring in the functional tests if there isn't already something like that.
10:54 < wumpus> there isn't, at the moment
10:56 -!- Karyon [~karyon@unaffiliated/karyon] has quit [Ping timeout: 252 seconds]
10:57 -!- spinza [~spin@155.93.246.187] has quit [Ping timeout: 268 seconds]
11:06 -!- mistergold [~mistergol@77.243.25.26] has quit [Read error: Connection reset by peer]
11:10 < 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 
11:10 < gribble> https://github.com/bitcoin/bitcoin/issues/14241 | appveyor: script improvement by ken2812221 · Pull Request #14241 · bitcoin/bitcoin · GitHub
11:19 < wumpus> oh yes msvc windows-land is like that, mingw-w64 windows-land should just work
11:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:21 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #15399: fuzz: Script validation flags (master...Mf1902-fuzzSoft) https://github.com/bitcoin/bitcoin/pull/15399
11:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:24 < sipa> wumpus: seems to work fine on rdrand-not-rdseed
11:25 -!- siom [~siom@31.13.191.152] has quit [Remote host closed the connection]
11:25 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
11:31 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.3]
11:33 -!- michaels_ [~michaelsd@208.59.170.5] has quit [Remote host closed the connection]
11:33 < wumpus> sipa: nice!
11:36 < jarthur> Is p2p_invalid_messages.py test known to be broken on macOS? Got a Protocol wrong type for socket error.
11:37 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
11:40 < jarthur> Tested fine on rdrand-and-rdseed, either way
11:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
11:44 < jarthur> looks like p2p_invalid_messages failure was from node closing sooner than expected and a subsequent write realizing the RST error.
11:45 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
11:46 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has quit [Ping timeout: 245 seconds]
11:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds]
11:49 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has joined #bitcoin-core-dev
11:53 < wumpus> jarthur: on P2P? I don't think that's a known issue
11:55 < wumpus> if you can reproduce it, please open an issue
11:55 -!- michaels_ [~michaelsd@208.59.170.5] has joined #bitcoin-core-dev
11:57 < 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
11:57 < instagibbs> and it'll only happen once
11:57 < gribble> https://github.com/bitcoin/bitcoin/issues/14021 | Import key origin data through descriptors in importmulti by achow101 · Pull Request #14021 · bitcoin/bitcoin · GitHub
11:57 < instagibbs> less stressful than running a single "listunspent"
11:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
11:59 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
12:01 < jarthur> wumpus: will do, probably tonight or tomorrow
12:03 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has quit [Quit: Textual IRC Client: www.textualapp.com]
12:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 244 seconds]
12:09 < achow101> instagibbs: while thinking about that problem. i realized that current master is also broken in the same way
12:09 < instagibbs> what specifically?
12:10 < 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
12:10 < instagibbs> ah
12:10 < instagibbs> welp
12:12 < achow101> if we do it on first unlock, a user could make a psbt that has a bogus fingerprint
12:15 < achow101> i guess we could make walletprocesspsbt throw an error if the key metadata isn't updated?
12:18 -!- millerti [~millerti@cpe-66-24-91-119.stny.res.rr.com] has quit [Read error: Connection reset by peer]
12:21 -!- pinheadmz [~matthewzi@104-56-112-203.lightspeed.sntcca.sbcglobal.net] has quit [Quit: pinheadmz]
12:22 -!- pinheadmz [~matthewzi@104-56-112-203.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
12:24 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection]
12:24 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
12:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
12:31 < wumpus> jarthur: thanks
12:34 -!- marcoagner [~user@2001:8a0:fecd:a201:783b:bb47:4cb2:850] has joined #bitcoin-core-dev
12:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds]
12:38 -!- x4b1d [~nobody@unaffiliated/x4b1d] has joined #bitcoin-core-dev
12:39 < x4b1d> Anyone seen good code examples of offline signing outside of using bitcoind?
12:40 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection]
12:41 < wumpus> maybe some FOSS hw wallet firmware like the trezor one?
12:41 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
12:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
12:48 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
12:49 < 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!
12:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:50 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/cbe7efe9ea6c...9c4a90040dd3
12:50 < bitcoin-git> bitcoin/master 318b1f7 John Newbery: [wallet] Close bdb when flushing wallet.
12:50 < bitcoin-git> bitcoin/master 9c4a900 MarcoFalke: Merge #15390: [wallet-tool] Close bdb when flushing wallet
12:50 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:50 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]
12:50 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:50 < 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
12:50 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:52 < x4b1d> wumpus: achow101 yeah I haven't actually seen a lot of offline signing functionality anywhee that seems to conform since 2014
12:53 < wumpus> achow101: fair enough, but that's also true when you use bitcoind for offline signing, you have to provide the previous outputs yourself
12:53 -!- Karyon [~karyon@unaffiliated/karyon] has joined #bitcoin-core-dev
12:54 < achow101> x4b1d: maybe have a look at armory? it's entire goal is to do offline signing
12:55 < echeveria> achow101: armory is highly is advisable.
12:55 < echeveria> inadvisable. it has long standing implementation issues and a history of losing money. it’s not strongly maintained.
12:56 < 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
12:57 < x4b1d> doesn't armory just rpc into bitcoind ?
12:57 < wumpus> achow101: calling into a centralized server is kinda meh though I agree
12:57 < sipa> #bitcoin
12:57 < achow101> x4b1d: no. it only uses bitcoind for connection to the network
13:02 < wumpus> yea #bitcoin is better for questions like this as they don't involve bitcoin core development
13:05 < 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
13:06 < wumpus> well *that* would be on topic
13:06 < wumpus> FWIW I think that would be a good idea
13:07 < wumpus> the RPC pure utility functions (that don't need a node, wallet) could be a library
13:07 < x4b1d> god I wish I had that
13:08 < sipa> libwally has a bunch of functions
13:09 < wumpus> yes, that one is used by clightning for example
13:09 < sipa> but a standalone library/tool that can do psbt signing would be pretty nice
13:09 < 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
13:11 < x4b1d> would be so happy to see that as a development
13:19 < achow101> what's up with travis? the linter target is failing since python 3.4 couldn't be downloaded
13:19 < wumpus> achow101: haven't noticed yet, where is that?
13:20 < achow101> https://travis-ci.org/bitcoin/bitcoin/jobs/492915824
13:21 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
13:21 < wumpus> -restarted
13:21 < achow101> seems to have just became a problem within the last hour
13:21 < achow101> (i've tried restarting already and it didn't fix it)
13:21 < wumpus> ohh
13:22 < wumpus> dead python 3.4 then
13:22 < achow101> rip
13:23 < wumpus> Downloading archive: https://s3.amazonaws.com/travis-python-archives/binaries/ubuntu/16.04/x86_64/python-3.4.tar.bz2
13:23 < wumpus> $ curl -sSf -o python-3.4.tar.bz2 ${archive_url}
13:23 < wumpus> curl: (22) The requested URL returned error: 403 Forbidden
13:25 < 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
13:25 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds]
13:26 < wumpus> it's *before* our script takes action so nothing we can do I think
13:27 < achow101> yeah... i'll contact their support
13:29 < wumpus> thanks !
13:31 < 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.
13:31 < jarthur> wumpus Did a little bit of due-dilligence and filed the p2p_invalid_messages issue as #15400
13:31 < 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
13:31 < wumpus> jarthur: interesting
13:32 < wumpus> we've certainly run into problems with this before, with tests failing simply due to unexpected stderr output
13:34 < wumpus> okay this is definitely something else it happens in python itself
13:37 < 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.
13:38 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
13:41 < 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
13:41 < 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
13:42 < 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
13:43 < sipa> agree
13:43 < sipa> (in general, i haven't looked at the pr)
13:43 < wumpus> it's been open for a while but I think it just WTFs everyone
13:45 < wumpus> (and I don't think the issue with it was indentation)
13:47 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has quit [Quit: Snoozing.]
13:48 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:48 < 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
13:48 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:52 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9c4a90040dd3...9c93f5d9fc93
13:52 < bitcoin-git> bitcoin/master a4b92e4 Hennadii Stepanov: Log full paths for wallets
13:52 < bitcoin-git> bitcoin/master 9c93f5d Wladimir J. van der Laan: Merge #15334: wallet: Log absolute paths for the wallets
13:52 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
13:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:52 < 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
13:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:54 < wumpus> "throw help" hehe
13:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds]
13:58 -!- bralyclo_ [bralyclow@gateway/vpn/protonvpn/bralyclow] has joined #bitcoin-core-dev
13:58 < MarcoFalke> I don't understand what #15140 is trying to do
13:58 < 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
13:58 < wumpus> same
13:59 < MarcoFalke> A comment with "//---------><----- cut here"
13:59  * MarcoFalke takes scissors and cuts the monitor
13:59 < 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
14:01 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has joined #bitcoin-core-dev
14:01 < sipa> oh, i get it
14:01 < sipa> the test is broken
14:01 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-ebjfudelljktfbxq] has joined #bitcoin-core-dev
14:01 -!- bralyclow [bralyclow@gateway/vpn/protonvpn/bralyclow] has quit [Ping timeout: 246 seconds]
14:02 < wumpus> oh!
14:02 < 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)
14:02 < sipa> but the OP_PUSHDATA2 and OP_PUSHDATA4 opcodes are missing from the test; so they correctly fail, but for the wrong reason
14:02 < sipa> and the cut thing is because he gives 2 versions
14:03 < wumpus> that's where it gets confusing
14:03 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
14:04 < wumpus> if the opcodes are missing, the fix would seem to be to add the opcodes, not duplicate the entire test
14:04 < sipa> that's what his first version does
14:04 < wumpus> right
14:13 < wumpus> so that would seem to be enough
14:23 < wumpus>  #15257 really has a crapload of changes just to make the new version of the python linter happy
14:23 < 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
14:29 < achow101> travis seems to have fixed itself
14:30 < wumpus> good, problems that fix themselves just by waiting are the best
14:31 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
14:32 < wumpus> hopefully it's not a transient issue that will come back, e.g. because of changing IP
14:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
14:33 -!- shesek`` [~shesek@141.226.217.238] has joined #bitcoin-core-dev
14:39 < 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.
14:40 -!- michaels_ [~michaelsd@208.59.170.5] has quit [Remote host closed the connection]
14:44 -!- mistergold [~mistergol@77.243.25.26] has joined #bitcoin-core-dev
14:50 -!- michaels_ [~michaelsd@208.59.170.5] has joined #bitcoin-core-dev
14:54 -!- michaels_ [~michaelsd@208.59.170.5] has quit [Ping timeout: 246 seconds]
14:54 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection]
14:55 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
15:00 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has quit [Ping timeout: 256 seconds]
15:06 < MarcoFalke> Eh, the travis issue (failed to fetch  py3.4) is transient 
15:06 < MarcoFalke> I've seen it for weeks
15:07 < wumpus> we both tried restarting and that didn't solve it
15:18 < wumpus> could be that simply restarting doesn't re-assign the ip
15:19 -!- mave [536320ed@gateway/web/freenode/ip.83.99.32.237] has joined #bitcoin-core-dev
15:19 < mave> hi
15:19 < jarthur> 'lo
15:20 < 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)
15:20 < mryandao> you have to tell it
15:20 < mryandao> or it creates a new $HOME/.bitcoin/
15:21 < mave> I'm not telling it and it's finding my /disco-dos/bitcoin-data/ directory :o
15:21 < mave> I'm confused as to how
15:21 < mryandao> o.O 
15:21 < mave> I just start it up with bitcoin-qt
15:21 < mave> with an empty $HOME/.bitcoin
15:21 < mave> and it correctly finds my datadir
15:21 < jarthur> What platform? And is it in finding the wallet in there? Blockchain data, all of the above?
15:22 < mave> ubuntu
15:22 < mave> bitcoind
15:22 < mave> compiled from source recently
15:22 < mave> yes, it is finding everything correctly (which is unexpected as I deleted $HOME/.bitcoin on purpose)
15:22 < luke-jr> mave: bitcoind or bitcoin-qt?
15:23 < mave> I compiled both
15:23 < luke-jr> which are you using?
15:23 < mave> the one that's surprising me is bitcoin-qt
15:23 < luke-jr> cat ~/.config/Bitcoin/Bitcoin-Qt.conf
15:23 < mave> for this use case it's bitcoin-qt
15:24 < mave> aah, so it has a different set of config files
15:24 < mave> I thought it would read from $HOME/.bitcoin/bitcoin.conf
15:25 < luke-jr> it will read that too
15:25 < luke-jr> well, if $HOME/.bitcoin is your datadir ;)
15:25 < mave> my datadir I specify manually when starting bitcoind
15:25 < mave> but I don't when starting bitcoin-qt
15:25 -!- michaels_ [~michaelsd@208.59.170.5] has joined #bitcoin-core-dev
15:25 < mave> hence my surprise to see that bitcoin-qt could find my datadir
15:26 < mave> I now understand that bitcoin-qt has some other set of config files under $HOME/.config/Bitcoin
15:26 < mave> however looking into them I don't find any pointer to my datadir
15:28 < jarthur> What do you see for "Default data directory" and "Using data directory" in debug.log for the -Qt session?
15:29 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
15:30 < mave> Default data directory /home/roge/.bitcoin
15:30 -!- michaels_ [~michaelsd@208.59.170.5] has quit [Ping timeout: 272 seconds]
15:31 < mave> which is my $HOME/.bitcoin
15:31 < mave> and is different from my datadir
15:32 -!- timothy [~tredaelli@redhat/timothy] has quit [Remote host closed the connection]
15:33 -!- murrayn [~murrayn@S0106f8a097f16608.ok.shawcable.net] has joined #bitcoin-core-dev
15:33 -!- murrayn [~murrayn@S0106f8a097f16608.ok.shawcable.net] has quit [Changing host]
15:33 -!- murrayn [~murrayn@unaffiliated/murrayn] has joined #bitcoin-core-dev
15:33  * mave sits back
15:35 < jarthur> So it says "Using data directory /disco-dos/bitcoin-data/" shortly after that?
15:35 < 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?
15:35 < 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
15:36 < mave> 2019-02-13 23:34:57 Bitcoin Core version v0.16.0 (release build)
15:36 < mave> 2019-02-13 23:34:57 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
15:36 < mave> 2019-02-13 23:34:57 Assuming ancestors of block 0000000002e9e7b00e1f6dc5123a04aad68dd0f0968d8c7aa45f6640795c37b1 have valid signatures.
15:36 < mave> 2019-02-13 23:34:57 Setting nMinimumChainWork=00000000000000000000000000000000000000000000002830dab7f76dbb7d63
15:36 < mave> 2019-02-13 23:34:57 Using the 'sse4' SHA256 implementation            
15:36 < mave> 2019-02-13 23:34:57 Using RdRand as an additional entropy source              
15:37 < mave> 2019-02-13 23:34:57 Default data directory /home/roge/.bitcoin             
15:37 < mave> 2019-02-13 23:34:57 Using data directory /disco-dos/bitcoin-data/testnet3
15:37 < mave> 2019-02-13 23:34:57 Using config file /disco-dos/bitcoin-data/bitcoin.conf
15:37 < mave> it says it's using /home/roge/.bitcoin  as default data dir 
15:37 < sipa> mave: please don't spam the channel
15:37 < mave> this dir is empty
15:38 < sipa> copy-pasting more than 3 lines is considered impolite on IRC
15:38 < mave> @sipa, sorry, I'm new here
15:38 < mave> I just wanted to answer luke-jr's question
15:38 -!- Aaronva__ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
15:38 < sipa> mave: ok, use a pastebin site next time
15:39 < promag> use https://pastebin.com/
15:39 < luke-jr> I only asked for 2 lines -.-
15:39 < mave> so, the debug.log says it's using as default data dir /home/roge/.bitcoin which is empty on purpose
15:39 < mave> and on the next debug.log line it says it's using as datadir /disco-dos/bitcoin-data/testnet3 which is correct
15:40 < jarthur> Alright, how are you opening Bitcoin-Qt, and are you passing it that conf file at the command line?
15:40 < mave> nope, I'm running it from shell just using the command bitcoin-qt, no params
15:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds]
15:41 < sipa> is the datadir maybe stored in the Qt config?
15:41 < mave> there is no qt-config that I am aware of aside from bitcoin.conf
15:42 < sipa> bitcoin-qt has its own config, but i don't know the details
15:43 < luke-jr> sipa: assuming you mean ~/.config/Bitcoin/Bitcoin-Qt.conf , he said he already checked it
15:43 < sipa> ah
15:43 < sipa> yes
15:43 < mave> yes, I checked those files and there is no ref to my datadir
15:44 < mave> never mind
15:44 < mave> I found it
15:44 < luke-jr> where?
15:45 < mave> you were right luke-jr
15:45 < mave> grep disco-dos * found it for me 
15:45 < mave> it was as you said
15:45 < mave> under .config/Bitcoin/Bitcoin-QT.conf
15:45 < mave> strDataDir=
15:45 < mave> mistery solved :)
15:45 < jarthur> Cool. I hate mysteries.
15:45 < luke-jr> I was about to suggest strace <.<
15:45 < mave> haha
15:46 < mave> thanks for the welcome help
15:46 < promag> jarthur: The End
15:46 < mave> cool irc channel :)
15:47 -!- mistergold [~mistergol@77.243.25.26] has quit [Read error: Connection reset by peer]
15:47 < jarthur> :)
15:59 -!- mave [536320ed@gateway/web/freenode/ip.83.99.32.237] has quit [Quit: Page closed]
16:05 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
16:05 -!- michaels_ [~michaelsd@208.59.170.5] has joined #bitcoin-core-dev
16:07 -!- Aaronva__ is now known as AaronvanW
16:10 -!- michaels_ [~michaelsd@208.59.170.5] has quit [Ping timeout: 250 seconds]
16:25 -!- Karyon [~karyon@unaffiliated/karyon] has quit [Quit: Leaving]
16:34 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Ping timeout: 246 seconds]
16:34 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
16:39 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has quit [Quit: Snoozing.]
16:45 -!- michaels_ [~michaelsd@208.59.170.5] has joined #bitcoin-core-dev
16:46 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has joined #bitcoin-core-dev
16:50 -!- michaels_ [~michaelsd@208.59.170.5] has quit [Ping timeout: 257 seconds]
16:52 -!- jarthur [~jarthur@207.114.244.5] has quit []
17:11 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-ebjfudelljktfbxq] has quit [Quit: Connection closed for inactivity]
17:11 -!- profmac [~ProfMac@2001:470:1f0f:226:b003:d1c5:b7c:b4ba] has quit [Ping timeout: 268 seconds]
17:11 -!- pinheadmz [~matthewzi@104-56-112-203.lightspeed.sntcca.sbcglobal.net] has quit [Quit: pinheadmz]
17:14 < gwillen> do I need to get more people to look at #14978
17:14 < gribble> https://github.com/bitcoin/bitcoin/issues/14978 | Factor out PSBT utilities from RPCs for use in GUI code; related refactoring. by gwillen · Pull Request #14978 · bitcoin/bitcoin · GitHub
17:14 < gwillen> it feels like it is almost there :-)
17:18 -!- michaels_ [~michaelsd@208.59.170.5] has joined #bitcoin-core-dev
17:19 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
17:24 -!- michaels_ [~michaelsd@208.59.170.5] has quit [Ping timeout: 272 seconds]
17:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
17:27 < bitcoin-git> [bitcoin] sipa opened pull request #15402: Granular invalidateblock and RewindBlockIndex (master...201902_limitrewindinvalidate) https://github.com/bitcoin/bitcoin/pull/15402
17:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
17:29 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
17:30 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #bitcoin-core-dev
17:32 < sipa> gmaxwell, wumpus: ^
17:32 < sipa> infinite depth invalidateblock
17:38 -!- michaels_ [~michaelsd@208.59.170.5] has joined #bitcoin-core-dev
17:39 < gmaxwell> rewinding irrelevancy is also because the rewind is slow... 
17:39 < gmaxwell> might even be faster to reindex now
17:40 -!- ExtraCrispy [~ExtraCris@gateway/tor-sasl/extracrispy] has quit [Ping timeout: 256 seconds]
17:41 < sipa> it very likely is
17:41 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection]
17:42 -!- michaels_ [~michaelsd@208.59.170.5] has quit [Ping timeout: 268 seconds]
17:43 -!- ExtraCrispy [~ExtraCris@gateway/tor-sasl/extracrispy] has joined #bitcoin-core-dev
17:50 -!- profmac [~ProfMac@2001:470:1f0f:226:65f7:305:2721:bd6] has joined #bitcoin-core-dev
18:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds]
18:12 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
18:14 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has quit [Ping timeout: 256 seconds]
18:21 < meshcollider> gwillen: I agree, it'd be good to get a post-rebase re-ACK from someone though
18:21 < meshcollider> Or a review from ryanofsky who had commented on it a few times
18:34 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Quit: drexl]
18:45 -!- ExtraCrispy [~ExtraCris@gateway/tor-sasl/extracrispy] has quit [Ping timeout: 256 seconds]
19:02 -!- TX1683 [~TX1683@unaffiliated/tx1683] has quit [Ping timeout: 272 seconds]
19:09 -!- TX1683 [~TX1683@unaffiliated/tx1683] has joined #bitcoin-core-dev
19:50 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Remote host closed the connection]
19:51 -!- rh0nj [~rh0nj@88.99.167.175] has joined #bitcoin-core-dev
19:54 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
19:55 < gwillen> thanks achow101 :-)
20:07 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
20:37 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds]
20:40 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
20:41 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Client Quit]
20:42 -!- jtimon [~quassel@92.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 250 seconds]
20:52 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
20:53 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
21:08 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
21:15 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has joined #bitcoin-core-dev
21:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
21:18 < bitcoin-git> [bitcoin] amitiuttarwar opened pull request #15404: [test] Remove -txindex to start nodes (master...remove_txindex) https://github.com/bitcoin/bitcoin/pull/15404
21:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
21:41 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
21:44 -!- yoyo_ [6d9af433@gateway/web/freenode/ip.109.154.244.51] has joined #bitcoin-core-dev
21:45 -!- yoyo_ [6d9af433@gateway/web/freenode/ip.109.154.244.51] has quit [Client Quit]
21:50 -!- bralyclow [bralyclow@gateway/vpn/protonvpn/bralyclow] has joined #bitcoin-core-dev
21:53 -!- bralyclo_ [bralyclow@gateway/vpn/protonvpn/bralyclow] has quit [Ping timeout: 245 seconds]
21:56 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
22:29 -!- zhangzf [~zhangzf@106.38.157.147] has joined #bitcoin-core-dev
22:44 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
22:51  * kallewoof wonders why appveyor is failing on master
22:54 -!- rhavar [uid237883@gateway/web/irccloud.com/x-honrlkfrcjmplfyj] has joined #bitcoin-core-dev
22:54  * sipa also
22:55 < sipa> something something leveldb linket error
23:02 -!- anonymous8587 [~Mutter@46.183.103.8] has joined #bitcoin-core-dev
23:04 -!- anonymous8587_ [~Mutter@2a01:598:8988:37b1:1189:1565:4426:c1f9] has joined #bitcoin-core-dev
23:04 -!- anonymous8587 [~Mutter@46.183.103.8] has quit [Read error: Connection reset by peer]
23:06 -!- anonymous8587_ [~Mutter@2a01:598:8988:37b1:1189:1565:4426:c1f9] has quit [Client Quit]
23:06 -!- anonymous8587 [~Mutter@46.183.103.8] has joined #bitcoin-core-dev
23:08 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
23:09 -!- anonymous8587 [~Mutter@46.183.103.8] has quit [Client Quit]
23:09 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has quit [Remote host closed the connection]
23:09 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has joined #bitcoin-core-dev
23:29 < kallewoof> yeah. i can't see the reason why that would start happening though. the latest merged commits seem to have passed.
23:38 -!- ap4lmtree- [ap4lmtree@unaffiliated/ap4lmtree] has joined #bitcoin-core-dev
23:38 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has quit [Ping timeout: 245 seconds]
23:51 < wumpus> sipa: neat!
23:55 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has quit [Ping timeout: 256 seconds]
23:57 -!- anonymous8587 [~Mutter@2a01:598:8988:37b1:1189:1565:4426:c1f9] has joined #bitcoin-core-dev
--- Log closed Thu Feb 14 00:00:10 2019