Re: [Guide] How to run a Bitcoin Core full node for under 50 bucks!
I agree, although it's different case if you need to host full node on remote server.
I strongly believe that full nodes do belong in people's homes; that's why I made this guide and why I'm so hell-bent on reasonably small blocks. 
Just like laws are kicking in in the EU right now, and probably other places in the future, laws could be put in place that categorize node operators similarly to payment providers, requiring some kind of license or KYC. Hence, cloud providers might either hand out this sort of information if queried or just forbid to run e.g. Bitcoin Core.
It's also in general a bad concept running 'decentralized' software on 'centralized' servers. Isn't this what altcoins are doing? Spinning up a few AWS instances and calling it decentralized?
Aside from bandwidth, you also need to consider CPU speed, RAM capacity and HDD speed. HDD speed can be partially solved by moving chainstate directory to SSD or allocate very big RAM to Bitcoin Core (IIRC at least 8GB).
That's right: my last node install was on such a 'budget build' as described here and it was taking too long, so I installed 4 extra GB and it went super fast. My internet connection was not very fast, but the RAM was the bottleneck. As you guys are saying; $50 can be a lot of money in some places, so I believe it's great to see that Bitcoin still manages with pretty low system requirements and such a low cost barrier to 'entry' as a node runner.For now, I would like to share my experience with a node that I've setup a few days ago. It is one of my nodes that needed a bit of maintenance; it was quite cluttered and had outdated software so I rebuilt it from scratch. I will also post a guide about it soon (OpenSUSE node walkthrough).
The hardware is a laptop motherboard with 4GB RAM and 2 500GB HDDs.
After it had taken almost a week to achieve ~40% sync, it was going super slow; around 1-2% a day, so I thought it may be a good idea to just plop in a second stick of RAM and see if it does anything. I kind of expected something to happen, but I was astonished at the speed it was going at afterwards! The HDD arm was moving much less now (audible difference); I suspect it was swapping a ton before, and the log was literally flying.
Here's a graph of some measurements I took; I let you guys guess at which point in time I upgraded the node from 4GB to 8GB
The speed at which it's going, makes me think it should be able to do a full sync in 2 days or so (from scratch); even though it's using a HDD.
Sooo.. all these modern hardware - based super fast syncing nodes.... (Pi 4 8GB + SSD + nice case) I think they actually gain most of their speed from the larger RAM and not from the SSD (which I was considering buying for this node actually)! Very impressive; that HDDs are actually this well suited for a fast IBD. I had not expected it.
The hardware is a laptop motherboard with 4GB RAM and 2 500GB HDDs.
After it had taken almost a week to achieve ~40% sync, it was going super slow; around 1-2% a day, so I thought it may be a good idea to just plop in a second stick of RAM and see if it does anything. I kind of expected something to happen, but I was astonished at the speed it was going at afterwards! The HDD arm was moving much less now (audible difference); I suspect it was swapping a ton before, and the log was literally flying.
Here's a graph of some measurements I took; I let you guys guess at which point in time I upgraded the node from 4GB to 8GB
The speed at which it's going, makes me think it should be able to do a full sync in 2 days or so (from scratch); even though it's using a HDD.
Sooo.. all these modern hardware - based super fast syncing nodes.... (Pi 4 8GB + SSD + nice case) I think they actually gain most of their speed from the larger RAM and not from the SSD (which I was considering buying for this node actually)! Very impressive; that HDDs are actually this well suited for a fast IBD. I had not expected it.