[Question] regarding difference between the ECDSA computation process in the initializing base points process and doIteration about bitcrack HOT 3 CLOSED

Additionally, I noticed that you are still verifying initial points on the CPU using ecp256k1::multiplyPoint(k, secp256k1::G()) - is there a reason why this computation is not being done on the GPU?

from bitcrack.

Hi,

More specifically, how come initializing is so much slower than iteration generation (even with the latest shift from the CPU to the GPU)?

Because initialization uses point multiplication. There is a starting key k, and we can test N keys in parallel, so we need to compute kG, (k+1)G, (k+2)G, ... (k+N-1)G

The GPU does this with 256 iterations. For each iteration, it look at one bit of the private key. If it is 1, then add a multiple of G. If not, then do nothing. The first iteration adds G, the 2nd adds 2G, the 3rd 4G, all the way up to (2^255)G

How are you checking in the doIteration process without multiplying the point by the secp256k1 curve constant like you do in the addrGen repo (secp256k1::ecpoint p = secp256k1::multiplyPoint(k, secp256k1::G());)?

Iteration only requires point addition. All the points have already been initialized to kG, (k+1)G, (k+2)G, ... (k+N-1)G. All points are incremented by N x G.

Why is the hash digest only 8 bytes when it should be 32 bytes (since it's SHA256)?

The digest is 8 x 32-bit words.

Additionally, I noticed that you are still verifying initial points on the CPU using ecp256k1::multiplyPoint(k, secp256k1::G()) - is there a reason why this computation is not being done on the GPU?

This verification is only done in debug builds in order to check that the secp256k1 library on the CPU agrees with the GPU.

I hope this clears things up. Let me know if you have more questions.

Thanks

from bitcrack.

Thank you for your response, it was very helpful.

from bitcrack.