Bitcoin puzzle transaction ~32 BTC prize to who solves it

[bankeroft]

🚨🚨 EMERGENCY WARNING FOR BITCOIN PUZZLE #71 HUNTERS 🚨🚨

⚠️ I think anyone involved in Bitcoin Puzzle #71 should be extremely careful with krackpot.io.

Gridinsoft has recently analyzed the website and currently classifies it as:

🚨 MALWARE DISTRIBUTOR
⚠️ TRUST SCORE: 1/100

🔗 Report:
https://gridinsoft.com/online-virus-scanner/url/krackpot-io

According to the report, krackpot.io is advertising itself as:

 “Krackpot: crack Bitcoin Puzzle 71 for 6 BTC”

The site apparently allows users to point their GPU at Bitcoin Puzzle #71 through their browser.

🚩 Some of the warning signals reported by Gridinsoft include:

* ⚠️ Domain is only around 2 months old
* 🚩 Cryptocurrency-related risk indicators
* 🚩 Software/crack-related content indicators
* ⚠️ Low third-party reputation
* ⚠️ Limited independent reputation/history
* 🚩 Suspicious or unclear social-media links
* 🚨 1 external security-provider warning
* 🚨 Gridinsoft currently gives the domain only 1/100 trust

The domain was reportedly registered on July 7, 2026.

⚠️ IMPORTANT: I am NOT saying this proves that the owners are intentionally distributing malware. Gridinsoft itself says its classification is based largely on automated analysis, and automated systems can sometimes produce false positives.

However, considering that Bitcoin Puzzle #71 attracts people running GPU software, downloading tools, entering wallet information, and working with private keys, I think this deserves serious attention.

🚨 DO NOT:

* ❌ Download or execute unknown software from the site
* ❌ Enter private keys
* ❌ Enter seed phrases
* ❌ Connect wallets containing funds
* ❌ Give browser extensions or software unnecessary permissions
* ❌ Disable antivirus/security protections just to make something run

🔐 Until someone from the community independently audits exactly what the website is doing, I would treat it as **HIGH RISK**.

If anybody here has:

* 🔍 Inspected the site's JavaScript
* 🔍 Analyzed its browser GPU/WebGPU code
* 🔍 Captured its network requests
* 🔍 Downloaded and reverse-engineered any files it provides
* 🔍 Actually used the service

please post your findings.

It would be useful to determine whether this is:

⚠️ A genuine security problem
⚠️ A false positive caused by the site's Bitcoin/cracking terminology
⚠️ Or something else entirely

🚨🚨 **PUZZLE #71 HUNTERS — BE CAREFUL.** 🚨🚨

🔐 Never expose your private keys, wallet seeds, or systems holding BTC just because a website promises additional GPU search power.

⚠️ **VERIFY FIRST. TRUST LATER.** ⚠️

The rule is that the first person to see the private key will likely claim the prize for themselves and will fail to keep their promises to you. Do not trust any unknown person, website, or program; instead, rely on yourself and your own software.

[toshisa_toshisa]

I found something interesting during my search and wanted to hear what others think.

These are two results:

```
PubAddress: 1PWo3JeYEgBK9dt1egRP3rwMvxvUAnkv17
Priv (HEX): 0x659436EB201A7433FA

PubAddress: 1PWo3JeYEHBw7dfxuPzXB7TGK9jp886EH6
Priv (HEX): 0x659436EB210F344535
```

The private keys are quite close to each other:

```
659436EB201A7433FA
659436EB210F344535
```

Difference:

```
0xF4C0113B
= 4,106,228,027
```

What caught my attention is the addresses.

Character-by-character:

```
1PWo3JeYEgBK9dt1egRP3rwMvxvUAnkv17
1PWo3JeYEHBw7dfxuPzXB7TGK9jp886EH6
  ||||||||| |  |
```

They have the same characters at **11 out of 34 positions**.

Matching positions:

```
1  = 1
2  = P
3  = W
4  = o
5  = 3
6  = J
7  = e
8  = Y
9  = E
11 = B
14 = d
```

So both addresses start with exactly:

```
1PWo3JeYE
```

and they also match again at positions 11 and 14.

The important part is that I understand nearby private keys should NOT normally generate visually similar Bitcoin addresses. Because of EC public-key generation followed by SHA-256 and RIPEMD-160, small changes in the private key should effectively produce unrelated address hashes.

So my question is:

**Is this simply an interesting statistical coincidence, or is there anything worth investigating when two relatively close private keys generate addresses sharing this many characters in exactly the same positions?**

I'm not claiming there is a correlation. I'm interested in the probability/statistics behind seeing a pair like this.

Especially interested to hear from anyone who has done large-scale VanitySearch/KeyHunt scans and has seen similar clusters.

[bankeroft]

I found something interesting during my search and wanted to hear what others think.

These are two results:

```
PubAddress: 1PWo3JeYEgBK9dt1egRP3rwMvxvUAnkv17
Priv (HEX): 0x659436EB201A7433FA

PubAddress: 1PWo3JeYEHBw7dfxuPzXB7TGK9jp886EH6
Priv (HEX): 0x659436EB210F344535
```

The private keys are quite close to each other:

```
659436EB201A7433FA
659436EB210F344535
```

Difference:

```
0xF4C0113B
= 4,106,228,027
```

What caught my attention is the addresses.

Character-by-character:

```
1PWo3JeYEgBK9dt1egRP3rwMvxvUAnkv17
1PWo3JeYEHBw7dfxuPzXB7TGK9jp886EH6
  ||||||||| |  |
```

They have the same characters at **11 out of 34 positions**.

Matching positions:

```
1  = 1
2  = P
3  = W
4  = o
5  = 3
6  = J
7  = e
8  = Y
9  = E
11 = B
14 = d
```

So both addresses start with exactly:

```
1PWo3JeYE
```

and they also match again at positions 11 and 14.

The important part is that I understand nearby private keys should NOT normally generate visually similar Bitcoin addresses. Because of EC public-key generation followed by SHA-256 and RIPEMD-160, small changes in the private key should effectively produce unrelated address hashes.

So my question is:

**Is this simply an interesting statistical coincidence, or is there anything worth investigating when two relatively close private keys generate addresses sharing this many characters in exactly the same positions?**

I'm not claiming there is a correlation. I'm interested in the probability/statistics behind seeing a pair like this.

Especially interested to hear from anyone who has done large-scale VanitySearch/KeyHunt scans and has seen similar clusters.

rare statistical coincidence !!!

[detechs]

I found something interesting during my search and wanted to hear what others think.

These are two results:

```
PubAddress: 1PWo3JeYEgBK9dt1egRP3rwMvxvUAnkv17
Priv (HEX): 0x659436EB201A7433FA

PubAddress: 1PWo3JeYEHBw7dfxuPzXB7TGK9jp886EH6
Priv (HEX): 0x659436EB210F344535
```

The private keys are quite close to each other:

```
659436EB201A7433FA
659436EB210F344535
```

Difference:

```
0xF4C0113B
= 4,106,228,027
```

What caught my attention is the addresses.

Character-by-character:

```
1PWo3JeYEgBK9dt1egRP3rwMvxvUAnkv17
1PWo3JeYEHBw7dfxuPzXB7TGK9jp886EH6
  ||||||||| |  |
```

They have the same characters at **11 out of 34 positions**.

Matching positions:

```
1  = 1
2  = P
3  = W
4  = o
5  = 3
6  = J
7  = e
8  = Y
9  = E
11 = B
14 = d
```

So both addresses start with exactly:

```
1PWo3JeYE
```

and they also match again at positions 11 and 14.

The important part is that I understand nearby private keys should NOT normally generate visually similar Bitcoin addresses. Because of EC public-key generation followed by SHA-256 and RIPEMD-160, small changes in the private key should effectively produce unrelated address hashes.

So my question is:

**Is this simply an interesting statistical coincidence, or is there anything worth investigating when two relatively close private keys generate addresses sharing this many characters in exactly the same positions?**

I'm not claiming there is a correlation. I'm interested in the probability/statistics behind seeing a pair like this.

Especially interested to hear from anyone who has done large-scale VanitySearch/KeyHunt scans and has seen similar clusters.

Keep looking into it, cause I definitely am, anyone saying no pattern or coincidence is probably hoping u don't investigate it

[eggsylacer]

Did anyone manage to arrange the points on the curve in their own order?
Is this even possible? As far as I understand, something similar is implemented in the “kangaroo” algorithm.

[optioncmdPR]

It is possible. Regarding implementing and testing the results of customized elliptic curve parameters, you can play around with this:

Code:

P = 13407807929942597099574024998205846127479365820592393377723561443721764030073431184712636981971479856705023170278632780869088242247907112362425735876442206
  # 2^512 - 2^256 - 1954
Gx =0xf37cccfdf3b97758ab40c52b9d0e160e0537f9b65b9c51b2b3e502b62df02f30
Gy =0x9075b4ee4d4788cabb49f7f81c221151fa2f68914d0aa833388fa11ff621a970

def mod(a, b=P):
    res = a % b
    return res if res >= 0 else res + b

def mod_inverse(a, m=P):
    b, u, v = m, 0, 1
    old_a, old_u = a, 1
    while old_a != 0:
        q = b // old_a
        b, old_a = old_a, b - q * old_a
        u, old_u = old_u, u - q * old_u
    return mod(u, m)

def point_add(p1, p2):
    if not p1: return p2
    if not p2: return p1
    
    if p1['x'] == p2['x']:
        if p1['y'] != p2['y'] or p1['y'] == 0: 
            return None
        m = mod(3 * p1['x'] * p1['x'] * mod_inverse(2 * p1['y']))
        x = mod(m * m - 2 * p1['x'])
        y = mod(m * (p1['x'] - x) - p1['y'])
        return {'x': x, 'y': y}
    else:
        m = mod(mod(p2['y'] - p1['y']) * mod_inverse(mod(p2['x'] - p1['x'])))
        x = mod(m * m - p1['x'] - p2['x'])
        y = mod(m * (p1['x'] - x) - p1['y'])
        return {'x': x, 'y': y}

def point_multiply(k):
    if not k or k <= 0: 
        k = 1
    result = None
    addend = {'x': Gx, 'y': Gy}
    scalar = k
    while scalar > 0:
        if scalar & 1:
            result = point_add(result, addend)
        addend = point_add(addend, addend)
        scalar >>= 1
    return result or {'x': Gx, 'y': Gy}

def to_base_n(num: int, base: int) -> str:
    """Converts a large integer to a string representation in any base (2 to 10)."""
    if num == 0:
        return "0"
    digits = []
    while num > 0:
        digits.append(str(num % base))
        num //= base
    return "".join(reversed(digits))



if __name__ == "__main__":
    print("=== Elliptic Curve Scalar Multiplication ===")
    print("Supports Decimal (e.g., 5), Hex (0x05), or Binary (0b101)\n")
    
    try:
        # Prompt for input
        user_input = input("Enter scalar value: ").strip()
        
        # Determine format and parse dynamically
        if user_input.lower().startswith('0x'):
            scalar = int(user_input, 16)
        elif user_input.lower().startswith('0b'):
            scalar = int(user_input, 2)
        else:
            scalar = int(user_input)
            
        print("\nCalculating point multiplication...")
        public_key = point_multiply(scalar)
        
        x_val = public_key['x']
        y_val = public_key['y']
        
        # Display Results
        print("\n" + "="*60)
        print(f"Input Scalar (Decimal): {scalar}")
        print(f"Input Scalar (Hex):     {hex(scalar)}")
        print("="*60)
        
        print("\n--- POINT X COORDINATE ---")
        print(f"Base 10 : {x_val}")
        print(f"Base 9  : {to_base_n(x_val, 9)}")
        print(f"Base 5  : {to_base_n(x_val, 5)}")
        
        print("\n--- POINT Y COORDINATE ---")
        print(f"Base 10 : {y_val}")
        print(f"Base 9  : {to_base_n(y_val, 9)}")
        print(f"Base 5  : {to_base_n(y_val, 5)}")
        print("="*60)

    except ValueError:
        print("\n[Error] Invalid input format. Please check your value.")
    except Exception as e:
        print(f"\n[Error] An unexpected error occurred: {e}")

    # Final pause ensures the terminal window stays open
    input("\nProcess finished. Press Enter to close this window...")

[fecell]

hi, buddy!

how much points U can check at one sec with own programs?
i'v got 115m/s (at cold start) to 104-108m/s at work state with 1650ti (4gb, notebook).  
for 140bits.

whats 'bout Ur algo?

Code:

[15:51:34] [+] [C 21,706 / 2,596,148,429,267,413,814,265,248,164,610,048] [11,653,320,015,872 / 696,898,287,454,081,973,172,991,196,020,261,297,061,888 prob] S: 104591380.9 pr/s, E: 1d 06:56:57, ETA: 3.390e+26 y, exp-ETA: 1.353e+17 y, progress: 0.0000%

It is possible. Regarding implementing and testing the results of customized elliptic curve parameters, you can play around with this:

sure. it's like child playing game.!

[eggsylacer]

It is possible. Regarding implementing and testing the results of customized elliptic curve parameters, you can play around with this:

Code:

P = 13407807929942597099574024998205846127479365820592393377723561443721764030073431184712636981971479856705023170278632780869088242247907112362425735876442206
  # 2^512 - 2^256 - 1954
Gx =0xf37cccfdf3b97758ab40c52b9d0e160e0537f9b65b9c51b2b3e502b62df02f30
Gy =0x9075b4ee4d4788cabb49f7f81c221151fa2f68914d0aa833388fa11ff621a970

def mod(a, b=P):
    res = a % b
    return res if res >= 0 else res + b

def mod_inverse(a, m=P):
    b, u, v = m, 0, 1
    old_a, old_u = a, 1
    while old_a != 0:
        q = b // old_a
        b, old_a = old_a, b - q * old_a
        u, old_u = old_u, u - q * old_u
    return mod(u, m)

def point_add(p1, p2):
    if not p1: return p2
    if not p2: return p1
    
    if p1['x'] == p2['x']:
        if p1['y'] != p2['y'] or p1['y'] == 0: 
            return None
        m = mod(3 * p1['x'] * p1['x'] * mod_inverse(2 * p1['y']))
        x = mod(m * m - 2 * p1['x'])
        y = mod(m * (p1['x'] - x) - p1['y'])
        return {'x': x, 'y': y}
    else:
        m = mod(mod(p2['y'] - p1['y']) * mod_inverse(mod(p2['x'] - p1['x'])))
        x = mod(m * m - p1['x'] - p2['x'])
        y = mod(m * (p1['x'] - x) - p1['y'])
        return {'x': x, 'y': y}

def point_multiply(k):
    if not k or k <= 0: 
        k = 1
    result = None
    addend = {'x': Gx, 'y': Gy}
    scalar = k
    while scalar > 0:
        if scalar & 1:
            result = point_add(result, addend)
        addend = point_add(addend, addend)
        scalar >>= 1
    return result or {'x': Gx, 'y': Gy}

def to_base_n(num: int, base: int) -> str:
    """Converts a large integer to a string representation in any base (2 to 10)."""
    if num == 0:
        return "0"
    digits = []
    while num > 0:
        digits.append(str(num % base))
        num //= base
    return "".join(reversed(digits))



if __name__ == "__main__":
    print("=== Elliptic Curve Scalar Multiplication ===")
    print("Supports Decimal (e.g., 5), Hex (0x05), or Binary (0b101)\n")
    
    try:
        # Prompt for input
        user_input = input("Enter scalar value: ").strip()
        
        # Determine format and parse dynamically
        if user_input.lower().startswith('0x'):
            scalar = int(user_input, 16)
        elif user_input.lower().startswith('0b'):
            scalar = int(user_input, 2)
        else:
            scalar = int(user_input)
            
        print("\nCalculating point multiplication...")
        public_key = point_multiply(scalar)
        
        x_val = public_key['x']
        y_val = public_key['y']
        
        # Display Results
        print("\n" + "="*60)
        print(f"Input Scalar (Decimal): {scalar}")
        print(f"Input Scalar (Hex):     {hex(scalar)}")
        print("="*60)
        
        print("\n--- POINT X COORDINATE ---")
        print(f"Base 10 : {x_val}")
        print(f"Base 9  : {to_base_n(x_val, 9)}")
        print(f"Base 5  : {to_base_n(x_val, 5)}")
        
        print("\n--- POINT Y COORDINATE ---")
        print(f"Base 10 : {y_val}")
        print(f"Base 9  : {to_base_n(y_val, 9)}")
        print(f"Base 5  : {to_base_n(y_val, 5)}")
        print("="*60)

    except ValueError:
        print("\n[Error] Invalid input format. Please check your value.")
    except Exception as e:
        print(f"\n[Error] An unexpected error occurred: {e}")

    # Final pause ensures the terminal window stays open
    input("\nProcess finished. Press Enter to close this window...")

Buddy, I don't need an intermediary between me and the AI. No hard feelings.
Moreover, the question was deliberately constructed in such a way that the AI couldn’t understand it, while someone who truly understands the topic could.

[Igor_cherkassy]

Hi. I’ll share the 1.121.996 keys I’ve collected.


1PWo3JeB9jrG         3         
1PWo3JeB9jr          22       
1PWo3JeB9j           413       
1PWo3JeB9            22346     
1PWo3JeB             1121996

 https://mega.nz/file/kjQ1xbZL#EIm-r_tyaq2xFChIFuTv2wMgmGS-NI2-J0NIFc7yV7g

18Aa9hXYH84UAoKWHZ9LTeF19KjMgb5FGX   I accept donations.

[fecell]

Hi. I’ll share the 1.121.996 keys I’ve collected.


1PWo3JeB9jrG         3        
1PWo3JeB9jr          22        
1PWo3JeB9j           413      
1PWo3JeB9            22346    
1PWo3JeB             1.121.996

 https://mega.nz/file/kjQ1xbZL#EIm-r_tyaq2xFChIFuTv2wMgmGS-NI2-J0NIFc7yV7g

18Aa9hXYH84UAoKWHZ9LTeF19KjMgb5FGX   I accept donations.

Nice job! 

[zahid888]

What if some puzzle keys are hidden inside the SHA-256 hashes of well-known passwords? Has anyone explored this possibility?

Or Minikeys 

Searching the Puzzle 2^36 to 2^256 range using randomly generated 30-character MiniKeys.

Code:

 [+] Bloom filters ready    : Exact + Prefix
 [+] Bloom filter           : 256 Addresses Loaded
[/] Total Speed: 853.31 MK/s [/] [00:00:18 Elapsed Time] [Progress: 11 %] | Prefix [0]

======================================================================================
|                    Total Matching character in hash160: 14                         |
|------------------------------------------------------------------------------------|
| 19vnME8b8YNFd17LtuuuoLNveWRAVkhBW 01b038f889edfabc3c311cb11655e5c4d98279a4         |
| 19vnME8b28SzJDuEFNShAG5JCR63V1zzV 01b038f889ed602266f2c6647f657713e52d8cac         |
| ^^^^^^^^                    ^     ^^^^^^^^^^^^               ^          ^          |
|------------------------------------------------------------------------------------|
|  Password    : SzpVJYetsiQAEjw6DfHdepby83ghRE                                      |
|  SHA256      : 3895570417E1E3EE0BE2E46173003B883A9703ACB8D7CA6FDB23659B434B124D    |
|--------------------------[ Puzzle 191 | Private Key 195 ]--------------------------|
|  Private Key : 000000000000000417E1E3EE0BE2E46173003B883A9703ACB8D7CA6FDB2370DB    |
|  Public Key  : 029185053F29E58783DB02F8D7024EC5692B3EE6F308B36CE08903D348FE237771  |
======================================================================================

[/] Total Speed: 872.31 MK/s [/] [00:00:30 Elapsed Time] [Progress: 19 %] | Prefix [1]

======================================================================================
|                    Total Matching character in hash160: 16                         |
|------------------------------------------------------------------------------------|
| 1BDTXmiyz2AAYJ176WEaKs9JYRsZrAEgfb 700c655d586d3a0a3253e3ad0d19e0b3720cae4c        |
| 1BDTXmiyyzq9i79RGGTW7cjmYJbxKoV27e 700c655d586d1a06b0185b12007a1b195d60271c        |
| ^^^^^^^^                ^          ^^^^^^^^^^^^ ^^         ^              ^        |
|------------------------------------------------------------------------------------|
|  Password    : SNMHjagBQM5GtYbXw7UhpJFuhjvfvY                                      |
|  SHA256      : 7792E421D3B717C58F5657632D8FD34525E263B59176682073175BF6D4C89D7D    |
|--------------------------[ Puzzle 218 | Private Key 115 ]--------------------------|
|  Private Key : 00000000000000000000000000000000000525E263B59176682073175BF6DAE2    |
|  Public Key  : 02D53387ECFDDADE19700DB16A6747C2CFC751BC23D351BD35056D05E9B9ADFF0B  |
======================================================================================

[\] Total Speed: 938.24 MK/s [\] [00:00:40 Elapsed Time] [Progress: 27 %] | Prefix [2]

======================================================================================
|                    Total Matching character in hash160: 14                         |
|------------------------------------------------------------------------------------|
| 1F3JRMWudHPNTYL4TNDM68J4hv7D7Umf2R 9a012260d01cdd041139a0a959a97a043d380911        |
| 1F3JRMWudBaj48EhwcHDdpeuy2jwACNxjP 9a012260d01c5113df66c8a8438c9f7a1e3d5dac        |
| ^^^^^^^^^                          ^^^^^^^^^^^^          ^           ^             |
|------------------------------------------------------------------------------------|
|  Password    : SUAuiM3MqyJLFn5qxi4Rx1ppWC4vZC                                      |
|  SHA256      : 4593B69A135B6354FBF00981CA6EC4B848450995664C5BD379EC2A70C83AC2D0    |
|--------------------------[ Puzzle 046 | Private Key 119 ]--------------------------|
|  Private Key : 000000000000000000000000000000000054FBF00981CA6EC4B8484509957F66    |
|  Public Key  : 02B1B0153E5968685D6E02F2E8DD766C82EE32391642475DA7F20BB74E5A139AC3  |
======================================================================================

[|] Total Speed: 936.14 MK/s [|] [00:00:54 Elapsed Time] [Progress: 37 %] | Prefix [3]

Final Stats:
Elapsed Time: 55.14 seconds
Partials Found: 3
======================================================================================
 [+] Bloom filters ready    : Exact + Prefix
 [+] Bloom filter           : 256 Addresses Loaded
[\] Total Speed: 929.51 MK/s [\] [00:00:12 Elapsed Time] [Progress: 8 %] | Prefix [0]

======================================================================================
|                    Total Matching character in hash160: 40                         |
|------------------------------------------------------------------------------------|
| 1HBtApAFA9B2YZw3G2YKSMCtb3dVnjuNe2 b190e2d40cfdeee2cee072954a2be89e7ba39364        |
| 1HBtApAFA9B2YZw3G2YKSMCtb3dVnjuNe2 b190e2d40cfdeee2cee072954a2be89e7ba39364        |
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^        |
|------------------------------------------------------------------------------------|
|  Password    : S2P233E6QVjwny8kSDNYyvomGMgCqH                                      |
|  SHA256      : F22382FAD2BF3391774DA02F91F0EDEC66472C26AAB8DEECA22E77B6063CB996    |
|--------------------------[ Puzzle 038 | Private Key 038 ]--------------------------|
|  Private Key : 00000000000000000000000000000000000000000000000000000022382FACD0    |
|  Public Key  : 03C060E1E3771CBECCB38E119C2414702F3F5181A89652538851D2E3886BDD70C6  |
======================================================================================

===============================|  [ Target Found ]  |=================================
Press any key to exit or wait 60 seconds...
Exiting in 1 seconds...


Final Stats:
Elapsed Time: 73.02 seconds
Partials Found: 0
======================================================================================

 [+] Bloom filters ready    : Exact + Prefix
 [+] Bloom filter           : 256 Addresses Loaded
[\] Total Speed: 813.27 MK/s [\] [00:00:08 Elapsed Time] [Progress: 5 %] | Prefix [0]

======================================================================================
|                    Total Matching character in hash160: 40                         |
|------------------------------------------------------------------------------------|
| 1EeAxcprB2PpCnr34VfZdFrkUWuxyiNEFv 95a156cd21b4a69de969eb6716864f4c8b82a82a        |
| 1EeAxcprB2PpCnr34VfZdFrkUWuxyiNEFv 95a156cd21b4a69de969eb6716864f4c8b82a82a        |
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^        |
|------------------------------------------------------------------------------------|
|  Password    : SkPGu1odkUrfMSKETmUMEcHFC9H3DK                                      |
|  SHA256      : B4C13307F6D2B0BDD718147B97AAD9E9AE493130ADF935C4C374C13FBA0F97DC    |
|--------------------------[ Puzzle 040 | Private Key 040 ]--------------------------|
|  Private Key : 000000000000000000000000000000000000000000000000000000E9AE4933D6    |
|  Public Key  : 03A2EFA402FD5268400C77C20E574BA86409EDEDEE7C4020E4B9F0EDBEE53DE0D4  |
======================================================================================

===============================|  [ Target Found ]  |=================================
Press any key to exit or wait 60 seconds...
Exiting in 1 seconds...

Managed to hit 2^50, 2^51, and 2^52 in a single night of searching. I don't think any existing tool can hit a 2^52 private key in just a few hours while keeping the search fully random.

Code:

000000000000000000000000000000000000000000000000000EFAE164CB9E3C  15z9c9sVpu6fwNiK7dMAFgMYSK4GqsGZim  target: 15z9c9sVpu6fwNiK7dMAFgMYSK4GqsGZim Password: HS9rHARSH8rbS8RS
000000000000000000000000000000000000000000000000000EFAE164CB9E3C  15z9c9sVpu6fwNiK7dMAFgMYSK4GqsGZim  target: 15z9c9sVpu6fwNiK7dMAFgMYSK4GqsGZim Password: szRj8si1jSaizZJS
00000000000000000000000000000000000000000000000000022BD43C2E9354  1MEzite4ReNuWaL5Ds17ePKt2dCxWEofwk  target: 1MEzite4ReNuWaL5Ds17ePKt2dCxWEofwk Password: JSsaRS9iSbZHaJJA
000000000000000000000000000000000000000000000000000174176B015F4D  12CiUhYVTTH33w3SPUBqcpMoqnApAV4WCF  target: 12CiUhYVTTH33w3SPUBqcpMoqnApAV4WCF Password: Rri88sbiH1JzSJZS
000000000000000000000000000000000000000000000000000EFAE164CB9E3C  15z9c9sVpu6fwNiK7dMAFgMYSK4GqsGZim  target: 15z9c9sVpu6fwNiK7dMAFgMYSK4GqsGZim Password: 9HrSZAARs8iZ1aRS
00000000000000000000000000000000000000000000000000075070A1A009D4  1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS  target: 1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS Password: rZjSSZ8jJRs1b9Zi

For those who are always asking for tools: if I manage to hit any unsolved puzzle, 20+ Best GPU and CPU tools will be released as 100% open source for the entire community.

[albert0bsd]

Keep looking into it, cause I definitely am, anyone saying no pattern or coincidence is probably hoping u don't investigate it

Anyone knowing how (publickey - sha256 - rmd160 - base58) works must know that its not relationship between them...

rare statistical coincidence !!!

Exactly

[puzzle_72_worker]

Puzzle 71 have same difficulty as Puzzle 72.
Now all haters will say: i need glasses, i have no ideea...that puzzle 72 is double than 71...

Wrong! After you will see this theory, you will understand the puzzles. Who will discover the puzzle 71, puzzle 72 can be found in seconds with same method, now if you do bruteforce like monkeys, you will have double difficulty...
Will be funny if anyone will see this...

[Dapud0886]

Keep looking into it, cause I definitely am, anyone saying no pattern or coincidence is probably hoping u don't investigate it

Anyone knowing how (publickey - sha256 - rmd160 - base58) works must know that its not relationship between them...

rare statistical coincidence !!!

Exactly

Long time no see

[SittingDuck52]

Two things for anyone running CUDACyclone on puzzle 71 or 72.

1. A bug that silently skips keys. When a warp hits a hash160 prefix match without a full match, it returns without saving its state, so the rest of that batch is never checked - and the run still reports "KEY NOT FOUND (exhaustive)". I reproduced it with a debug build using a 20-bit prefix compare, which makes that path about 4096x more likely: 4 of 10 planted keys were missed. With a four-line fix it finds 10 of 10, at no measurable cost (1,820-1,831 Mkey/s on an RTX 5060 Ti, same as before).

Details and the patch: https://github.com/Dookoo2/CUDACyclone/pull/16

In normal operation the effect is small - I estimate 0.02 to 0.05 % of a range stays unchecked, scattered across it - but it is there, and "exhaustive" is then not exhaustive. The repo looks unmaintained (last push September 2025), so the PR is still open.

2. Windows build and resume. Stock CUDACyclone does not compile with MSVC (__int128) and cannot continue an interrupted run. My fork has both - a GitHub Actions workflow that builds the exe, and --resume-batches/--resume-threads, which take a checkpoint every one to two minutes: https://github.com/SittingDuck52/CUDACyclone (the Windows part is PR #17 against the original)

And the reason I needed all of this: a PowerShell dashboard that runs BitCrack or CUDACyclone unattended on Windows. Random share per GPU, checkpoints, a list of finished shares so nothing is searched twice, automatic pause when another program needs the card, web page, MQTT for Home Assistant, German and English.

https://github.com/SittingDuck52/Heuhaufen

It does not make the search faster, it just keeps it running. On my card CUDACyclone does 1,720 Mkey/s at 150 W where BitCrack does 991. The only binary in the repo is BitCrack's, built by GitHub Actions with the workflow included; CUDACyclone you build yourself from the fork - for obvious reasons I would not download a key searcher as a stranger's exe either. MIT licensed, no telemetry, nothing is sent anywhere.

[KarTonP]

So, friends, I need someone with a lot of computing power to test a certain area using the Kangaro method. Ideally, a batch of 8–12 graphics cards better than the 4k+. I need to test a new theory. On the 140 puzzle—if you’re interested, send me a DM.

[brainless]

Two things for anyone running CUDACyclone on puzzle 71 or 72.

1. A bug that silently skips keys. When a warp hits a hash160 prefix match without a full match, it returns without saving its state, so the rest of that batch is never checked - and the run still reports "KEY NOT FOUND (exhaustive)". I reproduced it with a debug build using a 20-bit prefix compare, which makes that path about 4096x more likely: 4 of 10 planted keys were missed. With a four-line fix it finds 10 of 10, at no measurable cost (1,820-1,831 Mkey/s on an RTX 5060 Ti, same as before).

Details and the patch: https://github.com/Dookoo2/CUDACyclone/pull/16

In normal operation the effect is small - I estimate 0.02 to 0.05 % of a range stays unchecked, scattered across it - but it is there, and "exhaustive" is then not exhaustive. The repo looks unmaintained (last push September 2025), so the PR is still open.

2. Windows build and resume. Stock CUDACyclone does not compile with MSVC (__int128) and cannot continue an interrupted run. My fork has both - a GitHub Actions workflow that builds the exe, and --resume-batches/--resume-threads, which take a checkpoint every one to two minutes: https://github.com/SittingDuck52/CUDACyclone (the Windows part is PR #17 against the original)

And the reason I needed all of this: a PowerShell dashboard that runs BitCrack or CUDACyclone unattended on Windows. Random share per GPU, checkpoints, a list of finished shares so nothing is searched twice, automatic pause when another program needs the card, web page, MQTT for Home Assistant, German and English.

https://github.com/SittingDuck52/Heuhaufen

It does not make the search faster, it just keeps it running. On my card CUDACyclone does 1,720 Mkey/s at 150 W where BitCrack does 991. The only binary in the repo is BitCrack's, built by GitHub Actions with the workflow included; CUDACyclone you build yourself from the fork - for obvious reasons I would not download a key searcher as a stranger's exe either. MIT licensed, no telemetry, nothing is sent anywhere.

If you add cuda 10.2 version
Where gpu compute compatibility 30 gcc 9
95%community user use 30 to 65 compute C GPUs
Only few power user uses 3070 to 5090 GPUs

2nd function inside cuda cyclone required
Load range list
Start:end
Start:end
Cpu version have this function

3rd
Inside start:end range
Check and stride example
Check 10000 stride 50000
User level input for check and stride

In by default bitcrack or cuda cyclone
Stride is available for user input but check is 1 only
Mean check 1 and stride 123456 etc
Hope these info help you to make product more better workable

[SittingDuck52]

Two things for anyone running CUDACyclone on puzzle 71 or 72.

1. A bug that silently skips keys. When a warp hits a hash160 prefix match without a full match, it returns without saving its state, so the rest of that batch is never checked - and the run still reports "KEY NOT FOUND (exhaustive)". I reproduced it with a debug build using a 20-bit prefix compare, which makes that path about 4096x more likely: 4 of 10 planted keys were missed. With a four-line fix it finds 10 of 10, at no measurable cost (1,820-1,831 Mkey/s on an RTX 5060 Ti, same as before).

Details and the patch: https://github.com/Dookoo2/CUDACyclone/pull/16

In normal operation the effect is small - I estimate 0.02 to 0.05 % of a range stays unchecked, scattered across it - but it is there, and "exhaustive" is then not exhaustive. The repo looks unmaintained (last push September 2025), so the PR is still open.

2. Windows build and resume. Stock CUDACyclone does not compile with MSVC (__int128) and cannot continue an interrupted run. My fork has both - a GitHub Actions workflow that builds the exe, and --resume-batches/--resume-threads, which take a checkpoint every one to two minutes: https://github.com/SittingDuck52/CUDACyclone (the Windows part is PR #17 against the original)

And the reason I needed all of this: a PowerShell dashboard that runs BitCrack or CUDACyclone unattended on Windows. Random share per GPU, checkpoints, a list of finished shares so nothing is searched twice, automatic pause when another program needs the card, web page, MQTT for Home Assistant, German and English.

https://github.com/SittingDuck52/Heuhaufen

It does not make the search faster, it just keeps it running. On my card CUDACyclone does 1,720 Mkey/s at 150 W where BitCrack does 991. The only binary in the repo is BitCrack's, built by GitHub Actions with the workflow included; CUDACyclone you build yourself from the fork - for obvious reasons I would not download a key searcher as a stranger's exe either. MIT licensed, no telemetry, nothing is sent anywhere.

If you add cuda 10.2 version
Where gpu compute compatibility 30 gcc 9
95%community user use 30 to 65 compute C GPUs
Only few power user uses 3070 to 5090 GPUs

2nd function inside cuda cyclone required
Load range list
Start:end
Start:end
Cpu version have this function

3rd
Inside start:end range
Check and stride example
Check 10000 stride 50000
User level input for check and stride

In by default bitcrack or cuda cyclone
Stride is available for user input but check is 1 only
Mean check 1 and stride 123456 etc
Hope these info help you to make product more better workable

Thanks - the first point was a fair hit, the other two are out of my hands. Details:

Old cards. My fork only built for sm_75/86/89/120, so anything before Turing could not even start the exe. That is fixed: the workflow now also builds 5.0, 5.2, 6.0, 6.1 and 7.0, which covers GTX 750 Ti, the 900 series, the 10 series and the 16 series. No CUDA 10.2 needed for that - CUDA 12.9 still supports compute capability 5.0 and up, it was simply a missing line in the build. Kepler (3.x) is the real cutoff: CUDA 12 dropped it, so those cards would need a separate build with CUDA 11.8, which I am not set up for.

One caveat: nvcc already warns that support for anything below sm_75 will be dropped in a future CUDA release, so this is a reprieve, not a permanent fix. And I cannot test any of it - I only have a 5060 Ti here. If someone with an older card tries the build from the Actions tab and reports back whether it runs and at what speed, I will put that in the README: https://github.com/SittingDuck52/CUDACyclone

Range list and check/stride. Both are changes inside CUDACyclone itself, not in the Windows build. My fork only adds the MSVC build, resume, and the fix for skipped keys - I did not write the kernel and I am not planning to extend it. The upstream repo looks unmaintained (last push September 2025, my two pull requests are still open), so the honest answer is that this would need someone to pick the project up.

If you build the CPU version's range-list handling into it, I will happily merge a pull request.

[Grzegorz2022]

Hi, could you share how many keys you have scanned so far for puzzle 140? I'm not asking about the range

[optioncmdPR]

Hey,I wanted to share some thoughts on an observation in the spelling out of "saatoshi_rising" as a hint associated with 16-bit register width derivation structure. The infamous statement "There is no pattern. It is just consecutive keys from a deterministic wallet" does not interfere with this observation and remains technically accurate. A test of ones ability to see what it says vs what it could have said but ommited. Lets start with "there is no pattern" which is true. And that's because it is a function / operation that was implemented which does not lead to any observable pattern. The core difference comes down to cause versus effect. An operation based on rules is the active recipe or mechanism that forces a calculation to happen, while a pattern is the visible design, shape, or repetition that results from applying those rules.  an operation is not a pattern but people have noted several structural anomalies and statistically improbable occurances of repeating byte chunks, which do not form a pattern. This is what can occur and what you will see when you have a purely random base structure at start and then introduce any type of ordered operation to it, no matter how subtle. What I see (and you likely have as well and dont want to discuss it out of fear of someone figuring it out before you) strongly suggest a deliberate reduction in entropy to make brute-forcing the higher-tier keys achievable. This was done because after a certain point, probably starting at puzzle 2^65, brute force was less and less feasible so keys were designed to be half solved by a multi operation logic that sourced bytes of previous puzzles then concatenated to a random portion to be resolved by brute force. Back to the name saatoshi_rising and what it could mean, here is the why I feel a 16-bit architecture hint fits into this puzzle: First, there is the 'Typo Theory' regarding the name "saatoshi". The double "aa" maybe an anagram or a low-level instruction hint. In legacy 16-bit x86 assembly language and register architectures, "aa" commonly refers to ASCII Adjust instructions, like AAA (ASCII Adjust after Addition). Alternatively, in 16-bit internal architecture, registers are broken into High and Low bytes—for example, the AX register is composed of AH and AL. Doubling the letter implies a repeated 8-bit block forming a 16-bit word (AA).Second, look at the Deterministic Masking Model. The original puzzle was funded by choosing keys from explicitly restricted spaces. For instance, Puzzle 16 maps to a key space between 2^15 and 2^16, while Puzzle 32 maps between 2^31 and 2^32.Because the keys are constrained to these exact bit-boundary thresholds, the creator likely utilized.....drumroll.... deterministic masking. If the master private key or seed was passed through a legacy 16-bit hashing or shifting function, the resulting keys would naturally fall into predictable, truncated segments. By analyzing the keys that have already been solved, we can look for a specific 16-bit stride or offset pattern. I'll tell you what Ive seen: too many puzzles like 66, which blatently have what I call " seams " and that is two or three or more points where the number stops being random , copies itself, reverses the copy and concatenates it then applies some method to stretch it out slightly :  
46346217550346335726
move the third occurance of 46 to the end
463462175503  335726
                     46 -->
46346217550333572646
observe :
463|4621755033357264|6

 alternatively look for "0" stretched 16 bit block ( everywhere in puzzles )
463|462175503|46335726
       46217553   rotate >> 35571264 and then re insert.

result: 4633557126446335726

split  4633557126   446335726

stack
  4633557126
  446335726

open your minds people. We can do this. Lets revert the Rubix Cube back to its starting point, because thats where you will find the unsolved keys.