Running a Bitcoin full node on $5 a month

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
• Handling larger blocks

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
• $4/mo: Hostens 512 MB RAM, 512 GB HDD, 4 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. [Update 2018-10-02: a new offering by Hostens is a lot more attractive with four times the bandwidth (4 vs. 1 TB per month) and a tad more storage.]

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:

dbcache=100
maxmempool=10
maxconnections=10
disablewallet=1

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.¹ 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,² allow up to 30 peers, and limit upload to 16000 MB/day (0.5 TB/month):

dbcache=50
maxmempool=50
maxconnections=30
disablewallet=1
maxuploadtarget=16000

Complete specs of this ServerHub VPS:

• 32-bit Debian 6.0.10 (old but fits the job)
• 32-bit Bitcoin Core 0.15.0.1
• 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.