Substart startRange bug.

[hskun]

JLP use a Substart startRange to the point to solve.

  Int km(&ph->startKey);
  km.Neg();
  km.Add(&secp->order);
  km.Sub((uint64_t)(CPU_GRP_SIZE/2)*bsSize);
  startP = secp->ComputePublicKey(&km);
  startP = secp->AddDirect(keyToSearch,startP);

This is the bug. startP is a neg point.
the sub result maybe 0.
however 0 key is secp256k1 is infinity(unaviable).
I have a test input file:

400
0
FFFFFFF
02A804C641D28CC0B53A4E3E1A2F56C86F6E0D880A454203B98CD3DB5A7940D33A #0x80000

According to the code.

Int km(&ph->startKey); #0
km.Neg(); #0
km.Add(&secp->order); #0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
km.Sub((uint64_t)(CPU_GRP_SIZE/2)*bsSize); #0x80000
startP = secp->ComputePublicKey(&km); # (A804C641D28CC0B53A4E3E1A2F56C86F6E0D880A454203B98CD3DB5A7940D33A,6A417CDAD4D0592FC213D7BD3E9FB817E50E73576308C956BC316A0492B965B5)
startP = secp->AddDirect(keyToSearch,startP); #JLP show the result is 0xAFF6737C5AE67E958B6383CBA1526F2123E4EFEB757BF88CE65849490D7E51EA(wrong)

[albertobsd]

I solve this bug in my keyhunt tool adding a Point comparation if the original startKey (Computed as a public key or point ) is equals to the current searched point it show the key found , in other case it continue with the current algorithm.