ERROR: ProcessBlock() : already have block #2542

After not using the application for a few months I had a backlog of blocks to catch up on and I found that there was a .7 to .8 version update. After updating, my balance went to 0 as it now had about 10+ months of blocks to catch up on and then after a power failure, it was in 'reindexing' blocks mode.

It was struggling to catch up, gaining only a few days of blocks for each day of use. I could see in the debug.log that it had up to 7 or 8 'already have block' errors for each ACCEPTED block.

I left it running, reindexing and catching up, and found it had used up most of my 10gb/month ISP limit. (took about 6 hours to reindex)

Until I found a suggestion on a forum to set maxconnections=1 now it only has 176 days of blocks to get and it gaining weeks worth of blocks each day of use...

This issue is to suggest that the program to not connect while 'reindexing' and limit connections while catching up on blocks more than x weeks ago. To prevent multiple duplicate block transmissions and perhaps a backup of a good index file?

#1382 fixes this issue... but never got merged.

@rebroad It does not fix the issue, it breaks the network.

I also used the : listen=0 setting, and I'm up to blocks 139 days old now, 21k+ blocks to go.

Yesterday I tried upping to maxconnections=2, but it didn't take long for duplicates to show up.

So far with maxconnections=1, I've only noticed 2 duplicate blocks error messages (yesterday before I tried maxconnections=2)

@gmaxwell How does it break the network? And how does it not fix the issue? Certainly, from my testing (11 months of testing now against the latest bitcoin master) it doesn't break the network and does fix the issue.

@rebroad I hope it won't break the network if you're the only one running it! I don't know whether it fixes the issue (and will not claim it doesn't), but killing connections because nodes do what you ask them is not the correct way to deal with the issue.

@sipa I agree it's not the ideal way, but it's a start. The ideal solution is to change the protocol so that a node can abort a block download without aborting the connection, but as this isn't currently part of the protocol, the only way it can currently be done is by aborting the connection.

@rebroad No offence, but it's not. Of course you can cancel a block sync without aborting the connection: just stop asking for blocks. Or even better, don't ask for the same block twice to begin with. That's the only correct solution. As I (and others) have told you many times before: killing a connection because the peer does what you asked is not going to happen.

@sipa - what you talk about is indeed a better solution, but since no one seems interested in making those changes, then i still argue that my fix is better than doing nothing - and will benefit the network too IMHO as current much traffic is wasted on nodes sending and receiving duplicate blocks. I'm not aware that my patch can be exploited to cause any network splits - which would be a good reason for not implementing it.