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

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.

Hello again  

Puzzle #64 was solved on 09/09/2022. It's prize was 0.64 BTC and that day BTC price was US$21.268, so the prize in BTC was like US$13.611

Any puzzle below #80 or #90, I think, can be snatching up by a bot.

---

That day I got like US$165 between BCH, BSV, XEC (eCash) and BTG. It was cool to get that here in a latinamerican country  

And, even today, fork coins weren't updated with 10x, so the prize is still the same for the fork coins (ie 0.66 BCH for puzzle #66 and so on)

During that time the puzzles had like 0.0064 bitcoin it and on top of that BTC was very low. Why would it create a world wide bot race and why would someone waste hundreds or thousands of dollars in fees to withdraw it?
It only became an issue once the creator increased the puzzle prize and since then, no lower end puzzle have been solved.

I suggest to take whatever time/scripts/motivation you have and try to solve puzzle #80 on wards instead where you will be guaranteed the prize.
Or, ask someone with knowledge about timings which is the lowest feasible puzzle to be solved that will leave enough time to withdraw without a bot snatchingup. I don't know this answer, could be even puzzle #70?  

If someone can answer that, that would be great.

Your best option would be some implementation of KeyHunt-CUDA / Rotor-CUDA. Or BitCrack if you want to mess with the stride option.

In terms of raw performance BitCrack lacks tho.

This made me laugh out loud.

Where did 10^74 come from?

You realize 10^74 is larger than 2^66, correct? Not by a little but a lot.

Thanks for the laugh though! I appreciate it.