Topic: 🍑 PeachBitcoin [CHALLENGE] Run A Bitcoin Node: 14 Days To 14 Merits - page 147. (Read 35110 times)

Great Initiative @NotATether I always wanted to try Bitcoin Core but heard that it'll consume a lot of Data so I was kinda of confused. but now to take part in your challenge I am going to have a Experience Bitcoin Core Too  And hopefully learn something new as well.


Day 1 For Me:



It is my first time with Bitcoin Core in fact with any nodes. so Please guide me if I am doing it wrong.

Loyce is correct. The blocks folder will be ~550 GB. The chainstate, however, is what is constantly being read and written to.

The total size of the chainstate will only be ~9 GB once all is said and done, but it is updated after every block to remove all spent UTXOs and update all newly created UTXOs. Ideally this would be stored entirely within your RAM and only flushed to disk when you shutdown your node, but few people are running Core with a big enough dbcache, and so the chainstate file on your SSD is constantly being updated, especially during the IBD. Once you are fully synced and running, then Core will cache as much of the chainstate as possible in your RAM (up to your dbcache limit), and will optimize what it can cache to RAM (i.e. will preferentially cache newer UTXOs which are more likely to be spent rather than ones which have been dormant for years, specifically to minimize how much needs to be written to the chainstate file).

The more RAM you allocate, the less your chainstate will be written to. The less often you shutdown your node, the less your chainstate will be written to.

Well, yeah. Megabytes is technically 1000 Kilobytes, but the only people who use that measurement are disk & memory manufacturers, everyone else considers them a factor of 1024 although technically it is not.

Actually it's specified in mebibytes, according to this from bitcoin's github:


It doesn't really make a big difference, I just mention it for the sake of accuracy.

It's a lot more than that. My (laptop) sync is almost done, and my disk %util is now consistently around 96%. It has written 4.58 TB to disk in 42 hours.
When it's done, I'll create a progress graph.

For a modern disk, that's correct. My 2 TB Samsung has 1200 TBW.
One of my old SSDs can only write 36 TB. It won't instantly kill it, but it takes a significant chunk out of it's life.

Use the -dbcache setting in the command line or add dbcache=the value to your bitcoin.conf file. It's specified in megabytes and it can be a maximum of 16GB. Although most people should use 2 or 4GB of dbcache. There is little benefit to make it higher.

Are you using an HDD or SSD?

HDDs are designed to handle petabytes or at the very least, many, many terabytes of read/write IO total bytes. SSDs a bit less than that, but regardless, the process of syncing your Core Node one time doesn't affect your disk life much if at all. Having said that, if your disk is failing SMART tests, do not use any disk-intensive apps like running a Node, and get it replaced.

With this speed,  it is quick enough but I want to learn

How to set dbcache?
How to know how the sync progress kills % of my disk life?

I have Core i7, 8GB RAM and think I won't to do anything with dbcache, want to know only.

Yes, everyone can join. No, it will not kill your disk. The workload is equivalent to downloading a 600GB file in your browser and scanning it for viruses. Will that break your disk? No. No matter whether it is an HDD or SSD.

Can I join it?

I actually run a prune node since 3 Jan but on my desktop because I have my laptop to repair something for a few days. The syncing on desktop is very low.

Today, I copied the prune node data to my laptop, and it syncs very quickly.









Reading LoyceV's posts, I am worrying that it will kill my laptop and its disk. Should I continue?

Great initiative NotATether.

I am obviously running nodes since I started my bitcoin journey, but since I have less than 1000 merits, I will participate with one of my nodes.

DAY 1:

This took 11 hours and 10 minutes to sync Unfortunately, I didn't store data from getblockchaininfo. Somehow bitcoin-cli couldn't connect to the daemon now. So I can't tell how the progress estimate changed over time.

Day 4

I'm in! I started about 4 hours ago and this is my progress. The time left is showing just 3 days but it’s not always so, sometimes it reset and goes back to an average of 12 days or so.


These are my settings. I set pruning to 20GB (I think it should be more because my external ssd drive which I am using has over 500GB of space).

It's an older 128 GB disk, with 70 TBW. It's not something I worry about now, since that disk has served me for many years and still has enough left, but I was surprised that just 1 blockchain download will now take 10-20% of it's "life". It has written another 0.3 TB since my previous post.

---

---

Another experiment:
I'll keep hourly status-snapshots again.

I'm running this on a 6-core Xeon (E-2236) with 32 GB RAM and 1 GBit internet (and HDD, but I won't be using that).
I expect this one not to slow down when chainstate grows, because it won't be low on memory (and even though dbcache isn't that high, that doesn't matter when using a RAM-drive for storage).

Which SSD do you use and what is its TBW?

Now that you made me curious about the wear of my own SSD in my Umbrel node (mine is a Samsung SSD 860 Evo 1TB), I checked S.M.A.R.T. attributes:

This SSD has endured two full intial blockchain downloads and 24/7 operation as Umbrel node for about two years now. Total Power_On_Hours indicates almost three years of use but the first year of life was not as storage device for a Bitcoin node.

Attribute ID# 177 Wear_Leveling_Count is to be read as remaining percentage of endurance. So after something over a total of 94TiBW (1TiB is 2⁴⁰ bytes) my SSD is at 87% of remaining endurance. I'm not worried at all now. I was a bit worried when I read LoyceV's post.

I hope this is not off-topic here.

DAY 4 progress:

Update: with 5.6 GB chainstate, progress (and bandwidth consumption) is going down. Disk reads are increasing while CPU-consumption is decreasing.
I checked something else: writing 20-50 MB/s for a few days is very destructive for an SSD! Until now, I've written 2.6 TB in less than a day, which is already more than 10% of all writes that SSD has seen in it's entire life! My current estimate for this old disk is that this is going to cost 10-20% of the SSD's TBW (TeraBytes Written, a design-life span for SSDs). This is destructive for old SSDs with little RAM!

Some months ago I had some issues with my Raspi Umbrel node which I run for testing purposes only, not a big fan of Umbrel, (1TB SATA SSD, Raspi 4B with 8GB RAM) and I decided to throw away any Umbrel app (i.e. delete Bitcoin, Electrs, Lightning node containers on it). I didn't want to setup Umbrel completely from scratch though, because I also wanted to test how fast a (and in particular my) Raspi can perform the initial blockchain download (IBD) under slightly optimized conditions.

After deleting all Umbrel containers I made sure the blockchain files were truely gone. Then I re-installed the Umbrel Bitcoin Core container, opted for ~4.5GB of dbcache size, according to debug.log Umbrel passed dbcache=4883 to bitcoind.


My Umbrel is configured to only communicate via Tor outside of my local network. My internet connection has stable 100MBit/s for download and 40MBit/s upload bandwidth. My Raspi isn't overclocked but it is actively cooled with a fan which keeps it under 40°C even at higher workloads.

I will list the timestamps of UpdateTip log entries at intervals of 50k blocks as processed by my Raspi Umbrel below:

If there's interest, I can also post UpdateTip logs at some constant time elapsed intervals, maybe every 6h would be convenient?

As you can see the IBD to current tip at block height 796033 on 2023-06-26T16:46:31Z (received time, not blocktime) took little less than 95 hours in total on such "weak" hardware like a Raspi 4B with 8GB RAM and 1TB SATA SSD, UASP active for USB3-SATA-adapter.

Day 3

Oh wow, I felt it would require a higher specification system. My system is actually higher than yours, it’s a gaming system from barely a few years back so I believe if you can do it with this specifications then I can too. The difference is just the internet speed. I’ll just start today anyways and just see how it goes.