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?

[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

[nomachine]

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.

I especially don't see a reason for it to be closed source because supposedly everything was done in OpenSSL - even a toddler could do it. Because this is the level of these scripts. For beginners.

Here's an example of simple OpenSSL one file code that is incredibly fast:

puzzle.cpp

Code:

#include <iostream>
#include <vector>
#include <iomanip>
#include <openssl/bn.h>
#include <openssl/ec.h>
#include <openssl/obj_mac.h>
#include <openssl/evp.h>
#include <openssl/rand.h>
#include <openssl/sha.h>
#include <openssl/ripemd.h>
#include <ctime>
#include <sstream>
#include <fstream>
#include <thread>
#include <mutex>

// Convert bytes to hex string
std::string bytesToHex(const std::vector<unsigned char>& bytes) {
    std::stringstream ss;
    for (unsigned char byte : bytes) {
        ss << std::hex << std::setw(2) << std::setfill('0') << static_cast<int>(byte);
    }
    return ss.str();
}

// Generate keys and check for match
void generateKeys(BIGNUM* minKeyBN, BIGNUM* range, const std::vector<unsigned char>& target_hash160_bytes, std::mutex& outputMutex) {
    BIGNUM* randomPrivateKey = BN_new();
    BN_CTX* ctx = BN_CTX_new();
    EC_KEY* ec_key = EC_KEY_new_by_curve_name(NID_secp256k1);
    const EC_GROUP* curve = EC_KEY_get0_group(ec_key);
    EC_POINT* public_key_point = EC_POINT_new(curve);

    std::vector<unsigned char> sha256_result(SHA256_DIGEST_LENGTH);
    std::vector<unsigned char> ripemd160_result(RIPEMD160_DIGEST_LENGTH);

    while (true) {
        // Generate a random number in the range [0, range)
        BN_rand_range(randomPrivateKey, range);

        // Add the minimum value to the generated random number
        BN_add(randomPrivateKey, randomPrivateKey, minKeyBN);

        // Convert private key to bytes
        int numBytes = BN_num_bytes(randomPrivateKey);
        std::vector<unsigned char> private_key_bytes(numBytes);
        BN_bn2bin(randomPrivateKey, private_key_bytes.data());

        // Calculate the public key
        EC_KEY_set_private_key(ec_key, randomPrivateKey);
        EC_POINT_mul(curve, public_key_point, randomPrivateKey, NULL, NULL, ctx);

        size_t public_key_length = EC_POINT_point2oct(curve, public_key_point, POINT_CONVERSION_COMPRESSED, NULL, 0, ctx);
        std::vector<unsigned char> public_key_bytes(public_key_length);
        EC_POINT_point2oct(curve, public_key_point, POINT_CONVERSION_COMPRESSED, public_key_bytes.data(), public_key_length, ctx);

        // Calculate the hashes
        SHA256(public_key_bytes.data(), public_key_bytes.size(), sha256_result.data());
        RIPEMD160(sha256_result.data(), sha256_result.size(), ripemd160_result.data());

        // Convert to hex string for comparison
        std::string calculated_hash160_hex = bytesToHex(ripemd160_result);

        {
            std::lock_guard<std::mutex> lock(outputMutex);
            std::cout << "\r\033[01;33m[+] Public Key Hash (Hash 160): " << calculated_hash160_hex << "\e[?25l";
            std::cout.flush();
        }

        if (ripemd160_result == target_hash160_bytes) {
            std::time_t currentTime;
            std::time(&currentTime);
            std::tm tmStruct = *std::localtime(&currentTime);
            std::stringstream timeStringStream;
            timeStringStream << std::put_time(&tmStruct, "%Y-%m-%d %H:%M:%S");
            std::string formattedTime = timeStringStream.str();

            {
                std::lock_guard<std::mutex> lock(outputMutex);
                std::cout << "\n\033[32m[+] PUZZLE SOLVED: " << formattedTime << "\033[0m" << std::endl;
                std::cout << "\r\033[32m[+] Target Public Key Hash (Hash160) found! Private Key: " << bytesToHex(private_key_bytes) << std::endl;
            }

            std::ofstream file("KEYFOUNDKEYFOUND.txt", std::ios::app);
            if (file.is_open()) {
                file << "\nPUZZLE SOLVED " << formattedTime;
                file << "\nPrivate Key (hex): " << bytesToHex(private_key_bytes);
                file << "\n-------------------------------------------------------------------------------------";
                file.close();
            }

            break;
        }
    }

    BN_free(randomPrivateKey);
    EC_POINT_free(public_key_point);
    EC_KEY_free(ec_key);
    BN_CTX_free(ctx);
}

int main() {
    if (OpenSSL_add_all_algorithms() != 1) {
        std::cerr << "OpenSSL initialization failed." << std::endl;
        return 1;
    }

    BIGNUM* minKeyBN = BN_new();
    BIGNUM* maxKeyBN = BN_new();
    BIGNUM* range = BN_new();

    // Configuration for the **Puzzle 20**
    BN_dec2bn(&minKeyBN, "524287");   // min range
    BN_dec2bn(&maxKeyBN, "1048575");  // max  range
    std::string target_hash160_hex = "b907c3a2a3b27789dfb509b730dd47703c272868";

    // Calculate the range (maxKey - minKey)
    BN_sub(range, maxKeyBN, minKeyBN);

    // Convert the target_hash160_hex string to bytes
    std::vector<unsigned char> target_hash160_bytes;
    for (size_t i = 0; i < target_hash160_hex.length(); i += 2) {
        std::string byteString = target_hash160_hex.substr(i, 2);
        unsigned char byte = static_cast<unsigned char>(std::stoul(byteString, nullptr, 16));
        target_hash160_bytes.push_back(byte);
    }

    unsigned int num_cores = std::thread::hardware_concurrency();
    const int numThreads = num_cores; // Adjust the number of threads as needed
    std::system("clear");
    time_t currentTime = std::time(nullptr);
    char* minKeyStr = BN_bn2dec(minKeyBN);
    char* maxKeyStr = BN_bn2dec(maxKeyBN);
    int minKeyBits = BN_num_bits(minKeyBN);
    int maxKeyBits = BN_num_bits(maxKeyBN);
    int numBits = std::max(minKeyBits, maxKeyBits);
    std::cout << "\r\033[01;33m[+] HASH160 Search by NoMachine" << "\n";
    std::cout << "\r\033[01;33m[+] " << SSLeay_version(SSLEAY_VERSION) << std::endl;
    std::cout << "\r\033[01;33m[+] " << std::ctime(&currentTime);  
    std::cout << "\r\033[01;33m[+] Puzzle: " << numBits << "\n";
    std::cout << "\r\033[01;33m[+] Lower range limit: " << minKeyStr << "\n";
    std::cout << "\r\033[01;33m[+] Upper range limit: " << maxKeyStr << "\n";
    std::cout << "\r\033[01;33m[+] Using " << num_cores << " CPU cores for parallel search\033[0m" << std::endl;
    OPENSSL_free(minKeyStr);
    OPENSSL_free(maxKeyStr);
    std::cout.flush();

    std::mutex outputMutex;
    std::vector<std::thread> threads;

    for (int i = 0; i < numThreads; i++) {
        threads.emplace_back(generateKeys, minKeyBN, range, target_hash160_bytes, std::ref(outputMutex));
    }

    for (std::thread& thread : threads) {
        thread.join();
    }

    // Cleanup
    BN_free(minKeyBN);
    BN_free(maxKeyBN);
    BN_free(range);

    return 0;
}

Compile:

Code:

g++ -o puzzle puzzle.cpp -lssl -lcrypto -m64 -mssse3 -Wno-write-strings -pthread -ftree-vectorize -flto -Wall -Wextra -funroll-loops -finline-functions -O3

Or with clang if you have AMD Ryzen :

Code:

/opt/AMD/aocc-compiler-4.2.0/bin/clang++ -o puzzle puzzle.cpp -lssl -lcrypto -m64 -march=znver2 -mtune=znver2 -mfpmath=sse -mssse3 -msse3 -msse4 -msse4.1 -msse4.2 -msse4a -Wno-write-strings -pthread -ftree-vectorize -flto -Wall -Wextra -funroll-loops -finline-functions -O3

You can list the available flags by running the following command:

Code:

gcc -Q -march=native --help=target | grep -E '^\s+-.*(sse|march)'

You can experiment with these flags for cryptographic workloads, achieving a boost of 15-20% depending on the architecture and specific flags.

and then execute with:
./puzzle

• HASH160 Search by NoMachine
• OpenSSL 1.1.1w  11 Sep 2023
• Sat Jun 15 05:54:19 2024
• Puzzle: 20
• Lower range limit: 524287
• Upper range limit: 1048575
• Using 12 CPU cores for parallel search
• Public Key Hash (Hash 160): b907c3a2a3b27789dfb509b730dd47703c272868
• PUZZLE SOLVED: 2024-06-15 05:54:22
• Target Public Key Hash (Hash160) found! Private Key: 0d2c55
• Public Key Hash (Hash 160): b907c3a2a3b27789dfb509b730dd47703c272868
• PUZZLE SOLVED: 2024-06-15 05:54:25
• Target Public Key Hash (Hash160) found! Private Key: 0d2c55
• Public Key Hash (Hash 160): b907c3a2a3b27789dfb509b730dd47703c272868

This method can effectively solve puzzles from Puzzle 1 to Puzzle 40 within a reasonable time frame. However, solving beyond that range is impractical using straightforward brute force techniques. This approach is useful for understanding how code is compiled and functions in the context of cryptography and learning.

For puzzles requiring more than 40 bits of complexity, more advanced algorithms like BSGS (Baby-Step Giant-Step) or the Kangaroo algorithm are necessary. Additionally, implementation in C++ or Rust is recommended over Python for these cases.

[nomachine]

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

When evaluating the performance of advanced algorithms such as BSGS (Baby-Step Giant-Step) or the Kangaroo algorithm against straightforward brute force techniques, it's crucial to recognize their fundamentally different operational principles.

Brute force is typically evaluated by the raw number of keys tested per second.

In contrast, advanced algorithms like BSGS and Kangaroo are assessed based on their effective search steps or jumps within the problem space, utilizing mathematical optimizations to minimize operations.

Therefore, direct comparisons based solely on keys tested per second are not appropriate because advanced algorithms employ vastly more efficient search strategies.

Even when comparing the speeds of BSGS vs Kangaroo, such comparisons cannot be straightforward due to variations in implementation details and constraints such as memory usage and characteristics of the search domain.