Bitcoin puzzle transaction ~32 BTC prize to who solves it

[dede_tuga]

Hello everyone,

We are assembling a team to decode BTC Puzzle 130 https://privatekeys.pw/puzzles/bitcoin-puzzle-tx, which carries a reward of 13.000076 BTC! If you're interested and have a CUDA-compatible graphics card, this is the perfect opportunity for you.

What is BTC Puzzle?
BTC Puzzle involves cryptographic challenges focused on finding hidden Bitcoin private keys. Puzzle 130 is one of the most challenging, with a substantial reward awaiting the solver.

How to Participate:
We are using Kangaroo2 software for collaborative puzzle solving. Here are instructions to connect to our server:

Software Requirements:
Kangaroo2 works on Windows and Linux.
You can find the repository and more information on GitHub.

Connection Instructions:
Download and set up Kangaroo2 following the instructions on the GitHub repository.
https://github.com/momofukku/Kangaroo2/tree/master
Use the following command in the terminal to connect to our server:

Code:

./kangaroo -t 0 -gpu -c hddmining.ddns.net -sp 17403

Contribution:
Any contribution is welcome! Whether you have experience in cryptography, programming, or simply a passion for solving puzzles, join us. Your assistance could be pivotal in cracking this challenging puzzle and sharing the reward.

Contact:
For more information and updates, keep an eye on this post and reach out through our server.

Let's decipher BTC Puzzle 130 together and share the grand reward!

[kTimesG]

How to Participate:
We are using Kangaroo2 software for collaborative puzzle solving.
Let's decipher BTC Puzzle 130 together and share the grand reward!

Good joke, so your business model is to find idiots that mine DP for you. Using software that doesn't even support puzzle 130 anyway. With zero innovations, fixes, or changes to the code, probably because you have zero idea how to even read it. Just adding a "2" at the end. It's also, most likely, not even forked by you.

[NotATether]

How to Participate:
We are using Kangaroo2 software for collaborative puzzle solving.
Let's decipher BTC Puzzle 130 together and share the grand reward!

Good joke, so your business model is to find idiots that mine DP for you. Using software that doesn't even support puzzle 130 anyway. With zero innovations, fixes, or changes to the code, probably because you have zero idea how to even read it. Just adding a "2" at the end. It's also, most likely, not even forked by you.

Here's the thing - Until we can figure out how to properly mod JLP's Kangaroo to use an additional 128-bit word for its DPs, higher puzzles cannot be solved with it.

Multi-word operations are tricky, like walking in a minefield. I've already attempted and failed at this, but maybe someone else will figure it out.

[BitcoinADAB]

Here's the thing - Until we can figure out how to properly mod JLP's Kangaroo to use an additional 128-bit word for its DPs, higher puzzles cannot be solved with it.
Multi-word operations are tricky, like walking in a minefield. I've already attempted and failed at this, but maybe someone else will figure it out.

Jean Luc wrote it in his Github:

[albert0bsd]

you need to know the compressed publickey hex66 to run.
However I don't know how to get this. I tried publichash like
Public Key Hash: 20d45a6a762535700ce9e0b216e31994335db8a5


but I can't run because is not the the public key in the format the BSGS need.
Someone know how to do this?

There is no way to get the public key from the address or hash160, unless the address has some outputs or signed message

Anyway please for keyhunt question please use the next topic for it:
https://bitcointalk.org/index.php?topic=5322040.msg56503352#msg56503352

Regards

[kTimesG]

How to Participate:
We are using Kangaroo2 software for collaborative puzzle solving.
Let's decipher BTC Puzzle 130 together and share the grand reward!

Good joke, so your business model is to find idiots that mine DP for you. Using software that doesn't even support puzzle 130 anyway. With zero innovations, fixes, or changes to the code, probably because you have zero idea how to even read it. Just adding a "2" at the end. It's also, most likely, not even forked by you.

Here's the thing - Until we can figure out how to properly mod JLP's Kangaroo to use an additional 128-bit word for its DPs, higher puzzles cannot be solved with it.

Multi-word operations are tricky, like walking in a minefield. I've already attempted and failed at this, but maybe someone else will figure it out.

It's not really so difficult, I started creating a CUDA kernel from scratch. There are lots of things to improve on to the way JLP did it, beginning with the way points are stored and accessed in the memory by each thread, up to the inefficient instructions that are used (why is it using 64-bit? CUDA doesn't have such a thing - instant performance drop right there). The list of issues is too long. I'm not dismissing his work, it just seems very convoluted so it's understandably hard to follow. But still some script kiddie copy pastes such a project, runs make, and than brags about him asking for cryptography programmers to join his Kangaroo2 project, lol.

[nomachine]

I'm not dismissing his work, it just seems very convoluted so it's understandably hard to follow. But still some script kiddie copy pastes such a project, runs make, and than brags about him asking for cryptography programmers to join his Kangaroo2 project, lol.

When a project like Kangaroo is developed, it's crucial to recognize that the initial version is just a starting point.

When creating a CUDA kernel from scratch, one quickly realizes that there are numerous aspects to optimize.

No single person can foresee all potential improvements or solutions. When developers work together, knowledge exchange happens organically.

A project that relies on a single developer is fragile; it risks stagnation or abandonment if that individual becomes unavailable. By coming together and pooling our knowledge and resources, we can transform a good project into a great one, and a great project into a groundbreaking one.

This particular project, aimed at brute-force cryptography, raises significant ethical concerns.

The question here is, who has the balls to stand behind a project like this and build it into a groundbreaking one?

[madogss]

Does anyone still happen to have the public keys for all of the solved puzzles?   Like starting from puzzle number 1 upto number 65 for example?   Just was curious since usually only the private key is listed after a puzzle is solved.  But knowing what the public keys were helps greatly too.  Maybe you will reply here later if you have that list of values,  thanks

Going to https://privatekeys.pw/puzzles/bitcoin-puzzle-tx has all the pubkeys for the solved puzzles

[AliBah]

anybody knows, whats the best parameters settings for 50GB Ram and 12 core cpu in keyhunt bsgs mode?

[madogss]

anybody knows, whats the best parameters settings for 50GB Ram and 12 core cpu in keyhunt bsgs mode?

Your K value should be around 3072 but if your working on puzzles 130 and above I would recommend using Etarkangaroo or another modified kangaroo because they find privkeys much faster with bigger ranges compared to bsgs.
The best way I think you could use bsgs would be to search in-between kangaroo jumps.

[pbies]

Simple program for puzzle 66 below.

If you want to search from a specific private key number both ways up and down, just use it:

Code:

#!/usr/bin/env python3

from hdwallet import HDWallet
from hdwallet.symbols import BTC
from tqdm import tqdm
from tqdm.contrib.concurrent import process_map

hdwallet = HDWallet(symbol=BTC)

p=0x000000000000000000000000000000000000000000000001a838b13505b26867
middle=p*2
mid=1000000

def go(i):
b=hex(i)
b='0'*(66-len(b))+b[2:]
hdwallet.from_private_key(private_key=b)
a=hdwallet.p2pkh_address()
if a=='13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so':
print('private key: 0x'+b+'\a')
exit()

process_map(go, [x for i in range(mid) for x in {middle-i:0,middle+i:0}], max_workers=10, chunksize=10000)

import sys
print('\a',end='',file=sys.stderr)

Here I set p for previous puzzle pvk and double it.
Middle is the variable from where the search will start.

[nomachine]

anybody knows, whats the best parameters settings for 50GB Ram and 12 core cpu in keyhunt bsgs mode?

Your K value should be around 3072 but if your working on puzzles 130 and above I would recommend using Etarkangaroo or another modified kangaroo because they find privkeys much faster with bigger ranges compared to bsgs.
The best way I think you could use bsgs would be to search in-between kangaroo jumps.

Yes, I have about ~4 Ekeys/s on PC with 64GB RAM.

Code:

./keyhunt -m bsgs -f 65.txt -b 65 -e -t 12 -l compress -q -S -k 4096

But it's a blast to solve Puzzle 65, 66, 67, 68.  It takes about 60 seconds once we identify the public key from the blockchain.  

Here i tested my toddler bot script on Puzzle 65 = address -> 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe


root@puzzle ~/Test # time python3 toddler_puzzle_bot.py

• Version 0.2.230519 Satoshi Quest, developed by AlbertoBSD
• Endomorphism enabled
• Threads : 12
• Search compress only
• Quiet thread output
• K factor 4096
• Mode BSGS sequential
• Opening file 65.txt
• Added 1 points from file
• Bit Range 65
• -- from : 0x10000000000000000
• -- to   : 0x20000000000000000
• N = 0x100000000000
• Bloom filter for 17179869184 elements : 58890.60 MB
• Bloom filter for 536870912 elements : 1840.33 MB
• Bloom filter for 16777216 elements : 57.51 MB
• Allocating 256.00 MB for 16777216 bP Points
• Reading bloom filter from file keyhunt_bsgs_4_17179869184.blm .... Done!
• Reading bloom filter from file keyhunt_bsgs_6_536870912.blm .... Done!
• Reading bP Table from file keyhunt_bsgs_2_16777216.tbl .... Done!
• Reading bloom filter from file keyhunt_bsgs_7_16777216.blm .... Done!
• Thread Key found privkey 1a838b13505b26867   
• Publickey 0230210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b

All points were found
Private Key: 1a838b13505b26867
WIF Key: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZM21gaY8WN2CdwnTG57
Starting Electrum ....
starting daemon (PID 41802)
true
Keypair imported: 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe
Transaction IDs: []
Daemon stopped
Electrum daemon stopped successfully.

real   2m46.311s
user   1m55.133s
sys   0m59.598s


and the time required to import the key into Electrum and start the redirection of transactions (if they exist ).  

[CY4NiDE]

Yes, I have about ~4 Ekeys/s on PC with 64GB RAM.

Code:

./keyhunt -m bsgs -f 65.txt -b 65 -e -t 12 -l compress -q -S -k 4096

But it's a blast to solve Puzzle 65, 66, 67, 68.  It takes about 60 seconds once we identify the public key from the blockchain.  

Here i tested my toddler bot script on Puzzle 65 = address -> 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe


root@puzzle ~/Test # time python3 toddler_puzzle_bot.py

• Version 0.2.230519 Satoshi Quest, developed by AlbertoBSD
• Endomorphism enabled
• Threads : 12
• Search compress only
• Quiet thread output
• K factor 4096
• Mode BSGS sequential
• Opening file 65.txt
• Added 1 points from file
• Bit Range 65
• -- from : 0x10000000000000000
• -- to   : 0x20000000000000000
• N = 0x100000000000
• Bloom filter for 17179869184 elements : 58890.60 MB
• Bloom filter for 536870912 elements : 1840.33 MB
• Bloom filter for 16777216 elements : 57.51 MB
• Allocating 256.00 MB for 16777216 bP Points
• Reading bloom filter from file keyhunt_bsgs_4_17179869184.blm .... Done!
• Reading bloom filter from file keyhunt_bsgs_6_536870912.blm .... Done!
• Reading bP Table from file keyhunt_bsgs_2_16777216.tbl .... Done!
• Reading bloom filter from file keyhunt_bsgs_7_16777216.blm .... Done!
• Thread Key found privkey 1a838b13505b26867   
• Publickey 0230210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b

All points were found
Private Key: 1a838b13505b26867
WIF Key: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZM21gaY8WN2CdwnTG57
Starting Electrum ....
starting daemon (PID 41802)
true
Keypair imported: 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe
Transaction IDs: []
Daemon stopped
Electrum daemon stopped successfully.

real   2m46.311s
user   1m55.133s
sys   0m59.598s


and the time required to import the key into Electrum and start the redirection of transactions (if they exist ).  

I think for this purpose you could achieve even faster results by using BSGS-CUDA, if you can.

In my experience Keyhunt takes much longer to load in. With BSGS-CUDA; around 18 to 20 seconds to initialize.

Of course, it can vary from one setup to another. This is what I've observated with my rig.

Nice script, the people hating clearly have no idea what they are talking about. 

[nomachine]

How to Participate:
We are using Kangaroo2 software for collaborative puzzle solving.
Let's decipher BTC Puzzle 130 together and share the grand reward!

Good joke, so your business model is to find idiots that mine DP for you. Using software that doesn't even support puzzle 130 anyway. With zero innovations, fixes, or changes to the code, probably because you have zero idea how to even read it. Just adding a "2" at the end. It's also, most likely, not even forked by you.

I cannot physically measure the benefits of this collaborative puzzle-solving. Who cares if it's 100, 500, or 1500 Mk/s? It's the same slow hashing shit, even with all possible fixes. Without something groundbreaking, it's a dead end.

They will work on it for at least two years, and eventually, someone will collect all the prizes using a bot script. It is likely that only resellers of cloud and GPU hosting will benefit.

And if some genius discovers something groundbreaking, do you think they will publicly open-source it? I'm not sure about their safety after that..Which comes to the next point... being slow is what makes them (agencies with three letters) secure. They don't want it to be fast.

[GR Sasa]

If puzzle 64 was recently solved, how to actually check if the puzzle in the end was drained also by bots or its the solver himself who got the prize?

If it was the solver himself who got the prize, why didn't the bots / scripts had gone in and taken the prize?

[nomachine]

The 10 minutes is the average time and this is a pretty stupid circumstance. At this stage, the transaction has entered the mempool and remains 'Pending,' waiting for confirmation.

It only takes a matter of seconds to obtain the private key, after which you can replace the still-unconfirmed transaction in the mempool.

By using Replace-by-Fee (RBF), you can bump the transaction fee and forward the coins of #66 to any other address. RBF is a feature in Bitcoin that allows you to increase the transaction fee on an unconfirmed transaction, making it more attractive for miners to prioritize.

In summary, the logs for RBF transactions can be stored indefinitely or for a limited time, depending on the system's configuration and policies. If there are no logs - we can look into the glass ball what happened..

[Baskentliia]

Yes, I have about ~4 Ekeys/s on PC with 64GB RAM.

Code:

./keyhunt -m bsgs -f 65.txt -b 65 -e -t 12 -l compress -q -S -k 4096

But it's a blast to solve Puzzle 65, 66, 67, 68.  It takes about 60 seconds once we identify the public key from the blockchain.  

Here i tested my toddler bot script on Puzzle 65 = address -> 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe


root@puzzle ~/Test # time python3 toddler_puzzle_bot.py

• Version 0.2.230519 Satoshi Quest, developed by AlbertoBSD
• Endomorphism enabled
• Threads : 12
• Search compress only
• Quiet thread output
• K factor 4096
• Mode BSGS sequential
• Opening file 65.txt
• Added 1 points from file
• Bit Range 65
• -- from : 0x10000000000000000
• -- to   : 0x20000000000000000
• N = 0x100000000000
• Bloom filter for 17179869184 elements : 58890.60 MB
• Bloom filter for 536870912 elements : 1840.33 MB
• Bloom filter for 16777216 elements : 57.51 MB
• Allocating 256.00 MB for 16777216 bP Points
• Reading bloom filter from file keyhunt_bsgs_4_17179869184.blm .... Done!
• Reading bloom filter from file keyhunt_bsgs_6_536870912.blm .... Done!
• Reading bP Table from file keyhunt_bsgs_2_16777216.tbl .... Done!
• Reading bloom filter from file keyhunt_bsgs_7_16777216.blm .... Done!
• Thread Key found privkey 1a838b13505b26867   
• Publickey 0230210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b

All points were found
Private Key: 1a838b13505b26867
WIF Key: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZM21gaY8WN2CdwnTG57
Starting Electrum ....
starting daemon (PID 41802)
true
Keypair imported: 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe
Transaction IDs: []
Daemon stopped
Electrum daemon stopped successfully.

real   2m46.311s
user   1m55.133s
sys   0m59.598s


and the time required to import the key into Electrum and start the redirection of transactions (if they exist ).  

I think for this purpose you could achieve even faster results by using BSGS-CUDA, if you can.

In my experience Keyhunt takes much longer to load in. With BSGS-CUDA; around 18 to 20 seconds to initialize.

Of course, it can vary from one setup to another. This is what I've observated with my rig.

Nice script, the people hating clearly have no idea what they are talking about. 

Keyhunt does not take long to load, it takes a long time because you do not save the files.
If you add the -S command, your next run will take a very short time.

[Baskentliia]

If puzzle 64 was recently solved, how to actually check if the puzzle in the end was drained also by bots or its the solver himself who got the prize?

If it was the solver himself who got the prize, why didn't the bots / scripts had gone in and taken the prize?

Bitcoin wasn't very valuable back then. Also, no one bothers for 0.64 bitcoins and finally, the software, technology bots etc. at that time. It was not as developed as it is now.

There are currently 6.6 bitcoins, the reward is very high and the software bots are also quite advanced. Once Pubkey appears, there will be a lot of chaos.

[CY4NiDE]

Keyhunt does not take long to load, it takes a long time because you do not save the files.
If you add the -S command, your next run will take a very short time.

I did take that into account.

Even with the -S parameter it takes more than one minute to load in with my machine.

In my particular case almost 2 minutes to initialize Keyhunt, 20 seconds for BSGS-CUDA.

[nomachine]

Keyhunt does not take long to load, it takes a long time because you do not save the files.
If you add the -S command, your next run will take a very short time.

I did take that into account.

Even with the -S parameter it takes more than one minute to load in with my machine.

In my particular case almost 2 minutes to initialize Keyhunt, 20 seconds for BSGS-CUDA.

It depends on how big the .BLM file is. If it is too big, it can take a long time. I think 16GB is enough for #66