 Show Posts
|
|
Pages: [1] 2 3 »
|
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()
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: 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) == ..............
|
|
|
|
Speed test with 4 cores: [ Speed : 301444.62 Keys/s ]
the calculation takes place one after the other, not at the same time, which would take time...
I can get the same speed with only one core using my code ..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.. |
|
|
|
I have 16 available cores each capable of 4.5 GHz but I get only 1,186,383.53 Keys/s when running your code. When I check utilization in top or htop I see there are only about 4 cores utilized at 100% but even then I would have expected higher rate. Anything I'm missing ?
I'm using secp256k1 from iceland2k14. When I manually set core for instance to "15" it utilizes 15 cores, but I would have expected that the cpu_count enumeration had worked. Seems it didn't, despite that ... With 15 cores I can achieve 2003121.42 Keys/s that is 2 MKey/s. You said you're achieving 600 MKey/s, how do you do that with CPU only? Wouldn't it be better to utilize GPU for such things?
You are confusing something, I achieve the 600 MKeys/s with the GPU and not with this code... for this code a CPU is working with 3 GHz/core.. |
|
|
|
They're relentless already. Check out NVIDIA's "Hybrid Quantum-Classical Computing Platform" .. and "cuQuantum SDK"
WOW! Thanks a lot for this information... THUMBS UP! |
|
|
|
I wish we would have any quantum computing students or gurus here to discuss how many Qubits we need to break as much as 66 bits .. I'm guessing around 1000-3000 at most .. Quantum computing is amazingly useful when it comes to cryptography.
The "quantum leap" will come one day for us too, i'm confident at Nvidia, they are constantly working on the further development of their processors.. let's take a look at the developer cards... the computing power is overwhelming and will certainly continue to increase. Sure, it's not a comparison to the quantum computer... but but... |
|
|
|
'....it's better after dividing the big range into smaller ones, to search within those subranges "randomly"'.
That's what I do.... that's exactly how I work..  I'm not a newbie in this matter.... But better with 600 MKeys/s than not looking for it at all... ^^ |
|
|
|
Yes and No ..
Yes, it does inspire to find solutions. After all, that's how humans evolved. Being Incredibly curious is what gave us the competitive advantage over all other creatures. However, it's very important to know what you're dealing with before raising hopes high. Puzzle #66 is 72 million trillion private keys.. and this means you're gonna encounter tons and tons of prefixes and only one of them is the right one. Trying to make a statistical analysis out of these is like trying to find a similar pattern across the whole universe. You are looking for only one Earth among too many Goldilock zone Earths in the Cosmos. There will be no pattern leading you to it. You just have to brute force your way through planets until you find that exact one Earth. No mathematical formula will get you there. Sure it can lead you to many Earth-like planets, but it doesn't find your exact desired Earth.
That being said, we don't even have to find a pattern in order to reach the private key, we only have to keep searching long enough until we find it, just like #64 got solved by keeping at it. In fact, it blew me away that within the exact month i thought we were never gonna solve it, someone solves it and proves me wrong. Nothing is impossible when it comes to luck and randomness. But then again, Luck and randomness do not get predicted, and that's why they're the only way to beat huge numbers. I'm so grateful they exist
yes, we are looking for a logarithm, a clue.. a system in the structure... but the hash is so sophisticated that the patterns like 13zb1hQ... don't repeat themselves regularly... but you can still scan for system... divide the entire range into smaller areas and based on the addresses already found, a certain start/end point enclose. Of course, this should also be enjoyed with caution... ^^ "The route is the goal"... I scan with more than 600 MKeys/s and, as I said, I divided the range into smaller areas... it's still a matter of luck... because I can't scan the entire area, the computing power is far from sufficient for that... . Nonetheless, good luck! |
|
|
|
And the main feature of sha256 hex pvt key that makes it secure in the first place is, once you change even one letter in (input) string, the entire hex output changes! This works both way, if you change the output (the sha256 32 byte) , the input will be hugely different. And to make things even harder, that's just one hash function, now let's continue the process of generating the address: we're doing ripemd of the sha256 of the resulting pub key to get the address .. By design, this means that whatever comes out as an address will change significantly after all that hashing we went through. This means that you can have trillions and trillions of addresses starting with 13zb1hQ.... Spread around the entire 256 bit range leaving you with the fact that none of them is the exact address you're looking for. Someone then might ask then why would we search by prefix instead of addresses?! The answer is simple: it's way faster to look for part of the address. That's the only advantage. But It doesn't say anything about determining the range.
Thanks for the detail... but the people who program themselves and work with hashes know that.. But that's not the content of the "statement".. It only represents the difficulty of the search for the target address.. seen in this way, the difficulty is the incentive.. it inspires, it brings new ideas to the programming, new ways to solve the problem... |
|
|
|
[2022-10-01.14:26:29] [Info] Address : 13zb1hQbWMzfvBudo1G28SjrDjwpcY8PA9
Private key : 319AFC93A46A34462
Compressed : yes
Public key : 03BA713FDDD4D0E475A60D3057F2E33B18A50B40827EF3728B4EE9E86C444D23C5
It's not just about the beginning of the address... There are tons of those... more about the similarities between the beginning and the end of the address.. 13zb1hQbwfhhEryPWBrAioLY5tiFLr hs5o |
|
|
|
my guess. it should be above this one,
00000000000000000000000000000000000000000000000319AFC9E3FF391B01
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3q > ZsnspiitMKGTKUxzXus
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3q > (a) something
ripemd -- 20D45A6A76AEB187FB6E669463E929D7072AB330
13zb1hQbwfhhEryPWBrAioLY5tiFLrhs5o
If you look at how many addresses start with "13zb1hQ..", that's to despair! There are areas where there are significantly more... that makes it difficult to narrow down the range.. A good example of this was the 64-bit range, which was assumed to be in the middle of this range... unfortunately it was totally wrong ^^ |
|
|
|
Puzzle 66... ( 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so )That's a mockery ....!    13zb1hQbwfhhEryPWBrAioLY5tiFLr hs5o - 0x319AFC9E3FF391B01
|
|
|
|
Will it work with Python?
If "NO" - perhaps there is an option for working with Python?
This code is programmed in Python 3.x ... You need this for this code as import.. https://github.com/iceland2k14/secp256k1 |
|
|
|
Sorry, what exactly is happening in this?
Another form of random with "FLOAT" That's actually quite simple.. the 64-bit area is divided into decimal places. From 0.000001 to 1.000000 captures the entire range.. The size of the steps is set using the decimal places. This can be varied, the more decimal places, the smaller/finer the steps... |
|
|
|
BTC FLOAT SCAN #64 another way of scanning.. import time
import random
import secp256k1 as ice
from time import sleep
t = time.ctime()
print('',t)
print('\n\n * BTC FLOAT SCAN #64 *\n')
print('\n |=========CURRENT===LINE=========||=====CNT====||=FLOAT=||=LOOP=|\n\n')
sleep(1)
print(' scanning...',end='\r')
def range_with_floats(start, stop, step):
while stop > start:
yield start
start += step
a=9223372036854775807
b=9223372036854775808
#=========================================
c = 1000000
d = 3846
group_size = c
#=========================================
e = 0.0000031115691002
f = 1.0000000000000000
g = 0.000001
#=========================================
total=0
loop=0
for x in range_with_floats(e, f, g):
loop += 1
for i in range(d):
x += 0.00026
xx = x
x1 = int(a * x + b)
key_int = x1
P = ice.scalar_multiplication(key_int)
current_pvk = key_int + 1
Pv = ice.point_sequential_increment(group_size, P)
for t in range(group_size):
this_btc = ice.pubkey_to_address(0, True, Pv[t*65:t*65+65])
total+=1
if this_btc.startswith('16jY7'): # 16jY7q
print(' ',hex(current_pvk+t)[2:],(this_btc)[:12] + '... ',str(total).zfill(12),'','{0:.5f}'.format(xx),'',str(loop).zfill(6),end='\r')
if this_btc == '16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN':
file=open(u"BTC.Target.Info.txt","a")
file.write('\n ' + this_btc + ' | ' + hex(current_pvk+t))
file.close()
sleep(1)
exit()
P = Pv[-65:]
current_pvk += group_size
|
|
|
|
Thank u brother.
Have you checked which address type the codes you have written give you? compressed? not compressed?
I'm new to this puzzle. but
For 4 years I started to think that's why puzzle 64 was not solved.
You're welcome! all addresses we are looking for are compressed... |
|
|
|
hi my friend, i want to ask you a private question but i can't dm you because i am a new member. i need a code to search in the range i want. The codes here are only for puzzle 64 and I can't edit spacing.
I want to search by typing the range I want between these two ranges, with the range 0 to 115792089237316195423570985008687907853269984665640564039457584007913129639935. I'll be glad, if you help me.
kötü ingilizcem için özür dilerim.
The range for 64 bit is 9223372036854775808 to 18446744073709551615 this is easy to show.. an example for it: use this web-calculator https://web2.0rechner.de/and just enter 2^64 for 64bit 2^66 for 66bit.. etc.. greetings! |
|
|
|
User 'Jolly Jocker' has not chosen to allow messages from newbies. You should post in their relevant thread to remind them to enable this setting.
been trying to pm you. please do the needful so i can pm you
Sorry, I overlooked that in the settings..  I have changed it, so it's now possible.. sorry again!!  |
|
|
|
Hi, I have been using a couple of your codes that you have posted here and your ideas are very fascinating, I have become a big fan of yours. i found a code on github and i am very excited to show you, my hope on this share is that you might come up with your own way to improve the code effency in a way that it can be used for puzzle 66 and 69. i hope that you would share the improved version if this code i would greatly appreciate it if you would. so here is the link:- https://github.com/Isaacdelly/Plutusi hope to hear from you, will be waiting in anticipation to a positive response hey hey shelby0930!! A big thanks for your nice words, this gives me impetus for new projects in the future!  A small tool for you personally.!! Happy hunting!! XD For more infos and link, send me PM.. greetings Jolly! |
|
|
|
it takes a while.. with more than 730030 entries XD
Why does it take time? There are so many ways to get it in a very short time. For example you could find a block explorer with an API that lets you search and fetch hashes with block height then get them from 0 to 730,030. Or you could download and run a SPV client like Electrum, let it sync for a minute to download the blockchain_headers file which is currently about 55 MB (it also verifies headers) then just read that data file 80 bytes at a time and hash that to get each block hash within seconds. So basically the time it takes for you to construct such a list should be roughly the same as the time it takes you download 55 MB from the internet. the tool works in the background, doesn't need any computing power, creates a list for me from 0 - xxxxxx .. so everything is fine... i like to program and that's why i created the tool... Thanks anyway!! |
|
|
|
Is anyone else interested in a list of block hashes (BTC)? I can make a list available in the next few days, I wrote a little tool to read in.. 0000000004db6bc621f87b60eaf55d0069e415c431bf2c5a3e566b5e6f318998 CNT: 66154
000000000067fb57b70c3f233170c735db3bf97d8ec3c7938a051e8d577720d6 CNT: 66155
000000000008690ada906f8939342df2969006dcb6be0979ece32d2428a8b24e CNT: 66156
0000000000513a50edcfbc8fdf297717dfa20a9632d259362b0eab999036fabc CNT: 66157
0000000003681f0db1699deeaec4715b70dffbf4c47c1ec8aa512d8616562a2f CNT: 66158
0000000004cb66ebb55280e54a730f02a75fee4cc739735612e4e9a4e84f7f06 CNT: 66159
0000000007f57bf898e28c4bfdaa6faedd77e338e8975ea8ceae8e41df8805f2 CNT: 66160
0000000002da8e2bc6e9471c2ab2a1a765dcebf9cfdd756d9d5c9b768f817857 CNT: 66161
00000000006de5a14a9ba858143849da12e5e1ab5559065ea8de7d70e0f72642 CNT: 66162
0000000002c22ac0e55c0c3ffb1cb7d3a0d1be98729840a04e0f992315ba94dc CNT: 66163
000000000040457e7d373d0a8936d95a1ea735bbd722744c93e263b33d6cb106 CNT: 66164
0000000009e8f6727fc03bb98180b2b207625f6be0abf034606cdbab234a2f00 CNT: 66165
00000000042fd6149efc75225860dbc3cd423b8c90d6b2be5edb70d1eab23075 CNT: 66166
000000000a289819e3864dcb5ddf2e571434de73bf7cc45a00c119278be7427a CNT: 66167
0000000003531f64f33542446ed64bf7256703cebd232054ed80a6e64f7951a4 CNT: 66168
0000000005b65d76fa80f53fc50c4dd2ab9ba2b849fda780153318f867d86b38 CNT: 66169
000000000930008a87441840c023ce50e99b79c74f18d120582cefbc47e76143 CNT: 66170
0000000001f8239143e2f8b7e151da5ebdd40931e4eea0290a83f5704676893a CNT: 66171
0000000006504dbcd0d41503e4e7df03016b05356f84bf00fa5c69728de3a0cd CNT: 66172
000000000871168470edeb66409d7a4d01dc17f3edcccf9f5c78a6a1d0e7d0d5 CNT: 66173
000000000893b45721f43f5d317656ab6b82ac76ddaf543976648c7714344eea CNT: 66174
0000000003341f718be514e885e7c0c14c66ccbc67e40e791b3311456a560370 CNT: 66175
000000000007198d2fa784855d2f0d1d0fbfb4d987cdf22c1d5826ac7fc9e5eb CNT: 66176
...........
it takes a while.. with more than 730030 entries XD |
|
|
|
|
