Bitcoin puzzle transaction ~32 BTC prize to who solves it

[brainless]

i dont know if headers checking is really the "last worry" when a mitm attack could theoretically feed you fake work or hijack your solution if you actually hit it, security should never be an afterthought especially when there is 32 btc on the line, that is enough money to make people get very creative with their attacks

Pls read this: https://github.com/Dookoo2/HashTransit-HT
MITM attacks are simply impossible with HT.
But if you dream further, it's much easier to catch data in the local host's memory than to try to crack nonce and bypass the timestamp

Your cuda cyclone ver could you add features like load list of ranges to scan
As nomachine CPU cyclone ver

[kTimesG]

MITM attacks are simply impossible with HT.
But if you dream further, it's much easier to catch data in the local host's memory than to try to crack nonce and bypass the timestamp

OK, we got it, stop promoting your lib.

Here's the issues with your approach:

- if TLS is used, it's just adding an unneeded layer, which is slower, unsafer, untested, and unaudited compared to decades of SSL.

- if TLS is not used, it's just reinventing the wheel; except the wheel is now a triangle; if we pretend it's a wheel, then we still have the same issues: slower, untested, unaudited, plus the extras: anyone can capture and modify the traffic - this is the very definition of MITM; also impossible to actually do protect against Denial of Service attacks, since all code needs to reach app layer and so on.

- you mention HTTP replay protection: I'm afraid HTTP replays are needed by design, for example, if a request fails and a retry is needed, which should be omnipotent; you're blocking a valid use-case and actually turning it into a messy problem;

- you mention servers, clients, needing to add/check headers and so on, and to verify stuff: again, you're just moving an already solved (L3, highly efficient) issue onto the application plane. So, do you have some nginx plugin that does this fancy headers checking, or do we need to touch the application code and mess up with X- headers and Redis databases, just to parse a response (or worse, to do the advertised rate limiting and etc - which should have already been done by the load balancer 5 steps earlier, like in TLS case)? Or maybe we should not trust the data that travels between a reverse proxy / load-balancer and the actual app? In that case, I think the machine is already compromised, so...

One last thing: if you're storing all the keys on a server, then anyone with access can impersonate any client, right? With TLS, the client key is generated by a client and never leaves the box.

We got it, you wrote a lib that does some stuff. You think it's useful somewhere, somehow. Maybe, but not for a puzzle pool. Let's get over it.

[FrozenThroneGuy]

MITM attacks are simply impossible with HT.
But if you dream further, it's much easier to catch data in the local host's memory than to try to crack nonce and bypass the timestamp

OK, we got it, stop promoting your lib.

Here's the issues with your approach:

- if TLS is used, it's just adding an unneeded layer, which is slower, unsafer, untested, and unaudited compared to decades of SSL.

- if TLS is not used, it's just reinventing the wheel; except the wheel is now a triangle; if we pretend it's a wheel, then we still have the same issues: slower, untested, unaudited, plus the extras: anyone can capture and modify the traffic - this is the very definition of MITM; also impossible to actually do protect against Denial of Service attacks, since all code needs to reach app layer and so on.

- you mention HTTP replay protection: I'm afraid HTTP replays are needed by design, for example, if a request fails and a retry is needed, which should be omnipotent; you're blocking a valid use-case and actually turning it into a messy problem;

- you mention servers, clients, needing to add/check headers and so on, and to verify stuff: again, you're just moving an already solved (L3, highly efficient) issue onto the application plane. So, do you have some nginx plugin that does this fancy headers checking, or do we need to touch the application code and mess up with X- headers and Redis databases, just to parse a response (or worse, to do the advertised rate limiting and etc - which should have already been done by the load balancer 5 steps earlier, like in TLS case)? Or maybe we should not trust the data that travels between a reverse proxy / load-balancer and the actual app? In that case, I think the machine is already compromised, so...

One last thing: if you're storing all the keys on a server, then anyone with access can impersonate any client, right? With TLS, the client key is generated by a client and never leaves the box.

We got it, you wrote a lib that does some stuff. You think it's useful somewhere, somehow. Maybe, but not for a puzzle pool. Let's get over it.

KtimesG, plz read the readme file, its very difficult to describe base things.
MITM - completely eliminated.
Packet forgery, modification, or resending without updating security components (timestamp, nonce) - eliminated.
Balancers and reverse proxies - cannot modify the packet itself without errors (bad sig flag).
Server spoofing - eliminated.
Client spoofing - completely eliminated.
What else...
The ability to use encryption without establishing a TLS handshake is present.

Listen, you may know your way around secp256k1, but don't ask questions that are already described in the readme file; it's counterproductive.

The component I'm proposing is something like AWS KMS (key management system), and you also can store clients keys in TPM module (for perfect security), why not?
And this library is not for puzzles, this is only a part of my pet project.

[kTimesG]

KtimesG, plz read the readme file, its very difficult to describe base things.
MITM - completely eliminated.
...

I did. And MITM is totally possible. You probably confuse MITM with forging data. However, without a secure transport at the socket level, any packets can simply be sniffed, moved, redirected, analyzed, dropped, captured for later replay, delayed, and so on, hence you didn't stop any kind of MITM attack at all. Maybe you think you did, that is fine.

IP flooding isn't an app-level issue, this can be done with kernel rules to limit SYN, or by misc. rules at the load balancer level (I hope you do use a load balancer, right?). By the time you do IP rate limiting at the app layer, the server is already zombified, because all traffic is allowed with no problems at all.

I prefer such nasty details to be handled by the kernel and an TLS terminator (like nginx) instead of parsing HTTP headers and doing weird crypto in application code. But anyway, why would I use HTTP at all?

Balancers and reverse proxies - cannot modify the packet itself without errors (bad sig flag).

Nasty. Most LB/RV do modify the packets, for lots of reasons. For example, that is where the TLS should terminate, for maximum efficiency. I think we should get rid of the LB altogether, it just stands in the way of security, right?...

[ee1234ee]

HONESTPOOL VS BTCPUZZLE or other alternatives ?

I use both. However, there's one major concern I have with btcpuzzle. They pick verification addresses randomly, which means they could all end up in the first half of the range. This actually happened to me: my software crashed halfway through, but since all the check-addresses had already been found, the pool marked the range as verified. This means at least one range in btcpuzzle remains unverified, and I suspect this has happened more than once. Honestpool handles this much better: their ranges are half the size and each is split into 5 segments, with a random check-address picked from each segment.

You have not completed the scanning of the entire block, but you have found all the inspection addresses. At this point, your program crashes and your scanning results will not be submitted to the server. Only when the entire block is scanned will it be submitted. Therefore, the block you scanned will not be marked as scanned, and someone else will obtain it in the future and continue scanning.

However, there's one major concern I have

So you don't have any issues at all if a random dude scans only up until whatever amount of proof keys are found, and potentially marks some whatever ranges as "scanned", no matter if the actual target key is really in that range? For only 5 proofs, on average you can only trust that around 83% of each range was actually completed (and 0% trust that the key wasn't actually found already)..

Worse yet: somebody knows all the required proofs keys beforehand, since they were chosen. This is like trying to prove to someone that you know the answer of a problem, because the problem was created out of the known answer.

A better system would be based on PoW where the results confirm with a very high accuracy that the supposedly claimed range was really scanned (for example: presenting keys of all found hashes that pass some on-the-fly bit mask checking). These cannot be spoofed due to the statistical guarantees of the uniform distribution. It's also faster to search for a single pattern instead of a dozen different hashes.

I am using btcpuzzle, which is a separate prize pool. Scanning blocks does not earn any prizes. Why would someone only scan the addresses of 6 checkpoints and submit the results? What are the benefits of doing this? The missed scanning part may miss the real private key of the puzzle. Is buying a GPU just to attack this platform?
By the way, the official scanning client must complete the scanning of the entire block before submitting the results, unless they develop their own third-party program.

[zahid888]

Another idea: If the author states that all keys are derived from a deterministic wallet, it implies that the same seed phrase was used to generate both Puzzle 70 and Puzzle 71.
The last few bytes of Puzzle 70 are already known. If those bytes match, it is reasonable to assume that the last few bytes of Puzzle 71 is from the next key, since both keys originate from the same seed.
'Still Random' but
Rather than treating the last few bytes as completely random, this approach appears logical and worth considering.

Code:

================================= Deterministic wallet masked with leading Zeros ===================================

Bip32 : hotel use model denial parrot aunt roast shiver fabric choice occur rely pig market radar

Bpath : m/44h/0h/0h/0/70
Bkeyy : 5460f068acced19d294592bfa5c86b19da197ebff67e2da1abb6849cd99beef1
Pvk70 : 000000000000000000000000000000000000000000000021abb6849cd99beef1

Puz70  Determine : 1HfQvgb4GPDstsYR2so5UmhiKmpK8haJ7D 21abb6849cd99beef1
Puz70  Originaly : 19YZECXj3SxEZMoUeJ1yiPsw8xANe7M7QR 349b84b6431a6c4ef1


Bpath : m/44h/0h/0h/0/71
Bkeyy : 58439b17b07aa7cda8557ca8aa146e4f8d446b8f51f3a155d82984f731734b25
Pvk71 : 000000000000000000000000000000000000000000000055d82984f731734b25

Puz71  Determine : 1HM8RLN9eosZed5F47ZcsgzsXnkbXsEkX2 55d82984f731734b25
Puz71  Originaly : 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU _________731734b25


Sufix:   ================================================================================================= 731734B25
Speed:   1194.22 MK/s 1PWo3JeL13aTTh5RMe36NbEqnoEwbhRXAo f6f5431d30afd424e850f8ac92f7b36e8e27d822 570EC833C731734B25

=============================================== [ KeySpace Ends ] ==================================================

Final Stats :
Elapsed Time  : 14.19 seconds
Partials Found: 1
====================================================================================================================

================================= Deterministic wallet masked with leading Zeros ===================================

Bip32 : odor response dog shop style amazing close uniform fatigue virus cheese wall inmate bicycle rabbit

Bpath : m/44h/0h/0h/0/70
Bkeyy : f781947f4bb0d437998438ccbff96d3ff58ffbbd61a3093e2fd9c5244afa4ef1
Pvk70 : 00000000000000000000000000000000000000000000003e2fd9c5244afa4ef1

Puz70  Determine : 1Aoy5G18tegvntBgVRcLFMPFERmET3GG3A 3e2fd9c5244afa4ef1
Puz70  Originaly : 19YZECXj3SxEZMoUeJ1yiPsw8xANe7M7QR 349b84b6431a6c4ef1


Bpath : m/44h/0h/0h/0/71
Bkeyy : bd14a76cfe57865078bc603be498aa3e5b3a1da04bfdab771176d060d59c94e2
Pvk71 : 0000000000000000000000000000000000000000000000771176d060d59c94e2

Puz71  Determine : 1HQxZADDX9jeG7bEuMxb7FTWsCZKNyVbhQ 771176d060d59c94e2
Puz71  Originaly : 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU _________0d59c94e2


Sufix:   ================================================================================================= 0D59C94E2
Speed:    597.76 MK/s 1PWo3JeHNg9eyLQKe267fgKFtHpubzcbFy f6f5431d2d6f881b6fca1c32f20dc5da53e854ab 7F1C299000D59C94E2
Speed:    597.76 MK/s 1PWo3JeHNg9eyLQKe267fgKFtHpubzcbFy f6f5431d2d6f881b6fca1c32f20dc5da53e854ab 7F1C299000D59C94E2
Speed:   1051.16 MK/s 1PWo3JgYGcMvo2CwCxFJT1gTRszEawtDEu f6f5431dcf6d6cffe6551bfa71fe52a2c8a5e05d 44AA620D00D59C94E2
Speed:   1183.62 MK/s 1PWo3JfLVCbfQqpr8CZuHxsASDCvdCRkZG f6f5431d791102708e48e48c10a59c36135bcde2 7490420730D59C94E2

=============================================== [ KeySpace Ends ] ==================================================

Final Stats :
Elapsed Time  : 14.17 seconds
Partials Found: 4
====================================================================================================================

================================= Deterministic wallet masked with leading Zeros ===================================

Bip32 : catalog sniff define initial symptom wire ask neutral stand hip into denial success truth ill

Bpath : m/44h/0h/0h/0/70
Bkeyy : 444e31beea92a9436deeee26796eb0299708667114f82ae6714f7d0c3567eef1
Pvk70 : 000000000000000000000000000000000000000000000026714f7d0c3567eef1

Puz70  Determine : 13RUzFkxT5BnP9Yv7PLp2nUmojYQvdQh29 26714f7d0c3567eef1
Puz70  Originaly : 19YZECXj3SxEZMoUeJ1yiPsw8xANe7M7QR 349b84b6431a6c4ef1


Bpath : m/44h/0h/0h/0/71
Bkeyy : dc55bacec580d146f1769bf0a67f126d1cb70f1a0de7b91f1ba02dfbb56ac146
Pvk71 : 00000000000000000000000000000000000000000000005f1ba02dfbb56ac146

Puz71  Determine : 17n1vehKBtjc9fjCN2jPT4AMkpT6wusuNA 5f1ba02dfbb56ac146
Puz71  Originaly : 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU _________bb56ac146


Sufix:   ================================================================================================= BB56AC146
Speed:      0.00 MK/s 1PWo3Jeu72pCKpXqi9RJo9pVT3V2buwgqw f6f5431d59a77dd321616989382cc8dd9b31c8f3 706510D2EBB56AC146
Speed:   1168.02 MK/s 1PWo3Jf2A9XtX9wySewqN5z4L52tArEpme f6f5431d62623af21d13cac7e888a30f205fa6eb 645740DC7BB56AC146
Speed:   1180.76 MK/s 1PWo3Jf8yoEtZ98pAmbg96KhT9mp7CMfr6 f6f5431d6ad36a1373ef3dabd51e6c4cd286e2cc 4F33FDF88BB56AC146
Speed:   1190.88 MK/s 1PWo3JeL1C4XjJaDHMg8sYPLF96GanBSGF f6f5431d30b0a0b11bad7aed0519451be901b218 551CFC2F5BB56AC146

=============================================== [ KeySpace Ends ] ==================================================

Final Stats :
Elapsed Time  : 14.23 seconds
Partials Found: 4
====================================================================================================================

================================= Deterministic wallet masked with leading Zeros ===================================

Bip32 : damage dune wide wise buyer fan adapt parade script hidden original short noodle liar forest

Bpath : m/44h/0h/0h/0/70
Bkeyy : 3c924b884750a64036146b296ee16d02ca623df3869b10ba8a0fb3c2b82f1ef1
Pvk70 : 00000000000000000000000000000000000000000000003a8a0fb3c2b82f1ef1

Puz70  Determine : 1Lq2FTxnQQiVh5sRNEKFUoiuQfNkBpd1Pt 3a8a0fb3c2b82f1ef1
Puz70  Originaly : 19YZECXj3SxEZMoUeJ1yiPsw8xANe7M7QR 349b84b6431a6c4ef1


Bpath : m/44h/0h/0h/0/71
Bkeyy : 2ecdc2e9aeb9d35dcd9e194edd93348a9a19b086eec859baa271b3533e8ec40c
Pvk71 : 00000000000000000000000000000000000000000000007aa271b3533e8ec40c

Puz71  Determine : 1Adp9LNnWLTFXCG97hGxf9unS6yaNc66uv 7aa271b3533e8ec40c
Puz71  Originaly : 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU _________33e8ec40c


Sufix:   ================================================================================================= 33E8EC40C
Speed:    850.15 MK/s 1PWo3Jdxr52SqRZN6pqxmpJYYqRqQmthAY f6f5431d1681a5a9b2d287a533476921bc806757 5B705BF0133E8EC40C
Speed:    971.62 MK/s 1PWo3Je5uPfpqWRcZUMH5enoTmPBNaiVYR f6f5431d1f3d824ebe947c852e1fdc6c08df16bf 5B1DC631033E8EC40C
Speed:   1034.02 MK/s 1PWo3Jh2W6voPeA8pLzNx7GxfJ5hPHa5rD f6f5431df25e00a08d9e0edf73999a78b98e854b 644B4176333E8EC40C
Speed:   1067.58 MK/s 1PWo3JfC7jR4dApY84BpCtXnJYWSXQsKR5 f6f5431d6eb5343a4d18e117615202d2b65cb77d 49C0781B233E8EC40C
Speed:   1105.07 MK/s 1PWo3JfRx1VG9i58nW8v7CCC4K4Rmw8Aku f6f5431d7fd3882862a919f7641668cf606df819 5A2C3E38333E8EC40C
Speed:   1151.24 MK/s 1PWo3Jej7JjAk8gs7t5cj7iUHEySb4jnMV f6f5431d4d48d2022bb541f296b7f8ded27005cb 7240A902633E8EC40C
Speed:   1151.24 MK/s 1PWo3Jf1bK1NoZV7KwaGKwLNhmwkx4Dp96 f6f5431d61aedd53b39eb59955f90797cb719fb2 42C4B3AB333E8EC40C
Speed:   1174.83 MK/s 1PWo3JeboM4Bfpu7RuFTx115Zci66EKHRD f6f5431d443cff8822db801a8c05e8be125fe9bf 7618074C433E8EC40C
Speed:   1186.62 MK/s 1PWo3JfZJu1ewxjA6B1Jd9UoFP9SeQ6pQ1 f6f5431d88ef59b7deea516f4aff78a40fe87c80 620902CF833E8EC40C

=============================================== [ KeySpace Ends ] ==================================================

Final Stats :
Elapsed Time  : 14.27 seconds
Partials Found: 9
====================================================================================================================

[ee1234ee]

Another idea: If the author states that all keys are derived from a deterministic wallet, it implies that the same seed phrase was used to generate both Puzzle 70 and Puzzle 71.
The last few bytes of Puzzle 70 are already known. If those bytes match, it is reasonable to assume that the last few bytes of Puzzle 71 is from the next key, since both keys originate from the same seed.
'Still Random' but
Rather than treating the last few bytes as completely random, this approach appears logical and worth considering.



================================= Deterministic wallet masked with leading Zeros ===================================

Bip32 : catalog sniff define initial symptom wire ask neutral stand hip into denial success truth ill

Bpath : m/44h/0h/0h/0/70
Bkeyy : 444e31beea92a9436deeee26796eb0299708667114f82ae6714f7d0c3567eef1
Pvk70 : 000000000000000000000000000000000000000000000026714f7d0c3567eef1

Puz70  Determine : 13RUzFkxT5BnP9Yv7PLp2nUmojYQvdQh29 26714f7d0c3567eef1
Puz70  Originaly : 19YZECXj3SxEZMoUeJ1yiPsw8xANe7M7QR 349b84b6431a6c4ef1


Bpath : m/44h/0h/0h/0/71
Bkeyy : dc55bacec580d146f1769bf0a67f126d1cb70f1a0de7b91f1ba02dfbb56ac146
Pvk71 : 00000000000000000000000000000000000000000000005f1ba02dfbb56ac146

Puz71  Determine : 17n1vehKBtjc9fjCN2jPT4AMkpT6wusuNA 5f1ba02dfbb56ac146
Puz71  Originaly : 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU _________bb56ac146


Sufix:   ================================================================================================= BB56AC146
Speed:      0.00 MK/s 1PWo3Jeu72pCKpXqi9RJo9pVT3V2buwgqw f6f5431d59a77dd321616989382cc8dd9b31c8f3 706510D2EBB56AC146
Speed:   1168.02 MK/s 1PWo3Jf2A9XtX9wySewqN5z4L52tArEpme f6f5431d62623af21d13cac7e888a30f205fa6eb 645740DC7BB56AC146
Speed:   1180.76 MK/s 1PWo3Jf8yoEtZ98pAmbg96KhT9mp7CMfr6 f6f5431d6ad36a1373ef3dabd51e6c4cd286e2cc 4F33FDF88BB56AC146
Speed:   1190.88 MK/s 1PWo3JeL1C4XjJaDHMg8sYPLF96GanBSGF f6f5431d30b0a0b11bad7aed0519451be901b218 551CFC2F5BB56AC146

=============================================== [ KeySpace Ends ] ==================================================

Final Stats :
Elapsed Time  : 14.23 seconds
Partials Found: 4
====================================================================================================================

================================= Deterministic wallet masked with leading Zeros ===================================

Bip32 : damage dune wide wise buyer fan adapt parade script hidden original short noodle liar forest

Bpath : m/44h/0h/0h/0/70
Bkeyy : 3c924b884750a64036146b296ee16d02ca623df3869b10ba8a0fb3c2b82f1ef1
Pvk70 : 00000000000000000000000000000000000000000000003a8a0fb3c2b82f1ef1

Puz70  Determine : 1Lq2FTxnQQiVh5sRNEKFUoiuQfNkBpd1Pt 3a8a0fb3c2b82f1ef1
Puz70  Originaly : 19YZECXj3SxEZMoUeJ1yiPsw8xANe7M7QR 349b84b6431a6c4ef1


Bpath : m/44h/0h/0h/0/71
Bkeyy : 2ecdc2e9aeb9d35dcd9e194edd93348a9a19b086eec859baa271b3533e8ec40c
Pvk71 : 00000000000000000000000000000000000000000000007aa271b3533e8ec40c

Puz71  Determine : 1Adp9LNnWLTFXCG97hGxf9unS6yaNc66uv 7aa271b3533e8ec40c
Puz71  Originaly : 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU _________33e8ec40c


Sufix:   ================================================================================================= 33E8EC40C
Speed:    850.15 MK/s 1PWo3Jdxr52SqRZN6pqxmpJYYqRqQmthAY f6f5431d1681a5a9b2d287a533476921bc806757 5B705BF0133E8EC40C
Speed:    971.62 MK/s 1PWo3Je5uPfpqWRcZUMH5enoTmPBNaiVYR f6f5431d1f3d824ebe947c852e1fdc6c08df16bf 5B1DC631033E8EC40C
Speed:   1034.02 MK/s 1PWo3Jh2W6voPeA8pLzNx7GxfJ5hPHa5rD f6f5431df25e00a08d9e0edf73999a78b98e854b 644B4176333E8EC40C
Speed:   1067.58 MK/s 1PWo3JfC7jR4dApY84BpCtXnJYWSXQsKR5 f6f5431d6eb5343a4d18e117615202d2b65cb77d 49C0781B233E8EC40C
Speed:   1105.07 MK/s 1PWo3JfRx1VG9i58nW8v7CCC4K4Rmw8Aku f6f5431d7fd3882862a919f7641668cf606df819 5A2C3E38333E8EC40C
Speed:   1151.24 MK/s 1PWo3Jej7JjAk8gs7t5cj7iUHEySb4jnMV f6f5431d4d48d2022bb541f296b7f8ded27005cb 7240A902633E8EC40C
Speed:   1151.24 MK/s 1PWo3Jf1bK1NoZV7KwaGKwLNhmwkx4Dp96 f6f5431d61aedd53b39eb59955f90797cb719fb2 42C4B3AB333E8EC40C
Speed:   1174.83 MK/s 1PWo3JeboM4Bfpu7RuFTx115Zci66EKHRD f6f5431d443cff8822db801a8c05e8be125fe9bf 7618074C433E8EC40C
Speed:   1186.62 MK/s 1PWo3JfZJu1ewxjA6B1Jd9UoFP9SeQ6pQ1 f6f5431d88ef59b7deea516f4aff78a40fe87c80 620902CF833E8EC40C

=============================================== [ KeySpace Ends ] ==================================================

Final Stats :
Elapsed Time  : 14.27 seconds
Partials Found: 9
====================================================================================================================

May I ask what scanning program is this?

[nomachine]

Another idea........

BIP32 does not give you any usable correlation between sibling keys (70 and 71) unless you already know the parent private key or chain code. The suffix-matching intuition feels logical, but cryptographically it collapses.

Even though Puzzle 70 and Puzzle 71 come from the same BIP32 seed, each child key is derived using a cryptographic HMAC that makes the output indistinguishable from random. Knowing the last bytes of Puzzle 70 gives no usable information about Puzzle 71.

Any apparent patterns or suffixes are coincidental; BIP32 is designed so that sibling keys are cryptographically independent. Brute-forcing Puzzle 71 based on Puzzle 70 provides no advantage over a standard brute-force attack.

[mjojo]

Hello everyone. I have published my optimized versions of VanitySearch (CUDA) with speed boost in case anyone is interested  

The "bitcrack" version is specific to the puzzle and allows searching for addresses and prefixes (compressed) within a given range. The speed is about 6900 MKey/s on a 4090 and 8800 MKey/s on 5090.

The second version, on the other hand, performs a standard search for vanity addresses (not just P2PKH compressed) but with the same optimizations in terms of math and CUDA code. Random searches with endomorphisms.

https://github.com/FixedPaul/VanitySearch-Bitcrack

https://github.com/FixedPaul/VanitySearch

Hi @FixedPaul, I try your VanitySearch-Bitcrack use command like in readme but change the range for puzzle 71, the result in output.txt is in random scan result not sequential scan and some keys is above on end range. Any explain?

[brainless]

If file contain 3500000 lines each line need to scan 268000000 keys,
What you think what total keys and what time gpu take to scan these keys , ?

[fixedpaul]

Hi @FixedPaul, I try your VanitySearch-Bitcrack use command like in readme but change the range for puzzle 71, the result in output.txt is in random scan result not sequential scan and some keys is above on end range. Any explain?

Because it is not strictly sequential, the range is divided based on the number of threads. Each thread scans a subrange in a nearly sequential manner, processing 1024 keys per batch, and these 1024 keys are not sequential but start from a central point.

[ee1234ee]

Because it is not strictly sequential, the range is divided based on the number of threads. Each thread scans a subrange in a nearly sequential manner, processing 1024 keys per batch, and these 1024 keys are not sequential but start from a central point.

Hello, I noticed that in your source code, you limit the value of nbThreadGroup to a power of 2, while the number of cores in 5090 is not a power of 2. Will this limit the speed of the program running on 5090?

[pliego]

do you actually think the power of 2 limitation in the code matters when you are hitting nearly 9 gkeys a second on a 5090, fixedpaul probably used that for optimization in the cuda kernels and changing it might actually slow things down even if it doesnt match the core count exactly, those extra cores are probably still being utilized by the warp scheduler anyway so i wouldn't worry about it too much, the bottleneck is usually the global memory access or the ec multiplication logic not a few idle cores on a monster card like the 5090

[Ali_555]

data taken from the site
privatekeys.pw

0000000000000000000000000000000000000000000000000000000000000007 75%
000000000000000000000000000000000000000000000000000000000000004c 18.75%
0000000000000000000000000000000000000000000000000000000000000483 12.79%
00000000000000000000000000000000000000000000000000000000000068f3 63.98%
000000000000000000000000000000000000000000000000000000000005749f 36.39%
0000000000000000000000000000000000000000000000000000000000556e52 33.49%
0000000000000000000000000000000000000000000000000000000006ac3875 66.82%
000000000000000000000000000000000000000000000000000000007d4fe747 95.8%
00000000000000000000000000000000000000000000000000000004aed21170 17.07%
0000000000000000000000000000000000000000000000000000004b5f8303e9 17.77%
000000000000000000000000000000000000000000000000000006bd3b27c591 68.48%
00000000000000000000000000000000000000000000000000006cd610b53cba 70.06%
00000000000000000000000000000000000000000000000000075070a1a009d4 82.86%
000000000000000000000000000000000000000000000000006abe1f9b67e114 66.79%
00000000000000000000000000000000000000000000000007496cbb87cab44f 82.17%
0000000000000000000000000000000000000000000000007cce5efdaccf6808 95.01%
00000000000000000000000000000000000000000000000730fc235c1942c1ae 79.78%

What do you think 7 or 6?

[ee1234ee]

Guys im using BitCrack$ on vast.ai but the speed he give me is target 3079.36 MKey/s  how you guys manage to push at 4090 7 GK?  thank you

Check out my GitHub (Vanitysearch-bitcrack), 6.8/6.9 bk/s on a 4090.

I’m working on a version without prefixes and other useless stuff, plus some optimizations. It’ll hit 7.1 bk/s, and I’m planning to release it in the next few weeks

You said the new version can achieve a speed of 7.1 bk/s on 4090 GPU.
Has this version been released yet?

[fixedpaul]

Guys im using BitCrack$ on vast.ai but the speed he give me is target 3079.36 MKey/s  how you guys manage to push at 4090 7 GK?  thank you

Check out my GitHub (Vanitysearch-bitcrack), 6.8/6.9 bk/s on a 4090.

I’m working on a version without prefixes and other useless stuff, plus some optimizations. It’ll hit 7.1 bk/s, and I’m planning to release it in the next few weeks

You said the new version can achieve a speed of 7.1 bk/s on 4090 GPU.
Has this version been released yet?

Not yet, but it will be a version that searches for a single target, without prefixes. However, it will include the ability to save PoWs

do you actually think the power of 2 limitation in the code matters when you are hitting nearly 9 gkeys a second on a 5090, fixedpaul probably used that for optimization in the cuda kernels and changing it might actually slow things down even if it doesnt match the core count exactly, those extra cores are probably still being utilized by the warp scheduler anyway so i wouldn't worry about it too much, the bottleneck is usually the global memory access or the ec multiplication logic not a few idle cores on a monster card like the 5090

Exactly

[E36cat]

data taken from the site
privatekeys.pw

0000000000000000000000000000000000000000000000000000000000000007 75%
000000000000000000000000000000000000000000000000000000000000004c 18.75%
0000000000000000000000000000000000000000000000000000000000000483 12.79%
00000000000000000000000000000000000000000000000000000000000068f3 63.98%
000000000000000000000000000000000000000000000000000000000005749f 36.39%
0000000000000000000000000000000000000000000000000000000000556e52 33.49%
0000000000000000000000000000000000000000000000000000000006ac3875 66.82%
000000000000000000000000000000000000000000000000000000007d4fe747 95.8%
00000000000000000000000000000000000000000000000000000004aed21170 17.07%
0000000000000000000000000000000000000000000000000000004b5f8303e9 17.77%
000000000000000000000000000000000000000000000000000006bd3b27c591 68.48%
00000000000000000000000000000000000000000000000000006cd610b53cba 70.06%
00000000000000000000000000000000000000000000000000075070a1a009d4 82.86%
000000000000000000000000000000000000000000000000006abe1f9b67e114 66.79%
00000000000000000000000000000000000000000000000007496cbb87cab44f 82.17%
0000000000000000000000000000000000000000000000007cce5efdaccf6808 95.01%
00000000000000000000000000000000000000000000000730fc235c1942c1ae 79.78%

What do you think 7 or 6?

you would not find it even if you knew the first 3 chars

[kTimesG]

you would not find it even if you knew the first 3 chars

No, it would be found in less than a couple of weeks, if not much faster. Margin of profit: ~ 1000x the maximum investment.

[zahid888]

Another idea........

BIP32 does not give you any usable correlation between sibling keys (70 and 71) unless you already know the parent private key or chain code. The suffix-matching intuition feels logical, but cryptographically it collapses.

Even though Puzzle 70 and Puzzle 71 come from the same BIP32 seed, each child key is derived using a cryptographic HMAC that makes the output indistinguishable from random. Knowing the last bytes of Puzzle 70 gives no usable information about Puzzle 71.

Any apparent patterns or suffixes are coincidental; BIP32 is designed so that sibling keys are cryptographically independent. Brute-forcing Puzzle 71 based on Puzzle 70 provides no advantage over a standard brute-force attack.

I'm already aware that BIP32 sibling keys are cryptographically independent and effectively random. When I said it "feels logical" -:

I didn't mean it as a real advantage __ more as a conceptual comfort.. this is just a "satisfaction-of-the-soul"

However, if (as the author stated.. deterministically) and luckily i got the actual seed_phrase.. lol..   and all puzzles are derived deterministically from that seed,

then a different possibility arises.

If the author generated keys from that seed and then manually modified only the starting bytes of the private key to force each puzzle into its intended range (or applied some masking or truncation method)

then the ending bytes of PVK could remain unchanged definitely (if the author's statement is taken literally)..

That is the specific assumption I'm exploring. At this stage, I still have to treat the suffix bytes of PVK as unknown.

If you have any better approach instead of blindly guessing random hex for the private-key suffix, I'd genuinely appreciate hearing it.

May I ask what scanning program is this?

Here you go... Link: https://github.com/Dookoo2/CUDACyclone

I tried your username also.. LoL

Code:

1PWo3JgUWETsb3UqNnB1vacPPEXpMKKza8 401C195F24EE1234EE
1PWo3JgFkhktyoKBSoKzqnNTf5PrvJCasS 4140B4794BEE1234EE
1PWo3JgxSVR73BHBSJoLnJo87oBTUkXJLY 4473231189EE1234EE
1PWo3Jh5FNzq7h8VwFqq27VeNZ9aTdJrTK 4724AC3792EE1234EE
1PWo3JfpkKBPTdW2v297itzMWYUdoJUsck 478D61D778EE1234EE
1PWo3Jfmk6M6z8GddQ94jBTWjhve3RpwTf 4A0787D7C1EE1234EE
1PWo3Jf1TXYeVZDL44hbSNHuqP5CrTxtdQ 4A1136D829EE1234EE
1PWo3Jf1SwXi8iZLvMFj4i7Ds51xZrTPmk 4AA0CB3890EE1234EE
1PWo3JfBaGLswyFsnYmdg57PLGXAcmu1Tn 4C71EF40CFEE1234EE
1PWo3JdnHSfEPuQr5eD9M7QPGg5dye8z9k 4C86656618EE1234EE
1PWo3Jeqoho78PsV7GKvLCK41ZzE4SJVu2 501C69FE16EE1234EE
1PWo3Jh7aZvT9baxki7sqtcKhpfLyqQri8 50DC9F4818EE1234EE
1PWo3JesPbAoj6j5YtPCvABciqtdPUnquV 5105793E69EE1234EE
1PWo3JfANwmDFxcK5YHYGdJnq5sMmcqPEu 51B770DEB1EE1234EE
1PWo3JehkJBsv6Qg79isjXupoxNe88ygug 52D7CE03F6EE1234EE
1PWo3JfY4tUUTe8qwbjfGNknuEFUdzMGer 551FCB9542EE1234EE
1PWo3JgcFrgRF4EJQabtkQPXzESJHdvQ9C 58992CA6E1EE1234EE
1PWo3JfY9CLWYVDwjhWoXaeJ7b1bBuufPM 595C41B021EE1234EE
1PWo3Je8Po3eiGkr1DtyDpVfRQ9Hhy1enc 5961233AA8EE1234EE
1PWo3JeYxo5MGd2j2x79LvAa71cn9Y8YHq 5BA611206CEE1234EE
1PWo3JgEFg1XXKLVP2LyMKtm7U4EU5EbQP 5CABB12B50EE1234EE
1PWo3JfgWQwT62QFcce5qMiYRdvCds2egx 5CB4AB05B4EE1234EE
1PWo3JfJPqkpKFiVuSHUE6Zv1vFE1XrLeF 5DAABD37C5EE1234EE
1PWo3JfKiQrPweVFDvH26ZA15z2zGfqJwY 6009AECCD2EE1234EE
1PWo3JeaYsfM4GvPt6Z57Zo72w5qCagJv3 624C39032BEE1234EE
1PWo3JfmUGHELGsPEchGp7RretTv24ZXLd 62D5E3E9DBEE1234EE
1PWo3JhAkq7o4WECFCyK9yCm8pAiKf73D5 63B105163DEE1234EE
1PWo3JfVu2aMCWahaMu8sFuSGindBf4mj3 6547412053EE1234EE
1PWo3JgeHNA5wZsKJ1cgy6DBjuE47So1TN 66F4486D6DEE1234EE
1PWo3JekvHiGsn1rn8Dx2GuquJTUgDZ7Ww 6726C5D9A1EE1234EE
1PWo3JerUdxpHmXVZcLMfvpaCGY1t7zMyW 6844EB0E80EE1234EE
1PWo3JeYzJX88aJXshtkMRKAKaomhfQyev 689CDCDA0DEE1234EE
1PWo3Jer368Emi8QQb4iGZxqpE5pTt3Poc 68EAE6DC5AEE1234EE
1PWo3JekoYBd6VNXsxGSUqf6vWi42iZGAe 6AE167E684EE1234EE
1PWo3JeFuwyTgdi5ypLjAWFe9CLCCtSsuh 6B19796039EE1234EE
1PWo3JdtNCbkXCLp8V18f1tJXzE1ZDfxPf 6E15DDD6D0EE1234EE
1PWo3JdjytSqzNu7gRoEUoq7L7iuC8KtJQ 6E3AE9736CEE1234EE
1PWo3Je6YN1r6QXd9TnVFxx7BMJXsFkquz 6F1B17F1A8EE1234EE
1PWo3JgHuYprJqxQDiXheGuGoksGxtxru4 6FBDE66F53EE1234EE
1PWo3JdfpXmMfsxwWruwBUWvwYtvcjnNur 707A208300EE1234EE
1PWo3JdfpXmMfsxwWruwBUWvwYtvcjnNur 707A208300EE1234EE
1PWo3Jgk3LF44H2YQvi4NjCJ65CHKDqWh6 70E3158B24EE1234EE
1PWo3JfVXVzDgRnotJyiUrB1PDiJZChjjK 715D22253AEE1234EE
1PWo3JfG667c2LEKDAVJRtFap1GeFiSSoX 72E51E1244EE1234EE
1PWo3Jgqi2UHzCdyUvfQ8MTn49zTiTJPov 730B727A6AEE1234EE
1PWo3Jg5KQp2mW9avMvmTztzgMjGw6okiW 743637A73BEE1234EE
1PWo3JfQHdh6r9r1VBdn99FbpnixyczGVt 7507F49950EE1234EE
1PWo3JhDCEm2TyaUYHppbbQFrbX2RczBmp 75139274E8EE1234EE
1PWo3JeKC3GhYZvYgpSqGaT248jpUHeMFK 766C80759DEE1234EE
1PWo3JfjPn2CgenqbFZtLtfFTqEgi7ChZE 77FBC7A5BDEE1234EE
1PWo3Jffyv1wg4JCAiNXYb2k2FheUfJj3g 790E57734FEE1234EE
1PWo3JfxVS2rgxMHLBhtc1jXZujq13iQkU 7A93CD5ED0EE1234EE
1PWo3JdgKnHNqYtNsLURkUwmLaRX2yVGaa 7CD482EDAEEE1234EE
1PWo3JgLbJaho2cnDneCpTJcHEWRLiCV9f 7DDBC574FFEE1234EE
1PWo3JeAYBqbeByK1BjnHG94U6kApdH2kx 7E9561A72CEE1234EE
1PWo3JfPpjmcJUngCmJesxDaR42nEE4ETu 7F6F7E94D9EE1234EE

[ee1234ee]

Here you go... Link: https://github.com/Dookoo2/CUDACyclone

I tried your username also.. LoL

Are you sure you're using CUDACyclone?
Why did I see that CUDACyclone's program running interface is completely different from yours?






./CUDACyclone --range 2000000000:3FFFFFFFFF --address 1HBtApAFA9B2YZw3G2YKSMCtb3dVnjuNe2 --grid 512,256
======== PrePhase: GPU Information ====================
Device               : NVIDIA GeForce RTX 3070 Laptop GPU (compute 8.6)
SM                   : 40
ThreadsPerBlock      : 256
Blocks               : 8192
Points batch size    : 512
Batches/SM           : 256
Batches/launch       : 64 (per thread)
Memory utilization   : 64.0% (5.12 GB / 8.00 GB)
-------------------------------------------------------
Total threads        : 2097152

======== Phase-1: BruteForce (sliced) =================
Time: 61.2 s | Speed: 1234.3 Mkeys/s | Count: 72707573152 | Progress: 52.90 %

======== FOUND MATCH! =================================
Private Key   : 00000000000000000000000000000000000000000000000000000022382FACD0
Public Key    : 03C060E1E3771CBECCB38E119C2414702F3F5181A89652538851D2E3886BDD70C6