THE BITCOIN PUZZLE (1000 BTC CHALLENGE)-Complete Deep Research — From A to Z

Blog July 19, 2026

 

THE BITCOIN PUZZLE (1000 BTC CHALLENGE)

Complete Deep Research — From A to Z

Compiled: July 2026
Context: The 1000 BTC Challenge is the most famous cryptographic treasure hunt in Bitcoin history, serving as a real-time benchmark of elliptic curve security.

PART I: FOUNDATIONS — HOW BITCOIN WORKS

1.1 Public-Key Cryptography Overview

Bitcoin's security model is built entirely on asymmetric (public-key) cryptography. Every Bitcoin user controls a private key (a secret 256-bit integer) from which a public key is derived, and from that public key, a Bitcoin address is hashed. The system works because:

  • Derivation is easy: private key → public key (one-way scalar multiplication on an elliptic curve)
  • Inversion is computationally infeasible: public key → private key (the Elliptic Curve Discrete Logarithm Problem, ECDLP)

1.2 secp256k1 — The Elliptic Curve

Bitcoin uses the secp256k1 curve, defined by the Standards for Efficient Cryptography Group (SECG):

Curve equation:  y² = x³ + 7   (over the field Fₚ)

Prime modulus p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F
                 = 2²⁵⁶ − 2³² − 2⁹ − 2⁸ − 2⁷ − 2⁶ − 2⁴ − 1

Order n         = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

Generator point G:
  Gx = 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
  Gy = 0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8

Cofactor h = 1

Key properties:

  • p ≈ 2²⁵⁶ — the field is a 256-bit prime field
  • n ≈ 2²⁵⁶ — the curve order is also ~2²⁵⁶, meaning private keys are uniformly distributed in [1, n−1]
  • Koblitz curve (a = 0, b = 7) — chosen for efficiency; has special endomorphism properties that speed up computation by ~2x
  • p ≡ 3 (mod 4) — enables efficient square root computation via Euler's criterion: √y = y^(p+1)/4 mod p

1.3 ECDSA — Elliptic Curve Digital Signature Algorithm

When you spend Bitcoin, you produce an ECDSA signature proving you know the private key without revealing it.

Key Generation

Private key: d = random integer in [1, n−1]
Public key:  Q = d × G  (elliptic curve scalar multiplication)

Signing (spending Bitcoin)

1. Generate random nonce k ∈ [1, n−1]
2. Compute R = k × G, let r = R.x mod n
3. Compute s = k⁻¹ × (hash(message) + d × r) mod n
4. Signature = (r, s)

Verification

1. Compute u₁ = hash(message) × s⁻¹ mod n
2. Compute u₂ = r × s⁻¹ mod n
3. Compute R' = u₁ × G + u₂ × Q
4. Valid if R'.x ≡ r (mod n)

Critical security note: The nonce k MUST be:

  • Unique per signature — reusing k with the same private key lets anyone compute d = (s₁ − s₂)⁻¹ × (k₁ − k₂)... but with same k, r is the same and the private key falls out trivially.
  • Random — if k is predictable or biased, lattice attacks can recover the key from multiple signatures (the HackerOne PS3 incident, the Android Java RNG disaster, and numerous blockchain hacks).

Why Public Key Exposure Changes Everything

A Bitcoin address is a hash of the public key (RIPEMD-160 of SHA-256). When you spend from an address, the public key is revealed in the transaction input. Before that moment, an attacker only sees the hash — they cannot even apply ECDLP algorithms.

This is the fundamental security layering of Bitcoin:

  • Unspent P2PKH address: attacker only has the hash → must brute-force the private key space (O(2²⁵⁶))
  • After first spend: public key is revealed → attacker can apply Pollard's Kangaroo (O(2¹²⁸))
  • P2PK (Pay-to-Public-Key): public key is visible from the start → always vulnerable to ECDLP solvers

1.4 Bitcoin Address Types

P2PK (Pay to Public Key)

  • Script: <pubkey> OP_CHECKSIG
  • Public key directly visible on-chain — never hashed
  • Used in early Bitcoin (2009-2010), including Satoshi's coins
  • Always vulnerable to quantum/ECDLP attacks since the key is exposed

P2PKH (Pay to Public Key Hash) — Legacy addresses (1...)

  • Script: OP_DUP OP_HASH160 <pubkey_hash> OP_EQUALVERIFY OP_CHECKSIG
  • Address = Base58Check(RIPEMD160(SHA256(pubkey)))
  • Starts with '1' (e.g., 1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH)
  • Public key hidden until first spend

P2SH (Pay to Script Hash) — 3... addresses

  • Address starts with '3'
  • Can wrap SegWit (P2SH-P2WPKH)

P2WPKH (Native SegWit) — bc1q... addresses

  • Bech32 encoded
  • Lower fees, signature malleability fixed
  • Still hashes the public key until first spend

P2TR (Taproot) — bc1p... addresses

  • Schnorr signatures, not ECDSA
  • Key aggregation, MAST, better privacy

1.5 Transaction Structure

A Bitcoin transaction has:

  • Inputs: references to previous outputs + unlocking script (signature + public key)
  • Outputs: value + locking script (recipient address conditions)

The funding transaction for the puzzle (TXID: 08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15) created 256 outputs, each locked to a different address with progressively increasing amounts.

PART II: BITCOIN PUZZLE — COMPLETE HISTORY

2.1 The Original Creation (January 15, 2015)

On 2015-01-15, an anonymous user created a transaction in block 339085 that sent Bitcoin to 256 different addresses. The amounts were tiny but followed a pattern:

Puzzle #1:   0.001 BTC  (key in range [2⁰, 2¹-1] = [1, 1])
Puzzle #2:   0.002 BTC  (key in range [2¹, 2²-1] = [2, 3])
Puzzle #3:   0.003 BTC  (key in range [2², 2³-1] = [4, 7])
...
Puzzle #N:   0.00N BTC  (key in range [2^(N-1), 2^N-1])
...
Puzzle #256: 0.256 BTC  (key in range [2²⁵⁵, 2²⁵⁶-1])

Total original funding: ~32.9 BTC

The creator's stated purpose (from their BitcoinTalk post):

"There is no pattern. It is just consecutive keys from a deterministic wallet (masked with leading 000...0001 to set difficulty). It is simply a crude measuring instrument, of the cracking strength of the community."

This quote is extremely important — the creator explicitly stated:

  1. The keys come from a deterministic wallet (this is the BIP32 angle)
  2. They are masked with leading zeros to set the difficulty range
  3. It's a measuring instrument — a benchmark for community cracking power

2.2 The First Refill — 10x Increase (July 11, 2017)

In block 475240 (2017-07-11), the creator moved funds from addresses #161–#256 (which had never been solved and were in practically unsolvable ranges) to the lower-range addresses #53–#160. This effectively:

  • Increased the prize pool by redistributing value
  • Concentrated the rewards on solvable ranges
  • Hinted that the creator expected progress up to ~160-bit, but not beyond

At this point, puzzles #1–#50 had already been solved (most in the first days/weeks).

2.3 The Public Key Leak — 1000-Satoshi Transactions (May 31, 2019)

This is the most pivotal event in the puzzle's history for researchers.

On 2019-05-31, the creator sent 1,000-satoshi transactions from every 5th puzzle address:

  • #65, #70, #75, #80, #85, #90, #95, #100, #105, #110, #115, #120, #125, #130, #135, #140, #145, #150, #155, #160

Why this matters: Spending from an address reveals the public key on-chain. Before this, solvers could only brute-force by testing private keys against address hashes (O(2^N) complexity). After the leak, those 20 addresses had exposed public keys, enabling:

  • Pollard's Kangaroo algorithm — reduces complexity from O(2^N) to O(2^(N/2))
  • Baby-Step Giant-Step — O(√N) with O(√N) memory

This was likely intentional — the creator wanted to benchmark the community's ability to solve ECDLP directly, vs. brute-forcing addresses.

The creator's stated purpose: "comparing the difficulty of finding a private key for the address from which such a transaction was carried out, and one that has no transaction."

2.4 The Mega Refill — ~1000 BTC (April 16, 2023)

On 2023-04-16, the creator dropped the bombshell: every unsolved puzzle's prize was increased approximately 10x again, bringing the total pool to ~1,000 BTC.

Current rewards:

Puzzle #66:   6.6 BTC
Puzzle #67:   6.7 BTC
Puzzle #68:   6.8 BTC
...
Puzzle #125:  12.5 BTC
...
Puzzle #160:  16.0 BTC

The total value (~$60M+ at current prices) made this the largest cryptographic puzzle prize pool in history. The timing — during the 2023 bull market — was not coincidental.

2.5 The Great Solves of 2024-2025

Puzzle #66 (September 12, 2024) — 6.6 BTC (~$400K)

  • The watershed moment. First high-value solve in years.
  • The solver broadcast the transaction publicly; bots in the mempool extracted the private key from the public key (the transaction revealed the public key in the input, and once that was known, Kangaroo recovered the private key) and front-ran the original transaction with a higher fee.
  • The prize was mostly stolen.
  • This exposed a critical OpSec vulnerability in puzzle solving.

Puzzle #67 (February 21, 2025) — 6.7 BTC

  • The solver learned from #66: bypassed the public mempool entirely.
  • Used a private mining service (likely MARA Slipstream or similar) to submit the transaction directly to a mining pool.
  • Successfully claimed the full prize.

Puzzle #68 (April 7, 2025) — 6.8 BTC

  • Also solved via private mining bypass.
  • Offline key recovery confirmed the BIP32 theory.

Puzzle #69 (April 30, 2025) — 6.9 BTC

  • Discovered at just 0.72% into the search range — very early in the key space.
  • The solver broadcast publicly (repeating #66's mistake).
  • Stolen again — bots extracted the public key from the mempool, ran Kangaroo, computed the private key from the range, and replaced the transaction multiple times.
  • The mempool theft problem was now a known exploit with a known mitigation (private mining), yet solvers kept making the same mistake.

2.6 Current State (July 2026)

82 of 160 puzzles solved. Remaining prize pool: ~900+ BTC.

Solved puzzles: #1–#70 (all), plus every 5th key up to #130:

  • #75, #80, #85, #90, #95, #100, #105, #110, #115, #120, #125, #130

The next targets:

  • Puzzle #71 (71-bit, brute-force only) — the easiest remaining unsolved puzzle. ~3.55 × 10²¹ keys in range. No public key exposed, so brute-force only. On an RTX 4090 (~1.5 GKeys/s), this would take ~25,000+ years alone, but distributed GPU pools are actively working.
  • Puzzle #135 (135-bit, public key exposed) — solvable with Kangaroo. Expected ~2⁶⁷.⁵ jumps. Collision Protocol pool targets this specifically.

PART III: THE FUNDING CHAIN TRACE

3.1 The Origin Transaction

The puzzle's main funding transaction:

TXID: 08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15
Date: 2015-01-15
Block: 339085

This transaction created 256 outputs. But tracing the inputs to this transaction reveals the funding source — and potentially the creator's wallet.

3.2 Tracing the Funders

The funding chain traces back to several key addresses that funded the puzzle creator:

Funder #1 — P2PK Output (Uncompressed Public Key)

Public key (uncompressed, 65 bytes):
04 7a0e5ead1210acebb8bcc1243cdc4d0d8bd3080116a1785af87dc064050f6aeb
   960d49694b1230854a84f9a8d51756aa3d53346717081d5ec6d59326b9eecb77

X-coordinate: 0x7a0e5ead1210acebb8bcc1243cdc4d0d8bd3080116a1785af87dc064050f6aeb
Y-coordinate: 0x960d49694b1230854a84f9a8d51756aa3d53346717081d5ec6d59326b9eecb77

This is a P2PK (Pay-to-Public-Key) output — the public key is directly visible on-chain. This means this funder's address has never had the public key hidden; it's been exposed since 2015.

The fact that this funder uses an uncompressed public key (prefix 0x04) and a P2PK script (not P2PKH) tells us:

  1. This was likely a very early Bitcoin user (P2PK was common in 2009-2010)
  2. They predate compressed keys becoming standard
  3. This could be an OG miner or early adopter

Funder #2 — Compressed P2PKH

Public key (compressed, 33 bytes):
02 c584e2cb49a5aabd9ceb1e5128cecd0a7ca96628e76b1491950f021a4852d8ec

X-coordinate: 0xc584e2cb49a5aabd9ceb1e5128cecd0a7ca96628e76b1491950f021a4852d8ec
Y-parity: even (prefix 0x02 → y is even)

This address funded ~872 BTC to the puzzle. Using a compressed public key, this funder is more modern but still significant.

The 872 BTC Funder

One address in the funding chain moved ~872 BTC in a single transaction to the puzzle — this is the largest single funder and likely the puzzle creator themselves, consolidating a large holding.

3.3 What the Funding Chain Tells Us

The funding chain is critical for the BIP32 recovery hypothesis:

  1. If the puzzle keys are BIP32 non-hardened children derived from a master key
  2. And the funding chain reveals the parent public key (or a related key)
  3. Then any solved child private key can be used to recover the master private key
  4. From the master private key, ALL 160 child keys can be derived

This is the holy grail of puzzle research.

PART IV: BIP32 — HIERARCHICAL DETERMINISTIC WALLETS

4.1 BIP32 Overview

BIP32 (proposed by Pieter Wuille in 2012) defines how to derive a tree of keypairs from a single seed. The critical feature is the distinction between:

  • Hardened derivation (i ≥ 2³¹): uses the private key in the HMAC; child public keys cannot be derived from parent public key alone
  • Non-hardened derivation (i < 2³¹): uses the public key in the HMAC; anyone with the parent public key (xpub) can derive all child public keys

4.2 Non-Hardened Derivation Math

This is the math that makes the BIP32 attack possible:

Private parent → Private child (non-hardened):

I = HMAC-SHA512(c_par, ser_P(point(k_par)) || ser_32(i))
Split I into I_L (32 bytes) and I_R (32 bytes)
k_i = (I_L + k_par) mod n
c_i = I_R

Public parent → Public child (non-hardened):

I = HMAC-SHA512(c_par, ser_P(K_par) || ser_32(i))
Split I into I_L and I_R
K_i = point(I_L) + K_par
c_i = I_R

The Critical Relationship:

k_i = I_L + k_par  (mod n)
K_i = I_L × G + K_par

Therefore:

k_par = k_i − I_L  (mod n)   ← Recover parent private key from child private key!

This is the BIP32 non-hardened derivation reversal attack:

  1. Given: child private key k_i + parent public key K_par + chain code c_par + index i
  2. Compute I = HMAC-SHA512(c_par, ser_P(K_par) || ser_32(i))
  3. Compute I_L from first 32 bytes of I
  4. Compute k_par = (k_i − I_L) mod n

Once k_par (the master private key) is recovered, derive ALL children:

For any j: k_j = (I_L_j + k_par) mod n

4.3 The Puzzle Creator's Statement

"It is just consecutive keys from a deterministic wallet (masked with leading 000...0001 to set difficulty)."

This directly supports the BIP32 hypothesis. "Consecutive keys from a deterministic wallet" strongly suggests BIP32 non-hardened derivation with consecutive indices.

4.4 Unknown: The Chain Code

The chain code is the missing puzzle piece. Without it, we cannot compute I_L and therefore cannot reverse the derivation.

Possible chain code candidates:

  1. All zeros (simplistic, unlikely for any real wallet)
  2. SHA-256 of some constant (e.g., puzzle-related strings, the TXID)
  3. Something derived from the funding public keys (e.g., SHA-256 of the public key)
  4. Embedded in the funding transaction (e.g., in an OP_RETURN output)
  5. The BIP32 seed itself — if we could guess the seed phrase, we could regenerate everything
  6. A deterministic function of the address/index — some non-standard scheme unique to the puzzle creator

4.5 Derivation Path Mystery

Even with the right chain code, we need to know:

  • The derivation path (e.g., m/44'/0'/0'/0/i vs m/0/i vs something custom)
  • Whether derivation indices match puzzle numbers exactly
  • Whether there's an offset or non-standard mapping

The existing scripts (bip32_recover.py and verify_bip32.py) test multiple chain code candidates and index offsets, but haven't found a match yet. This suggests either:

  1. The chain code is non-trivial and not in the candidate set
  2. The keys are NOT from a BIP32 wallet (contradicting the creator's statement)
  3. There's a different HD wallet standard being used (BIP44, BIP49, BIP84, etc.)
  4. The masking process modified the keys in a way that breaks the BIP32 relationship

PART V: ATTACK VECTORS & ALGORITHMS

5.1 Brute-Force Search (BitCrack)

Applicable to: Puzzles #71–#160 (except every 5th key with exposed public keys)

Input: Bitcoin address (hash of public key)
Output: Private key such that hash of pubkey matches target

Complexity: O(2^N) where N is the puzzle number

Performance:

  • RTX 4090: ~1.5-2.0 GKeys/s on VanitySearch/BitCrack
  • Tesla A100: ~3-4 GKeys/s
  • RTX 3090: ~1.0-1.2 GKeys/s
  • RTX 2080 Ti: ~0.6 GKeys/s
  • CPU (i7-7700K, 8 threads): ~22 MKeys/s

Time estimates for RTX 4090:

  • Puzzle #66 (solved): 2⁶⁵ keys → ~3.5 years (single GPU)
  • Puzzle #71 (next brute-force target): 2⁷⁰ keys → ~25,000+ years (single GPU)
  • Puzzle #80: 2⁷⁹ keys → impossibly large

Optimization: Distributed computing pools can bring these times down linearly with GPU count. A pool of 10,000 RTX 4090s could theoretically do #71 in ~2.5 years.

Limitations: After ~75-bit, brute-force becomes computationally infeasible for any reasonable attacker. This is the puzzle's core demonstration — the exponential barrier of key space search.

5.2 Pollard's Kangaroo Algorithm

Applicable to: Every 5th puzzle (#65, #70, #75, ..., #160) whose public keys were leaked in the 2019 transactions. Plus any puzzle whose public key has been revealed via spending.

Input: Public key (EC point) + known range [a, b]
Output: Private key

Complexity: O(√N) = O(2^(N/2)) expected time

How it works (the kangaroo analogy):

The algorithm uses two types of "kangaroos":

  1. Tame kangaroo: Starts at a known point (e.g., b×G) and hops forward using a deterministic jump function. These jumps form a "trap" that is set for the wild kangaroo.

  2. Wild kangaroo: Starts at the target public key Q and hops forward using the same jump function. The wild kangaroo is effectively searching for the private key.

Both kangaroos use a distinguished point technique: they store only points whose x-coordinate has a certain number of trailing zeros (e.g., the last 24 bits are zero). This is a time-memory tradeoff.

When the wild kangaroo lands on a point the tame kangaroo already visited → collision! The collision reveals the distance between the two starting points, which directly gives the private key.

Expected jumps: ~2√(b-a) = ~2^(N/2+1) jumps

Performance (RTX 4090, RCKangaroo with K=1.15 symmetry):

  • ~8 GKeyOps/s (group operations per second)
  • ~3.5× speedup from symmetry optimization (K=1.15, meaning the jump table is tuned for the specific range)

Expected time for Kangaroo vs Brute-Force:
| Puzzle | Range | Brute-Force (RTX 4090) | Kangaroo (RTX 4090) |
|--------|-----------|------------------------|---------------------|
| #70 | 2⁶⁹ | ~12,500 years | seconds |
| #80 | 2⁷⁹ | impossible | ~hours to days |
| #100 | 2⁹⁹ | impossible | ~years |
| #130 | 2¹²⁹ | impossible | ~centuries |
| #135 | 2¹³⁴ | impossible | ~millennia |

Current state: Kangaroo is the tool of choice for exposed-public-key puzzles up to ~130-bit. Beyond that, even Kangaroo's O(√N) becomes prohibitive.

5.3 Baby-Step Giant-Step (BSGS)

Also applicable to: Exposed public keys

Concept: A deterministic time-memory tradeoff algorithm with O(√N) time and O(√N) memory.

How it works:

  1. Let m = ⌈√(b-a)⌉
  2. Baby steps: Compute j×G for j = 0, 1, ..., m−1 and store as a hash table
  3. Giant steps: Compute Q − (a+km)×G for k = 0, 1, ..., m−1 and check each against the baby step table
  4. A collision gives: Q = (a + km + j) × G, so private key = a + km + j

Tradeoff: BSGS requires O(√N) memory (~16-32 GB for a 70-bit puzzle). Kangaroo requires negligible memory. For puzzle ranges >80-bit, memory becomes a significant bottleneck for BSGS.

5.4 BIP32 Non-Hardened Derivation Reversal (THE HOLY GRAIL)

This is the most promising avenue for solving ALL puzzles at once.

Theory:
If the puzzle creator used a single BIP32 wallet with non-hardened derivation:

  1. Take any solved child private key (e.g., puzzle #66 key: 0x2832ed74f2b5e35ee)
  2. Identify the correct chain code (unknown — the key missing piece)
  3. Find the correct parent public key (from the funding chain trace)
  4. Apply: parent_priv = child_priv − I_L mod n
  5. Derive ALL 160 child keys from the recovered master

Research vectors:

  • Chain code determination: Brute-force chain code candidates if the search space is small enough (e.g., if the chain code is derived from a short seed or known constant)
  • Multiple child key cross-validation: With 82 solved keys, any candidate chain code can be verified instantly — recover parent from key N, derive key M, check if it matches
  • Funding chain analysis: The funding public keys may re-encode information needed to reconstruct the chain code
  • TXID permutations: The creator may have used the transaction hash or some derivative as the chain code

If proven successful: ALL remaining puzzles (#71–#160) would be immediately solvable from the master private key, bypassing both brute-force and Kangaroo entirely.

Key challenge: The creator specifically said keys were "masked with leading zeros to set difficulty" — this masking may break the mathematical relationship between BIP32 derivation steps. If the masking is simply truncation (e.g., taking only the lower N bits of the key), the BIP32 relationship is preserved for the lower bits but the full master key cannot be reconstructed without knowing the upper bits.

5.5 Lattice Attacks (Nonce Analysis)

Applicable to: Transactions where the signer reused or biased the ECDSA nonce k

Not directly applicable to puzzle keys (which have never signed anything). However, if the puzzle creator also signed transactions from a wallet related to the funding chain, and if their nonce generation had biases, lattice attacks could recover keys from those signatures.

This is a secondary research avenue — not primary for the puzzle itself, but potentially useful for tracing the creator's identity.

5.6 Side-Channel Analysis

Applicable if you have the hardware that generated the keys. Since the puzzle keys were generated in 2015 and we don't have access to the creator's machine, this is theoretical.

PART VI: SOLVED KEYS — FULL ANALYSIS

6.1 All Known Solved Private Keys

#01: 0x0000000000000000000000000000000000000000000000000000000000000001
#02: 0x0000000000000000000000000000000000000000000000000000000000000003
#03: 0x0000000000000000000000000000000000000000000000000000000000000007
#04: 0x0000000000000000000000000000000000000000000000000000000000000008
#05: 0x0000000000000000000000000000000000000000000000000000000000000015
#06: 0x0000000000000000000000000000000000000000000000000000000000000031
#07: 0x000000000000000000000000000000000000000000000000000000000000004C
#08: 0x00000000000000000000000000000000000000000000000000000000000000E0
#09: 0x00000000000000000000000000000000000000000000000000000000000001D3
#10: 0x0000000000000000000000000000000000000000000000000000000000000202
#11: 0x0000000000000000000000000000000000000000000000000000000000000483
#12: 0x0000000000000000000000000000000000000000000000000000000000000A7B
#13: 0x0000000000000000000000000000000000000000000000000000000000001460
#14: 0x0000000000000000000000000000000000000000000000000000000000002930
#15: 0x00000000000000000000000000000000000000000000000000000000000068F3
#16: 0x000000000000000000000000000000000000000000000000000000000000C936
#17: 0x000000000000000000000000000000000000000000000000000000000001764F
#18: 0x000000000000000000000000000000000000000000000000000000000003080D
#19: 0x000000000000000000000000000000000000000000000000000000000005749F
#20: 0x00000000000000000000000000000000000000000000000000000000000D2C55
#21: 0x00000000000000000000000000000000000000000000000000000000001BA534
#22: 0x00000000000000000000000000000000000000000000000000000000002DE40F
#23: 0x0000000000000000000000000000000000000000000000000000000000556E52
#24: 0x0000000000000000000000000000000000000000000000000000000000DC2A04
#25: 0x0000000000000000000000000000000000000000000000000000000001FA5EE5
#26: 0x000000000000000000000000000000000000000000000000000000000340326E
#27: 0x0000000000000000000000000000000000000000000000000000000006AC3875
#28: 0x000000000000000000000000000000000000000000000000000000000D916CE8
#29: 0x0000000000000000000000000000000000000000000000000000000017E2551E
#30: 0x000000000000000000000000000000000000000000000000000000003D94CD64
#31: 0x000000000000000000000000000000000000000000000000000000007D4FE747
#32: 0x00000000000000000000000000000000000000000000000000000000B862A62E
#33: 0x00000000000000000000000000000000000000000000000000000001A96CA8D8
#34: 0x000000000000000000000000000000000000000000000000000000034A65911D
#35: 0x00000000000000000000000000000000000000000000000000000004AED21170
#36: 0x00000000000000000000000000000000000000000000000000000009DE820A7C
#37: 0x0000000000000000000000000000000000000000000000000000001757756A93
#38: 0x00000000000000000000000000000000000000000000000000000022382FACD0
#39: 0x0000000000000000000000000000000000000000000000000000004B5F8303E9
#40: 0x000000000000000000000000000000000000000000000000000000E9AE4933D6
#41: 0x00000000000000000000000000000000000000000000000000000153869ACC5B
#42: 0x000000000000000000000000000000000000000000000000000002A221C58D8F
#43: 0x000000000000000000000000000000000000000000000000000006BD3B27C591
#44: 0x00000000000000000000000000000000000000000000000000000E02B35A358F
#45: 0x0000000000000000000000000000000000000000000000000000122FCA143C05
#46: 0x00000000000000000000000000000000000000000000000000002EC18388D544
#47: 0x00000000000000000000000000000000000000000000000000006CD610B53CBA
#48: 0x0000000000000000000000000000000000000000000000000000ADE6D7CE3B9B
#49: 0x000000000000000000000000000000000000000000000000000174176B015F4D
#50: 0x00000000000000000000000000000000000000000000000000022BD43C2E9354
#51: 0x00000000000000000000000000000000000000000000000000075070A1A009D4
#52: 0x000000000000000000000000000000000000000000000000000EFAE164CB9E3C
#53: 0x00000000000000000000000000000000000000000000000000180788E47E326C
#54: 0x00000000000000000000000000000000000000000000000000236FB6D5AD1F43
#55: 0x000000000000000000000000000000000000000000000000006ABE1F9B67E114
#56: 0x000000000000000000000000000000000000000000000000009D18B63AC4FFDF
#57: 0x00000000000000000000000000000000000000000000000001EB25C90795D61C
#58: 0x00000000000000000000000000000000000000000000000002C675B852189A21
#59: 0x00000000000000000000000000000000000000000000000007496CBB87CAB44F
#60: 0x0000000000000000000000000000000000000000000000000FC07A1825367BBE
#61: 0x00000000000000000000000000000000000000000000000013C96A3742F64906
#62: 0x000000000000000000000000000000000000000000000000363D541EB611ABEE
#63: 0x0000000000000000000000000000000000000000000000007CCE5EFDACCF6808
#64: 0x000000000000000000000000000000000000000000000000F7051F27B09112D4
#65: 0x000000000000000000000000000000000000000000000001A838B13505B26867
#66: 0x000000000000000000000000000000000000000000000002832ED74F2B5E35EE
#67: 0x00000000000000000000000000000000000000000000000730FC235C1942C1AE
#68: 0x00000000000000000000000000000000000000000000000BEBB3940CD0FC1491
#69: 0x0000000000000000000000000000000000000000000000101D83275FB2BC7E0C
#70: 0x0000000000000000000000000000000000000000000000349B84B6431A6C4EF1
#75: 0x000000000000000000000000000000000000000000004C5CE114686A1336E07
#80: 0x00000000000000000000000000000000000000000000EA1A5C66DCC11B5AD180
#85: 0x000000000000000000000000000000000000000000011720C4F018D51B8CEBBA8
#90: 0x00000000000000000000000000000000000000000002CE00BB2136A445C71E85BF
#95: 0x0000000000000000000000000000000000000000000527A792B183C7F64A0E8B1F4
#100: 0x00000000000000000000000000000000000000000AF55FC59C335C8EC67ED24826
#105: 0x00000000000000000000000000000000000000016F14FC2054CD87EE6396B33DF3
#110: 0x0000000000000000000000000000000000000035C0D7234DF7DEB0F20CF7062444
#115: 0x0000000000000000000000000000000000000060F4D11574F5DEEE49961D9609AC6
#120: 0x0000000000000000000000000000000000000B10F22572C497A836EA187F2E1FC23
#125: 0x0000000000000000000000000000000000001C533B6BB7F0804E09960225E44877AC
#130: 0x0000000000000000000000000000000000033E7665705359F04F28B88CF897C603C9

6.2 Key Pattern Analysis

Leading Zeros

Every key has leading zeros padding it to 256 bits (32 bytes). The actual key value occupies a limited number of bits:

#66:  0x...2832ED74F2B5E35EE   (66 bits effective, 190 bits leading zeros)
#70:  0x...349B84B6431A6C4EF1   (70 bits effective, 186 bits leading zeros)
#130: 0x...33E7665705359F04F28B88CF897C603C9  (130 bits effective, 126 bits leading zeros)

This matches the creator's statement: keys are "masked with leading 000...0001 to set difficulty."

Key Distribution

  • Early keys (#1–#20) were solved almost immediately (2015)
  • Keys up to #50 were found within weeks
  • #51–#64 were solved gradually over years
  • #65 onwards were solved using increasingly powerful hardware
  • #70 was the last sequential solve (brute-force, Kangaroo-assisted since public key was leaked)
  • #75, #80, etc. were solved via Kangaroo (public key exposed)

Statistical Distribution

The keys appear to be pseudo-random within their ranges:

  • No obvious arithmetic sequences
  • No repeated patterns across different bit-lengths
  • Consistent with random number generation or BIP32 derivation

6.3 What the Solved Keys Tell Us About BIP32

If these keys are BIP32 children:

  • Indices appear to match puzzle numbers (or a simple offset)
  • All are non-hardened (hardened keys wouldn't be verifiable with just the public key)
  • The derivation path is unknown but likely straightforward

The lack of cross-key mathematical correlation (testing recover_parent from #66, derive #67, no match found with common chain code candidates) suggests:

  1. Chain code is not a simple constant
  2. Or derivation path is non-standard
  3. Or the keys are NOT BIP32 children (contradicting the creator's statement)

The creator could have used any deterministic scheme — what they called a "deterministic wallet" might not be BIP32 specifically but their own custom scheme.

PART VII: TOOLS & SOFTWARE

7.1 Brute-Force Tools

BitCrack

  • Author: brichard19
  • GitHub: https://github.com/brichard19/BitCrack
  • Type: GPU brute-force (CUDA/OpenCL)
  • Best for: Puzzles without exposed public keys
  • Key speed: ~1.5 GKeys/s on RTX 4090
  • Features: Range scanning, compressed/uncompressed, multiple GPU support

VanitySearch (+ BitCrack mode)

  • Author: JeanLucPons
  • Type: GPU, CUDA
  • Best for: Vanity address generation AND puzzle brute-force (with BitCrack mode)
  • Note: zielar (the Bitcointalk OP) compiled custom versions for every NVIDIA architecture (SM_35 through SM_86)

7.2 ECDLP Solvers (Kangaroo)

Kangaroo (JeanLucPons)

  • GitHub: https://github.com/JeanLucPons/Kangaroo
  • Type: GPU Pollard's Kangaroo for ECDLP
  • Best for: Puzzles with exposed public keys
  • Performance: ~500 MKeyOps/s on RTX 4090 (base)
  • Features: Distinguished points, parallel kangaroos, save/restore

RCKangaroo (RetiredCoder)

  • GitHub: https://github.com/RetiredC/RCKangaroo
  • Type: GPU, optimized Kangaroo with symmetry (K=1.15)
  • Best for: ~8 GKeyOps/s on RTX 4090 — current state of the art
  • Used to solve: Puzzles #125 and #130

Keyhunt (AlbertoBSD)

Keyhunt-CUDA (WanderingPhilosopher)

7.3 Research & Analysis

BIP32 Hypothesis Tools (local)

bip32_recover.py   — Recover master private key from child + parent public key
verify_bip32.py    — Cross-verify solved keys against BIP32 derivation

These test multiple chain code candidates and index offsets. Neither has confirmed the BIP32 hypothesis yet.

7.4 Pool-Based Solvers

Collision Protocol

TTD Sales (Puzzle Pool)

  • Website: https://ttdsales.com/67bit/
  • Type: Pool-based brute-force
  • Previously targeted: Puzzle #67
  • Integration: Works with VanitySearch + custom client

PART VIII: SECURITY IMPLICATIONS

8.1 What the Puzzle Teaches About Bitcoin Security

The Exponential Advantage

The puzzle is a live demonstration that:

  • Brute-forcing a 256-bit key is impossible (2²⁵⁶ combinations)
  • Even 128-bit is astronomically out of reach
  • But a 66-bit key was solved by a motivated individual with good hardware
  • The gap between "easily solvable" and "impossible" is roughly 70-80 bits with current technology

Public Key Exposure Risk

Every time you spend Bitcoin, your public key is revealed. After that:

  • Anyone can run ECDLP algorithms against your key
  • Currently this is computationally infeasible for 256-bit keys
  • But quantum computing changes this dramatically

The Mempool Poisoning Problem

Puzzles #66 and #69 demonstrated a new attack class:

  1. Solver broadcasts spending transaction
  2. Bots see the transaction in the mempool
  3. Bots extract the public key and signature
  4. Bots run Kangaroo to find the private key (for puzzles with known ranges)
  5. Bots broadcast a competing transaction with higher fees
  6. Original solver loses the prize

Mitigation: Use of private mining services (MARA Slipstream, Antpool private mining) that bypass the public mempool and submit directly to the block template.

8.2 Quantum Computing Threat

The Canary in the Coal Mine

The puzzle is often described as a "quantum canary" — when higher puzzles start falling faster than expected, it signals quantum progress.

Shor's Algorithm

A sufficiently large quantum computer running Shor's algorithm would:

  • Completely break ECDSA — find the private key from the public key in polynomial time
  • Not break SHA-256 or RIPEMD-160 — hashing is resistant to quantum attacks
  • Affect all addresses with exposed public keys (P2PK outputs, spent P2PKH outputs)

Current Timeline

  • Google's Willow chip (2024): 105 qubits, error correction milestone
  • Google Quantum AI paper (March 2026): claims 1M+ physical qubits roadmap
  • Breaking secp256k1: estimated ~2,500 logical qubits (millions of physical qubits with error correction)
  • Consensus estimate: 10-20 years before quantum computers threaten Bitcoin

Why the Puzzle is a Canary

  • If puzzle #135 suddenly falls (expected: 2⁶⁷ Kangaroo jumps, ~millennia on current hardware), it likely means someone has quantum hardware or a breakthrough algorithm
  • If puzzle #160 falls (Kangaroo expected: 2⁸⁰ jumps, physically impossible today), Bitcoin's ECDSA security is officially broken

8.3 The BIP32 Vulnerability

If the puzzle keys are indeed BIP32 non-hardened, it demonstrates a key security lesson:

  • Non-hardened derivation leaks the entire wallet if any child private key is exposed AND the parent public key is known
  • This is why BIP32 recommends using hardened derivation for the account level (m/44'/0'/0')
  • Bitcoin wallet best practice: use non-hardened only for receiving addresses below a hardened account level

The puzzle creator may have intentionally hardened the upper levels to prevent exactly this attack, or used a non-standard derivation scheme.

PART IX: OPEN RESEARCH QUESTIONS

9.1 BIP32 Hypothesis

Status: UNCONFIRMED
Question: Are the puzzle keys derived from a single BIP32 seed?
Evidence for: Creator's statement, consecutive nature
Evidence against: No cross-key relationship found with common chain codes
Next step: Systematic search of chain code space if bounded; if unbounded, this route is dead

9.2 Chain Code Identification

Status: UNKNOWN
Question: What is the chain code (or equivalent) for the BIP32 derivation?
Candidates to test:

  • SHA256 of the funding TXID
  • SHA256 of specific puzzle-related strings
  • The funding public key itself (or its hash)
  • A 32-byte string embedded in the funding transaction
  • The BIP32 seed derived from a known passphrase

9.3 Creator Identity

Status: ANONYMOUS
Question: Who created the puzzle and why?
Clues:

  • Registered on BitcoinTalk as "zielar" (the OP of the current thread)
  • Originally posted on BitcoinTalk as a different user
  • Has held ~1000 BTC since at least 2015
  • Funded from P2PK outputs suggesting early adopter status
  • Speaks English but may not be native (some phrases in the original thread suggest European origin)
  • Motivated by genuine interest in benchmarking crypto security

9.4 Timing of Remaining Solves

Predicted order:

  1. Puzzle #71 — brute-force, but easiest remaining non-Kangaroo target. Distributed pools are likely already scanning it.
  2. Puzzle #135 — Kangaroo with public key exposed. Pool-based attackers actively targeting.
  3. Puzzle #131–#134, #136–#140 — Kangaroo targets once #135 is solved and tools/pools shift focus.
  4. Non-exposed keys (#71, #72, #73, #74, #76, etc.) — brute-force only, requiring exponentially more resources.

9.5 The "Masking" Problem

The creator said keys are "masked with leading 000...0001 to set difficulty." This means:

  • The full key is longer (all 256 bits from BIP32)
  • Then it's masked (truncated/bitwise-ANDed) to only expose the lower N bits
  • This preserves the range property: key is now in [2^(N-1), 2^N-1]

Critical implication for BIP32 reversal: If masking is simply k_masked = k_full & (2^N - 1), then:

  • The lower N bits match the BIP32 derivation
  • The upper bits are unknown
  • We cannot reconstruct k_full from k_masked alone
  • But: The parent private key k_par only needs child privates in mod n, and the mod n addition is linear. If k_masked differs from k_full by an unknown multiple of 2^N, then:
    • k_par = k_masked + (unknown * 2^N) - I_L mod n
    • We'd need to brute-force the unknown upper bits

This may be why the BIP32 cross-validation didn't work — the masked key is not the full BIP32 key.

PART X: COMPLETE REFERENCE

10.1 Transaction IDs

Event TXID Block Date
Original funding 08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15 339085 2015-01-15
First refill 5d45587cfd1d5b0fb826805541da7d94c61fe432259e68ee26f4a04544384164 475240 2017-07-11
Second refill (April 2023) Multiple transactions N/A 2023-04-16
Public key leak (1000 sat) 20 transactions N/A 2019-05-31

10.2 Key Addresses

Puzzle # Address Status Reward
#66 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so SOLVED 6.6 BTC
#67 1BY8GQbnueYofwSuFAT3USAhGjPrkxDdpt SOLVED 6.7 BTC
#68 1MVDYgVaSN6iKKEsbzRUAYFrYJadLYZvvZ SOLVED 6.8 BTC
#69 19vkiEajfhuZ8bs8J2bU8m7G6gKjX2Tj2H SOLVED 6.9 BTC
#70 1DJh2eHFY3CE3dKAgvBe5AG3W1QqW5WjqN SOLVED 7.0 BTC
#71 1PWoJEgSRhX4bN92JZqNRHPzTDcAdLcCQ8 UNSOLVED 7.1 BTC
#72 1JHjT1kLsQxM6UcE2PpTYBC7bCWBVNyMN8 UNSOLVED 7.2 BTC
#73 1C23nrk5kJCGuEMfKcBU34mW8rwNqGaq4K UNSOLVED 7.3 BTC
#74 1CY6kZ3HnijcDGMqfBq3J8kGjGHiMYJkAi UNSOLVED 7.4 BTC
#75 1Mc7H69Kd4ss6nYKfNSubkcVbViGLGtAyz SOLVED 7.5 BTC
... ... ... ...
#100 (various) SOLVED 10.0 BTC
... ... ... ...
#135 16RGFo6hjq9ym6Pj7N5H7L1NR1rVPJyw2v UNSOLVED (key exposed) 13.5 BTC
... ... ... ...
#160 1NBC8uXJy1GiJ6drkiZa1WuKn51ps7EPTv UNSOLVED (key exposed) 16.0 BTC

10.3 Key Contact Points for Puzzle Numbers

Puzzle # Range Lower (2^(N-1)) Range Upper (2^N - 1) Bits
71 2361183241434822606848 4722366482869645213695 71
72 4722366482869645213696 9444732965739290427391 72
73 9444732965739290427392 18889465931478580854783 73
74 18889465931478580854784 37778931862957161709567 74
75 37778931862957161709568 75557863725914323419135 75 (SOLVED)
80 (2^79) (2^80-1) 80 (SOLVED)
85 (2^84) (2^85-1) 85 (SOLVED)
90 (2^89) (2^90-1) 90 (SOLVED)
100 (2^99) (2^100-1) 100 (SOLVED)
105 (2^104) (2^105-1) 105 (SOLVED)
110 (2^109) (2^110-1) 110 (SOLVED)
115 (2^114) (2^115-1) 115 (SOLVED)
120 (2^119) (2^120-1) 120 (SOLVED)
125 (2^124) (2^125-1) 125 (SOLVED)
130 (2^129) (2^130-1) 130 (SOLVED)
135 (2^134) (2^135-1) 135 (key exposed)
140 (2^139) (2^140-1) 140 (key exposed)
145 (2^144) (2^145-1) 145 (key exposed)
150 (2^149) (2^150-1) 150 (key exposed)
155 (2^154) (2^155-1) 155 (key exposed)
160 (2^159) (2^160-1) 160 (key exposed)

10.4 Reference URLs


Post a Comment

0 Comments