Well, the code using my strategy still needs something that I can't see now, but just like I saw the pattern with the powers of 2, I'm certain that I will see what's missing for it to be faster.
Currently, I will be working on #130, now that I finally understood how the BSGS works.
Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 159. (Read 215539 times)
what are the parameters to put in place and what codes or tools would be required to achieve that goal mentioned above?
If I had a perfect idea I could have used it myself, I only type what comes to my mind, whether it's possible or doable currently, I don't know. Hints is what I can provide the best.😉
Interesting!! However, in this case, you're not skipping keys; you're transposing the range from 2000:6000 to 1000:3000, which results in the same number of keys.
you avoid keys if you use the pubkey corresponding to pk 2, you would omit the odd private keys.
But there is a way to do the search for public key faster, first you need to subtract as many keys as you can to have a new and ideally small range key, then you could generate +1 billion offsets and -1 billion offsets to keep in a file for auto comparison, then you could use a stride in such a way that each stride never goes beyond 2 billion keys, that way you are certain each stride will definitely have a 100% chance of landing on one of the 2 billion saved public keys.
Now for someone with serious RAM and speed, they can generate +10 & -10 billion keys to check and use a bigger stride to search faster.😉
I am pretty much interested in generating these offsets as explained here, when you speaking of RAM sizes I can get as much as 5 Ekeys/s on BSGS with a good amount of thread too.
We need to know how to start and the BSGS is just an example to give you the understanding of the available RAM.
what are the parameters to put in place and what codes or tools would be required to achieve that goal mentioned above?
Interesting!! However, in this case, you're not skipping keys; you're transposing the range from 2000:6000 to 1000:3000, which results in the same number of keys.
you avoid keys if you use the pubkey corresponding to pk 2, you would omit the odd private keys.
But there is a way to do the search for public key faster, first you need to subtract as many keys as you can to have a new and ideally small range key, then you could generate +1 billion offsets and -1 billion offsets to keep in a file for auto comparison, then you could use a stride in such a way that each stride never goes beyond 2 billion keys, that way you are certain each stride will definitely have a 100% chance of landing on one of the 2 billion saved public keys.
Now for someone with serious RAM and speed, they can generate +10 & -10 billion keys to check and use a bigger stride to search faster.😉
Code:
pk= 1
pub_x= 79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
pub_y= 483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8
pub_dec_x= 55066263022277343669578718895168534326250603453777594175500187360389116729240
pub_dec_y= 32670510020758816978083085130507043184471273380659243275938904335757337482424
These are the standard bitcoin parameters (secp256k1).
# Elliptic curve parameters (secp256k1)
Code:
P = 2**256 - 2**32 - 977
N = 115792089237316195423570985008687907852837564279074904382605163141518161494337
A = 0
B = 7
Gx = 55066263022277343669578718895168534326250603453777594175500187360389116729240
Gy = 32670510020758816978083085130507043184471273380659243275938904335757337482424
G = (Gx, Gy)
Gx & Gy correspond to pubkey from pk #1
if we change these by the pubkey(x,y) of pk #2
Code:
pk= 2
pub_x= c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5
pub_y= 1ae168fea63dc339a3c58419466ceaeef7f632653266d0e1236431a950cfe52a
pub_dec_x= 89565891926547004231252920425935692360644145829622209833684329913297188986597
pub_dec_y= 12158399299693830322967808612713398636155367887041628176798871954788371653930
Code:
P = 2**256 - 2**32 - 977
N = 115792089237316195423570985008687907852837564279074904382605163141518161494337
A = 0
B = 7
Gx = 89565891926547004231252920425935692360644145829622209833684329913297188986597
Gy = 12158399299693830322967808612713398636155367887041628176798871954788371653930
G = (Gx, Gy)
we will get
Code:
pk=1
pub= 02c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5
pk=2
pub= 02e493dbf1c10d80f3581e4904930b1404cc6c13900ee0758474fa94abe8c4cd13
pk=3
pub= 03fff97bd5755eeea420453a14355235d382f6472f8568a18b2f057a1460297556
2, 4, 6....
that's what I mean.
And as for the decrease in the range of the pubkey, I'm on to something, which since you didn't understand before, I prefer to reserve it for the future.
Interesting!! However, in this case, you're not skipping keys; you're transposing the range from 2000:6000 to 1000:3000, which results in the same number of keys.
you avoid keys if you use the pubkey corresponding to pk 2, you would omit the odd private keys.
But there is a way to do the search for public key faster, first you need to subtract as many keys as you can to have a new and ideally small range key, then you could generate +1 billion offsets and -1 billion offsets to keep in a file for auto comparison, then you could use a stride in such a way that each stride never goes beyond 2 billion keys, that way you are certain each stride will definitely have a 100% chance of landing on one of the 2 billion saved public keys.
Now for someone with serious RAM and speed, they can generate +10 & -10 billion keys to check and use a bigger stride to search faster.😉
Interesting!! However, in this case, you're not skipping keys; you're transposing the range from 2000:6000 to 1000:3000, which results in the same number of keys.
you avoid keys if you use the pubkey corresponding to pk 2, you would omit the odd private keys.
Interesting!! However, in this case, you're not skipping keys; you're transposing the range from 2000:6000 to 1000:3000, which results in the same number of keys.
Folks, the focus shouldn't be on how many 1s or 0s bits keys should have; it should be on how to scan faster or how we can skip less probable keys.
If you want to play luck with #66 just change the parameter of the curve.
Code:
Gx = 55066263022277343669578718895168534326250603453777594175500187360389116729240
Gy = 32670510020758816978083085130507043184471273380659243275938904335757337482424
G = (Gx, Gy)
for example pub pk #2 (50-50 of probabilities)
Code:
Gy = 89565891926547004231252920425935692360644145829622209833684329913297188986597
Gy = 12158399299693830322967808612713398636155367887041628176798871954788371653930
G = (Gx, Gy)
or with any other pub to skip certain keys.
Please explain how to modify the parameters of the skip keys curve?
For example, the default parameter in the curve is this:
Code:
Gx = 55066263022277343669578718895168534326250603453777594175500187360389116729240
Gy = 32670510020758816978083085130507043184471273380659243275938904335757337482424
G = (Gx, Gy)
or in hex
Code:
Gx = 79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
Gy = 483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
If we change this to this(pub key corresponding to private key #2):
Code:
Gx = 89565891926547004231252920425935692360644145829622209833684329913297188986597
Gy = 12158399299693830322967808612713398636155367887041628176798871954788371653930
G = (Gx, Gy)
hex
Code:
Gx = C6047F9441ED7D6D3045406E95C07CD85C778E4B8CEF3CA7ABAC09B95C709EE5
Gy = 1AE168FEA63DC339A3C58419466CEAEEF7F632653266D0E1236431A950CFE52A
our search will go from 1,2,3,4,5,6,7..... to 2,4,6,8,10.....
if we want to search for a key in the range
Code:
2000:6000
we divide the range by 2
Code:
1000:3000
if we find the pk in 1024
multiply by 2 and this will be the original pk 2048
we would just skip odds.
if you use the pubkey from pk #3 then it would be sequence 3,6,9,12....
that is, 33.3% probability
Folks, the focus shouldn't be on how many 1s or 0s bits keys should have; it should be on how to scan faster or how we can skip less probable keys.
If you want to play luck with #66 just change the parameter of the curve.
Code:
Gx = 55066263022277343669578718895168534326250603453777594175500187360389116729240
Gy = 32670510020758816978083085130507043184471273380659243275938904335757337482424
G = (Gx, Gy)
for example pub pk #2 (50-50 of probabilities)
Code:
Gy = 89565891926547004231252920425935692360644145829622209833684329913297188986597
Gy = 12158399299693830322967808612713398636155367887041628176798871954788371653930
G = (Gx, Gy)
or with any other pub to skip certain keys.
Please explain how to modify the parameters of the skip keys curve?
Folks, the focus shouldn't be on how many 1s or 0s bits keys should have; it should be on how to scan faster or how we can skip less probable keys.
If you want to play luck with #66 just change the parameter of the curve.
Code:
Gx = 55066263022277343669578718895168534326250603453777594175500187360389116729240
Gy = 32670510020758816978083085130507043184471273380659243275938904335757337482424
G = (Gx, Gy)
for example pub pk #2 (50-50 of probabilities)
Code:
Gy = 89565891926547004231252920425935692360644145829622209833684329913297188986597
Gy = 12158399299693830322967808612713398636155367887041628176798871954788371653930
G = (Gx, Gy)
or with any other pub to skip certain keys.
Using this code below to find the private key for puzzle 30, which specifies that the first 4 bits are 1. Running it with 12 processes on my i7-12700kf, the private key was found in about 1 minute and 28 seconds.
Code:
000000000000000000000000000000000000000000000000000000003d94cd64
hash160: d39c4704664e1deb76c9331e637564c257d68a08
Target hash found!
Time: 0 h, 1 m, 28 s
Code:
import hashlib
import ecdsa
import random
import time
from multiprocessing import Process, Event
target_hash = "d39c4704664e1deb76c9331e637564c257d68a08"
def binary_to_hex(bin_string):
return hex(int(bin_string, 2))[2:].zfill(len(bin_string) // 4)
def worker(num_zeros, num_ones, stop_event):
while True:
if stop_event.is_set():
break
bits = ['0'] * num_zeros + ['1'] * (num_ones - 4)
random.shuffle(bits)
bits.insert(0, '1')
bits.insert(1, '1')
bits.insert(2, '1')
bits.insert(3, '1')
private_key_bin = ''.join(bits)
private_key_bin = '0' * (256 - 30) + private_key_bin
private_key_hex = binary_to_hex(private_key_bin)
sk = ecdsa.SigningKey.from_string(bytes.fromhex(private_key_hex), curve=ecdsa.SECP256k1)
public_key = sk.get_verifying_key().to_string().hex()
compressed_public_key = '02' + public_key[0:64] if int(public_key[-2:], 16) % 2 == 0 else '03' + public_key[0:64]
compressed_public_key_bytes = bytes.fromhex(compressed_public_key)
ripemd160_hash = hashlib.new('ripemd160')
ripemd160_hash.update(hashlib.sha256(compressed_public_key_bytes).digest())
hashed_compressed_public_key = ripemd160_hash.digest().hex()
if hashed_compressed_public_key == target_hash:
print(private_key_hex)
print("hash160:", hashed_compressed_public_key)
print("Target hash found!")
stop_event.set()
break
def main():
num_processes = 12
processes = []
stop_event = Event()
start_time = time.time()
for _ in range(num_processes):
process = Process(target=worker, args=(14, 16, stop_event))
processes.append(process)
for process in processes:
process.start()
for process in processes:
process.join()
if stop_event.is_set():
for process in processes:
process.terminate()
end_time = time.time()
execution_time_seconds = end_time - start_time
hours = int(execution_time_seconds // 3600)
minutes = int((execution_time_seconds % 3600) // 60)
seconds = int(execution_time_seconds % 60)
print(f"Time: {hours} h, {minutes} m, {seconds} s")
if __name__ == '__main__':
main()
I just try it and I can find it in 30 sec on #30. For #66 it's still difficult to scan without GPU.
Try also for #35, #40, or #45.
Scan it in python without GPU too slow for 66 bit. The only way I can figure out now as I previous posted.
Step 1
Let's say start scanning from 60 bits. Use Python to do the combination.
0s - 30 - 1s -30 = 50%
0s - 31 - 1s 29 = 51.67%
0s - 32 - 1s 28 = 53.4%
0s - 33 - 1s 27 = 55%
0s - 34 - 1s 26 = 56.67%
0s - 35 - 1s 25 = 58.34%
0s - 36 - 1s 24 = 60%
Then reverse 0s and 1s position in max 60% which is most likely where the key are.
Step 2
Convert results from Binary to Hexa
Step 3
Make a batch file and run in Bitcrack to use GPU
Step 4
Run until it hits the key or else increase the percentages if it doesn't.
By using Python to eliminate those less like key first, then scan the list with GPU
Pro Python definitely have no problem with it but I'm not pro. Combine pro Python with GPU, I believe the results will be as Bestie said, achievable in 3 days.
Using this code below to find the private key for puzzle 30, which specifies that the first 4 bits are 1. Running it with 12 processes on my i7-12700kf, the private key was found in about 1 minute and 28 seconds.
Code:
000000000000000000000000000000000000000000000000000000003d94cd64
hash160: d39c4704664e1deb76c9331e637564c257d68a08
Target hash found!
Time: 0 h, 1 m, 28 s
Code:
import hashlib
import ecdsa
import random
import time
from multiprocessing import Process, Event
target_hash = "d39c4704664e1deb76c9331e637564c257d68a08"
def binary_to_hex(bin_string):
return hex(int(bin_string, 2))[2:].zfill(len(bin_string) // 4)
def worker(num_zeros, num_ones, stop_event):
while True:
if stop_event.is_set():
break
bits = ['0'] * num_zeros + ['1'] * (num_ones - 4)
random.shuffle(bits)
bits.insert(0, '1')
bits.insert(1, '1')
bits.insert(2, '1')
bits.insert(3, '1')
private_key_bin = ''.join(bits)
private_key_bin = '0' * (256 - 30) + private_key_bin
private_key_hex = binary_to_hex(private_key_bin)
sk = ecdsa.SigningKey.from_string(bytes.fromhex(private_key_hex), curve=ecdsa.SECP256k1)
public_key = sk.get_verifying_key().to_string().hex()
compressed_public_key = '02' + public_key[0:64] if int(public_key[-2:], 16) % 2 == 0 else '03' + public_key[0:64]
compressed_public_key_bytes = bytes.fromhex(compressed_public_key)
ripemd160_hash = hashlib.new('ripemd160')
ripemd160_hash.update(hashlib.sha256(compressed_public_key_bytes).digest())
hashed_compressed_public_key = ripemd160_hash.digest().hex()
if hashed_compressed_public_key == target_hash:
print(private_key_hex)
print("hash160:", hashed_compressed_public_key)
print("Target hash found!")
stop_event.set()
break
def main():
num_processes = 12
processes = []
stop_event = Event()
start_time = time.time()
for _ in range(num_processes):
process = Process(target=worker, args=(14, 16, stop_event))
processes.append(process)
for process in processes:
process.start()
for process in processes:
process.join()
if stop_event.is_set():
for process in processes:
process.terminate()
end_time = time.time()
execution_time_seconds = end_time - start_time
hours = int(execution_time_seconds // 3600)
minutes = int((execution_time_seconds % 3600) // 60)
seconds = int(execution_time_seconds % 60)
print(f"Time: {hours} h, {minutes} m, {seconds} s")
if __name__ == '__main__':
main()
I just try it and I can find it in 30 sec on #30. For #66 it's still difficult to scan without GPU.
Try also for #35, #40, or #45.
Scan it in python without GPU too slow for 66 bit. The only way I can figure out now as I previous posted.
Step 1
Let's say start scanning from 60 bits. Use Python to do the combination.
0s - 30 - 1s -30 = 50%
0s - 31 - 1s 29 = 51.67%
0s - 32 - 1s 28 = 53.4%
0s - 33 - 1s 27 = 55%
0s - 34 - 1s 26 = 56.67%
0s - 35 - 1s 25 = 58.34%
0s - 36 - 1s 24 = 60%
Then reverse 0s and 1s position in max 60% which is most likely where the key are.
Step 2
Convert results from Binary to Hexa
Step 3
Make a batch file and run in Bitcrack to use GPU
Step 4
Run until it hits the key or else increase the percentages if it doesn't.
By using Python to eliminate those less like key first, then scan the list with GPU
Folks, the focus shouldn't be on how many 1s or 0s bits keys should have; it should be on how to scan faster or how we can skip less probable keys.
That's the point right there folk.Before BitCrack was developed do you think people were scanning at the speed we're scanning right now?
Before BitCrack was developed people were only scanning in thousands and million keys/s and even when BitCrack was developed the GPUs available at that time were not as powerful as the ones we have right now. I understand that some projects needs to be funded but the point is that some people here don't see potentials in the logic but I believe these people are also willing to give us better means to solve the puzzles without the exposed public keys because there will be a time when all the public keys stages would have been successfully conquered and we would all be forced to start scanning the stages without the exposed public keys which would be some kind of problem then because we had only chosen to stick to the stages with the exposed pubkeys. Now let us start with making something work. the probability of guessing the 0s and 1s in levels without the pubkeys is much higher than the probability of guessing if puzzle 66 starts with either 2 or 3 because for you to find out if its 2 or 3 you'd have had to scan half of the keyspace and if you're wrong then you'd see that the investment used and time wasted to scan that range alone isn't worth it compared to guessing the 0s and 1s.
I buy the 0s and 1s scanning methodology pretty well but I'd advise we look for a way to make the scan work faster and not only based on CPUs. If we can get the logic to work efficiently well on GPUs, I'm not saying 1 week to scan the level 66,67 and 68 but we can achieve that in 3 days, with the availability of GPUs on demand and it will as well be cost efficient than scanning through all the ranges endlessly
Using this code below to find the private key for puzzle 30, which specifies that the first 4 bits are 1. Running it with 12 processes on my i7-12700kf, the private key was found in about 1 minute and 28 seconds.
Code:
000000000000000000000000000000000000000000000000000000003d94cd64
hash160: d39c4704664e1deb76c9331e637564c257d68a08
Target hash found!
Time: 0 h, 1 m, 28 s
Code:
import hashlib
import ecdsa
import random
import time
from multiprocessing import Process, Event
target_hash = "d39c4704664e1deb76c9331e637564c257d68a08"
def binary_to_hex(bin_string):
return hex(int(bin_string, 2))[2:].zfill(len(bin_string) // 4)
def worker(num_zeros, num_ones, stop_event):
while True:
if stop_event.is_set():
break
bits = ['0'] * num_zeros + ['1'] * (num_ones - 4)
random.shuffle(bits)
bits.insert(0, '1')
bits.insert(1, '1')
bits.insert(2, '1')
bits.insert(3, '1')
private_key_bin = ''.join(bits)
private_key_bin = '0' * (256 - 30) + private_key_bin
private_key_hex = binary_to_hex(private_key_bin)
sk = ecdsa.SigningKey.from_string(bytes.fromhex(private_key_hex), curve=ecdsa.SECP256k1)
public_key = sk.get_verifying_key().to_string().hex()
compressed_public_key = '02' + public_key[0:64] if int(public_key[-2:], 16) % 2 == 0 else '03' + public_key[0:64]
compressed_public_key_bytes = bytes.fromhex(compressed_public_key)
ripemd160_hash = hashlib.new('ripemd160')
ripemd160_hash.update(hashlib.sha256(compressed_public_key_bytes).digest())
hashed_compressed_public_key = ripemd160_hash.digest().hex()
if hashed_compressed_public_key == target_hash:
print(private_key_hex)
print("hash160:", hashed_compressed_public_key)
print("Target hash found!")
stop_event.set()
break
def main():
num_processes = 12
processes = []
stop_event = Event()
start_time = time.time()
for _ in range(num_processes):
process = Process(target=worker, args=(14, 16, stop_event))
processes.append(process)
for process in processes:
process.start()
for process in processes:
process.join()
if stop_event.is_set():
for process in processes:
process.terminate()
end_time = time.time()
execution_time_seconds = end_time - start_time
hours = int(execution_time_seconds // 3600)
minutes = int((execution_time_seconds % 3600) // 60)
seconds = int(execution_time_seconds % 60)
print(f"Time: {hours} h, {minutes} m, {seconds} s")
if __name__ == '__main__':
main()
I just try it and I can find it in 30 sec on #30. For #66 it's still difficult to scan without GPU.
Try also for #35, #40, or #45.
Folks, the focus shouldn't be on how many 1s or 0s bits keys should have; it should be on how to scan faster or how we can skip less probable keys.
Using this code below to find the private key for puzzle 30, which specifies that the first 4 bits are 1. Running it with 12 processes on my i7-12700kf, the private key was found in about 1 minute and 28 seconds.
Code:
000000000000000000000000000000000000000000000000000000003d94cd64
hash160: d39c4704664e1deb76c9331e637564c257d68a08
Target hash found!
Time: 0 h, 1 m, 28 s
Code:
import hashlib
import ecdsa
import random
import time
from multiprocessing import Process, Event
target_hash = "d39c4704664e1deb76c9331e637564c257d68a08"
def binary_to_hex(bin_string):
return hex(int(bin_string, 2))[2:].zfill(len(bin_string) // 4)
def worker(num_zeros, num_ones, stop_event):
while True:
if stop_event.is_set():
break
bits = ['0'] * num_zeros + ['1'] * (num_ones - 4)
random.shuffle(bits)
bits.insert(0, '1')
bits.insert(1, '1')
bits.insert(2, '1')
bits.insert(3, '1')
private_key_bin = ''.join(bits)
private_key_bin = '0' * (256 - 30) + private_key_bin
private_key_hex = binary_to_hex(private_key_bin)
sk = ecdsa.SigningKey.from_string(bytes.fromhex(private_key_hex), curve=ecdsa.SECP256k1)
public_key = sk.get_verifying_key().to_string().hex()
compressed_public_key = '02' + public_key[0:64] if int(public_key[-2:], 16) % 2 == 0 else '03' + public_key[0:64]
compressed_public_key_bytes = bytes.fromhex(compressed_public_key)
ripemd160_hash = hashlib.new('ripemd160')
ripemd160_hash.update(hashlib.sha256(compressed_public_key_bytes).digest())
hashed_compressed_public_key = ripemd160_hash.digest().hex()
if hashed_compressed_public_key == target_hash:
print(private_key_hex)
print("hash160:", hashed_compressed_public_key)
print("Target hash found!")
stop_event.set()
break
def main():
num_processes = 12
processes = []
stop_event = Event()
start_time = time.time()
for _ in range(num_processes):
process = Process(target=worker, args=(14, 16, stop_event))
processes.append(process)
for process in processes:
process.start()
for process in processes:
process.join()
if stop_event.is_set():
for process in processes:
process.terminate()
end_time = time.time()
execution_time_seconds = end_time - start_time
hours = int(execution_time_seconds // 3600)
minutes = int((execution_time_seconds % 3600) // 60)
seconds = int(execution_time_seconds % 60)
print(f"Time: {hours} h, {minutes} m, {seconds} s")
if __name__ == '__main__':
main()
I just try it and I can find it in 30 sec on #30. For #66 it's still difficult to scan without GPU.
Quote
Using this code below to find the private key for puzzle 30, which specifies that the first 4 bits are 1. Running it with 12 processes on my i7-12700kf, the private key was found in about 1 minute and 28 seconds.
Of course, it's just trying my luck. But who isn't trying their luck for hunters who don't have a lot of gpu? I believe that any other tool used by each of us hunters with only a small amount of resources is using random mode to search for private keys, so why not rule out some combinations with lower probability to try some private keys with higher probability?
Using this code below to find the private key for puzzle 30, which specifies that the first 4 bits are 1. Running it with 12 processes on my i7-12700kf, the private key was found in about 1 minute and 28 seconds.
Of course, it's just trying my luck. But who isn't trying their luck for hunters who don't have a lot of gpu? I believe that any other tool used by each of us hunters with only a small amount of resources is using random mode to search for private keys, so why not rule out some combinations with lower probability to try some private keys with higher probability?
Code:
000000000000000000000000000000000000000000000000000000003d94cd64
hash160: d39c4704664e1deb76c9331e637564c257d68a08
Target hash found!
Time: 0 h, 1 m, 28 s
Code:
import hashlib
import ecdsa
import random
import time
from multiprocessing import Process, Event
target_hash = "d39c4704664e1deb76c9331e637564c257d68a08"
def binary_to_hex(bin_string):
return hex(int(bin_string, 2))[2:].zfill(len(bin_string) // 4)
def worker(num_zeros, num_ones, stop_event):
while True:
if stop_event.is_set():
break
bits = ['0'] * num_zeros + ['1'] * (num_ones - 4)
random.shuffle(bits)
bits.insert(0, '1')
bits.insert(1, '1')
bits.insert(2, '1')
bits.insert(3, '1')
private_key_bin = ''.join(bits)
private_key_bin = '0' * (256 - 30) + private_key_bin
private_key_hex = binary_to_hex(private_key_bin)
sk = ecdsa.SigningKey.from_string(bytes.fromhex(private_key_hex), curve=ecdsa.SECP256k1)
public_key = sk.get_verifying_key().to_string().hex()
compressed_public_key = '02' + public_key[0:64] if int(public_key[-2:], 16) % 2 == 0 else '03' + public_key[0:64]
compressed_public_key_bytes = bytes.fromhex(compressed_public_key)
ripemd160_hash = hashlib.new('ripemd160')
ripemd160_hash.update(hashlib.sha256(compressed_public_key_bytes).digest())
hashed_compressed_public_key = ripemd160_hash.digest().hex()
if hashed_compressed_public_key == target_hash:
print(private_key_hex)
print("hash160:", hashed_compressed_public_key)
print("Target hash found!")
stop_event.set()
break
def main():
num_processes = 12
processes = []
stop_event = Event()
start_time = time.time()
for _ in range(num_processes):
process = Process(target=worker, args=(14, 16, stop_event))
processes.append(process)
for process in processes:
process.start()
for process in processes:
process.join()
if stop_event.is_set():
for process in processes:
process.terminate()
end_time = time.time()
execution_time_seconds = end_time - start_time
hours = int(execution_time_seconds // 3600)
minutes = int((execution_time_seconds % 3600) // 60)
seconds = int(execution_time_seconds % 60)
print(f"Time: {hours} h, {minutes} m, {seconds} s")
if __name__ == '__main__':
main()
Quote
Using this code below to find the private key for puzzle 30, which specifies that the first 4 bits are 1. Running it with 12 processes on my i7-12700kf, the private key was found in about 1 minute and 28 seconds.
Of course, it's just trying my luck. But who isn't trying their luck for hunters who don't have a lot of gpu? I believe that any other tool used by each of us hunters with only a small amount of resources is using random mode to search for private keys, so why not rule out some combinations with lower probability to try some private keys with higher probability?
Quote
Just start to scan from 50-50, 51-49, 52-48 and so on and it will save a lot of time and unnecessary scan from the beginning of useless less likely range.
The key is how to write code to run the specified 0 and 1 digits on the gpu.
Also, I think that there is a high probability that the hexadecimal number of the private key for puzzle 66 starts with 3. That is, the highest 2 bits of the binary private key we can both set to 1, and we can specify the number of bits for 0s and 1s, and we can even search for less than just 2^63 private keys if we use bits with a probability of more than 40%! Of course, this is an extreme case, using too many coincidences.
If we continue to exclude combinations with negligible probability, such as 10 consecutive 0's or 1's, then the search space will be further reduced.
Step 1
Let's say start scanning from 60 bits. Coding in Python.
0s - 30 - 1s -30 = 50%
0s - 31 - 1s 29 = 51.67%
0s - 32 - 1s 28 = 53.4%
0s - 33 - 1s 27 = 55%
0s - 34 - 1s 26 = 56.67%
0s - 35 - 1s 25 = 58.34%
0s - 36 - 1s 24 = 60%
Then reverse 0s and 1s position in max 60% which is most likely where the key are.
Step 2
Convert Binary to Hexa
Step 3
Print in .CMD for continuous execution in Bitcrack.
Step 4
Run until it hits the key or else increase the percentages if it doesn't.
Make sense?
Quote
Just start to scan from 50-50, 51-49, 52-48 and so on and it will save a lot of time and unnecessary scan from the beginning of useless less likely range.
The key is how to write code to run the specified 0 and 1 digits on the gpu.
Also, I think that there is a high probability that the hexadecimal number of the private key for puzzle 66 starts with 3. That is, the highest 2 bits of the binary private key we can both set to 1, and we can specify the number of bits for 0s and 1s, and we can even search for less than just 2^63 private keys if we use bits with a probability of more than 40%! Of course, this is an extreme case, using too many coincidences.
If we continue to exclude combinations with negligible probability, such as 10 consecutive 0's or 1's, then the search space will be further reduced.
You don't write it in GPU. Just write it in Python, print it in CMD and automate it in Bitcrack. Then the whole thing transfered to GPU already with Bitcrack.
Jump to: