Why use Bitcoin and ECDSA imports? They're so slow, it feels like a waste of time.
Instead, utilize ICE (import secp256k1 as ice) for this function and the Bitcoin address line:
def private_key_to_public_key(private_key):
priv_int = int(private_key, 16)
return ice.scalar_multiplication(priv_int)
and
bitcoin_address = ice.pubkey_to_address(0, True, public_key)
It's approximately 10 times faster than ECDSA. But even that is miserable if you attack the dinosaur numbers.
The more you delve into Python, the more apparent it becomes that searching for Puzzle 66 through it is pointless.
Is it non-pointless even if writing it in assembler? Some dick size updates: 11 million point additions/s (affine coords). There is a trick that even JLP's VanitySearch is missing which allows for some optimization on batch additions (8.5 Mkeys/s with that one). It's all about the branch processing.
On my old Laptop with i7 4810 MQ CPU
With 3500000 continuous keys in 1 group call, we get 3.5 Miilion Key/s Speed with 1 cpu:
This is very misleading. We only get the result key, not 3.500.000, simply because it does 3500000 Jacobian additions and a single final affine conversion. I don't even need to disassemble the DLL to be 100% sure about this, because the fastest known algorithm to do an modular inversion on 256-bit numbers requires 4000 CPU cycles on my i9 13th gen CPU, which means it can never ever do more than around 1 million inversions per second. But Jacobian point additions? 8 million. But those intermediary points are useless since they do not have any invariant characteristic unless you actually reduce the fractions it holds (so, the expensive mod inverse).
Anyway, all this is completely irrelevant for puzzle 66, even if magically we can do an infinite amount of additions / second, it has zero impact on the speed, because all the hashing required is many times slower than any EC operation.