Hi everyone,
I am studying a WIF recovery problem and would appreciate some advice from people familiar with RCKangaroo and interval ECDLP.
This is specifically about a standard 51-character uncompressed WIF, where only a contiguous suffix at the END of the WIF is unknown.The full secp256k1 public key is known.
The two cases I am interested in are:
Case A:
51-character WIF
first 37 characters known
last 14 Base58 characters unknown
Case B:
51-character WIF
first 35 characters known
last 16 Base58 characters unknown
My first rough calculation was based simply on the Base58 search space:
log2(58) ~= 5.858 bits
14 characters:
14 * log2(58) ~= 82.0 bits
16 characters:
16 * log2(58) ~= 93.7 bits
However, I understand that this is only the raw Base58 suffix space.
A WIF also contains the version/payload and a 4-byte Base58Check checksum, so I do not want to assume that 82 or 94 bits is necessarily the actual private-key interval that should be supplied to Kangaroo.
My main question is:Given a fixed prefix of a 51-character WIF and N completely unknown trailing Base58 characters, what is the correct method to derive the exact private-key interval:
k_min
k_max
range = k_max - k_min + 1
that can then be used with RCKangaroo?
In other words, does a fixed WIF prefix + unknown contiguous suffix map cleanly to one continuous private-key interval after Base58Check/version constraints are handled?
I am especially interested in the 14-character and 16-character suffix cases.
What I have tested so farI have RCKangaroo v3.0 running successfully on an RTX 3090.
For example, its built-in 78-bit benchmark runs at approximately:
I also tested a small known-answer 40-bit ECDLP case with two different Kangaroo implementations.
Test vector:
start = 0x8000000000
range = 40
pubkey = 03a2efa402fd5268400c77c20e574ba86409ededee7c4020e4b9f0edbee53de0d4
known private key = 0xe9ae4933d6
oritwoen/kangaroo recovered:
Private key found: 0xe9ae4933d6
Verification: SUCCESS
RCKangaroo v3.0 also recovered exactly:
PRIVATE KEY: ...E9AE4933D6
So my next step is to generate synthetic 51-character WIF test vectors with exactly 14 and 16 trailing characters hidden, calculate their exact private-key intervals, and test those intervals with RCKangaroo.
I am not asking anyone to recover an unknown real wallet key at this stage.I first want to make sure that my WIF -> integer interval -> private-key interval conversion is mathematically correct.
If anyone here has already tested trailing-WIF recovery with RCKangaroo, especially 14-16 missing characters, I would appreciate any advice on:
- the exact interval derivation;
- how Base58Check should be handled;
- whether the resulting private-key candidates form one continuous interval;
- the best RCKangaroo parameters for testing this case;
- and whether there are any pitfalls specific to 51-character uncompressed WIFs.
If useful, I can post a completely synthetic known-answer WIF/public-key example so that everybody can reproduce the calculation.
Thanks.