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.
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.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):
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.
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. ↩