Bitcoin puzzle transaction ~32 BTC prize to who solves it

[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?

[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

[nomachine]

If you have any better approach instead

You’ve got a way better shot at brute-forcing a busted WIF key missing the last 12–14 characters than cracking anything touching BIP32/BIP39. That stuff’s built like a bunker. PBKDF2-HMAC-SHA512 isn’t slow by accident......it’s slow because it "hates you" and wants attackers to suffer.  

https://github.com/AkitoHosana/WIF-Cracker

After five years of banging your head against BIP32/BIP39 like a caveman discovering fire for the 12th time, the truth finally hits you.......

Crypto recovery isn’t about math.
It isn’t about GPUs.
It isn’t about “one clever trick.”

It’s about fishing 🎣

You cast lines where fish actually exist.
This game is just to pass the time before we die. There is no winner..

[Wanderingaran]

We’re just HODLin’ till the heat death of the universe. like Satoshi planned it

[POD5]

It’s about fishing 🎣

“Put out into deep water, and let down the nets for a catch.”

[zahid888]

After five years of banging your head against BIP32/BIP39 like a caveman discovering fire for the 12th time, the truth finally hits you.......

For the 13th time, a caveman is trying to explain to a highly advanced civilization
Ex:

I have a collection of about 100 useless scripts. Because the problem is speed in Python.....

Relying solely on Python for 66-bit counting is a waste of time. However, if Python is used only to generate the starting or ending points and the rest of the counting is done through GPUs, it could be a more efficient approach. This is what I am trying to achieve.

The discovery of fire was made five years ago- and that discovery is simple: brute force is the only solution.

The conversation is not about escaping brute force. It's about how to burn the fire more efficiently.. how to brute force smartly instead of blindly.

Unfortunately, even after providing visuals and detailed explanations, this highly advanced civilization still fails to understand that BIP32 or BIP39 (which are inherently slow processes) are not being used as the base for brute forcing. They are only being explored, at best, as possible ways to extract starting or ending bytes of a private key, after which brute force is applied within realistic limits.

Instead of understanding that, I'm being advised to use a WIF cracker.. basically suggesting I cripple an optimized brute-force engine by stuffing it with unnecessary Base58 overhead.

Anyway, I'm happy in my cave. And I'm fully aware that this over-smart civilization doesn't have a better solution either, aside from sarcasm and mockery.

[emiliamuller6710]

Even if u found it they won't let you have it 😞

After five years of banging your head against BIP32/BIP39 like a caveman discovering fire for the 12th time, the truth finally hits you.......

For the 13th time, a caveman is trying to explain to a highly advanced civilization
Ex:

I have a collection of about 100 useless scripts. Because the problem is speed in Python.....

Relying solely on Python for 66-bit counting is a waste of time. However, if Python is used only to generate the starting or ending points and the rest of the counting is done through GPUs, it could be a more efficient approach. This is what I am trying to achieve.

The discovery of fire was made five years ago- and that discovery is simple: brute force is the only solution.

The conversation is not about escaping brute force. It's about how to burn the fire more efficiently.. how to brute force smartly instead of blindly.

Unfortunately, even after providing visuals and detailed explanations, this highly advanced civilization still fails to understand that BIP32 or BIP39 (which are inherently slow processes) are not being used as the base for brute forcing. They are only being explored, at best, as possible ways to extract starting or ending bytes of a private key, after which brute force is applied within realistic limits.

Instead of understanding that, I'm being advised to use a WIF cracker.. basically suggesting I cripple an optimized brute-force engine by stuffing it with unnecessary Base58 overhead.

Anyway, I'm happy in my cave. And I'm fully aware that this over-smart civilization doesn't have a better solution either, aside from sarcasm and mockery.

[realnewuser]

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.

I’m not sure what you mean. I’m using the BTCpuzzle API. In my case, the program scanned a bit more than half of the range before it stopped. It found all 6 proof keys, calculated their SHA256 hash (proofKey1 + proofKey2 + proofKey3 + proofKey4 + proofKey5 + proofKey6), and the report was submitted and successfully accepted by the server. The verification process isn't complex at all — it's just a SHA256 hash of all the keys.

[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.

I’m not sure what you mean. I’m using the BTCpuzzle API. In my case, the program scanned a bit more than half of the range before it stopped. It found all 6 proof keys, calculated their SHA256 hash (proofKey1 + proofKey2 + proofKey3 + proofKey4 + proofKey5 + proofKey6), and the report was submitted and successfully accepted by the server. The verification process isn't complex at all — it's just a SHA256 hash of all the keys.

Tell you to immediately disable the - stop parameter of VanitySeacrh, so that the program can scan the entire range before stopping and submitting the results.
If you bring the - stop parameter, you are wasting GPU computing power and time because you missed many ranges and did not scan them. You may miss the real private key of the puzzle.