CUDA Bitcoin Private Key Searcher v2.3
(BitCrack/VanitySearch architecture)
Target hash160：f6f5431d25bbf7b12e8add9af5e3475c44a0a5b8
Key constraint:71 bit total, fixed high bits [70, 71) = 0b1; free bits [0, 70) with exactly 32 ones Search space: C(70, 32) = 8.704e+19 states
Scalar mult: bit-swap randon walk (1 mixed add / key, zero doubling)
Serialization: batch in-place Montgomery trick
Grid; 1536 blocks x 256 threads = 393216 total | keys/thread = 4096
Parallelism knobs：WALKS PER_THREAD=16 BATCH_SIZE=256 MIN BLOCKS_PER SN=6
Table memory:G_PRECOMP 16.0 KB DELTA_TABLE 150.9 KB
Seed:25324634100
GPU：NVIDIA GeForce RTX 4090 | SH：128 | Memory;24564 MB | regs/SN：65536 | maxThreads/SM：1536
Initializing tables...
G_PRECOMP：256 x 64B = 16.0 KB (window path / walk start point)
DELTA TABLE:2415 x 64B = 150.9 KB
Done.
Starting Search...
[Launch 172] Total： 277, 025, 390, 592 keys ] Rate： 486.47 M keys/s | Elapsed; 3.3s
Maybe this is a new shortcut to find puzzle 71. Good luck!
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hi! I looked at the log from your search tool. Before drawing any conclusions, I’d like to understand a few points:
The search space: the log says “71 bits, bit 70 = 1, exactly 32 ones in the other 70 bits.” Is this restriction your own hypothesis about the puzzle 71 key, or does it come from some information you have? If it’s a hypothesis, what is it based on?
Why only this set: this set has about 8.7 × 10^19 keys, which is only about 7% of all 71-bit keys with the top bit set. If the key doesn’t have exactly 32 ones, the program will never find it. Have you tested this restriction on smaller puzzles with a known key?
The numbers don’t add up: each launch processes 393,216 threads × 4096 = 1.61 billion keys. With 172 launches, that gives 277 billion in total. But the rate shown is 486 M/s, and over 3.3 seconds that would be only 1.6 billion keys. Which of these is correct: the elapsed time, the total, or the rate? The counter may be adding up something wrong.
Range or seed: the log doesn’t show a continuous key range. Did you search a continuous range, or did you draw keys with the seed 25324634100? How does the random walk choose its next point?
Test with a known key: can you run the program on a small range that contains a known key, for example puzzle 20 (key 863317, address 1HsMJxNiV7TLxmoF6uJNkydxPFDog4NQum)? If it finds the right key, that’s good. If it doesn’t, the problem is in the program, not in the puzzle 71 hypothesis.
Output when a key is found: what is the exact output when a key is found? Do you have an example? That would help us validate results.
The code: can you share the source code or the binary? If it’s a binary, I won’t run anything that hasn’t gone through your own checks, but reading the source code would help me understand the logic a lot.
I’m not trying to dismiss your work. Random walks with bit restrictions are an interesting idea. But the log, as it stands, shows no result and the numbers don’t reconcile. I want to understand it before I treat this as a shortcut.
If you’d like to talk privately, just send me a private message; I’m open to receiving messages.
