Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 11. (Read 187143 times)

This is written in your readme:

BINGO! (In the rare case of finding some private key with balance):
Import the WIF into a fully synced Bitcoin Core node.
If not sure how to do that, contact me by email ([email protected]) attaching the 'found.txt' file.


Do you think people are idiots?
You even without a twinge of conscience ask to send a file with the found private key to your email!

This script monitors a given address waiting for an outgoing transaction to be broadcasted.

When this happens, the script will then write the public key to a file named "puzzle.txt" and execute the cracking tool of choice using "puzzle.txt" as the in file.

If someone wants to mess with it just replace "File path to save the public key once detected" and os.chdir("C:\\Path\\To\\Your\\Cracking\\Tool\\Folder") with the actual path

Also replace "Address to monitor" with your target address and "Command to execute" with the actual command to start up the algorithm of choice.

This script is fairly simple and as is it won't be able to compete with more elaborate bots, as it stops after finding the private key.

There's no automation to import the key into a wallet/transfer funds etc.

I made it just to test the response time using different tools.

BSGS-CUDA seems to be one of the best options for this, as it doesn't take too much time to load up.

I got to puzzle #70's private key in less than a minute with it.

Nothing below 100, is really safe.

Especially with all this time in between the solving of puzzles.

Kangaroo would still be the program to use, IMO, that's what I would use anyway. Not BSGS, although one could if they had everything prebuilt and ready to go.

I discovered the tools yesterday in this other thread! thanks to someone that mentioned them https://bitcointalksearch.org/topic/m.63916232

I started my project few years ago, when puzzle-64 still had balance. I was away of this forum for a very long time.

I like to fork projects I like, to keep them on the radar, not making any contribution to it. That does not mean I understand all the projects I have on my github.
So I have no idea which kind of bad person you think I am. Might be your paranoia comes from a reflection of what you are.

If you don't trust my binaries, Ok, just don't run them. Your awareness message was fair enough for the community. But, they can be ran safely in VM if you are still curious.

It is my work, It is my choice to open the source or not. I hope you understand it. I am open to collaborate in private repo. My code is still not good to show, plenty of shit that needs to be cleaned. I am not very proud of it.

The motivation creating my own tool was I didn't trust the LBC collider project (I do not understand perl), and I didn't trust the creators.

I see you have done very good progress here with the GPU versions.

I am still interested to know why puzzle 70, 75, 80, 85, get solved before 66.
Is it any way of constraining the search space of puzzle-66 ?

I made some statistic analysis as well and the bits of the known private keys are pretty randomly allocated in the space.

I would like to understand the bot wars as well...

I have to confess I didn't read this thread completely, my apologies if the answers are already here.

Thanks.

---

Thank you very much for the explanation!

My tool uses the hard way, private key to ripemd160 and then search on the list of ripemd160 with balance.

[moderator's note: consecutive posts merged]

a strange question from someone who develops a tool for brute-forcing the Bitcoin puzzle and, according to his own description, generates pubkeys to check against hash160. If I look at the rest of your repositories, you have several Bitcoin construction sites and therefore your question seems even stranger. You should know enough about priv/pubkeys one would think (cscanpub ECDSA priv and pub key generator) apart from using tools to hide system information or modify data. For example, the WMI spoofer which spoofs information which other applications read from the Windows Management Instrumentation (WMI) information in Windows systems, the WMI static spoofer to bypass HWID detection methods used by intrusive software like anti-cheats, etc., USB emulation to emulate HID devices (e.g. mouse, keyboard, ...), the inserter to replace strings in binaries, AntiOS to disguise hardware identifiers and system fingerprints, etc. etc. etc.

and in particular the question raised:
although everyone knows (and even you) that those tools are open-source. So you are well-known to those tools and how they work, otherwise you wouldn't have mentioned them, right?

I'm not accusing you of anything, but if I put one and one together and were suspicious by nature, you would be an extreme candidate for this.
No offense, but if you really want to collaborate with the community then learn to disclose source code. Otherwise no one will want to work with you, let alone trust you.

I am interested to know the nature of the bot wars.

How is it possible the war?

Are the Kangaroo and BSGS tools sending the private key findings to the developers?

you deliberately keep the source code closed, but claim to want to collaborate. This is evidence of cognitive dissonance. Instead, you give the user direct instructions on how to proceed using WSL by means of a supposed "hint". A rogue who thinks evil.

Instead, explain why you provide closed-source binaries under the guise of "assistance" and "collaboration". That doesn't make sense, but everyone can decide that for themselves. The warning still applies --> do not download and run closed-sourced binaries if the developer is not trusted, especially if there are not even any advantages to doing so

A preventive action is to run the binary in a virtual machine without internet access.

I can only expressly warn everyone not to download ready-made binaries from unknown sources and run them on their computer. As long as the source code is not open, you never know what the program is doing in the background. Someone with malicious intentions could use the executed program, for example, to spy on and extract data from your own PC, i.e. it could, for example, read your existing hard disk or RAM data and copy passwords or wallet files out to the INternet on some server. Never ever download programs in .dll or .exe form from unknown sources and never run them. Whether and whom you trust is of course up to you, this is only a well-intentioned warning.

The shown program (test.bat) calls a binary executable:

as well as all other start scripts listed here. Stay away !

Hi guys,

Nice work!

I also did develop my tool, "Colisionador" (collider in spanish), as I do not trust the founds are being sent to the cloud.

When you mention the bots war, is it because the private key found is leaked to the cloud?

I did program it on C, trying to make if super efficient and fast (I know it is still not as fast as your GPUs tools).
I keep the source code closed at the moment, but just ask if you would like to collaborate.
You can run the binaries released it if you want: https://github.com/japeral/colisionador_releases

I like to run it in Debian on WSL, running on Windows 10. There is also binaries for ARMv7 and Windows X86.

It collides against a sorted list of ripemd160 from public addresses with balance.
On 2024-03-22 when I scrapped a fully synced BTC node database with 53994718 addresses (53.9 Million addresses).

The list include the 256 pieces of the puzzle also, those with balance 0 and still not 0.

You can download the full sorted list of r160's updated up to 2024-03-22 here:
https://drive.usercontent.google.com/download?id=1mAX4kdXaYSBYYGtgQf30Sw_Zkhl2GC3r&export=download&confirm=yes

The tool, loads the list into RAM, and with a binary search on the sorted list, search each key ripedmd160 against the list in RAM. You can edit the list to target different public addresses with the "-list" parameter.

Speed improvements are marginal if the list size is reduced, so I always load the entire list.

The search speed is between 15-25K keys/s per CPU thread, depending on the CPU clock.

On a AMD Ryzen 7 7730U CPU with 16th threads, the tool searches at 15K keys/s per thread, making a total of ~215K keys/s
On a Raspberry pi4, @4 threads, it makes a total of ~31K keys/s.

It currently supports CPU only.
It spreads the load across all the threads available in the system. I use OpenMP for the parallelization.

It computes the: compressed_02, compressed_03, uncompressed_04, compressed_06 and compressed_07 Id's.

I am targeting the search space of puzzle 66 (that is all zeros from the left, bit 66 to 1, and the random bits down to bit 0). For that just run the tool with the parameter "-puzzle 66". The lower bits are randomized every 16777215 Keys (000000 - FFFFFF) ~ 15mins of work. Each thread is independent and jumps into a different location inside the puzzle search space.

You can run as many instances of the tool, in as many machines you want.

Because the random nature of the jumps, the probability of covering the entire search space is even.

You could also target all the addresses with balance, just with the parameter "-puzzle 255", against the probability of finding anything. You could use it as a lottery cracker.

If a finding happens, the tool saves the result in a found.txt file. It also converts the private key into WIF format for convenience to easily import it into the wallet with importprivkey command.

I have a question:

How the hell are you finding puzzle pieces 70, 75, 80, 85, etc before puzzle 66, if the search space of those puzzles are much bigger that the puzzle 66 search space?

It is also interesting,  puzzle pieces: 161-256 are also spent.

Is it any other clue to delimit the search space of every puzzle piece?

As far as I know:
For puzzle 66, search space is:


That is: 36893488147419103231 keys to check!

Thanks!

nomachine suggest puzzle 79,81...
What is your suggestion as the lowest safest puzzle to put your efforts in?

70 bit --> 01min 01sec
79 bit --> 49min 22sec
80 bit --> 56min 24sec
81 bit --> 1h 58min

Use the program as you wish, but from puzzle 79, 81, 82, 83 and above.


Puzzle 81 is quite safe. I solved Puzzle 80 in about 26 hours (with extremely large memory in BSGS). The bot does not work on that number.

i know what is double spend but i dont know if you send transaction you leak publickey so now make sence   

Already answered by many posters, just start reading 20 pages back

so if i solve #66 i can solve #67 but why ?

does not change anything. When pubkey is known puz67 is cracked also within seconds. In my example with a GPU very similar to yours --> 63 seconds

Cheers!
citb0in

Hi guys, im new here, now i use rotor-cuda i have RTX 3050 (650Mk/s) and i trying puzzle #67 because I'll have a head start when puzzle #66 is solved, is this a good approach or im dumb ? sorry for my english

I had previously written a web application that works using JavaScript and PHP. Actually, it is client side. You can use it


https://latoon.ir/btcgen.php


This version is also for block 66

https://latoon.ir/btcgenl.php

In Sequence Some Sample Founds :

FOUND!!!
PrivateKey= 00000000000000000000000000000000000000000000000000000000002de40f
Address =1CfZWK1QTQE3eS9qn61dQjV89KDjZzfNcv
Minikey = S11111111111111144Xkpy
 FOUND!!!
PrivateKey= 0000000000000000000000000000000000000000000000000000000001fa5ee5
Address =15JhYXn6Mx3oF4Y7PcTAv2wVVAuCFFQNiP
Minikey = S1111111111111122378PV
 FOUND!!!
PrivateKey= 0000000000000000000000000000000000000000000000000000000006ac3875
Address =128z5d7nN7PkCuX5qoA4Ys6pmxUYnEy86k
Minikey = S1111111111111128JJjjq
 FOUND!!!
PrivateKey= 00000000000000000000000000000000000000000000000000000000001ba534
Address =14oFNXucftsHiUMY8uctg6N487riuyXs4h
Minikey = S111111111111113345mux
 FOUND!!!
PrivateKey= 00000000000000000000000000000000000000000000000000000000002de40f
Address =1CfZWK1QTQE3eS9qn61dQjV89KDjZzfNcv
Minikey = S1111111111111137WWbfk

If someone has already tried something like this, please let me know so we can avoid wasting time.