With my struggle to resync the blockchain I learned that Bitcoin is something like the ultimate RAM test.
At least this was the most plausible explanation I heard about a phenomen I experienced myself and heard from two more people: The client loads and syncs and loads, and suddenly it stopps, no message, nothing, and if you close it and start again it tells you: "Corrupted database." - and you have to start with genesis again.
Explanation might be that the RAM makes so many operations while syncing, validating 100 millions of transactions, that even the tiniest damage of the ram, such kind of damage even your linux-memtest doesn't find, is enough to materialize at some time. like cancer materializes with a good chance after enough cell divisions, like you find a block if you do enough sha 256 calculations.
When you start again from genesis after the failure, you probably experience again. Not in the same block, maybe later, maybe earlier, but probably. Best solution is to buy a new ram (like I did -- success -- but I did also bought a new cpu that validates faster than I can download) - or to not run a client. Two of people that asked in my blog / in our forum decided to not buy a new ram because their old ram works in everything but bitcoin.
Syncing the client has requirements to rams you never find in "normal life". If the blockchain grows and grows and grows, especially when we have bigger blocks, the problem will grow with it. If we have a billion of transactions a node has to process in a row, it needs a perfect ram, and maybe even not damaged, but cheap sticks will fail.
I don't know nothing about the code, but I think the best solution would be to just do "saves", like in a videogame. Maybe save the index-files (?) evey 1024 blocks, and if the nodes detects corrupted databases he loads the last working database? If you don't need to start at zero, the problem would fade away - you can just try again and again, it doesn't matter, because your blockchain gets longer with every attempt.
At least this was the most plausible explanation I heard about a phenomen I experienced myself and heard from two more people: The client loads and syncs and loads, and suddenly it stopps, no message, nothing, and if you close it and start again it tells you: "Corrupted database." - and you have to start with genesis again.
Explanation might be that the RAM makes so many operations while syncing, validating 100 millions of transactions, that even the tiniest damage of the ram, such kind of damage even your linux-memtest doesn't find, is enough to materialize at some time. like cancer materializes with a good chance after enough cell divisions, like you find a block if you do enough sha 256 calculations.
When you start again from genesis after the failure, you probably experience again. Not in the same block, maybe later, maybe earlier, but probably. Best solution is to buy a new ram (like I did -- success -- but I did also bought a new cpu that validates faster than I can download) - or to not run a client. Two of people that asked in my blog / in our forum decided to not buy a new ram because their old ram works in everything but bitcoin.
Syncing the client has requirements to rams you never find in "normal life". If the blockchain grows and grows and grows, especially when we have bigger blocks, the problem will grow with it. If we have a billion of transactions a node has to process in a row, it needs a perfect ram, and maybe even not damaged, but cheap sticks will fail.
I don't know nothing about the code, but I think the best solution would be to just do "saves", like in a videogame. Maybe save the index-files (?) evey 1024 blocks, and if the nodes detects corrupted databases he loads the last working database? If you don't need to start at zero, the problem would fade away - you can just try again and again, it doesn't matter, because your blockchain gets longer with every attempt.
