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

[mcdouglasx]

Has anyone compared this with the bsgs version that I updated? It would be interesting.

[WanderingPhilospher]

Has anyone compared this with the bsgs version that I updated? It would be interesting.

For the script you have posted, without any tinkering, I imagine the DB creation (same as this script) and the search, will be slower at lower bits.

Looking at the script, there's no way to tell progress, etc.

I like your DB idea, the search part needs to be implemented into a different language to speed it up.

ON a funny note, I had a false positive with the script, even at 64. It ran for about 30 hours, so I guess after you check so many keys, even the 64 will give you a false positive lol.

Quick tweak to script and ran the DB generation part. For 20,000,000 keys:

creating Baby Step

DB Generation Time:  0:00:08.942671

Ran a 32 bit search (changed out your random start point because that seemed counterintuitive, especially since it could be higher than the priv key):

Code:

Found the Baby Steps Table file: baby_steps__binary.bin. Will be used directly
Checking 400000000000000 keys from 0x1
BSGS FOUND PrivateKey  : 3093472813
Time Spent : 21.40 seconds

I ran another test, 36 bit with 60,000,000 keys.
I also changed the k value (start) to k = start (0x800000000, start of 36 bit range) - m (number of keys, since they are consecutive).

Code:

creating Baby Step

DB Generation Time:  0:00:25.307935

Code:

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

Search is super slow right now. Not even close to the other search script with same amount of generated keys.  At some bit, I am sure the BSGS would outperform the other search script.

[mcdouglasx]

Has anyone compared this with the bsgs version that I updated? It would be interesting.

For the script you have posted, without any tinkering, I imagine the DB creation (same as this script) and the search, will be slower at lower bits.

Looking at the script, there's no way to tell progress, etc.

I like your DB idea, the search part needs to be implemented into a different language to speed it up.

ON a funny note, I had a false positive with the script, even at 64. It ran for about 30 hours, so I guess after you check so many keys, even the 64 will give you a false positive lol.

Quick tweak to script and ran the DB generation part. For 20,000,000 keys:

creating Baby Step

DB Generation Time:  0:00:08.942671

The question is not based on the speed of creating the database, it is fixed with C and if you do not want to investigate in C, at least some dll that will do the job for you using ctypes, in my few tests I noticed that searching for bsgs is a lot faster than in normal search like here, and yes with cm 64 you could find false positives for every 8bits 256 possible combinations and then it becomes exponential which could be more likely an error when you create your database a few bits more or less what they change everything, you deduce this if the pk obtained partially matches the one you are looking for, this would definitely be a failure in the creation of the database and not a false positive, so I recommend saving those "false positives" because if it is a bug in your database you could be a few jumps below or above the target.

[WanderingPhilospher]

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.

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

[WanderingPhilospher]

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?

[mcdouglasx]

Has anyone compared this with the bsgs version that I updated? It would be interesting.

Code:

Found the Baby Steps Table file: baby_steps__binary.bin. Will be used directly
Checking 400000000000000 keys from 0x1
BSGS FOUND PrivateKey  : 3093472813
Time Spent : 21.40 seconds

You are doing something wrong, my results on intel i5 4gb ddr3.

BSGS FOUND PrivateKey  : 3093472813
Time Spent : 0.25 seconds

[WanderingPhilospher]

Has anyone compared this with the bsgs version that I updated? It would be interesting.

Code:

Found the Baby Steps Table file: baby_steps__binary.bin. Will be used directly
Checking 400000000000000 keys from 0x1
BSGS FOUND PrivateKey  : 3093472813
Time Spent : 21.40 seconds

You are doing something wrong, my results on intel i5 4gb ddr3.

BSGS FOUND PrivateKey  : 3093472813
Time Spent : 0.25 seconds

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.

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

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

[mcdouglasx]

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.

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