7isce
Jr. Member
Offline
Activity: 61
Merit: 6
|
|
November 02, 2022, 08:29:09 AM |
|
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.
|
|
|
|
Evillo
Member
Offline
Activity: 185
Merit: 15
Two things you should never abandon: Family & BTC
|
|
November 02, 2022, 09:16:20 AM |
|
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.
|
Cool Story Bro. BTC: 1EviLLo1Y5VeNn2Lajv9tdZTkUuVgePVYN
|
|
|
Ynotcleta
Newbie
Offline
Activity: 8
Merit: 0
|
|
November 26, 2022, 08:23:18 PM |
|
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
Member
Offline
Activity: 185
Merit: 15
Two things you should never abandon: Family & BTC
|
|
November 26, 2022, 11:32:56 PM |
|
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.
|
Cool Story Bro. BTC: 1EviLLo1Y5VeNn2Lajv9tdZTkUuVgePVYN
|
|
|
Evillo
Member
Offline
Activity: 185
Merit: 15
Two things you should never abandon: Family & BTC
|
|
December 08, 2022, 01:22:42 AM |
|
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: 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. 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?
|
Cool Story Bro. BTC: 1EviLLo1Y5VeNn2Lajv9tdZTkUuVgePVYN
|
|
|
warui
Newbie
Offline
Activity: 2
Merit: 0
|
|
December 09, 2022, 08:58:44 AM |
|
but why upto 160
|
|
|
|
citb0in
|
|
December 11, 2022, 07:15:20 PM |
|
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%
|
_______. ______ __ ______ ______ __ ___ .______ ______ ______ __ ______ .______ _______ / | / __ \ | | / __ \ / || |/ / | _ \ / __ \ / __ \ | | / __ \ | _ \ / _____| | (----`| | | | | | | | | | | ,----'| ' / | |_) | | | | | | | | | | | | | | | | |_) | | | __ \ \ | | | | | | | | | | | | | < | ___/ | | | | | | | | | | | | | | | / | | |_ | .----) | | `--' | | `----.| `--' | __| `----.| . \ | | | `--' | | `--' | | `----.__| `--' | | |\ \----.| |__| | |_______/ \______/ |_______| \______/ (__)\______||__|\__\ | _| \______/ \______/ |_______(__)\______/ | _| `._____| \______| | 2% fee anonymous solo bitcoin mining for all at https://solo.CKpool.org | No registration required, no payment schemes, no pool op wallets, no frills, no fuss. |
|
|
|
|
citb0in
|
|
December 11, 2022, 07:36:15 PM |
|
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. 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.
|
_______. ______ __ ______ ______ __ ___ .______ ______ ______ __ ______ .______ _______ / | / __ \ | | / __ \ / || |/ / | _ \ / __ \ / __ \ | | / __ \ | _ \ / _____| | (----`| | | | | | | | | | | ,----'| ' / | |_) | | | | | | | | | | | | | | | | |_) | | | __ \ \ | | | | | | | | | | | | | < | ___/ | | | | | | | | | | | | | | | / | | |_ | .----) | | `--' | | `----.| `--' | __| `----.| . \ | | | `--' | | `--' | | `----.__| `--' | | |\ \----.| |__| | |_______/ \______/ |_______| \______/ (__)\______||__|\__\ | _| \______/ \______/ |_______(__)\______/ | _| `._____| \______| | 2% fee anonymous solo bitcoin mining for all at https://solo.CKpool.org | No registration required, no payment schemes, no pool op wallets, no frills, no fuss. |
|
|
|
|
andiu9999
Newbie
Offline
Activity: 74
Merit: 0
|
|
December 15, 2022, 05:57:03 PM |
|
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
|
|
December 15, 2022, 07:19:26 PM Last edit: December 15, 2022, 07:37:54 PM by 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: ('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 __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: __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
I get 0.21194690400443505 when running the original mandelbrot code and 2.2377483489981387 when commenting the "from numba import jit" and "@jit..." lines.
|
_______. ______ __ ______ ______ __ ___ .______ ______ ______ __ ______ .______ _______ / | / __ \ | | / __ \ / || |/ / | _ \ / __ \ / __ \ | | / __ \ | _ \ / _____| | (----`| | | | | | | | | | | ,----'| ' / | |_) | | | | | | | | | | | | | | | | |_) | | | __ \ \ | | | | | | | | | | | | | < | ___/ | | | | | | | | | | | | | | | / | | |_ | .----) | | `--' | | `----.| `--' | __| `----.| . \ | | | `--' | | `--' | | `----.__| `--' | | |\ \----.| |__| | |_______/ \______/ |_______| \______/ (__)\______||__|\__\ | _| \______/ \______/ |_______(__)\______/ | _| `._____| \______| | 2% fee anonymous solo bitcoin mining for all at https://solo.CKpool.org | No registration required, no payment schemes, no pool op wallets, no frills, no fuss. |
|
|
|
|
saxydev
|
|
December 26, 2022, 07:48:18 PM |
|
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
|
|
December 26, 2022, 08:12:30 PM |
|
either you scan through the whole range which is time and ressource consuming or you take the short-cut
|
_______. ______ __ ______ ______ __ ___ .______ ______ ______ __ ______ .______ _______ / | / __ \ | | / __ \ / || |/ / | _ \ / __ \ / __ \ | | / __ \ | _ \ / _____| | (----`| | | | | | | | | | | ,----'| ' / | |_) | | | | | | | | | | | | | | | | |_) | | | __ \ \ | | | | | | | | | | | | | < | ___/ | | | | | | | | | | | | | | | / | | |_ | .----) | | `--' | | `----.| `--' | __| `----.| . \ | | | `--' | | `--' | | `----.__| `--' | | |\ \----.| |__| | |_______/ \______/ |_______| \______/ (__)\______||__|\__\ | _| \______/ \______/ |_______(__)\______/ | _| `._____| \______| | 2% fee anonymous solo bitcoin mining for all at https://solo.CKpool.org | No registration required, no payment schemes, no pool op wallets, no frills, no fuss. |
|
|
|
|
Evillo
Member
Offline
Activity: 185
Merit: 15
Two things you should never abandon: Family & BTC
|
|
December 27, 2022, 06:16:27 AM |
|
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?
|
Cool Story Bro. BTC: 1EviLLo1Y5VeNn2Lajv9tdZTkUuVgePVYN
|
|
|
saxydev
|
|
December 27, 2022, 06:38:18 AM |
|
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
Member
Offline
Activity: 185
Merit: 15
Two things you should never abandon: Family & BTC
|
|
December 27, 2022, 08:15:53 PM |
|
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
|
Cool Story Bro. BTC: 1EviLLo1Y5VeNn2Lajv9tdZTkUuVgePVYN
|
|
|
ProjectSe7en
Jr. Member
Offline
Activity: 59
Merit: 1
|
|
December 28, 2022, 09:45:06 PM |
|
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/brainflayeryour_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
|
|
December 28, 2022, 11:36:40 PM |
|
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!
|
I am available for hiring. Avatar and Signature available for rent. Donations: bc1qjyhcjacmpc9pg8wes82lktyrjcwk4sdvqtm7ky
|
|
|
ProjectSe7en
Jr. Member
Offline
Activity: 59
Merit: 1
|
|
December 29, 2022, 01:15:22 AM |
|
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
|
|
January 08, 2023, 08:30:57 AM Last edit: January 10, 2023, 04:30:49 PM by 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. 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()
|
Look over there...
|
|
|
JamesH1453
Newbie
Offline
Activity: 1
Merit: 0
|
|
January 11, 2023, 12:32:31 PM |
|
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: 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. 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: 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
|
|
|
|
|