--- Day changed Sun Oct 18 2015
00:09 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-cwdwpaiyuyohbdkz] has joined #bitcoin-core-dev
00:26 -!- maaku [~quassel@botbot.xen.prgmr.com] has quit [Remote host closed the connection]
00:28 -!- maaku [~quassel@botbot.xen.prgmr.com] has joined #bitcoin-core-dev
00:28 -!- maaku is now known as Guest88932
00:31 -!- Guest88932 is now known as maaku
00:36 < JoeLiu>  Is there any book for Bitcoin developping?
00:36 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
00:53 -!- CodeShark [~androirc@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev
00:54 < Luke-Jr> JoeLiu: bitcoin.org has some useful documentation
01:04 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev
01:04 < dcousens> gmaxwell: you around?
01:04 < dcousens> Just had my node drop, was curious why
01:04 < dcousens> bitcoind
01:04 < dcousens> Killed
01:04 < dcousens> Nothing more on the console
01:05 < dcousens> last few messages on the debug.log are 2015-10-16 18:14:46 socket sending timeout: 37784s
01:06 < phantomcircuit> dcousens, run dmesg
01:06 < phantomcircuit> im guessing out of memory
01:06 < dcousens> ta, ya OOM.
01:07 < dcousens> Though shouldn't have bitcoind thrown an error std::bad_alloc etc?
01:08 < dcousens> is there any way I can stop this from happening?
01:08 < dcousens> I had a higher minrelaytxfee
01:11 < phantomcircuit> dcousens, how much memory do you have?
01:11 < dcousens> phantomcircuit: on this node? 2GB
01:12 < phantomcircuit> drop the maxconnections limit is probably what you have to do
01:12 < phantomcircuit> unfortunately
01:12 < dcousens> would just setting an even higher relay fee work maybe?
01:12 < dcousens> also,  whats the easiest way to track this data over time?
01:12 < dcousens> (like, say, process v mempool MB size)
01:14 < phantomcircuit> dcousens, you can call getmempoolinfo and dump that to a file somewhere
01:16 < Luke-Jr> 2 GB is plenty. Probably your relay policy is too broad and is storing spam.
01:36 -!- aj__ is now known as aj
02:19 < dcousens>  Luke-Jr: default policy, so probably
02:20 < dcousens> 0.12 couldn't come sooner :)
02:21 < Luke-Jr> software versions are not for policies.
02:21 < Luke-Jr> you're supposed to configure that yourself
02:24 < dcousens> Luke-Jr: if I were to configure this node for what it is being paid to do,  it'd be a leech solely
02:24 < dcousens> I don't have time to allocate to configuring policy, so, the defaults matter
02:24 < dcousens> Maybe if policy was as simple as dropping in some pre-written CPP files that there were a library of somewhere
02:25 < dcousens> But, I'm not aware (nor is it advertised) of that
02:26 < dcousens> (by leech solely, I mean, it'd only download blocks, no relay whatsoever)
02:28 < Luke-Jr> then you get to deal with the unlimited resource consumption. we don't have time to help you.
02:30 < Luke-Jr> deciding and configuring policy is part of the job of running a node, *especially* if you're being paid to do it..
02:31 < dcousens> Luke-Jr: lol, conceptually I agree with you, but pragmatically things tend to be different
02:32 < Luke-Jr> instead you get paid to do it, and then go insist others do your job on their unpaid (at least by you) time..
02:33 < dcousens> Luke-Jr: I wasn't insisting anything? 
02:33 < Luke-Jr> [09:20:08] <dcousens> 0.12 couldn't come sooner ☺ [09:24:34] <dcousens> I don't have time to allocate to configuring policy, so, the defaults matter
02:33 < Luke-Jr> sure sounds like it
02:34 < dcousens> I understand the implications of OSS,  its all I do all day
02:34 < Luke-Jr> pragmatically, you're the one left without a working node, and having to explain to whoever is paying you why you're not doing the job
02:34 < dcousens> Doesn't mean I can't express interest in some of the changes that will be deployed as defaults in 0.12
02:35 < Luke-Jr> dcousens: we adopted a "don't change default policy" principle a bit ago. maybe we should have stuck to it stronger..
02:36  * Luke-Jr goes to bed.
02:37 < dcousens> Luke-Jr: night,  sorry you took my comments the wrong way.  phantomcircuit thanks for the help
02:55 -!- JoeLiu [uid88238@gateway/web/irccloud.com/x-pgrnmyjmjgogushq] has quit [Quit: Connection closed for inactivity]
03:03 < GitHub28> [bitcoin] dcousens opened pull request #6846: bitcoind: alias -h for --help (master...aliash) https://github.com/bitcoin/bitcoin/pull/6846
03:06 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
03:45 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
04:16 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Quit: Lost terminal]
04:25 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
08:03 -!- Guest13178 is now known as GAit
08:44 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
08:47 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
08:49 -!- BananaLotus [~BananaLot@54.186.186.141] has quit [Ping timeout: 240 seconds]
08:50 -!- guruvan [~guruvan@unaffiliated/guruvan] has quit [Ping timeout: 240 seconds]
08:50 -!- BananaLotus [~BananaLot@54.186.186.141] has joined #bitcoin-core-dev
08:51 -!- BananaLotus [~BananaLot@54.186.186.141] has quit [Excess Flood]
08:54 -!- BananaLotus [~BananaLot@54.186.186.141] has joined #bitcoin-core-dev
08:55 -!- guruvan [~guruvan@unaffiliated/guruvan] has joined #bitcoin-core-dev
09:18 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
09:18 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Max SendQ exceeded]
09:18 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
09:29 < GitHub58> [bitcoin] rnicoll opened pull request #6848: Add DERSIG transaction test cases (master...bip66-tests) https://github.com/bitcoin/bitcoin/pull/6848
09:48 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
09:56 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
09:57 -!- rrrandom [~user@94.14.150.26] has joined #bitcoin-core-dev
09:57 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
09:58 -!- belcher [~user@unaffiliated/belcher] has quit [Ping timeout: 255 seconds]
10:00 -!- rrrandom [~user@94.14.150.26] has quit [Client Quit]
10:01 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
10:01 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
10:11 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
10:25 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
11:26 < GitHub31> [bitcoin] afk11 opened pull request #6849: Mention PHP bindings to libbitcoinconsensus (master...bitcoinconsensus-php-bindings) https://github.com/bitcoin/bitcoin/pull/6849
12:20 -!- ParadoxSpiral [~ParadoxSp@p508B816E.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
12:26 -!- ParadoxSpiral [~ParadoxSp@p508B816E.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds]
12:26 -!- JoeLiu [uid88238@gateway/web/irccloud.com/x-fqzhuigtbjqerfbu] has joined #bitcoin-core-dev
12:28 -!- ParadoxSpiral [~ParadoxSp@p508B816E.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
12:32 < GitHub197> [bitcoin] bittylicious opened pull request #6850: Improve AddToWallet performance when rescanning (master...master) https://github.com/bitcoin/bitcoin/pull/6850
12:34 < gmaxwell> Luke-Jr: ^
13:00 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
13:11 -!- belcher [~user@unaffiliated/belcher] has quit [Ping timeout: 252 seconds]
13:11 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
13:17 < gmaxwell> Luke-Jr: So I'd rather remove smart times completely than have rescans take 9.5 hours longer in that case. :P so you should help him figure out how to get the behavior right.
13:17 < gmaxwell> we never would have merged smart times knowing that it added hours to the rescan of a 200k key wallet.
13:18 < Luke-Jr> :/
13:19 < Luke-Jr> this is the first complaint of that nature, whereas we used to have regular complaints about tranasction times before smart-times got released..
13:19 < gmaxwell> Luke-Jr: we have had regular complaints about rescan taking forever for a long time.
13:19 < Luke-Jr> O.o
13:19 < gmaxwell> Just didn't know smarttimes were part of it until now.
13:19 < gmaxwell> heck, even I've complained about it. :)
13:19 < Luke-Jr> it's rare enough I assumed he meant reindex
13:20 < gmaxwell> Luke-Jr: no, rescale! as in zapwallettx (which he mentioned specifically)
13:20 < gmaxwell> er rescan.
13:20 < Luke-Jr> I mean, rescan and zapwallettx are not daily tasks
13:20 < Luke-Jr> reindex is getting to be :/
13:21 < gmaxwell> Luke-Jr: people are zaping frequently because of the malleation attacks.
13:21 < gmaxwell> still, this also means reindex would be slow, as we run the same code there.
13:23 < Luke-Jr> if it's really 9.5 hours longer, then any significant optimisation is likely to require changing the database non-trivially, which is dangerous. I consider slow better than dangerous, since we plan to go away from bdb someday anyway. So if bad times in day-to-day use is preferable to slow rescan, reverting it may be our best option. :|
13:25 < Luke-Jr> I'll take a look and see if I'm wrong about the risk, but that's what 9.5 hours suggests to me.
13:35 < Luke-Jr> ok, we can probably get a lot of improvement by caching the ordered tx list rather than sorting it every add
13:35 < Luke-Jr> >_<
13:38 < Luke-Jr> any simple way to benchmark?
13:40 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
13:45 -!- ParadoxSpiral [~ParadoxSp@p508B816E.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
14:05 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
14:08 < Luke-Jr> gmaxwell: this would be easier if I could remove accounting first; thoughts?
14:08 < Luke-Jr> wumpus: ^
14:12 -!- Thireus1 [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
14:14 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Ping timeout: 265 seconds]
14:20 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
14:22 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
14:35 -!- JoeLiu [uid88238@gateway/web/irccloud.com/x-fqzhuigtbjqerfbu] has quit [Quit: Connection closed for inactivity]
15:31 -!- CodeShark [~androirc@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 240 seconds]
16:45 < gmaxwell> Luke-Jr: why do you need the sorted list?
16:45 < gmaxwell> Luke-Jr: can you not cache a min or max?
17:10 < Luke-Jr> gmaxwell: perhaps. optimizing the sorted list would help in multiple places though
17:13 < gmaxwell> as far as optimizing, how about adding one of the satoshi dice addreses to a wallet and rescanning?
17:14 < Luke-Jr> (just the last item will actually change the algorithm btw)
17:14 < gmaxwell> Luke-Jr: sure other optimizations are good too, but AFAIR all that needs to do is track a the extrema.
17:16 < Luke-Jr> gmaxwell: it ignores any transactions timestamped >5m in the future from the local time, which means such txns would have to be reconsidered over time
17:18 < gmaxwell> Luke-Jr: uh. how are they ever going to get learned then? 
17:19 < Luke-Jr> gmaxwell: ?
17:19 < Luke-Jr> ignores in the context of looking at other txns timestamps to decide the timestamp for this one
17:20 < phantomcircuit> what's the relative cost of checking an address vs pattern matching the output to start with?
17:20 < gmaxwell> remind me precisely what it does?
17:20 < gmaxwell> phantomcircuit: go read the pr
17:20 < gmaxwell> (the text on the opening)
17:21 < Luke-Jr> gmaxwell: it's complex enough that I'd just be rewriting the code in pseudo-code to explain it :/
17:21 < gmaxwell> Luke-Jr: good well that means it can change behavior and not violate anyone's expectations because apparently no one can understand it. :P
17:21 < Luke-Jr> it's not hard to understand, it's just complex :p
17:22 < phantomcircuit> gmaxwell, i never understood why we even bothered to guess when an unconfirmed transaction happened
17:22 < Luke-Jr> the point is that it meets expectations
17:22 < gmaxwell> phantomcircuit: because we show them in listtransactions
17:22 < phantomcircuit> gmaxwell, "this transaction happened now" seems reasonable for all unconfirmed transactions
17:23 < gmaxwell> phantomcircuit: but then its inconsistent with what you get when it confirms.
17:23 < Luke-Jr> phantomcircuit: no, definitely not when you're syncing a node that was off
17:23 < phantomcircuit> Luke-Jr, how about null
17:23 < gmaxwell> (the listtransaction output gives several different times when you care about details... and a smart time)
17:24 < gmaxwell> phantomcircuit: bet peoples software will handle that super awesomely well.
17:24 < Luke-Jr> phantomcircuit: … that is not useful
17:24 < phantomcircuit> the timestamp we're returning now isn't very useful either
17:24 < gmaxwell> phantomcircuit: It's usually pretty good.
17:24 < gmaxwell> Luke-Jr: I think you might need to write out the algorithim again, we cannot continue with this being slow like this. 
17:25 < phantomcircuit> i guess...
17:26 < Luke-Jr> gmaxwell: that's why I'm working on optimizing it.. if we want accounting to keep working, I can deal with that, just would have saved time to omit it
17:26 < Luke-Jr> (this code actually seems to be somewhat broken with accounts, fwiw)
17:27 < gmaxwell> Luke-Jr: I thought smarttime just returned blocktime for confirmed transactions that you didn't observe first?
17:29 < Luke-Jr> not necessarily
17:29 -!- Thireus1 [~Thireus@icy.thireus.fr] has quit [Remote host closed the connection]
17:29 < gmaxwell> unless the blocktime is in the future, in which case? 
17:30 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
17:32 < phantomcircuit> this seems much smarter than it needs to be...
17:32 < Luke-Jr> it's approximately max(last_txn_time, min(block_time, max(last_txn_time, now)))
17:32 < phantomcircuit> also it seems like all of these values should be cachable
17:33 < gmaxwell> Luke-Jr: than can be simplified to refer only to blocktimes in the context of a rescan.
17:33 < Luke-Jr> gmaxwell: half the goal here is to avoid transactions ever having timestamps out of order
17:34 < gmaxwell> which they cannot, in a rescan.
17:34 < Luke-Jr> uh, why not?
17:34 < Luke-Jr> block times are out of order all the time
17:34 < phantomcircuit> what's the rational behind not setting the transaction timestamp to the block timestamp?
17:34 < gmaxwell> Luke-Jr: as I just said, you can apply that filter to blocktimes only!
17:35 < phantomcircuit> oh you want to avoid the timestamps disagreeing with the nOrdPos
17:35 < gmaxwell> phantomcircuit: becuase they end up out of order which really screws with people.
17:35 < Luke-Jr> gmaxwell: that sounds a lot more complex, and doesn't consider that we can ignore it when blocks don't have any txns of ours
17:36 < gmaxwell> Luke-Jr: this code takes _9.5 hours of processing_ in the requesting users example.
17:36 < gmaxwell> And you are going to complain about complex?
17:38 < gmaxwell> Luke-Jr: having it use some really old time because your last transaction was 50 blocks ago isn't good.
17:38 < Luke-Jr> I find it simpler to just optimise the ordered tx list
17:38 < gmaxwell> e.g. if the latest block is in the future, okay you don't use the time. Then it should use the time of the prior block, even if there was no transaction there, not the time of your last transaction.
17:39 < gmaxwell> at least in the context of a rescan where you do not learn times anywhere except blocks.
17:39 < gmaxwell> I think the current behavior is just busted there.
17:39 < Luke-Jr> gmaxwell: it would use `now` in that case
17:40 < Luke-Jr> in a rescan, block times will basically never be in the future.
17:40 < gmaxwell> yea, unlikely, indeed.
17:42 < Luke-Jr> gmaxwell: will you NACK an optimization that preserves existing behaviour?
17:42 < gmaxwell> if it's measurably slower, yes.  This should not take any time at all. as I said, I would have NAKED smarttimes if I knew it caused a measurable slowdown.
17:44 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-cwdwpaiyuyohbdkz] has quit [Quit: Connection closed for inactivity]
17:54 -!- equil_ [~equil@195-154-204-94.rev.poneytelecom.eu] has joined #bitcoin-core-dev
18:16 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev
18:16 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
18:32 -!- maaku [~quassel@botbot.xen.prgmr.com] has quit [Read error: Connection reset by peer]
18:33 < Luke-Jr> gmaxwell: I *think* it is possible to optimise so it's reasonably close, but in case not, there is a possibility of rescan just skipping smart-time assignment (which currently causes "time" to fall back to received time = rescan time, but maybe that should change?)
18:34 < Luke-Jr> side note: hmm, sync of my node confused BFGMiner as it got notified of old blocks O.o
18:34 < gmaxwell> Luke-Jr: of course, if this function is slow during rescan its also slow during runtime... so I do support speeding it up generally too.
18:35 < gmaxwell> Luke-Jr: would rather fall back to monotoneized blocktime than rescan time.
18:35 < Luke-Jr> well, part of why it was unoptimised is probably because runtime is not time sensitive
18:36 < gmaxwell> Luke-Jr: hope you're not mining from a node with a wallet...
18:36 < gmaxwell> but really having a very big wallet (Even bigger than the ones there) would eventually be disruptive.
18:36 -!- maaku [~quassel@botbot.xen.prgmr.com] has joined #bitcoin-core-dev
18:37 -!- maaku is now known as Guest57960
18:37 < Luke-Jr> eh? it's just BFGMiner (running for testing) automatically picking up my hot wallet
18:38 < Luke-Jr> it's using Eligius mainly, but the local node's block disagreements somewhat confused it
18:38 < Luke-Jr> no big deal if mining is negatively impacted by it; maybe a slightly bigger deal if it were to compromise my hot wallet
18:39 < Luke-Jr> but if that latter case is a risk, we should fix it. I'm not aware of such a problem.
18:43 < gmaxwell> I wasn't commenting on your bfgminer comment. 
18:44 < Luke-Jr> oh
18:44 < gmaxwell> I'm saying that you shouldn't dismiss that the performance of sorting the whole wallet on an add as being important. As an example, someone who is mining with a wallet cares about a 100ms delay, (which is the ballpark of what that user was reporting).. or very big wallets.
18:45 -!- Guest57960 is now known as maaku
18:48 < phantomcircuit> Luke-Jr, cant you just cache the oldest record timestamp?
18:49 < Luke-Jr> phantomcircuit: newest*, but no, because of the 5 minute future rule
18:50 < Luke-Jr> optimising OrderedTxList looks like an easy big win. let me finish that and we can see where we are and if we need more improvements?
18:59 < gmaxwell> Luke-Jr: sounds like something to try.
19:08 < phantomcircuit> bleh the real problem is the rpc api is wrong
19:08 < phantomcircuit> probably cant reasonably fix that though
19:11 < gmaxwell> on my not very huge wallet, the PR on github is a ~1% speedup. 
19:12 < gmaxwell> really we're doing something dumb if every wallet isn't approximately the same speed for rescan.
19:27 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
19:29 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
19:56 < kanzure> rescan was killing all my rpcthreads a few weeks ago and i didn't have any insight into what was going on :-( maybe i'll submit an rpcthread status info command.
19:56 < kanzure> s/killed/pegged? what's the right term
19:57 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
20:01 -!- maaku [~quassel@botbot.xen.prgmr.com] has quit [Remote host closed the connection]
20:02 -!- maaku [~quassel@botbot.xen.prgmr.com] has joined #bitcoin-core-dev
20:02 -!- maaku is now known as Guest67646
20:11 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
20:13 -!- Guest67646 is now known as maaku
20:13 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
21:13 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Ping timeout: 250 seconds]
21:16 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
21:30 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Ping timeout: 252 seconds]
21:30 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
22:10 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
22:12 -!- equil_ [~equil@195-154-204-94.rev.poneytelecom.eu] has quit [Ping timeout: 268 seconds]
22:35 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
22:38 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev
22:38 < dcousens> jgarzik: not sure what users would use it tbh
22:38 < dcousens> I know I would for an API perspective
22:38 < dcousens> So, in my case, automated?
22:39 < dcousens> And I guess for sites like webbtc, they lightly dress it up in some readable HTML
22:40 < dcousens> hell, if an addrindex existed, a block explorer would solely be a HTML dress up of the bitcoind REST API ha
22:40 < jgarzik> dcousens, yeah the 'GET /foo' case is more likely to be used manually, versus PUT/POST
22:40 < dcousens> jgarzik: probably a more important question is,  what is the default
22:40 < dcousens> that will dictate how easy it is for curl users
22:41 < dcousens> And even then, content type isn't that hard for curl users?
22:47 < dcousens> I feel like most users might do something along the lines of     'bitcoin-tx ... | curl 'http://somepopularnode.com/tx' --data-raw -H "Content-Type:application/octet-stream"
22:47 -!- challisto [~challisto@unaffiliated/challisto] has quit [Remote host closed the connection]
22:47 < dcousens> or application/json if `-json` was used
22:48 < dcousens> Probably easiest to just specify the format to whatever the default is, and have `-json` or whatever on bitcoin-tx though
22:52 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
23:30 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
23:35 -!- baldur [~baldur@pool-173-52-43-219.nycmny.fios.verizon.net] has quit [Ping timeout: 264 seconds]
23:48 -!- baldur [~baldur@pool-173-52-43-219.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
23:49 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-qbcxeduyeasabbni] has joined #bitcoin-core-dev
23:52 < wumpus> kanzure: rescan blocks all your RPC threads, on aquiring cs_main
23:53 < wumpus> kanzure: long-running RPC commands tend to block the rest, apart from gettxoutsetinfo which I changed at some point to not hold locks (as it runs on a snapshot of the database)
23:54 < wumpus> probably in rescan the lock could be moved down too, and only aquired when block database structures are accessed
23:56 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]