Bitcoin core reindex error

[davidorentol]

........

[1715177144]

1715177144

[1715177144]

1715177144

[1715177144]

1715177144

[1715177144]

1715177144

[achow101]

-reindex and -reindex-chainstate are command line options for when you start Bitcoin Core. They are not commands that you enter into the debug console.

If something is corrupted and requires a reindex, usually Core will let you know when you start it and it will begin the reindexing process when you continue to let it run. It will appears as if it is syncing and redownloading the blockchain (and if you pruned, it will be), but in reality it is reading the blocks on the disk and reindexing them, not redownloading the entire thing. However, if you do have pruning enabled, it will have to redownload the entire blockchain (and do the normal pruning thing) because reindexing requires walking through the entire blockchain again from beginning to end.

What files exactly did you delete?

[davidorentol]

......

[jackg]

i dont remember really

Currently i'm trying to do something from here  https://jlopp.github.io/bitcoin-core-config-generator/  ...and in particular "Bitcoin Core" ---> "Config File Location"

Does anyone know if i'm  using non-default location ,for example E:/Bitcoin  ,where to put config.file ?

There are instructions, but i don't fully understand them  

To use non-default location, create a default location config file containing this setting

edit: think i found how to

You need to reindex the entire block chain I think if you've deleted the chainstate.

Also, to check you've got the right thing, you need the config file to be in the same folder as the executible. It'll probably still function if the config file is in a sub folder but will be slower on startup. You don't then need to specify the location of the config file (unless it's in a different folder than the exectivle).
Inside that config file should be:

Code:

datadir=E:\Bitcoin\BitCoinData

For it to work.

[davidorentol]

...........

[achow101]

I found i have a backup ,but it seems that is not working   

A backup of what? The datadir?

Is there a way to avoid downloading the entire blockchain,using my backups or any command in config.fire ? i want to use CORE client, not svp.

If you have a backup of the datadir, then you can just replace everything inside of the datadir with the contents of your backup datadir, except the wallet, you will want the most recent wallet file.

Put the bitcoin.conf file in your datadir, E:\Bitcoin\BitCoinData. That is where it needs to go in order to be properly read by Core.

[davidorentol]

.......

[achow101]

The datadir?

yes

If you have a backup of the datadir, then you can just replace everything inside of the datadir with the contents of your backup datadir, except the wallet, you will want the most recent wallet file.

Put the bitcoin.conf file in your datadir, E:\Bitcoin\BitCoinData. That is where it needs to go in order to be properly read by Core.

this is exactly what I did

Then you are not redownloading the entire blockchain. Just because you see the progress bar there does not mean that you are redownloading the blockchain. Look at what it says next to that. In your screenshot, it says "Reindexing" which is exactly what it is doing.

[davidorentol]

........

[jackg]

I did not express myself correctly
After 40 min reindexing finished and client start downloading blockchain from 5 years and 37 week (the picture is taken a little later)




i don't understand why indexing stopped at 5 years and 37 week   i have 821 bik files (130 mb each)  + 821 rev files ,totaling of 115 gb

Could you post the debug log? Did the reindexing finish successfully or did the client just shut down?
It could be a problem with the backup that you used having some sort of corruption in one of the files (any very small change to the state of a file and the software has to download everything again).

[davidorentol]

............

[davidorentol]

......

[jackg]

with the backup that you used having some sort of corruption in one of the files

I'm afraid that's the problem. Hoped it can be fixed somehow 

debug log is about 10 mb , important things inside are


2017-04-04 20:49:36 Reindexing block file blk00001.dat...
2017-04-04 20:49:40 Reindexing block file blk00002.dat...
.....
2017-04-04 20:51:10 Reindexing block file blk00033.dat...
2017-04-04 20:51:10 LoadExternalBlockFile: Deserialize or I/O error - CBufferedFile::Fill: end of file
2017-04-04 20:51:10 Reindexing block file blk00034.dat...
...........
 Reindexing block file blk00068.dat...
2017-04-04 20:52:44 receive version message: /Satoshi:0.13.1/: version 70014, blocks=460407, us=38.122.43.186:10075, peer=14
2017-04-04 20:52:47 Reindexing block file blk00069.dat...
2017-04-04 20:52:49 Reindexing block file blk00070.dat...
2017-04-04 20:52:52 receive version message: /Satoshi:0.13.2/: version 70015, blocks=460407, us=38.122.43.186:10001, peer=12
2017-04-04 20:52:52 Reindexing block file blk00071.dat...
2017-04-04 20:52:55 Reindexing block file blk00072.dat...
2017-04-04 20:52:58 Reindexing block file blk00073.dat...
2017-04-04 20:52:59 receive version message: /Satoshi:0.13.1/: version 70014, blocks=460407, us=38.122.43.186:10014, peer=13
2017-04-04 20:52:59 ProcessMessages(sendcmpct, 5 bytes): Exception 'CDataStream::read(): end of data' caught, normally caused by a message being shorter than its stated length
2017-04-04 20:52:59 ProcessMessages(sendcmpct, 5 bytes) FAILED peer=13
2017-04-04 20:52:59 ProcessMessages(sendcmpct, 5 bytes): Exception 'CDataStream::read(): end of data' caught, normally caused by a message being shorter than its stated length
2017-04-04 20:52:59 ProcessMessages(sendcmpct, 5 bytes) FAILED peer=13
2017-04-04 20:53:01 Reindexing block file blk00074.dat...
2017-04-04 20:53:03 Reindexing block file blk00075.dat...

....


 Reindexing block file blk00080.dat...
2017-04-04 20:53:19 receive version message: /Satoshi:0.13.2/: version 70015, blocks=460407, us=[2001:0:5ef5:79fb:4c:d8c3:d985:d445]:55433, peer=15
2017-04-04 20:53:19 receive version message: /Satoshi:0.13.1/: version 70014, blocks=460407, us=38.122.43.186:10111, peer=16
2017-04-04 20:53:20 receive version message: /Satoshi:0.14.0/: version 70015, blocks=460407, us=38.122.43.186:10112, peer=17
2017-04-04 20:53:20 Reindexing block file blk00081.dat...
2017-04-04 20:53:21 receive version message: /Satoshi:0.13.1/: version 70014, blocks=460407, us=38.122.43.186:10114, peer=18
2017-04-04 20:53:21 receive version message: /Satoshi:0.13.1/: version 70014, blocks=460407, us=38.122.43.186:10115, peer=19
2017-04-04 20:53:22 ProcessMessages(sendcmpct, 5 bytes): Exception 'CDataStream::read(): end of data' caught, normally caused by a message being shorter than its stated length
2017-04-04 20:53:22 ProcessMessages(sendcmpct, 5 bytes) FAILED peer=19
2017-04-04 20:53:22 ProcessMessages(sendcmpct, 5 bytes): Exception 'CDataStream::read(): end of data' caught, normally caused by a message being shorter than its stated length
2017-04-04 20:53:22 ProcessMessages(sendcmpct, 5 bytes) FAILED peer=19
2017-04-04 20:53:23 Reindexing block file blk00082.dat...

.....then there are no errors till the end

2017-04-04 21:29:27 Reindexing block file blk00820.dat...
2017-04-04 21:29:30 Reindexing block file blk00821.dat...
2017-04-04 21:29:33 Reindexing finished
2017-04-04 21:29:33 Imported mempool transactions from disk: 76 successes, 28 failed, 0 expired
2017-04-04 21:29:35 UpdateTip: new best=00000000000004cfa99ab1c42854dc7539060972165f3eeb68c9aaa608a22c92 height=136588 version=0x00000001 log2_work=65.367834 tx=1051581 date='2011-07-16 16:48:20' progress=0.005015 cache=93.2MiB(399071tx)
2017-04-04 21:29:35 UpdateTip: new best=0000000000000a8346baa71a483fafb31e46fb3ee412a071c1a7335dc0522524 height=136589 version=0x00000001 log2_work=65.368038 tx=1051611 date='2011-07-16 16:49:16' progress=0.005015 cache=93.2MiB(399083tx)
2017-04-04 21:29:35 UpdateTip: new best=00000000000008ac5ac796bf5b3c796565d011425e6e756bb3528a6b953c31bb height=136590 version=0x00000001 log2_work=65.368241 tx=1051662 date='2011-07-16 17:07:51' progress=0.005016 cache=93.2MiB(399113tx)
2017-04-04 21:29:36 UpdateTip: new best=0000000000000941a54baa799a804246285d26c1447784ea2971b5c8a91
......................

Probably a peer connection issue then, but I don't think it should continue if that's the case.

found this also


2017-04-04 22:02:00 Bitcoin version v0.14.0
2017-04-04 22:02:00 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2017-04-04 22:02:00 Assuming ancestors of block 00000000000000000013176bf8d7dfeab4e1db31dc93bc311b436e82ab226b90 have valid signatures.
2017-04-04 22:02:00 GUI: "registerShutdownBlockReason: Successfully registered: Bitcoin Core didn't yet exit safely..."
2017-04-04 22:02:01 Default data directory C:\Users\********\AppData\Roaming\Bitcoin
2017-04-04 22:02:01 Using data directory E:\Bitcoin\BitCoinData
2017-04-04 22:02:01 Using config file E:\Bitcoin\BitCoinData\bitcoin.conf
2017-04-04 22:02:01 Using at most 125 automatic connections (2048 file descriptors available)
2017-04-04 22:02:01 Using 32 MiB out of 32 requested for signature cache, able to store 1048576 elements
2017-04-04 22:02:01 Using 4 threads for script verification
2017-04-04 22:02:01 Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
2017-04-04 22:02:01 scheduler thread start
2017-04-04 22:02:01 Using wallet wallet.dat
2017-04-04 22:02:01 init message: Verifying wallet...
2017-04-04 22:02:01 CDBEnv::Open: LogDir=E:\Bitcoin\BitCoinData\database ErrorFile=E:\Bitcoin\BitCoinData\db.log
2017-04-04 22:02:01 Bound to [::]:8333
2017-04-04 22:02:01 Bound to 0.0.0.0:8333
2017-04-04 22:02:01 Cache configuration:
2017-04-04 22:02:01 * Using 2.0MiB for block index database
2017-04-04 22:02:01 * Using 8.0MiB for chain state database
2017-04-04 22:02:01 * Using 290.0MiB for in-memory UTXO set (plus up to 286.1MiB of unused mempool space)
2017-04-04 22:02:01 init message: Loading block index...
2017-04-04 22:02:01 Opening LevelDB in E:\Bitcoin\BitCoinData\blocks\index
2017-04-04 22:02:05 Opened LevelDB successfully
2017-04-04 22:02:05 Using obfuscation key for E:\Bitcoin\BitCoinData\blocks\index: 0000000000000000
2017-04-04 22:02:05 Opening LevelDB in E:\Bitcoin\BitCoinData\chainstate
2017-04-04 22:02:09 Opened LevelDB successfully
2017-04-04 22:02:09 Using obfuscation key for E:\Bitcoin\BitCoinData\chainstate: ef4070bca4b243b3
2017-04-04 22:02:12 LoadBlockIndexDB: last block file = 4
2017-04-04 22:02:12 LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=1195, size=25794924, heights=141973...143836, time=2011-08-21...2011-09-03)
2017-04-04 22:02:12 Checking all blk files are present...
2017-04-04 22:02:12 LoadBlockIndexDB: transaction index disabled
2017-04-04 22:02:12 LoadBlockIndexDB: hashBestChain=0000000000000136cf94487e7716d584a0131461c9183050a1e829c0085802c0 height=143124 date=2011-08-30 03:13:46 progress=0.006681
2017-04-04 22:02:12 init message: Rewinding blocks...
2017-04-04 22:02:13 init message: Verifying blocks...
2017-04-04 22:02:13 Verifying last 6 blocks at level 3
2017-04-04 22:02:13 [0%]...[16%]...[33%]...[50%]...[66%]...[83%]...[99%]...[DONE].
2017-04-04 22:02:13 No coin database inconsistencies in last 7 blocks (411 transactions)
2017-04-04 22:02:13  block index           11773ms
2017-04-04 22:02:13 init message: Loading wallet...
2017-04-04 22:02:13 nFileVersion = 140000
2017-04-04 22:02:13 Keys: 0 plaintext, 261 encrypted, 59 w/ metadata, 261 total
2017-04-04 22:02:13  wallet                   86ms
2017-04-04 22:02:13 setKeyPool.size() = 100
2017-04-04 22:02:13 mapWallet.size() = 143
2017-04-04 22:02:13 mapAddressBook.size() = 15
2017-04-04 22:02:13 mapBlockIndex.size() = 460412
2017-04-04 22:02:13 nBestHeight = 143124
2017-04-04 22:02:13 Imported mempool transactions from disk: 0 successes, 0 failed, 0 expired
2017-04-04 22:02:13 torcontrol thread start
2017-04-04 22:02:13 AddLocal************************
2017-04-04 22:02:13 Discover: *******-PC -***************
2017-04-04 22:02:13 init message: Loading addresses...
2017-04-04 22:02:14 Loaded 64819 addresses from peers.dat  323ms
2017-04-04 22:02:14 init message: Loading banlist...
2017-04-04 22:02:14 init message: Starting network threads...
2017-04-04 22:02:14 net thread start
2017-04-04 22:02:14 dnsseed thread start
2017-04-04 22:02:14 addcon thread start
2017-04-04 22:02:14 opencon thread start
2017-04-04 22:02:14 init message: Done loading
2017-04-04 22:02:14 msghand thread start
2017-04-04 22:02:14 GUI: Platform customization: "windows"
2017-04-04 22:02:14 GUI: PaymentServer::LoadRootCAs: Loaded  49  root certificates
2017-04-04 22:02:25 Loading addresses from DNS seeds (could take a while)
2017-04-04 22:02:25 121 addresses found from DNS seeds
2017-04-04 22:02:25 dnsseed thread exit
2017-04-04 22:02:34 receive version message: /Satoshi:0.13.2/: version 70015, blocks=460415, *************, peer=0
2017-04-04 22:02:35 UpdateTip: new best=000000000000058a0bef39360166aa669e9578774dcc46a3e3ba0d6fc0717229 height=143125 version=0x00000001 log2_work=66.402201 tx=1400947 date='2011-08-30 03:27:13' progress=0.006681 cache=0.0MiB(120tx)
2017-04-04 22:02:35 UpdateTip: new best=00000000000002aa8c3a720cbb1711c2b955e683ee2fdfdff458ca2f66fff916 height=143126 version=0x00000001 log2_work=66.402315 tx=1401008 date='2011-08-30 03:50:34' progress=0.006682 cache=0.1MiB(263tx)
2017-04-04 22:02:35 UpdateTip: new best=00000000000006692c83b86054b813c6ff3e10d620217fa567220b09a96fe651 height=143127 version=0x00000001 log2_work=66.40243 tx=1401028 date='2011-08-30 03:57:37' progress=0.006682 cache=0.1MiB(296tx)
2017-04-04 22:02:35 UpdateTip: new best=00000000000007bd5

Did you make the whitelist? How many pears does it have on?

Have you made the config file yourself or did you load the core with those parameters?
The final part of the file looks like it is loading correctly at that point (but those are the ones without corruption on the hard drive).
Try to extend the whitelist if possible or just remove the files you've used in the backup and see if it'll load that way (moving the "Blocks" and "Chainstate" folder to a different location while this is being done and see if any blocks are loaded after that.

Reindex after extending the whitelist and deleting the chainstate and blocks folder. Only do that if the reindexing fails after whitelist extension.