< morcos> the reason this doesn't happen with 9375 alone is that peer 0 hasn't requested that peer 1 be a HB peer, so the reorg isn't announced via the fast mechanism, i'm guessing 9400 changed that, but haven't looked into the details
< gmaxwell> I wondered if that might also force us to cache more than one block.
< gmaxwell> e.g. what happens if we get a second block instantly after the first, since they're tied will we still advertise the second?
< morcos> gmaxwell: that sounds annoying. seems like maybe we need to rework the signals a bit. maybe make BlockChecked always called after ProcessNewBlock and we can hold a cache of all blocks from NewPowValidBlock until BlockChecked.
< morcos> also always cache the tip
< morcos> but then we have to figure out where the right place to call MaybeSetPeer.. is
< morcos> But there is already another minor problem with the way the signals work now, mapBlockSource is never cleared of blocks which don't have BlockChecked called on them
< morcos> and valid blocks that don't become your tip don't get that I don't think.. probably rare enough not to matter much now, but if we want to be have an alternate block request mechanism for SPV/hybrid whatever or something..
< cfields> sipa: if you're here, please refresh your browser. You're reviewing stale commits :)
< sipa> :(
< sipa> i was reviewing from the app
< cfields> sipa: sorry. no clue what the app sees. I split them up into much more reviewable chunks, i hope.
< sipa> i see it now
< sipa> i guess it just caches a bit more aggressively
< sipa> no worries
< sipa> that's also why the result ends up with commit comments
< sipa> rather than PR comments
< cfields> ah, that's annoying. I was just looking at the page and saw no comments on the pr. Checked my mail on my phone on a whim.
< cfields> no worries though, i'll watch for that now
< sipa> cfields: i was surprised to see that 2*buffersize was still there, tbh
< cfields> sipa: i couldn't really imagine a scenario where it could be hit. I just imagined a response of "belt and suspenders"
< cfields> should've asked :)
< sipa> yeah, belt and suspenders indeed
< cfields> will nuke it though. I've certainly never seen it. And I've done enough stupid things in tests that would've prompted it.
< sipa> but if you want to keep it, don't just turn it into fPauseSend
< cfields> well, I think the checking now should be tight enough. But I'll add some tests. I think the corks could've been quite broken and gone unnotiiced.
< sipa> if you set max send size below the block size, you'll hit it automatically :)
< cfields> see 30ad8c069bcaf4ef8b6bf17498386bcb42e39fc3 :(
< cfields> s/send/recv/ though
< sipa> yeah, i saw
< cfields> headed to bed, thanks for having a look
< cfields> and happy new year!
< wumpus> happy new year!
< cfields> wumpus: !
< cannon-c> New year not for another day
< cannon-c> Happy New Years Eve!
< wumpus> yes, same here, it's still a few hours to go, just not sure I'm going to speak to cfields before that
< cannon-c> must be in Australia
< BlueMatt> morcos: hey, sorry, not been around much...
< BlueMatt> morcos: I'm looking at the stuff now
< bitcoin-git> [bitcoin] isle2983 opened pull request #9450: Increment MIT licence copyright header year on files modified in 2016 (master...PR-increment-year) https://github.com/bitcoin/bitcoin/pull/9450
< bitcoin-git> [bitcoin] robmcl4 opened pull request #9451: CScript: remove redundant bounds check (master...remove_extra_bounds_check) https://github.com/bitcoin/bitcoin/pull/9451
< bitcoin-git> [bitcoin] isle2983 opened pull request #9452: Use TravisCI to enforce copyright header rules for source files (master...PR-travisci-copyright-enforce) https://github.com/bitcoin/bitcoin/pull/9452
< btcdrak> Happy New Year everyone
< instagibbs> yes happy new years, hoping for another year of successful releases
< paveljanik> Yay!
< btcdrak> let's tag 0.13.2 for New Year!
< bitcoin-git> [bitcoin] jsmith-dev opened pull request #9453: Copyright notice year 2017 increment. Happy New Year! (master...master) https://github.com/bitcoin/bitcoin/pull/9453