Tiny 1-block forks in blk.dat files I just completed parsing the Testnet3 Bitcoin blockchain stored in the blk.dat files into a database. Since I was using multi-processing to parse several files at the same time, I didn't add the height to the blockchain while parsing it. Instead, I did this after the whole blockchain was parsed.
Everything was going smoothly while adding the height to the blocks for the most part. However, approaching the end of the blockchain (the last 7%), my code started to crash because it started to find 2 different blocks that had the same previous block (basically, a fork), and I had already constrained my database to avoid having 2 blocks with the same height. All these tiny forks I have been finding are just one block long, and it looks like the closer I get to the end, the most common it is to find these tiny forks.
I have had to look both block-ids up in a block explorer to find out which one is the official block and which one is the fork (&quot;fake&quot; block). One of them is always non-existent for which I know it is not an ID misplacing. I have been manually deleting the link of the &quot;fake&quot; block so my code can keep adding the height, but as I said before, it becomes more and more common to find these tiny forks the more I approach the end of the blockchain.
I was just wondering if this is normal, or if there is something really wrong with my blk.dat files.
This is normal, especially on testnet. What you are seeing are known as stale blocks (or also incorrectly as orphan blocks). These occur when miners complete a block at around the same time so some nodes receive the two blocks in a different order. The conflict resolves when the next block is found.
You will commonly see stale blocks on testnet due to testnet's low difficulty. Furthermore, you see these towards the chain tip because it is only possible to receive these when you are not attempting to do the initial sync. So you won't receive stale blocks during the initial sync, but once you exit that and begin normal operation and your node receives new blocks, you will end up receiving stale blocks (but they aren't necessarily stale yet).
You will need to modify your code to handle stale blocks.