Limit the number of orphan blocks in memory #3609

pull sipa wants to merge 1 commits into bitcoin:master from sipa:limitorphanblocks changing 2 files +29 −1

sipa commented at 1:17 PM on January 31, 2014: member

In case the total number of orphan blocks in memory exceeds a limit (currently set to 750), a random orphan block (which is not depended on by another orphan block) is dropped. This means it will need to be downloaded again, but it won't consume memory until then.

Limit the number of orphan blocks

In case the total number of orphan blocks in memory exceeds a limit
(currently set to 750), a random orphan block (which is not
depended on by another orphan block) is dropped. This means it will
need to be downloaded again, but it won't consume memory until then.

bbde1e99c8

BitcoinPullTester commented at 1:33 PM on January 31, 2014: none

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/bbde1e99c893924dbef135f42c14f4df9828c6e5 for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.

in src/main.cpp:None in bbde1e99c8

1053 | @@ -1054,6 +1054,31 @@ uint256 static GetOrphanRoot(const uint256& hash)
1054 |      } while(true);
1055 |  }
1056 |  
1057 | +// Remove a random orphan block (which does not have any dependent orphans).

laanwj commented at 1:13 PM on February 4, 2014:

Maybe add to comment: if the number of stored orphans is greater or equal to MAX_ORPHAN_BLOCKS

laanwj commented at 1:32 PM on February 4, 2014: member

ACK on code changes
gavinandresen commented at 2:37 PM on February 4, 2014: contributor

RE: pulling for 0.9.0rc2 : a fill-memory-with-valid-orphan-blocks attack would be insanely expensive, so this is not urgent and I don't see any reason to pull it for 0.9.0.
sipa commented at 2:37 PM on February 4, 2014: member

Huge sequences of orphans are regularly seen during normal synchronization, just because of how they are fetched.
laanwj commented at 9:37 AM on February 8, 2014: member

I can confirm what @sipa says. Due to receiving out of order, large chains of orphans occur during initial sync. Even though they take less memory now that they are stored in serialized form, this can still be a cause of running out of memory during initial sync.
gavinandresen commented at 3:49 PM on February 8, 2014: contributor

Crash-during-initial-block-download is a good reason to pull this for 0.9.0rc2.
gavinandresen referenced this in commit 95e66247eb on Feb 8, 2014
gavinandresen merged this on Feb 8, 2014
gavinandresen closed this on Feb 8, 2014
DrahtBot locked this on Sep 8, 2021

Contributors