Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 241. (Read 229433 times)
but why upto 160
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:
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?
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?
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.
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?
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?
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.
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.
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
is there any page with an overview of ranges that already have been scanned for puzzle #66 without success ? Please point me to the right direction.
http://www.ttdsales.com/66bit/login.phpJust register with anything
and then you can see the progress done in 66-bit.
is there any page with an overview of ranges that already have been scanned for puzzle #66 without success ? Please point me to the right direction.
just ignore this AI bot 
I have found several of these puzzles including the very last one. But I don’t know how to get $ inside of them seriously
Puzzle from 1 to 65 and 70,75,80,85,90,95,100,105,110,115 are SOLVED(all its BTC already taken).Which Bit in the puzzle you claiming you solved it?
I have found several of these puzzles including the very last one. But I don’t know how to get $ inside of them seriously
Hi guys,
In continuation to this thread: https://bitcointalksearch.org/topic/brute-force-on-bitcoin-addresses-video-of-the-action-1305887
While playing around with my bot, I found out this mysterious transaction:
https://blockchain.info/tx/08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15
those 32.896 BTC were sent to multiple addresses, all the private keys of those addresses seem to be generated by some kind of formula.
For example:
Address 2:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU74sHUHy8S
1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb
Biginteger PVK value: 3
Hex PVK value: 3
Address 3:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU76rnZwVdz
19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA
Biginteger PVK value: 7
Hex PVK value: 7
Address 4:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU77MfhviY5
1EhqbyUMvvs7BfL8goY6qcPbD6YKfPqb7e
Biginteger PVK value: 8
Hex PVK value: 8
Address 5:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7Dq8Au4Pv
1E6NuFjCi27W5zoXg8TRdcSRq84zJeBW3k
Biginteger PVK value: 21
Hex PVK value: 15
Address 6:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7Tmu6qHxS
1PitScNLyp2HCygzadCh7FveTnfmpPbfp8
Biginteger PVK value: 49
Hex PVK value: 31
Address 7:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7hDgvu64y
1McVt1vMtCC7yn5b9wgX1833yCcLXzueeC
Biginteger PVK value: 76
Hex PVK value: 4C
Address 8:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU8xvGK1zpm
1M92tSqNmQLYw33fuBvjmeadirh1ysMBxK
Biginteger PVK value: 224
Hex PVK value: E0
Address 9:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUB3vfDKcxZ
1CQFwcjw1dwhtkVWBttNLDtqL7ivBonGPV
Biginteger PVK value: 467
Hex PVK value: 1d3
Address 10:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUBTL67V6dE
1LeBZP5QCwwgXRtmVUvTVrraqPUokyLHqe
Biginteger PVK value: 514
Hex PVK value: 202
Address 11:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUGxXgtm63M
1PgQVLmst3Z314JrQn5TNiys8Hc38TcXJu
Biginteger PVK value: 1155
Hex PVK value: 483
Address 12:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUW5RtS2JN1
1DBaumZxUkM4qMQRt2LVWyFJq5kDtSZQot
Biginteger PVK value: 2683
Hex PVK value: a7b
Address 13:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUspniiQZds
1Pie8JkxBT6MGPz9Nvi3fsPkr2D8q3GBc1
Biginteger PVK value: 5216
Hex PVK value: 1460
Address 14:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFVfZyiN5iEG
1ErZWg5cFCe4Vw5BzgfzB74VNLaXEiEkhk
Biginteger PVK value: 10544
Hex PVK value: 2930
and so on...
until the addresses 50 (1MEzite4ReNuWaL5Ds17ePKt2dCxWEofwk) it was already cracked by someone.
Any ideas what's the formula behind the generation of these addresses?
Address 2, pvk decimal value: 3
Address 3, pvk decimal value: 7
Address 4, pvk decimal value: 8
Address 5, pvk decimal value: 21
Address 6, pvk decimal value: 49
Address 7, pvk decimal value: 76
Address 8, pvk decimal value: 224
Address 9, pvk decimal value: 467
Address 10, pvk decimal value: 514
Address 11, pvk decimal value: 1155
Address 12, pvk decimal value: 2683
Address 13, pvk decimal value: 5216
Address 14, pvk decimal value: 10544
Address 15 and after, pvk decimal value: ?
The prize would be ~32 BTC
EDIT: If you find the solution feel free to leave a tip 1DPUhjHvd2K4ZkycVHEJiN6wba79j5V1u3
i also found this one just now Page #1.4947678577364E+75 out of #2.573157538607E+75 (58.0908%). In continuation to this thread: https://bitcointalksearch.org/topic/brute-force-on-bitcoin-addresses-video-of-the-action-1305887
While playing around with my bot, I found out this mysterious transaction:
https://blockchain.info/tx/08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15
those 32.896 BTC were sent to multiple addresses, all the private keys of those addresses seem to be generated by some kind of formula.
For example:
Address 2:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU74sHUHy8S
1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb
Biginteger PVK value: 3
Hex PVK value: 3
Address 3:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU76rnZwVdz
19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA
Biginteger PVK value: 7
Hex PVK value: 7
Address 4:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU77MfhviY5
1EhqbyUMvvs7BfL8goY6qcPbD6YKfPqb7e
Biginteger PVK value: 8
Hex PVK value: 8
Address 5:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7Dq8Au4Pv
1E6NuFjCi27W5zoXg8TRdcSRq84zJeBW3k
Biginteger PVK value: 21
Hex PVK value: 15
Address 6:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7Tmu6qHxS
1PitScNLyp2HCygzadCh7FveTnfmpPbfp8
Biginteger PVK value: 49
Hex PVK value: 31
Address 7:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7hDgvu64y
1McVt1vMtCC7yn5b9wgX1833yCcLXzueeC
Biginteger PVK value: 76
Hex PVK value: 4C
Address 8:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU8xvGK1zpm
1M92tSqNmQLYw33fuBvjmeadirh1ysMBxK
Biginteger PVK value: 224
Hex PVK value: E0
Address 9:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUB3vfDKcxZ
1CQFwcjw1dwhtkVWBttNLDtqL7ivBonGPV
Biginteger PVK value: 467
Hex PVK value: 1d3
Address 10:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUBTL67V6dE
1LeBZP5QCwwgXRtmVUvTVrraqPUokyLHqe
Biginteger PVK value: 514
Hex PVK value: 202
Address 11:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUGxXgtm63M
1PgQVLmst3Z314JrQn5TNiys8Hc38TcXJu
Biginteger PVK value: 1155
Hex PVK value: 483
Address 12:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUW5RtS2JN1
1DBaumZxUkM4qMQRt2LVWyFJq5kDtSZQot
Biginteger PVK value: 2683
Hex PVK value: a7b
Address 13:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUspniiQZds
1Pie8JkxBT6MGPz9Nvi3fsPkr2D8q3GBc1
Biginteger PVK value: 5216
Hex PVK value: 1460
Address 14:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFVfZyiN5iEG
1ErZWg5cFCe4Vw5BzgfzB74VNLaXEiEkhk
Biginteger PVK value: 10544
Hex PVK value: 2930
and so on...
until the addresses 50 (1MEzite4ReNuWaL5Ds17ePKt2dCxWEofwk) it was already cracked by someone.
Any ideas what's the formula behind the generation of these addresses?
Address 2, pvk decimal value: 3
Address 3, pvk decimal value: 7
Address 4, pvk decimal value: 8
Address 5, pvk decimal value: 21
Address 6, pvk decimal value: 49
Address 7, pvk decimal value: 76
Address 8, pvk decimal value: 224
Address 9, pvk decimal value: 467
Address 10, pvk decimal value: 514
Address 11, pvk decimal value: 1155
Address 12, pvk decimal value: 2683
Address 13, pvk decimal value: 5216
Address 14, pvk decimal value: 10544
Address 15 and after, pvk decimal value: ?
The prize would be ~32 BTC
EDIT: If you find the solution feel free to leave a tip
1DPUhjHvd2K4ZkycVHEJiN6wba79j5V1u3So how secure are satoshi's coins which were mined directly and put in a public address instead of a BTC address.
Because you are saying that reusing addresses is not good because its not as secure but if this was the case why wouldn't this person who is solving all these puzzles for less than <1 BTC instead try and crack Satoshi's early coins which are sitting in all those public key addresses?
I think why its faster is because the search space is much small compared to the entire 128 bit search space, so its still safe to re-use addresses since as far as we know ECDSA hasn't been cracked yet or some exploit found.
Few people deal with this issue, as soon as it is put on stream then This standard ECDSA will quickly split. Because you are saying that reusing addresses is not good because its not as secure but if this was the case why wouldn't this person who is solving all these puzzles for less than <1 BTC instead try and crack Satoshi's early coins which are sitting in all those public key addresses?
I think why its faster is because the search space is much small compared to the entire 128 bit search space, so its still safe to re-use addresses since as far as we know ECDSA hasn't been cracked yet or some exploit found.
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:
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()
I genuinely would like to know .. are any of these python scripts working any faster than known C programs like keyhunt or vanitygen etc? I mean the slowest I've ever seen to date was Brainflayer as it starts with pass->key->...... but to be honest i would be surprised if i see a fast python one getting the same speed as for example keyhunt .. plz post your speed results .. much appreciated
No, no WIF key is generated with a checksum, the correction (checksum) of the key only takes place after the 2nd conversion.. so the output is then correct.. 6 letters from the Wif-key are random, the last 10 letters from this key are range search.
Abstract:
Code:
L = []
while True:
for i in range(0x22000000000000000, 0x3ffffffffffffffff, 0x34fde3761da26c):
b = str(ice.btc_pvk_to_wif(i, True)[:-16])
x = ''.join(random.choices('123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz', k=6))
key_WIF01 = b + x + '1111111111'
key_hex = ice.btc_wif_to_pvk_hex(key_WIF01)
L.append(key_hex)
if len(L) == ..............
Using a chromebook and the python timeit module with (10000) loops.
chromeos@penguin:~$ python3 puzzle.py
18.291343925000092
chromeos@penguin:~$ python3 puzzle.py
18.38286600100014
chromeos@penguin:~$
I would suggest keyhunt or some other program.
The code I posted was a creative example using the python bitcoin module.
chromeos@penguin:~$ python3 puzzle.py
18.291343925000092
chromeos@penguin:~$ python3 puzzle.py
18.38286600100014
chromeos@penguin:~$
I would suggest keyhunt or some other program.
The code I posted was a creative example using the python bitcoin module.
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:
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()
I genuinely would like to know .. are any of these python scripts working any faster than known C programs like keyhunt or vanitygen etc? I mean the slowest I've ever seen to date was Brainflayer as it starts with pass->key->...... but to be honest i would be surprised if i see a fast python one getting the same speed as for example keyhunt .. plz post your speed results .. much appreciated
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:
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()
Good luck
..it depends on the CPU used... I have 3GHz/core... be happy, the faster the better!
but the forum is not for saying "who can run faster"
it's about innovation, ideas to shorten the search... new ways in the programming..
but the forum is not for saying "who can run faster"
it's about innovation, ideas to shorten the search... new ways in the programming..
My CPU is core i5 @ 2.6 GHz.
Anyway if it is about innovation your code doesn't have any of them.
Your way is not the shorten way, and also is not a new way of programing.
You did not reply my question
Your way:
WIF->Private Key->Publickey->Sha256->rmd160->Address.
Why not only?
Publickey->Sha256->rmd160
Skipping the WIF to privatekey and the rmd160 to address you can save a lot of process and speed up your search up to 200% or more... Trust me I already pass for that process.
What I'm trying to write, is that you can do it better, what stop you from that slow speed? You can get a better performance from your current hardware
Jump to: