There is one more idea I want to share.
If there is a bot owner who can produce a viable solution for every possible starting block that fit in say 60 sec threshold and require less than 60 sec for this... then this botowner is now probably building an alternate blockchain fork from 8000 block. And he will publish this blockchain shortly. His blockchain will be longer than the current blockchain because he can catch it up very quickly. If he can produce a solution in 5 sec then he needs a 5000 * 5 sec ~ 7 hours to produce a chain of 5000 blocks with solutions close to 60secs. Motocoin network will accept his new chain because his chain will be longer than the current one and it is done. This is not a 51% attack this is something different because attacker do not even need a lot of computation power to achieve this.
In other words. A bot owners can produce a blockchain fork as long as they want, each block in the forked chain will contain a solution close to 60sec. Bot owner needs far less time to achieve this than the sum of the thresholds for blocks in the chain itself. An actual block computation complexity is not connected to the threshold itself. This compromise the main idea of a blockchain. A blockchain fork attack complexity is very low now. Motocoin is literally compromised now. I am out.
What you describe is 51% attack. But you couldn't mine blocks just with 60 sec target time, if you want blocks only with 60 seconds target time then you need to ensure that average spacing between blocks is more than 60 seconds to prevent difficulty retarget to set target time to lower value; to produce longer chain this you will need to set time for some blocks far in the future and network will not accept such blocks.
If I understand this line correctly
https://github.com/motocoin-dev/motocoin/blob/e13a143890b9f6a035294dc27d729890641d2b0a/src/main.cpp#L1197:
int bnNew = 2*Current - Median - (Current - Median)*nTargetTimespan/nActualTimespan;
then if Median is equal to Current... then bnNew will be equal to Current no matter what nActualTimespan is. Even if nActualTimespan is close to zero the new complexity threshold will not be changed.
This is entirely what I'd expect, if the current rate is the same as the average rate then no adjustment is necessary. Are your proposing that if solution times remain consistent, we should retarget? Should we make the challenge easier or harder in such a case, and by how much, exactly?
If hashing strength on a sha coin remains constant would you expect changes in difficulty targets??
You are a smart fellow, but there seems to be a theme emerging in a lot of your posts.... you say "moto is flawed because motohashing has BLAH problem" but when we take your arguments and replace "moto" with "bitcoin" and "motohashing" with "sha" they entirely stop making sense. If we assume that the work function itself is computationally challenging at low bounds (still an open question, but likely true?) than there is little/no difference in semantics from litecoin, and the moto racing might as well be scrypt. For any argument against moto to succeed with this complexity assumption the argument would also have to hold up against "clasically hashed" coins as well. If your argument doesn't make sense in the context of sha hashing it likely won't make sense in the context of moto path hashing, unless you can first show that our complexity assumption about the hashing itself is flawed. (
PLEASE do so! Seriously! I desperately want to see someone do some real science around a complexity analysis of this work function. I'd be doing so myself but I'm far too busy with my bots, my dayjob, a web based replay viewer, and living life.)