Bitcoin puzzle transaction ~32 BTC prize to who solves it

[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

[kTimesG]

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.

There's no hashing for kangaroo, just plain point addition as fast as possible. Which translates to 256-bit arithmetic mambo-jambo.

JLP's kangaroo for example is definitely not fully optimized when it comes to this. But SHA and RIPEMD hashing were heavily studied and lots of hand-written optimized code exists, so the optimization upper bound is likely reached since long ago and nothing better (faster) is likely, just linear speed-up with better hardware. And even if it is, why the hell would one search for a key that, once public, is broken in a matter of seconds anyway? This is a logic fracture...

This is not the case with secp256k1 P + Q, since the longer the private key, the time to break it increases exponentially, but the computations are the same for any length. So it makes sense for scammers to try to convince naive people to contribute the results of some 256-bit mambo-jambo gymnastics (e.g. the bill they pay for running a GPU at full load) for their own benefit (e.g. build a msssively contributed kangaroo jump points database and simply scan for wild-tame collisions). A true non-scam collaborative effort would require that the finder of the key cannot know what the key is, and the owner of the pool cannot know what the key is, but that anyone can verify that the key is correct. So at spend time, a correct prize is distributed. So something like a ZKP protocol for miners.

I think the puzzles are the least problems of agencies, they definitely have access to special-purpose hardware that is beyond our imagination. If FPGAs to break RSA were already built in the 1970s, imagine how things look for them in 2024. We have chips with hundreds of billions of logic gates in our smartphones and call that high-end. How much processing power would, let's say, some processing "chip" that has the size of a basement?

[nomachine]

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.

There's no hashing for kangaroo, just plain point addition as fast as possible. Which translates to 256-bit arithmetic mambo-jambo.

Believe it or not, I used Pollard's Rho algorithm to crack a Windows XP CD for the first time.

Running it on a P3-450  , it took about 19 hours.

The parameters were completely different, but the principle was the same.

[escobol]

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.

There's no hashing for kangaroo, just plain point addition as fast as possible. Which translates to 256-bit arithmetic mambo-jambo.

Believe it or not, I used Pollard's Rho algorithm to crack a Windows XP CD for the first time.

Running it on a P3-450  , it took about 19 hours.

The parameters were completely different, but the principle was the same.

Amazing, and now you are doing setup to steal someones prize with RBF fee bump... ?

[nomachine]

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.

There's no hashing for kangaroo, just plain point addition as fast as possible. Which translates to 256-bit arithmetic mambo-jambo.

Believe it or not, I used Pollard's Rho algorithm to crack a Windows XP CD for the first time.

Running it on a P3-450   , it took about 19 hours.

The parameters were completely different, but the principle was the same.

Amazing, and now you are doing setup to steal someones prize with RBF fee bump... ?

Steal a prize with RBF fee bump? Nah, I’m just making sure transaction gets there faster than a kid on Halloween running to the house giving out full-sized candy bars! 🤡

[CY4NiDE]

JLP's kangaroo for example is definitely not fully optimized when it comes to this.

Check out Etarkangaroo if you haven't, it seems to have some improvements, albeit small.

Max range width up to 192 bits and (on my setup at least) it's 1Gk/s faster than JLP's.

I have no idea if it's fully optimized but I'm guessing it could be a better starting point for further improvements, although one potential downside is that it requires PureBasic to compile, which has to be bought.

[kTimesG]

Amazing, and now you are doing setup to steal someones prize with RBF fee bump... ?

To steal something implies that there was a legitimate owner of that something. Be it a physical thing or intellectual property.

Now, if someone is stupid enough to think that they own information which is computable in a way that holds no patents or rights, then they very much deserve a lesson in what "property" means from a legal (social-enforced) perspective.

Now, do you understand what "public" means in the compound term of "public key"?

It means that some bits of information is known to everyone, and it is information that does not have any owner or rights attached to it.

Now, back to basics. Let us say you create a "private key" and you declare yourself as its owner. What rights do you have over it? ZERO.

Did someone buy the rights to use the bits 0 and 1 to represent information and we didn't get the memo?

There is no such thing as an owner of a private key. There is only the art of trying to protect a freaking mathematical number to remain undisclosed.

Now - did someone buy the rights to use numbers? Did someone bought an actual number, and has the legal right to be the single entity in the society that has the rights to ever use it? We didn't get the memo on that as well.

No one ever fought a class suit process because somebody else used some number they wrote on some piece of paper.

EVERYONE owns ALL the numbers that can ever exist. You cannot "steal" a number from someone.

But it is true that stupidity costs a lot. We have a saying in my country: the one who's stupid is not the one who ASKS, but the one who GIVES.

So, if you give out your number, and you worked a LOT to get at it, guess what? You never owned it.