Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 41. (Read 193352 times)

Thank you, colleagues, for suggesting Rust and C  , but for educational purposes, what is specifically required is Python code for CUDA that can brute-force keys.

if you like the maximum possible speed than you need to go for C. This is primarily because C is a compiled language, while Python is an interpreted language. That means C code is compiled directly into machine code, which can be executed directly by the computer's hardware. On the other hand, Python code is interpreted, meaning that it's translated into bytecode by the Python interpreter and executed line by line at runtime. Additionally Python utilizes automatic memory management via garbage collection which can introduce overhead.

Frankly speaking, go for C if you like to achieve the best performnce. While C tends to be faster than Python in terms of raw performance, Python offers advantages such as ease of use. And as already mentioned, Rust is also interesting because it combines the performance of languages like C with the safety and concurrency features of modern languages.

It is 20 times faster in Rust  then Python/Numba

https://github.com/Rust-GPU/Rust-CUDA

https://github.com/Rust-GPU/Rust-CUDA/blob/master/guide/src/guide/getting_started.md


But there is a 0 puzzle script written in Rust.
There is this one here as an example
https://bitcointalksearch.org/topic/m.63539973

Then 1000 billion keys a second would take one year (31,536,000 seconds) ?

For educational purposes. Can anyone provide Python code for iterating through private keys in a specified range that works with CUDA? Or a link to such a resource.
Thank you.

Obviously not, this was just my wishful thinking when I had less experience ⬇


I hope Tepan has some new idea

Has anyone ever figured out what the #64 and #120 keys were, up to now?

i already make some display looks clean and more likely like your display codes on terminal



i'll send the python files, i hope you can help me , thanks!

Yes, perhaps I have the world's highest number of prefixes for puzzle66.
And maybe I have conducted the most experiments on prefixes worldwide, whether it be in the form of base58 or hash160.
Through these experiments, I have consistently encountered a 50-50 probability of outcomes.
Sometimes, a few bytes of a private key match, and at other times, they do not match at all.
So, there is no difference between a 'private keys with matched prefixes' and a 'totally random private keys'.
I save addresses with prefixes only as a 'proof of work'; beyond that, these addresses serve no further purpose.

If your objective is solely to locate addresses with matching prefixes, it would be advisable to opt for the vanity search implemented by WanderingPhilosopher, which is based on multi-GPU counting, rather than attempting to enhance speed in Python, which never ever compete with GPU-counting.

Edit :

---

Anyway, I have scanned about 6.5% of puzzle 66 keys individually, I need your best wishes, and a lot of good wishes from my side to all of you.

it is more likely to find a privatekey-publickey pattern
than a pattern between privatekey-h160.
For mathematical reasons, pubkeys are in their most "basic" section a residue of P, so you could go in scale reducing the search range where you get more matches.
This is a vague idea of a possible search.

Wow I just did the math to see how long it would really take if you went from start to finish with no stride for puzzle 66
With the start and end params of 20000000000000000...3ffffffffffffffff and a 3080 at 1100 MKeys/s or 1.1 billion keys a second
I got
33,539,534,679 seconds
558,992,244 minutes
9,316,537 hours
388,189 days
1,063 years

no, i'm not hesitant to share my codes, because don't have much time, i know what i'm working on it clearly someone’s has been done before.
 i'll dm you and zahid888, soon.

Tepan, you seem hesitant to share your code, but trust me, what you are doing has already been done, in a much faster programming language, C++; CPU and GPU versions, where you can provide a h160 or address prefix and it will find EVERY collision in a 40 bit range, in less than a minute (depending on GPU setup).

Your python script may have some different settings/search criteria, but the bottom line is the same.

People are trying to help you speed up your code, in python, because your code is extremely slow. If your python code isn't checking at least 250,000 keys per second, then it desperately needs an overhaul. I can create a python script to do what yours is doing, that will check at least 250,000 keys per second, python only, single core, in less than 10 minutes.

But hey, you do you.

Zahid888, is the expert at prefix searches...probably has the world's largest prefix database, he can attest to what I am saying to you.

Sure, I'll see what else i can do to improve your code.

sure, i'll dm you, btw your codes looks cool and more advanced!
wow!, i'm beginner can you teach ?!

#EDIT
from my codes provide chance to find the 66 puzle is on 3000000000000000:37fffffffffffffff , below that it's just give same result hash and different 13zb1 address derived from private key. (but it's just speculation.)

Can i take a look at your code ?

>> test.py 18ZRLg9BMfAg9WYVWqVDtYdT59QV1PzrJe 18Z 52ea8235174b368df646576fc04eb0d2737057b6 1a000000000000000 1afffffffffffffff

000000000000000000000000000000000000000000000001a6f7e55277418662 | Hash 160 52ffb5fad1e2964e0d62d0fb1fba1b2a51959602 | 18ZrjqFukCHggGmF9NHvTHnypz8CWUiesG | 600.90 sec |
000000000000000000000000000000000000000000000001a698bf0141abba89 | Hash 160 52faf3bd9c45c9788dd66c1c3247b9861149342c | 18Zm3BwAm4CNym3KuUUZu3n3vytQ6TXRoU | 700.29 sec |
000000000000000000000000000000000000000000000001a61adda168bf1479 | Hash 160 5304d1f3f9a3e5d191a70656b8cd49f242d91e8e | 18ZxrqALETxJS5eQ834BD8xdLBuLzDztqA | 700.61 sec |
000000000000000000000000000000000000000000000001a64271593ec75f14 | Hash 160 52df324fdd87f86fb67bd415db3fd3c63d70d5a2 | 18ZBnhRYcHxdw4fSDByCb7tMqnCA1n9UxC | 700.87 sec |
000000000000000000000000000000000000000000000001a678bde0e606d586 | Hash 160 52ea8235174b368df646576fc04eb0d2737057b6 | 18ZRLg9BMfAg9WYVWqVDtYdT59QV1PzrJe | 800.39 sec |
000000000000000000000000000000000000000000000001a7d696f300cda2fc | Hash 160 52db4611541a1d382a06279c0a32b45bd1a0bf2b | 18Z768mmb7LCGDjU5xsF5YtPiSvRo5pVvR | 900.63 sec |
Similar hash160 found: 52ea8235174b368df646576fc04eb0d2737057b6

=========[Address Found]===========
Private Key: 000000000000000000000000000000000000000000000001a678bde0e606d586
Hash 160: 52ea8235174b368df646576fc04eb0d2737057b6
Address: 18ZRLg9BMfAg9WYVWqVDtYdT59QV1PzrJe
0x1a678bde0e606d586
Compressed Public Key: 02f46cb94bfecf5daf63cd54353c73eb3f7e148ac0f9b8af46e3a94ee8b60e1260
Time taken to find: 0.0000 seconds
Speed of keys: 0.0000 keys per second
=========[Address Found]===========

thankyou for advice, i make the KNN algorithm work with my previous code but have some trouble with other codes, some confusion call the rest codes to work with scan range, but it's work.
i test on 65 bit.

mightbe push my luck for 66 for couple weeks.

I think you could figure out the probability before scanning any range, especially the first x amount of leading characters/"prefixes". A rough, but close estimate.

Take the range size, say 2^40, and merely divide by the size of leading characters (in bits). So if you are wondering about the h160 prefix, "20cb78", and consider each position/character 4 bits, so 6 characters x 4 = 24 bits.

Then in a range size of 2^40, you would roughly find 2^40/2^24 = 2^16 h160s starting with "20cb78".

@Tepan, could you implement KNN algorithm to your script?  it could somewhat help you in predicting a clearer pattern in order to create a map of similar hashes in certain ranges.

You could scan 39 to 40 bit range and categorize similarly found hashes,  do that with different hash prefixes in different bit ranges,  you might figure out the average probability of certain hashes existing in specific ranges.

Note that KNN algo is a great tool for statistics.  it stands for k-nearest neighboring.

Did you know the work of bitcoin address, my codes to search the puzzle to sink the large private key range bro, random data ? it's calculated, the private key generate public key, and hash160 was from public key of address, the "20cb78" of hash 160 from 13zQNfHTEd9EZncjXmiKMoZV7SqSZP39myL is on range "2a6bdd8aaca2a5a56".

hash 160 of 13zQNJwpREZogcPSkNJmYQzZ9HZQZS48Hx is "20cb77af1a425c5e74483d9b30cf950911a090de", take a look "20cb78" and "20cb77" It doesn't look that far away from the hash160 generated from the private key.

if you change the 78 into 78 it make lot of changes on address.
20cb77af1a425c5e74483d9b30cf950911a090de : 13zQN JwpREZogcPSkNJmYQzZ9HZQZS48Hx
20cb78af1a425c5e74483d9b30cf950911a090de : 13zQN agqxpgJMoqzrF3SUvYVq82ENKem4J


so the work of codes is when found that similiarities it will change the range of private key e.g 2a6bdd8aaca2a5a56 to 3ffffffffffffffff

the technical i learn is from https://learnmeabitcoin.com/technical/address, you change some number/letter on hash160 it's generate the different Bitcoin Address, but in other ways, we don't know what coresponding private key from that changes.

so what i do is collision hash160, it's like changes the private key start range to end range, when similiarities found.

i will preview the codes, the most unique is i make something new for search proccess and work on puzzle 40 bit within 18 second with that codes, it's not completed by speed, but by math from collision hash160.
and if u ask ? why not complete the 66 puzle, it's hard because i need to configure anything on that codes, because if there's mistaken value input for search, the proggress can be exhausted.

but thank you for your response, even though you don't help anything in the development I do, it's just criticism regarding someone's proggress in this community.