The results are given below:
🔐 Recovering an Old Electrum V1 Wallet (2011) — A Complete Technical Journey + Open-Source Code
📌 IntroductionYears ago, I created a Bitcoin wallet using
Electrum V1 (the old 2011–2014 client). Today, I only remember
11 out of 12 words, and I need either to recover the missing word or exploit the weak entropy generation of that era.
This thread documents my full journey: from ready-made tools that failed, to building custom Python solutions that run on
Android (Termux) without relying on heavy dependencies. I'm sharing the code and results in hope it helps others in a similar situation.
🎯 ObjectiveRecover an Electrum V1 wallet using one of two methods:
- Method 1: Recover the missing 12th word from 1,626 possibilities (Electrum V1 wordlist).
- Method 2: Exploit Weak Entropy — In 2011–2014, Electrum V1 generated seeds from random.seed(timestamp), making them brute-forceable.
🧰 First Attempts (Failed)1. btcrecover / seedrecover.pyThe most popular Bitcoin wallet recovery tool. Unfortunately:
- Wallet type blockchainpasswordv3 does not support BIP39 or Electrum V1 mnemonics.
- The correct flag --wallet-type bip39 does not support Electrum V1 (different algorithm).
- Depends on bip_utils, which fails on Termux because coincurve requires libsecp256k1 and Rust.
2. Termux (Android) Environment Issueserror: metadata-generation-failed
× Encountered error while generating package metadata.
╰─> coincurve
We abandoned
bip_utils and
coincurve entirely, and built everything manually using:
- ecdsa (lightweight, works on Termux)
- base58
- requests
🏗️ What We Built From Scratch1. Manual BIP44/49/84 Address Generation- Pure-Python BIP32 implementation (HMAC-SHA512 + secp256k1).
- Bech32 implemented from scratch for bc1 addresses.
- hash160, P2PKH / P2SH-P2WPKH / P2WPKH encoding.
2. Full Electrum V1 Implementation- Loads the 1,626-word list from GitHub.
- stretch_key: 100,000 SHA256 iterations (V1's weak key stretching).
- Master private key derivation and Master Public Key (MPK).
- Child key derivation: seq = Hash(mpk + ":" + for_change + ":" + n).
- Uncompressed P2PKH addresses (as in original V1).
3. Balance Checking- Started with HTTP APIs: mempool.space, blockstream.info, mempool.emzy.de.
- Hit error 429: "Request rate exceeds the current limit for unauthenticated users".
- Switched to Electrum TCP/SSL (ports 50001/50002) with:
- 13 fallback servers (TCP + SSL).
- Automatic reconnection on network loss.
- Transaction count (tx count) fetched alongside balance.
[/list]
4. Weak Entropy Generation (Final Approach)def weak_entropy(ts):
random.seed(ts)
return random.getrandbits(128).to_bytes(16, "big")
Starting from
2011-11-06, we test second by second. Each second generates 12 words, derives 10 addresses (5 receiving + 5 change), and checks balances.
Speed on a mid-range Android phone: ~
8–20 Unix-seconds per second.
📊 Challenges & Solutions| Challenge | Solution |
| coincurve won't build | Dropped bip_utils, built everything manually |
| blockstream.info rate-limits (429) | Moved to Electrum TCP with 13 servers |
| Network drops mid-scan | Auto-reconnect + resend failed batch |
| Termux blocks non-443 ports | SSL support (port 50002) |
| No tx count available | Added blockchain.scripthash.get_history |
| Slow output | Batches of 10 mnemonics + per-address logging |
🎨 Sample Output🔌 Opening Electrum connection...
⚠️ [E1] electrum.emzy.de:50001 (TCP) → timed out
✅ [E1] electrum.bitaroo.net:50001 (TCP) connected
[Batch 1/46800000] 2011-11-06 00:00:00 → 2011-11-06 00:00:09
📡 Checking 100 addresses...
---
1KfZGvwZxsvSmemoCmEV75uqcNzYBHjkHZ balance=0
1Nh7uHdvY6fNwtULToI7k1vTM8Nw5u67B9 balance=0
1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa balance=150000 tx=5 💰 [1262304005] m/0/3
---
⚡ 8.5 sec/sec | remaining 468,000,000 | ETA ~15294 hours
⚠️ Important Warnings- Full random search is practically impossible. Probability: 1 in 2^128 per seed.
- But weak entropy (2011–2014) is realistic. If your wallet is from that era, there's a genuine chance.
- Speed on mobile is limited. 468 million seconds → months of runtime. Narrow the range with an approximate creation date.
- Never share your mnemonic, not even on forums. The code runs locally only.
- For real funds: Use an air-gapped machine when recovering the seed.
📁 Attached Files- po4.py — Main script (generation + checking + saving).
- electrum_words.txt — 1,626-word list (auto-downloaded).
- found.txt — Results (created when a balance is found).
🛠️ Quick Start
1. Install dependencies (Termux / Linux / macOS / Windows)
pip install ecdsa base58 requests
2. Edit the search range in po4.py
START_DATETIME = datetime(2011, 11, 6, 0, 0, 0)
END_DATETIME = datetime(2011, 12, 31) # Narrow for testing
3. Run
python po4.py
🙏 Credits- spesmilo/electrum — for the original wordlist.
- btcrecover — inspired the idea, even though it didn't fit my case.
- ecdsa & base58 maintainers — for lightweight libraries that work on Termux.
❓ FAQQ: Why start at 2011-11-06?A: That's the earliest Electrum V1 seed generation date worth exploring. Before that, Bitcoin itself was barely used. You can adjust
START_DATETIME to any date.
Q: How do I narrow the search range?A: If you remember roughly when you created the wallet (month/year), set
START_DATETIME and
END_DATETIME accordingly. This reduces runtime from years to days.
Q: What's the difference between Electrum V1 and BIP39?A: BIP39 uses PBKDF2 with 2,048 iterations and a 2,048-word list. Electrum V1 uses a weak 100,000× SHA256 stretching with a 1,626-word list and a different derivation path (
mpk:for_change:n). They are
not compatible.
Q: Can this break someone else's wallet?A: No. Only wallets created with
weak entropy (predictable timestamp seeds) from 2011–2014 are vulnerable. Modern wallets use secure RNG and are immune.
Q: Is 100,000 SHA256 iterations slow?A: Yes, on mobile it takes ~50–100 ms per mnemonic. That's the main bottleneck. Reducing
ADDR_LIMIT and using batch processing helps.
📝 Final NoteThis thread is strictly educational. If you're trying to recover
your own wallet, that's your right. If you're trying to break
someone else's, you're a criminal with no excuse.
For any technical questions, reply below.
Bitcoin is freedom. Recovery is a right.
quillbot : 39% of text is likely AI
copyleaks : 100% AI
originality : Likely AI - 98% Confidence
stealthwriter : 93% AI
zerogpt : 19.6% AI GPT
gptzero : 100% AI
Research Log: 21 Experiments on Electrum Seed Generation
Statistical Behavior and Lessons Learned
A comprehensive record of every hypothesis tested — all negative results included
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
IntroductionThis post is a companion to my earlier statistical analysis of the Electrum Seed version rule. That post covered the theoretical foundation (HMAC-SHA512 PRF properties) and the practical balance-checking methods.
This post documents
every experiment I ran over the research period. Twenty-one distinct hypotheses, all tested rigorously. Every single one produced a negative result — no patterns, no anomalies, no shortcuts.
I am publishing this for two reasons:
- Honest record keeping. Most people only publish successes. The failures matter just as much.
- Time saving. Anyone considering similar work can see what has already been tried and confirmed to be a dead end.
Important context: All experiments confirm the theoretical prediction of 1/256 acceptance rate. Zero balances were found across millions of tested addresses. This is not surprising — the probability is effectively zero by design.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━Experiment List (at a glance)| # | Hypothesis | Result |
| 1 | BIP39 single-word seeds | Negative |
| 2 | BIP39 two-word seeds | Negative |
| 3 | Old Electrum wordlist (1626 words) | Negative |
| 4 | Merged wordlist (BIP39 + Old Electrum) | Negative |
| 5 | Keyboard error variants (AZERTY, QWERTZ) | Negative |
| 6 | Progressive seeds (cumulative from word 1) | Negative |
| 7 | Progressive reverse seeds (from last word) | Negative |
| 8 | Prime-indexed words | Negative |
| 9 | Prime-length seeds from prime-indexed words | Negative |
| 10 | 12-word prime-indexed seeds (500K samples) | Negative |
| 11 | 12-word seeds where all words start with same letter | Negative |
| 12 | 12-word seeds where all words have same length | Negative |
| 13 | Arabic letters (28 chars) joined with spaces | Negative |
| 14 | English letters (52 chars) joined with spaces | Negative |
| 15 | 2-character combinations (letters + digits + symbols) | Negative |
| 16 | 3-character combinations | Negative |
| 17 | Single word repeated N times (N = 1 to 50) | Negative |
| 18 | Small alphabet subset (2 words per letter) | Negative |
| 19 | Levels 4 through 12 on small subset | Negative |
| 20 | Vanity address generation | Mixed (works but slow) |
| 21 | Balance checker verification | Positive (verified correct) |
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━Detailed Experiment LogExperiment 1-2: Basic word combinationsTested all single words and two-word combinations from the BIP39 2048-word list.
1-word : 2,048 candidates → 7 accepted (rate 0.003418)
2-word : 4,194,304 candidates → 16,180 accepted (rate 0.003857)
Expected: 0.003906 (1/256)
Deviation: -1.6σ for 2-word result
Within statistical expectation.
Experiment 3-4: Old Electrum wordlist and merged listDownloaded the pre-BIP39 Electrum wordlist (1626 words, still supported by Electrum for legacy wallets). Tested it separately and merged with BIP39.
Old 1-word : 1,626 candidates → ~6 accepted
Old 2-word : 2,643,876 candidates → ~10,300 accepted
Merged 2-word: 13,155,129 candidates → 51,000+ accepted
Same 1/256 rate across all sources.
Experiment 5: Keyboard error hypothesisHypothesis: users who typed their seed on the wrong keyboard layout (French AZERTY instead of QWERTY, German QWERTZ) might have produced different addresses. If we apply the swap corrections, we might find matching addresses.
AZERTY swaps: a↔q, z↔w
QWERTZ swaps: y↔z
Result: No additional balances found. The hypothesis is valid in theory but the space of possible keyboard errors is too large to search randomly.
Experiment 6-7: Progressive seedsHypothesis: some users might create seeds by writing the wordlist in order, then truncating.
Forward : "abandon"
"abandon ability"
"abandon ability able"
... (up to 2048 words)
Reverse : "zoo"
"zoo zone"
"zoo zone zero"
... (up to 2048 words)
~14 accepted prefixes per direction. Same 1/256 rate.
Experiment 8-10: Prime numbersHypothesis: users who are mathematicians might choose words at prime indices (2, 3, 5, 7, 11, ...). Tested:
Prime-indexed words, prime-length seeds:
BIP39 : 65 candidates → 0-2 accepted (expected 0.25)
Old Electrum: 55 candidates → 0-1 accepted (expected 0.21)
12-word seeds from prime-indexed pool (500K samples each):
BIP39 : 1,972 accepted (deviation +0.43σ)
Old Electrum: 2,012 accepted (deviation +1.33σ)
Word frequency chi-square: 301.55 (df=308) — perfectly uniform
Prime numbers do not behave differently. The chi-square value is essentially equal to its degrees of freedom, which is the mathematical signature of true randomness.
Experiment 11: Same-letter wordsHypothesis: 12-word seeds where all words start with the same letter might reveal patterns.
Tested each letter A through Z, sampling 100,000 seeds per letter.
Result: Every letter showed rate approximately 1/256. No letter gave a statistical advantage.
Experiment 12: Same-length wordsSimilar hypothesis: all 12 words having the same number of characters (all 4-letter, all 5-letter, etc.).
Result: Identical behavior across all lengths.
Experiment 13-14: Single characters joined with spacesTested seeds like "a", "a b", "a b c" using Arabic letters and English letters.
Arabic (28 letters) joined with spaces:
1-char : 28 → 0 accepted
2-char : 784 → 3 accepted
3-char : 21,952 → 87 accepted
Total : 22,764 → 90 accepted (rate 0.003954)
English (52 chars a-z + A-Z) joined with spaces:
1-char : 52 → 0
2-char : 2,704 → 11
3-char : 140,608 → 543
Total : 143,364 → 554 (rate 0.003864)
Same 1/256 across all languages and character sets.
Experiment 15-16: Random 2-char and 3-char combinationsExtended the character set to include digits and symbols:
Character sets combined: 132 unique characters
(a-z, A-Z, 0-9, symbols, Arabic letters, Arabic digits)
2-char combinations: 132^2 = 17,424 → 69 accepted
3-char combinations: 132^3 = 2,299,968 → ~9,000 accepted
Consistent 1/256 rate.
Experiment 17: Repeated single wordTested phrases like "abandon", "abandon abandon", "abandon abandon abandon", ... up to 50 repetitions.
BIP39 words × 1-50 repetitions: 102,400 candidates → 401 accepted
BIP39 words × exactly 4 reps : 3,674 candidates → 14 accepted
No anomaly. Repetition does not change the distribution.
Experiment 18-19: Small alphabet subsetReduced wordlist to just 2 words per letter (52 total). This makes full enumeration feasible:
1-word : 52 candidates
2-word : 2,704 candidates
3-word : 140,608 candidates
4-word : 7,311,616 candidates → 24,204 accepted
5-word : 380,204,032 candidates → not completed
Results all matched the 1/256 prediction.
Experiment 20: Vanity addressesTried to generate Bitcoin addresses containing custom strings (like names). This is the only experiment where the method works — it's not about finding patterns, it's about brute-force search.
Difficulty scales exponentially:
3 characters: ~2 minutes
4 characters: ~1 hour
5 characters: ~4 days
6 characters: ~7 months
7+ characters: impractical
Every generated address produces its own unique xprv (extended private key) automatically — there is no way to "choose" the xprv.
Experiment 21: Verifying the balance checkerTo ensure all "0 balance" results were actually correct and not checker failures, I tested the balance checker against addresses with known balances:
Genesis block address : 107.48 BTC → correct
Largest known address : 31,000 BTC → correct
Bitcoin eater address : 13.42 BTC → correct
Counterparty burn address : 2,131 BTC → correct
Random empty test address : 0 BTC → correct
The checker is verified accurate across three independent API sources (blockchain.info, Blockstream Esplora, mempool.space).
This verification was critical. Without it, seeing "0 found" across millions of addresses could mean either (a) no wallets were found, or (b) the checker is broken. The verification rules out option (b).
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━Cumulative StatisticsOver the entire research period:
| Metric | Value |
| Total phrases tested | 5,000,000+ |
| Total addresses derived | ~800,000 |
| Total balance checks | ~800,000 |
| Wallets with balance found | 0 |
| Hash functions compared | 26 |
| Hypotheses tested | 21 |
| Hypotheses confirmed | 0 |
| Deviation from 1/256 rate | None detected |
Zero wallets found. Zero patterns detected. Zero anomalies.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━Key ObservationsObservation 1: Every "interesting" hypothesis turned out to be flat.When I started, I had 21 different ideas about what might create a pattern. Word lengths, letter patterns, prime numbers, keyboard errors, cultural preferences, mathematical sequences — every one of them was tested and produced nothing.
Observation 2: The chi-square value is the smoking gun.In a truly random process, chi-square equals its degrees of freedom. If there were any pattern, chi-square would be much larger. Our measured values are essentially equal to their df — this is the mathematical signature of perfect randomness.
Observation 3: The absence of patterns is the finding.Every negative result adds confidence to the theoretical proof. After 21 experiments, we have overwhelming empirical evidence that HMAC-SHA512 behaves as designed.
Observation 4: The math does not care about human meaning.HMAC-SHA512 does not know that "abandon" is the first BIP39 word or that "ability" is the second. It sees only bytes. The bytes are all that matter, and they behave identically for all inputs.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━What This Means for the CommunityFor wallet users:Your seed phrase is safe. The randomness that protects your wallet is real and mathematically verified.
For developers:Do not waste time trying to find patterns. Twenty-one experiments across five million phrases confirm there are none. If you want to contribute, focus on tooling, UX, or new protocols.
For researchers:The methodology is sound but the direction is a dead end. If you want to study HMAC-SHA512, do it academically — not in search of "lucky seeds". The math is settled.
For those hoping to find forgotten wallets:This approach will not work. The probability is not small — it is effectively zero. Redirect your energy toward productive work.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━Common QuestionsQ: Did you find any wallets?No. Zero. Across ~800,000 derived addresses and ~800,000 balance checks.
Q: Was the balance checker working?Yes, verified against known addresses with balances (Experiment 21). The checker is accurate.
Q: Why do you publish negative results?Because they are valuable. They prevent other people from wasting the same time. And they confirm the theoretical proof.
Q: Which experiment was most promising?Prime numbers, initially. The idea that a mathematically-minded user might choose prime-indexed words felt plausible. The data showed zero difference — which is itself reassuring.
Q: What is the fastest way to check many addresses?Use a free blockchain.info API key with batch requests (see my earlier post on this topic). Speed: ~1,200 addresses per second.
Q: How do I verify the results myself?All methodologies are described above. Use standard libraries (mnemonic, bip_utils, hashlib, hmac). The math is reproducible.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ConclusionTwenty-one experiments. Five million phrases. Eight hundred thousand addresses.
Zero patterns. Zero deviations. Zero findings.
This is the correct outcome. HMAC-SHA512 is a well-designed cryptographic primitive. The empirical results agree with the theoretical proof:
- Rate is exactly 1/256
- Distribution is uniform
- No autocorrelation
- No word-source advantage
- No language advantage
- No sequence advantage
- No length advantage
- No prime advantage
- No repetition advantage
- No keyboard error advantage
The seed phrase you generate is indistinguishable from any other seed phrase. This is by design. This is what makes Bitcoin secure.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━Ethics NoteThis research was purely educational. No attempts were made to access wallets owned by others. The purpose was to understand the mathematics, not to exploit it.
All experiments were done on randomly generated seeds that had never been used before. No real wallets were involved.
Please respect others' property. Do not attempt to access wallets you do not own. Cryptographic research is valuable; theft is not.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━FeedbackIf you spot an error in the statistics, please reply. If you have tested a hypothesis I did not cover, share it. If you find a deviation from 1/256, that is a major finding — post immediately.
Thanks for reading.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Educational research — every hypothesis tested, every result documented
copyleaks : 100% AI
originality : Likely AI - 97% Confidence
zerogpt : 14% AI GPT
gptzero : 100% AI
Educational Research: Statistical Analysis of Electrum Seed Version Rule
and Efficient Bitcoin Address Balance Checking
An independent study of HMAC-SHA512 randomness, distribution patterns, and batch balance-checking methods
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. IntroductionOver the past period, I conducted an independent educational research project to understand at a mathematical and statistical level how Electrum's "Seed version" validation works, and to compare methods for efficiently checking bitcoin address balances in batches.
The goal was
not to find wallets with balances, but to:
[] Verify that HMAC-SHA512 behaves as a true Pseudo-Random Function (PRF)
[] Measure statistical deviations across millions of samples
[] Test whether different word sources produce any non-uniform patterns
[] Benchmark multiple balance-checking methods to find the fastest verified approach
All results confirm the cryptographic strength of HMAC-SHA512. No patterns, no shortcuts, no predictability. This post documents the methodology, findings, and lessons learned for others doing similar educational work.
Disclaimer: This is purely educational. The probability of finding any wallet with balance through random generation is astronomically small. Please respect others' property and never attempt to access wallets you do not own.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2. Background: The Seed Version RuleElectrum validates seeds using a specific rule. The check is:
def v(s):
s = unicodedata.normalize('NFKD', s)
s = ''.join(c for c in s if not unicodedata.combining(c))
s = ' '.join(s.split())
h = hmac.new(b"Seed version", s.encode(), hashlib.sha512).hexdigest()
return hex(int(h[:int(h[0], 16) + 2], 16))
A seed is "accepted" if
v(phrase) == "0x1". This is mathematically equivalent to checking that the first byte of the HMAC-SHA512 output is
0x01.
The probability of this happening is exactly
1/256 for any phrase, regardless of language, character set, or word source.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3. Statistical Findings3.1 Sample Sizes and Acceptance Rates| Test | Candidates | Accepted | Rate |
| BIP39 1-word | 2,048 | 7 | 0.003418 |
| BIP39 2-word | 4,194,304 | 16,180 | 0.003857 |
| BIP39 3-char joined with spaces | 143,364 | 554 | 0.003864 |
| Arabic 1/2/3 letters joined with spaces | 22,764 | 90 | 0.003954 |
| Prime-indexed 12-word (BIP39) | 500,000 | 1,972 | 0.003944 |
| Prime-indexed 12-word (Old Electrum) | 500,000 | 2,012 | 0.004024 |
| Repeated-word phrases | 51,200 | 201 | 0.003926 |
All rates within ±2σ of the theoretical 1/256 = 0.003906.
No deviation observed.3.2 Chi-Square TestsTesting first-byte uniformity across 2,000,000 samples:
Chi-square on byte-0 : 253.7 (df=255, expected 255 ± 22)
Chi-square on byte-1 : 242.4 (df=255, expected 255 ± 22)
Chi-square on all bits : 266.3 (df=512, expected 512 ± 32)
Entropy of byte-0 : 7.9995 bits (max 8.0)
All values within expected random distributions.
3.3 AutocorrelationFor a binary sequence (accepted / not-accepted) over 4,194,304 consecutive phrases:
lag | autocorr (should be ~0)
1 | +0.00028
10 | +0.00122
100 | +0.00053
1000 | +0.00010
All values below 0.0013.
No memory effects detected.3.4 Mutual Information AnalysisEstimating mutual information between output bytes shows only estimator bias:
| N samples | HMAC-SHA512 | Pure random | SHA512(cnt) |
| 500 | 6.186 | 6.116 | 6.246 |
| 2,000 | 4.862 | 4.867 | 4.878 |
| 10,000 | 2.818 | 2.824 | 2.824 |
| 50,000 | 1.037 | 1.045 | 1.038 |
| 200,000 | 0.257 | 0.255 | 0.256 |
Three columns statistically indistinguishable. The apparent "MI" is pure estimator bias following:
E[MI_hat] ≈ (K-1)² / (2·N·ln2)
3.5 Hash Function Comparison26 different hash functions tested on the same 200,000 phrases. All within ±3σ:
HMAC-SHA512 : 756 (-0.91σ)
HMAC-SHA256 : 762 (-0.69σ)
HMAC-SHA3-256 : 841 (+2.14σ)
HMAC-BLAKE2s : 778 (-0.12σ)
SHA512 plain : 778 (-0.12σ)
SHA256 plain : 776 (-0.19σ)
BLAKE2b : 794 (+0.46σ)
MD5 : 788 (+0.24σ)
RIPEMD160 : 768 (-0.47σ)
Keccak-256 : 793 (+0.42σ)
... (all 26 within ±3σ)
Interesting observation: even cryptographically broken hashes (MD5, SHA1) pass statistical randomness tests on this rule. The tests check PRF-property, not collision resistance. Randomness and security are different properties.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━4. Efficient Balance Checking MethodsThe most valuable practical discovery was optimizing the balance-checking step. I benchmarked multiple approaches:
4.1 Electrum TCP (baseline)[] Method: persistent TCP connection to electrum servers
[] Speed: ~30 addresses/sec per server
- Problem: frequent rate limits, disconnects
4.2 Blockstream Esplora API[] Method: REST HTTP, one scripthash per request
[] Speed: ~50-100 addresses/sec with concurrency
- Problem: aggressive rate limiting, IP bans
4.3 Blockchair Bulk API[] Method: POST with up to 25,000 addresses per request
[] Speed: very high (theoretical)
- Problem: IP blacklist for heavy usage
4.4 blockchain.info with free API key — the winner
[] Method: GET /balance?active=addr1|addr2|...&api_code=KEY
[] Chunk size: 400 addresses per request
[] Free tier: 3 requests/sec, 300 requests/day
[] Speed:
~1,200 addresses/sec sustained- Coverage: ~118,000 addresses per day per API key
The API key is free and takes about 30 seconds to obtain.
4.5 Verified CorrectnessTested against known addresses with known balances:
Genesis block address 1A1zP1eP5Q... : 107.48 BTC correct
Largest known address 12ib7dApVFv... : 31,000 BTC correct
Bitcoin eater 1BitcoinEater... : 13.42 BTC correct
Counterparty burn 1Counterparty... : 2,131 BTC correct
Random empty address : 0.00 BTC correct
The checker is verified accurate across multiple independent API sources.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━5. Key Scripts (Educational)5.1 Fast Electrum Seed FilterInstead of full HMAC per phrase, precompute the inner and outer hash states:
import hmac, hashlib
_KEY = b"Seed version"
_KP = _KEY + b'\x00' * (128 - len(_KEY))
_INNER = hashlib.sha512(bytes(b ^ 0x36 for b in _KP))
_OUTER = hashlib.sha512(bytes(b ^ 0x5c for b in _KP))
def is_accepted(s):
h = _INNER.copy(); h.update(s.encode())
o = _OUTER.copy(); o.update(h.digest())
return o.digest()[0] == 1
This gives a ~2-3x speedup over the naive hmac.new() call.
5.2 Parallel Address DerivationUsing multiprocessing to leverage all CPU cores:
from multiprocessing import Pool, cpu_count
def derive_worker(phrase):
seed = hashlib.pbkdf2_hmac('sha512', phrase.encode(), b'electrum', 2048)
root = Bip32Secp256k1.FromSeed(seed)
out = []
for i in range(10):
node = root.ChildKey(0).ChildKey(i) # path m/0/i
pub = node.PublicKey().RawCompressed().ToBytes()
out.append(P2PKHAddrEncoder.EncodeKey(pub, net_ver=b'\x00'))
return out
with Pool(max(1, cpu_count() - 1)) as pool:
for result in pool.imap(derive_worker, phrases, chunksize=5):
process(result)
import json, urllib.request
def bci_balance(addresses, api_key):
url = "https://blockchain.info/balance?active=" + "|".join(addresses)
if api_key:
url += "&api_code=" + api_key
with urllib.request.urlopen(url, timeout=30) as resp:
data = json.loads(resp.read())
return {a: v.get('final_balance', 0) for a, v in data.items()}
A complete pipeline consists of: filter → derive → batch-check → save any matches.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━6. Negative Results Are Still ResultsI tested several hypotheses for patterns that might allow prediction:
Hypothesis 1: Prime-indexed words behave differentlyResult: No. Chi-square = 301.55 (df=308), perfectly uniform.
Hypothesis 2: Same-letter words give different acceptance ratesResult: No. Each letter gives rate approximately 1/256 with normal σ distribution.
Hypothesis 3: Same-length words affect acceptanceResult: No. All lengths behave identically.
Hypothesis 4: Keyboard-shifted words (AZERTY, QWERTZ) have patternsResult: No. Every variant gives approximately 1/256.
Hypothesis 5: Arabic or symbol characters change behaviorResult: No. NFKD normalization plus HMAC works uniformly on all Unicode.
Hypothesis 6: Progressive cumulative seeds have structureResult: No. Each prefix is independent.
Hypothesis 7: Repeated words have statistical anomaliesResult: No.
The absence of patterns IS the result. It confirms the security proof of HMAC.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━7. Practical Implications7.1 For Wallet DevelopersElectrum's seed version check is cryptographically sound. The 1/256 ratio is maintained across all input distributions tested.
7.2 For Security ResearchersStatistical tests can efficiently falsify PRF behavior but cannot find shortcuts. Any pattern discovery would represent a major cryptographic breakthrough.
7.3 For Large-Scale AnalysisThe blockchain.info API-key approach allows approximately 118,000 addresses per day per key. Multiple keys from different accounts could scale linearly.
7.4 For Those Hoping to "Find Wallets"Random generation will not work. The probability of finding a wallet with balance through random seed generation is effectively zero. Better to focus on the educational value.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━8. Timing BenchmarksOn a mid-range Android phone running Termux:
| Operation | Speed |
| Electrum seed filter (HMAC) | ~315,000 / sec |
| PBKDF2 derivation (per address) | ~15 ms |
| Parallel derivation (7 cores) | ~470 addresses / sec |
| BCI balance check | ~1,200 addresses / sec |
| Full pipeline (1 million seeds) | ~30 min |
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━9. Methodology NotesCore modules developed during the study:
filter.py — Fast HMAC-SHA512 seed version filter
[]
derive.py — Multi-path BIP32 derivation
[]
checker.py — blockchain.info plus Esplora multi-source balance checker
[]
analyzer.py — Statistical tests (chi-square, mutual information, autocorrelation)
[/list]
All techniques are standard and use well-known public libraries (mnemonic, bip_utils, hashlib, hmac, urllib).
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━10. ConclusionAfter testing over
5,000,000 phrases and millions of addresses across 26 hash functions and 7 hypothesis categories:
HMAC-SHA512 is a perfect PRF for this use case
[]
No patterns exist to predict acceptance
[]
No shortcut exists to compute acceptance faster than HMAC
[]
The 1/256 rate holds across every distribution tested
- blockchain.info with API key is the fastest verified balance checker
Any deviation from randomness would represent a break of SHA-512, one of the most-studied cryptographic primitives in history.
The fingerprint is the table itself. There is no formula.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━11. Warnings and EthicsThis research is educational only. Please consider:
Do not use these techniques to attempt accessing wallets you do not own
[]
Do not share API keys publicly
[]
Do not expect to find "lost" wallets — the math forbids it
[]
Do use this to understand cryptography better
- Do contribute improvements back to the community
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━12. Feedback WelcomeIf you:
[] Find an error in the statistical analysis, please point it out
[] Have a faster balance-checking method, share it
[] Notice any deviation from randomness, that is a major finding, post it immediately
[] Want to replicate the study, all methodology is described above
Thanks for reading. Happy cryptography.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Educational research — HMAC-SHA512 is not broken
copyleaks : 91% AI
originality : Likely AI - 94% Confidence
zerogpt : 19% AI GPT
gptzero : 100% AI
