Solving ECDLP with Kangaroos: Part 1 + 2 + RCKangaroo

[Ykra]

Thank you for the suggestion, but I described my own approach to solving it. I know it will probably take longer.

If I’m not mistaken, in your example you solved a private key with missing characters in raw HEX format, while mine is in WIF format, and the process is a bit different there. I’m also not sure that the same method can be applied in my case.

That small puzzle was actually very useful for me because it showed that this particular method probably won’t work for my situation.

So I will continue with my slower and more methodical approach: I will substitute the first 3 unknown characters one by one, and for the remaining unknown section I will simply define a range and check it.

I adjusted my solver to work with broken WIF's - different to the method used for Puzzle6. Puzzle6 made me realise it's possible to solve (with some complexity shift) on WIFs with gaps.

That is why I suggested you create a new WIF key on https://iancoleman.io/bip39/ or wherever, post the WIF with the broken parts only (same structure as yours: [26 known characters] + [3 unknown characters] + [5 known characters] + [10 unknown characters] + [8 known characters]) and the pubkey and I'll return you the full WIF.

If you are not interested, no worries and good luck!

[farou9]

the speds varies depending on the language and the libraries , on python using ecdsa its very slow i think 80k/s but if we used coincurve it goes up (114,956 EC additions/sec) , but on c++ the speed is better never tested it but i can predict it coincurve uses libsecp so if we used the 4threads we can achive 500-700k/s , just tested it it can reach Speed: 548779 EC additions/sec using 4 threads in  c++

BTW, you talk about knowledge and intelligence, but use slow python and its libs instead of writing own optimized lib in c. So optimizing is not a part of intelligence in you opinion?
Performance always matters here, if I had only CPU I would create heavy-optimized lib for it to be able to perform more tests and researches.

i only use python because it is eay and fast to write and easy-fast to fix if an error shows up. also i only use it to test my ideas.
for real tests i use c of course (i cant say i do build optemized libs too lazy for that) but i use every available optimization in math i can think of.
"Performance always matters here" that is if you know you have a chance "and damn good one too"

[Bram24732]

Thank you for the suggestion, but I described my own approach to solving it. I know it will probably take longer.

If I’m not mistaken, in your example you solved a private key with missing characters in raw HEX format, while mine is in WIF format, and the process is a bit different there. I’m also not sure that the same method can be applied in my case.

That small puzzle was actually very useful for me because it showed that this particular method probably won’t work for my situation.

So I will continue with my slower and more methodical approach: I will substitute the first 3 unknown characters one by one, and for the remaining unknown section I will simply define a range and check it.

I adjusted my solver to work with broken WIF's - different to the method used for Puzzle6. Puzzle6 made me realise it's possible to solve (with some complexity shift) on WIFs with gaps.

That is why I suggested you create a new WIF key on https://iancoleman.io/bip39/ or wherever, post the WIF with the broken parts only (same structure as yours: [26 known characters] + [3 unknown characters] + [5 known characters] + [10 unknown characters] + [8 known characters]) and the pubkey and I'll return you the full WIF.

If you are not interested, no worries and good luck!

I think the guy’s method will work even if slower.
A slow method and not sharing keys is always better than a faster one requiring to send your keys to a stranger.
Congrats on the mini puzzle win ! I was sleeping when it was posted so couldn’t compete sadly !

[dextronomous]

Why should we wait? Let's have fun right now!   
https://bitcointalk.org/index.php?topic=5577390

as was doing my try to find the key,

the code i had showed this, nothing hardcoded for that address in the code btw but still there,

==================================================================
  VERIFY — Scale-Reduction Puzzle  (community example)
==================================================================

  k = Scale * pK  (mod n)    Scale = 4*2^192 + 3*2^128 + 2*2^64 + 1
  k in four 64-bit lanes:
    k[255:192]=4*pK  k[191:128]=3*pK  k[127:064]=2*pK  k[063:000]=1*pK

  Community member's approach:
    1. Compute Scale and its modular inverse on secp256k1 order
    2. Q' = inv(Scale)*PubKey  =>  Q' = pK*G  (standard 1D DLP)
    3. BSGS on Q' in ~[2^63, 2^64) range — solved in 2 min on a PC
    4. Reconstruct full key: k = Scale*pK mod n

  pK      = 0x3380374721080fff  (62 bits)
  k       = ce00dd1c84203ffc9a80a5d563182ffd67006e8e42101ffe3380374721080fff
  Address = 1PGRtg6XjiYSB1VJAhsqLQc6hQeBqFGVPD

  inv(Scale)*PubKey == pK*G : VERIFIED

  Lane check:
    4*pK = ce00dd1c84203ffc   3*pK = 9a80a5d563182ffd
    2*pK = 67006e8e42101ffe   1*pK = 3380374721080fff
  Combined = ce00dd1c84203ffc9a80a5d563182ffd67006e8e42101ffe3380374721080fff
  k (mod n)= ce00dd1c84203ffc9a80a5d563182ffd67006e8e42101ffe3380374721080fff  match

================================================================== saw later it was puzzle 5's address, weird or normal.