< 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] 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