I didn't think it needed any further explanation, but well, of course, you need to subtract public key of 55 from public key of 99 to get public key of 44.

You can just subtract divider from original key (99-55 = 44) to get same results without complex EC divisions and multiplications.

This cannot be done without knowing the private key.

Don't use cpu at all, -t 0
Check your grid size.
Also, if you use low dp setting with fast gpu, too many points enters main hashtable, this slows down overall speed.

There is no way to do this. If it were possible, the ecc would be completely broken.

yeah, you're right here, I wrote it wrong.

Kangaroo works with specific public key only, not the address, so you have to check whole secp256k1 keyspace to find it - 2^256 (using symmetry and endomorphism this can be reduced to ~2^254)

If we talking about bruteforce like bitCrack, you have to check 2^97 keys in average to find specific address (not the specific public key)

Every private key has it own unique public key, but hashing of different public keys may produce same hashes (addresses). Thus, in average, 2^96 different public/private keys have the same address.

As I said before, there is no exists inverse of zero (a[0] = b[0], b[0]-a[0] = 0)

If you modinv() function returning something with a zero argument, this is mean that is a wrong (or simplified - without error checking) implementation of modular multiplicative inverse. And that is why you're getting unexpected strange numbers in result.

Basically, zero-point, or identity point cannot be calculated, it is defined as [0;1;0] in projective coordinates or [P,0] in affine. Due to all of this, addition algorithms should contain  something like "if (p1.y != p2.y and p1.x == p2.x) return zero"

You can't calculate -P+P in a "normal" way, because this points have same X, so it will lead to division by zero (or, if we talking about EC math - multiplicative modular inverse of zero which doesn't exist).

Nobody can't help you here, until you explain how exactly you're calculated this numbers

Zero point in secp256k1 is point with zero Y (X = P = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F)
All basic calculations is applies in EC math, so: -k1*G+k1*G = -k2*G+k2*G = zero
I don't know why are you get different results with 1*G and 2*G, you should check your calculations.

No. Collisions still randomly distributed throughout whole keyspace. Some addresses may have no collisions at all.
If you find one collision, it will not help you find another collision or solve the ECDLP.

Of course it has. Equation like x+y = 10 has infinite number of solutions.

That is smart contract transactions, read here: https://eips.ethereum.org/EIPS/eip-1820

Did you write something about algorithm in your own script? Why I have to uncover my mathematical poetry?  

But ok, this is not secret - algorithm is well known lattice reduction, as was already mentioned on this forum. It works perfectly with only 4 known bits of nonces (yes, up to 252 bit nonces) and any private key length. I don't know why you also required reduced private keys.

Also I don't understand what a problem you mentioned with different nonce sizes. If all of nonces is beetween 2**1 and 2**240 then it is obviously that we know that at least first 16 bits are zeroes - this is enough for construct the matrices, and other 240 bits do not matter whether there are zeros or not.


This code is very close to my own.

You offer script "where nonce and privatekey cannot be more than 240 bit"
My script can recover keys with the same conditions.

What are you laughing at?
I have same script as yours - it can recover private from multiple transactions with reduced nonces. And i offer it for 1.5 BTC.

I'm offering the same script as yours for 1.5 BTC

What the kind of problem was?
I think you exploited symmetry to double size of giant steps?
Why it did not find some keys?

you can try to use this tool - https://www.desmos.com/calculator/ialhd71we3