wipes the chainstate (the UTXO set)
wipes the block index (the database with information about which block is where on disk)
rebuilds the block index (by going over all blk*.dat files, and finding things in it that look like blocks)
rebuilds the chainstate (redoing all validation for blocks) based on the blocks now in the index
-rescan likely did nothing at all. It goes through the blockchain to find transactions that are missing from your wallet. It is only very rarely needed (like when you manually changed things in wallet.dat).
-reindex throws away the block chain index and chain state (the database of all unspent transaction outputs), and rebuilds those from scratch. It is ...
You can't delete the block data themselves, but you can reset the blockchain state to a specific block by using the invalidateblock command. This command will mark a specific block and its descendants as invalid thus setting the chainstate to the block immediately before it. Note that this may not necessarily work to switch to a blockchain fork and may still ...
If you give Bitcoin Core a fully populated data directory, it will use it without any validation.
However, if you only give it the blocks/ subdirectory, it will fully validate it to recreate the chainstate directory, exactly as if it were received over the network.
I would like to know, if using txindex = 1, will solve my problem with transactions that are not found.
Yes, getrawtransaction only works for transactions with unspent outputs, unless txindex is enabled (in which case it will find every transaction). gettransaction only works for your wallet transactions.
Using txindex = 1 and -reindex, how long does it ...
getrawtransaction's behaviour has not changed since Bitcoin Core 0.8 (up until at least 0.14).
It will always work:
For mempool (unconfirmed) transactions
For confirmed transactions that have unspent outputs left.
So, -txindex=1 is only needed in order to query for confirmed transactions of which all the outputs are spent. It also speeds up querying for ...
txindex=1 has to be added in the bitcoin.conf file.
When starting the node, the following command should be issued
bitcoind -reindex=1 -daemon
You can keep checking the debug.log file in the .bitcoin folder to see the progress of blockchain synchronisation
Until you have downloaded the entire blockchain and reindexed, getblockcount will keep returning 0.
It walks back a small number of blocks and re-verifies them, this ensures there's no obvious corruption and warms the cache. It takes a few tens of seconds at maximum on most hardware. You can adjust or effectively disable this using checklevel=1, but it is generally inadvisable to do so.
An exhaustive survey of Google searches relating to the failure to read blknnnn.dat files implicated data corruption on the hard drive or in files such as wallet.dat and/or blknnnn.dat. In my case, however, I was able to rule out these factors. I ruled out hard drive failure by using a clone of my virtual machine that ran on a substitute hard drive. I ...
Blocks are not stored in individual files, but flat bundles of a fixed size, so replacing one that is missing isn’t really possible. If a block can not be found on disk it has either keen deleted manually or by an errant process, or the disk is seriously corrupted. A re-index will fix this, but it’s an indicator of other possible issues related to hardware ...
I can make new address and send bitcoin in proccess of reindex?
Yes, but your wallet won't be able to check whether it has been confirmed by the network (i.e. mined) until it is caught up and synced with the block in which said transaction was mined.
I just reindexed after setting txindex=1. My data directory increased in size about 3GB, but it seems like it might be saving data in another location since moving the data directory to other nodes is asking me to reindex.