Using Kangaroo for WIF solving

[PawGo]

Hello

I would like to share with you my modifications of Jean-Luc's famous Kangaroo program. I adapted it to be used as a 'WIF solver'.
In general, there are 2 cases - where stride is large enough not to collide with WIF checksum or when it is more complicated and stride collides.
I described it and showed test examples on github:
https://github.com/PawelGorny/Kangaroo
but I will also rewrite it here.

Let's take WIF: 5HrdZxkxnVst8Q3qCLJkeiLe1k4AmSDaAhqQVUYVxVSBkf5VfUu which encodes the private key 0552e025571c01bcda0297c22731d74becbd30d07e4ec355c741825fffc0a672.
Decoded WIF shows checksum 524412ca
The corresponding public key is 04777c026b8085951da7117395bf269c055f36bf2ddf623281962855edee36d4e73bec2fa87b122 a0f1b2841ef4f7afdec2443f89c151ee2597feac18ae0d62bdf

• Search without checksum (large stride)

Let's take WIF 5HrdZxkxnVst8Q_____keiLe1k4AmSDaAhqQVUYVxVSBkf5VfUu
Now, we may find the first WIF to be tested, it will be 5HrdZxkxnVst8Q11111keiLe1k4AmSDaAhqQVUYVxVSBkf5VfUu. When we decode it, we find the private key which is the beginning of our range: 0552e025571c01bcd9eda59365a2fb3ae0bd7547dfeeeb13d971d848bcbf0467
Now, we must calculate the number of WIFs in our range. Beause we have 5 missing characters, it will be 58^5 = 656356768 (271f35a0 hex)
To have the end of range for Kangaroo, we must calculate fake end which is start + range

Code:

new BigInteger("0552e025571c01bcd9eda59365a2fb3ae0bd7547dfeeeb13d971d848bcbf0467",16).add(new BigInteger("656356768",10)).toString(16) =
552e025571c01bcd9eda59365a2fb3ae0bd7547dfeeeb13d971d848e3de3a07

We check where is the most right unknown character - it's position will tell us what is the stride. In our case it is 58^32 = af820335d9b3d9cf58b911d87035677fb7f528100000000
Because WIFs encodes checksum, we must observe if stride collides with checksum. Fortunately - not, because the last 8 characters (length of checksum) are 0s. We may remove these zeros and get shorter stride.
The final configuration file is:

Code:

552e025571c01bcd9eda59365a2fb3ae0bd7547dfeeeb13d971d848bcbf0467
552e025571c01bcd9eda59365a2fb3ae0bd7547dfeeeb13d971d848e3de3a07
04777c026b8085951da7117395bf269c055f36bf2ddf623281962855edee36d4e73bec2fa87b122a0f1b2841ef4f7afdec2443f89c151ee2597feac18ae0d62bdf

and test:

Code:

$ ./kangaroo -stride af820335d9b3d9cf58b911d87035677fb7f5281 test_af820335d9b3d9cf58b911d87035677fb7f5281.txt
Kangaroo v2.2
Start:552E025571C01BCD9EDA59365A2FB3AE0BD7547DFEEEB13D971D848BCBF0467
Stop :552E025571C01BCD9EDA59365A2FB3AE0BD7547DFEEEB13D971D848E3DE3A07
Keys :1
Stride:
MaxRange: 271F35A0
Jump: AF820335D9B3D9CF58B911D87035677FB7F5281
Number of CPU thread: 2
Range width: 2^30
Jump Avg distance: 2^15.04
Number of kangaroos: 2^11.00
Suggested DP: 1
Expected operations: 2^16.11
Expected RAM: 13.3MB
DP size: 1 [0x8000000000000000]
SolveKeyCPU Thread 1: 1024 kangaroos
SolveKeyCPU Thread 0: 1024 kangaroos

 verify PK 552E025571C01BCD9EDA59365A2FB3AE0BD7547DFEEEB13D971D848BEA7DAF2
Key# 0 [2N]Pub:  0x03777C026B8085951DA7117395BF269C055F36BF2DDF623281962855EDEE36D4E7
       Priv: 0x552E025571C01BCD9EDA59365A2FB3AE0BD7547DFEEEB13D971D848BEA7DAF2
   RealPriv: 0x552E025571C01BCDA0297C22731D74BECBD30D07E4EC355C741825FFFC0A672

• Search with checksum (small stride)

Let's take WIF 5HrdZxkxnVst8Q3qCLJkeiLe1k4Am____hqQVUYVxVSBkf5VfUu
Now, we may find the first WIF to be tested, it will be 5HrdZxkxnVst8Q3qCLJkeiLe1k4Am1111hqQVUYVxVSBkf5VfUu. When we decode it, we find the private key which is the beginning of our range: 0552e025571c01bcda0297c22731d74becbd30cfb218f04dc91299473f61ffde
Now, we must calculate the number of WIFs in our range. Beause we have 4 missing characters, it will be 58^4 = 11316496
To have the end of range for Kangaroo, we must calculate fake end which is start + range

Code:

new BigInteger("0552e025571c01bcda0297c22731d74becbd30cfb218f04dc91299473f61ffde",16).add(new BigInteger("11316496",10)).toString(16) =
552e025571c01bcda0297c22731d74becbd30cfb218f04dc9129947400eacee

We check where is the most right unknown character - it's position will tell us what is the stride. In our case it is 58^18 = 2b85840fc1d6a480ae7fa240000
Unfortunately the stride collides with checksum (last 8 characters are not 0s). It means that for our calculations we must take into account the proper checksum And this is difficult part, because the real checksum is unknown. In our test it is known, but in real-life it could be needed to see how many possibilities there are. For example, in this case, playing with missing characters of WIF we may observe that last 4 characters of checksum are fixed. The first 4 could be changed, BUT the 4th character gets only 4 values. It means that if we want to use this method for real-life problem, we may need to do calculations for 16*16*16*4 checksums (in fact will less operations needed, because many checksums will generate the same private key in addition to the stride).
Because stride collides with checksum, we will have to use the full (long) value and pass checksum as a parameter.
The final configuration file is:

Code:

552e025571c01bcda0297c22731d74becbd30cfb218f04dc91299473f61ffde
552e025571c01bcda0297c22731d74becbd30cfb218f04dc9129947400eacee
04777c026b8085951da7117395bf269c055f36bf2ddf623281962855edee36d4e73bec2fa87b122a0f1b2841ef4f7afdec2443f89c151ee2597feac18ae0d62bdf

and test:

Code:

$ ./kangaroo -stride 2b85840fc1d6a480ae7fa240000 -checksum 524412ca test_2b85840fc1d6a480ae7fa240000_524412ca.txt
Kangaroo v2.2
Start:552E025571C01BCDA0297C22731D74BECBD30CFB218F04DC91299473F61FFDE
Stop :552E025571C01BCDA0297C22731D74BECBD30CFB218F04DC9129947400EACEE
Keys :1
Stride:
MaxRange: ACAD10
Jump: 2B85840FC1D6A480AE7FA240000
checksum:
Number of CPU thread: 2
Range width: 2^24
Jump Avg distance: 2^11.97
Number of kangaroos: 2^11.00
Suggested DP: 0
Expected operations: 2^13.25
Expected RAM: 12.4MB
DP size: 0 [0x0]
SolveKeyCPU Thread 1: 1024 kangaroos
SolveKeyCPU Thread 0: 1024 kangaroos

 verify PK 552E025571C01BCDA0297C22731D74BECBD30CFB218F04DC91299473FAD12F9
Key# 0 [2N]Pub:  0x03777C026B8085951DA7117395BF269C055F36BF2DDF623281962855EDEE36D4E7
       Priv: 0x552E025571C01BCDA0297C22731D74BECBD30CFB218F04DC91299473FAD12F9
   RealPriv: 0x552E025571C01BCDA0297C22731D74BECBD30D07E4EC355C741825FFFC0A672

[Coding Enthusiast]

Interesting approach but what's the speed of something like this?

And how does it perform compared to the simple approach of decoding and computing checksum that only computes SHA256?
For example it takes me 3.5 min to check the entire 656 million keys in your first example using checksum (answer is found after 1.1 min) and it is faster if the key was compressed (KwQ4QV73DpTafe_____MfTTgNH2z78JVPqEegga2ovWATXzDVu6U) only 25 seconds.

[PawGo]

For these examples - result is instant.
I have made test with 10 missing characters (CPU only, on my dev machine I do not have GPU).

Code:

5HrdZxkxn__________keiLe1k4AmSDaAhqQVUYVxVSBkf5VfUu
5HrdZxkxn1111111111keiLe1k4AmSDaAhqQVUYVxVSBkf5VfUu
0552e02556fb5aeb9aedc2ea64efec8ac200eb71a9653cfaad25d4c2a5b4d5c7

Range: BigInteger.valueOf(58L).pow(10).toString(16) =
 5fa8624c7fba400

Fake end: new BigInteger("0552e02556fb5aeb9aedc2ea64efec8ac200eb71a9653cfaad25d4c2a5b4d5c7",16).add(new BigInteger("5fa8624c7fba400",16)).toString(16) = 
552e02556fb5aeb9aedc2ea64efec8ac200eb71a9653cfab3205ae76db079c7

Config file:

Code:

0552e02556fb5aeb9aedc2ea64efec8ac200eb71a9653cfaad25d4c2a5b4d5c7
552e02556fb5aeb9aedc2ea64efec8ac200eb71a9653cfab3205ae76db079c7
04777c026b8085951da7117395bf269c055f36bf2ddf623281962855edee36d4e73bec2fa87b122a0f1b2841ef4f7afdec2443f89c151ee2597feac18ae0d62bdf

Test:

Code:

$ ./kangaroo -stride af820335d9b3d9cf58b911d87035677fb7f5281 testBig.txt
Kangaroo v2.2
Start:552E02556FB5AEB9AEDC2EA64EFEC8AC200EB71A9653CFAAD25D4C2A5B4D5C7
Stop :552E02556FB5AEB9AEDC2EA64EFEC8AC200EB71A9653CFAB3205AE76DB079C7
Keys :1
Stride:
MaxRange: 5FA8624C7FBA400
Jump: AF820335D9B3D9CF58B911D87035677FB7F5281
Number of CPU thread: 2
Range width: 2^59
Jump Avg distance: 2^28.96
Number of kangaroos: 2^11.00
Suggested DP: 15
Expected operations: 2^30.59
Expected RAM: 13.9MB
DP size: 15 [0xfffe000000000000]
SolveKeyCPU Thread 1: 1024 kangaroos
SolveKeyCPU Thread 0: 1024 kangaroos
[3.28 MK/s][GPU 0.00 MK/s][Count 2^30.87][Dead 0][10:49 (Avg 08:13)][3.8/12.4MB]
 verify PK 552E02556FB5AEB9AEDC2EA64EFEC8AC200EB71A9653CFAB01FDAB8EEA94AF2
Key# 0 [2N]Pub:  0x03777C026B8085951DA7117395BF269C055F36BF2DDF623281962855EDEE36D4E7
       Priv: 0x552E02556FB5AEB9AEDC2EA64EFEC8AC200EB71A9653CFAB01FDAB8EEA94AF2
   RealPriv: 0x552E025571C01BCDA0297C22731D74BECBD30D07E4EC355C741825FFFC0A672

Done: Total time 10:49

Not bad, no?  10 missing WIF characters - Less than 11 minutes on old CPU. GPU performance - to be seen.

[Coding Enthusiast]

Not bad, no?  10 missing WIF characters - Less than 11 minutes on old CPU. GPU performance - to be seen.

That's fantastic. I'll have to go back to check Pollard's kangaroo algorithm again.

[WanderingPhilospher]

On a piddly 1060 6GB GPU

Code:

Kangaroo v2.2
Start:552E02556FB5AEB9AEDC2EA64EFEC8AC200EB71A9653CFAAD25D4C2A5B4D5C7
Stop :552E02556FB5AEB9AEDC2EA64EFEC8AC200EB71A9653CFAB3205AE76DB079C7
Keys :1
Stride:
MaxRange: 5FA8624C7FBA400
Jump: AF820335D9B3D9CF58B911D87035677FB7F5281
Number of CPU thread: 0
Range width: 2^59
Jump Avg distance: 2^28.96
Number of kangaroos: 2^19.32
Suggested DP: 7
Expected operations: 2^30.60
Expected RAM: 498.6MB
DP size: 7 [0xFE00000000000000]
GPU: GPU #0 GeForce GTX 1060 6GB (10x128 cores) Grid(20x256) (57.0 MB used)
SolveKeyGPU Thread GPU#0: creating kangaroos...
SolveKeyGPU Thread GPU#0: 2^19.32 kangaroos [4.8s]
[67.92 MK/s][GPU 67.92 MK/s][Count 2^31.85][Dead 3][54s (Avg 24s)][0.9/1.1GB]  B]
 verify PK 552E02556FB5AEB9AEDC2EA64EFEC8AC200EB71A9653CFAB01FDAB8EEA94AF2
Key# 0 [2N]Pub:  0x03777C026B8085951DA7117395BF269C055F36BF2DDF623281962855EDEE36D4E7
       Priv: 0x552E02556FB5AEB9AEDC2EA64EFEC8AC200EB71A9653CFAB01FDAB8EEA94AF2
   RealPriv: 0x552E025571C01BCDA0297C22731D74BECBD30D07E4EC355C741825FFFC0A672

Done: Total time 01:17

I didn't mess with any settings, like DP, not sure if it matters or not. Just ran it straight out the box.

2070 Super with DP of 14:

Code:

Kangaroo v2.2
Start:552E02556FB5AEB9AEDC2EA64EFEC8AC200EB71A9653CFAAD25D4C2A5B4D5C7
Stop :552E02556FB5AEB9AEDC2EA64EFEC8AC200EB71A9653CFAB3205AE76DB079C7
Keys :1
Stride:
MaxRange: 5FA8624C7FBA400
Jump: AF820335D9B3D9CF58B911D87035677FB7F5281
Number of CPU thread: 0
Range width: 2^59
Jump Avg distance: 2^28.96
Number of kangaroos: 2^20.32
Suggested DP: 6
Expected operations: 2^32.18
Expected RAM: 23.3MB
DP size: 14 [0xFFFC000000000000]
GPU: GPU #2 GeForce RTX 2070 SUPER (40x64 cores) Grid(80x128) (107.0 MB used)
SolveKeyGPU Thread GPU#2: creating kangaroos...
SolveKeyGPU Thread GPU#2: 2^20.32 kangaroos [10.8s]
[795.42 MK/s][GPU 795.42 MK/s][Count 2^33.45][Dead 9][17s (Avg 06s)][23.8/55.7MB]
 verify PK 552E02556FB5AEB9AEDC2EA64EFEC8AC200EB71A9653CFAB01FDAB8EEA94AF2
Key# 0 [2N]Pub:  0x03777C026B8085951DA7117395BF269C055F36BF2DDF623281962855EDEE36D4E7
       Priv: 0x552E02556FB5AEB9AEDC2EA64EFEC8AC200EB71A9653CFAB01FDAB8EEA94AF2
   RealPriv: 0x552E025571C01BCDA0297C22731D74BECBD30D07E4EC355C741825FFFC0A672

Done: Total time 31s

2070 Super with DP of 10:

Code:

Kangaroo v2.2
Start:552E02556FB5AEB9AEDC2EA64EFEC8AC200EB71A9653CFAAD25D4C2A5B4D5C7
Stop :552E02556FB5AEB9AEDC2EA64EFEC8AC200EB71A9653CFAB3205AE76DB079C7
Keys :1
Stride:
MaxRange: 5FA8624C7FBA400
Jump: AF820335D9B3D9CF58B911D87035677FB7F5281
Number of CPU thread: 0
Range width: 2^59
Jump Avg distance: 2^28.96
Number of kangaroos: 2^20.32
Suggested DP: 6
Expected operations: 2^31.04
Expected RAM: 94.5MB
DP size: 10 [0xFFC0000000000000]
GPU: GPU #2 GeForce RTX 2070 SUPER (40x64 cores) Grid(80x128) (107.0 MB used)
SolveKeyGPU Thread GPU#2: creating kangaroos...
SolveKeyGPU Thread GPU#2: 2^20.32 kangaroos [10.8s]
[451.64 MK/s][GPU 451.64 MK/s][Count 2^30.05][Dead 0][02s (Avg 04s)][35.1/68.6MB]
 verify PK 552E02556FB5AEB9AEDC2EA64EFEC8AC200EB71A9653CFAB01FDAB8EEA94AF2
Key# 0 [2N]Pub:  0x03777C026B8085951DA7117395BF269C055F36BF2DDF623281962855EDEE36D4E7
       Priv: 0x552E02556FB5AEB9AEDC2EA64EFEC8AC200EB71A9653CFAB01FDAB8EEA94AF2
   RealPriv: 0x552E025571C01BCDA0297C22731D74BECBD30D07E4EC355C741825FFFC0A672

Done: Total time 15s

[abadon666999]

hi dev..thanks for your support
I have 3 question
1)
5HrdZxkxnVst8Q11111keiLe1k4AmSDaAhqQVUYVxVSBkf5VfUu. When we decode it, we find the private key which is the beginning of our range: 0552e025571c01bcd9eda59365a2fb3ae0bd7547dfeeeb13d971d848bcbf0467
Can you say me what is procedure for DECODE PRIVATE KEY with 11111 ( 5HrdZxkxnVst8Q11111keiLe1k4AmSDaAhqQVUYVxVSBkf5VfUu )

2)this code
new BigInteger("0552e025571c01bcda0297c22731d74becbd30cfb218f04dc91299473f61ffde",16).add(new BigInteger("11316496",10)).toString(16) =
552e025571c01bcda0297c22731d74becbd30cfb218f04dc9129947400eacee
How should it be applied via Linux command?

3)for calculate STRIDE
We check where is the most right unknown character - it's position will tell us what is the stride. In our case it is 58^32 = af820335d9b3d9cf58b911d87035677fb7f528100000000
What is procedure or comand for calculate?

Thanks

[PawGo]

The code extracts are from my helper, written in java - so yes, you would be able to use it under linux.
For decoding WIF you may use BitcoinJ library or just a webpage: https://learnmeabitcoin.com/technical/wif

[NotATether]

Unfortunately the stride collides with checksum [...snip] we will have to use the full (long) value and pass checksum as a parameter.

Then why make the checksum bits part of the stride in the first place? It doesn't need to be guessable because this part can be derived after the private key is known, so passing the checksum bits makes no sense in this context because it lets the program look for invalid checksums as if it were part of the private key.

The easy way to port Kangaroo to look for WIF values is to convert it into a private key hex, and since the public key and therefore base58 public address can be computed from the private key hex, you can mod it to pass a start and end WIF which are then turned into private keys. However you'll still need to directly pass the public key of the address you want to crack because hashing the public key to an address is irreversible.

True you could scan the blockchain for the public key corresponding to an address but this only works if there's a transaction associated with it.

[PawGo]

Then why make the checksum bits part of the stride in the first place? It doesn't need to be guessable because this part can be derived after the private key is known, so passing the checksum bits makes no sense in this context because it lets the program look for invalid checksums as if it were part of the private key.

Because checksum has impact on addition result.
Example (in dec):
Imagine you have stride 530. And you have checksum 70.
If I do like you said, so I will remove 2 last digits of stride, I will have private keys:
5, 10, 15, 20, 25.
But if I do the correct addition and then remove 2 last digits, I will have:
600->6, 1130->11, 1650->16, 2180->21, 2710->27.
And the problem is that some group of checksums will create the same private keys and some checksums completely different.

[abadon666999]

hi ..i have create 1 file
new BigInteger("0552e025571c01bcda0297c22731d74becbd30cfb218f04dc91299473f61ffde",16).add(new BigInteger("11316496",10)).toString(16) =
that i have call  sun.java
when i run file java
java sun.java  


i have error
sun.java:1: error: class, interface, or enum expected                                                                  new BigInteger("0552e025571c01bcda0297c22731d74becbd30cfb218f04dc91299473f61ffde",16).add(new BigInteger("11316496",10)).toString(16) =                                                                                                         ^                                                                                                                       1 error                                                                                                                 error: compilation failed

can you help me please?
can you create 1 clear guide...for calculate 1)the end of range for Kangaroo and 2)STRIDE...please                                

[NotATether]

hi ..i have create 1 file
new BigInteger("0552e025571c01bcda0297c22731d74becbd30cfb218f04dc91299473f61ffde",16).add(new BigInteger("11316496",10)).toString(16) =

This isn't valid Java, you are assigning the result of BigInt().toString(), a String class, the value of... nothing (there's nothing after the equals sign!).

And you can't assign anything to this value anyway because it is not an lvalue, something declared like String s = /* ... */ ;

[abadon666999]

thanks for your reply
can you post please the correct file java for calculate the end of range for Kangaroo?

can you post file java for calculate STRIDE?

[PawGo]

Just a lazy solution:

Code:

import java.math.BigInteger;

public class K {
    public static void main(String[] args) {
        BigInteger start = new BigInteger("0552e025571c01bcd9eda59365a2fb3ae0bd7547dfeeeb13d971d848bcbf0467", 16);
        BigInteger stride = BigInteger.valueOf(58L).pow(32);//depends on the position of most-right unknown character
        BigInteger range = BigInteger.valueOf(58L).pow(5);//5=number of unknown characters
        BigInteger end = start.add(range);
        System.out.println("START: "+start.toString(16));
        System.out.println("END: "+end.toString(16));
        System.out.println("STRIDE: "+stride.toString(16));
    }
}

Going back to this version of Kangaroo: I think there is still something wrong with calculations with checksum - for longer ranges (>6 unknown characters) it does not return result, while when there is case without checksum (just a stride) it works good.

[abadon666999]

hi thanks dev for this file...work good
START: 552e025571c01bcd9eda59365a2fb3ae0bd7547dfeeeb13d971d848bcbf0467                                                
END:    552e025571c01bcd9eda59365a2fb3ae0bd7547dfeeeb13d971d848e3de3a07                                                    
STRIDE: af820335d9b3d9cf58b911d87035677fb7f528100000000    
just 1 last thing

i d'like test  with 14=number of unknown characters


import java.math.BigInteger;

public class K {
    public static void main(String[] args) {
        BigInteger start = new BigInteger("0552e025571c01bcd9eda5935d619d2f6e92860be1a512c4a71dbee04cacbc67", 16);
        BigInteger stride = BigInteger.valueOf(58L).pow(32);//depends on the position of most-right unknown character
        BigInteger range = BigInteger.valueOf(58L).pow(14);//14=number of unknown characters
        BigInteger end = start.add(range);
        System.out.println("START: "+start.toString(16));
        System.out.println("END: "+end.toString(16));
        System.out.println("STRIDE: "+stride.toString(16));
    }
}

is this correct or i must to do other modifications?

for example
5HrdZxkxnVst8Q11111111111111mSDaAhqQVUYVxVSBkf5VfUu   14=number of unknown characters
0552e025571c01bcd9eda5935d619d2f6e92860be1a512c4a71dbee04cacbc67


results=

START:  552e025571c01bcd9eda5935d619d2f6e92860be1a512c4a71dbee04cacbc67                                                 
END:     552e025571c01bcd9eda5935d619d2f6e92860be1a91b21742359640a3afc67                                                   
STRIDE: af820335d9b3d9cf58b911d87035677fb7f528100000000

[NotATether]

Just a lazy solution:

Code:

import java.math.BigInteger;

public class K {
    public static void main(String[] args) {
        BigInteger start = new BigInteger("0552e025571c01bcd9eda59365a2fb3ae0bd7547dfeeeb13d971d848bcbf0467", 16);
        BigInteger stride = BigInteger.valueOf(58L).pow(32);//depends on the position of most-right unknown character
        BigInteger range = BigInteger.valueOf(58L).pow(5);//5=number of unknown characters
        BigInteger end = start.add(range);
        System.out.println("START: "+start.toString(16));
        System.out.println("END: "+end.toString(16));
        System.out.println("STRIDE: "+stride.toString(16));
    }
}

This can be extended to handle a "partial" number of characters known, which is the case where some of the bits are set, by changing 5 to be a decimal number. For example by setting it to 4.5 we can do the equivalent of searching for 4 characters plus the the first 29 base58 values 1-V of the fifth. Or the first character having the last 29 base58 values W-z and 4 whole characters after that (or anything between those two).

This will make Kangaroo perform better in the cases where you know one of the characters is in a range but searching all 58 characters is too prohibitive, like when you're already searching a lot of characters.

Although doing a fractional exponentiation on a BigInteger is going to be a problem. Ideally you do not want to change this to BigDecimal for performance reasons, and you can't split the decimal into a fraction and do 58^num / 58^denom = 58^num * 58^-denom because BigInteger.pow() raises an exception with a negative exponent. Worst case scenario is that you use the divide(58^denom) method but I have no idea how slow dividing BigInts together is going to be. (Maybe try 58^num * (58^denom).modInverse(m) but set the modulus m to something bigger than 58^denom so we don't do the "mod" part of modInverse. But this only brings benefit if modInverse() is faster than the divide() method.

This can easily be ported to other languages provided that their bigint libraries are sane and let you take negative exponents (unlike Java). In particular it's a very useful feature to port to the original Kangaroo itself if Jean_Luc is still around on Github.

[PawGo]

Oh, it was just a simple calculator, I would not focus now on it - you may always calculate it manually, it was just a easy piece of code for him.

Anyway, I have started to have doubts if the case witch checksum is doable at all. I must verify carefully because I have a huge increase of used memory (without any result) and I think that the problem is in the fact that checksum may cause the private keys are not 'linear'. I do not have this problem when I do not use checksum, so it must be this...
In other words:
For virtualprivate key X we recalculate using stride&checksum and receive public key related to realkey X1.
For virtualprivate key Y we recalculate using stride&checksum and receive public key related to realkey Y1.

If checksum does not have impact, we may get point from X (it will be in fact point from X1), do (Y-X) operations and we should receive point related to Y (in fact Y*stride). But because checksum may have impact on which point we return as a point corresponding to Y, it becomes to be untrue. If checksum have impact, we may have for example situation where point for Y would be point from real private key Y1=Y*stride+1. And we expected to have point from Y*stride.

[abadon666999]

PawGo i have SENT YOU  1 message in bitcointalkforum...please check and contact me on telegram...thanks for your SUPPORT

[NotATether]

Anyway, I have started to have doubts if the case witch checksum is doable at all. I must verify carefully because I have a huge increase of used memory (without any result) and I think that the problem is in the fact that checksum may cause the private keys are not 'linear'. I do not have this problem when I do not use checksum, so it must be this...

I dunno, I still feel like you can find a stock WIF to hex converter and put that in Kangaroo without more memory usage, in which case you won't have to worry about the checksum at all and it's like 10x easier than fixing this.

Maybe instead of a stride parameter you can make users pass a hexadecimal bit mask to let them choose which bits Kangaroo's going to fill using hops from the search range. But IMHO I think that chopping up the range like this may even cause Pollard's Kangaroo algorithm to give wrong results, because the algorithm is trying to collide wild Kangaroos with the tame one, but has no idea that the resulting value of the kangaroo is going to be split up and sent to different parts of some other numbers.

I think this logic might also apply to your stride parameter too since it's equivalent to a bit mask with the lower few bits set to zero, from what I can understand (correct me if I'm wrong).

[dextronomous]

Just a lazy solution:

Code:

import java.math.BigInteger;

public class K {
    public static void main(String[] args) {
        BigInteger start = new BigInteger("0552e025571c01bcd9eda59365a2fb3ae0bd7547dfeeeb13d971d848bcbf0467", 16);
        BigInteger stride = BigInteger.valueOf(58L).pow(32);//depends on the position of most-right unknown character
        BigInteger range = BigInteger.valueOf(58L).pow(5);//5=number of unknown characters
        BigInteger end = start.add(range);
        System.out.println("START: "+start.toString(16));
        System.out.println("END: "+end.toString(16));
        System.out.println("STRIDE: "+stride.toString(16));
    }
}

Going back to this version of Kangaroo: I think there is still something wrong with calculations with checksum - for longer ranges (>6 unknown characters) it does not return result, while when there is case without checksum (just a stride) it works good.

how do i run this java.
i have a question, does this work with missing chars at the end of the wif, really want to know, stuck on reading here past 2 days.
 

[WanderingPhilospher]

Just a lazy solution:

Code:

import java.math.BigInteger;

public class K {
    public static void main(String[] args) {
        BigInteger start = new BigInteger("0552e025571c01bcd9eda59365a2fb3ae0bd7547dfeeeb13d971d848bcbf0467", 16);
        BigInteger stride = BigInteger.valueOf(58L).pow(32);//depends on the position of most-right unknown character
        BigInteger range = BigInteger.valueOf(58L).pow(5);//5=number of unknown characters
        BigInteger end = start.add(range);
        System.out.println("START: "+start.toString(16));
        System.out.println("END: "+end.toString(16));
        System.out.println("STRIDE: "+stride.toString(16));
    }
}

Going back to this version of Kangaroo: I think there is still something wrong with calculations with checksum - for longer ranges (>6 unknown characters) it does not return result, while when there is case without checksum (just a stride) it works good.

how do i run this java.
i have a question, does this work with missing chars at the end of the wif, really want to know, stuck on reading here past 2 days.
 

He has a java one that will work pretty well and fast for 7-8 characters missing off the end. For the method in this topic, it won't do any good because your stride will be "1"...meaning check every key, in order.

Here is a python script I threw together real quick if you are more familiar with it:

Code:

#First, enter the start range as start = "starting range like example below"
start       =  "552e025571c01bcda0297c22731d74becbd2cc13a750046ca49b5e9006a2c72" # <<<<------ enter starting range in hex
startrange  =  int(start, 16) #leave alone

#This determines the range that determines the start and end range; depends on the number of unknown characters; enter that number in ukchar = int(x)
ukchar      =  int(5) # <<<<------ enter the number of unknown characters
addtostart  =  int(pow(58, ukchar)) 
endrange    =  hex(startrange + addtostart).rstrip("L").lstrip("0x")

#This determines the stride which is based on the position of the most right unknown character; enter that number in mostright = int(x)
mostright   =  int(32)  # <<<<------ enter the position of the most right unknown character
stride      =  int(pow(58, mostright)) 

#This prints out starting range, ending range, and stride; leave alone
print ("Starting range: " + hex(startrange).rstrip("L").lstrip("0x"))
print ("Ending range  : " + endrange)
print ("Stride        : " + hex(stride).rstrip("L").lstrip("0x"))