ProcessBlock: ORPHAN BLOCK 751, prev=00xxxxxx #4353

Trying to sync fresh node, it takes 2 days now. Looks like it will be 2-3 days more. daemon is taking only like 10% of cpu, and log is spammed by

ProcessBlock: ORPHAN BLOCK 751, prev=00xxxxx

I`m not understand, why blocks are not downloaded from other nodes in order? daemon is processing less than 1 block per 1 second. Then umber 751 is dropping from time to time after several

UpdateTip: new best=00xxxxx

in row. Is daemon storing more than 751 "orphan" blocks? If not, it is huge waste of time and bandwidth. Looks like closing daemon and starting it again is speeding things up.

commit f59d8f0b644d49324cabd19c58cf2262d49e1392 (pull #3514) is the culprit here. I've no idea why it was merged without being tested first.

The purpose is preventing nodes from dying through out-of-memory, at the cost of wasting some network traffic.

I did test this, but as I rarely saw more than 500 orphans simultaneously in memory, 750 seemed like a safe number. It's probably not enough for some deployments.

The real problem however is that we're downloading and storing orphans in the first place. As long as we do that, everything will be a compromise one way or another (either RAM or network traffic), and guessing is hard.

#4431 has been developed by me over the last few days, and quite successfully fixes the many orphans problem. Please do check it out.

I just wanted to comment on this issue (because it shows up in google first) that a work around is to use the '-maxorphanblocks' startup parameter which should be in latest version if anyone is still running into this issue.

It was merged here: #4258

@a-r-d im having a similar issue. As my local node connects to more and more peers it appears to slow to a crawl over time as the orphan list grows until max:750

what would be a good starting point to set for -maxorphanblocks ?

Note that in master (what will be 0.10) there is no concept of ORPHAN BLOCKS anymore. It just downloads the blocks on the longest chain.

@Taugeran I just ran for 6 hours and got 450 orphan blocks but I am still 30 weeks behind. I set my '-maxorphanblocks' to 5000 and hopefully it will run for a few days at this rate. @laanwj that sounds good this is just for those of us running binaries from release tags v0.9.3 and v0.9.2 or basically what is currently linked to the main bitcoin.org site.

@laanwj are there other issues fixed in master right now? I am wondering if it would be better just to clone off of the master branch and compile it myself. The client still seems to downloading blocks extremely slowly.

If you count 1MB per block, a maxorphanblocks of 5000 can take up to 5GB of memory. If you suffer from the OP's issue you should set it lower than the default of 750, not higher.

For 0.9.x it is recommended to use the bootstrap torrent instead of letting the node download the blocks. See https://bitcointalk.org/index.php?topic=145386.0 . @a-r-d Yes, a lot has changed since 0.9.x. See for example https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes.md .

@laanwj thanks for linking me to the bootstrap torrent. I finished downloading the block chain and copied into my data directory (and cleared out my old data). I then started bitcoin-qt and watched it import the blocks- this got me all the way up to block 295266.

However I am still 34 weeks behind and the client will not download any more blocks after being connected for several days. Do you have any more suggestions to try? The 0.9.3 build seems a little broken to me.

I also did clone master and build from the source. I started it an let it run for a few hours... it also seems not to want to download any more blocks from the network.

Screenshot:

same here, got stuck at block 322082.

version is v0.9.3.0-g40d2041-beta (0.9.3-trusty2 deb).

here's a short snippet from debug.log: https://gist.github.com/anonymous/26122b65a246e8e00d82

@varac see #5660 and #5645