--- Day changed Wed Apr 19 2017
00:03 -!- kexkey [~kexkey@184.75.212.36] has quit [Ping timeout: 260 seconds]     
00:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
00:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
00:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
00:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
00:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
00:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
00:38 <@wumpus> git add --patch is so useful
00:40 <@wumpus> it's essential if you want to add just some changes in a file to a commit but not all. Only discovered this recently, don't ask what hacks I was doing to accomplish that before...
00:41 < sipa> you can also use it split existing commits
00:41 < sipa> during a rebase, while editing a commit, use git reset HEAD~
00:41 < sipa> then git add -p to select the changes to be in the first half
00:41 < sipa> git commit -m first; git commit -am second
00:42 <@wumpus> 'git gui' can also be used for this (you can stage and unstage individual lines, even), but usually work in the console so that was kind of annoying
00:42 <@wumpus> ah great
00:42 < sipa> and then git rebase --continue
00:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
00:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
00:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds]     
00:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
00:59 <@wumpus> is there anything (almost) ready for merging?
00:59 -!- Novella [~Novella@188.226.139.184] has joined #bitcoin-core-dev     
01:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
01:04 -!- Novella [~Novella@188.226.139.184] has quit [Ping timeout: 240 seconds]     
01:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:05 -!- Dahlia2 [~Dahlia@188.226.139.184] has joined #bitcoin-core-dev     
01:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
01:14 -!- tw2006 [~tw2006@2601:187:8480:2770:c4fb:af54:bbbf:1588] has joined #bitcoin-core-dev     
01:19 -!- tw2006 [~tw2006@2601:187:8480:2770:c4fb:af54:bbbf:1588] has quit [Ping timeout: 240 seconds]     
01:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:26 <@wumpus> thought #10143 was, but needs some minor changes still
01:26 < gribble> https://github.com/bitcoin/bitcoin/issues/10143 | [net] Allow disconnectnode RPC to be called with node id by jnewbery · Pull Request #10143 · bitcoin/bitcoin · GitHub
01:33 < bitcoin-git> [bitcoin] laanwj closed pull request #9524: rpc: Don't FlushStateToDisk when pruneblockchain(0) (master...Mf1701-qaPruning) https://github.com/bitcoin/bitcoin/pull/9524
01:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
01:42 < paveljanik> wumpus, #10226?
01:42 < gribble> https://github.com/bitcoin/bitcoin/issues/10226 | wallet: Use boost to more portably ensure -wallet specifies only a filename by luke-jr · Pull Request #10226 · bitcoin/bitcoin · GitHub
01:44 -!- nOgAnOo [uid146237@gateway/web/irccloud.com/x-ytzaqprutcunijho] has joined #bitcoin-core-dev     
01:44 <@wumpus> yes, that one is very straightforward
01:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:55 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9111df9673be...64c45aada702
01:55 < bitcoin-git> bitcoin/master a4186dd Luke Dashjr: wallet: Use boost to more portably ensure -wallet specifies only a filename
01:55 < bitcoin-git> bitcoin/master 64c45aa Wladimir J. van der Laan: Merge #10226: wallet: Use boost to more portably ensure -wallet specifies only a filename...
01:56 < bitcoin-git> [bitcoin] laanwj closed pull request #10226: wallet: Use boost to more portably ensure -wallet specifies only a filename (master...refactor_wallet_pathsep) https://github.com/bitcoin/bitcoin/pull/10226
01:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds]     
02:03 -!- AaronvanW [~AaronvanW@66.red-88-11-249.dynamicip.rima-tde.net] has joined #bitcoin-core-dev     
02:03 -!- AaronvanW [~AaronvanW@66.red-88-11-249.dynamicip.rima-tde.net] has quit [Changing host]     
02:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds]     
02:11 -!- d9b4bef9 [~d9b4bef9@207.38.86.239] has quit [Remote host closed the connection]     
02:12 -!- d9b4bef9 [~d9b4bef9@207.38.86.239] has joined #bitcoin-core-dev     
02:14 -!- PaulCape_ [~PaulCapes@2604:5500:17:2ea:6d20:763f:c2b4:f4fb] has joined #bitcoin-core-dev     
02:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:15 < bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/64c45aada702...e96486cbebc6
02:15 < bitcoin-git> bitcoin/master 608bbcc Matt Corallo: [qt] Stop treating coinbase outputs differently: show them at 1conf
02:15 < bitcoin-git> bitcoin/master e96486c Jonas Schnelli: Merge #10221: Stop treating coinbase outputs differently in GUI: show them at 1conf...
02:15 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #10221: Stop treating coinbase outputs differently in GUI: show them at 1conf (master...2017-04-no-coinbase-display-lag) https://github.com/bitcoin/bitcoin/pull/10221
02:16 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:4158:6da8:2ea3:932a] has quit [Ping timeout: 245 seconds]     
02:21 < jonasschnelli> Anyone has an opinion on: https://github.com/bitcoin/bitcoin/pull/9502
02:21 < jonasschnelli> I think it's useful even if there is the "hidden" feature of clicking the peers-statusbar-icon
02:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
02:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
02:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
02:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:50 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
02:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
02:56 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-gwpwsfawwpwzvndn] has joined #bitcoin-core-dev     
02:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
02:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
03:03 -!- tw2006 [~tw2006@2601:187:8480:2770:6179:ddc3:ad22:7709] has joined #bitcoin-core-dev     
03:08 -!- tw2006 [~tw2006@2601:187:8480:2770:6179:ddc3:ad22:7709] has quit [Ping timeout: 260 seconds]     
03:19 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
03:24 < jonasschnelli> I think this is RFM: https://github.com/bitcoin/bitcoin/pull/9827
03:29 <@wumpus> yep, thanks
03:30 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e96486cbebc6...c91ca0ace9bd
03:30 < bitcoin-git> bitcoin/master 30abce7 Russell Yanofsky: Improve ScanForWalletTransactions return value...
03:30 < bitcoin-git> bitcoin/master c91ca0a Wladimir J. van der Laan: Merge #9827: Improve ScanForWalletTransactions return value...
03:30 < bitcoin-git> [bitcoin] laanwj closed pull request #9827: Improve ScanForWalletTransactions return value (master...pr/scanret) https://github.com/bitcoin/bitcoin/pull/9827
03:36 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-core-dev     
03:37 <@wumpus> jonasschnelli: and yes I think it can be a useful feature
03:37 < jonasschnelli> wumpus: Thanks for the review.
03:37 < jonasschnelli> Will fix your points soon
03:41 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Ping timeout: 240 seconds]     
03:45 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has quit [Ping timeout: 240 seconds]     
03:50 -!- face [~face@mail.hmel.org] has quit [Ping timeout: 252 seconds]     
03:56 -!- tw2006 [~tw2006@2601:187:8480:2770:1158:e872:291d:d543] has joined #bitcoin-core-dev     
03:57 -!- pepe__ [~pepe@84.126.69.179.dyn.user.ono.com] has joined #bitcoin-core-dev     
04:03 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
04:05 -!- Soligor [~Soligor@unaffiliated/soligor] has quit [Ping timeout: 255 seconds]     
04:06 -!- face [~face@mail.hmel.org] has joined #bitcoin-core-dev     
04:10 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev     
04:27 -!- nOgAnOo [uid146237@gateway/web/irccloud.com/x-ytzaqprutcunijho] has quit [Quit: Connection closed for inactivity]     
04:30 -!- goksinen [~goksinen@2604:2000:c591:8400:2995:7ea7:65d5:6cd5] has joined #bitcoin-core-dev     
04:35 -!- goksinen [~goksinen@2604:2000:c591:8400:2995:7ea7:65d5:6cd5] has quit [Ping timeout: 260 seconds]     
04:36 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
04:56 -!- Dahlia2 [~Dahlia@188.226.139.184] has quit [Remote host closed the connection]     
04:56 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:d471:8a95:788b:eb49] has joined #bitcoin-core-dev     
04:58 -!- jtimon [~quassel@9.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
05:09 -!- tw2006 [~tw2006@2601:187:8480:2770:1158:e872:291d:d543] has quit [Remote host closed the connection]     
05:14 -!- To7 [~theo@cpe-158-222-192-214.nyc.res.rr.com] has quit [Quit: Whatever]     
05:14 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has joined #bitcoin-core-dev     
05:26 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
05:31 < instagibbs> wumpus, git add -p also works line by line, in manual edit mode
05:32 < instagibbs> 's' to keep splitting chunks, if not granular enough, 'e' for manual editor. A bit confusing at first but description is at end.
05:33 -!- NielsvG` is now known as NielsvG     
05:36 <@wumpus> instagibbs: ah :) thanks
05:43 -!- nu11p7r [~nu11p7r@dfaefce4-1ec2-41ac-b8f9-6bd816c36ded.node.sporestack.com] has quit [Ping timeout: 260 seconds]     
05:48 -!- tw2006 [~tw2006@2601:187:8480:2770:913b:b08b:95e7:f8f9] has joined #bitcoin-core-dev     
05:52 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev     
05:53 -!- To7 [~theo@cpe-158-222-192-214.nyc.res.rr.com] has joined #bitcoin-core-dev     
06:15 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 252 seconds]     
06:18 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev     
06:18 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-core-dev     
06:23 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Ping timeout: 260 seconds]     
06:34 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
06:46 -!- owowo [~ovovo@31.7.59.226] has joined #bitcoin-core-dev     
06:46 -!- owowo [~ovovo@31.7.59.226] has quit [Changing host]     
06:46 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
06:50 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
06:50 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Client Quit]     
06:54 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has quit [Ping timeout: 240 seconds]     
07:04 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
07:08 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
07:13 -!- goksinen [~goksinen@2604:2000:c591:8400:68d3:b545:6d34:7cb7] has joined #bitcoin-core-dev     
07:17 -!- goksinen [~goksinen@2604:2000:c591:8400:68d3:b545:6d34:7cb7] has quit [Ping timeout: 240 seconds]     
07:19 < BlueMatt> sipa: re #10148: I'm still super unconvinced that multi-head is worth it. in the future optimization space of "flush in chunks in the background", there is relatively little harm in requiring that mid-flush-states be in only one direction - either you're during ibd, in which cas I'd certainly hope this is already the case, or you're not in which case it should be relatively rare that your disk cant keep up and enforcing a 
07:19 < BlueMatt> fully-flushed state prior to block disconnect seems perfectly reasonable
07:19 < gribble> https://github.com/bitcoin/bitcoin/issues/10148 | [WIP] Use non-atomic flushing with block replay by sipa · Pull Request #10148 · bitcoin/bitcoin · GitHub
07:19 < BlueMatt> sipa: not to mention multihead is super hard to review right now since we dont even have the write side of it implemented
07:20 < BlueMatt> so the assumptions on the read side just seem arbitrary
07:20 < BlueMatt> (and complicated)
07:20 < sipa> BlueMatt: i don't think it's reasonanle to require a full flush before a reorg
07:21 < sipa> reorgs should lead to network-wide slowdowns
07:21 < sipa> and the write side is partially implemented; i'm writing a test for it now
07:24 -!- n1ce [~n1ce@unaffiliated/n1ce] has joined #bitcoin-core-dev     
07:25 < BlueMatt> sipa: why? if your node cant finish flushing its state before the next block comes in 9 times out of 10 you have no hope of staying up to date anyway
07:25 < sipa> BlueMatt: the idea is that you'd be flushing continuously
07:25 < sipa> and never fully flush
07:25 < BlueMatt> sipa: why?
07:25 < BlueMatt> why would you want to never fully flush
07:26 < BlueMatt> that'd mean startup would always be painfully slow
07:26 < sipa> because wiping your cache is retarded
07:26 < BlueMatt> well then dont wipe cache when you flush :)
07:26 < BlueMatt> thats an orthogonal issue, i think
07:26 < sipa> it isn't
07:26 < sipa> if you don't wipe when you flush, you need to flush more frequently
07:26 < sipa> and we've benchmarked that (before non-atomic flush)... it's slower
07:26 < BlueMatt> what happened to always flushing in the background?
07:27 < sipa> we're already flushing outside of normal block connection
07:27 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has joined #bitcoin-core-dev     
07:27 < sipa> it's still just more CPU to not wipe your cache
07:28 < morcos> sipa: at the very least this is an unnecessarily complicated optimization for right now
07:28 < sipa> (again, before non-atomic)
07:28 < morcos> this code is difficult to reason about with high certainty and i think BlueMatt is right that multi-head really compounds that
07:28 < morcos> If we decide we need it later, we can discuss it then... 
07:29 < sipa> morcos: i think both the test code i'm writing and the recovery code would he hardly any simpler without it
07:29 < sipa> it still needs to be able to deal with reorgs, just not multi-headed ones
07:29 < morcos> Ideally I think we would do #10195 first and not make that contingent on 10148 (w or w/o multihead)
07:29 < gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
07:29 < sipa> oh     
07:29 < sipa> that's certainly possible
07:30 < morcos> the issue i see with 10148 is that it seems like a lot of complication to solve a relatively simple problem about the way leveldb flushes...   it seems to me it would make more sense to review flush/don't erase strategies with 10195 as a first step
07:30 < BlueMatt> sipa: I'm more than happy to revisit multihead after per-utxo, but right now I'm super worried about the complication in it
07:31 < sipa> BlueMatt: if i put an assert(blockhead.size() == 2), would you be happy about it?
07:31 < morcos> maybe we eventually want to do 10148, but i'm hesitant to rework cache writiing in 2 big ways at the same time...  
07:32 < sipa> i think 10148 is much more urgent
07:32 < sipa> it dramatically changes our memory usage
07:32 < morcos> so does 10195?
07:32 < sipa> how so?
07:32 < morcos> for the same cache performance you can have a much smaller cache 
07:33 < sipa> eh, slightly
07:33 < sipa> anyway, i'm happy to rebase 10195 without 10148
07:34 < sipa> i just assumed we'd want 10148 sooner
07:34 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has quit [Ping timeout: 260 seconds]     
07:34 < BlueMatt> sipa: possibly I'd be ok with an assert like that, but then why have the much more complicated code in our consensus logic when we can push that review to when we actually remove the assert, right where it should be? Otherwise you have dormant code and people wont sufficiently review it when it becomes active?
07:34 < morcos> really?  only slightly?  i haven't tested 10195 yet, but it was my memory that a lot of the cache mem usage was taken up with dead weight from txs you bring along
07:35 < BlueMatt> I tend to agree that I like 10148, personally
07:35 < BlueMatt> i mean both, dont really care tooo much about order, just dont think we need to worry about multi-head
07:35 < sipa> morcos: but with 10195 you get duplication instead
07:35 < morcos> in memory?
07:35 < sipa> yes     
07:35 < morcos> oh i havent' reveiwed 10195 yet, i was envisioning a structure without duplication
07:35 < sipa> if multiple outputs for the same tx are in the cache, they become independent entries
07:36 < morcos> like a multi level cache
07:36 < sipa> we can think about that later, first switch the model to be per-txout
07:36 < morcos> ok, well i'll shut up until i review more... but i have to say, the complication of 10148 turns me off from getting to 10195!
07:37 < sipa> have you seen the commit i just added to 10148?
07:37 < sipa> well, yesterdat
07:37 < morcos> Yes...  And the part that is confusing is the Multiple reorganizations
07:37 < morcos> Thats still not clear to me exactly what scenario you guys are envisioning that results in that
07:38 < BlueMatt> frankly, we only have 2.5 months before 0.15 feature freeze, and we're gonna get in half of what people are PRing these days
07:38 < sipa> multiple reorgs, with partial flushing
07:38 < morcos> the rest of that comment is very good though
07:38  * BlueMatt is entirely unconvinced thats a thing we need to ever worry about
07:39 < BlueMatt> unless we never fully flush, but if we never fully flush startup will /always/ be painfully slow
07:39 < BlueMatt> which i also dont think is acceptable
07:39 < sipa> how so?
07:39 < sipa> it would just lag a few blocks behind
07:40 < sdaftuar> how would it only be a few blocks behind?
07:40 < sipa> at least it's configurable... during IBD it could lag behind more
07:40 < BlueMatt> during ibd you only need single-head, though, I think
07:40 < BlueMatt> it should be pretty much all serial
07:41 < sipa> sure, but i don't want two separate recovery algorithms
07:41 < BlueMatt> huh?
07:41 < morcos> I just think its too many steps at once...   Matt and Suhas are trying to explain to me what the series of events that happens here is and I just don't understand
07:41 < BlueMatt> sipa: I'm saying never support recovery of multiple reorgs at once
07:42 < sipa> BlueMatt: it's maybe 5 lines less code!
07:42 < sipa> instead of rolling back from one branch, you roll back from all of them
07:42 < morcos> I don't understand what a partial flush is
07:42 < sipa> morcos: write some of the entries in your cache to disk
07:42 < sipa> instead of all
07:42 < morcos> And then what?
07:42 < BlueMatt> and then...thats it?
07:42 < sipa> continue
07:43 < sipa> you're running out of memory, pick a few dirty entries in the cache, and write those to disk
07:43 < sipa> and perhaps delete a few non-dirty entries
07:43 < sipa> and continue
07:43 < sipa> there are tons of tweaks and analysis possible to find good strategies
07:43 < sipa> but non-atomic flushing makes all of it safe
07:43 < BlueMatt> sipa: but 20 more edge cases in consensus code, 30 more lines of comments to explain why its ok. the previous stuff was very reviewable, now its super tricky unless we /also/ implement the write side (I know you said you have that, but can we leave that for a separate pr?)
07:44 < morcos> So while you are writing those entries, no one else is modifying the cache...  but then you give up the lock before you've flushed the whole cache, so then when people modify the cache more..  ok i guess  i get it.
07:44 < morcos> But why can't we save that for a later "improvement" , why is it necessary now?
07:44 < sipa> morcos: because the algorithm is the same
07:44 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Read error: Connection reset by peer]     
07:44 < sipa> can we just put an assert in it, that forces it to be the simple case?
07:45 < sipa> so you can review it assuming it only needs to deal with the simple case
07:45 < morcos> What am I missing, why do you want to have the code there if we are not using it?
07:45 < sipa> it's 5 lines...
07:45 < sipa> yes, i can remove it
07:46 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
07:47 < sipa> but it's nice to at least have the database format support multihead, so it's not yet another backward compatible upgrade that needs upgrade
07:47 < BlueMatt> hardly? just means you cant downgrade after an unclear shutdown?
07:47  * BlueMatt is much less concerned about that
07:47 < sipa> plus new code that needs to deal with the old case
07:47 < BlueMatt> but maybe others are?
07:47 < sdaftuar> you can still downgrade with a -reindex-chainstate!
07:47 < sipa> ok...
07:49 < sipa> would you be fine with a database format that just has a record saying "rollback block X, rollforward block Y, rollback block Z", and the recovery code literally follows those steps?
07:49 < sipa> actually, that's pretty complicated on the write side
07:50 < BlueMatt> possibly, though the "might have had stuff from a future branch way down the line partially flushed" stuff just makes it harder to review consensus-critical crap
07:51 < sipa> sigh, ok, i'll try to simplify the code as much as possible to only deal with a single reorg
07:51 < morcos> sipa: i'm not sure that your approach is wrong..  i think its just a lot to hit someone all at once in thinking about it
07:51 < sipa> morcos: fair enough
07:51 < BlueMatt> sipa: thanks, now lets get this all merged for 0.14 =D
07:51 < BlueMatt> ehh, 15
07:51 < morcos> you might be right that it is a more elegant approach if you have this end goal in mind down the road
07:52 < morcos> but we're stuck trying to recreate the logical progression you went through to end up there
07:52 < sipa> understood
07:52 < sdaftuar> sipa: did you ever test the performance of flush-without-wiping with a per-utxo model?
07:52 < morcos> that said... i'm getting more comfortable with it after hashing it out a bit
07:53 < sipa> sdaftuar: i haven't
07:56 -!- pepe__ [~pepe@84.126.69.179.dyn.user.ono.com] has quit [Ping timeout: 268 seconds]     
07:57 -!- nu11p7r [~nu11p7r@dfaefce4-1ec2-41ac-b8f9-6bd816c36ded.node.sporestack.com] has joined #bitcoin-core-dev     
08:02 < morcos> sipa: another simple improvement would be to instead of having a 2.0x factor for cache memory usage to just track usage =  all cache usage + dirty coins usage
08:02 < sipa> morcos: i really hope that the non-atomic flushing after simplifying will be simple enough to be reviewed
08:03 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev     
08:20 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Read error: Connection reset by peer]     
08:21 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
08:24 < sdaftuar> wumpus: i think #9942 is ready for merge
08:24 < gribble> https://github.com/bitcoin/bitcoin/issues/9942 | Refactor CBlockPolicyEstimator by morcos · Pull Request #9942 · bitcoin/bitcoin · GitHub
08:24 < bitcoin-git> [bitcoin] jet0 opened pull request #10230: Merge pull request #1 from bitcoin/master (master...freeze) https://github.com/bitcoin/bitcoin/pull/10230
08:25 < bitcoin-git> [bitcoin] jet0 closed pull request #10230: Merge pull request #1 from bitcoin/master (master...freeze) https://github.com/bitcoin/bitcoin/pull/10230
08:29 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Remote host closed the connection]     
08:31 < jonasschnelli> I have significant freezes in the GUI with current master catching up a couple of days on mainnet..
08:32 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
08:33 < jonasschnelli> I think this was re-introduced with https://github.com/bitcoin/bitcoin/pull/9583
08:33 < jonasschnelli> Although not sure...
08:34 < Lauda> ^happens to me occasionally in 0.14.0
08:36 < BlueMatt> jonasschnelli: great! review #10179 :p
08:36 < gribble> https://github.com/bitcoin/bitcoin/issues/10179 | Give CValidationInterface Support for calling notifications on the CScheduler Thread by TheBlueMatt · Pull Request #10179 · bitcoin/bitcoin · GitHub
08:36 -!- n1ce [~n1ce@unaffiliated/n1ce] has quit [Quit: gtg]     
08:38 < jonasschnelli> BlueMatt: Oh... I totally forgot that one.. thanks. Will try.
08:41 < BlueMatt> jonasschnelli: that doesnt do anything by itself
08:41 < BlueMatt> the real change is the pr after it
08:41 < BlueMatt> but its blocking :)
08:41 < jonasschnelli> Okay... thanks.
08:41 < jonasschnelli> I think the freezes i face are caused by something different then the 9583
08:43 < sipa> BlueMatt: ha, blocking.
08:44 < BlueMatt> lol     
08:45 < BlueMatt> jonasschnelli: you may still wish to test my branch which is based on that (https://github.com/TheBlueMatt/bitcoin/tree/2017-01-wallet-cache-inmempool-4, I think, though i believe travis didnt like it last time, i need to go back and fix it prior to pring it)
08:45 < BlueMatt> would be good feedback if it is faster :)
08:46 < jonasschnelli> BlueMatt: Yes. I'll give it a try and a review once I have tracked the current freeze down
08:46 < jonasschnelli> *tracked down the current freeze
08:52 < cfields> jonasschnelli: https://github.com/bitcoin/bitcoin/issues/10209#issuecomment-295311664
08:52 < cfields> $10 says it's that :)
08:53 < jonasschnelli> cfields: But don't I need https://github.com/bitcoin/bitcoin/issues/10228?
08:53 < cfields> jonasschnelli: 10228 just keeps it from happening in the future. Problem is that your bitcoin-config.h is busted atm
08:54 < cfields> (i strongly suspect, anyway)
08:54 < jonasschnelli> ah... I see. That seams reasonable...
08:55 < cfields> jonasschnelli: specifically MSG_DONTWAIT. Are you seeing a warning about it when you build?
08:55 < jonasschnelli> oh.. maybe. :|
08:55 < cfields> if so, this is your problem, and autogen will fix you right up.
08:56 -!- d9b4bef9 [~d9b4bef9@207.38.86.239] has quit [Remote host closed the connection]     
08:57 -!- d9b4bef9 [~d9b4bef9@207.38.86.239] has joined #bitcoin-core-dev     
09:05 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #10231: [Qt] Reduce a significant cs_main lock freeze (master...2017/04/qt_freeze) https://github.com/bitcoin/bitcoin/pull/10231
09:08 < cfields> jonasschnelli: why not subscribe to UpdatedBlockTip() and cache it there?
09:14 < jonasschnelli> cfields: IMO we don't have a signal that covers the bestheader (not bestblock)
09:14 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
09:15 < jonasschnelli> ermm... we have NotifyHeaderTip
09:15 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]     
09:16 < jonasschnelli> cfields: Do you think it would be preferable to cache it in the GUI clientmodel instead of the core validation part (validation.cpp)?
09:16 < cfields> jonasschnelli: heh, I just grepped to the same conclusion :)
09:17 < jonasschnelli> cfields: Yes. I could cache it in "static void BlockTipChanged(ClientModel *clientmodel, bool initialSync, const CBlockIndex *pIndex, bool fHeader)"
09:17 < jonasschnelli> when fHeader == true
09:17 < cfields> jonasschnelli: i think it makes sense for each subsystem to maintain their own view of those things, yes
09:17 < jonasschnelli> Yes. Let me change this... I don't think there are valid use cases outside the GUI
09:17 < cfields> (not sure everyone would agree with that, but that's the direction we've been moving in)
09:18 < jonasschnelli> cfields: indeed.
09:19 < cfields> jonasschnelli: the exception obviously being if you need atomic access to a few locally cached things, in which case you have to be careful to keep everything in sync. But if it's just for the gui, I think caching it there makes sense.
09:20 < jonasschnelli> Yes. Right... i'll change the PR
09:24 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
09:28 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has quit [Ping timeout: 255 seconds]     
09:31 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
09:32 -!- timothy [tredaelli@redhat/timothy] has quit [Remote host closed the connection]     
09:34 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 245 seconds]     
09:37 < cfields> jonasschnelli: any reason we can't do the same thing for the other cs_main takers in there?
09:37 < jonasschnelli> cfields: Yes. We should do similar things there... i'll have a look
09:37 < cfields> (adding new ui events, i mean)
09:37 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has quit [Quit: mining]     
09:39 < cfields> jonasschnelli: great :)
09:41 -!- [\\\] [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
09:41 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 240 seconds]     
09:42 < morcos> Here is my attempt at a high level description of the current fee estimation algorithm.
09:42 < morcos> https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41
09:42 < morcos> gmaxwell: Please let me know if ^ is what you had in mind
09:43 < morcos> I thought it best to explain the basic concept of how it currently works without getting into the changes yet
09:46 < bitcoin-git> [bitcoin] luke-jr opened pull request #10232: release-notes: Accurately explain getblocktemplate improvements (0.14...0.14_relnotes_mining) https://github.com/bitcoin/bitcoin/pull/10232
09:49 < sipa> morcos: very clear
09:50 < bitcoin-git> [bitcoin] jet0 opened pull request #10233: Wallet: Support not reusing addresses (master...freezea) https://github.com/bitcoin/bitcoin/pull/10233
09:52 < morcos> sipa: heh, had a bug in it though!
09:58 -!- [\\\] [~triplesla@unaffiliated/imsaguy] has quit [Read error: Connection reset by peer]     
09:59 < bitcoin-git> [bitcoin] jnewbery opened pull request #10234: [net] listbanned RPC and QT should show correct banned subnets (master...list_banned_correctly) https://github.com/bitcoin/bitcoin/pull/10234
10:00 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
10:07 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
10:09 -!- tw2006 [~tw2006@2601:187:8480:2770:913b:b08b:95e7:f8f9] has quit [Remote host closed the connection]     
10:13 < sipa> BlueMatt, morcos, sdaftuar: i hope it's easier to review now
10:13 < bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10235: Track keypool entries as internal vs external in memory (master...2017-04-wallet-more-keypool-cache) https://github.com/bitcoin/bitcoin/pull/10235
10:13 < sipa> i'll leave the WIP marker in until I had a test for the reorganization
10:13 < sdaftuar> sipa: thanks, i'm taking a look
10:13 < BlueMatt> sipa: thanks, will review
10:14 < jonasschnelli> BlueMatt: re: https://github.com/bitcoin/bitcoin/pull/10184#issuecomment-295350649
10:14 < jonasschnelli> Yes. Makse sense..
10:15 < jonasschnelli> though the argument of "little money" is dangerous.. 
10:15 < sipa> sdaftuar, BlueMatt: thank you
10:15 < jonasschnelli> Years back some of us probably had little money on VPS's which now has worth a six digit number. :)
10:15 < jonasschnelli> And while you move your keys away from your VPS,... there is no guarantee they where not compromised..
10:16 < jonasschnelli> the security requirements can change over time and most people won't sweep the funds to a new address
10:16  * sipa remembers the linode hack
10:16 < sipa> but agree that there is not argument why it shouldn't work
10:16 < jonasschnelli> But I know... i also run nodes on external root servers and sometimes,.. they have a some test mainnet coins
10:17 < BlueMatt> jonasschnelli: I'm not saying its a *good* idea, just that if people want to do it we shouldnt try to break it
10:17 < sipa> new key creation performance has been horrible for ages
10:17 < BlueMatt> (some people buy insurance, too :p)
10:17 < sipa> we should improve that when we can, period
10:18 < jonasschnelli> Yes. Sure... I just in general think it's good to show some critical respons whenever someone mentions AWS or Azure. :)
10:18 < BlueMatt> fair
10:18 < sipa> btw     
10:18  * sipa had a bitcoind with wallet on a vps, and its money was stolen
10:18 < jonasschnelli> see! :-)
10:18 < BlueMatt> lol     
10:19 < sipa> though i do consider that my own damned fault
10:19 < jonasschnelli> so it even happens to core devs. :)
10:39 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
10:44 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has quit [Ping timeout: 260 seconds]     
10:45 -!- vicenteH [~user@195.235.96.150] has quit [Ping timeout: 260 seconds]     
10:49 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
10:52 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 240 seconds]     
10:54 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has quit [Read error: Connection reset by peer]     
10:55 -!- arowser_ [~quassel@106.120.101.38] has joined #bitcoin-core-dev     
10:56 -!- fao1 [~fao@106.120.101.38] has joined #bitcoin-core-dev     
10:58 -!- arowser [~quassel@unknown-3-103.windriver.com] has quit [Read error: Connection reset by peer]     
10:58 -!- fao [~fao@unknown-3-103.windriver.com] has quit [Read error: Connection reset by peer]     
10:58 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
11:01 < gmaxwell> BlueMatt:  I don't understand your complaint about multiple head. It's strictly safer than not having it. 
11:02 < gmaxwell> I agree it will be easier to reason about the effects of multi-head after were're per-txout, and I expect we won't make intentional use of it until then.
11:04 < sipa> gmaxwell: multi-head is only needed once we do multiple partial flushes
11:05 < sipa> gmaxwell: we *do* need reorg support immediately, but not necessarily support for multiple reorgs at once
11:05 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]     
11:07 < BlueMatt> gmaxwell: I'm happy to re-review post-per-utxo
11:08 < BlueMatt> but right now the review burden is high, and I'm not convinced of its usefulness unless we actually have a write side that we're gonna merge :)
11:09 < sipa> BlueMatt: well the advantage would be not breaking backward compatibility
11:09 < sipa> but per-txout will break that anyway
11:09 < BlueMatt> yes, also not sold on that :)
11:09 < BlueMatt> indeed
11:09 < gmaxwell> the same code fixes reorgs to that, the extra stuff that does things for multi-head is just a no-op otherwise.
11:10 < BlueMatt> gmaxwell: can we not have no-ops in consensus-critical logic?
11:11 < gmaxwell> so then if there is some corner case we should corrupt the state rather than just handling it?
11:12 < sipa> gmaxwell: there is no way we can now end up in a situation that needs multi-head support
11:12 < sipa> unless there is a bug in the code, and in that case it's unlikely the multi-head code actually does the right thing
11:14 < sipa> my reason for having it in the first place was because i don't consider it much more complicated, so it's easier to get it in now than changing it again later
11:14 < sipa> but it seems people disagree it's easy to understand
11:16 -!- chartractegg [~chartract@ip72-208-61-212.ph.ph.cox.net] has joined #bitcoin-core-dev     
11:33 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
11:35 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has quit [Ping timeout: 255 seconds]     
11:36 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
11:49 < luke-jr> wumpus: might make sense to backport #10207
11:49 < gribble> https://github.com/bitcoin/bitcoin/issues/10207 | Clarify importprivkey help text ... example of blank label without rescan by wtogami · Pull Request #10207 · bitcoin/bitcoin · GitHub
11:50 -!- tw2006 [~tw2006@2601:187:8480:2770:846b:2c26:1235:72b4] has joined #bitcoin-core-dev     
11:51 -!- chartractegg [~chartract@ip72-208-61-212.ph.ph.cox.net] has quit [Quit: Textual IRC Client: www.textualapp.com]     
11:54 -!- tw2006 [~tw2006@2601:187:8480:2770:846b:2c26:1235:72b4] has quit [Ping timeout: 240 seconds]     
11:58 < luke-jr> why is abortrescan not allowed in safe mode?
11:58 < sipa> lol     
12:02 -!- tw2006 [~tw2006@2601:187:8480:2770:f055:36ee:8458:4cad] has joined #bitcoin-core-dev     
12:07 < jonasschnelli> luke-jr: heh... is that already merged?
12:07 < luke-jr> seems so
12:25 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
12:33 -!- jtimon [~quassel@9.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
12:45 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]     
12:54 -!- vicenteH [~user@135.234.15.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
12:56 < luke-jr> Travis jobs are randomly cancelling?
12:59 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
13:04 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 260 seconds]     
13:04 < BlueMatt> luke-jr: they do that automagically if you force push before they run now
13:07 < luke-jr> BlueMatt: it doesn't *look* like jonasschnelli is force-pushing on #10231
13:07 < gribble> https://github.com/bitcoin/bitcoin/issues/10231 | [Qt] Reduce a significant cs_main lock freeze by jonasschnelli · Pull Request #10231 · bitcoin/bitcoin · GitHub
13:07 < BlueMatt> luke-jr: oh, then i dont know
13:07 < BlueMatt> i think people can also manually cancel their own jobs
13:07 < BlueMatt> maybe someone hit it on accident
13:08 < luke-jr> hmm     
13:10 -!- tw2006 [~tw2006@2601:187:8480:2770:f055:36ee:8458:4cad] has quit [Remote host closed the connection]     
13:10 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 255 seconds]     
13:13 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has quit [Quit: mining]     
13:16 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
13:16 -!- Guest36442 [~justin@47.148.176.74] has quit [Remote host closed the connection]     
13:16 -!- jtimon [~quassel@9.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
13:16 -!- juscamarena [~justin@47.148.176.74] has joined #bitcoin-core-dev     
13:17 -!- juscamarena is now known as Guest12838     
13:21 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]     
13:26 -!- CubicEarth [~cubiceart@c-67-168-4-85.hsd1.wa.comcast.net] has joined #bitcoin-core-dev     
13:31 -!- goksinen [~goksinen@2604:2000:c591:8400:68d3:b545:6d34:7cb7] has joined #bitcoin-core-dev     
13:35 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
13:36 -!- goksinen [~goksinen@2604:2000:c591:8400:68d3:b545:6d34:7cb7] has quit [Ping timeout: 260 seconds]     
13:55 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
14:00 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has quit [Ping timeout: 255 seconds]     
14:13 -!- vicenteH` [~user@135.234.15.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
14:15 -!- vicenteH [~user@135.234.15.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]     
14:17 -!- CubicEarth [~cubiceart@c-67-168-4-85.hsd1.wa.comcast.net] has quit [Remote host closed the connection]     
14:20 -!- e4xit [~textual@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has joined #bitcoin-core-dev     
14:20 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 258 seconds]     
14:29 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
14:34 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
14:36 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
14:41 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 260 seconds]     
14:55 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
14:59 -!- tw2006 [~tw2006@2601:187:8480:2770:5987:9a6e:e4ba:67fa] has joined #bitcoin-core-dev     
15:01 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 258 seconds]     
15:04 -!- tw2006 [~tw2006@2601:187:8480:2770:5987:9a6e:e4ba:67fa] has quit [Ping timeout: 260 seconds]     
15:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []     
15:15 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
15:17 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Ping timeout: 255 seconds]     
15:20 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 260 seconds]     
15:22 -!- Naphex [~naphex@naphex.rocks] has quit [Ping timeout: 252 seconds]     
15:22 -!- Naphex [~naphex@naphex.rocks] has joined #bitcoin-core-dev     
15:33 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Quit: Leaving]     
15:33 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
15:35 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has quit [Ping timeout: 255 seconds]     
15:36 -!- Giszmo [~leo@ip-22-233.219.201.nextelmovil.cl] has joined #bitcoin-core-dev     
15:38 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
15:50 -!- CubicEarth [~cubiceart@c-67-168-4-85.hsd1.wa.comcast.net] has joined #bitcoin-core-dev     
15:55 -!- Giszmo [~leo@ip-22-233.219.201.nextelmovil.cl] has quit [Ping timeout: 260 seconds]     
16:15 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev     
16:27 -!- dermoth [~thomas@dsl-216-221-55-119.mtl.contact.net] has quit [Ping timeout: 240 seconds]     
16:48 -!- tw2006 [~tw2006@2601:187:8480:2770:1858:e863:a1ed:d8b2] has joined #bitcoin-core-dev     
16:48 -!- CubicEarth [~cubiceart@c-67-168-4-85.hsd1.wa.comcast.net] has quit [Remote host closed the connection]     
16:53 -!- tw2006 [~tw2006@2601:187:8480:2770:1858:e863:a1ed:d8b2] has quit [Ping timeout: 260 seconds]     
16:56 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
17:01 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com]     
17:06 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 240 seconds]     
17:16 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 240 seconds]     
17:17 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
17:22 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
17:30 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-gwpwsfawwpwzvndn] has quit [Quit: Connection closed for inactivity]     
17:33 -!- goksinen [~goksinen@2604:2000:c591:8400:3816:c092:e861:a7ab] has joined #bitcoin-core-dev     
17:53 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
17:54 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
18:00 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 240 seconds]     
18:05 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
18:07 -!- CubicEarth [~cubiceart@c-67-168-4-85.hsd1.wa.comcast.net] has joined #bitcoin-core-dev     
18:11 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
18:12 -!- jouke [~worst@unaffiliated/komkommer] has quit [Ping timeout: 258 seconds]     
18:13 -!- jouke [~worst@2001:1c02:1600:5a00:3040:afc4:afa0:9c0a] has joined #bitcoin-core-dev     
18:13 -!- jouke [~worst@2001:1c02:1600:5a00:3040:afc4:afa0:9c0a] has quit [Changing host]     
18:13 -!- jouke [~worst@unaffiliated/komkommer] has joined #bitcoin-core-dev     
18:21 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:d471:8a95:788b:eb49] has quit [Ping timeout: 258 seconds]     
18:33 -!- PaulCape_ [~PaulCapes@2604:5500:17:2ea:6d20:763f:c2b4:f4fb] has quit [Ping timeout: 258 seconds]     
18:37 -!- tw2006 [~tw2006@2601:187:8480:2770:b90c:ccd9:a990:2dd4] has joined #bitcoin-core-dev     
18:42 -!- tw2006 [~tw2006@2601:187:8480:2770:b90c:ccd9:a990:2dd4] has quit [Ping timeout: 260 seconds]     
19:13 < luke-jr> Does this look like a malicious peer? https://drive.google.com/file/d/0ByBPjWWp3nRqTHd2T2JqeVlGLUk/view
19:17 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Remote host closed the connection]     
19:18 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev     
19:23 -!- luxor [ba0e797b@gateway/web/freenode/ip.186.14.121.123] has joined #bitcoin-core-dev     
19:37 -!- luxor [ba0e797b@gateway/web/freenode/ip.186.14.121.123] has quit [Quit: Page closed]     
19:45 -!- wangchun [~wangchun@li414-193.members.linode.com] has quit [Quit: leaving]     
19:45 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
19:46 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has quit [Ping timeout: 260 seconds]     
19:46 -!- jtimon [~quassel@9.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
19:46 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Quit: Leaving.]     
19:48 -!- wangchun [~wangchun@li414-193.members.linode.com] has joined #bitcoin-core-dev     
19:48 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
20:26 -!- tw2006 [~tw2006@2601:187:8480:2770:7863:abc9:283b:47d9] has joined #bitcoin-core-dev     
20:30 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
20:30 -!- tw2006 [~tw2006@2601:187:8480:2770:7863:abc9:283b:47d9] has quit [Ping timeout: 260 seconds]     
20:33 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 255 seconds]     
20:58 < bitcoin-git> [bitcoin] NicolasDorier closed pull request #10184: [Wallet] Worst case performance improvement on KeyPool filtering (master...hdinternalperf) https://github.com/bitcoin/bitcoin/pull/10184
21:26 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:c83a:20bc:e733:117f] has joined #bitcoin-core-dev     
21:29 -!- dodomojo [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-core-dev     
21:31 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
21:31 -!- goksinen [~goksinen@2604:2000:c591:8400:3816:c092:e861:a7ab] has quit [Ping timeout: 255 seconds]     
21:35 -!- dodomojo [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Read error: No route to host]     
21:35 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-core-dev     
21:40 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Ping timeout: 255 seconds]     
21:48 < gmaxwell> morcos: that writeup is pretty much just what I hoped. I thougth there was also an element of using the current mempool queue too?
22:07 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
22:15 -!- tw2006 [~tw2006@2601:187:8480:2770:58ea:a14a:1f0e:71b6] has joined #bitcoin-core-dev     
22:19 -!- tw2006 [~tw2006@2601:187:8480:2770:58ea:a14a:1f0e:71b6] has quit [Ping timeout: 240 seconds]     
22:26 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has quit [Quit: mining]     
22:43 -!- annanay25 [~csbtech@geekon.tech] has quit [Remote host closed the connection]     
22:44 -!- annanay25 [~csbtech@geekon.tech] has joined #bitcoin-core-dev     
22:48 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has joined #bitcoin-core-dev     
22:50 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]     
22:50 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev     
23:02 -!- jnewshoes [~jodie@blk-215-123-241.eastlink.ca] has quit [Ping timeout: 245 seconds]     
23:03 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-core-dev     
23:06 <@wumpus> luke-jr: I don't think we usually backport help texts, butit's fine w/ fe
23:06 <@wumpus> indeed, I've enabled the auto-cancel feature in travis where superceded jobs are automatically cancelled
23:07 <@wumpus> if this doesn't work properly I could disable it again, but in general speeding up tests by avoiding unncessary work is a good thing
23:09 <@wumpus> however travis admits it's still in beta stage
23:15 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Remote host closed the connection]     
23:19 < bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.14: https://github.com/bitcoin/bitcoin/commit/51c787dfb4963d2a59dc8944f45e065be0a06613
23:19 < bitcoin-git> bitcoin/0.14 51c787d Warren Togami: Clarify importprivkey help text with example of blank label without rescan...
23:19 -!- jnewshoes [~jodie@blk-215-123-241.eastlink.ca] has joined #bitcoin-core-dev     
23:26 < jonasschnelli> [08:26:20]  <luke-jr>	[21:56:40] Travis jobs are randomly cancelling?
23:27 < jonasschnelli> I sometime manually cancel (if I force push a couple of times)
23:27 < jonasschnelli> no need to build obsolete branches
23:29 -!- harrymm [~wayne@104.237.91.140] has joined #bitcoin-core-dev     
23:31 -!- dermoth [~thomas@dsl-216-221-55-119.mtl.contact.net] has joined #bitcoin-core-dev     
23:33 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-mvaeeeagbzxtqqpd] has joined #bitcoin-core-dev     
23:46 < NicolasDorier> sipa: Have you considered https://github.com/bitcoin/bitcoin/pull/10148#issuecomment-295599772 ? I think it would make the whole thing a lot easier, with less risk.
23:54 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 268 seconds]     
23:55 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has quit [Ping timeout: 268 seconds]     
23:56 < NicolasDorier> edited it
23:57 -!- Dyaheon [~Dya@a91-156-192-24.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
23:58 -!- goksinen [~goksinen@2604:2000:c591:8400:380c:3163:2c88:cc60] has joined #bitcoin-core-dev