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 ...
2
The getblockchaininfo RPC will tell you have many blocks and headers you have. When the number of headers is larger, you're still synchronizing.
2
In a sense, such a command would be trusting a third party: any putative answer would be that given by whoever supplied that code to you; and it may not be trustworthy - it could tell you it was 21 million, but behind the scenes actually use, say, 42 million.
The nearest you could do would be to download the source code from a proper source and, having ...
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 ...
1
This is a common issue for any service with BTC incomings/outgoings.
The answer is simply to consolidate all your inputs in a large transaction all at once, so you remove possibly hundreds of small outputs, and get one big at the end.
Usually people do this semi-regularly, though you also see people waiting until mempool fees are super low.
One reason ...
1
You can see all available command options by running the command bitcoind -?.
Similarly, in the GUI you can check out "HELP" -> "Command Line Options" in the task bar.
This will return a list of all available commands, as well as their default values (when applicable). Note that this just returns all possible command options, not specifics about what you ...
Only top voted, non community-wiki answers of a minimum length are eligible
