detechs
Newbie

Activity: 8
Merit: 0
|
 |
July 22, 2026, 12:54:23 AM |
|
look up the addresses on any block explorer both exist on mainnet
HASH-160 of 1PWo3JgFsv: f6f5431dbb246d70b85f78f3ad00ee54055d5ed3
HASH-160 of puzzle 71: f6f5431d25bbf7b12e8add9af5e3475c44a0a5b8
same 4-byte prefix: f6f5431d
the blockchain has ~460 million addresses ever created the 4-byte HASH-160 prefix space is 2^32 = 4,294,967,296
expected random collisions with this prefix: zero point one
there are 6 verified addresses on this prefix all from the same BIP32 wallet sent by the same entity on the same day
your claim of "thousands" requires 8.5 trillion addresses that is 18,000 times more than have ever existed
anyone can compute the HASH-160 from the base58 address and verify the math is public
just need 1 if you claim there's thousands, tell us one more
|
|
|
|
|
NUCLEAR7.1
Jr. Member
Online
Activity: 51
Merit: 2
|
 |
July 22, 2026, 01:02:55 AM |
|
look up the addresses on any block explorer both exist on mainnet
HASH-160 of 1PWo3JgFsv: f6f5431dbb246d70b85f78f3ad00ee54055d5ed3
HASH-160 of puzzle 71: f6f5431d25bbf7b12e8add9af5e3475c44a0a5b8
same 4-byte prefix: f6f5431d
the blockchain has ~460 million addresses ever created the 4-byte HASH-160 prefix space is 2^32 = 4,294,967,296
expected random collisions with this prefix: zero point one
there are 6 verified addresses on this prefix all from the same BIP32 wallet sent by the same entity on the same day
your claim of "thousands" requires 8.5 trillion addresses that is 18,000 times more than have ever existed
anyone can compute the HASH-160 from the base58 address and verify the math is public
just need 1 if you claim there's thousands, tell us one more
haha Hash160:f6f5431d263b08974e9c2e8d695d7a7328715bfc
(P2PKH): 1PWo3JeBZ13yxvPgqrtfJthwoPmKVrV9b7
Will this convince you to believe that I am the Creator, or will you say that you were wrong and leave?
|
|
|
|
|
detechs
Newbie

Activity: 8
Merit: 0
|
 |
July 22, 2026, 02:36:29 AM |
|
sign a message with the private key for that address spend from that address on chain derive puzzle 66 key from seed + passphrase and post it if you had the genesis seed phrase you could get my btc right now, i used it to create my wallet a couple days ago, from dust to....
|
|
|
|
|
mumsidea
Newbie

Activity: 5
Merit: 0
|
 |
July 22, 2026, 11:46:21 AM |
|
If the community moves toward updating the tools, we could make significant progress. Modern versions of Kangaroo and BitCrack with support for different search strategies would be extremely valuable. Not only the current random search approach, but also other modes, adaptive methods, and algorithms optimized for new hardware architectures. Better compatibility with modern GPUs and reducing implementation issues would make a huge difference. Right now, there is no known direct way to solve Puzzle #71. However, there are three possible approaches: 1. Full keyspace search This is already happening across several platforms. Based on the information I have collected from different communities — Telegram, Discord, Reddit, and here — the total estimated progress on Puzzle #71 is around 11%. This is verifiable from publicly shared information. 2. Luck, prefixes, and hash-related observations This approach can work, but it requires a significant amount of luck. There is no guaranteed method here. 3. Searching high-probability ranges The idea of “golden ranges” depends entirely on available data and whether useful information patterns are discovered. The biggest problem is that the main tools have not received major updates for a long time. Many forks are also not actively maintained or significantly improved. It would be great if developers and researchers pushed this area forward again. For a long time, there has not been much new research shared. Someone needs to start publishing even small observations. For example: We know from analyzing 82 solved puzzles that the private keys were never located beyond 50% of their midpoint range. Even a small observation like this can reduce the search space slightly. Now imagine combining hundreds of small observations like this, creating multiple filters, and building a funnel-based search strategy. Linear search will continue. Random search and range-based approaches are also already being used, but much of the information and analysis is not publicly shared. Instead of everyone searching alone, we should focus on finding better candidate ranges, sharing results, and building stronger methods together. This does not mean there is a pattern or that the private key can be directly predicted. The goal is not to break the randomness of Bitcoin keys. The goal is to use probability, statistics, and publicly available data to improve search efficiency.
Sharing information creates better ideas.
|
|
|
|
|
napros
Newbie

Activity: 32
Merit: 0
|
 |
July 22, 2026, 12:47:28 PM |
|
If the community moves toward updating the tools, we could make significant progress. Modern versions of Kangaroo and BitCrack with support for different search strategies would be extremely valuable. Not only the current random search approach, but also other modes, adaptive methods, and algorithms optimized for new hardware architectures. Better compatibility with modern GPUs and reducing implementation issues would make a huge difference. Right now, there is no known direct way to solve Puzzle #71. However, there are three possible approaches: 1. Full keyspace search This is already happening across several platforms. Based on the information I have collected from different communities — Telegram, Discord, Reddit, and here — the total estimated progress on Puzzle #71 is around 11%. This is verifiable from publicly shared information. 2. Luck, prefixes, and hash-related observations This approach can work, but it requires a significant amount of luck. There is no guaranteed method here. 3. Searching high-probability ranges The idea of “golden ranges” depends entirely on available data and whether useful information patterns are discovered. The biggest problem is that the main tools have not received major updates for a long time. Many forks are also not actively maintained or significantly improved. It would be great if developers and researchers pushed this area forward again. For a long time, there has not been much new research shared. Someone needs to start publishing even small observations. For example: We know from analyzing 82 solved puzzles that the private keys were never located beyond 50% of their midpoint range. Even a small observation like this can reduce the search space slightly. Now imagine combining hundreds of small observations like this, creating multiple filters, and building a funnel-based search strategy. Linear search will continue. Random search and range-based approaches are also already being used, but much of the information and analysis is not publicly shared. Instead of everyone searching alone, we should focus on finding better candidate ranges, sharing results, and building stronger methods together. This does not mean there is a pattern or that the private key can be directly predicted. The goal is not to break the randomness of Bitcoin keys. The goal is to use probability, statistics, and publicly available data to improve search efficiency.
Sharing information creates better ideas.
Sounds like a good idea, but as soon as someone posts or suggests an idea, they are treated like a complete idiot. there is little to no respect by 'some' on this forum, they carry on as if they are Gods and know everything and any suggest is rubbished straight away. So I agree, a lot of applications are old and need updates, and ideas on providing suggestions or insight is treated like spam and you get treated like scum. So I wont be one of those that would be posting much. Did it before, had some bright ideas (that I thought might work) was treated like scum of the Earth. So I wish you well, and maybe someone else might step up and assist.
|
|
|
|
|
optioncmdPR
Newbie

Activity: 52
Merit: 0
|
 |
July 22, 2026, 05:16:00 PM |
|
look up the addresses on any block explorer both exist on mainnet
HASH-160 of 1PWo3JgFsv: f6f5431dbb246d70b85f78f3ad00ee54055d5ed3
HASH-160 of puzzle 71: f6f5431d25bbf7b12e8add9af5e3475c44a0a5b8
same 4-byte prefix: f6f5431d
the blockchain has ~460 million addresses ever created the 4-byte HASH-160 prefix space is 2^32 = 4,294,967,296
expected random collisions with this prefix: zero point one
there are 6 verified addresses on this prefix all from the same BIP32 wallet sent by the same entity on the same day
your claim of "thousands" requires 8.5 trillion addresses that is 18,000 times more than have ever existed
anyone can compute the HASH-160 from the base58 address and verify the math is public
just need 1 if you claim there's thousands, tell us one more
It is my understnding that what is going on is someone has created a custom wallet consisting of mined vanity addresses all starting with puzzle 71 prefix . The reason for dust transactions is convolute transaction history for the puzzle 71 address to hope that the solver of 71 makes a wallet mistake and sends a transaction to one the look alike addresses addresses out of inexperience or carelessnesss in scrutiny.
|
|
|
|
|
NUCLEAR7.1
Jr. Member
Online
Activity: 51
Merit: 2
|
 |
July 22, 2026, 07:18:53 PM Last edit: July 22, 2026, 07:30:28 PM by NUCLEAR7.1 |
|
It is my understnding that what is going on is someone has created a custom wallet consisting of mined vanity addresses all starting with puzzle 71 prefix . The reason for dust transactions is convolute transaction history for the puzzle 71 address to hope that the solver of 71 makes a wallet mistake and sends a transaction to one the look alike addresses addresses out of inexperience or carelessnesss in scrutiny.
But whoever solves the puzzle will not send to address similar to the puzzle's address because they will focus on the address that begins with bc1 not 1PWo3
|
|
|
|
|
crypto_user_new
Newbie

Activity: 7
Merit: 0
|
 |
July 23, 2026, 12:11:15 PM |
|
Very interesting the Vanitysearch from Jean Luc. I added a new feature to check anywhere in the BTC address
VanitySearch_the_one Contain search: added pattern '1*XXXXXXX*' Search: 1*XXXXXXX* [Compressed] Start Thu Jul 23 14:01:19 2026 Base Key: A624DAB6ED1C4E9E9BD51D83XXXXXXXXXXXXXXXX5147FDBCBCEF68283EB0B674 Number of CPU thread: 1024 GPU: GPU #1 NVIDIA GeForce RTX 5060 Ti (36x0 cores) Grid(2304x128) [2452.89 Mkey/s][GPU 2452.89 Mkey/s][Total 2^36.46][Found 1] ================================================================= *** KEY FOUND *** PubAddress : 1Fb2oPsF9DpXJ9XXXXXXXLNmXXAaaMt5Bn Priv (WIF) : L2nfzLXSQLfUz7poehXXXXXXXXXXXXXXXXhTgWQUYXPLuCzRBDgC4 Priv (HEX) : A624DAB6ED1C4E9E9BD51D83XXXXXXXXXXXXXXXX5147FDBCBCEF68283EB0B674 XXXX- is to protect the key found.
The speed is a little bit faster because i modified the algorithm that is doing the random(i created my own random algorithm based on PI number). The one that is already inside is a crap and you will never find because will skip the critical points. And the sequential mode was a garbage because was doing true sequential only on suffix and not in true order.
|
|
|
|
|
|
kTimesG
|
 |
July 23, 2026, 03:18:07 PM |
|
Very interesting the Vanitysearch from Jean Luc. I added a new feature to check anywhere in the BTC address
The speed is a little bit faster because You are aware that searching for non-prefix base58 characters requires doing H160 to base58 conversions at every single step, right? Or are in the category that now wants congratulations for slowing down the entire search process by whatever factor and calling it "faster"?
|
|
|
|
crypto_user_new
Newbie

Activity: 7
Merit: 0
|
 |
July 23, 2026, 03:33:39 PM |
|
If is slowing down this means JeanL is doing the same...i didn't do any magic there. If you read the code, you see that you can add a new search method and add similar to other flags as prefix, hash160, suffix or search anywhere in the BTC address. The only change is when the address is generated and read similar to prefix, you clone the principle and add a new logic... Is that hard? The new thing that i added is the new random logic and sequential in real order. So we do not need to reinvent the wheel.... And i reached for 5060Ti GPU 2801 Mkey/s after final touch on the code. If i search by prefix list until 500k entries i have 2801 Mkey/s, if i search by 10M entries in the file i have 1000 Mkey/s.
|
|
|
|
|
Welsh
Staff
Legendary

Activity: 3850
Merit: 4609
Reporting saves lives. Probably.
|
 |
July 23, 2026, 03:49:43 PM |
|
This topic is such a hard read because some half good information, and some information which is complete fantasy land. I'm conflicted, because the puzzle is a very cool challenge to Bitcoiners. Yet we have users claiming to have found a pattern and to have broken it, which is just impossible. If you've found the pattern, and you believe that you can solve it (not randomly) within x amount of time, you've effectively broken Bitcoin which means this puzzle no longer means anything as its practically worth 0 the time that this pattern is known.
Unless claiming the original creator of the puzzle made a mistake on their end, which I also heavily doubt otherwise every transaction / wallet around that time, created in the same way would also be suspect to the same issue. They likely used commonly used software which was mass used around this time, which would effectively mean a ton of Bitcoin would be vulnerable.
|
▬▬▬ PROTECT THE NETWORK • SECURE THE BOARD • EARN YOUR BOUNTY ▬▬▬ I can add 700 more characters to this code, we want EXTRA EXTRA WOW factor
|
|
|
|
kTimesG
|
 |
July 23, 2026, 03:52:17 PM |
|
If is slowing down this means JeanL is doing the same... Oh, my bad. I thought this topic was about finding a specific H160, in which case base58 filtering is useless. A 5060 would probably go beyond 9Gk/s for this case. If you're bragging about revolutionary base58 "inner vanity" stuff where you like to divide big integers by the number 58 up to 31 times in a loop, you're in the wrong place.
|
|
|
|
NUCLEAR7.1
Jr. Member
Online
Activity: 51
Merit: 2
|
 |
July 23, 2026, 04:59:39 PM Last edit: July 23, 2026, 05:25:46 PM by NUCLEAR7.1 |
|
This topic is such a hard read because some half good information, and some information which is complete fantasy land. I'm conflicted, because the puzzle is a very cool challenge to Bitcoiners. Yet we have users claiming to have found a pattern and to have broken it, which is just impossible. If you've found the pattern, and you believe that you can solve it (not randomly) within x amount of time, you've effectively broken Bitcoin which means this puzzle no longer means anything as its practically worth 0 the time that this pattern is known.
Unless claiming the original creator of the puzzle made a mistake on their end, which I also heavily doubt otherwise every transaction / wallet around that time, created in the same way would also be suspect to the same issue. They likely used commonly used software which was mass used around this time, which would effectively mean a ton of Bitcoin would be vulnerable.
I think it's a mistake by the creator, but it's useless because the only puzzle that can be exploited is 71, as the cost will be less than the reward. The remaining puzzles, even with the pattern you discovered, won't be useful because the cost will far exceed the reward, and not all puzzles are predictable. you've effectively broken Bitcoin
My method does not rely on encryption breaking. Honestly, I doubt it was a mistake on the part of the creator Meaning, not intentionally, and even unintentionally, because they might have been aware of it. It doesn't necessarily have to be their mistake, as it would simply be how his system works, not necessarily an mistake.
|
|
|
|
|
detechs
Newbie

Activity: 8
Merit: 0
|
 |
July 24, 2026, 02:20:53 AM |
|
This topic is such a hard read because some half good information, and some information which is complete fantasy land. I'm conflicted, because the puzzle is a very cool challenge to Bitcoiners. Yet we have users claiming to have found a pattern and to have broken it, which is just impossible. If you've found the pattern, and you believe that you can solve it (not randomly) within x amount of time, you've effectively broken Bitcoin which means this puzzle no longer means anything as its practically worth 0 the time that this pattern is known.
Unless claiming the original creator of the puzzle made a mistake on their end, which I also heavily doubt otherwise every transaction / wallet around that time, created in the same way would also be suspect to the same issue. They likely used commonly used software which was mass used around this time, which would effectively mean a ton of Bitcoin would be vulnerable.
I think it's a mistake by the creator, but it's useless because the only puzzle that can be exploited is 71, as the cost will be less than the reward. The remaining puzzles, even with the pattern you discovered, won't be useful because the cost will far exceed the reward, and not all puzzles are predictable. you've effectively broken Bitcoin
My method does not rely on encryption breaking. Honestly, I doubt it was a mistake on the part of the creator Meaning, not intentionally, and even unintentionally, because they might have been aware of it. It doesn't necessarily have to be their mistake, as it would simply be how his system works, not necessarily an mistake. are you talking about the twin block chain? ive been remining both and comparing, the real prize is mining the next block from under the asics, instead of computing power, I'm using base 5 binary maths to compute exactly instead of guessing too.. you need two tools for it to work both working together, i remade kangaroo and call mine the kiwi hopper, that hops along my sprout coming through the bitcoin genesis gap. sha256 looks interesting when you stick your head inside it, not as magical as people claim it is
|
|
|
|
|
SRG02289
Newbie
Online
Activity: 22
Merit: 0
|
 |
July 24, 2026, 07:06:51 AM |
|
If a user is asking for a simple information, why you give more that he asked? At least if you give the private key, give also the address...he needs now to scan again and again wasting power and money....sometimes is a joke for everyone...
There is only 2 addresses with form 1PWo3JeB9jrG for puzzle 71. If the first one is on 4, the second one should be on 60-68.
1PWo3JeB9jrGMLiH83vD775NRqHZMR2hHB 1PWo3JeB9jrGLDTmsp45h1pDXXtb7zisQH 1PWo3JeB9jrGFsveoYdzAukjcwp645X7Zx
|
|
|
|
|
PHA_.07
Newbie

Activity: 5
Merit: 0
|
 |
July 24, 2026, 07:45:26 AM |
|
After all this time spent researching, I have discovered how to solve all these puzzles; based on a calculation, I can deduce the next number in the sequence. I will not tell anyone how, nor do I wish to discuss it. To anyone who doubts this process, here is puzzle number 71—the first two numbers are 69.
If you have the first 2 digits to puzzle 135 I will gladly accept them. 
|
|
|
|
|
OzBtcOz
Newbie

Activity: 21
Merit: 0
|
 |
July 24, 2026, 08:23:07 AM |
|
If a user is asking for a simple information, why you give more that he asked? At least if you give the private key, give also the address...he needs now to scan again and again wasting power and money....sometimes is a joke for everyone...
There is only 2 addresses with form 1PWo3JeB9jrG for puzzle 71. If the first one is on 4, the second one should be on 60-68.
1PWo3JeB9jrGMLiH83vD775NRqHZMR2hHB 1PWo3JeB9jrGLDTmsp45h1pDXXtb7zisQH 1PWo3JeB9jrGFsveoYdzAukjcwp645X7Zx SRG02289, please don't feint the comunity. There are only 2 addresses betweeen puzzle 71's gap 0x400..0x7fff. One of the is solution and another one is 0x4da0aa7f285f61b1c5 = 1PWo3JeB9jrGMLiH83vD775NRqHZMR2hHB. Other 2 addresses(1PWo3JeB9jrGLDTmsp45h1pDXXtb7zisQH - 1PWo3JeB9jrGFsveoYdzAukjcwp645X7Zx) aren't between the gap 0x400..0x7fff.
|
|
|
|
|
detechs
Newbie

Activity: 8
Merit: 0
|
 |
July 24, 2026, 08:45:29 AM Last edit: July 24, 2026, 09:32:46 AM by detechs |
|
the central bottleneck in kangaroo ECDLP:
Jacobian coordinates eliminate modular inverse per hop (8.8x speedup), but DP detection needs affine coordinate which needs modular inverse mod p (3000-4000 cycles). this kills the speedup at every DP check.
the solution:
compute x mod D where D is the SMALL DP modulus (19 or 323), not mod p where p is the 256-bit field prime. modular inverse mod 19 is a 19-entry lookup table (~2 cycles). modular inverse mod p is ~36000 cycles via binary GCD.
|
|
|
|
|
Niekko
Member


Activity: 139
Merit: 57
|
 |
July 24, 2026, 10:52:12 AM |
|
After all this time spent researching, I have discovered how to solve all these puzzles; based on a calculation, I can deduce the next number in the sequence. I will not tell anyone how, nor do I wish to discuss it. To anyone who doubts this process, here is puzzle number 71—the first two numbers are 69.
No, you can't do that. Each byte is independent. If you sum the pubkey of 0xc3 with 0xb200 and 0xa10000, you get the pubkey of 0xa1b2c3. If you cut the first byte, you're left with the sum of the other two, and that sum has nothing to do with the byte you cut off.
|
|
|
|
|
crypto_user_new
Newbie

Activity: 7
Merit: 0
|
 |
July 24, 2026, 10:54:32 AM |
|
From my perspective and the searching on the old puzzles, the distribution is based on a specific pattern. And from what i see where is the distribution high, for example over 15 prefixes in a range 44, there are big chances to find the remaining G. On old puzzles there is a little numbers 1-2 for spcific prefixes that are found on specific keys and is progressing with each puzzle. If anyone checked after puzzle 60 will see what i am saying.
|
|
|
|
|
|