Bitcoin puzzle transaction ~32 BTC prize to who solves it

[CryptoMaster84]

Any ideas?

How do you know if Point X prefix = 02?
you can do this:

Code:

if (isOdd == 0) { //  02
    _GetHash160Comp(px, isOdd, (uint8_t *)h);
    CHECK_POINT(h, incr, 0, true);
}

In addition, you will have to calculate the Y coordinate when adding points. Look at my mod 12. I removed everything unnecessary there in GPU.
And I changed the conditions in GPUEngine.cu - the ComputeKeys() code is executed. But ComputeKeysComp() is not executed - for the reason that the Y coordinate is needed.
It was measured that it is more profitable to add the Y coordinate than to calculate Ripemd160 2 times.
Everything has already been checked, you can only add a condition. Or loop using Spin. So I gained 6.3% in speed. #define NB_SPIN 32
You also need to change the increment index multiplied by the number of Spin rotations and  add Load256(sx, px); Load256(sy, py);
Post the code and I'll check it

Thank you for your input, but I think you miss the point where I asked about processing only the expected public keys from the start. Your proposed solution is equal to my second attempt on _GetHash160Comp function.

Let me give you a scenario so you would understand what I mean.

Let's assume the priv key 66 bit range:  3fa62700000000000:3fa627fffffffffff , so you will have to scan ~ 17592186044416 private keys, generate a public key for each key, right? Now let's assume for the sake of the argument that priv key is at 75% of the end of the keyspace and the public key which generates the hashing to obtain the btc adresss starts with "02b7" (the compressed key is: 02b79ba3ab8ca1fd1399e27ce5bf337819ba34320653c7528084a6b52118c17b86).

Now, let's assume that there's an equal parity after you compute all the public keys from the priv key range with pubkeys that start with 02 or 03 and based on that filter from the start 50% of the keys your are not storing anymore and store/load only what you want? Theoretically you will compute less key, therefore the speed should be double.

getGPUStartingKeys code:

Code:

        int prefix02Count = 0;  // Counter for keys starting with '02' //for debug only
        int prefix03Count = 0;  // Counter for keys starting with '03' //for debug only        

	for (int i = 0; i < nbThread; i++) {

		tRangeEnd2.Set(&tRangeStart2);
		tRangeEnd2.Add(&tRangeDiff);

		if (rKey <= 0)
			keys[i].Set(&tRangeStart2);
		else
			keys[i].Rand(&tRangeEnd2);

		tRangeStart2.Add(&tRangeDiff);

		Int k(keys + i);
		k.Add((uint64_t)(groupSize / 2));	// Starting key is at the middle of the group
		//p[i] = secp->ComputePublicKey(&k); //here we compute the public keys from the priv keys and store them in the p array
                
		Point pubKey = secp->ComputePublicKey(&k);  // Compute the public key

		// Extract compressed public key bytes
		unsigned char publicKeyBytes[33];
		secp->GetPubKeyBytes(true, pubKey, publicKeyBytes);

                // Check the prefix of the public key
                if (publicKeyBytes[0] == 0x02) {
                      prefix02Count++;
                      p[i] = pubKey; // here we store in the array only the keys we want
                      //std::string pubKeyAddr = secp->GetPublicKeyHex(true, p[i]);
                      //printf("Public key %d: %s\n", i, pubKeyAddr.c_str()); //for debuging
                } else if (publicKeyBytes[0] == 0x03) {
                      prefix03Count++;
                }

	}
        // Calculate percentages
        //double totalKeys = nbThread; //for debug only
        //double percentage02 = (prefix02Count / totalKeys) * 100.0; 
        //double percentage03 = (prefix03Count / totalKeys) * 100.0;

	//printf("Total number of keys generated: %d\n", nbThread);
        //printf("Percentage of keys starting with '02': %.2f%%\n", percentage02);
        //printf("Percentage of keys starting with '03': %.2f%%\n", percentage03);

FinKeyGPU code:

Code:

...
getGPUStartingKeys(tRangeStart, tRangeEnd, g->GetGroupSize(), nbThread, keys, p);
ok = g->SetKeys(p); //will set only the keys we stored in p
....

How do you know if PubKey prefix = 02?

I think it's a waste of time to guess whether it's 02 or 03 prefix. Whatever the script is, it must pass all the private keys. It is impossible to accelerate this way. It can be filtered, but filtering is not acceleration.

Sorry mate but you don't seem to understand what I asked, read again my post.

I started studying this program in 2020. Now I will try to explain to you what you are doing wrong.
1. In the getGPUStartingKeys function, it forms an array of points with X and Y coordinates. In this function, you do not need to check them for compliance with the prefixes 02 and 03. Because later in the GPU code, when adding any point to the coordinates generated in this function, the new points will be with the prefixes 03 (not even Y). You won't even know it. You need to filter specifically in the GPU code. For this reason, you won't be able to add new cmd argument.
2. There is no need to reduce nbThread > filtredKeys by 50%, the remaining threads are filled with zeros. The entire Points p array must be transferred to the GPU.
I suggested that you check in the GPU code for the parity of the Y coordinate. uint8_t isOdd = (uint8_t)(py[0] & 1); It's simple
It is not entirely clear what you want to increase further. This is the limit

I know that piece of code: uint8_t isOdd = (uint8_t)(py[0] & 1), depending on the parity of Y coordinate if 0 is then the parity will be even and if 1 then it will be odd and it will serve on this line when permutation is done: publicKeyBytes[0] = __byte_perm(x32[7], 0x2 + isOdd, 0x4321);

What I want to increase further, speed of computation even with 16 x RTX 4090, I get only 76.8Gk/s, is useless to scan at this speed the 66 puzzle.

[1714617099]

1714617099

[1714617099]

1714617099

[alek76]

...

Yes, I understood your idea. But there is 1 fact. When adding a point with even private keys and then adding them, the Y coordinate can be either even or odd. If you filter in getGPUStartingKeys(), I think that after 1 addition the result can be anything. Yes. Just check the rand key generator, how many even and odd values it generates
Try it. I used only 1 nbThread to check the GPU code; you can even print points from the GPU using the printf() function, preloading fixed repeating even or odd ones.

[CryptoMaster84]

...

Yes, I understood your idea. But there is 1 fact. When adding a point with even private keys and then adding them, the Y coordinate can be either even or odd. If you filter in getGPUStartingKeys(), I think that after 1 addition the result can be anything.

Yeah you're right, damn it. I guess that's it, we reached a limit.
Thank you again for the responses.

[nomachine]

Here is my script that filters the 03 prefix. I cannot physically measure the benefits of this.
Who cares if it's 10, 20 or 200 Mk/s ?. . .Same slow shit. 

puzzle.cpp

Code:

#include <iostream>
#include <vector>
#include <iomanip>
#include <cmath>
#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>
#include <atomic>

std::atomic<int> keysGenerated(0);

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();
}

std::vector<unsigned char> calculateSHA256(const std::vector<unsigned char>& data)
{
    std::vector<unsigned char> hash(SHA256_DIGEST_LENGTH);
    SHA256(data.data(), data.size(), hash.data());
    return hash;
}

std::vector<unsigned char> calculateRIPEMD160(const std::vector<unsigned char>& data)
{
    std::vector<unsigned char> hash(RIPEMD160_DIGEST_LENGTH);
    RIPEMD160(data.data(), data.size(), hash.data());
    return hash;
}

void generateKeys(BIGNUM* minKeyBN, BIGNUM* maxKeyBN, const std::vector<unsigned char>& target_hash160_bytes, std::mutex& outputMutex, std::atomic<int>& keysGenerated, int totalKeys)
{
    BIGNUM* range = BN_new();
    BIGNUM* randomPrivateKey = BN_new();
    BIGNUM* bn_private_key = NULL;

    BN_sub(range, maxKeyBN, minKeyBN);

    EC_KEY* ec_key = EC_KEY_new_by_curve_name(NID_secp256k1);
    const EC_GROUP* curve = EC_KEY_get0_group(ec_key);
    EC_GROUP* ec_group = EC_GROUP_dup(curve);
    EC_KEY_set_group(ec_key, ec_group);

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

    while (keysGenerated < totalKeys) {
        BN_rand_range(randomPrivateKey, range);
        BN_add(randomPrivateKey, randomPrivateKey, minKeyBN);

        int numBits = BN_num_bits(randomPrivateKey);
        int numBytes = (numBits + 7) / 8;

        std::vector<unsigned char> private_key_bytes(numBytes, 0);
        int key_length = BN_bn2bin(randomPrivateKey, private_key_bytes.data());

        bn_private_key = BN_bin2bn(private_key_bytes.data(), key_length, NULL);
        EC_KEY_set_private_key(ec_key, bn_private_key);

        EC_POINT* public_key_point = EC_POINT_new(ec_group);
        EC_POINT_mul(ec_group, public_key_point, bn_private_key, NULL, NULL, NULL);

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

        if (public_key_bytes[0] != 0x03) {
            // Skip this iteration if the prefix is not 0x03
            EC_POINT_free(public_key_point);
            continue;
        }

        SHA256(public_key_bytes.data(), public_key_bytes.size(), sha256_result);
        ripemd160_result = calculateRIPEMD160(std::vector<unsigned char>(sha256_result, sha256_result + SHA256_DIGEST_LENGTH));

        std::string calculated_hash160_hex = bytesToHex(ripemd160_result);

        std::string message = "\r\033[01;33m[+] Public Key Hash (Hash 160): " + calculated_hash160_hex;
        {
            std::lock_guard<std::mutex> lock(outputMutex);
            std::cout << message << "\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) << "\033[0m" << std::endl;
                std::cout << "\e[?25h";
                std::cout.flush();
            }

            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();
            }

           keysGenerated++;

            break;
        }

        EC_POINT_free(public_key_point);
    }

    BN_free(range);
    BN_free(randomPrivateKey);
    EC_KEY_free(ec_key);
    EC_GROUP_free(ec_group);
}

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();
    BN_dec2bn(&minKeyBN, "524287");   // min range
    BN_dec2bn(&maxKeyBN, "1048575");  // max range
    std::string target_hash160_hex = "b907c3a2a3b27789dfb509b730dd47703c272868";

    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, maxKeyBN, target_hash160_bytes, std::ref(outputMutex), std::ref(keysGenerated), 1);
    }

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

    BN_free(minKeyBN);
    BN_free(maxKeyBN);

    return 0;
}

Code:

g++ -o puzzle puzzle.cpp -lssl -lcrypto -lpthread

[WanderingPhilospher]

...

Yes, I understood your idea. But there is 1 fact. When adding a point with even private keys and then adding them, the Y coordinate can be either even or odd. If you filter in getGPUStartingKeys(), I think that after 1 addition the result can be anything.

Yeah you're right, damn it. I guess that's it, we reached a limit.
Thank you again for the responses.

Interesting discussion.

You need to take those 16 GPUs and run a version of Kangaroo with them.

Speed should = at least 112GK/s

So you get more speed with roughly performing the same number of ops.

AND the reward for #130 is bigger

I am working on a few things, "prep" for #130. I'm still working it out but have the idea and have tested it at lower bits. Nothing earth shattering, just trying to create better "traps".

[3dmlib]

There are no limits on changing the address or fees, those limits are only on some wallets, otherwise you can change the fee, and receiving address by default as many times. If you are fighting a looter by double spending, it's better that you send the new tx to the initially intended address, but things like that should be automated.

How to change receiver address on second RBF transaction? What wallet have this function?

[Tepan]

did you really understand what this RBF-challenge is all about?

i know what you mean bro, i already told to everyone about attack the addresses with some TX like RBF method, but noones care  

Take your chances by deploying a bot to compete with the looter, otherwise you can kiss your coins good bye. Or just talk  with a large pool beforehand, you could offer them $10,000 bonus and if they include the tx in their block, other pools won't dare to mine that block again just to take those extra coins.

So you are claiming that any Bitcoin transaction could be double-spended and therefore all Bitcoin transactions are insecure. Makes sense ?

What do you think of a challenge? I transfer an amount of x coins, you only know the source address, which I will publish here. Its private key will be in the range of 66bit just like the mentioned puzzle. Then you siphon off the coins and transfer them to another address before I receive them just like you described the looter would. If the coins end up at your freely chosen address, you can keep them. If they end up with me, you have lost and made a fool of yourself. Deal ?

@Legends_Never_Die
So what's about the RBF-challenge, deal or no deal?
I generate an address with a 66bit private key and send a few coins to it. Then I create a transaction to send the entire contents of this wallet address to any other address. I will explicitly set 1 sat/vB as the fee so that the transaction can stay in the blockchain forever. Now you (or someone else if you like) try to cancel this outgoing transaction and thus simulate a mallory sucker that wants to withdraw the coins. As the transaction has the minimum fee you have all the time that you need.

As the fees are currently very high, I am unfortunately unable to send coins to the RBF-challenge address. If anyone is interested in this RBF-challenge and would like to sponsor some minimum amount of satoshis, here is the wallet address:
1C8uD9G4AGQas5sG15869p5B1mrF3RELY3

I own the private key of this address, here's the signature:

^{Message: This address was exclusively generated for the RBF-challenge <https://bitcointalk.org/index.php?topic=1306983.msg63398077#msg63398077> and I have the private key of this address. citb0in, 2023-12-27
Address: 1C8uD9G4AGQas5sG15869p5B1mrF3RELY3
Signature: IAMmKuX5C2Z97eCSjYjfAN49hApXTk2LcMLzHWUp/vYYTxmKsHGaUdc7KQRFilTHUyqiEGt0B3NFqanjcgWl/Fg=}

The sha256 of the privkey is:
6297b7a9a38985d967e9d5603ba5e4f133b0e8a998219f29c4029aa03601110b

As soon as this address has been funded with a few satoshis by a generous supporter, I could prepare the outgoing transaction as explained. Any funder appreciated
Let me know if anyone's interested in that challenge.

i already send messages about this topic, i have some information about RBF attack, i learn this method from 2021.

[alek76]

Yeah you're right, damn it. I guess that's it, we reached a limit.
Thank you again for the responses.

The only thing we can do is use parity mode. Keeping in mind the fact that even private keys have public keys prefixed with 02 and 03, this is not important. The main thing is the parity of the private key.
1. Generate a new table GPUGroup.h from even numbers - 2G, 4G, 6G, 8G, 10G, 12G,... 1024G
2. In the getGPUStartingKeys() function we use only even private keys, make a dot and send it to the Poins p array, filling it completely. This way we will only look for an even private key. It doesn't matter what prefix PubKey has.
Winning plus 100% or minus 100%. Without knowing the even or odd target private key.
I also removed the return to save any result to a file:

Code:

string chkAddr = secp->GetAddress(searchType, mode, p);
    if (chkAddr != addr) {
      printf("\nWarning, wrong private key generated !\n");
      printf("  Addr :%s\n", addr.c_str());
      printf("  Check:%s\n", chkAddr.c_str());
      printf("  Endo:%d incr:%d comp:%d\n", endomorphism, incr, mode);
      //return false; error ?
    }

I think this return is unnecessary.

[alek76]

Added a file with a Spin loop. The code is only for P2PKH addresses.

https://github.com/alek76-2/VanitySearch/blob/main/mod/other_files/GPUCompute_fast.h
https://github.com/alek76-2/VanitySearch/blob/main/mod/other_files/GPUEngine.cu

Edit GPUEngine.h - add #define NB_SPIN 32 // max 64
Edit GPUGroup.h - add #define GRP_SIZE_DIV2 512
Replace GPUEngine.cu

Run:

Code:

VanitySearch.exe -stop -t 0 -nosse -o Result.txt -verbose 1 -gpu -level 0 -r 50000000 -bits 66 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so

VanitySearch.exe -stop -t 0 -nosse -o Result.txt -verbose 1 -gpu -bip39 12 -level 1 -r 50000000 -bits 66 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so

There the rekey are reduced by 1000.

Who can test the speed increase or find a bug?   New Year's gift

[WanderingPhilospher]

Added a file with a Spin loop. The code is only for P2PKH addresses.

https://github.com/alek76-2/VanitySearch/blob/main/mod/other_files/GPUCompute_fast.h
https://github.com/alek76-2/VanitySearch/blob/main/mod/other_files/GPUEngine.cu

Edit GPUEngine.h - add #define NB_SPIN 32 // max 64
Edit GPUGroup.h - add #define GRP_SIZE_DIV2 512
Replace GPUEngine.cu

Run:

Code:

VanitySearch.exe -stop -t 0 -nosse -o Result.txt -verbose 1 -gpu -level 0 -r 50000000 -bits 66 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so

VanitySearch.exe -stop -t 0 -nosse -o Result.txt -verbose 1 -gpu -bip39 12 -level 1 -r 50000000 -bits 66 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so

There the rekey are reduced by 1000.

Who can test the speed increase or find a bug?   New Year's gift

NGL....I lost interest after reading this much and not being half way done

Build OpenSSL:
Install Perl x64 for MS Windows from https://strawberryperl.com
Link: https://strawberryperl.com/download/5.32.1.1/strawberry-perl-5.32.1.1-64bit.msi
Install Netwide Assembler (NASM).
Download NASM x64 https://www.nasm.us/pub/nasm/releasebuilds/2.16.01/win64/nasm-2.16.01-installer-x64.exe
Add Path C:\Program Files\NASM;
Add PATHEXT .PL; before .BAT;
those. - .COM;.EXE;.PL;.BAT;
And be sure to restart your PC.
Download the library from the official website openssl-1.0.1a.tar.gz
http://www.openssl.org/source/old/1.0.1/openssl-1.0.1a.tar.gz

And there's not a clear and concise excerpt telling anyone what is what and what does what with your changes. Seems like only you and nomachine know what is going on.

[alek76]

NGL....I lost interest after reading this much and not being half way done

Build OpenSSL:
Install Perl x64 for MS Windows from https://strawberryperl.com
Link: https://strawberryperl.com/download/5.32.1.1/strawberry-perl-5.32.1.1-64bit.msi
Install Netwide Assembler (NASM).
Download NASM x64 https://www.nasm.us/pub/nasm/releasebuilds/2.16.01/win64/nasm-2.16.01-installer-x64.exe
Add Path C:\Program Files\NASM;
Add PATHEXT .PL; before .BAT;
those. - .COM;.EXE;.PL;.BAT;
And be sure to restart your PC.
Download the library from the official website openssl-1.0.1a.tar.gz
http://www.openssl.org/source/old/1.0.1/openssl-1.0.1a.tar.gz

And there's not a clear and concise excerpt telling anyone what is what and what does what with your changes. Seems like only you and nomachine know what is going on.

Is there another way to build OpenSSL?
Do you have any idea about the size of the keyspace or not? In any case, you need a good random generator. In another case, you will search with compressed entropy, which will also be in the 66-bit range. Then choose "compressed entropy", perhaps for this reason the search takes so long...
And don’t forget to add - Add Path C:\Strawberry\perl\bin;
What else should I tell you? The code is open. These are different ways to obtain a starting key. That's about it. But the entropy must be good in any case.

[WanderingPhilospher]

NGL....I lost interest after reading this much and not being half way done

Build OpenSSL:
Install Perl x64 for MS Windows from https://strawberryperl.com
Link: https://strawberryperl.com/download/5.32.1.1/strawberry-perl-5.32.1.1-64bit.msi
Install Netwide Assembler (NASM).
Download NASM x64 https://www.nasm.us/pub/nasm/releasebuilds/2.16.01/win64/nasm-2.16.01-installer-x64.exe
Add Path C:\Program Files\NASM;
Add PATHEXT .PL; before .BAT;
those. - .COM;.EXE;.PL;.BAT;
And be sure to restart your PC.
Download the library from the official website openssl-1.0.1a.tar.gz
http://www.openssl.org/source/old/1.0.1/openssl-1.0.1a.tar.gz

And there's not a clear and concise excerpt telling anyone what is what and what does what with your changes. Seems like only you and nomachine know what is going on.

Is there another way to build OpenSSL???
Do you have any idea about the size of the keyspace or not? In any case, you need a good random generator. In another case, you will search with compressed entropy, which will also be in the 66-bit range. Then choose "compressed entropy", perhaps for this reason the search takes so long...
And don’t forget to add - Add Path C:\Strawberry\perl\bin;
What else should I tell you? The code is open. These are different ways to obtain a starting key. That's about it. But the entropy must be good in any case.

I do not know about another way to build in OpenSSL.

So all of those mods are for just trying to generate starting keys, in different ways?

I like your work alek, but just to generate a starting key differently, that's a no from me. It's not about the starting key to me, but about the 2^64 ones after those starting keys

It's solid work/code. Was it all for trying to generate starting keys differently? I thought there was something in there about trying to crack deterministic wallets, no?

[alek76]

I do not know about another way to build in OpenSSL.

So all of those mods are for just trying to generate starting keys, in different ways?

I like your work alek, but just to generate a starting key differently, that's a no from me. It's not about the starting key to me, but about the 2^64 ones after those starting keys

It's solid work/code. Was it all for trying to generate starting keys differently? I thought there was something in there about trying to crack deterministic wallets, no?

You're caught No, this is not a hack. This is a generation method. We need approximately the same algorithm as deterministic wallets.
It is also possible that we need a correct way to generate SEED, which includes its entropy - according to a different principle. The space is very large. And we need life somewhere nearby in the starting keys.

It's all because of nomachine , how it went and went with these seed receipts... But, he's great

[WanderingPhilospher]

I do not know about another way to build in OpenSSL.

So all of those mods are for just trying to generate starting keys, in different ways?

I like your work alek, but just to generate a starting key differently, that's a no from me. It's not about the starting key to me, but about the 2^64 ones after those starting keys

It's solid work/code. Was it all for trying to generate starting keys differently? I thought there was something in there about trying to crack deterministic wallets, no?

You're caught No, this is not a hack. This is a generation method. We need approximately the same algorithm as deterministic wallets.
It is also possible that we need a correct way to generate SEED, which includes its entropy - according to a different principle. The space is very large. And we need life somewhere nearby in the starting keys.

It's all because of nomachine , how it went and went with these seed receipts... But, he's great

I hear ya man!

I guess it has its advantages in some aspects. Can you not program it to land on the correct priv key every time, in every range? (joke)

I'm still trying to figure out a stride function; it has gotten the better of me, off and on, for 2+ years lol.

A stride that strides each GPU thread, by x amount. I could find one of these challenges much quicker, but to no avail; I stick with Kangaroo for larger puzzles; 512 RTX 4090s would solve 130 in roughly 246 days

[mcdouglasx]

I have developed a new method!
I have studied it 100% and it works.
My calculations tell me that before the end of January 2024 I will have unlocked puzzle #130 (if someone else doesn't solve it before).
For registration, I will send it to this address BTC bc1qxs47ttydl8tmdv8vtygp7dy76lvayz3r6rdahu

This message will not have edits for its validity.

If you want to question it, do it on February 1, 2024 if I don't send it to that address.

happy new year in advance, see you in February!, if life allows me.

blessings for all.

[alek76]

I'm still trying to figure out a stride function; it has gotten the better of me, off and on, for 2+ years lol.

A stride that strides each GPU thread, by x amount. I could find one of these challenges much quicker, but to no avail; I stick with Kangaroo for larger puzzles; 512 RTX 4090s would solve 130 in roughly 246 days

Not everyone has such resources. But the probability can be different, and for this you need a good chance. Again we need a good random. Here, depending on your luck, it’s possible to win 130 in a month. I’m trying to increase the maximum jump size to 2^105. It's just a matter of chance

[WanderingPhilospher]

I have developed a new method!
I have studied it 100% and it works.
My calculations tell me that before the end of January 2024 I will have unlocked puzzle #130 (if someone else doesn't solve it before).
For registration, I will send it to this address BTC bc1qxs47ttydl8tmdv8vtygp7dy76lvayz3r6rdahu

This message will not have edits for its validity.

If you want to question it, do it on February 1, 2024 if I don't send it to that address.

happy new year in advance, see you in February!, if life allows me.

blessings for all.

Go get that bag mcdouglas!!!

Rooting for you even though I am a 130 searcher as well.

[alek76]

Go get that bag mcdouglas!!!

Rooting for you even though I am a 130 searcher as well.

Puzzle 130 will not be solved soon, around February 1, 2025

[nomachine]

Is there another way to build OpenSSL?

Yep....If you use Linux....

Code:

sudo apt-get install libgmp-dev libssl-dev build-essential

[FlleOWA]

Happy New Year everyone. I only read here but didn’t write anything.

What did I find? I found a number that, if subtracted or added to the public key. Returns the same public key, regardless of whether the private key is large or small. A number was also found that, if subtracted or added to the public key, produces a key that is not on the curve.

I don't know to be honest. Has anyone found this already or not? But I’m still deciding what to do with it next. Because, in my opinion, this is the vulnerability of the curve. I've been working on the puzzle for 2 weeks. So far I've only found this. Sorry for broken English. I wrote through a translator.