Do not inv old or missing blocks when pruning #6130

pull sdaftuar wants to merge 1 commits into bitcoin:master from sdaftuar:fix-getblocks-when-pruning changing 1 files +8 −0

sdaftuar commented at 4:13 PM on May 13, 2015: member

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).

Do not inv old or missing blocks when pruning

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.

4a0d11a783

in src/main.cpp:None in 16a8ded924 outdated
```
4152 | @@ -4153,6 +4153,14 @@ bool static ProcessMessage(CNode* pfrom, string strCommand, CDataStream& vRecv,
4153 |                  LogPrint("net", "  getblocks stopping at %d %s\n", pindex->nHeight, pindex->GetBlockHash().ToString());
4154 |                  break;
4155 |              }
4156 | +            // If pruning, don't inv blocks unless we have on disk and are likely to still have
```
sipa commented at 7:45 PM on May 13, 2015:

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?

sdaftuar commented at 8:07 PM on May 13, 2015:

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.

sipa commented at 8:12 PM on May 13, 2015:

Fair enough, and the test is cheap.
sdaftuar force-pushed on May 14, 2015
sdaftuar commented at 1:47 PM on May 14, 2015: member

Pushed up a small fix (was using fHavePruned instead of fPruneMode in the test).
laanwj added the label Bug on May 15, 2015
morcos commented at 9:00 PM on May 15, 2015: member

tested ACK. Although I don't think this change is needed until #6122 goes through, it will be needed at that point.
sdaftuar commented at 3:12 PM on June 16, 2015: member

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.
sdaftuar closed this on Jun 16, 2015
MarcoFalke locked this on Sep 8, 2021

Contributors

Labels

Linked (view graph)

#6122 Autoprune: Do relay blocks if possible #6148 Relay blocks when pruning