Large Bitcoin Collider Thread 2.0

[securus]

Is this project still alive and is the software still under development?

If not, can the source code be released?

[1715206150]

1715206150

[1715206150]

1715206150

[1715206150]

1715206150

[digaran]

OP is inactive, this topic is not active anymore, did they get to rico? Anyone know if he is still alive or not?

[happa]

OP is inactive, this topic is not active anymore, did they get to rico? Anyone know if he is still alive or not?

You can find Rico on Discord https://discord.gg/AyEfZrY

[digaran]

OP is inactive, this topic is not active anymore, did they get to rico? Anyone know if he is still alive or not?

You can find Rico on Discord https://discord.gg/AyEfZrY

Well, when you see him tell him we are still waiting for #120 private key, it's not cool to keep so many people waiting for so long, just dropping the key would be great!😉

[Z1pp4]

I might sound stupid, but can some1 explain me how this "0x236fb6d5ad1f43" is a private key if in normal life the priv key is 51 characters (or 52) long?

[digaran]

I might sound stupid, but can some1 explain me how this "0x236fb6d5ad1f43" is a private key if in normal life the priv key is 51 characters (or 52) long?

This is the WIF private key for key 0x1
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAnchuDf

If you decode it, you will see this
800000000000000000000000000000000000000000000000000000000000000001a85aa87e

If you remove the last 8 characters and the first 2 characters, you will be left with 63 zeros and a 1.
What you have posted is the hexadecimal format, what I posted is wallet import format, wallets convert the hex key to WIF, or WIF to hex depending on what you are doing. 😉

[joseperal]

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.

I did program it on C, trying to make if super efficient and fast.
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:

Code:

 from:
00000000000000000000000000000000000000000000000200000000000000000000000
to:
000000000000000000000000000000000000000000000003FFFFFFFFFFFFFFFFFFFFFFF

That is: 36893488147419103231 keys to check!

Thanks!

[WanderingPhilospher]

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.

I did program it on C, trying to make if super efficient and fast.
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:

Code:

 from:
00000000000000000000000000000000000000000000000200000000000000000000000
to:
000000000000000000000000000000000000000000000003FFFFFFFFFFFFFFFFFFFFFFF

That is: 36893488147419103231 keys to check!

Thanks!

I'm pretty sure this program is dead.

Every 5th key has its public key exposed so one can find the keys within minutes using kangaroo or BSGS.

You may want to read up more on the puzzles to answer your questions, get a better understanding at what people are using these days to search for keys such as #66. A 4090 is getting at least 5,000 MKey/s with GPU programs.

[holy_ship]

1. it is stupid to search for 66 and other lower puzzles, because when you begin to spend them,  guys with kangaroo stuff will steal you key and likely overwrite your transaction.

2. The speed is ridiculous. keyhunt on ryzen7 is searching at speed of 4040394398072471407 keys per second (puzzle 130) no GPU

[citb0in]

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

I did program it on C, trying to make if super efficient and fast.
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: ...

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:

colisionador_x86_64.exe -list puzzle_r160list_sorted.csv -puzzle 0 -threads 1 -start_pk_bin 0000000000000000000000000000000000000000000000000000000000000001

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

Read and continue here:
https://bitcointalk.org/index.php?topic=1306983.msg63917514#msg63917514