DEV FLASH
- During the first low diff period, we got high hash inputs and pools were finding blocks very quickly. The sudden influx of quick blocks with slightly different difficulty numbers triggered the DDoS protection - and network nodes (primarily the pools) were temporarily blacklisted. This resulted in micro-forks until the diff adjustment slowed things down, everyone resynchronized, and the network stabilized.
It is not "slightly different difficulty numbers" that are causing the DoS logic to kick in, it is a bug in ComputeMinWork and out-of-date checkpoints.
Here is what I am seeing, clients are getting disconnected in ProcessBlock by the DoS logic with this error message:
ERROR: ProcessBlock() : block with too little proof-of-work
The Blocks are being rejected because:
1) The latest checkpoint is on block 20000 from Dec 30
2) deltaTime passed into ComputeMinWork is about 3921600 (about 6 weeks)
3) ComputeMinWork is using nTargetTimespanOld*4 (2 weeks * 4) instead of nTargetTimespan*4 (6 hours * 4) because nHeight of the last checkpoint is less than 20290.
4) The diff at the last checkpoint was 64, causing ComputeMinWork to return a Diff of 16 instead of a proper value below 0.015625.
5) Pools are attempting to submit blocks with a diff that is valid (above the 2-3 diff currently floating around), but is below 16 that ComputeMinWork is returning.
6) The pool is DoS'ed for publishing a "invalid" block and cut off of the network.
7) The pool continues to build what it thinks are valid blocks in the 2-16 diff range the the rest of the network rejects, and it lands on a fork.
(The reason you did not see it on testnet is because ComputeMinWork returns bnProofOfWorkLimit.GetCompact() for testnet, and it never gets to the spot where the bug is.)
The solution is simple:
Create a new checkpoint with nHeight > 20290.