I found the easiest way to do this (version 0.12) is to issue the command (not case sensitive):
Then, compare the blocks received field, to the headers field. The blocks received should increase steadily until it matches the headers field, at which point the client is synced.
Once the client is synced you can check if the ...
Bitcoin Core contains a tool to do this properly (filtering out any orphan blocks, putting everything in the correct order — which will work a lot better than just concatenating the block files. It's documented in its own README, here: https://github.com/bitcoin/bitcoin/tree/master/contrib/linearize
Launch Bitcoin with an rpcuser and rpcpassword ...
You can compare the block count from Blockexplorer with your local block count. Something like this:
$ wget -q -O- https://blockchain.info/q/getblockcount; echo
$ bitcoin-cli -conf=/u0/bitcoin/bitcoin.conf getblockcount
As you can see above my node is synched since the counter is equal.
What usually takes time is the validation of the transactions in the blockchain, not downloading it. Bitcoin Core implements a fully validating node, which does not trust any of the information other peers give it. The only way to accomplish that is by validating everything itself.
30 hours sounds painfully long though. If you have memory to spare on your ...
Bitcoin Core sync very slow
Bitcoin Core is capable of full sync in a relatively short period of time depending mainly on the hardware.
Most of the work done is not actually downloading the blocks, it is validating them and every transaction that they contain. It not only depends on downloading the blocks but also on the quantity and complexity of every ...
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 ...
Yes. You can just stop bitcoind (using bitcoin-cli stop, or just killing it with SIGINT). Next time invoke it without -reindex, and it will continue from where it left off. If you do pass -reindex again, it will start over.
Bitcoin Core maintains two databases:
The block index
The chain state (or UTXO set)
The first one just contains a list of all blocks we know about, valid and invalid. It contains all forks we have ever heard about, and all branches that result from it. It also contains information about where on disk these are stored. It does however not contain any ...
You can also just tail the debug.log file in a new terminal window while bitcoind is running. It shows current block height i.e. height=181888 and percentage of download complete i.e. progress=68.189662 and keeps running in the window, so you see the progress.
tail -f ~/.bitcoin/debug.log
tail -f $HOME/Library/Application\ Support/Bitcoin/...
No, the chainstate is the nodes view of correctness. It would take many hours or days to re-verify the whole chain on most hardware, so an assumption is made that the state stored at the previous shutdown is most likely correct. There's some sanity checking of the previous couple of blocks to make sure there is no gross accidental corruption, but malicious ...
Pass -dbcache=N as a command line option. N is a number in megabytes, and setting it higher significantly improves verification speed. The default is 450, but up to 6000 or so you can notice improvements.
This is superior to using a RAM drive.
bitcoind logs the current sync status to its debug.log file:
$ tailf ~/.bitcoin/debug.log
2017-05-26 03:49:16 UpdateTip: new best=0000000000000001e0b7c8cffb8e7fa23909b8728913663decfaebffe24ca689 height=280022 version=0x00000002 log2_work=75.644236 tx=30854900 date='2014-01-12 03:50:07' **progress=0.137838** cache=312.7MiB(396972tx)
The field progress=0....
which, as I understand it, makes some data (until 2017?) real without verification.
You understand incorrectly. Firstly, the assumevalid blocks is updated at every major release, so it is at most a couple of months out of date for the most recent release. For Bitcoin Core 0.18.0, the assumevalid block is ...
If you still have the wallet.dat file and your password you can access your bitcoins. You do not have to use Bitcoin-Qt 7 and it does not matter if your wallet ever synced before. If the sender sent the bitcoins to an address you control and the transaction was confirmed, the bitcoin are yours.
If you want to ...
Let's say I found a tarball with blockchain data files which I load to my datadir and start my Bitcoin Core client, what sort of attacks am I vulnerable to? Could the files contain fake balances?
It depends. If you're just importing blocks (so no chainstate/ subdirectory with UTXO set), there should not be any possible attack. The client will validate those ...
One! Your full node will check every transaction and every block for validity while synchronizing. You therefore can be sure that whatever blockchain data your node accepts follows all rules of Bitcoin. If you are provided the correct blockchain, a single node will be able to provide all data for you to catch up with the network's blockchain tip.
That said, ...
If you are solo mining, then you need the entire blockchain since each block you mine references the hash code of the last block in the chain. If you don't have the last block yet, then the network will reject your mined blocks since there will already be later blocks in the blockchain.
If you are mining in a pool, then you don't need the blockchain or ...
If you shut down your PC and then restart, the Bitcoin sync will pick up where it left off.
The latest transaction your Bitcoin currently knows about is 7 years old, but it won't take 7 years to catch up. It should be all caught up in a matter of days.
You will need a lot of storage for Bitcoin Qt. The current size of the blockchain is over 80 GB, and ...
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 had this happen to me once. It was apparently caused by an incompatible peer node.
Afterwards, new compatible peers will be found, and hopefully, you'll start processing blocks as expected again.
In an earlier Version of bitcoin-qt the line was the following:
SetBestChain: new best=0000000000000419f719 height=212580 work=666804971104474944731
In the log messages, new best is the start of the hash of the block
that it considers to be the head of the best chain, height is the
length of ...
Blocks are downloaded from other nodes in Bitcoin's P2P network using a custom wire protocol. For the initial synch you can imagine it as a torrent with 5000 seeders, though the Bitcoin P2P protocol is more specialised and efficient for this task than BitTorrent.
The bottleneck is almost always CPU load on validation, rather than download speed.
A bitcoin node could be down or (extremely rarely as you say) all its peers could be down... but the bitcoin network could not be considered down; you could still synchronize by connecting to different peers manually using fallback nodes or even have your own list of nodes.
The only way for the bitcoin network to be down is if all the nodes+miners are down ...
Calling getblockchaininfo is your best bet. It includes a field called verificationprogress, which is an estimate of how much of the chain you have validated.
Alternatively, compare headers to blocks. If headers is higher, it means that your node has validated the headers for blocks that it has yet to validate. When these numbers match up, it either ...
run bitcoind getinfo, compare the block count to the current block height of several major block explorers such as:
If your block count matches the block height from those sites, your block chain is in sync. If it does not match the difference in block ...
It is a blacklist of erroneous nodes' IP addresses which has accrued a certain amount of banscore due to "misbehaviour". To check what sort of erroneous behaviour is considered "misbehaving", you can check the Core source code.
It is a precaution to protect your node against potential denial of service attacks. Example actions which will accrue banscore ...
Yes, this is by design.
The notify action is run in the function BlockNotifyCallback (init.cpp), and you can see:
static void BlockNotifyCallback(bool initialSync, const CBlockIndex *pBlockIndex)
if (initialSync || !pBlockIndex)
The initialSync argument comes from the return value of IsInitialBlockDownload() (in validate....