Bitcoin Core 0.17.0 sync stuck at block 553342

[odolvlobo]

My node refuses to sync beyond block 553342. I see this in the debug log:

2018-12-11T02:00:59Z InvalidChainFound: invalid block=0000000000000000001443924dba96339bfb0a06fb48ca8eb244c601a76a0e95  height=553343  log2_work=90.114118  date=2018-12-11T02:00:43Z

followed forever by this:

2018-12-11T02:00:59Z ERROR: AcceptBlockHeader: block 0000000000000000001443924dba96339bfb0a06fb48ca8eb244c601a76a0e95 is marked invalid

That block is height 553343 on the main chain according to blockchain.info.

I tried restarting Core, but no luck. The disk is nowhere close to being full.

Any suggestions?

Is there a way to unmark it as invalid? I hope I don't have to sync from the beginning.

[Rath_]

You have to delete that block manually. You won't have to re-download previous blocks. Stop your Bitcoin Core instance and open its data directory. Go to blocks folder and delete files associated with this block (blk.dat and rev.dat). A similar problem has been described here and it was answered by achow101 who is also a member of this forum.

[Jet Cash]

Rather than deleting the bad records, I would rename them. This means that if you have a bad spot on the disk, the software won't try to reuse it. All other actions should be as suggested.

[odolvlobo]

You have to delete that block manually. You won't have to re-download previous blocks. Stop your Bitcoin Core instance and open its data directory. Go to blocks folder and delete files associated with this block (blk.dat and rev.dat). A similar problem has been described here and it was answered by achow101 who is also a member of this forum.

I deleted the last blk.dat and rev.dat files and restarted. It re-indexed all the blocks and continued syncing and now I'm up-to-date. Thanks for the suggestion and the link.

I have some suggestions for any core developers that might read this:

• 1. Since this problem seems to happen regularly, it would be helpful if the block processing code would detect that the last block is corrupted and do something about it.
• 2. Since it is the last block that is corrupted, there really isn't a need to re-index the entire chain. Recovering from a corrupted last block could only take a second.

Rather than deleting the bad records, I would rename them. This means that if you have a bad spot on the disk, the software won't try to reuse it. All other actions should be as suggested.

Thanks for the suggestion, but I don't think that managing bad sectors by hand is practical. If you suspect that there is a bad sector, you should have the operating system check the disk.

[jackg]

1. There’s probably been a reason they haven’t done that. I got that bug originally three years a go so it is in no way a new thing. I’m guessing it would take a long time to do it but I’m not particularly sure (as I’m it would make the sync process a lot slower or it’s difficult to do).

[kalostrian]

Problem here is that reindexing takes the same time as downloading the blocks.

So if that problem happens all the time this is not a solution, as reindexing from the begining takes hours...

[NotATether]

I deleted the last blk.dat and rev.dat files and restarted. It re-indexed all the blocks and continued syncing and now I'm up-to-date. Thanks for the suggestion and the link.

I have some suggestions for any core developers that might read this:

• 1. Since this problem seems to happen regularly, it would be helpful if the block processing code would detect that the last block is corrupted and do something about it.
• 2. Since it is the last block that is corrupted, there really isn't a need to re-index the entire chain. Recovering from a corrupted last block could only take a second.

If you are able to reproduce this and have the disk space, I'd be interested to see what's in your debug.log if you run bitcoind on a new datadir with --log-level=debug, maybe it's a bug in parsing that particular block in Core 0.17.0 that's causing the syncing process to stall (could be an infinite loop).

EDIT: disregard this post, I didn't realize this thread was 2 years old (but I'm interested in knowing if this problem exists in 0.20.1).