Browser-only slot machine that derives real secp256k1 keypairs and checks them against 21,954 Patoshi-pattern addresses; odds are ~1 in 5.27×10⁷².
Key Takeaways
Full Bitcoin address derivation runs client-side: random 256-bit int → secp256k1 point → RIPEMD160(SHA256) → P2PKH, using Paul Miller’s audited @noble/secp256k1 and @noble/hashes.
Address set ships as a 135 KB Bloom filter (m=1,078,320 bits, k=30, p≈10⁻⁹) plus a 615 KB sorted (hash160, balance_sats) binary table; no API, no node connection.
Benchmark: ~2,490 spins/sec; 99% of cost is elliptic-curve point multiplication, not the Bloom check. Dataset could grow 100× with no runtime impact.
Dataset sourced from bensig/patoshi-addresses (Sergio Demian Lerner / Jameson Lopp): 21,954 addresses totalling 1,097,702.49 BTC including the genesis block.
Win UX includes WIF private key display, clipboard copy, confetti, and a ?devwin=1 flag for UI testing without a real hit.
Hacker News Comment Review
Commenters questioned whether a real win is actionable: the win modal shows the WIF key, but one user couldn’t locate the guessed key on the live site, raising a practical claim-ability concern.
The sharper technical suggestion was to narrow the search space by reverse-engineering Satoshi’s PRNG parameters from early block timestamps rather than brute-forcing the full 2²⁵⁶ keyspace.
Gallows-humor consensus: if a win ever occurs and coins move, Bitcoin’s market value likely collapses before the winner cashes out.
Notable Comments
@int32_64: Argues a targeted attack on Satoshi’s original PRNG parameters would be far more tractable than uniform keyspace search.
@ex-aws-dude: Raises the question of whether the app silently phones home on a Bloom hit, given the financial stakes.
