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 ...
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 ...
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.
To download the blockchain with maximal speed you want to be connected to nodes with high bandwidth.
On default bitcoin will search and connect to random nodes. One can add nodes to bitcoin conf to tell bitcoin to connect to specific nodes.
To add a node to the bitcoin client to connect to, add the following to the bitcoin.conf file in:
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 ...
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'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 ...
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 ...
You probably don't want to download the blockchain
The blockchain currently weighs in at about 144 GB (check current size)
Assuming you have solid 2 megabytes per second download speed, it would take around 20 hours just to download them.
In practice, this takes much longer, as your computer will verify every block individually, which takes some time.
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.
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/...
"Bitcoin-Qt/bitcoind version 0.7.1 and later supports a special import feature: If the file "bootstrap.dat" is found in the bitcoin data directory, it will validate and import all blockchain data found in that file."
The official torrent can be found at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/
Magnetic link: magnet:?xt=urn:btih:...
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, ...
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 ...
There are two factors to the time to catch up with the network:
The sheer size of the blockchain
The time to verify the blocks
As Tom mentioned the blockchain is currently about 7GB in size, so no matter what it'll take some time to download it. On the other side you have to verify each block, hence each transaction in the block, which requires random ...
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....
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.
The block files are in the same format as the bootstrap file. Their format is really simple: just concatenate all blocks after prefixing them by the network number (to avoid mixing the testnets) and the block length.
[network number] [length] [block header] [block transactions]
[network number] [length] [block header] [block transactions]
[network number] [...
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.
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 ...