Bitcoin puzzle transaction ~32 BTC prize to who solves it

[7isce]

Well, thanks for the link. However I am not interested in pool bruteforcing because I don't like the idea to possibly receive nothing although invested hard work into finding the correct key (range). The idea is good but the software/pool used therefore is something centralized and I consider it as bad. Sorry, just my 2 satoshis. However, thanks for the link

You are Welcome,
We have same opinion for this pool(They miss the 64-bit when they nearly scan 1/4 of range).
I working in divide the range and search it randomly, and if you like me then I don't think knowing range that scanned will be helpful because the will be always high change he/she will miss the key. its random after all.

[1715390846]

1715390846

[1715390846]

1715390846

[Evillo]

Well, thanks for the link. However I am not interested in pool bruteforcing because I don't like the idea to possibly receive nothing although invested hard work into finding the correct key (range). The idea is good but the software/pool used therefore is something centralized and I consider it as bad. Sorry, just my 2 satoshis. However, thanks for the link

You are Welcome,
We have same opinion for this pool(They miss the 64-bit when they nearly scan 1/4 of range).
I working in divide the range and search it randomly, and if you like me then I don't think knowing range that scanned will be helpful because the will be always high change he/she will miss the key. its random after all.

True .. Random search won't have to worry about finished ranges .. why? Because maths! All private keys residing in the 66 bit range are so many that even stumbling upon a certain already-searched range randomly is probabilistically too low .. it's easy to realize this when you visualize the randomized range .. in fact, it's the same exact reason why you are searching billions of keys everyday and still not finding the desired private key .. it's the massive amount of keys cluttering the space that makes meeting the same key (or subrange for that matter) highly unlikely. So yeah, you can search comfortably randomly and not worry about meeting an already searched range.

[Ynotcleta]

I get the same performance as you, but EC_POINT_add isn't the slowest step, it's the call to EC_POINT_point2oct.

So what if I am a newbie just glance at please?

x = int('11db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5c, 16) y = int('b2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3', 16)

point = ecdsa.ellipticcurve.Point(SECP256k1.curve, x, y) pubkey = Verifyingkey.from public point(point, SECP256k1)

def verify signature(hash, signature):

17 global pubkey

return pubkey.pubkey.verifies(hash, signature)

Do you know why EC_POINT_point2oct is slow? I called EC_POINT_get_affine_coordinates_GFp instead, but they seem to do the same thing. If EC_POINT_add stores the point in Cartesian coordination (X-Y), will extracting the public key be a trivial task?

Guys with brute force we won't go anywhere.

How precise is this formula?

I think all of us know that brute force is not viable for sure, but it is fun to estimate how long it will take to break the 51st, 52nd, ... addresses.

That division isn't the conventional division. It has perfect precision (http://www.johannes-bauer.com/compsci/ecc/#anchor07).

Well we wont get 5 TH/s or anything close for sure, but if we were able to generate 100 million keys per second we would break the #51 in about 3.5 months... And I believe it will be very hard to get to 100 million / s even with GPU.

Yes of course we can try it for the fun, but it wont be much fun when you get home and your GPU is burning plus your electricity bill

But of course if your formula brings down the range of keys to generate then we can have some chance.

So, basically I was wrong because we have to calculate λ to add the two points.

If you find the right formula can you post the results for each address so we know exactly what ranges we can count with?

[Evillo]

I get the same performance as you, but EC_POINT_add isn't the slowest step, it's the call to EC_POINT_point2oct.

So what if I am a newbie just glance at please?

x = int('11db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5c, 16) y = int('b2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3', 16)

point = ecdsa.ellipticcurve.Point(SECP256k1.curve, x, y) pubkey = Verifyingkey.from public point(point, SECP256k1)

def verify signature(hash, signature):

17 global pubkey

return pubkey.pubkey.verifies(hash, signature)

Do you know why EC_POINT_point2oct is slow? I called EC_POINT_get_affine_coordinates_GFp instead, but they seem to do the same thing. If EC_POINT_add stores the point in Cartesian coordination (X-Y), will extracting the public key be a trivial task?

Guys with brute force we won't go anywhere.

How precise is this formula?

I think all of us know that brute force is not viable for sure, but it is fun to estimate how long it will take to break the 51st, 52nd, ... addresses.

That division isn't the conventional division. It has perfect precision (http://www.johannes-bauer.com/compsci/ecc/#anchor07).

Well we wont get 5 TH/s or anything close for sure, but if we were able to generate 100 million keys per second we would break the #51 in about 3.5 months... And I believe it will be very hard to get to 100 million / s even with GPU.

Yes of course we can try it for the fun, but it wont be much fun when you get home and your GPU is burning plus your electricity bill

But of course if your formula brings down the range of keys to generate then we can have some chance.

So, basically I was wrong because we have to calculate λ to add the two points.

If you find the right formula can you post the results for each address so we know exactly what ranges we can count with?

Lol it's entertaining to imagine those days when people thought 100mil keys per sec was impossible to get .. a good 8g GPU now can you over 600 mil keys per sec thanks to some great tools available like Bitcrack and programs inspired by vanity search.

[Evillo]

I cannot get your @jolly_jocker code to run correctly.

However, I think what you are trying to achieve is using the known WIF key part and tumble searching the remaining characters to find the WIF private key. I am able to again, use the known key part and add a randomize search for the remaining part and output this in hexadecimal format. It is not any faster than a general hexadecimal search.

I am not sure if you can generate a WIF private key with a check sum and convert/compare ; and then print the WIF key again in the same script.
I do agree that this puzzle is about testing the strength and secure-ness of bitcoin with new, creative code.

This is a basic python script and variation of VanityGen:

Code:

import secrets
import base58
import binascii
from bitcoin import privtopub, pubtoaddr
import sys

vanity = "13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so"
btc_addr = ""

while btc_addr[:len(vanity)] != vanity:
    prefix = "KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qa"
    alphabet = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
    postfix = ''.join(secrets.choice(alphabet) for i in range(18))
    first_encode = base58.b58decode(prefix + postfix)
    private_key_full = binascii.hexlify(first_encode)
    private_key = private_key_full[2:-8]
    btc_pubkey = privtopub(private_key.decode())
    btc_addr = pubtoaddr(btc_pubkey)
    
print(private_key.decode())
print(btc_pubkey)
print(btc_addr)

sys.exit()

Hello, Thanks for all your posts !
I modified your script a little, so that it loads the database of all BTC addresses plus searches for puzzle patterns at the same time.

Code:

import os
import time
import secrets
import base58
import binascii
from bitcoin import privtopub, pubtoaddr
import sys
import multiprocessing
from halo import Halo
import random, string
import threading

print("Loading TXT Please Wait and Good Luck...")  
filename ='list.txt'
with open(filename) as f:
    add = f.read().split()
add = set(add)

spinner = Halo(text='Loading', spinner='dots')

r = 0
cores=1 #CPU Control Set Cores
def seek(r):
        F = []
        while True: 
            prefix = "KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qa"
            alphabet = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
            postfix = ''.join(secrets.choice(alphabet) for i in range(18))
            first_encode = base58.b58decode(f'{prefix}{postfix}')
            private_key_full = binascii.hexlify(first_encode)
            private_key = private_key_full[2:-8]
            btc_pubkey = privtopub(private_key.decode())
            btc_addr = pubtoaddr(btc_pubkey)
            spinner.start()
              
            if btc_addr.startswith("13zb1"):
               t = time.ctime()
               spinner.stop()
               print("Pattern Found:",t, btc_addr, private_key) 
               print("\n continue...\n")
               spinner.start()

            if btc_addr in add:
               t = time.ctime()
               spinner.stop()
               print("Winner Found!:",t, btc_addr, private_key)  
               f=open(u"Winner.txt","a") #Output File
               f.write('WIF private key: ' + str(private_key) + '\n' +
                            'public key: ' + str(btc_pubkey) + '\n' +
                            'BTC address: ' + str(btc_addr) + '\n\n')
               f.close()
               sleep(1)
               break

#CPU Control Command
if __name__ == '__main__':
        os.system('clear')
        t = time.ctime()
        print(t, "GOOD LUCK AND HAPPY HUNTING...") 
        
        jobs = []
        for r in range(cores):
                p = multiprocessing.Process(target=seek, args=(r,))
                jobs.append(p)
                p.start()

Cool thanks .. Can you test speed and post results for us?

[warui]

but why upto 160

[citb0in]

are you sure this will run on GPU? I quickly tested it and I see only 1 CPU thread being used at 100% for the program. There is absolutely no GPU utilization, GPU = 0%

[citb0in]

I understand, but I don't believe only numbers in output so I always do cross-checking. I ran your CPU/GPU comparison benchmark program and I ran your latest GPU version for puz66. None of them show GPU utilization on my system so I am puzzled.

Just take your CPU/GPU benchmark program and remove the CPU part. Now raise n to a higher number and you will always get immediate results when executing the program, regardless of n value. That is impossible.

Code:

import os
os.environ['CUDA_VISIBLE_DEVICES'] = "0"
import numpy as np
import numba
from numba import cuda, jit
from timeit import default_timer as timer
from fastecdsa import keys, curve
import secp256k1 as ice
# Run on GPU
numba.jit()
def gpu(x):
    dec   = keys.gen_private_key(curve.P256)
    HEX   = "%064x" % dec
    wifc  = ice.btc_pvk_to_wif(HEX)
    wifu  = ice.btc_pvk_to_wif(HEX, False)
    uaddr = ice.privatekey_to_address(0, False, dec)
    caddr = ice.privatekey_to_address(0, True, dec)
    return x+1
if __name__=="__main__":
    n = 100000000
    a = np.ones(n, dtype = np.float64)
    start = timer()
    gpu(a)
    numba.cuda.profile_stop()
    print("with GPU:", timer()-start)

when you re-run the same command line you will get different result. I am also not sure if it's correct to have float64 used here, possibly it could throw some error when reaching the limits for allocating for the array.

[andiu9999]

Hi, anyone can help me split the range for 66 bitcoin address on 64 small ranges- 0x20000000000000000 - 0x3FFFFFFFFFFFFFFFF  and to use with clbitcrack? i havce some hardware and is not the best but i get around 5 mkey/s with each. if anyone can help a i want give a try and if i found it i will give a bounty to person who help

[citb0in]

Hi, anyone can help me split the range for 66 bitcoin address on 64 small ranges- 0x20000000000000000 - 0x3FFFFFFFFFFFFFFFF  and to use with clbitcrack? i havce some hardware and is not the best but i get around 5 mkey/s with each. if anyone can help a i want give a try and if i found it i will give a bounty to person who help

Hi andiu9999,

here you go:

Code:

('0x20000000000000000', '0x20800000000000000')
('0x20800000000000000', '0x21000000000000000')
('0x21000000000000000', '0x21800000000000000')
('0x21800000000000000', '0x22000000000000000')
('0x22000000000000000', '0x22800000000000000')
('0x22800000000000000', '0x23000000000000000')
('0x23000000000000000', '0x23800000000000000')
('0x23800000000000000', '0x24000000000000000')
('0x24000000000000000', '0x24800000000000000')
('0x24800000000000000', '0x25000000000000000')
('0x25000000000000000', '0x25800000000000000')
('0x25800000000000000', '0x26000000000000000')
('0x26000000000000000', '0x26800000000000000')
('0x26800000000000000', '0x27000000000000000')
('0x27000000000000000', '0x27800000000000000')
('0x27800000000000000', '0x28000000000000000')
('0x28000000000000000', '0x28800000000000000')
('0x28800000000000000', '0x29000000000000000')
('0x29000000000000000', '0x29800000000000000')
('0x29800000000000000', '0x2A000000000000000')
('0x2A000000000000000', '0x2A800000000000000')
('0x2A800000000000000', '0x2B000000000000000')
('0x2B000000000000000', '0x2B800000000000000')
('0x2B800000000000000', '0x2C000000000000000')
('0x2C000000000000000', '0x2C800000000000000')
('0x2C800000000000000', '0x2D000000000000000')
('0x2D000000000000000', '0x2D800000000000000')
('0x2D800000000000000', '0x2E000000000000000')
('0x2E000000000000000', '0x2E800000000000000')
('0x2E800000000000000', '0x2F000000000000000')
('0x2F000000000000000', '0x2F800000000000000')
('0x2F800000000000000', '0x30000000000000000')
('0x30000000000000000', '0x30800000000000000')
('0x30800000000000000', '0x31000000000000000')
('0x31000000000000000', '0x31800000000000000')
('0x31800000000000000', '0x32000000000000000')
('0x32000000000000000', '0x32800000000000000')
('0x32800000000000000', '0x33000000000000000')
('0x33000000000000000', '0x33800000000000000')
('0x33800000000000000', '0x34000000000000000')
('0x34000000000000000', '0x34800000000000000')
('0x34800000000000000', '0x35000000000000000')
('0x35000000000000000', '0x35800000000000000')
('0x35800000000000000', '0x36000000000000000')
('0x36000000000000000', '0x36800000000000000')
('0x36800000000000000', '0x37000000000000000')
('0x37000000000000000', '0x37800000000000000')
('0x37800000000000000', '0x38000000000000000')
('0x38000000000000000', '0x38800000000000000')
('0x38800000000000000', '0x39000000000000000')
('0x39000000000000000', '0x39800000000000000')
('0x39800000000000000', '0x3A000000000000000')
('0x3A000000000000000', '0x3A800000000000000')
('0x3A800000000000000', '0x3B000000000000000')
('0x3B000000000000000', '0x3B800000000000000')
('0x3B800000000000000', '0x3C000000000000000')
('0x3C000000000000000', '0x3C800000000000000')
('0x3C800000000000000', '0x3D000000000000000')
('0x3D000000000000000', '0x3D800000000000000')
('0x3D800000000000000', '0x3E000000000000000')
('0x3E000000000000000', '0x3E800000000000000')
('0x3E800000000000000', '0x3F000000000000000')
('0x3F000000000000000', '0x3F800000000000000')
('0x3F800000000000000', '0x40000000000000000')

donations are always welcome   just open my user profile and you'll find my BTC address there  

It won't work until numba -s shows

Code:

__CUDA Information__
Found 1 CUDA devices
id 0      b'GeForce GTX 970'   [SUPPORTED]
compute capability: 5.2
pci device id: 0
pci bus id: 1

which will confirm whether you have a functioning CUDA  or not.

well, it seems that my GPU is supported, cannot see any issue here:

Code:

$ numba -s

__CUDA Information__
CUDA Device Initialized                       : True
CUDA Driver Version                           : 11.8
CUDA Runtime Version                          : 11.8
CUDA NVIDIA Bindings Available                : False
CUDA NVIDIA Bindings In Use                   : False
CUDA Detect Output:
Found 1 CUDA devices
id 0    b'NVIDIA GeForce RTX 3070 Laptop GPU'                              [SUPPORTED]
                      Compute Capability: 8.6
                           PCI Device ID: 0
                              PCI Bus ID: 1
                                    UUID: GPU-27a2b515-798b-e33d-89f8-d679eec4ab47
                                Watchdog: Enabled
             FP32/FP64 Performance Ratio: 32
Summary:
   1/1 devices are supported

CUDA Libraries Test Output:
Finding nvvm from System
   named  libnvvm.so.4.0.0
   trying to open library...   ok
Finding cudart from System
   named  libcudart.so.11.8.89
   trying to open library...   ok
Finding cudadevrt from System
   named  libcudadevrt.a
Finding libdevice from System
   trying to open library...   ok

Try to generate mandelbrot without GPU

https://numba.pydata.org/numba-doc/dev/user/examples.html#mandelbrot

0.3226363949943334 seconds with GPU
90 seconds with CPU

I get 0.21194690400443505 when running the original mandelbrot code and 2.2377483489981387 when commenting the "from numba import jit" and "@jit..." lines.

[saxydev]

For half a year I use my cpu to scan for the #67 puzzle. I am 0.000039% scanned addresses of the range ;( A lifetime more to wait. I wonder how many supercomputers out there scan the bitcoin chain for these keys every minute. If you remember the pipeline hack, the FBI had already the privkey for the address used and it was not obtain during a hack or seize.

[citb0in]

either you scan through the whole range which is time and ressource consuming or you take the short-cut 

[Evillo]

For half a year I use my cpu to scan for the #67 puzzle. I am 0.000039% scanned addresses of the range ;( A lifetime more to wait. I wonder how many supercomputers out there scan the bitcoin chain for these keys every minute. If you remember the pipeline hack, the FBI had already the privkey for the address used and it was not obtain during a hack or seize.

But Why the 67th puzzle ?.. why not the easier one? I mean the amount of private keys in 66 is unbelievably enormous already .. why go for the double of that gigantic range?

[saxydev]

For half a year I use my cpu to scan for the #67 puzzle. I am 0.000039% scanned addresses of the range ;( A lifetime more to wait. I wonder how many supercomputers out there scan the bitcoin chain for these keys every minute. If you remember the pipeline hack, the FBI had already the privkey for the address used and it was not obtain during a hack or seize.

But Why the 67th puzzle ?.. why not the easier one? I mean the amount of private keys in 66 is unbelievably enormous already .. why go for the double of that gigantic range?

It's all about luck isn't it? Everyone is on the 66th puzzle. I just wanted to go on a different one. And the mining power cost is arround 15-20$ a month, I don't even feel it or me being disturbed about it.

[Evillo]

For half a year I use my cpu to scan for the #67 puzzle. I am 0.000039% scanned addresses of the range ;( A lifetime more to wait. I wonder how many supercomputers out there scan the bitcoin chain for these keys every minute. If you remember the pipeline hack, the FBI had already the privkey for the address used and it was not obtain during a hack or seize.

But Why the 67th puzzle ?.. why not the easier one? I mean the amount of private keys in 66 is unbelievably enormous already .. why go for the double of that gigantic range?

It's all about luck isn't it? Everyone is on the 66th puzzle. I just wanted to go on a different one. And the mining power cost is arround 15-20$ a month, I don't even feel it or me being disturbed about it.

The factor that you're forgetting here is "probability" .. when you target the 67th, you are basically cutting your probability of being lucky in half .. I'm just saying, but you can do whatever you want of course

[ProjectSe7en]

Anyone knows a C program that can convert hexadecimal integer like "0000000000000000000000000000000000000000000000000000f7051f27b09112d4" to hash 160 or btc address, but from a text file or better in parallel in bash?

The only one I've found something similar is brainlayer https://github.com/ryancdotorg/brainflayer

your_generator | brainflayer -v -b example.blf

But it doesn't have multithread, and it's not as fast as others.

Thank you, happy holidays, and greetings. 

[albert0bsd]

But it doesn't have multithread, and it's not as fast as others.

The problem with multithread is that the output can be in different order than the Input file, if that doesn't matter to your output then it is OK.

Why you only need the output address or rmd hash ?

Regards!

[ProjectSe7en]

But it doesn't have multithread, and it's not as fast as others.

The problem with multithread is that the output can be in different order than the Input file, if that doesn't matter to your output then it is OK.

Why you only need the output address or rmd hash ?

Regards!

Doesn't matter cause it's for:

Experimental purposes with different languages and scripts, learn many more!!!, and have fun with the impossible luck.

BTW, my DM inbox is open.

Thanks for reply!

[The_Prof]

It is slow compared to ICE secp256k1. Twice the speed...However, I am currently creating a script that will be Full ICE - to search for lost parts of the private key. About 2 million per second per CPU thread..

I would love to see your 2 mil/sec as I am stuck on 500k/s with ice. Would be interested to see which route you went.

Edit: 2 mil+... CPU dependent. But that is on a public key hunt. So for those who want to try their luck.... It's set for 120 bit key...I guess if you link enough machines with enough CPU's you may hit in a few hundred years.

Code:

import secp256k1 as ice
from timeit import default_timer as timer
import random
import multiprocessing

cores = 1
perRound = 1000000
bitRange = 120
target_Key = '02ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a2630'
    
def new_Number():
    doneSet = set()
    rotate = True
    with open("120-Nums.txt", "r+") as textfile:  
        for checking in textfile: doneSet.add(str(checking.replace("\n","").replace(",", "")))
        while rotate != False:
            number = round(random.randint(2**(bitRange-1),2**bitRange)/perRound)
            if str(number) not in doneSet:
                rotate = False
                textfile.write(str(number) + "\n") 
            if str(number) in doneSet:
                print('Collision')
    textfile.close()
    return number

def seek(r,cores):
    startStart = timer()
    dog = False
    while dog != True:
        number = new_Number()
        p = (ice.scalar_multiplication(number*perRound))
        start = timer()
        check = str((ice.point_sequential_increment(perRound, p)).hex())
        if target_Key[5:25] in check:
            print('Success: ' + str(number))
            print('Test Run Time Length: ' + str((timer()-startStart))[:6])
            with open("results.txt", "a") as completed:
                completed.write(str(p) + '   ' + str(number)) 
            completed.close()
            dog = True
        else:
            print('Core: ' + str(r) + '   Key/s: ' + str(perRound/(timer()-start))[:10]  + '   Time: ' + str(timer()-start)[:6] + '   RandInt: ' + str(number))

if __name__ == '__main__':
    jobs = []
    for r in range(cores):
        p = multiprocessing.Process(target=seek, args=(r,cores))
        jobs.append(p)
        p.start()

[JamesH1453]

I cannot get your @jolly_jocker code to run correctly.

However, I think what you are trying to achieve is using the known WIF key part and tumble searching the remaining characters to find the WIF private key. I am able to again, use the known key part and add a randomize search for the remaining part and output this in hexadecimal format. It is not any faster than a general hexadecimal search.

I am not sure if you can generate a WIF private key with a check sum and convert/compare ; and then print the WIF key again in the same script.
I do agree that this puzzle is about testing the strength and secure-ness of bitcoin with new, creative code.

This is a basic python script and variation of VanityGen:

Code:

import secrets
import base58
import binascii
from bitcoin import privtopub, pubtoaddr
import sys

vanity = "13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so"
btc_addr = ""

while btc_addr[:len(vanity)] != vanity:
    prefix = "KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qa"
    alphabet = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
    postfix = ''.join(secrets.choice(alphabet) for i in range(18))
    first_encode = base58.b58decode(prefix + postfix)
    private_key_full = binascii.hexlify(first_encode)
    private_key = private_key_full[2:-8]
    btc_pubkey = privtopub(private_key.decode())
    btc_addr = pubtoaddr(btc_pubkey)
    
print(private_key.decode())
print(btc_pubkey)
print(btc_addr)

sys.exit()

Hello, Thanks for all your posts !
I modified your script a little, so that it loads the database of all BTC addresses plus searches for puzzle patterns at the same time.

Code:

import os
import time
import secrets
import base58
import binascii
from bitcoin import privtopub, pubtoaddr
import sys
import multiprocessing
from halo import Halo
import random, string
import threading

print("Loading TXT Please Wait and Good Luck...")  
filename ='list.txt'
with open(filename) as f:
    add = f.read().split()
add = set(add)

spinner = Halo(text='Loading', spinner='dots')

r = 0
cores=1 #CPU Control Set Cores
def seek(r):
        F = []
        while True: 
            prefix = "KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qa"
            alphabet = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
            postfix = ''.join(secrets.choice(alphabet) for i in range(18))
            first_encode = base58.b58decode(f'{prefix}{postfix}')
            private_key_full = binascii.hexlify(first_encode)
            private_key = private_key_full[2:-8]
            btc_pubkey = privtopub(private_key.decode())
            btc_addr = pubtoaddr(btc_pubkey)
            spinner.start()
              
            if btc_addr.startswith("13zb1"):
               t = time.ctime()
               spinner.stop()
               print("Pattern Found:",t, btc_addr, private_key) 
               print("\n continue...\n")
               spinner.start()

            if btc_addr in add:
               t = time.ctime()
               spinner.stop()
               print("Winner Found!:",t, btc_addr, private_key)  
               f=open(u"Winner.txt","a") #Output File
               f.write('WIF private key: ' + str(private_key) + '\n' +
                            'public key: ' + str(btc_pubkey) + '\n' +
                            'BTC address: ' + str(btc_addr) + '\n\n')
               f.close()
               sleep(1)
               break

#CPU Control Command
if __name__ == '__main__':
        os.system('clear')
        t = time.ctime()
        print(t, "GOOD LUCK AND HAPPY HUNTING...") 
        
        jobs = []
        for r in range(cores):
                p = multiprocessing.Process(target=seek, args=(r,))
                jobs.append(p)
                p.start()

HI
after run code:

Code:

Wed Jan 11 16:00:39 2023 GOOD LUCK AND HAPPY HUNTING...
⠙ LoadingProcess Process-1:
Traceback (most recent call last):
  File "/usr/lib/python3.8/multiprocessing/process.py", line 315, in _bootstrap
    self.run()
  File "/usr/lib/python3.8/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "ffff.py", line 32, in seek
    btc_pubkey = privtopub(private_key.decode())
  File "/usr/local/lib/python3.8/dist-packages/bitcoin/main.py", line 294, in privkey_to_pubkey
    raise Exception("Invalid privkey")
Exception: Invalid privkey