Quote from: TrollByFire on September 14, 2014, 09:05:29 PM

To expand upon what has already been said:

The blockchain is slow because the difficulty is outlandish. Bitcoin proper has a maximum adjustment when a retarget should happen. As a descendant of bitcoin, LTCD shares this limitation. However, when Bitcoin was first introduced, the concept of multipools was foreign, and so there was no infrastructure to protect the network in the case of a massive hash rate decrease. Recently newer altcoins have introduced alternative algorithms for calculating a proper difficulty retarget to deal with multipool coin switches, and they seem to work rather well. The two most popular implementations are KGW and DigiShield.

In my own testing, DigiShield seems to be a bit more responsive and accurate, and so I have been working on an adaptation of their algorithm to fit the architecture I'm designing for new updates. I have been removing difficulty calculation from main.cpp and placing it into the DifficultyShield class (which probably isn't the best name for it, but for now it's what it's called.) Since difficulty algorithm is being abstracted into OO classes, it will be trivial if, in the future, we need to create a new implementation or algorithm. Instead of hacking in V1, V2, V3, etc functions, we can simply derive from the base classes and only override the necessary methods. This also starts the process of removing some of the bloat contained in main.cpp.

I have no idea if this information is useful to anyone, but I hope it serves to clear up some confusion. The current (1.0) difficulty algorithm isn't "broken". It works great for Bitcoin. It works great for Litecoin. But it isn't the right choice for LitecoinDark, and I believe we have a better solution.

so when will the fix be out, and when will the diff be in check with hash