Do not inv old or missing blocks when pruning #6130
Conversation
There was a problem hiding this comment.
Can't this check be done only once, before the loop? If it holds for the oldest block in the list, it will also hold for all further ones, I think?
There was a problem hiding this comment.
That's very likely but not necessarily the case, because blocks can be written out of order to disk (so that we may have an older block but pruned a more recent block), and because we don't guarantee that we always have the last 288 blocks (though we try to, that assumption can break if there's a reorg). So it's possible, say, for a block at height tip-280 to be present but a block at height tip-279 to have been pruned.
There was a problem hiding this comment.
Fair enough, and the test is cheap.
When responding to a getblocks message, only return inv's as long as we HAVE_DATA for blocks in the chain, and only for blocks that we aren't likely to delete in the near future.
sdaftuar
force-pushed
the
fix-getblocks-when-pruning
branch
from
16a8ded to
4a0d11a
Compare
|
Pushed up a small fix (was using fHavePruned instead of fPruneMode in the test). |
|
tested ACK. Although I don't think this change is needed until #6122 goes through, it will be needed at that point. |
|
Closing, as I don't think this bug can be triggered without enabling block relay for pruning nodes, and this commit is included in #6148 already. |
4 participants
When responding to a getblocks message, only return inv's as
long as we HAVE_DATA for blocks in the chain, and only for blocks
that we are likely to not delete in the near future.
This fixes the issue mentioned here #6122 (comment).