bitcoin.conf reference
The few options worth knowing, with their defaults, and the ones to leave alone. Defaults checked against Bitcoin Core's own -help. Run bitcoind -help on your version to confirm.
Format
One option=value per line, no leading dash, # starts a comment. Changes apply after a restart (sudo systemctl restart bitcoind). Options under a [main] header apply to mainnet only. Install and file location: setup guide.
Options worth knowing
| Option | Default | What it does |
|---|---|---|
dbcache |
450 MiB; 1024 MiB on 64-bit machines with 4 GiB or more RAM (since 31.0) | RAM for the UTXO cache, in MiB. A larger value speeds up the initial sync and matters little afterwards. Leave RAM for the OS; unused mempool memory is shared with it. |
prune |
0 (off) | 1 allows manual pruning by RPC. 550 or more keeps about that many MiB of recent blocks. Cannot be combined with txindex. Switching it off later means downloading the chain again. |
txindex |
0 (off) | Index of every transaction, for getrawtransaction on arbitrary transactions. Needed by some explorers and Electrum servers. Costs extra disk and time. |
listen |
1, except with proxy, connect or maxconnections=0 |
Accept inbound peers. Already on; inbound peers only arrive if TCP 8333 is reachable from the internet. |
maxconnections |
125 | Cap on automatic peer connections. Lower it on small devices or slow links. A node needs only about 10 outbound connections to sync. |
maxuploadtarget |
0 (no limit) | Soft cap on upload per 24 hours, in MiB unless you add a suffix such as 5G. Useful on VPS plans with a bandwidth quota. |
blocksonly |
0 (off) | Do not accept transactions from peers, which cuts bandwidth a lot. Your mempool stays empty, so fee and mempool commands show nothing useful. |
rpccookieperms |
owner | group lets members of the node's group read the RPC cookie, so a normal user can run bitcoin-cli without sudo. |
proxy, listenonion |
proxy off; listenonion 1 | Route connections through Tor, and publish an onion address when a Tor control port is available. See the Tor guide. |
Leave these unset
rpcbindandrpcallowip: RPC already listens on localhost only.rpcbindis ignored unlessrpcallowipis also set, and opening either to other machines exposes your node. See security basics.rpcuserandrpcpassword: they still work, but they store a password in plain text. The default cookie login needs no setup. If an app needs a fixed login, userpcauth.server=1:bitcoindalready accepts RPC.daemon=1: the systemd unit expects the process to stay in the foreground.upnp: no longer an option in current releases. Port mapping usesnatpmp, on by default.- Config packs pasted from forums. Read each line in
bitcoind -helpbefore you keep it.
Examples
Defaults are fine for a machine with plenty of disk, so the full node file is nearly empty.
rpccookieperms=groupPruned, for a small disk. Pick the size you can spare above 550 MiB, plus space for the chainstate. Trade-offs: pruned vs full.
rpccookieperms=group
prune=5000Pruned VPS with a bandwidth quota:
rpccookieperms=group
prune=5000
maxuploadtarget=5GCheck it applied
$ sudo systemctl restart bitcoind
$ bitcoin-cli getblockchaininfo | grep pruned
"pruned": true,
$ ss -tln | grep 8332
LISTEN 0 128 127.0.0.1:8332 0.0.0.0:*Expected: pruned matches what you set, and port 8332 is bound to 127.0.0.1 (and [::1]). 0.0.0.0 there means it is reachable from the network. If the node will not start after an edit, run journalctl -u bitcoind -n 30 --no-pager; it logs what it could not accept. Indexes and Electrum servers: Electrum server vs full node.
FAQ
Where does bitcoin.conf live?
By default in the data directory (~/.bitcoin on Linux). The setup guide uses /etc/bitcoin/bitcoin.conf, which the systemd unit passes with -conf. The path itself (-conf) can only be set on the command line, and so is the datadir when you use that unit.
Do I need a bitcoin.conf at all?
No. A node with no config file uses the defaults and works. Add options only when you have a reason.
Does prune speed up the initial sync?
No. A pruned node still downloads and validates the whole chain, then deletes old block files as it goes. It saves disk space only; time and bandwidth stay the same.
How do I see what the node is actually using?
Run bitcoind -help to list every option with its default for your installed version. The effective settings are also logged at startup.