Bitcoin puzzle transaction ~32 BTC prize to who solves it

[maylabel]

We need to develop a multi-threaded algorithm with the following structure:

Thread 1: This thread generates starting keys and stores them in a global array.
Thread 2: This thread retrieves keys from the global array, computes the corresponding points and RIPEMD-160 hashes, and then stores the resulting HASH160 values into another global array.
Threads 3 and 4: These comparator threads read several hundred addresses from a file and compare them with the HASH160 values stored in the global array.
Each thread operates independently without relying on the others, potentially improving overall performance. They will work separately.
Maybe it will be faster this way? I don't know.

this is a pool, right? a pool of checking addresses.

https://tosc.iacr.org/index.php/ToSC/article/view/11282/10814

You can find the Git code for the 43-step differential comparator here:

https://github.com/Peace9911/ripemd160_attack

This is far better than gazing into a crystal ball or magic circle. 

ohhhhh, i looooooooove papers, thanks. I will consume 

Did you know also ECDSA has a great attack way not patched?
I didnt have time if is possible for btc but is worth it to read too
https://minerva.crocs.fi.muni.cz/

Anyways, i believe if we combine our minds we can arrive somewhere tho

[kTimesG]

Not really, I discarded the first number one because is a testnet, so basically I didnt screw my statistics.

Did you account for the implicit "1"s I mentioned about?
E.g. in decimal if I give you the number "42" but you also know it's a 64-bit value, there are implicit "0"s in front of 42, if your goal is to make some stats on base10 digits of 64-bit values. Because it would not be fair to only count 0s in numbers such as "402", "420", "81505" and so on.

Same principle for a BTC address. For base58 the implicit symbol is "1" (the first symbol of base58).
This has nothing to do with the "1" which you actually see at the start of an address. And even more, if you have multiple "1"s at the start, all of them are just a convention that says "so many bytes at the start are 0x00", NOT "this so many digits at the front of the base58 representation are 1". So some work is involved here if you truly want to make a histogram on base58 usage (which I don't really understand why you would, it's much more direct and error-free if you just use the binary representation).

Furthermore, I didn't found any explanation why has this preferential for some letter if is a "random math base equation" even if you use other hexadecimals. Is this not defeat the entire propose of been random?

Modulus bias. It is not about the random function, it's about the domain size vs. the modulus (base in this case) which is used. base58 is just done like in any other case: divide a big integer, use remainder, repeat with quotient.

Maybe run the stats on the base2 160 bits instead?

That's a possibility, but when you have a bias, you have a weakness  

The only bias here is about the bias of base58 representation, not on RIPEMD.

We need to develop a multi-threaded algorithm with the following structure:

Thread 1: This thread generates starting keys and stores them in a global array.
Thread 2: This thread retrieves keys from the global array, computes the corresponding points and RIPEMD-160 hashes, and then stores the resulting HASH160 values into another global array.
Threads 3 and 4: These comparator threads read several hundred addresses from a file and compare them with the HASH160 values stored in the global array.
Each thread operates independently without relying on the others, potentially improving overall performance. They will work separately.
Maybe it will be faster this way? I don't know.

But i believe an better strategy:
3 threads - one produce addresses, the other just check the first 4 digits, and other comparing the pool generated by the second one.
Why? Because you save time by just run the first 4 letters.

I was watching a yt about a billion data points challenge and they run the analyzes in less than 3 sec with java!


If someone can do this in rust/c/java, I will give a hug, please, i need it!
Because python....no,no,no... unless you want you house burn down

I did it in C. PrivKey (sequential) to PubKey to RIPEMD and then memcmp with the static constant target RIPEMD (which ofcourse returns false as soon as the first byte is different, come on...). You CAN't do it faster than this, and it can only scale linearly with thread count. But it's quickly obvious that it's unfeasible, I mean it's the only real way to do it without knowing the public key, but it's both a O(n) complexity AND it involves SHA256 + RIPEMD at every step. That's why I strongly believe #130 will be found next, not #66. Much more room for breakthroughs and exploration there, and while the complexity seems similar it runs WAY, way faster (no hashing nonsense).

btw we need a ton of signatures to break ECDSA, we only have one here. And the nonces are deterministic (checked), so we're screwed.

[jacky19790729]

btw we need a ton of signatures to break ECDSA, we only have one here. And the nonces are deterministic (checked), so we're screwed.

#130
only 1 rsz

r      =  0x9fca00d29192007648f7e4b525f15a00a5180833617a604ec6701833eb26e580
s      =  0x1f5ff38219a72080f77534b735badbcf57f503a33e91935ee7a859387abf5483
z      =  0x8d9ac8a5bc9b7ab8954e985fb9ebfc82e11c009fcccafcfb90934fb01a8c57ce
k     =  2^256
priv = 2^129  ~  2^130

Even with a large number of signatures, it still takes a lot of time...
I run https://github.com/iceland2k14/rsz LLL_nonce_leakage.py  ,  spend time log

CPU:    Intel i9-11900K                ( 2024/06/10 Update )

Code:

K bit_length               spend time
---------------------------------------------------------------
200  bits                 20    seconds ( success to find private key )     8  rsz  
...
224  bits                207   seconds ( success to find private key )    12  rsz  
...
236  bits               1813   seconds ( success to find private key )    19  rsz  
...
240  bits               5021  seconds ( success to find private key )    23 rsz  
...
244  bits             12747   seconds ( success to find private key )   31  rsz  
245  bits             18146   seconds ( success to find private key )   33  rsz
246  bits             36348   seconds ( success to find private key )   37  rsz
247  bits                                    
248  bits           142189  seconds ( success to find private key )   45  rsz
249  bits           251375  seconds ( failed )   52  rsz   , need more rsz
250  bits           572073  seconds ( failed )   64  rsz   , need more rsz
251  bits
252  bits
253  bits          Never  , No matter hundreds to thousands or more rsz
254  bits          Never  , No matter hundreds to thousands or more rsz
255  bits          Never  , No matter hundreds to thousands or more rsz
256  bits          Never  , No matter hundreds to thousands or more rsz

[Cryptoman2009]

Stop looking for logic, all the addresses of the puzzle are random.
And using python is 100% a waste of energy.
Don't dream idly.
Search in a small space (for 66 or 130) and hope for luck.

99.99999999999999999% JUST FOR FUN

[maylabel]

Not really, I discarded the first number one because is a testnet, so basically I didnt screw my statistics.

Did you account for the implicit "1"s I mentioned about?
E.g. in decimal if I give you the number "42" but you also know it's a 64-bit value, there are implicit "0"s in front of 42, if your goal is to make some stats on base10 digits of 64-bit values. Because it would not be fair to only count 0s in numbers such as "402", "420", "81505" and so on.

As I said,I didn't have time to take a look in running in decimals yet. It's in my to-do list, and I'm surely will take a look to see if any patterns emerged

Same principle for a BTC address. For base58 the implicit symbol is "1" (the first symbol of base58).
This has nothing to do with the "1" which you actually see at the start of an address. And even more, if you have multiple "1"s at the start, all of them are just a convention that says "so many bytes at the start are 0x00", NOT "this so many digits at the front of the base58 representation are 1". So some work is involved here if you truly want to make a histogram on base58 usage (which I don't really understand why you would, it's much more direct and error-free if you just use the binary representation).

I believe you didnt get what I was pointing out:
Cryptography, as any most mathematical techniques, consist in change a one space to another space... we do this all the time, transform x,y,z in polar coordinates, exp and so on...

What I may didn't said is:
Any exchange of spaces has strength and drawbacks, they are the sides of the same coin.
Some pattern can and will emerge when you change spaces.
Initially, i imagined change for an log space, but now I see can have other functions fitting better with what I'm seeing.

But something similar happened when I worked as statistician in developing games for casinos:
We need to work hard to looks "most random as possible". It's way more complicated than you think.

The greatest problem is human perception of randomness is not the same as computer randomness, that's why most lottery game are made by functions like that and I proved decade ago this
(I was just a broke uni student, and I didn't had credit to put money where my mouth it is, unfortunately )

That's why this puzzle really tickles me: I know I can do it, time and money is all I need tho

Stop looking for logic, all the addresses of the puzzle are random.
And using python is 100% a waste of energy.
Don't dream idly.
Search in a small space (for 66 or 130) and hope for luck.

99.99999999999999999% JUST FOR FUN

Of course, money is a great incentive (i never needed so much in my life like now) but is a great way to take the rust of my mathematical skills.
If you think is a waste of time, is your opinion and good luck for you.... is just not mine

Furthermore, I didn't found any explanation why has this preferential for some letter if is a "random math base equation" even if you use other hexadecimals. Is this not defeat the entire propose of been random?

Modulus bias. It is not about the random function, it's about the domain size vs. the modulus (base in this case) which is used. base58 is just done like in any other case: divide a big integer, use remainder, repeat with quotient.

That's a high possibility, but again, when pattern emerges, even if is not a bijective function per say, the areas of search reduce considerabily

Maybe run the stats on the base2 160 bits instead?

That's a possibility, but when you have a bias, you have a weakness  

The only bias here is about the bias of base58 representation, not on RIPEMD.

We need to develop a multi-threaded algorithm with the following structure:

Thread 1: This thread generates starting keys and stores them in a global array.
Thread 2: This thread retrieves keys from the global array, computes the corresponding points and RIPEMD-160 hashes, and then stores the resulting HASH160 values into another global array.
Threads 3 and 4: These comparator threads read several hundred addresses from a file and compare them with the HASH160 values stored in the global array.
Each thread operates independently without relying on the others, potentially improving overall performance. They will work separately.
Maybe it will be faster this way? I don't know.

But i believe an better strategy:
3 threads - one produce addresses, the other just check the first 4 digits, and other comparing the pool generated by the second one.
Why? Because you save time by just run the first 4 letters.

I was watching a yt about a billion data points challenge and they run the analyzes in less than 3 sec with java!


If someone can do this in rust/c/java, I will give a hug, please, i need it!
Because python....no,no,no... unless you want you house burn down

I did it in C. PrivKey (sequential) to PubKey to RIPEMD and then memcmp with the static constant target RIPEMD (which ofcourse returns false as soon as the first byte is different, come on...). You CAN't do it faster than this, and it can only scale linearly with thread count. But it's quickly obvious that it's unfeasible, I mean it's the only real way to do it without knowing the public key, but it's both a O(n) complexity AND it involves SHA256 + RIPEMD at every step.

I was searching yesterday about Bend and the Multi parallel processing for python, together with some other ideas:
- Instead to search for letters use the decimal code cuz been an integer is faster than base 58, around 30% of the speed
- KAN machine learning (maybe ) still very new so IDK tbh, but is a possibility nevertheless.
- dedicated 2 mini pcs and only the list been for another computer (mine is worse than a potato)
- use old phones to do some part of the search.... is not fast but is something

That's why I strongly believe #130 will be found next, not #66. Much more room for breakthroughs and exploration there, and while the complexity seems similar it runs WAY, way faster (no hashing nonsense).

btw we need a ton of signatures to break ECDSA, we only have one here. And the nonces are deterministic (checked), so we're screwed.

can you explain more about? I didn't get it, sorry 

Now I need go back to work... see you later

[nomachine]

That's why I strongly believe #130 will be found next, not #66. Much more room for breakthroughs and exploration there, and while the complexity seems similar it runs WAY, way faster (no hashing nonsense).

btw we need a ton of signatures to break ECDSA, we only have one here. And the nonces are deterministic (checked), so we're screwed.

can you explain more about? I didn't get it, sorry 

Now I need go back to work... see you later

That's not my quote. But regardless, I can say that none of the puzzles will be solved soon. It takes a thousand GPUs to make something serious. Everything else is just kidding or when discussion derails into "who has bigger dick" babble 

[holy_ship]

It takes a thousand GPUs to make something serious. Everything else is just kidding

Why GPU? BSGS works on CPU.

btw, what's more important RAM or CPU?

I've tried
AMD Ryzen 9 7950X - 4.5GHZ, 16c/32th + 128GB - 4ek on start, reaches 6ek after week
Intel Core i7-11700K 3.6GHZ, 8c/16th + 128GB - only 2ek, no growth
Intel Core i7-11700K 3.6GHZ, 8c/16th + 64GB - around 1ek, no growth

E5-2670v3 2.3 GHz 12c/24th + 256GB - 7ek on start
2×E5-2680v4 2.4 GHz 28c/56th + 256GB - 9.5ek on start

[Cryptoman2009]

for keyhunt
both, cpu and ram

[aminsolhi]

keyhunt not good

i get a test with key hunt


you can test it.  key hunt speed in my pc is  60 Mk/s


i search for  this addrrss   1E5V4LbVrTbFrfj7VN876DamzkaNiGAvFo
this privatekey is  200000000000f4240

search start of 20000000000000000


this private key is 1,000,000 key of start

in fact keyhunt must be find in 2 sec , but fin at 100 Sec

In the Cuda programming, an algorithm is executed in parallel, and in fact, this search operation in each core performs a similar task in parallel, and the cores do not help each other's process to increase the search speed, but each of them works as an island exactly the same way. They do something else and that's why this program has problems

i have a simple alghoritm with cpu in python , you can test it

Code:

# -*- coding: utf-8 -*-

"""
Created on Thu Mar 14 17:50:54 2024

1000 Bitcoin Puzzle Scanner for 2^66 ~ 2^67

@author: Amin Solhi , Contacts =>  email: amin.solhi@gmail.com , +9891111842779
"""
import bitcoin
import ecdsa
import secrets
from timeit import default_timer as timer   
import datetime

global target_address
global output_file
global rng
global private_key
global ks
global start
global random_mode


target_address = "13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so"
output_file = "data.txt"
rng = 20 # int(input("Enter Random Space Number 1 ~ 100 :"))
private_key="20000000000000000"
ks=0
start = timer()
random_mod = True # True or False

print ("\nBTCGEN Bitcoin Puzzle #66 Scanner \n")
print ("BTC Address : ",target_address)
print ("OutPut File : ",output_file)
print ("Randome Mod : ",f"{str(random_mod)}")
if (random_mod):
    print ("Random Key  : ",f'per {rng}K key')
print ("Device      :  CPU")
print ("Global Start: ",private_key)
print ("Global END  :  40000000000000000")

print('\n')



def remove_zeros(input_string):
    result = ""
    zero = ""
    for char in input_string:
        if char != "0":
            zero = "finish"
        if zero =="finish" :
            result += char
    return result


t=""
t +="0"*47

def h(a):
    #a = a[:1] + '0' + a[1:]   
    if (len(a) < 64):
        #a = a[:1] + '0' + a[1:]
        a = '0' + a[:]
        if (len(a) < 64):
           a = h(a)           
    return a 

def generate_random_priv():
    p=str(secrets.choice(range(2, 4)))
    return (p+secrets.token_hex(8))


def generate_private_key(num_hex):
    num_decimal = int(num_hex, 16)
    num_decimal += 1
    num_hex = h(str(f'{num_decimal:x}'))
    return (num_hex)

def private_key_to_public_key(private_key):
    sk = ecdsa.SigningKey.from_string(bytes.fromhex(private_key), curve=ecdsa.SECP256k1)
    vk = sk.get_verifying_key()
    compressed_public_key = vk.to_string("compressed").hex()
    return compressed_public_key

def onmain():
    #start = timer()
    global private_key
    global rng
    global ks
    global start
    global target_address
    global i
    for _ in range(rng*1000):#while True:
        ks+=1
        private_key = generate_private_key(private_key)#secrets.randbelow(32))  # Generate a random private key
        public_key = private_key_to_public_key(private_key)  # Convert private key to compressed public key       
        #print (private_key)
        #print(i,"--- ",timer()-start,"seconds ---" ,)
        # Generate Bitcoin address from public key
        bitcoin_address = bitcoin.pubtoaddr(public_key)
        if (bitcoin_address == target_address):
            f = open(output_file, "a")
            f.write('\nprivate key int: '
                    + private_key
                    +'\nBitcoin address: '
                    + bitcoin_address+'\n_________\n')
            f.close()
                   
            print(f"\nFound matching Bitcoin address for private key: {private_key}")
            input("")
    print(f"\r[Total : {(ks/1000000)} Mk/{int(timer()-start)}s] [Private key hex: {(remove_zeros(private_key))}]  ", end="")     


def onmain_random():
    #start = timer()
    global private_key
    global rng
    global ks
    global start
    global target_address
    global i
    global random_str
    for _ in range(rng*1000):#while True:
        ks+=1
        private_key = generate_private_key(private_key)#secrets.randbelow(32))  # Generate a random private key
        public_key = private_key_to_public_key(private_key)  # Convert private key to compressed public key       
        #print (private_key)
        #print(i,"--- ",timer()-start,"seconds ---" ,)
        # Generate Bitcoin address from public key
        bitcoin_address = bitcoin.pubtoaddr(public_key)
        if (bitcoin_address == target_address):
            f = open(output_file, "a")
            f.write('\nprivate key int: '
                    + private_key
                    +'\nBitcoin address: '
                    + bitcoin_address+'\n_________\n')
            f.close()
                   
            print(f"\nFound matching Bitcoin address for private key: {private_key}")
            input("")
    print(f"\r[{str(datetime.timedelta(seconds=int(timer()-start)))}] [Total : {(ks/1000000)} Mk] [R: {i}] [Private key hex: {(remove_zeros(private_key))}]  ", end="")     

def main():
    global private_key
    global i
    global random_str
    random_str =""
    i=0
    if (random_mod):
        while True:
            i+=1
            private_key=generate_random_priv()
            onmain_random()
    else:
        while True:
            i+=1
            onmain()
       

if __name__ == "__main__":
    main()
   

[nomachine]

i have a simple alghoritm with cpu in python , you can test it

Code:

import bitcoin
import ecdsa



def private_key_to_public_key(private_key):
    sk = ecdsa.SigningKey.from_string(bytes.fromhex(private_key), curve=ecdsa.SECP256k1)
    vk = sk.get_verifying_key()
    compressed_public_key = vk.to_string("compressed").hex()
    return compressed_public_key



        bitcoin_address = bitcoin.pubtoaddr(public_key)

Why use Bitcoin and ECDSA imports? They're so slow, it feels like a waste of time.

Instead, utilize ICE (import secp256k1 as ice) for this function and the Bitcoin address line:


def private_key_to_public_key(private_key):
    priv_int = int(private_key, 16)
    return ice.scalar_multiplication(priv_int)

and

bitcoin_address = ice.pubkey_to_address(0, True, public_key)


It's approximately 10 times faster than ECDSA. But even that is miserable if you attack the dinosaur numbers.

The more you delve into Python, the more apparent it becomes that searching for Puzzle 66 through it is pointless.

Perhaps someone knowingly obscures things by selling Python scripts as the ultimate solution.  

[kTimesG]

Why use Bitcoin and ECDSA imports? They're so slow, it feels like a waste of time.

Instead, utilize ICE (import secp256k1 as ice) for this function and the Bitcoin address line:

def private_key_to_public_key(private_key):
    priv_int = int(private_key, 16)
    return ice.scalar_multiplication(priv_int)

and

bitcoin_address = ice.pubkey_to_address(0, True, public_key)


It's approximately 10 times faster than ECDSA. But even that is miserable if you attack the dinosaur numbers.

The more you delve into Python, the more apparent it becomes that searching for Puzzle 66 through it is pointless.

Is it non-pointless even if writing it in assembler? Some dick size updates: 11 million point additions/s (affine coords). There is a trick that even JLP's VanitySearch is missing which allows for some optimization on batch additions (8.5 Mkeys/s with that one). It's all about the branch processing.

https://github.com/iceland2k14/secp256k1

On my old Laptop with i7 4810 MQ CPU
With 3500000 continuous keys in 1 group call, we get 3.5 Miilion Key/s Speed with 1 cpu:

This is very misleading. We only get the result key, not 3.500.000, simply because it does 3500000 Jacobian additions and a single final affine conversion. I don't even need to disassemble the DLL to be 100% sure about this, because the fastest known algorithm to do an modular inversion on 256-bit numbers requires 4000 CPU cycles on my i9 13th gen CPU, which means it can never ever do more than around 1 million inversions per second. But Jacobian point additions? 8 million. But those intermediary points are useless since they do not have any invariant characteristic unless you actually reduce the fractions it holds (so, the expensive mod inverse).

Anyway, all this is completely irrelevant for puzzle 66, even if magically we can do an infinite amount of additions / second, it has zero impact on the speed, because all the hashing required is many times slower than any EC operation.

[nomachine]

It takes a thousand GPUs to make something serious. Everything else is just kidding

Why GPU? BSGS works on CPU.

btw, what's more important RAM or CPU?

I've tried
AMD Ryzen 9 7950X - 4.5GHZ, 16c/32th + 128GB - 4ek on start, reaches 6ek after week
Intel Core i7-11700K 3.6GHZ, 8c/16th + 128GB - only 2ek, no growth
Intel Core i7-11700K 3.6GHZ, 8c/16th + 64GB - around 1ek, no growth

E5-2670v3 2.3 GHz 12c/24th + 256GB - 7ek on start

Why RAM ?

How much storage is required for a hash table for a search space of Puzzle 130?

Each entry in the hash table will contain a key (of 256 bits) and a pointer (of 80 bits) to the corresponding data.
So, each entry requires 256 bits + 80 bits = 336 bits.

Total bits required for hash table = 336 bits per entry * 2^130 entries
Total bits = 336 * 2^130

To convert bits to petabytes:
1 petabyte (PB) = 8 * 10^15 bits

So, total petabytes (PB) = (336 * 2^130) / (8 * 10^15)

Total petabytes (PB) ≈ 42 PB RAM

It is not possible to get such amount of ram in the next 80 years.

[aminsolhi]

i have a simple alghoritm with cpu in python , you can test it

Code:

import bitcoin
import ecdsa



def private_key_to_public_key(private_key):
    sk = ecdsa.SigningKey.from_string(bytes.fromhex(private_key), curve=ecdsa.SECP256k1)
    vk = sk.get_verifying_key()
    compressed_public_key = vk.to_string("compressed").hex()
    return compressed_public_key



        bitcoin_address = bitcoin.pubtoaddr(public_key)

Why use Bitcoin and ECDSA imports? They're so slow, it feels like a waste of time.

Instead, utilize ICE (import secp256k1 as ice) for this function and the Bitcoin address line:


def private_key_to_public_key(private_key):
    priv_int = int(private_key, 16)
    return ice.scalar_multiplication(priv_int)

and

bitcoin_address = ice.pubkey_to_address(0, True, public_key)


It's approximately 10 times faster than ECDSA. But even that is miserable if you attack the dinosaur numbers.

The more you delve into Python, the more apparent it becomes that searching for Puzzle 66 through it is pointless.

Perhaps someone knowingly obscures things by selling Python scripts as the ultimate solution.  

In fact, what I meant by this comment was the problem of Key Hunt and I wrote different versions of these programs. And compared to Key Hunt, I put this code so that you can test and see the speed of a simple program with a  CPUs and a powerful program with GPU that does not work properly.

In general, I am very happy that you paid attention to this code and took your time, and I thank you. And also ice's idea was very good

[nomachine]

Is it non-pointless even if writing it in assembler?

The necessary double SHA-256 hashing in Bitcoin's address generation process is substantially slower than EC operations, ensuring that even perfect optimization of point additions will not eliminate the hashing bottleneck.

Therefore, whatever assembler optimizations and algorithmic tricks you can imagine to push the boundaries, they do not overcome the inherent speed limits imposed by modular inversion and hashing.

Double SHA-256 hashing is the ultimate bottleneck  

[kTimesG]

Is it non-pointless even if writing it in assembler?

Therefore, whatever assembler optimizations and algorithmic tricks you can imagine to push the boundaries, they do not overcome the inherent speed limits imposed by modular inversion and hashing.

Double SHA-256 hashing is the ultimate bottleneck  

That was my point, read carefully the question

Any sort of strategy is useless if you use either Python or ASM as long as any sort of higher-level op like SHA / RIPEMD is the actual bottleneck.

But if we only operate on EC then it's another story, this is where kangaroo / rho / bsgs comes into play, and we can start optimizing the operations that are the bottleneck at THAT level. It's one thing to do a few thousand mul/s in Python and another to do batched additions (with a single inversion) on a GPU, to reach giga adds/second. Millions of times faster for identical results. And ofcourse it's still not enough even at that level, so...

Something to think about on 256-bit modular math:
- a single inversion is ~60 times slower than a multiplication (GCD algo, not a simple operation at all)
- a multiplication is ~2 times slower than a squaring
- a squaring is ~3 times slower than an addition, ~2 slower than a normalization

A simple point addition requires one inversion, 2 multiplications, a squaring, 2 normalizations, and 6 additions.
A simple point multiplication requires a bunch of point additions (in truth, it's somewhat faster bcz of Jacobian shortcut, but still a lot of multiplications).

So stuff like doing point-scalar multiplication is a bad joke, compared to the problem of optimizing the primitives

[Cryptoman2009]

keyhunt not good

i get a test with key hunt
..........................................

KEYHUNT in BSGS mode work well

[albert0bsd]

keyhunt not good

you should learn to configure it, defaul thread subrange is 32 bits, for small ranges with multiple threads you should lower the N value  with "-n number" if the range is less than 1 Million keys you should use -n 0x10000
where 0x10000 its a 16 bits subrange per thread

Look



Found i less than a second

[maylabel]

After talk with a mathematician friend,I was clearly not wrong.... That's a relief

And I could reduce to 1/10 of the pool... what is great but not enough tho because the error bar still in 15 orders of magnitude
Good but not enough for me


Searching a little more is actually not far fetch my assumptions not my techniques.
Some papers already did something close but I need to think more and have dedicated pc for that to neutralize the noise.

Interesting how reminds me my time in spectroscopy Lab
https://imgur.com/a/NTlgYpp

https://imgur.com/a/NTlgYpp

And that's pretty cool!

[aminsolhi]

keyhunt not good

you should learn to configure it, defaul thread subrange is 32 bits, for small ranges with multiple threads you should lower the N value  with "-n number" if the range is less than 1 Million keys you should use -n 0x10000
where 0x10000 its a 16 bits subrange per thread

Look

https://talkimg.com/images/2024/05/21/1iVIH.png

Found i less than a second

are you key hunt creator?
nice too meet you
It was my mistake, I apologize, dear friend
ok , thank you
I meant https://github.com/WanderingPhilosopher/KeyHuntCudaClient
i use of first version keyhunt cuda

[albert0bsd]

are you key hunt creator?
nice too meet you

Hi, Yes I developed the CPU version all other are copies, if you have some doubt about it please use the next topic: https://bitcointalk.org/index.php?topic=5322040