Configuration Tuning
This section contains advice about how to change your Bitcoin Core configuration to adapt it to your needs.
Last updated
This section contains advice about how to change your Bitcoin Core configuration to adapt it to your needs.
Last updated
There are two ways to change your configuration. The first is to start Bitcoin Core with the options you want. For example, if you want to limit it to using one CPU core for signature verification, you can start Bitcoin Core like this:
Once you’ve decided you like an option, you can add it to the Bitcoin Core configuration file. You can find that file in the following directories:
Windows: %APPDATA%\Bitcoin\
OSX: $HOME/Library/Application Support/Bitcoin/
Linux: $HOME/.bitcoin/
To add an option to the configuration file, just remove its leading dash. You may also need to remove any quotation marks you used in your shell. For example, the -par option seen above would look like this in the configuration file:
A user-friendly configuration file generator is If you have any questions about configuring Bitcoin Core, please stop by one of our or .
It is possible to configure your node to run in pruned mode in order to reduce storage requirements. This can reduce the disk usage from over 350GB to around 7GB.
Running a node in pruned mode is incompatible with -txindex and -rescan. It also disables the RPC importwallet. Two RPCs that are available and potentially helpful, however, are importprunedfunds and removeprunedfunds.
To enable block pruning set prune=N on the command line or in bitcoin.conf, where N is the number of MiB to allot for raw block and undo data.
A value of 0 disables pruning. The minimal value above 0 is 550. Your wallet is as secure with high values as it is with low ones. Higher values merely ensure that your node will not shut down upon blockchain reorganizations of more than 2 days - which are unlikely to happen in practice. In future releases, a higher value may also help the network as a whole because stored blocks could be served to other nodes.
Some node operators need to deal with bandwidth caps imposed by their ISPs.
By default, Bitcoin Core allows up to 125 connections to different peers, 10 of which are outbound. You can therefore have at most 115 inbound connections.
The default settings can result in relatively significant traffic consumption.
Ways to reduce traffic:
Maximum Upload Targets
A major component of the traffic is caused by serving historic blocks to other nodes during the initial blocks download phase (syncing up a new node). This option can be specified in MiB per day and is turned off by default. This is not a hard limit; only a threshold to minimize the outbound traffic. When the limit is about to be reached, the uploaded data is cut by no longer serving historic blocks (blocks older than one week). Keep in mind that new nodes require other nodes that are willing to serve historic blocks. The recommended minimum is 144 blocks per day (max. 144MiB per day)
Disable listening
Disabling listening will result in fewer nodes connected (remember the maximum of 10 outbound peers). Fewer nodes will result in less traffic usage as you are relaying blocks and transactions to fewer nodes.
Reduce maximum connections
Reducing the maximum connected nodes to a minimum could be desirable if traffic limits are tiny. Keep in mind that Bitcoin’s trustless model works best if you are connected to a handful of nodes.
Blocks-only mode
Causes your node to stop requesting and relaying transactions unless they are part of a block and also disables listening as described above.
This reduces your node’s bandwidth to the absolute minimum necessary to stay synchronized with the network, about 150 megabytes incoming data per day and about 1 megabyte of outgoing data per day, but it does mean that your node won’t see incoming transactions until they’ve received at least one confirmation.
You will still be able to send transactions from the built-in wallet or from peers you’ve whitelisted using the -whitelist parameter.