How long would it take you to verify 5,000,000,000 possibilities?
less than a second
.
How is that done?? I guess it’s with RTX? Which one ?How many?
Using BSGS/kangaroo, you could check Tk/s (trillion keys, thousands of trillion keys per second), GPU is much faster than CPU in this case.
The script posted on previous page won't work, it's just dividing one key, in order to successfully divide a key, you'd need to make sure that the key is +n and also even, since we don't know it's odd or even, we'd have to assume our original key is odd, then we'd add 1 G to it, then divide both, we will then treat the results as same as our starting keys, adding 1 G to each one and dividing all, keeping all the keys, how many times we divided, how many G we added, they are all important.
But note that when you divide a key, the result could be -n version, adding 1 G and dividing that -n key will get you no where, so you'd need to do all the operations on both -n and +n keys. This should take less than a second if you have the proper algorithm implemented with the correct tool!
I don't think you understand the algorithm completely. That algorithm generates 65536 pubkeys and does this as binary in the method used when creating a normal btc wallet address. As a result of this 65536 pubkey, one of them will reduce the pubkey to 109 bits. Our main goal is to find the correct bit range. The algorithm performs the test from the test. The bit sequence is 65536, which is equivalent to 16 bits. The correct sequence of 16 bits is one in 65536. You can multiply this, but it will also increase your processing load. If you examine the bit by bit processes with the code you wrote instead of using ready-made libraries, you will see the result. In other words, the algorithm reduces 125-16=109 bits and 1 pubkey to 109 bits. 65536*65536 =2^32 , Within 2^32 bit addresses, that is, 4294967296 addresses, 1 of them is a pubkey reduced to 2^93 bits. Now, of course, for this 125th puzzle. Depending on your bsgs speed it may take some time to solve. The problem is not that the last digit is even or odd, but because it operates with 0 or 1, it doesn't matter if it's a single even, change the leading bit with the same bit order, you will get different results, so it cannot be solved with even or odd. It can be solved with bits in the correct order So my algorithm works, it outputs a little too many pubkey results.
in puzzle #125 you only need 30000 pubkey to reduce the size of the privatekeys -16bit but if you want to keep going down the bit for example -32 bits, you would need 3000000000 public keys.