Pages:
Author

Topic: lightweight database, for brute force using publickeys-32Mk =3.81MB(secp256k1) (Read 2625 times)

jr. member
Activity: 46
Merit: 10
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.

He's not dead, he's been posting in this thread:  https://bitcointalksearch.org/topic/m.64634546
member
Activity: 122
Merit: 36
newbie
Activity: 23
Merit: 2
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.
jr. member
Activity: 40
Merit: 7
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
member
Activity: 122
Merit: 36
what is the highest scalar (private key) you have found with this method?
What were your settings?.
Thanks
newbie
Activity: 23
Merit: 2
Does anyone have C or C++ code to create databases faster?
jr. member
Activity: 53
Merit: 11
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.
full member
Activity: 1162
Merit: 237
Shooters Shoot...
Quote
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.

legendary
Activity: 1932
Merit: 2077
Quote
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.
full member
Activity: 1162
Merit: 237
Shooters Shoot...
Quote
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.
member
Activity: 239
Merit: 53
New ideas will be criticized and then admired.
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.
legendary
Activity: 1932
Merit: 2077
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
copper member
Activity: 205
Merit: 1
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?
full member
Activity: 1162
Merit: 237
Shooters Shoot...
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?
copper member
Activity: 205
Merit: 1
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?
full member
Activity: 1162
Merit: 237
Shooters Shoot...
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.

member
Activity: 239
Merit: 53
New ideas will be criticized and then admired.
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.
member
Activity: 873
Merit: 22
$$P2P BTC BRUTE.JOIN NOW ! https://uclck.me/SQPJk
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 Wink Your binary DB is real good. Thank you very mach  for your binary DB !!!
member
Activity: 873
Merit: 22
$$P2P BTC BRUTE.JOIN NOW ! https://uclck.me/SQPJk
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 ?))
full member
Activity: 1162
Merit: 237
Shooters Shoot...
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

Pages:
Jump to: