Do not inv old or missing blocks when pruning #6130

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

2. 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
3. in src/main.cpp: 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.
4. sdaftuar force-pushed on May 14, 2015
5. 
   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).
6. laanwj added the label Bug on May 15, 2015
7. 
   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.
8. 
   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.
9. sdaftuar closed this on Jun 16, 2015

   ---

10. MarcoFalke locked this on Sep 8, 2021

Contributors
sdaftuar sipa morcos

Labels
Bug