...
This will probably not take minutes unless you have a large GPU farm, but a few weeks is a more accurate estimate. Since Bitcrack can only talk to 1 GPU as far as I know.
Without an outgoing transaction, we don't have the public key, it will take longer.
Pollard's Kangaroo method also uses a start and end range. However, it does not support strides (AFAIK) because Pollard's Kangaroo algo is using it's own kind of stride while making the tame and wild kangaroos hop. There's no way to tell Kangaroo: "OK, there is a part of the private key at the end that's already known, don't search those bits". The consequence is that
for this particular situation, Kangaroo will take longer to find the PK (way too long actually).
Bitcrack, on the other hand, lets us specify an arbitrarily large stride and it converts it to a 256-bit int. Since in this case, 80% of the private key is already known, we can make the stride equal to that huge PK chunk at the end and effectively, only search keys between Kw11111111...... and Kwzzzzzzzzzz.......
so I am plugging the value into that site: w1111111111JzXaqU2rcFSoaLaehAQHqoQX1cWCo92tAA3ihLJ7 and for hex I am getting:
64 B3 82 BA 7E 44 5B 0F 02 B1 26 EE 95 04 62 B9 E3 A8 8D 67 7C 5D E1 74 E6 44 88 6D 5B 20 F8 8F F0 10 E5 FF A5 C0. I feel like I am doing something wrong on the site.
Any insight? I am not getting the hex values you got in your original post.
My hex for w1111111111 came from the following input: w1111111111JzXaqU2rcFSoaLaehAQHqoQX1cWCo92tAA3ihLJ7
oQX1cWCo92tAA3ihLJ7 (I accidentally duplicated the last part).
Ok, so I get how to get the range for the start and finish in hex to then use in the --keyspace. What I don't know is how did you get the decimal number that starts with 244 that goes after --stride?
S.