As I had previously posted, the planned change at block 4000 underwent weeks of testing in the -testnet environment. However, even with a half-dozen people mining against the -testnet tree, we could not completely duplicate the production current block history.
As such, when the block time continue to climb, we, well, honestly, we panicked. We didn't trust our own work, or our testing, and presumed we had something backwards and pushed out the previously release. The block after that (which we are currently on) proved that indeed, we had it right with the block 4000 patch after all. What we were seeing was simply the impact of historical quick blocks on the current timing.
Today, we pulled in another developer (thanks Wes!) to do code reviews. We spent the time recoding the algo from being 'inserted' to 'native', changing all related variable names to meaningful ones, instead of trying to make the code adapt to the portions that were common with the Litecoin base.
Although our confidence is high, we also enabled additional debugging statement. Blocks on 1CR are rare, so an extra few lines in your debug.log will hardly be noticed, but should serve to build confidence that things are working as designed.
We also instituted some additional limiters - like not allowing the difficulty to adjust up or down more than 2X - something that is unlikely given a per block check.
Finally, we put a "safety valve" in the code. Should block times ever go extreme, like they are now, the next block will default to a minimum difficulty, giving the community a handful of quick blocks and allowing the difficulty algo to re-engage. We hope that this will be "one-time-only" code, which will take effect at block 4008, but it will be there no matter what happens.
Anyhow, new git source has been pushed and the windows wallet is updated and available in it normal spot off http://www.1creditcoin.org
Again, our sincere apologies
Cassey and team.