Missing blk00000.dat doesn't cause failure when retrieving blocks. #3957

Using bitcoind v0.9.0rc2-17-gd33f69a-beta (64-bit). When using bitcoinj as a client to to retrieve blocks from bitcoind with the wire protocol recent blocks were able to be retrieved as normal but when starting at the genesis block invalid blocks were being returned.

The following steps were taken: 1/ complete ver/verack handshake 2/ send getblocks message using genesis block hash as the locator 3/ receive inv message with 500 block hashes. The first 5 were manually validated as correct by checking blockchain.info 4/ send getblocks message using the same inventory items from the previous inv message. 5/ 500 block messages returned by bitcoind. However every block 81 bytes long. First byte was 0x02 (which is the wrong version for the genesis block) followed by 80 0x00 bytes.

After much investigating it turns out blk00000.dat was missing. Apparently rather than failing when unable to locate the block in the blockchain bitcoind was returning zeroed arrays of bytes. Whilst a peer could probably recover from connecting to a bitcoind in this state as it will simply ignore the obviously invalid blocks it's not quite the behaviour you'd expect. The client behaved completely normally as a client. Guessing it would have continued to do so unless the wallet contained outputs from the missing blkxxxxx.dat.

Unable to pinpoint when the file was deleted but likely it was several weeks ago and the client has been running happilly without it.

Presumably the indexes where still present as the bitcoind was able to produce a valid inv response to getblocks.

I have reproduced this issue in the latest master branch and can confirm the behaviour as described in the above report.

Step 1: renamed blk00000.dat to blk.00000.dat.moved Step 2: Requested block 1 (getdata 000000006a625f06636b8bb6ac7b960a8d03705d1ace08b1a19da3fdcc99ddbd) Step 3: Received a "block" response with a corrupt block: 020000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Messages logged in debug.log: 2014-05-11 05:20:35 Unable to open file /media/btcnode/blocks/blk00000.dat 2014-05-11 05:20:35 ERROR: ReadBlockFromDisk : OpenBlockFile failed

Both OpenBlockFile() and its calling function ReadBlockFromDisk() are correctly detecting the error, but the block-serving code in ProcessGetData() is not checking the return value for errors.

A simple solution is to check for the error and not respond to the getdata request if the block was not available on disk.

Pull request incoming.

This issue can be closed as it has been fixed.