lightweight database, for brute force using publickeys-32Mk =3.81MB(secp256k1)

[mcdouglasx]

in my few tests I noticed that searching for bsgs is a lot faster than in normal search like here

My 2 tests results are above. This BSGS is much slower than other search script. Slower as in finding the key.

Maybe at 48 bit BSGS would outperform.

pk obtained partially matches the one you are looking for

Yeah, I do not know the pk lol, it was for the #130 challenge. I ran a fast BSGS (GPU) 74 bits above and below the "false positive" and nada.

Also, with your way of setting up the DB, with 0s and 1s; if running 64, isn't a false positive possible every 4,096 checks? 64^2.

In BSGS it is always better to create your database from the lowest possible range for your target, if your range is 2000:5000 in the database you start from 2000.
2^64 or 18446744073709551616 is the possibility of collision not 64^2.

If you do not know your target private key, I'm going with lowest range number - number of keys. You had it set up to start from a random point, which was usually in the middle of the range and above the key. Took me a minute to figure out why it hadn't found a key after a few minutes.

Maybe I am wrong, but I do not agree with your 2^64. The way I structure my database, and its number of subtractions, is a legit 2^16; but in your script, if a pub is either a 0 or a 1, how is that 2^64?
2^64 or a 64 bit number means there are 16 possible combos in each digit, example, 0xf62918cd28ab0236 is a 2^64 number, anything in the hex range 0x8000000000000000 - 0xffffffffffffffff is 2^64, 16 x 4, 16 combos for each character, or 2^4 for each position.
But if it's just a string of 64 0s and/or 1s, each position can only be a possible 2 digits. 64 characters in length, only 2 possible digits/characters (0, 1) 64^2, no?

we are talking about bits:  2^64.
If you choose as collision 128= 2^128

If I am, it’s your script lol.

I’m just telling you my results, from 20,000,000 and 60,000,000 keys.

Maybe you generated more keys? And why didn’t you show your starting key and how many keys. Something tells me you aren’t telling the whole truth.

Why would I need to lie?

BSGS is mainly a mathematical algorithm so we cannot do crazy searches.

this is random search it could have been coincidental.

edit:

sorry, my bad, I used my new script instead of using the published one.

Code:

Found the Baby Steps Table file: baby_steps__binary.bin. Will be used directly
Checking 3600000000000000 keys from 0x9de000a7c
BSGS FOUND PrivateKey  : 42387769979
Time Spent : 0.13 seconds

Oh hey look, .13 seconds, but look where the checking keys from is.

Man you can bullchit some people, but not this dawg.

In your script you have:
k1 = random.randint(start, end)

so if the random key is close to the key, then you will find it faster, but if you do not know the key, you must start from at least the starting range of the bit range.

My results above clearly showed the starting key of 0x1 and the amount of keys. You purposely didn't add that in your snippet.

Not today OP, not today lol.

I don't have the need to lie, I work hard and I sleep little, I used another script, that's all, there is no need to create a witch hunt Lol, like Albertobsd, he told me I was a liar, he ignored me, i shut his mouth and surely in a while we will see keyhunt with binary DB.

[moderator's note: consecutive posts merged]

[WanderingPhilospher]

Code:

Found the Baby Steps Table file: baby_steps__binary.bin. Will be used directly
Checking 3600000000000000 keys from 0x9de000a7c
BSGS FOUND PrivateKey  : 42387769979
Time Spent : 0.13 seconds

Oh hey look, .13 seconds, but look where the checking keys from is.

Man you can bullchit some people, but not this dawg.

In your script you have:
k1 = random.randint(start, end)

so if the random key is close to the key, then you will find it faster, but if you do not know the key, you must start from at least the starting range of the bit range.

My results above clearly showed the starting key of 0x1 and the amount of keys. You purposely didn't add that in your snippet.

Not today OP, not today lol.

I don't have the need to lie, I work hard and I sleep little, I used another script, that's all, there is no need to create a witch hunt Lol, like Albertobsd, he told me I was a liar, he ignored me, i shut his mouth and surely in a while we will see keyhunt with binary DB.

Well don’t tell me I’m doing something wrong with a simple search algo/script.

It’s like you told me I was wrong when the other script wouldn’t find the key when doing an increment and even a single key check. Which as you know, you found out to be true and fixed the bug.

Also, if using random, you could skip over the target key and miss it altogether, and that would result in a false negative.

I like to learn so I break down each script to understand it and test it. If something is wrong or broke, I let the OP know. No witch hunts lol.

[WanderingPhilospher]

I really don't understand the differences in the two scripts, when doing an incremental like I did.

Anywho, results for same 36 bit test using the other script:

Code:

This is the public key: 02b3e772216695845fa9dda419fb5daca28154d8aa59ea302f05e916635e47b9f6

 Building the Binary Database

 Targeting PubKey:      02b3e772216695845fa9dda419fb5daca28154d8aa59ea302f05e916635e47b9f6
 Number of PubKeys:     60,000,000
 Writing to file every: 60,000,000 keys
 Subtract Value:        1
 Space Covered:        60,000,000 / 0x3938700

DB Generation Time:  0:00:31.133606


 Scanning Randomly

 Current Random Key:  0x9dba52300   Jumps Made:  133
PK Found: 42387769980
PK Found: 0x9de820a7c


Search Time:  0:00:02.973942

Total Time:  0:00:34.107548

Start to finish using same concept as "BSGS", incremental search versus random.

BSGS results:

Code:

creating Baby Step

DB Generation Time:  0:00:27.731941

Found the Baby Steps Table file: baby_steps__binary.bin. Will be used directly
Checking 3600000000000000 keys from 0x800000000
BSGS FOUND PrivateKey  : 42387769979
Time Spent : 60.55 seconds

[COBRAS]

I really don't understand the differences in the two scripts, when doing an incremental like I did.

Anywho, results for same 36 bit test using the other script:

Code:

This is the public key: 02b3e772216695845fa9dda419fb5daca28154d8aa59ea302f05e916635e47b9f6

 Building the Binary Database

 Targeting PubKey:      02b3e772216695845fa9dda419fb5daca28154d8aa59ea302f05e916635e47b9f6
 Number of PubKeys:     60,000,000
 Writing to file every: 60,000,000 keys
 Subtract Value:        1
 Space Covered:        60,000,000 / 0x3938700

DB Generation Time:  0:00:31.133606


 Scanning Randomly

 Current Random Key:  0x9dba52300   Jumps Made:  133
PK Found: 42387769980
PK Found: 0x9de820a7c


Search Time:  0:00:02.973942

Total Time:  0:00:34.107548

Start to finish using same concept as "BSGS", incremental search versus random.

BSGS results:

Code:

creating Baby Step

DB Generation Time:  0:00:27.731941

Found the Baby Steps Table file: baby_steps__binary.bin. Will be used directly
Checking 3600000000000000 keys from 0x800000000
BSGS FOUND PrivateKey  : 42387769979
Time Spent : 60.55 seconds

Maybe you yse Celeron cpu ?))

[COBRAS]

Code:

Found the Baby Steps Table file: baby_steps__binary.bin. Will be used directly
Checking 3600000000000000 keys from 0x9de000a7c
BSGS FOUND PrivateKey  : 42387769979
Time Spent : 0.13 seconds

Oh hey look, .13 seconds, but look where the checking keys from is.

Man you can bullchit some people, but not this dawg.

In your script you have:
k1 = random.randint(start, end)

so if the random key is close to the key, then you will find it faster, but if you do not know the key, you must start from at least the starting range of the bit range.

My results above clearly showed the starting key of 0x1 and the amount of keys. You purposely didn't add that in your snippet.

Not today OP, not today lol.

I don't have the need to lie, I work hard and I sleep little, I used another script, that's all, there is no need to create a witch hunt Lol, like Albertobsd, he told me I was a liar, he ignored me, i shut his mouth and surely in a while we will see keyhunt with binary DB.

Definitely, not only Keyhunt will be with  binary DB, Mister Your binary DB is real good. Thank you very mach  for your binary DB !!!

[mcdouglasx]

I really don't understand the differences in the two scripts, when doing an incremental like I did.

Anywho, results for same 36 bit test using the other script:

Code:

This is the public key: 02b3e772216695845fa9dda419fb5daca28154d8aa59ea302f05e916635e47b9f6

 Building the Binary Database

 Targeting PubKey:      02b3e772216695845fa9dda419fb5daca28154d8aa59ea302f05e916635e47b9f6
 Number of PubKeys:     60,000,000
 Writing to file every: 60,000,000 keys
 Subtract Value:        1
 Space Covered:        60,000,000 / 0x3938700

DB Generation Time:  0:00:31.133606


 Scanning Randomly

 Current Random Key:  0x9dba52300   Jumps Made:  133
PK Found: 42387769980
PK Found: 0x9de820a7c


Search Time:  0:00:02.973942

Total Time:  0:00:34.107548

Start to finish using same concept as "BSGS", incremental search versus random.

BSGS results:

Code:

creating Baby Step

DB Generation Time:  0:00:27.731941

Found the Baby Steps Table file: baby_steps__binary.bin. Will be used directly
Checking 3600000000000000 keys from 0x800000000
BSGS FOUND PrivateKey  : 42387769979
Time Spent : 60.55 seconds

The problem with your tests may possibly be that the script that I uploaded as an example uses BitArray and using bitarray is much slower than using bytes (in python) and as the database increases, python becomes even slower, but I leave it that way. because my intention is to demonstrate how the use of bits should really be, with bytes it is faster but you ignore certain bits, and that is not what I intend.
baby step is a simple incremental database from point a to b (although you could make jumps but that would involve changing some things to the script

Since bsgs is a mathematical algorithm, you cannot be so close or so far from your objective, that is, you could believe that with a larger database you would reach the objective faster, but this is not the case in all cases because sometimes many bits of that database are useless for the calculation, you could spend hours looking for a match, in a pk that with the other script you find in a few seconds if you do not configure it correctly,
That is why a simple search with a larger database finds you faster than when you use BSGS because you are not taking into account the mathematical point of view.

My intention was to prove that we can eliminate the hash table and use a 1 bit per key binary database, but this did not prove fast.
For speed there is no other way than to use C.
or if you feel comfortable with python, create a dll that reads the bits in the database and integrate it with ctypes.
just like iceland does in his scripts.

Surely someone is using this in C, because there are programmers and developers and once the idea is developed, the programmers execute it without problems.

[WanderingPhilospher]

Another modified script using a modified version of your DB script.

Incremental, BSGS, Meet in the Middle, lol.

48 Bit Range Results:

Code:

This is the public key: 0291bee5cf4b14c291c650732faa166040e4c18a14731f9a930c1e87d3ec12debb

 Building the Binary Database

 Targeting PubKey:      0291bee5cf4b14c291c650732faa166040e4c18a14731f9a930c1e87d3ec12debb
 Number of PubKeys:     60,000,000
 Writing to file every: 60,000,000 keys
 Subtract Value:        1
 Space Covered:        60,000,000 / 0x3938700

DB Generation Time:  0:00:31.915161

Code:

 Scanning Incrementally (BSGS?! Maybe Meet In The Middle?)

 Current Key Position:  0x8000d693a3e2   Jumps Made:  30
PK Found: 191206974700443
PK Found: 0xade6d7ce3b9b


Search Time:  0:00:01.605224

Total Time:  0:00:01.606917

Not bad. Under 2 seconds to find the key in a 48 bit range. Less than 33 seconds combined with generating the DB.

[sssergy2705]

Another modified script using a modified version of your DB script.

Incremental, BSGS, Meet in the Middle, lol.

48 Bit Range Results:

Code:

This is the public key: 0291bee5cf4b14c291c650732faa166040e4c18a14731f9a930c1e87d3ec12debb

 Building the Binary Database

 Targeting PubKey:      0291bee5cf4b14c291c650732faa166040e4c18a14731f9a930c1e87d3ec12debb
 Number of PubKeys:     60,000,000
 Writing to file every: 60,000,000 keys
 Subtract Value:        1
 Space Covered:        60,000,000 / 0x3938700

DB Generation Time:  0:00:31.915161

Code:

 Scanning Incrementally (BSGS?! Maybe Meet In The Middle?)

 Current Key Position:  0x8000d693a3e2   Jumps Made:  30
PK Found: 191206974700443
PK Found: 0xade6d7ce3b9b


Search Time:  0:00:01.605224

Total Time:  0:00:01.606917

Not bad. Under 2 seconds to find the key in a 48 bit range. Less than 33 seconds combined with generating the DB.

Testing different versions of the script, I can't get a result in puzzles higher than 42. How are you doing with your modified versions of the script?

[WanderingPhilospher]

Another modified script using a modified version of your DB script.

Incremental, BSGS, Meet in the Middle, lol.

48 Bit Range Results:

Code:

This is the public key: 0291bee5cf4b14c291c650732faa166040e4c18a14731f9a930c1e87d3ec12debb

 Building the Binary Database

 Targeting PubKey:      0291bee5cf4b14c291c650732faa166040e4c18a14731f9a930c1e87d3ec12debb
 Number of PubKeys:     60,000,000
 Writing to file every: 60,000,000 keys
 Subtract Value:        1
 Space Covered:        60,000,000 / 0x3938700

DB Generation Time:  0:00:31.915161

Code:

 Scanning Incrementally (BSGS?! Maybe Meet In The Middle?)

 Current Key Position:  0x8000d693a3e2   Jumps Made:  30
PK Found: 191206974700443
PK Found: 0xade6d7ce3b9b


Search Time:  0:00:01.605224

Total Time:  0:00:01.606917

Not bad. Under 2 seconds to find the key in a 48 bit range. Less than 33 seconds combined with generating the DB.

Testing different versions of the script, I can't get a result in puzzles higher than 42. How are you doing with your modified versions of the script?

How many keys are you generating in your DB?
Are you using OPs github script versions? Or did you make any changes?

[sssergy2705]

How many keys are you generating in your DB?
Are you using OPs github script versions? Or did you make any changes?

Code:

import secp256k1 as ice

def _point_subtraction(pubkey1_bytes, pubkey2_bytes):
    return ice.point_subtraction(pubkey1_bytes, pubkey2_bytes)

def point_subtraction(pubkey1_bytes, pubkey2_bytes):
    res = _point_subtraction(pubkey1_bytes, pubkey2_bytes)
    return bytes(bytearray(res))

target_public_key = "026ecabd2d22fdb737be21975ce9a694e108eb94f3649c586cc7461c8abf5da71a"
target = ice.pub2upub(target_public_key)

num = 2**23 
subtract= 2**10 
subtract_pub= ice.scalar_multiplication(subtract)

with open('data-base.bin', 'wb') as binary_file:
    current_pubkey = target
    byte_accumulator = 0  
    bit_position = 0  

    for _ in range(num):
        current_pubkey = point_subtraction(current_pubkey, subtract_pub)

        binary_data = int(current_pubkey.hex(), 16)

        bit = 0 if str(binary_data).endswith(('0', '2', '4', '6', '8')) else 1

        byte_accumulator = (byte_accumulator << 1) | bit
        bit_position += 1
        if bit_position == 8:
            binary_file.write(byte_accumulator.to_bytes(1, byteorder='big'))
            byte_accumulator = 0
            bit_position = 0

    if bit_position > 0:
        byte_accumulator <<= (8 - bit_position)  
        binary_file.write(byte_accumulator.to_bytes(1, byteorder='big'))

Code:

import multiprocessing
import random
import secp256k1 as ice
from bitstring import BitArray
import psutil
import mmap
def kmp_prefix(pattern):
    prefix_table = [0] * len(pattern)
    j = 0
    for i in range(1, len(pattern)):
        while j > 0 and pattern[i] != pattern[j]:
            j = prefix_table[j - 1]
        if pattern[i] == pattern[j]:
            j += 1
        prefix_table[i] = j
    return prefix_table
def kmp_search(text, pattern, prefix_table):
    j = 0
    for i in range(len(text)):
        while j > 0 and text[i] != pattern[j]:
            j = prefix_table[j - 1]
        if text[i] == pattern[j]:
            j += 1
        if j == len(pattern):
            return i - j + 1
    return -1
def main_task(start, end, file_map):
    prefix_table = kmp_prefix(file_map)
    try:
        while True:
            pk = random.randint(start, end)
            target = ice.scalar_multiplication(pk)
            num = 64 # number of times
            sustract = 2**10  # amount to subtract each time
            sustract_pub = ice.scalar_multiplication(sustract)
            res = ice.point_loop_subtraction(num, target, sustract_pub)
            binary = ''
            for t in range(num):
                h = (res[t * 65:t * 65 + 65]).hex()
                hc = int(h[2:], 16)
                if str(hc).endswith(('0', '2', '4', '6', '8')):
                    binary += "0"
                if str(hc).endswith(('1', '3', '5', '7', '9')):
                    binary += "1"
            my_str = binary
            b = bytes(BitArray(bin=my_str))
            match_position = kmp_search(file_map, b, prefix_table)
            if match_position != -1:
                inx = match_position * sustract
                Pk = (int(pk) + int(inx)) + int(inx) * 7
                print(hex(Pk))
                with open("win45.txt", "a") as data_file:
                    data_file.write("Pk:" + " " + hex(Pk) + "\n")
    except KeyboardInterrupt:
        print("Пpoцecc был пpepвaн пoльзoвaтeлeм")
        return
def worker(start, end, file_map):
    main_task(start, end, file_map)
def split_range(start, end, num_splits):
    step = (end - start) // num_splits
    return [(start + i * step, start + (i + 1) * step) for i in range(num_splits)]
if __name__ == '__main__':
    total_start = 2**44
    total_end = 2**45
    num_physical_cores = psutil.cpu_count(logical=False)
 
    with open("data-base.bin", "r+b") as f:
        file_map = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
        range_splits = split_range(total_start, total_end, num_physical_cores)
        processes = []
        try:
            for start, end in range_splits:
                p = multiprocessing.Process(target=worker, args=(start, end, file_map))
                processes.append(p)
                p.start()
            for p in processes:
                p.join()
        except KeyboardInterrupt:
            print("Ocнoвнoй cкpипт был пpepвaн. Зaвepшeниe вcex пpoцeccoв.")
            for p in processes:
                p.terminate()
                p.join()
            print("Bce пpoцeccы ycпeшнo зaвepшeны.")
        
        file_map.close()

The scripts have changed a little, but the general meaning is the same.
Perhaps I made a mistake somewhere?

[arulbero]

After more script tweaking, I can generate a 20,000,000 key database in less than 10 seconds. Search time less than 2 seconds.

36 Bit Result:

Code:

This is the public key: 02b3e772216695845fa9dda419fb5daca28154d8aa59ea302f05e916635e47b9f6

 Building the Binary Database

 Targeting PubKey:      02b3e772216695845fa9dda419fb5daca28154d8aa59ea302f05e916635e47b9f6
 Number of PubKeys:     20,000,000
 Writing to file every: 20,000,000 keys
 Subtract Value:        1
 Space Covered:        20,000,000 / 0x1312d00

DB Generation Time:  0:00:09.604563


 Scanning Randomly

 Current Random Key:  0x9dd926219   Jumps Made:  291
PK Found: 42387769980
PK Found: 0x9de820a7c


Search Time:  0:00:01.815859

Total Time:  0:00:11.420422

EDIT:  If I use the BitArray option, as in original code, 20,000,000 keys generated into DB takes right at 4 seconds.

Are you using multithreading?  It works only for consecutive keys?

With multithreading and 16 cores, I get 2**24 (16.77M) keys in 4.35 seconds. Non consecutive keys.

EDIT:

multithread (16 cores), 2^25 keys (33.5M) with distance = 16 (using ice.point_loop_subtraction): 5.15 seconds

multithread (16 cores), 2^25 consecutive keys (using ice.point_sequential_decrement): 1.39 seconds

EDIT2:

multithread (16 cores), 2^25 keys (33.5M) with distance = 16 (using ice.point_loop_subtraction): 4.8 seconds

multithread (16 cores), 2^25 consecutive keys (using ice.point_sequential_decrement): 1.06 seconds


EDIT3:

multithread (16 cores), 2^25 keys (33.5M) with distance = 16 (using ice.point_loop_subtraction): 4.67 seconds

multithread (16 cores), 2^25 consecutive keys (using ice.point_sequential_decrement): 0.89 seconds

[mcdouglasx]

Be careful with those who use multithreading to create the db, if you do something wrong and write the bits where they don't belong, they could obtain partially correct keys, such as:


private key = 32685509
private key = 33435509

when you should really get:

target = 33185509

Test your codes first, before believing that it is a false positive when it is really a human error.

[WanderingPhilospher]

EDIT2:

multithread (16 cores), 2^25 keys (33.5M) with distance = 16 (using ice.point_loop_subtraction): 4.8 seconds

multithread (16 cores), 2^25 consecutive keys (using ice.point_sequential_decrement): 1.06 seconds

Wow, impressive!

My results have all been single core. I have not attempted to do anything with multi-core yet.

[arulbero]

EDIT2:

multithread (16 cores), 2^25 keys (33.5M) with distance = 16 (using ice.point_loop_subtraction): 4.8 seconds

multithread (16 cores), 2^25 consecutive keys (using ice.point_sequential_decrement): 1.06 seconds

Wow, impressive!

My results have all been single core. I have not attempted to do anything with multi-core yet.

Then your results are better than mine.

With only 1 cpu in 4 seconds I get around 16.5 M consecutive keys, not 20 M.

[WanderingPhilospher]

EDIT2:

multithread (16 cores), 2^25 keys (33.5M) with distance = 16 (using ice.point_loop_subtraction): 4.8 seconds

multithread (16 cores), 2^25 consecutive keys (using ice.point_sequential_decrement): 1.06 seconds

Wow, impressive!

My results have all been single core. I have not attempted to do anything with multi-core yet.

Then your results are better than mine.

With only 1 cpu in 4 seconds I get around 16.5 M consecutive keys, not 20 M.

That’s probably just because of the different CPUs.

[ElDalmatino]

Hi new to this topic, asking if there is a newer single core script that we can try, than the one in the first post.

[ElonMusk_ia]

Does anyone have C or C++ code to create databases faster?

[whanau]

what is the highest scalar (private key) you have found with this method?
What were your settings?.
Thanks

[studyroom1]

lol tried to even find where is working codes but all seems like chit chat and no solid code are available not even on github

please provide all working codes or update it in github

[ElonMusk_ia]

lol tried to even find where is working codes but all seems like chit chat and no solid code are available not even on github

please provide all working codes or update it in github

I wrote to the OP, but I think he died according to his last post, or maybe he's a troll, I don't know.