Multiple search is possible but I won't work on it first.
I will work on a distributed client/server version.
The #110 will be likely solved soon.
With the distributed version, I'm almost sure the #115 will also be solved.
110 solve depend on multiple pubkeys search at once, in others , you all will spend time in jumping here and there, mean you need lot of gpu powers, you need lot of ram, etc, and you can not manage all things togather, and no one have these all option available, only my last word, if you design multiple pubkeys search ver, that will be solution for just within 3 days
Enjoy your research!!!
I am not sure the multiple pubkey search will really help to solve #110 within 3 days.
As I see your idea is to "decrease" the pow of the key and solve the lower bits key, however decreasing the power you will also receive the incorrect public keys which will be the dust for you and will "burn" the resources.
This is the example what you want to do (correct me if I am not right):
1) The
key #110 (with kno public key P110) has range with width 2^109 (start range is 2^109, end range is 2^110-1). To solve it, the current GPU solver needs approx. 2.22*sqrt(2^109) =
2^55.652) You want to divide this key by some number and receive the "lower bit" public key and solve that new one. Let's imagine you want to receive the key with range 2^90 instead of 2^109, so you need to divide by 2^(109-90) = 2^19 = 524 288. However as you do not know the remainder from that division you should check all the keys.
3) You make 2^19 (524 288) additions (or divisions, it does not matter) of P110 with points 0*G, 1*G, 2*G, 3*G, ... 2^19-1*G (total 2^19 points) and receive 2^19 new points. All these new points are subsequent points, and the scalar of one of that points could be divided by 2^19 with 0 remainder.
4) Now you divide (i.e multiply by inverse scalar) every of these new points by 2^19, and receive another set of 2^19 points, where one of them will be in range 2^90
5) New range for that divided points is now from 2^90 to 2^91-1 (with width exactly 2^90).
However, you do not know which point from generated 2^19 is that one with the private key in the new range. So you should check all of them, all 524 288 points (2^19). Yes, the solver could find 90 bit range for some hours, but only for one key to search. If you put 2^19 public keys, (a) the speed will not be the same as for one, (b) you will have "wrong" DPs in the hashtable generated by wild kangaroos started from "wrong" points. Only 1 point from 2^19 is correct, others are wrong and will never solved (because of the incorrect range for them).
Now, let's calculate the number of operations required to solve these 2^19 new public keys with new ranges (with one key in range
2^90). For one key, the total number of operations is 2.22*sqrt(2^90) = 2^46.15; However we have not one, but 2^19 key to check. So, the total number of operations for all new generated public keys is 2^19 * 2^46.15 =
2^65.15So, with the whole range you could solve the key for 2^55.65 operations, but now need 2^65.15 operations. This is 725 times more (2^9.5)
Moreover, this approximation does not count the new overheads due to incorrect DPs in hashtable.
Even you have several independent public keys in the same range, running their solving altogether at the same time will proportionally decrease the speed to find the collision.
