Is the problem that "nActualTimespan" is to large, right?
It's really the result of the multiplication as opposed to just the "nActualTimespan" being too large. There is a check to ensure the minimum possible value for "nActualTimespan" is nTargetTimespan/4 = 302,400 = 0x49d40. Thus, when you take the regtest powLimit of 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff and multiply it by the minimum possible "nActualTimespan", the result is > (2^256) - 1.
If you can control the timestamps on the blocks, then you can for nActualTimestamp to anything.
Not quite. It is limited to a minimum and maximum value. The minimum value is, as previously stated, 0x49d40. The maximum value is nTargetTimespan*4 = 4,838,400 = 0x49d400. This effectively limits how much a single difficulty readjustment step can be.
So, while you do have some measure of control, there is no way to make it lower than the minimum allowed value and the regtest powLimit multiplied by that minimum allowed value overflows.
The simple fix, as provided by jrick in
PR 6162 is to use 512-bit arithmetic so it can't overflow.
I think today a somewhat different approach would make more sense for the regtest shortcutting and would result in a smaller divergence from the normal network behavior. (e.g. when in testing mode, mask out the highest bits of the block hashes before the target check).
That's a better idea. It emulates running lots of hashes by only running one.
It could even be a permanent thing, just change the
CheckProofOfWork() method and use a default mask of all ones.
I agree this is not a bad idea, however it does mean that whatever is creating the block also has to be modified since they are most likely mining blocks using either the built-in CPU miner, or based on details from getblocktemplate (which includes the target bits). They would therefore, by default, be aiming to create blocks using the higher difficulty.