[error] Fatal LevelDB error: Corruption: block checksum mismatch

[28e7166c23e70c2014feb5d64]

I am trying to setup a node for the first time. I already downloaded the whole blockchain into an external Samsung T7 USB SSD drive. The node is working fine, but about one out of five times I stop `bitcoind` using the `bitcoin-cli stop` command, then the next time I start `bitcoind` I get `[error] Fatal LevelDB error: Corruption: block checksum mismatch`. I have already run `bitcoind -reindex-chainstate` about 3 times this week. The node then runs fine, until this happens again. I always stop the daemon with `bitcoin-cli stop`, always. I also always umount the external SSD and wait until the umount is done. Why is the data corrupted so often? Is it normal?

[Asiska02]

Are you sure your external SSD is not corrupt? This could be the major issue leading to that though. Your external SSD can get corrupted during the process of unmounting the SSD while trying to stopp the daemon. If your RAM is low, it can also be a factor causing that, try increasing the RAM and reduce memory usage by editing and configuring your bitcoin core.

You can also verify your system log in connection with the SSD and run a troubleshoot on your system.

[BitMaxz]

There might be a delay after using bitcoin-cli stop if you immediately unplug the external drive after sending this command, it would end up corrupted.

You should wait for a couple of minutes, and if you are using Windows OS, you should be able to see bitcoind on the task manager under details. If it's totally shut down, you shouldn't see bitcoind.

Are you using a laptop? Sometimes the USB cable is the culprit of this delay that can make your files corrupted. If you can have a USB cable with separate power, it can improve the data processing and cache on the drive to avoid this corruption.

Also use the proper way to unmount the drive; don't force it to unplug directly. You need to eject it manually to avoid corruption.

[nc50lc]

I have already run `bitcoind -reindex-chainstate` about 3 times this week. The node then runs fine, until this happens again.

Since that command can consistently fix it, it's your "UTXO set" that's always been being corrupted. (it should be in the log)
Could be during the time when the cached chainstate is being written to disk.
Or even after stopping Core when the SSD is moving data from its/system cache to the actual drive.

For the former, that is usually caused by a too high dbcache with high dbbatchsize, but it's mostly an issue if the drive is suddenly unplugged.
For the latter, it could happen if you unmount the drive right after stopping Core, but AFAIK, it will not finish unmounting until it's finished.
This shouldn't be an issue if you always pay attention to the message when you unmount, like when sometimes it doesn't actually unmount but proceeded to unplug the External SSD.
...Unless it's a hardware issue.

Of course, it's better to ask hardware-related stuffs like how your SSD works on computer hardware forums.

Why is the data corrupted so often? Is it normal?

Obviously not normal, all nodes would get their chainstate corrupted often just like yours if it's the norm.

Start by checking the drive for "bad sectors" because it's the easiest to test. Samsung should have its official SSD tool to do that.
CPU and Memory are quite troublesome to test, those appear to work fine when not stressed enough.
Those are more of a computer technical issue than Bitcoin-related though so search the internet for related tutorials.

[28e7166c23e70c2014feb5d64]

This happened again, this time not even unmounting the USB drive. `bitcoind` was running fine since yesterday. I stopped it with `bitcoin-cli stop` and waited until it finished. Time later I started it again (no `umount`, no disconnect the USB storage, no reboot, no nothing), and the error happens. This is the tail of the `debug.log` file:

```
10:12:06Z' progress=1.000000 cache=64.6MiB(492019txo)
2025-09-13T10:20:07Z New block-relay-only v2 peer connected: version: 70016, blocks=914479, peer=203
2025-09-13T10:29:20Z New block-relay-only v2 peer connected: version: 70016, blocks=914479, peer=205
2025-09-13T10:34:05Z Saw new header hash=000000000000000000008bb1e440ff81db36f781b06f2649023c6f896da5e43e height=914480
2025-09-13T10:34:11Z UpdateTip: new best=000000000000000000008bb1e440ff81db36f781b06f2649023c6f896da5e43e height=914480 version=0x27b56000 log2_work=95.821791 tx=1241565015 date='2025-09-13T
10:33:20Z' progress=1.000000 cache=65.7MiB(500558txo)
2025-09-13T10:34:29Z New block-relay-only v1 peer connected: version: 70016, blocks=914480, peer=206
2025-09-13T10:37:55Z New block-relay-only v1 peer connected: version: 70016, blocks=914480, peer=207
2025-09-13T10:47:37Z New block-relay-only v2 peer connected: version: 70016, blocks=914480, peer=208
2025-09-13T10:52:26Z Flushed fee estimates to fee_estimates.dat.
2025-09-13T10:53:53Z tor: Thread interrupt
2025-09-13T10:53:53Z opencon thread exit
2025-09-13T10:53:53Z torcontrol thread exit
2025-09-13T10:53:53Z addcon thread exit
2025-09-13T10:53:53Z Shutdown: In progress...
2025-09-13T10:53:53Z msghand thread exit
2025-09-13T10:53:53Z net thread exit
2025-09-13T10:53:56Z DumpAnchors: Flush 2 outbound block-relay-only peer addresses to anchors.dat started
2025-09-13T10:53:56Z DumpAnchors: Flush 2 outbound block-relay-only peer addresses to anchors.dat completed (0.02s)
2025-09-13T10:53:56Z scheduler thread exit
2025-09-13T10:53:56Z Writing 3852 mempool transactions to file...
2025-09-13T10:53:57Z Writing 0 unbroadcast transactions to file.
2025-09-13T10:53:57Z Dumped mempool: 0.037s to copy, 0.117s to dump, 1622666 bytes dumped to file
2025-09-13T10:53:57Z Flushed fee estimates to fee_estimates.dat.
2025-09-13T10:54:36Z Shutdown: done



2025-09-13T11:17:57Z Bitcoin Core version v29.0.0 (release build)
2025-09-13T11:17:57Z parameter interaction: -proxy set -> setting -natpmp=0
2025-09-13T11:17:57Z parameter interaction: -proxy set -> setting -discover=0
2025-09-13T11:17:57Z Using the 'standard' SHA256 implementation
2025-09-13T11:17:57Z Default data directory /home/bitcoin/.bitcoin
2025-09-13T11:17:57Z Using data directory /home/bitcoin/.bitcoin
2025-09-13T11:17:57Z Config file: /home/bitcoin/.bitcoin/bitcoin.conf
2025-09-13T11:17:57Z Config file arg: bind="127.0.0.1"
2025-09-13T11:17:57Z Config file arg: deprecatedrpc="create_bdb"
2025-09-13T11:17:57Z Config file arg: listen="1"
2025-09-13T11:17:57Z Config file arg: listenonion="1"
2025-09-13T11:17:57Z Config file arg: maxconnections="40"
2025-09-13T11:17:57Z Config file arg: maxuploadtarget="5000"
2025-09-13T11:17:57Z Config file arg: proxy="127.0.0.1:9050"
2025-09-13T11:17:57Z Config file arg: rpcauth=****
2025-09-13T11:17:57Z Config file arg: rpccookieperms="group"
2025-09-13T11:17:57Z Config file arg: server="1"
2025-09-13T11:17:57Z Config file arg: txindex="1"
2025-09-13T11:17:57Z Config file arg: whitelist="download@127.0.0.1"
2025-09-13T11:17:57Z Config file arg: zmqpubrawblock="tcp://127.0.0.1:28332"
2025-09-13T11:17:57Z Config file arg: zmqpubrawtx="tcp://127.0.0.1:28333"
2025-09-13T11:17:57Z Using at most 40 automatic connections (128000 file descriptors available)
2025-09-13T11:17:57Z scheduler thread start
2025-09-13T11:17:57Z Binding RPC on address ::1 port 8332
2025-09-13T11:17:57Z Binding RPC on address 127.0.0.1 port 8332
2025-09-13T11:17:57Z Generated RPC authentication cookie /home/bitcoin/.bitcoin/.cookie
2025-09-13T11:17:57Z Permissions used for cookie: rw-r-----
2025-09-13T11:17:57Z Using random cookie authentication.
2025-09-13T11:17:57Z Using rpcauth authentication.
2025-09-13T11:17:57Z Starting HTTP server with 16 worker threads
2025-09-13T11:17:57Z Using wallet directory /home/bitcoin/.bitcoin/wallets
2025-09-13T11:17:57Z init message: Verifying wallet(s)…
2025-09-13T11:17:57Z Using /16 prefix for IP bucketing
2025-09-13T11:17:57Z init message: Loading P2P addresses…
2025-09-13T11:17:59Z Loaded 65030 addresses from peers.dat  1698ms
2025-09-13T11:17:59Z init message: Loading banlist…
2025-09-13T11:17:59Z SetNetworkActive: true
2025-09-13T11:17:59Z Cache configuration:
2025-09-13T11:17:59Z * Using 2.0 MiB for block index database
2025-09-13T11:17:59Z * Using 56.2 MiB for transaction index database
2025-09-13T11:17:59Z * Using 8.0 MiB for chain state database
2025-09-13T11:17:59Z * Using 383.8 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)
2025-09-13T11:17:59Z Script verification uses 3 additional threads
2025-09-13T11:17:59Z Using obfuscation key for blocksdir *.dat files (/home/bitcoin/.bitcoin/blocks): 'a8e990189ca8423c'
2025-09-13T11:17:59Z Opening LevelDB in /home/bitcoin/.bitcoin/blocks/index
2025-09-13T11:17:59Z Opened LevelDB successfully
2025-09-13T11:17:59Z Using obfuscation key for /home/bitcoin/.bitcoin/blocks/index: 0000000000000000
2025-09-13T11:17:59Z Using 16 MiB out of 16 MiB requested for signature cache, able to store 524288 elements
2025-09-13T11:17:59Z Using 16 MiB out of 16 MiB requested for script execution cache, able to store 524288 elements
2025-09-13T11:17:59Z init message: Loading block index…
2025-09-13T11:17:59Z Assuming ancestors of block 00000000000000000001b658dd1120e82e66d2790811f89ede9742ada3ed6d77 have valid signatures.
2025-09-13T11:17:59Z Setting nMinimumChainWork=0000000000000000000000000000000000000000b1f3b93b65b16d035a82be84
2025-09-13T11:18:29Z LoadBlockIndexDB: last block file = 5138
2025-09-13T11:18:29Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=30, size=50335584, heights=914451...914480, time=2025-09-13...2025-09-13)
2025-09-13T11:18:29Z Checking all blk files are present...
2025-09-13T11:18:38Z Initializing chainstate Chainstate [ibd] @ height -1 (null)
2025-09-13T11:18:38Z Opening LevelDB in /home/bitcoin/.bitcoin/chainstate
2025-09-13T11:18:40Z Opened LevelDB successfully
2025-09-13T11:18:40Z Using obfuscation key for /home/bitcoin/.bitcoin/chainstate: ae677c5e7ff974fe
2025-09-13T11:18:41Z Loaded best chain: hashBestChain=000000000000000000008bb1e440ff81db36f781b06f2649023c6f896da5e43e height=914480 date=2025-09-13T10:33:20Z progress=0.999990
2025-09-13T11:18:42Z init message: Verifying blocks…
2025-09-13T11:18:42Z Verifying last 6 blocks at level 3
2025-09-13T11:18:42Z Verification progress: 0%
2025-09-13T11:25:59Z Verification progress: 16%
2025-09-13T11:49:37Z Verification progress: 33%
2025-09-13T12:02:33Z Verification progress: 50%
2025-09-13T12:05:03Z Verification progress: 66%
2025-09-13T12:17:59Z Flushed fee estimates to fee_estimates.dat.
2025-09-13T12:28:00Z LevelDB read failure: Corruption: block checksum mismatch: /home/bitcoin/.bitcoin/chainstate/059768.ldb
2025-09-13T12:28:00Z Fatal LevelDB error: Corruption: block checksum mismatch: /home/bitcoin/.bitcoin/chainstate/059768.ldb
2025-09-13T12:28:00Z You can use -debug=leveldb to get more complete diagnostic messages
2025-09-13T12:28:01Z [error] Fatal LevelDB error: Corruption: block checksum mismatch: /home/bitcoin/.bitcoin/chainstate/059768.ldb
2025-09-13T12:28:01Z : Error loading databases.
Please restart with -reindex or -reindex-chainstate to recover.
2025-09-13T12:28:01Z Shutdown: In progress...
2025-09-13T12:28:01Z scheduler thread exit
2025-09-13T12:28:05Z Flushed fee estimates to fee_estimates.dat.
2025-09-13T12:28:53Z Shutdown: done
```

[nc50lc]

This happened again, this time not even unmounting the USB drive. `bitcoind` was running fine since yesterday. I stopped it with `bitcoin-cli stop` and waited until it finished. Time later I started it again (no `umount`, no disconnect the USB storage, no reboot, no nothing), and the error happens. This is the tail of the `debug.log` file:
-snip-
2025-09-13T12:28:01Z [error] Fatal LevelDB error: Corruption: block checksum mismatch: /home/bitcoin/.bitcoin/chainstate/059768.ldb

So we can rule-out the possibility of improper unmounting.

As for the logs, like the previous, it's your chainstate (UTXO set) that's corrupted this time.
It's indicated that it caught up to the tip without issue in the last session, the options/config are good,
The shutdown process wasn't interrupted either.

I also noticed that it's using the default datadir in your "home" directory while you mentioned that it's in an external SSD.
Are you using it as your system drive as well? I can't see it as the direct cause of the issue, but could be a variable like overheating due to high disk IO.

For now, try another USB port, USB Cable and test your External SSD for hardware issue.

BTW, you can set a higher dbcache if your memory can handle it to speed-up the process of --reidex-chainstate or --reidex.
I noticed that you're using the default.

[28e7166c23e70c2014feb5d64]

I also noticed that it's using the default datadir in your "home" directory while you mentioned that it's in an external SSD.
Are you using it as your system drive as well? I can't see it as the direct cause of the issue, but could be a variable like overheating due to high disk IO.

The `.bitcoin` directory is a symlink to the folder in the USB drive.

Now it failed during `bitcoind -reindex-chainstate` in this way:

```
2025-09-13T21:22:28Z connect() to 127.0.0.1:9050 failed after wait: Connection refused (111)
2025-09-13T21:22:28Z UpdateTip: new best=000000000000000002c31d18f8364e91f94c9d2072e7323e97b61f57e36439de height=446988 version=0x20000000 log2_work=85.782986 tx=185557910 date='2017-01-07T03:20:54Z' progress=0.149714 cache=583.5MiB(4695604txo)
2025-09-13T21:22:28Z UpdateTip: new best=000000000000000001fbd8f4e70d1a5661684d6f7d83ef6a8b15f844a51499fa height=446989 version=0x20000002 log2_work=85.783016 tx=185560560 date='2017-01-07T03:42:42Z' progress=0.149716 cache=583.5MiB(4697663txo)
2025-09-13T21:22:28Z Fatal LevelDB error: Corruption: block checksum mismatch: /home/bitcoin/.bitcoin/indexes/txindex/006557.ldb
2025-09-13T21:22:28Z You can use -debug=leveldb to get more complete diagnostic messages
2025-09-13T21:22:28Z

************************
EXCEPTION: 15dbwrapper_error
Fatal LevelDB error: Corruption: block checksum mismatch: /home/bitcoin/.bitcoin/indexes/txindex/006557.ldb
bitcoin in scheduler



************************
EXCEPTION: 15dbwrapper_error
Fatal LevelDB error: Corruption: block checksum mismatch: /home/bitcoin/.bitcoin/indexes/txindex/006557.ldb
bitcoin in scheduler

terminate called after throwing an instance of 'dbwrapper_error'
  what():  Fatal LevelDB error: Corruption: block checksum mismatch: /home/bitcoin/.bitcoin/indexes/txindex/006557.ldb
Aborted
```

I will try different hardware.

[BitMaxz]

I will try different hardware.

Typically, this is caused by poor data transfer and power. Replacing the USB, as I suggested in my post above, should resolve your issue.

If replacing the USB does not work. I recommend that if you have an extra SSD/HDD, move all of your files there and reformat it. If your SSD is formatted with FAT, that's not the right format; it should be NTFS to protect your blockchain data from corruption.
Even if it is NTFS formatted, you should try a clean format and move your blockchain data back into that SSD.

Update here if it works or not for future reference.

[nc50lc]

Now it failed during `bitcoind -reindex-chainstate` in this way:
-snip-
2025-09-13T21:22:28Z Fatal LevelDB error: Corruption: block checksum mismatch: /home/bitcoin/.bitcoin/indexes/txindex/006557.ldb

Now it's one of your block index file that's corrupted.
It could only point to a faulty hardware or at least the setup.

You'll need -reindex to fix it this time.

The `.bitcoin` directory is a symlink to the folder in the USB drive.

Hmm, normally symlink shouldn't cause such issue.
But perhaps the limitations of an external drive may be affecting its reliability. (I'm not an expert on hardware though)

I think it's better to just point the blocksdir to the external SSD and keep everything in the system drive (no symlink).
You can add a blocksdir="external_blocks_directory_path" line to your "/home/bitcoin/.bitcoin/bitcoin.conf" file to set it.
The rest of the datadir files will be saved in your home directory but with -txindex, it'll occupy quite a few GB, but it's more stable that way.

[28e7166c23e70c2014feb5d64]

If replacing the USB does not work. I recommend that if you have an extra SSD/HDD, move all of your files there and reformat it. If your SSD is formatted with FAT, that's not the right format; it should be NTFS to protect your blockchain data from corruption.
Even if it is NTFS formatted, you should try a clean format and move your blockchain data back into that SSD.

It is formatted as ext4.

Now it failed during `bitcoind -reindex-chainstate` in this way:
...

I discovered that if I remove (or comment) `rpcauth=btcusr:78a8kocqo123n3u139b19695ac06401b2f$00e056c84e4981419f8c9829edaaaf9685b50988e12646318945dd9b60f0e165` from the `bitcoin.conf` file, then this error does not happen. As soon as I add that line again, it happens.

About the hardware, up to now there is no sign anything is wrong with it, except obviously for this issue with bitcoind. Any other data I put on it is fine, any test I run on it looks good. Below is a screenshot of a benchmarking done with the Gnome "disks" app:

https://i.ibb.co/0R2sn5dd/Screenshot-From-2025-09-15-07-53-31.png

(sorry, I don't understand how to embed the images here)

[LoyceV]

About the hardware, up to now there is no sign anything is wrong with it, except obviously for this issue with bitcoind. Any other data I put on it is fine, any test I run on it looks good. Below is a screenshot of a benchmarking done with the Gnome "disks" app:

Bitcoin Core is a lot more demanding than most other disk usage:

When you first start Bitcoin Core, it gives this warning:

The initial synchronisation is very demanding, and may expose hardware problems with your computer that had previously gone unnoticed.

(sorry, I don't understand how to embed the images here)

Newbies can't embed images (thanks to spammers in the past).

[28e7166c23e70c2014feb5d64]

I was going once more through a `bitcoind -reindex-chainstate` and now I got this:

```
2025-09-15T16:28:46Z UpdateTip: new best=000000000000000001b2c2c82835d620f320a164d5a2bc76d2f0055587aa6697 height=349842 version=0x00000002 log2_work=82.524812 tx=63842044 date='2015-03-29T19:08:14Z' progress=0.051480 cache=50.0MiB(385365txo)
2025-09-15T16:28:46Z UpdateTip: new best=000000000000000010feb2e9b195c0408363531d31956884f8c53629563d922d height=349843 version=0x00000002 log2_work=82.524854 tx=63842176 date='2015-03-29T19:10:00Z' progress=0.051480 cache=50.0MiB(385570txo)
2025-09-15T16:28:46Z UpdateTip: new best=000000000000000017812eba7442fbdcb107445daefe1ce338b8f0d257e66681 height=349844 version=0x00000003 log2_work=82.524896 tx=63844394 date='2015-03-29T19:54:54Z' progress=0.051482 cache=50.2MiB(387915txo)
2025-09-15T16:28:46Z [error] ReadBlock: Deserialize or I/O error - ReadCompactSize(): size too large: iostream error at FlatFilePos(nFile=249, nPos=60126709)
2025-09-15T16:28:46Z [error] A fatal internal error occurred, see debug.log for details: Failed to read block.
Error: A fatal internal error occurred, see debug.log for details: Failed to read block.
2025-09-15T16:28:46Z [error] A fatal internal error occurred, see debug.log for details: Failed to connect best block (Failed to read block.).
Error: A fatal internal error occurred, see debug.log for details: Failed to connect best block (Failed to read block.).
2025-09-15T16:28:46Z tor: Thread interrupt
2025-09-15T16:28:46Z Loading 519 mempool transactions from file...
2025-09-15T16:28:46Z torcontrol thread exit
2025-09-15T16:28:46Z addcon thread exit
2025-09-15T16:28:46Z Shutdown: In progress...
2025-09-15T16:28:46Z msghand thread exit
2025-09-15T16:28:46Z net thread exit
2025-09-15T16:28:46Z initload thread exit
2025-09-15T16:28:46Z opencon thread exit
2025-09-15T16:28:46Z DumpAnchors: Flush 2 outbound block-relay-only peer addresses to anchors.dat started
2025-09-15T16:28:46Z DumpAnchors: Flush 2 outbound block-relay-only peer addresses to anchors.dat completed (0.01s)
2025-09-15T16:28:46Z scheduler thread exit
2025-09-15T16:28:46Z Flushed fee estimates to fee_estimates.dat.
2025-09-15T16:28:47Z Shutdown: done
```

Faulty USB SSD drive? It is a Samsung T7. Which one could I use instead?

[LoyceV]

Faulty USB SSD drive? It is a Samsung T7. Which one could I use instead?

Check the SMART status, that may tell you more. It could still just be a cable problem.
Take a step back: what are you trying to accomplish? I wouldn't use an external disk for Bitcoin Core, it's just waiting for problems. I'd either install a larger internal disk, prune Bitcoin Core, or use Electrum.

[28e7166c23e70c2014feb5d64]

At the moment I just want to setup a node for learning purposes.

Why on an external USB SSD? So it is system independent, today I run it in PC1, next week in PC2, and so on. In the end, the `.bitcoin` directory is just data. I have followed this approach with many applications in the past, also dealing with multi-Terabyte datasets, and it usually worked very well. Though I recognize the bitcoin node seems to be much more stringent in terms of read/write speed (part of my learning  ).

I am now downloading the blockchain again. When it finishes and is working, I will make an image of the data directory so when it breaks, it does not take that long again.

[nc50lc]

2025-09-15T16:28:46Z [error] ReadBlock: Deserialize or I/O error - ReadCompactSize(): size too large: iostream error at FlatFilePos(nFile=249, nPos=60126709)

First your 'UTXO set', next your 'Block Index', now it's your actual blockchain that's corrupted.
The error means that your "blk00249.dat" file is corrupted.

At this point, you should stop trying to re-sync or fix it with --reindex for now and do an extensive hardware stability check on your machine and external SSD.
Sync Core once confirming that the hardware is good or after replacing the bad part(s).

[BitMaxz]

It is formatted as ext4.

That filesystem should be fine for a Linux PC.

I did some research about this SSD model; it seems it's common for this model to have a slow writing speed but have faster read.
This might be the cause of this issue, like the report here.

However, the most common solution that I heard is to update its firmware.
I found the guide from Samsung on how to update SSD. You can read them here

Updating shouldn't affect the stored data, but for safety purposes make sure to back up all data first before you proceed to update it to the latest version.

[takuma sato]

At the moment I just want to setup a node for learning purposes.

Why on an external USB SSD? So it is system independent, today I run it in PC1, next week in PC2, and so on. In the end, the `.bitcoin` directory is just data. I have followed this approach with many applications in the past, also dealing with multi-Terabyte datasets, and it usually worked very well. Though I recognize the bitcoin node seems to be much more stringent in terms of read/write speed (part of my learning   ).

I am now downloading the blockchain again. When it finishes and is working, I will make an image of the data directory so when it breaks, it does not take that long again.

I run the same setup and I have a number of SSD and HDD disks that I tested with including yours, that one works well on a relatively old laptop with an USB3 port. What is your system settings?

I was having checksum error mismatches as well and what solved it was to lower par=1, and dbcache no more than a third of your total RAM. Try that and guarantee your CPU is not overheating. If overheating then clean CPU fan and reapply thermal paste. Also try to buy RAM modules and reach 16 GB ram.

To test health of the disk the crystaldiskinfo program works well on Windows, to test read and write speed and see if it's what's expected.

Try some SMART  tests with gsmartcontrol on linux.

Potentially delete chainstate folder and run bitcoin-qt with -reindex to rebuild from scratch.

Also, if you have a more powerful computer, you can do the initial block download with it and then use the laptop as a node, because spammers have made it hell to verify blocks my older thinkpad laptops no longer can finish the initial block download or at least it would take ages and the CPU's are struggling to process these blocks.

[28e7166c23e70c2014feb5d64]

I just discovered that my system time as reported by the `timedatectl status` command was wrong by 1 hour with respect to my location, because he `Time zone` was set to a nearby city but not my city.

Could this be the reason it corrupts the data?

[LoyceV]

Could this be the reason it corrupts the data?

No.

[nc50lc]

I just discovered that my system time as reported by the `timedatectl status` command was wrong by 1 hour with respect to my location, because he `Time zone` was set to a nearby city but not my city.
Could this be the reason it corrupts the data?

Hmm, that shouldn't cause any corruption.

In bitcoin, your system's misconfigured clock shouldn't cause any issue even if you set it to an hour late/advance as long as it's not 70minutes prior/past the network's "median time".
If it does, you'll get related warnings instead of random corruption.