Bitcoin puzzle transaction ~32 BTC prize to who solves it

[3dmlib]

No 100 USD man, just the minimum possible account you can send. Let's say 0.0001 BTC. Send 0.0001 BTC to 1C8uD9G4AGQas5sG15869p5B1mrF3RELY3 and choose an appropriate fee that is ok for you, 145 sat/vB ? By this the mentioned address that is controlled by me should be funded soon. As soon as this RBF-challenge address is funded I will generate the outgoing transaction with 1sat/vB, so it will take forever to be executed. This means the potential attacker has huge time available to redirect the transaction to his address of choice and keep the coins.

We're just gonna simulate if and how a bad boy could make such an attack to the real puzzle 66 (67, 68 ...) hit

I think it will be more interesting to attacker get 100 usd, not 0.0001 btc
Can I do it on my own address and post private key here?

I don't see the challenge in RBF, donate it to the kangaroo or keyhunt project, this is giving more money to the miners.

But if address balance is low attacker cannot make a transaction, because address balance should be more than current transaction fee...

If I did it right then 1PbL9QGg5fqRHmFXEBNBkey6Atp6SkWnFw address should have stuck transaction now.

After what time it will be usually dropped from mempool if not processed?

[mcdouglasx]

After what time it will be usually dropped from mempool if not processed?

48 hours

[AlanJohnson]

So for the sake of my safety and the safety of my loved ones, I resign from actively trying to break elliptic curve cryptography.

Oh, thank you my lord ! Now elliptic curve cryptography will remain safe.

Seriously now : you are a funny guy.

[CryptoMaster84]

Hello guys, I've been working lately on the @WanderingPhilosopher KeyHuntCudaClient version, stripped everything to keep only the single address search mode for the sake of searching puzzle 66 only.

Now the problem, as usual, no mater what ideas I try, there's no possibility to adapt it to what I want to increase the speed.

Without this set of controlling the public keys too to reduce the search complexity is not possible with the current resources, even if we know the priv key ranges.

For e.g. now I tried to modify the getGPUStartingKeys function, on the part where the keys are computed, to compute only the pub keys with the expected prefix, let's say 02 and save them to the p array instead of computing everything and store there.
Normaly this a good thing because you reduce almost 50% of keys, but as nbThread > filtredKeys, the rest of the threads are filled with zeros and I end up processing that garbage too when setKeys is called, so not a solution, even if I force the nbThread = filtredKeys.

Maybe the _GetHash160Comp I said, to filter there the keys just before the SHA256Initialize(s); an if condition to check if (publicKeyBytes[0] & 0xFF) != 0x02, to return early, otherwise to process.

The reason of considering this is as you know hash160 transformation is an expensive process, like the _ModInvGrouped from ComputeKeysSEARCH_MODE_SA and it that way I wanted to save processing.

Oh and the final goal was to have a new cmd argument defined as --pubKeyStartsWith to control the key, only the expected prefix and maybe the second byte, let' say --pubKeyStartsWith "02b7", I think that search will be more refined.

Any ideas?

[lordfrs]

^{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=}

Pubkey can be calculated with the information you provide and it takes a few seconds to find the private key. Because you said it was in the 66 bit range. I think you should not send coins to this wallet.

[alek76]

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

[nomachine]

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.

[alek76]

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.

That's right, that's the limit. It can speed up by about 6.3%. If spin rotation is used. I don’t know what can be optimized in the GPU anymore. Everything is clear there. This is absolutely a normal increase in speed. Every percent is worth it, especially in GPUs.

[CryptoMaster84]

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.

[alek76]

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

[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.

[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.