34
-reindex:
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
-reindex-...
17
-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 ...
9
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 ...
8
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 ...
7
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.
3
No, it would not. --reindex only handles the data that is stored on disk. Blocks are stored in the order that they are received, which is what brought you to your current view of the blockchain. So all that would happen is that you end up at that same state.
Switching to another blockchain fork requires your node to be aware of it, so you need to have ...
3
bitcoind --reindex will be faster because starting over from scratch would not only do all the work bitcoind --reindex is doing, but it'd also have to go out and re-download all those blocks too.
3
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 ...
2
A reindex will not redownload the block. However, after safely shutting down Bitcoin Core, you can delete the block file containing that block. When you start it again, you will need to reindex, but once it gets to the blocks that you deleted, it will redownload them.
2
The total extra size is around 7GB as of november 2016. You can check by looking at the size of the $DATADIR/blocks/index directory.
If you copy that directory, you'll copy the index with it.
2
It refers to actual disk space. RAM is memory, not storage. The term "disk space" is very specific.
Then a while later this:
[2020-01-20T09:05:59Z Reindexing finished]
But bitcoind continued grinding on... Well then what is all this? ::
Your node was not fully synced, so after it finished reindexing the blocks on disk, it continued to download ...
2
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.
2
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.
1
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 ...
1
You can check the debug logs (might require -debug flag) and see if it is indexing transactions:
$ tail -f ~/.bitcoin/debug.log
You can also try to get a transaction by txid, and if it returns transaction data, then the blockchain has been indexed for transactions (might have to wait for sync to complete):
$ bitcoin-cli getrawtransaction {txid}
1
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 ...
1
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.
1
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.
Only top voted, non community-wiki answers of a minimum length are eligible
