Decoding Puzzle 130

I'm in this thread, but honestly it's kinda tough to follow along since I’m using a not-so-great translator. I’ve got a speed of around 19999-20000 mkey with an RTX 4090 on the 8th GPU. I grabbed the compressed K key from puzzle 130, filled in the missing 15 characters with ? signs, and ran a script that switched those ? marks to big base 58 symbols (1) and small symbols (z). The script spit out the key in hex format and mentioned a range of 2⁶⁴-⁶⁵, if I’m remembering right. After that, I set it up on a rented server with 8 GPUs running JLPKengoro. I made sure to update the tsuda and everything else, basically did all I could to get JLPKengoro working. I tested a key for Puzzle 130, but after running it for half an hour at 20,000 mkey, still no luck finding the key. There was this one time the program just froze after 6 minutes, and I never saw the key... Maybe I messed up somewhere? I’d really appreciate it if someone could grab the key for puzzle 130 and make a video showing the proper setup for JLPKengoro. I also need a guide on how to properly extract hex from a given key, like this example: KwDiBf89QgGbjEhKnhXJuH8DvUBxVmJ3???h9M3t, which are my missing symbols for puzzle 130. Here’s the Python script I used to find the hex of my key: import base58 import math def wif_to_hex_range(wif_pattern): min_wif = wif_pattern.replace('?', '1') max_wif = wif_pattern.replace('?', 'z') def decode_wif_raw(wif): data = base58.b58decode(wif) data = data[:-4] # Remove the last 4 bytes

There usually no need to full-quote my or others posts. Just quote the details you want to comment on. And pay attention not to break rule #32 of Unofficial list of (official) Bitcointalk.org rules, guidelines, FAQ. I don't know why you want to play with puzzle #130's private key, but that's your decision. Compressed WIF of puzzle #130 KwDiBf89QgGbjEhKnhXJuH8DvUBxVmJ3761ahfZuohBr53Zh9M3t Hex private key of puzzle #130 000000000000000000000000000000033E7665705359F04F28B88CF897C603C9 Public key (compressed) 03633CBE3EC02B9401C5EFFA144C5B4D22F87940259634858FC7E59B1C09937852 You can mostly ignore the last 5 Base58 characters at the end (it's basically the indicator byte for an uncompressed (51 bytes, starts with 5...) or compressed (52 bytes, starts with K... or L...) WIF and the 4-bytes double SHA-256 checksum). Instead of KwDiBf89QgGbjEhKnhXJuH8DvUBxVmJ3???????????????h9M3t you can work with KwDiBf89QgGbjEhKnhXJuH8DvUBxVmJ3????????????????????. Using KwDiBf89QgGbjEhKnhXJuH8DvUBxVmJ311111111111111111111 as Base58 start key range and KwDiBf89QgGbjEhKnhXJuH8DvUBxVmJ3zzzzzzzzzzzzzzzzzzzz as Base58 end key range. Base58 conversion gives me KwDiBf89QgGbjEhKnhXJuH8DvUBxVmJ311111111111111111111 --> 80000000000000000000000000000000033e7665705359ec8ef00d0fb13d25f255d161c00000 stripped to hex key --> 000000000000000000000000000000033e7665705359ec8ef00d0fb13d25f255 KwDiBf89QgGbjEhKnhXJuH8DvUBxVmJ3zzzzzzzzzzzzzzzzzzzz --> 80000000000000000000000000000000033e766570535a104d57c300a3c5c0a1a62462cfffff stripped to hex key --> 000000000000000000000000000000033e766570535a104d57c300a3c5c0a1a6 Green color highlights where the hex region bounds differ. I would try this as input file for JLP Kangaroo: My gear isn't powerful enough to run and solve this in a reasonable time.

I'm new bro, I don't understand how this site works yet... I just realized that you can reply to certain messages this way, thanks for the instructions. I'm new bro, I don't understand how this site works yet... I just realized that you can reply to certain messages this way, thanks for the instructions. ------------ Ah, so that's how it is, I needed to replace the last five characters of the check amount with ?? That leaves 20 unknowns.. I did everything wrong, did I insert it? In those places where I lost 15 characters, and my script automatically deleted only 4 characters of the check amount... Perhaps for this reason I took the wrong one Hex 130 puzzles... And my range was 2⁶²+- and when I took the hex you posted below, the range showed 2¹³⁰... Idon't know why you want to play with puzzle #130's private key, but that's your decision. Compressed WIF of puzzle #130 KwDiBf89QgGbjEhKnhXJuH8DvUBxVmJ3761ahfZuohBr53Zh9M3t Hex private key of puzzle #130 000000000000000000000000000000033E7665705359F04F28B88CF897C603C9 Public key (compressed) 03633CBE3EC02B9401C5EFFA144C5B4D22F87940259634858FC7E59B1C09937852 It turns out I was doing everything completely wrong. I need to remove the automatic cutting of the check amount from my script and simply replace the last 5 characters with ??, then get the hex key and replace It contains symbols that don't match 000 and fff. I also used your key with 17 unknowns, which took 6 minutes to find the hex key, I found it in 45 seconds on 6 4090 video cards. I was doing everything completely wrong, thank you bro, you help me a lot, I am very grateful to you!!! The main thing is that the symbols I have are placed correctly, otherwise everything will be in vain.. If possible, leave your Bitcoin address here. If I recover the key, I will definitely thank you. P.S: Bro, check out my screenshot please: https://ibb.co/KpjGpmZY Please tell me if I replaced my 15+5 (the last characters of the key) correctly 0 - 20, f - 20? I tried to do everything as you said above in your comment... I got a range of 2⁸⁰ - is it really that huge when using JLPkangaroo and 16-17 mkey sec?

I have a Bitcoin address which I fully control in my forum profile. You can see it when you click on my account name and I can post it here, too: I don't expect to get something, my help is voluntary and usually for free, but I don't mind if you want to express your gratitude by sending something what you deem fair. Wish you good progress!

Definitely, if I succeed... I don't expect to get something, my help is voluntary and usually for free, but I don't mind if you want to express your gratitude by sending something what you deem fair. I also want to ask you to please look at my screenshot (I attached the link) to see if I separated 0000 and ffff correctly.

That range is nothing compared to the hardware that you're using. 80-bit range with ECDLP solver tools like "kangaroo" shouldn't be compared to blindly bruteforcing 80-bit, so if the provided data is correct, it shouldn't take an hour to solve at that speed (about 16,000 MK/s with CPU and GPU combined). Take for example the stripped puzzle 130 private key in Cricktor's post that you've solved in just 45seconds with GPUs. Perhaps you're in a similar situation as OP that he's been decoding a partial WIF with a typo? And it's not limited to typo in the WIF, even one wrong Byte from public key to private key Hex will result with false negative results.

No, I didn't find the 130 headlock in 45 seconds, because it had a range of 1¹³⁰, I found this key in 45 seconds: This is your key that was missing 17 characters of the private key. Yes, it's true that I may have made a mistake somewhere, or taken the hex key incorrectly... But my range shows 2⁸⁰... I'll ask a friend to write a python script to get the hex key correctly.

2^80±1 range for 20 missing Base58 characters including the checksum is within its reasonable average range. And it's still within "easy-mode" for your hardware so if it's taking so long, there must be something wrong with the provided data. Or alternatively, you can test your current Base58 decoder script and see if an example WIF is decoded correctly. Just pick any of the previously given examples and use the script if you can get the same Hex private key result. So, you can assure that the tool is working as intended. You've already tested the next step - you successfully tested that the ECDLP tool that you're using (JLPKengoro?) can solve sample partial private keys.

Yes, I'll take your example key from puzzle 130 and try to convert it to a hex and then compare it with your result. Or alternatively, you can test your current Base58 decoder script and see if an example WIF is decoded correctly. Just pick any of the previously given examples and use the script if you can get the same Hex private key result. So, you can assure that the tool is working as intended. You've already tested the next step - you successfully tested that the ECDLP tool that you're using (JLPKengoro?) can solve sample partial private keys. [/quote] Yes, I am convinced that JLPKengoro It works very well, I'm glad that such applications exist. 👍 Thank you for your help bro.

Here, bro, I took this address and key and tried to convert it into hexadecimal format. Your example: This is what I got with my script: MIN WIF: KwcqwXrpWbsw2SpPcm6mfcabFhnmafmPGoP11111111111111111 MAX WIF: KwcqwXrpWbsw2SpPcm6mfcabFhnmafmPGoPzzzzzzzzzzzzzzzzz === HEX RANGE === MIN HEX: 0be69f479d2dfbb65acd0165963e1460912517953702ca45 e7119b153c0690a9 MAX HEX: 0be69f479d2dfbb65acd0165963e1460912517953702ca45 f313209dfebd5cf0 ~ 2^59.59 0be69f479d2dfbb65acd0165963e1460912517953702ca4500000000000000000 0be69f479d2dfbb65acd0165963e1460912517953702ca45fffffffffffffffff ---------------------------------------------------------------- I also took the key to puzzle 130 and did as you said, and this is what I got: == INPUT === MIN WIF: KwDiBf89QgGbjEhKnhXJuH8DvUBxVmJ311111111111111111111 MAX WIF: KwDiBf89QgGbjEhKnhXJuH8DvUBxVmJ3zzzzzzzzzzzzzzzzzzzz === HEX RANGE === MIN HEX: 000000000000000000000000000000033e766570535 9ec8ef00d0fb13d25f255 MAX HEX: 000000000000000000000000000000033e766570535 a104d57c300a3c5c0a1a6 ~ 2^77.16 000000000000000000000000000000033e76657053500000000000000000000 000000000000000000000000000000033e766570535ffffffffffffffffffff And this is your result: As far as I understand, I'm using the correct range? And placing 000 and fff? Photo, please look: https://ibb.co/N6SzgtgM

I can't really judge if you defined your start and end hex range correctly. Shouldn't be too hard. Both start and end hex range should have around 44 identical hex characters at the start and about 20 hex characters at the end where they differ. It should work when you set the the region that differs to 0000...0000 for the start region and to FFFF...FFFF in the end region. Every hex character represents 4 bits, so 20x4 equals 80 bits search reagion. Sounds reasonable. No, the length is incorrect. Look carefully! I will also repeat what I said to previous user who started this topic. Are you, citramonb, sure you use the correct public key for your real recovery case? You need to have spending transactions from the Bitcoin address of your private key that you try to recover! And you need to get the public key error-free from those spending transactions! Otherwise the Kangaroo search will not find anything. Put screenshots in [img]https://<your picture link>[/img], they will still look only like links but when higher ranked users quote your pictures they will be visible. (I've edited your picture links above like that and used talkimg.com as picture hoster, no forum image proxy hassles with TalkImg.com.) If you quote text from others, please put in [quote]Something someone else wrote before.[/quote] This will then look like this which makes it clear what you quote and what are your own words.

I don't know if I quoted your message correctly, but I decided to just show you a photo. I think you'll understand what I'm talking about. Please take a look: https://talkimg.com/images/2026/04/27/UyTRWC.jpeg

Looks good to me, based on the numbers and length of items. A compressed private key WIF is 52 chars long and starts either with K... or L... Your hex range has to be of length 64 (=44+20). Your MIN HEX and MAX HEX are OK. You could also first try the following a bit smaller search range than in your screenshot: MIN HEX: 12........................................7f70000000000000000000 MAX HEX: 12........................................7fcfffffffffffffffffff I hope you got your public key right. Good luck! By the way, be careful when you rent your GPUs. You're operating a private key recovery on someone else's rented computers. You don't know what the service monitors and what their admins can see. If you have a decent GPU at your own computer, try it first. You can make a much safer recovery environment at your own place than at remote computers with rented GPUs. Yes, I know, I'm potentially paranoid. Better safe, than sorry, especially when handling Bitcoin private key material! Post edit: Corrected a small typo and extended last sentence.

Bro, are you on Telegram? If so, can I contact you?

I have Telegram, very rarely use it, don't really like it because there are a lot of shady folks on Telegram, haha. I can't really say, because as I said, I very very rarely use it. Why do you want to go to Telegram? It's safer for both of us to keep things public here. You can send me a personal message instead if it's about your public key. I will keep it confidential as best as I can, just know that personal messages are not encrypted. Do you need help to determine or verify the public key? To send me a personal message, click the PM icon under my account name (I show it with your account name):

Heads up to @citramonb, I'll ask a mod to separate your posts from this thread. Because as far as OP is concerned, this thread is already solved. So, if they separated it, you can find your and our replies in a new separate topic in this board. Plus I didn't expect that it'll take more than a page to solve your similar case since it seem simple in your first few replies. Turns out, there may be something more in this. BTW, I checked your LLM-coded Base58 decoder script from another thread and that should work in your use-case.

It's probably not a bad idea to separate the two cases, although they are pretty similar. notkim was able to solve his recovery case which is nice. A solved problem is something to learn from with a bit more satisfaction than if it remained unsolved (not that you can't learn from unsolved problems). We will see how it turns out for the new case. I must say, I'm not happy with the topic's title "Solving Puzzle 130"! Puzzle #130 has been solved and the (new) OP has chosen puzzle #130's private key as an example for his toolchain. It doesn't matter which random private key you use as a proofing example. What matters is that you evaluate if all your steps lead you to a valid solution. Only when you have verified that you can flawlessly solve an example problem to a valid solution, you're good to go to tackle your real recovery with confidence.

Probably, the Mod who responded didn't have the time to completely read the post and the rest of the replies, thus made the topic title irrelevant. The new OP, citramonb can just easily edit it anyways by editing the first post.

I did some testing on my gaming computer which has a AMD Ryzen 5 5600X CPU, 64GiB RAM and a Nvidia RTX 3060 GPU 12GiB GDDR6. Software used was JLP Kangaroo v2.2 Test private key: 18 missing WIF symbols (trailing), WIF search range Solver output: 19 missing WIF symbols (trailing), WIF search range Solver output: 20 missing WIF symbols (trailing), WIF search range Solver output: Apparently I couldn't finish e.g. 25 missing trailing WIF symbols... Post edit: Changed the title

That's quite beefy. So you can potentially test OP's case if he can trust you with his partial private key. I wonder why he didn't follow-up even before splitting the thread. He might have realized something wasn't right or didn't mention an important detail since it should be fairly easy with his 16K MKey/sec rate.