Quote from: randywald on August 05, 2014, 05:01:18 PM

Ok, thanks for testing. So my question: Is there a function to tell the client on startup to skip scanning all the blocks or to skip that what takes so much time? Can the wallet be used as a "lite wallet" without all the blockchain or so? Thank you.

I think I have a handle on why the loading is so slow. Since microcoin is based (however loosely) on Bitcoin-Qt, it has a full blockchain and creates an index in memory during the "Loading Block Index" phase. I imagine for security sake, the hashes of the blocks do not appear to be stored in the blkindex.dat, which maps location of blocks in the blknnnn.dat files. Thusly, while loading the block index in memory, the hashes of all blocks are calculated. For Scrypt-jane at high N-factor, this takes thousands of times longer than a SHA256d hash and is the reason why start-up time is slow.

My proposal is to go ahead and save the hashes in the blkindex.dat file alongside the index and simply load from the db. This requires a few considerations/possibilities: 1) update-in-place an old blkindex.dat file 2) require blockchain be discarded and re-downloaded 3) offer a command line option to to hash validation 4) spawn a thread to check the hashes after loading from disk, and report any errors later.

For a full node, calculating the hashes is important because it validates the block chain has not been tampered with. However, due to the complexity of Scrypt-jane with modified N-factor, we need to cache the hashes in order to be able to start quickly.

With that in mind, I do think I can put together a solution specific for this issue, without all of the coin control, multi-wallet and multi-sig changes I have been analyzing separately. However, I promise no time frame because I have many other things on my plate and because summer vacation.