mrb's blog

Running a Bitcoin full node on $5 a month

Keywords: bitcoin full node cost decentralization

In the context of the Bitcoin scaling debate, small blockers believe that if the block size limit is doubled, running a fully validating Bitcoin node will become expensive and only well-funded corporations will be able to run nodes, hence increasing centralization.

However facts and data disprove this narrative.

Here is a fact: despite blocks currently averaging 1 MB it is possible to run a full node on a $5/month VPS. I know because I run one. I demonstrate below it could also (likely) handle 4 MB blocks.

The point I am making is not that people should run full nodes on VPS. The point is that the cost of a VPS serves as a good indicator of the amortized cost of resources consumed by a full node, and this cost is tiny. It is irrelevant if users run the workload on a Raspberry Pi on a home connection, or on a VPS.

Technical setup

In my experience 512 MB RAM is sufficient, even during IBD (initial block download.) According to the requirements (bare minimum, with custom settings) we could do with 256 MB, but I choose 512 MB to have some headroom.

The blockchain is currently approximately 145 GB, so that is the minimum storage we need. We could run in pruned mode to reduce requirements to 5 GB, however the goal here is to have a full node archiving the entire blockchain. The blockchain will likely grow to 200-220 GB over the next year, assuming 1.0-1.5 MB blocks.

I observed the network bandwidth consumed by 30 connected peers to be in the range 100-300 GB/month (average of 300-900 kbit/s) and 95% of it is outbound.

bitcoind is at <1% CPU usage most of the time, so CPU performance is a non-issue. Extremely rare pathological cases like the 1 MB transaction in block 364292 would cause a spike of CPU usage lasting 20-60 seconds.

Here is a handful of VPS plans adequate for running a full node:

  • $3.5/mo: LetBox 512 MB RAM, 200 GB HDD, 2 TB bandwidth
  • $5/mo: HostHatch 512 MB RAM, 250 GB HDD, 1 TB bandwidth
  • $5/mo: ServerHub 512 MB RAM, 500 GB HDD, 1 TB bandwidth
  • 6€/mo: Scaleway 2 GB RAM, 200 GB SSD, 200 Mbps unmetered (3€ for VPS including 50 GB + 3€ for an extra 150 GB)

I chose ServerHub at $5/month, because it offered the most disk space.

These tips are a great baseline for reducing memory usage. However one advice is notably missing: run Bitcoin Core 0.15.0 or later because its memory usage is more predictible. Also, running a 32-bit version of Bitcoin Core may help—I have not measured by how much, but that is what I chose to run based on experience.

When first setting up the node, I configured bitcoin.conf to optimize the initial block download. The dbcache parameter (UTXO cache) should be as large as what the machine can support:


The peak system memory usage I recorded with these settings during IBD was 403 MB out of 512 MB, excluding Linux buffers/cache. IBD completed in 45 hours.1 In the initial stages it was bottlenecked by the overall network throughput of my peers at ~30 Mbit/s, while in the later stages the bottleneck shifted to CPU and disk I/O.

Once IBD completed I reconfigured bitcoin.conf to give more space to the mempool,2 allow up to 30 peers, and limit upload to 16000 MB/day (0.5 TB/month):


Complete specs of this ServerHub VPS:

  • 32-bit Debian 6.0.10 (old but fits the job)
  • 32-bit Bitcoin Core
  • 2 CPU cores Xeon E5-2630 v3 @ 2.40GHz
  • 512 MB RAM
  • 500 GB simfs (OpenVZ instance)

That is it. We have a $5/month full node, running well, perfectly healthy, contributing to decentralizing the network.

Handling larger blocks

2 MB or 4 MB blocks should not significantly increase RAM usage. The UTXO cache can remain limited (dbcache=50). It is a widespread misconception that the cache must be big enough to hold the entire UTXO set. It is fine for a non-mining full node to have many UTXO cache misses. The mempool can also remain limited (maxmempool=50) even if blocks are 2× or 4× larger. An overflowing mempool causes, at worst, occasional unnecessary network retransmissions of transactions.

2 MB or 4 MB blocks should proportionally increase network bandwidth, storage, and CPU usage. However this VPS has resources to spare: it uses only 10-30% of its monthly bandwidth, 31% of its storage space, and the CPU is <1% usage most of the time. Quadratic hashing is solved by segwit, and solvable in non-segwit transactions by limiting them to 1 MB.

If 4 MB blocks started being mined today, the monthly bandwidth would still work out (I would probably double maxuploadtarget to allow bitcoind to use the maximum amount of bandwidth possible, and reduce maxconnections from 30 to 25 if needed), and the 500 GB would fill up in 1.7 years.

So this $5/month VPS would have enough RAM/network/storage/CPU resources to function as a full node with 4 MB blocks, today and for the near future. Plus, $5/month will buy more resources 1.7 years from now, so it may be possible to continue operating a node on such a shoestring budget even further.

How does $5/month fit the narrative of small blockers who claim running a full node will become too expensive? It does not. $5/month is affordable. $5/month is within reach of enough individuals to protect decentralization.

Fun comparison: the average transaction fee right now is over $3, therefore running a full node costs less than the fees for sending 2 Bitcoin transactions a month.

  1. For comparison, as of block 482000 (August 2017) IBD can be completed in 3 hours on a high-end machine (24 cores, 64 GB RAM), see also chart on page 16 of Upcoming in Bitcoin Core 0.15

  2. In theory IBD would have run just fine with dbcache=50 and maxmempool=50 because unused mempool memory is automatically shared with the UTXO cache, since version 0.14.0. I did things the way I did out of habit. 


Which OS instance? wrote: You say that you choose 32-bit Debian 6.0.10, but this OS instance is not allowed by ServerHub. Only 64-bit Debian 5.0 is allowed. All options for the OS seems very old.
02 Nov 2017 17:51 UTC

mrb wrote: It seems ServerHub recently removed the 32-bit Debian instance option. However it doesn't matter. Bitcoin Core 32-bit should work just fine on any 64-bit instance (eg. CentOS 7 64-bit). The memory usage should be the same. You may need to install 32-bit compatibility libraries. 02 Nov 2017 19:32 UTC

anta40 wrote: Using this setup, how many BTC you usually get per month? 28 Nov 2017 12:59 UTC

mrb wrote: You need specialized equipment to mine (Canaan, Bitmain, Bitfury...). A full node simply operates the peer-to-peer Bitcoin network. 29 Nov 2017 19:47 UTC

johan wrote: Completely off-topic but I love how you layout the comments on this blog! 08 Dec 2017 14:05 UTC

Name wrote: Bitcoin Cash is more relevant. The writing has been on the wall since August 1st 2017. 20 Dec 2017 09:23 UTC

93kd0 wrote: Hi Marc, great info! I didn't know ServerHub yet but it looks like a great option. Would you say you could still use the VPS for hosting a couple of low traffic websites besides running the full node? 28 Dec 2017 19:52 UTC

Masterboy wrote: On a Raspberry Pi 1 B+ (ARMv6) running Arch Linux Arm (no need to compile bitcoin as it has a binary) I put these settings - after a few days it uses 86% of ram 444 MB of 477MB - stable and usable when overclocked to 950Mhz.
12 Jan 2018 13:21 UTC

badgerd wrote: Digiconomics has annual mining revenue at $15,322,072,328 and cost at $2,031,864,939. with 12.5 bitcoin being awarded/earned every 10 minutes that 75 per hour, 1800 per day 657,000 per year at $14,000 per bitcoin that is ~$9,2 billion not $15.3 B and i thought cost was 60%? this model looks like 13.2%. what am I missing? 14 Jan 2018 01:31 UTC

burned wrote: sorry to inform but Scaleway have denied me access to account, they "don't want" to cancel my service and/or delete my credit card/personal data, maybe it's a bad luck but I would not recommend such service. 15 Jan 2018 20:27 UTC