Bitcoin Forum
August 13, 2026, 01:32:54 AM *
News: Latest Bitcoin Core release: 31.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: 51-character WIF with 14/16 trailing characters missing — RCKangaroo interval co  (Read 13 times)
jeffjeff120808 (OP)
Newbie
*
Offline

Activity: 1
Merit: 0


View Profile
August 12, 2026, 09:32:29 AM
 #1

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:

Code:
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:

Code:
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:

Code:
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 far

I have RCKangaroo v3.0 running successfully on an RTX 3090.

For example, its built-in 78-bit benchmark runs at approximately:

Code:
~2.24 GKeys/s
Err: 0

I also tested a small known-answer 40-bit ECDLP case with two different Kangaroo implementations.

Test vector:

Code:
start  = 0x8000000000
range  = 40
pubkey = 03a2efa402fd5268400c77c20e574ba86409ededee7c4020e4b9f0edbee53de0d4
known private key = 0xe9ae4933d6

oritwoen/kangaroo recovered:

Code:
Private key found: 0xe9ae4933d6
Verification: SUCCESS

RCKangaroo v3.0 also recovered exactly:

Code:
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.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!