What to expect when running a Bitcoin Core Full Node

This post is not about how to install Bitcoin Core and run it as a full node.

Its about what you can expect when you install Bitcoin Core and run it as a full node.

About full nodes

Firstly, lets clarify the role of a full node. A node is any system that connects to the Bitcoin network. A full node is any system that connects to the Bitcoin network and retains a full and up to date copy of the blockchain.

A full node is not a miner. Nodes simply relay information. By contrast, a miner specifically listens for transactions and tries to create new blocks. Miners do not typically hold a copy of the blockchain.

A full node fulfils one of two roles.

If you simply run a full node, and do not use it as a wallet, all your node is doing is adding to the capacity of the Bitcoin Network to relay information between nodes. This is of some value, but not hugely significant.

If you run a full node and use it as a wallet (either directly or by linking a client wallet to your node), your full node adds to the economic strength of the Bitcoin Network. It does this by enforcing the consensus rules for transactions. The more nodes that enforce the consensus rules, the more difficult it is for malicious nodes to break that consensus.

It is also worth pointing out that running your Bitcoin transactions through your own node is the purest form of transacting in Bitcoin. You have your own copy of the blockchain and can verify transactions for which you are a beneficiary without have to rely on someone else’s copy of the blockchain. It is the most accurate interpretation of the common Bitcoin axiom of “being your own bank”.


If you’re an individual and not employed by a software firm involved in Bitcoin, or some other agency tasked with promoting Bitcoin, chances are you’re going to run Bitcoin Core on some old system that you might otherwise have recycled/dumped.

Generally, this is OK. Where your system is going to need the most poke is in downloading the blockchain and verifying each block as it comes in. Once you have downloaded the entire blockchain, each new block is created every 10 minutes, so your system will have a 10 minute break between processing calls. Prior to this, when you’re downloading blocks one after the next in order to complete the blockchain, your system will exhaust its RAM and disk IO. Its quite normal for your system to be become momentarily unresponsive in this phase.

For reference, I downloaded the blockchain on an 8 year old mini-PC with 4GB of RAM and a 300GB disk. You’re going to need 180GB of disk at the time of writing to accommodate the current block chain.


Something similar applies in respect of the network. The current blockchain is ~180GB, so you’re going to have to download this. There is no hurry with this. You can stop and start the Bitcoin daemon as often as you want. It will just pick up where it left off when you restart. I set up a cron schedule on mine to start the daemon at 23:00 and stop it again at 08:00, so that the node wasn’t interfering with my day to day download requirements. It took me 5-6 week to get the entire blockchain.

At the beginning blocks will will rack up really quickly, as the first blocks weren’t full and considerably smaller than the 1mb limit. As you get into the last 50k blocks (out of 500k at time of writing), where all blocks are full, things slow down significantly.

Once you have the entire chain, the load on the network eases, as you’re only picking up 1 new 1mb block every 10 minutes. There is also a bit of chatter re. notifications but nothing substantial.

One point to note:

If the Bitcoin daemon isn’t shut down cleanly, the next time it starts, it will re-verify all the blocks it downloaded during its last run. During this time, it won’t download any new blocks, and the RPC service won’t be available to process calls. If the previous run was particularly long, this process will also take a long time. You can check the log to see that this is happening. All you can do is let it run. If the daemon gets improperly killed again, the whole process will start again when the Bitcoin daemon is restarted. You should really, really try to avoid letting the daemon stop unexpectedly. Never kill the daemon.

Checking status

How do you know when you have downloaded the full blockchain?

One way you’ll know is when the Bitcoin daemon is running, but you disk isn’t thrashing and your system is generally responsive. That generally means you have all the blocks and the daemon is just sitting there waiting to pick up the next one that becomes available.

You can obviously verify this with an RPC call too:

root@ubuntu:~# bitcoin-cli getblockchaininfo | grep blocks -A 1
 "blocks": 508695,
 "headers": 508695,

This tell you that the service can see headers on the blockchain for 508,695, and also that there are 508,695 blocks on your system.

If you stop your system for  a few hours or days, and run this command again when your restart it, the number of blocks will be lower than the numbers of headers, and your system will start thrashing again as it catches up. The longer the gap, the longer the catch up period. When your system is catching up, it has no value to the Bitcoin network, so try and organise your system so that it is always on with cron controlling whether or not the Bitcoin daemon is running.

In my next post, I will explain how to use your full node with your Bitcoin wallet.