Changelog — what changed on this site, and when

How to read this page

This log lists changes that affect what you read or use: new pages and guides, new tools and widgets, factual corrections, and structural fixes that change how the site works. Small wording tweaks and formatting-only changes are not logged here. Every entry below was verified before going live — the same checks (structure, links, schema, search index, contrast and mobile layout) run before anything ships.

Corrections are listed as prominently as additions on purpose. If a claim on the site changes, the old claim was wrong or misleading, and the correction is part of the record. The "last reviewed" date on each page shows the last time that page went through the full check.

Pages are organised for clarity over hype: the diagnosis quiz stops early when the answer is already clear, the master list shows the verdict for every wallet in one glance, and pages that cannot help you say so instead of sending you down a tool path. If a page changes because a tool or format changed, the page and its sources update together.

16 August 2026

• Corrected (source link, launch prep): the “should you pay a wallet recovery service?” page’s UK fraud-reporting link pointed to the former Action Fraud site — Action Fraud was replaced by the national Report Fraud service (City of London Police, since 4 December 2025), so the sources list now links https://www.reportfraud.police.uk/ (“UK Report Fraud — report a fraud”) and the report-to-your-local-authority step now names Report Fraud instead of Action Fraud (EN + NL).
• Changed (diagnosis quiz): the quiz no longer asks whether you shared your seed phrase with a website or a person — the question and its “Stop — your seed phrase may be compromised” verdict are removed. The flow is now password → file → memory → how-it-was-created, and passphrase → memory → how-it-was-created (EN + NL).

15 August 2026

• Corrected (7 points from a new deep re-audit): (1) Dogechain.info now has its own master-list row — it is not the bitcoinj scrypt family: it uses PBKDF2-HMAC-SHA256 + AES with parameters/version stored in the wallet data, btcrecover reads the export directly, and hashcat mode 32500 covers the applicable/older format while newer payload variants (e.g. AES-GCM) may differ, so identify the wallet format first (EN + NL). (2) keplr2john.py is now consistently scoped to the legacy Keplr extension format on the file-finder, John walkthrough, old-phone guide and cheat sheet — the master list already had the v2 caveat (EN + NL). (3) the Electrum troubleshooting entry no longer tells you to confirm use_encryption in the raw JSON of a fully encrypted 2.8+ wallet — for fully encrypted files, identify the BIE1/BIE2 encrypted storage format or let the current extractor detect it, because the wallet JSON only becomes readable after decryption (EN + NL). (4) the encrypted-drive table now lists BestCrypt separately with hashcat 23900 (v3) / 24000 (v4) alongside bestcrypt2john, instead of presenting BestCrypt as John-only (EN + NL). (5) MetaMask mode 26620 is no longer called a community-only build — current/development hashcat includes 26620 and 26630 with dynamic iteration counts; the walkthrough mode table, extraction table and JSON-LD now list 26600/26610/26620/26630 with "check the installed version" (EN + NL). (6) Blockchain.com: very early legacy V0 wallets are now called out as a separate algorithm — hashcat mode 34700 (Blockchain, My Wallet, Legacy Wallets) is added to the master list, hashcat walkthrough, offline-tools mode table, cheat sheet, convert page and Blockchain.com guide, and 12700 is no longer labelled "original/v0" (EN + NL). (7) the "a wrong variant can open a different, empty wallet" warning is removed from the hashcat, John and btcrecover password-found steps — it is a seed-passphrase phenomenon (still kept on the BIP39 passphrase pages), not a verified encrypted-wallet password result (EN + NL).
• Corrected (7 points from a deep re-audit): (1) tezos2john.py is no longer described as a generic extractor for password-protected Tezos client key files — it is the Tezos ICO/fundraiser route (15-word mnemonic, fundraiser email, tz1 address), now stated on the file identifier, file-finder and John the Ripper walkthrough (the master list already had it) (EN + NL). (2) fork wallets no longer share "exactly the same wallet.dat format" as a blanket claim — the Core-derived clients share Bitcoin Core's legacy wallet encryption, but the filename does not tell you which database backend is inside (legacy Berkeley DB vs modern SQLite descriptor wallets, and forks differ), now on the fork guide, wallet.dat guide and file identifier (EN + NL). (3) the master list's security-model taxonomy now splits "Seed-based" from "Passphrase-as-key" — BIP38 encrypted private keys and brain wallets are no longer lumped into a "restore the phrase or key and the forgotten password stops mattering" category, because the passphrase itself is the recovery target (EN + NL). (4) the "recovery without the wallet file" flow and FAQ now list BIP38 encrypted private keys as a real exception (the 6P… string is itself the encrypted recovery target), alongside the seed phrase, custodial accounts and brain wallets — four real cases, not three (EN + NL). (5) the FAQ no longer says the seed phrase derives every key in the wallet — it is the master backup for the accounts and keys derived from that phrase, while imported private keys, hardware-wallet accounts, additional recovery phrases and some legacy wallet data may need separate backups; the same wording now backs the glossary's seed-phrase definition (EN + NL). (6) the no-file flow, the Blockchain.com guide and the FAQ now point to the Blockchain.com mobile app's encrypted cloud backup (Apple iCloud / Google Drive) as a documented recovery route when the wallet password and/or Recovery Phrase are lost — restore on the same OS/cloud account with your app PIN; not a guarantee, but worth checking before writing the wallet off (EN + NL). (7) Armory is no longer presented as unsupported by current maintained tooling — current John the Ripper Jumbo supports Armory wallet hashes from btcrecover data extracts (extract-armory-privkey.py), with the caveat that a compatible extraction step is still required and the format remains slow (master list, glossary, file identifier; EN + NL).
• Corrected (6 points from a deep re-audit): (1) KeePass KDBX 4 no longer automatically means Argon2 — KDBX 4 lets you choose AES-KDF or Argon2, so the password-manager guide, hashcat walkthrough, hint list, cheat sheet and encrypted-file guide now say to identify the version and KDF first (keepass2john reports it) and list the current hashcat modes 34300 (Argon2) and 34301 (AESKDF) (EN + NL). (2) the Exodus guide now checks other recovery sources before seed.seco — a synced Exodus device, the pre-February-2019 email backup, passkey + iCloud/Google Drive backup, and archived data from an overwritten wallet — and only treats the local file as the crack target once those are ruled out (EN + NL). (3) MetaMask now opens with "how was this wallet created?" — SRP-created wallets follow the classic local-vault flow, while Google/Apple/Telegram-created wallets protect the Secret Recovery Phrase with the social account and MetaMask password together, so "no SRP" no longer universally means "crack the local vault" (EN + NL). (4) the Monero guide no longer sends a forgotten optional passphrase to the BIP39 25th-word page without context — Monero's passphrase is a seed offset (mnemonic + offset derive a different wallet), now explained with the official restore-from-seed guide (EN + NL). (5) Monero's .keys file is no longer "the only door" — the page now lists three routes: seed restore, official restore-from-keys (primary address + private spend/view keys), and only then password recovery on the .keys file (EN + NL). (6) the John the Ripper FAQ no longer says "or your distro's john package" as if any package works — distro packages only count if they are real jumbo builds with the wallet formats and *2john scripts; Debian/Ubuntu's john is core-only (EN + NL).
• Added (legal, launch prep): the disclaimer now carries an explicit "Limitation of liability / Aansprakelijkheid" section — the site and its instructions are used at your own risk, and to the fullest extent permitted by law the operator is not liable for loss or damage, including loss of funds, arising from following them (EN + NL). New pages: Privacy Policy (data controller Crypto Recovers / Robbert Bink, KVK 75927276, Le Mairekade 77, 1013 CB Amsterdam; local tools never send search/token/calculator input to the server; server logs ≤ 90 days; contact email ≤ 12 months; no advertising/tracking cookies or analytics on this site; GDPR rights; recovery-service data handled under the separate Crypto Recovers privacy policy) and Terms of Use (educational use only, acceptable use on your own wallets/devices, no professional relationship, no guarantees, intellectual property, "as is"/"as available" warranty disclaimer, limitation of liability, Dutch law / Amsterdam courts). The footer now links About · Contact · Disclaimer · Privacy · Terms on every page (EN + NL). Both new pages are in the sitemap (62/62), llms.txt/llms-full.txt, the search index (EN + NL) and carry WebPage + BreadcrumbList JSON-LD. A site-wide claim audit (EN + NL) confirmed every guarantee/success mention is a negation or scam warning — the site promises no results anywhere.
• Corrected (site-wide, safety copy): the site no longer says "never your file / never your hash" as an absolute — it now distinguishes seed phrase/private keys (never share) from encrypted wallet files and hashes/extracts (sensitive, but technically needed for legitimate recovery; only local/offline or within a clear written, trusted process, never public checkers or unknown websites). Updated: the nav tagline ("never your seed, never public uploads"), the online-crackers page itself (hero, answer box, safety rules, meta/og/tw/JSON-LD), the convert page ("not doing recovery" → "not running a safe recovery"), Exodus, Blockchain.com .aes.json, the btcrecover/hashcat/John/offline-tools callouts, the FAQ upload rule, the DIY page, the scammers rule, the encrypted-file page (4 spots), password manager, hint list, cheat sheet, master list, Monero, when-recovery-is-possible and protect-your-wallet-files (EN + NL).
• Corrected (honest math & wording): (1) the how-long cracking-time table is split into blind brute force (full range — 6 lowercase random = 26⁶ ≈ 309M candidates: wallet.dat hours to about a day, Ethereum scrypt ~37 days, BIP38 ~50–83 days; 8 chars letters+digits = centuries–millennia/forever; 12+ random = forever) and smart attack (fast only with strong clues / small candidate lists). (2) password-vs-seed no longer says "funds are not gone … doors can be opened … almost always recoverable" — the correct file makes recovery possible, but odds depend on the format, file condition, password strength and memory. (3) the FAQ no longer says passwords are tested "against the wallet file (or seed phrase)" — testing targets an encrypted wallet file, keystore, hash/extract or known address; a seed phrase itself is not cracked like a wallet password. (4) John the Ripper is no longer blanket-labelled "the classic CPU cracker" — many wallet formats are CPU-oriented, some have GPU/OpenCL support depending on the Jumbo build; Monero .keys stays a CPU-style route. (5) the entropy calculator now says clue reductions are rough examples, not predictions. (6) lost-crypto-statistics no longer claims wallet.dat "before roughly 2021" used "far weaker settings" — older files often have fewer rounds, but the exact count is stored in the file and not determined by the year. (7) guide numbers fixed on protect-your-wallet-files (feasibility = guide 08, old-passwords sweep = guide 05) and the Coinbase Wallet / Base App closure note was added to the master-list seed-based taxonomy (EN + NL).
• Corrected (1Password Secret Key, PDF modes, glossary scrypt, prevention advice): (1) the password-manager walkthrough no longer says "a cracked master password opens the vault" as a blanket — for some managers it may, but for modern 1Password accounts the account password alone is not enough: the Secret Key, an already signed-in device, Emergency Kit, recovery code or another supported recovery route may also be required. (2) PDF modes on the encrypted-file page and the cheat sheet now list 10400/10500/10600/10700 and, in some cases, 25400 — let pdf2john output and hashcat --help decide. (3) the glossary scrypt entry no longer presents N=262144, r=8, p=1 as universal for Ethereum keystores — the parameters are stored in the JSON under kdfparams; geth-style keystores commonly use those values, others may differ. (4) the never-lose-access sealed-envelope advice now warns not to put every access component in one place (EN + NL).
• Corrected (should-i-pay consistency): the service page no longer mixes two strictness levels — the Level 2 bullet, the red-flag bullet and the before-you-pay checklist title + hint now all say the same thing: never upload the wallet file to a public checker or unknown website; only under a clear written agreement with a verified professional may the encrypted file itself be processed in a controlled workflow; the standard remote route is the extract (level 3); your seed phrase is never shared under any contract (EN + NL).
• Corrected (post-audit, external technical audit): (1) the Ethereum keystore scrypt labels on the benchmarks page, the cracking-time table and the entropy calculator now state the geth/Web3 standard N=2¹⁸ = 262,144 (r=8 p=1) instead of N=2¹⁷, with the fine-print that the published btcrecover suite’s reference test uses N=2¹⁷ — the measured 96/s applies to that test, and a standard 2¹⁸ keystore tests roughly 2× slower per guess on the same hardware (EN + NL). (2) the wallet-identifier widget’s Ethereum KDF label now reads scrypt N=2¹⁸ r=8 p=1 (geth standard) · or PBKDF2 262,144 iterations (EN + NL). (3) the classic Coinbase Wallet note on the master list and wallet identifier no longer carries the unverifiable specific closure date — it now says the classic Coinbase Wallet is being retired in favor of the Base App, with the recovery phrase and addresses remaining (EN + NL). Re-verified correct, no change: the “official btcrecover benchmark suite” sourcing, best66.rule, every hashcat mode and *2john extractor, FAQPage schema, sitemap/robots/redirects and the crack-time arithmetic.
• Changed (diagnosis quiz): the homepage diagnosis quiz no longer asks “have you already paid anyone?” — the paid-a-“recovery”-service option and its verdict are removed; the risk step now only asks whether you shared your seed phrase (No / Shared), with the question and the “no” answer reworded accordingly (EN + NL).
• Changed (theme default): the site now starts in light mode on first visit regardless of the operating system’s color scheme; the light/dark toggle and any saved preference still work exactly as before (EN + NL, all 128 pages).
• Changed (diagnosis flow — quiz + what-to-do): (1) the homepage quiz is now the single interactive router — its first question is reworded from terminology (“password / seed / passphrase / PIN”) to plain access language (“What are you trying to open or restore?” with concrete descriptions), and the password verdicts now link to the master list (verdict per wallet) so the quiz routes to the site’s strongest asset. (2) a machine-generated (password-manager) password with no or only fragmentary memory now gets an honest “effectively unrecoverable” verdict instead of “possible”. (3) the what-to-do page is no longer a competing six-question decision tree — it is the same flow in reading form, with a prominent link to the interactive diagnosis and the same branches and destinations (custodial, seed, passphrase, wallet-file password, PIN, not-a-password-problem). Title/meta/JSON-LD, the nav label (“the diagnosis flow”), the homepage and guides cards, search keywords and every “six-question decision tree” reference are updated site-wide (EN + NL).

14 August 2026

• Corrected (7 content points + 2 cleanups): (1) BIP39 passphrase is no longer CPU-only on the benchmarks page — the official BTCRecover set includes an RTX 5090/OpenCL measurement (~19,950/s), now shown in the table, and the CPU-only fine-print is removed (EN + NL). (2) the entropy calculator now uses the real RTX 5090/OpenCL rates — BIP39 19,950, Blockchain.com v2 9,470, v3 20,030 (with CPU noted where slower) — instead of copying CPU rates into the GPU column (EN + NL). (3) the wallet.dat "old/pre-0.21 vs modern/0.21+" framing is removed — age can be a rough clue, but the machine-tuned nDeriveIterations stored in the file determines cost; the lost-statistics rows are now "low-round (original ~25,000 baseline)" and "reference wallets", and the wallet.dat answer box says "especially low-round files" (EN + NL). (4) the Chainalysis methodology description is corrected — it segmented the supply by coin age and activity, not "counted five-years-untouched addresses"; the "five-years-untouched method" phrasing is removed (EN + NL). (5) the hashcat walkthrough's MetaMask line no longer sends newer extension vaults to 26600 — it now says extension vaults may use 26600 or 26610 depending on the extracted hash/layout and to use the installed version's supported mode (EN + NL). (6) "restore the wallet anywhere" is qualified on the old-phone, Monero and Blockchain.com pages — restore in the original or a compatible wallet that supports the same seed type, coin and derivation settings (EN + NL). (7) "hardware wallet PINs work the same way" is replaced with the device-specific statement (retry limits, delays, reset behaviour; check the manufacturer's docs) (EN + NL). Cleanups: MultiBit superlatives softened ("one of the fastest common formats" / "exceptionally weak by modern standards") and the benchmarks freshness date is now 14 August (EN + NL).
• Corrected (missed-propagation cleanup, 7 items): (1) the homepage Ethereum card no longer says "the slowest common format" — now "among the slower common formats" (EN + NL). (2) the homepage fork-wallet card no longer says "same encryption, same recovery rules" — it now notes that wallet type/version and Windows data-directory defaults differ per coin, so check each client's actual setup (EN + NL); the fork-wallet page meta/JSON-LD descriptions now say the same. (3) the homepage MetaMask card no longer says "the seed restores instantly" — it now says the seed restores its SRP-derived accounts and imported private-key/JSON or hardware accounts need their own recovery material (EN + NL). (4) the homepage Exodus card no longer says "the 12-word seed restores instantly" — now "restores the wallet without the password" (EN + NL). (5) what-to-do Q2 no longer says "most wallets restore completely" — now the seed-derived-accounts nuance with the imported-accounts caveat (EN + NL). (6) password-vs-seed-phrase: the seed row no longer says "the wallet can never be recreated on any device" and the MetaMask line no longer says "the phrase restores everything" — both now carry the seed-derived/imported-accounts nuance (EN + NL). (7) verified already clean: the old "the .dat / keystore file Electrum encrypts" and "the Android scrypt vault" nav labels (rounds 44/37) and the UTC– en-dash (round 47) — 0 occurrences remain.
• Corrected (2 points; 1 mostly already fixed and enhanced): (1) the password-manager page's 1Password guidance already required conversion with 1password2john.py for agilekeychain/cloudkeychain and treated 31800 as a separate format (round 22) — the 31800 row and the walkthrough step now additionally say to verify the exact local format and required extraction route first (EN + NL). (2) the 68-place checklist no longer says Time Machine snapshots restore files you deleted years ago as a guarantee — it now says old backups can be thinned or deleted when the backup disk fills and local snapshots are short-lived, so check the backup timeline around the wallet setup period without assuming years-old deleted files are present (EN + NL).
• Corrected (3 points): (1) the 68-place checklist no longer implies a dead laptop drive is automatically readable — if the disk uses BitLocker, FileVault or another full-disk encryption system, the unlock password, recovery key or account-based recovery route is also required (both drive entries, EN + NL). (2) the Linux/macOS grep example now uses real shell quotes — grep -Rni "seed" ~ instead of smart quotes that would be treated as literal characters (EN + NL). (3) "no countdown / nothing expires / time alone never does" is now qualified — there is usually no blockchain countdown, but data-retention countdowns (cloud trash, recently deleted files/photos, email trash, backup retention, SSD behavior) are time-sensitive, so freeze the device and check recoverable windows promptly (first-24-hours page + DIY page, EN + NL).
• Corrected (2 points): (1) the custodial flow page now carries an explicit callout distinguishing Coinbase exchange (custodial, reset/KYC) from Coinbase Wallet / Base App (self-custody — recovery depends on the recovery phrase, cloud backup, passkey/signer setup or remaining device access; Coinbase cannot recover or move funds for you) (EN + NL). (2) "Deleted ≠ gone" now carries the SSD/TRIM caveat on both the first-24-hours and protect-your-wallet-files pages — on a modern SSD deleted data can become unrecoverable quickly, so stop using the device immediately, avoid rebooting or installing recovery tools on it, and image the drive or get specialist help before experimenting (EN + NL).
• Corrected (2 points): (1) the password-vs-seed-phrase device-password row is no longer too reassuring — on phones and encrypted devices a forgotten passcode may require erasing the device, which can destroy local wallet data, so the page now says not to reset/wipe/factory-reset/reinstall before checking whether wallet data, backups or app storage can be preserved (table row + flow bullet, EN + NL). (2) Ethereum keystore filename patterns are now written with two regular hyphens — UTC--*.json / UTC--<timestamp>--<address> — the en-dash UTC– variants (16 files) and single-hyphen UTC-* variants are all corrected (EN + NL).
• Corrected: the 68-place search checklist no longer tells people to just "delete the photo afterward" when a photographed seed sheet is found in a cloud photo library — the seed is digitally exposed, so the route is: treat it as compromised, restore/check the wallet safely, create a fresh wallet with a new seed, move the funds to fresh addresses, and only then clean up the photo, trash folders, cloud backups and synced devices (EN + NL).
• Corrected: BIP38 encrypted private keys are now an explicit "no wallet file" case — the recovery-without-file page adds Exception 5 (a 6P… string is the encrypted recovery target itself; the forgotten passphrase is tested offline, e.g. btcrecover --bip38-enc-privkey) and its FAQ now lists four real cases; the "when it's not a password problem" page no longer says cracking only helps with an encrypted wallet file — it now notes the exceptions where the test target is not a wallet file (BIP38 encrypted private keys, brain wallets, supported seed-passphrase recovery). Also repaired a truncated Dutch answer-box paragraph on the latter page (EN + NL).
• Corrected: the global navigation/sidebar label for Electrum no longer calls it "the .dat / keystore file Electrum encrypts" — Electrum wallet files normally have no fixed .dat extension (the default is default_wallet in the Electrum wallets folder); the label now reads "the encrypted wallet file in Electrum's wallets folder" sitewide (60 EN + 61 NL files).
• Corrected: the password-vs-seed-phrase page no longer labels Electrum wallets as .aes files — Electrum wallet files have no fixed extension (often default_wallet in the Electrum wallets folder); the sentence now lists .dat, keystore JSON (UTC--*.json) and an Electrum wallet file in the Electrum data folder (EN + NL).
• Corrected: the password hint list's BTCRecover examples no longer put spaces between fixed text and wildcards — tokens on one line are alternatives in BTCRecover, so Markus %1,6a 2019 becomes Markus%1,6a2019 and %1,4a !23$ becomes %1,4a!23$, with python btcrecover.py --listpass --tokenlist tokens.txt added so readers can preview the candidates actually generated; the hashcat mask for "starts with Markus" now literally includes Markus (Markus?a?a?a?a?a?a?d?d?d?d) (EN + NL).
• Corrected (2 points): (1) the fork-wallet guide no longer says every Core-derived fork's current Windows default is %LOCALAPPDATA% — it now splits per client: Bitcoin Core current %LOCALAPPDATA%\Bitcoin with legacy %APPDATA% still relevant, Dogecoin Core check %APPDATA%\Dogecoin first, Litecoin Core check %APPDATA%\Litecoin first unless the installed version documents otherwise, with %LOCALAPPDATA% as an extra fallback (EN + NL). (2) the file-finder now lists the legacy Windows geth keystore location %APPDATA%\Ethereum\keystore alongside the current %LOCALAPPDATA%\Ethereum\keystore, and says to search both before concluding none exists (EN + NL).
• Corrected (4 points; 1 already fixed and re-verified): (1) the offline-tools page no longer says a high-round wallet.dat is "low hundreds" on GPU — the benchmarked high-round reference is low hundreds per second on CPU, with GPU results reaching several thousand depending on the wallet parameters and tool path (EN + NL). (2) the hashcat walkthrough's mode-list JSON-LD now labels 13400 as KeePass (AES-KDF) — the mode table already carried the AES-KDF / KDBX4 caveat (EN + NL). (3) the hashcat walkthrough's protected-documents summary now lists RAR 12500/23700/23800/13000 with "mode depends on what rar2john produces" instead of only 12500/13000 (EN + NL). (4) the encrypted-file LUKS row now splits the extraction route: Hashcat uses luks2hashcat.py (14600/29511–29543 LUKS1 variants; 34100 for supported LUKS2/Argon2 configs after checking the KDF), John uses luks2john (EN + NL). VeraCrypt/TrueCrypt extraction: re-verified — already split into veracrypt2hashcat.py / truecrypt2hashcat.py (round 32), no truecrypt2john remains.
• Corrected (3 points; 1 already fixed and re-verified): (1) the BIP39 passphrase command on the cheat sheet and btcrecover walkthrough is now a complete, runnable form — --bip39 --mnemonic "…" --addrs <known-address> --addr-limit 10 --tokenlist tokens.txt — with the note that the mnemonic plus a known address/xpub target are required, and that Ethereum/altcoin cases often need --wallet-type (EN + NL). (2) Ethereum keystore "no extraction" claims: re-verified — the extraction guide and hashcat walkthrough already say hashcat does not read the raw UTC JSON and require ethereum2john.py / the $ethereum$… format (rounds 19/20); no change needed. (3) the wallet identifier now carries a current Coinbase note — the classic Coinbase Wallet closes on 15 August 2026, the recovery phrase and addresses remain, and some classic-wallet networks are not supported in the Base App (EN + NL). (4) the password-vs-seed-phrase table no longer says the phrase derives every key in the wallet — it now says seed-derived wallets derive their normal accounts and that manually imported private keys, JSON accounts, hardware-wallet accounts or accounts from another phrase may need separate recovery material (EN + NL).
• Corrected (5 points): MultiBit — the guide, FAQ and cheat sheet no longer claim the Classic .wallet "needs hashcat 27700 / multibit2john": btcrecover can read it directly, but the .key backup is strongly preferred because it is much faster; hashcat 27700 / John via multibit2john are alternatives that require extraction (EN + NL). Coinomi — the sidebar label is no longer "the Android scrypt vault" (sitewide EN + NL), the vault section now notes that the crackable-file assumption applies to password-protected wallets (biometrics / no-password / password + biometrics need device-keystore material), and the old-phone guide notes that Coinomi Desktop/Windows is not a phone-extraction case (%LOCALAPPDATA%\Coinomi\Coinomi\wallets) (EN + NL). Seed-passphrase: the "if one is lost, the other still unlocks the wallet" sentence is not present in the current build (round 23 fix, re-verified — the page says both are required and either may mean permanent loss of access). Blockchain.com: the "recover without wallet file" page now carries the same legacy payload-retrieval exception as the guide (Wallet ID + email/2FA during a login attempt; not a reset, not guaranteed) (EN + NL).
• Corrected (17 points from a 23-point audit; 6 were already fixed in earlier rounds and re-verified): (1) Ethereum keystore KDF path is now crypto.kdfparams.n (was crypto.scrypt.n) (EN + NL). (2) PBKDF2 262,144 is no longer hardcoded as universal in the encryption explainer — the count is stored in the file's kdfparams.c (EN + NL). (3) the ~96 guesses/sec Ethereum figure is now labelled as the measured 9950X CPU reference run, not a GPU claim (guide FAQ + JSON-LD, how-long page, EN + NL). (4) the how-long measured table keeps the Ethereum benchmark at N=2¹⁷ only (was N=2¹⁷–2¹⁸) (EN + NL). (5) Ethereum is now "among the slower/harder common wallet formats", not "slowest/most secure/hardest" (H1, intro, answer box, hashcat paragraph, cite, EN + NL). (6) MetaMask SRP restores only SRP-derived accounts — imported accounts need their own material (already fixed in round 24, re-verified). (7) Coinomi: "whoever holds the phrase controls the funds, full stop" now says the phrase plus any optional BIP39 passphrase are both required to restore (EN + NL). (8) FAQ: "no legitimate tool ever needs your credentials" now distinguishes entering material locally into verified offline tools from sending it to anyone; "wallet can never be recreated" now says access may still be recoverable from a surviving key-bearing backup, wallet file or device (EN + NL). (9) Bitcoin Core backend row is now wallet-type based (legacy BDB vs SQLite descriptor wallets), not "0.21+ = SQLite" (EN + NL). (10–12) Armory: historical btcrecover distinction and root-key paper backup were already fixed in round 24 (re-verified); the "16 MB" KDF constant is now "memory/iteration parameters calibrated per wallet" (EN + NL). (13) WarpWallet: no longer described as plain scrypt — scrypt N=2¹⁸ XOR PBKDF2-HMAC-SHA256 2¹⁶ rounds (master list + brain-wallet guide + JSON-LD, EN + NL). (14) master list "one of two security models" now lists seed/key-based, file-based, hardware/device-based and custodial (EN + NL). (15) never-lose-access "almost every wallet is seed-backed" now follows the wallet-type taxonomy, and the PIN row says failed-PIN behavior is model-specific — devices may wipe, lock or permanently brick (EN + NL). (16) how-long page: the ratio math is fixed (~1.3×, not 5×, vs the 122/s row), the BIP38 GPU row is restored (43/s OpenCL; CPU measured faster at 72), the 12+/16+ statements carry the full-printable-alphabet assumption, and the "6 lowercase" example is now actually lowercase (bfqxwm) (EN + NL). (17) master list MetaMask row no longer presents 900k as a universal default — read the stored count (EN + NL). The MetaMask timeline split (round 26) is re-verified.
• Corrected (11 points from a 13-point audit; 4 were already fixed in earlier rounds and re-verified): (1) rented-GPU guidance no longer says an extracted hash line is safe to upload generically — remote-compute safety is format- and extractor-dependent (ethereum2john.py warns against sharing its extracts; some btcrecover extracts are minimized for cloud), and an untrusted rented machine may learn the recovered plaintext password (offline-tools page, EN + NL). (2) Monero: the file table and FAQ no longer call the extensionless wallet file "JSON, not encrypted" — both <walletname> (encrypted wallet cache) and <walletname>.keys (encrypted keys/settings) are password-encrypted per official Monero docs; .cache is a derived file, not the standard documented pair (EN + NL). (3) BIP38: the guide no longer suggests Electrum/MultiBit can import an encrypted 6P key directly — decrypt offline with a BIP38-capable tool first, then sweep into a fresh wallet (EN + NL). (4) Ethereum keystore: the "which wallets" list now separates wallets that create/export V3 JSON from wallets that only import it (MetaMask: import via "Import account with JSON file", the file keeps its own password; MetaMask's ordinary export is a private key) (EN + NL). (5) "move funds to a maintained wallet" is now "create a fresh wallet with a new seed, back it up, verify, then send/sweep" — importing old keys does not make them fresh — applied consistently in the hashcat, btcrecover and John walkthroughs (EN + NL). (6) btcrecover walkthrough: no longer implies btcrecover's own extracts are generic hashcat input — the format's *2john/*2hashcat extractor is the conversion route (EN + NL). (7) hashcat mode table heading now says "official modes plus separately labelled community/development modes" (EN + NL). (8) offline-tools: "Handles all the crypto formats" → "many common crypto-wallet formats" (EN + NL). (9) Blockchain.com intro now explicitly calls the legacy mnemonic a "legacy credential-recovery mnemonic, not a BIP39 wallet seed" (EN + NL). Already fixed and re-verified: wallet.dat "opens without password = never encrypted" (rounds 17/25), Ethereum raw-JSON → hashcat (round 19), Exodus Mobile seed.seco (round 22), Blockchain.com v3 "genuinely slow" (round 17).
• Corrected (8 points): Tezos — the cheat sheet and master list no longer describe tezos2john.py as a generic client-key-file extractor: it is the Tezos ICO/fundraiser password route using mnemonic + fundraiser email + tz1 address. BTC.com/Blocktrail — the raw PDF is not a direct --wallet input; the recovery-sheet wallet data (passwordEncryptedSecretMnemonic) must be prepared first (cheat sheet + master list). Bither — the supported btcrecover target is the SQLite wallet database (format-3), not every exported/encrypted backup (cheat sheet + master list). block.io — "PIN search is fast" is replaced with the real KDF (PBKDF2-HMAC-SHA256) and a check-the-stored-iteration-count-first note (legacy ~2,048 vs newer 100,000+), plus the browser/Network data route (master list + cheat sheet). The "billions of combinations in minutes to hours" token-attack claim on the cracking-time page is corrected to runtime = candidate count ÷ wallet-specific measured rate, with the site's own benchmark examples. RAR3 — the cheat sheet now lists 12500 (RAR3-hp), 23700 (RAR3-p uncompressed), 23800 (RAR3-p compressed) and 13000 (RAR5), letting rar2john's output decide. ZIP — no more ".zip → 13600" mapping; PKZIP/ZipCrypto modes 17200/17210/17220/17225/17230 are listed with "let the extracted hash decide" (cheat sheet + encrypted-file guide, including the previously missing 17230). Terra Station and Stargazer — the cheat sheet no longer presents hashcat -m 29600/-m 25500 as directly runnable; both rows now state that extraction to the hash format comes first and link the extraction guide. Also added a one-line warning about 2john filename: prefixes in the cheat sheet fine-print (EN + NL).
• Corrected: KeePass rows no longer send every .kdbx to hashcat mode 13400 — 13400 covers only the supported AES-KDF KeePass formats; KDBX4 may use Argon2 and needs a KDBX4-compatible route, so identify the database version/KDF first (encrypted-file guide, cheat sheet, hashcat walkthrough mode table; EN + NL). MetaMask: mode 26620 is removed from the current stable "copy, adapt, run" references — current stable hashcat v7.0.0 has 26600, 26610 and 31900 but no 26620 (that mode appears only in later releases dated after 14 August 2026); the cheat sheet, convert page, master list, encryption timeline and encryption explainer now say 26620 is only in newer/development builds and to use the modes the installed version supports (EN + NL).
• Corrected: the encrypted-file guide no longer presents mode 22100 as a catch-all BitLocker route — hashcat 22100 accepts only user-password-protected VMK hashes (hash types 0/1). The row now splits BitLocker with a user-password protector (22100, bitlocker2john / bitlocker2hashcat.py) from TPM / TPM+PIN / startup-key protection (not the same offline route; TPM-protected VMKs cannot be converted) and the 48-digit recovery password (not an ordinary mode-22100 search; recovery-key brute force is treated as infeasible by the official extractor). VeraCrypt/TrueCrypt: the combined row with "29411–29483 (XTS) · truecrypt2john" is split — the current VeraCrypt hashcat route is 29411–29483 via veracrypt2hashcat.py (legacy 13711–13783 only if deliberate), the current TrueCrypt route is 29311–29343 via truecrypt2hashcat.py (legacy 6211–6243); the misleading "XTS" label is gone (EN + NL).
• Corrected: the cheat sheet no longer lists "Hive for OS X / Android / Web" as one btcrecover wallet-password route — btcrecover's wallet-password support covers Hive for OS X; Hive Android/iOS/Web are documented under seed recovery instead (EN + NL). LastPass: the cheat sheet no longer says "own export" for mode 6800 — the CSV account export contains no hash; the local XML/SQLite vault cache via lastpass2hashcat.py is the artifact (EN + NL). Ethereum keystore: the master list and encryption timeline no longer hardcode "scrypt N=262,144 / PBKDF2 262,144" as universal — the parameters are stored in each file's kdfparams; geth commonly uses scrypt N=262,144 but lighter/non-default configurations exist, so read the actual file before estimating recovery speed (EN + NL).
• Corrected: the encrypted-file guide and cheat sheet no longer route every macOS FileVault case through mode 16700 — older FileVault 2 / CoreStorage volumes use 16700 + fvde2john, while FileVault on APFS (macOS 10.13+) is a separate route (hashcat 18300, APFS), and on Apple silicon / T2 Macs the Secure Enclave key architecture applies, so identify the exact configuration first (EN + NL). The LUKS rows were already corrected in an earlier round — the old "no official mode / treat as unrecoverable" claim is gone — and now explicitly name luks2hashcat.py and mode 34100 for supported LUKS2 Argon2 configurations, splitting LUKS1 (29511–29543) from LUKS2 (EN + NL).
• Corrected: SLIP39 is no longer lumped under the BIP39 KDF row — BIP39 passphrases use PBKDF2-HMAC-SHA512 (2,048 iterations), while SLIP39 passphrases are a separate btcrecover recovery mode (--slip39) with their own Feistel + PBKDF2-HMAC-SHA256 construction, an iteration exponent stored in the material and a required share quorum (master list + cheat sheet, EN + NL). Electrum: the master list, cheat sheet and guide now flag 2FA / TrustedCoin wallets as a special case — current btcrecover documentation excludes 2FA wallets from its standard Electrum password-recovery support, so identify the wallet type before the generic route (EN + NL). Bitwarden: the cheat sheet now splits PBKDF2-configured vaults (mode 23400, bitwarden2john) from Argon2id-configured vaults, which do not use the generic 23400 route — identify the KDF first (EN + NL).
• Corrected: the wallet identifier no longer treats every modern phone wallet as a simple "12/24-word phrase → password irrelevant" case — it now says to identify the wallet model first. Trust Wallet SWIFT wallets use a passkey tied to your Apple/Google environment instead of a 12-word phrase; Coinbase Smart Wallet / Base wallet is passkey-based (a recovery phrase exists only if you set one); Phantom wallets created with Google or Apple recover via that account plus your PIN, with the phrase only exportable while you still have access. Updated on the identifier page (app-name list + seed-based definition), the identifier widget verdict, the file-finder Trust Wallet rows and the Phantom glossary entry (EN + NL).
• Corrected: the file-finder and the Blockchain.com FAQ no longer say there is no way to get the wallet file without the password — for some legacy Blockchain.com wallets the encrypted wallet payload can be retrieved during a login attempt (even with a wrong password) if you still have the Wallet ID and can pass the required email/2FA checks; version-dependent, not guaranteed for the current account flow (EN + NL). Coinomi: the guide and file-finder no longer describe Coinomi as Android-only — desktop installations keep .wallet files in the Coinomi data directory (e.g. %localappdata%\Coinomi\Coinomi\wallets) that btcrecover can read directly, so the recovery path now separates desktop from Android app storage. And the "vault file = crackable" claim now starts with a decision point: password-protected wallets can be attacked from the file, but biometrics, password + biometrics or no-password setups may additionally depend on device-keystore material — keep the device intact until that is ruled out (guide, FAQ visible + JSON-LD, EN + NL). Dutch: pre-existing slot drift on the Coinomi page repaired (fine-print, steps heading, 25th-word paragraph, common-mistakes list, next-step and sources sections were showing wrong fragments).
• Corrected: the file-finder no longer says the Yoroi recovery phrase is 24 words — wallets created directly in Yoroi use a 15-word recovery phrase; Yoroi can also restore compatible 24-word Cardano wallets created elsewhere (such as some Daedalus wallets). The master list already had this right; the find-file row now matches it (EN + NL).
• Corrected: the encryption timeline no longer collapses all MetaMask vaults into one "2016–present · 10,000 iterations · fast per guess" row. It now separates the legacy extension layout (10,000 fixed, hashcat 26600), newer extension vaults (iteration count stored in vault metadata — read the actual keyMetadata/KDF parameters instead of assuming a hard default; dynamic-count modes 26610/26620), and the MetaMask Mobile vault (separate format, hashcat 31900). The dedicated MetaMask guide, glossary PBKDF2 definition and the benchmark/calculator fine-print no longer present 900,000 as a hard universal default — they say to read the stored count, with 600,000 and 900,000 both documented (EN + NL).
• Corrected: the wallet.dat-family guide no longer uses "does the client ask for a password at startup?" as an encryption test — an encrypted Bitcoin Core wallet can load and display information while locked, so the correct check is getwalletinfo (unlocked_until, 0 = locked) on a safe working copy with a matching client version. The wrong startup-test step on the Bitcoin-family forks guide (EN + NL) is replaced; the wallet.dat FAQ and troubleshooting page already had the correct framing. KeePass: the manager guide, cheat sheet and search checklist no longer describe KeePass 1 as .kdbx — KeePass 1 databases are .kdb, KeePass 2 are .kdbx — and the extraction step now says to identify the database version first (EN + NL). BIP38: the wallet identifier no longer tells people with only a photo to "delete the photo" right after transcribing — the original must be preserved until the 6P… string is independently verified (ideally successfully decrypted); only a cloud-synced copy is removed, after a verified offline backup exists (EN + NL).
• Corrected: MetaMask, Blockchain.com and Armory pages no longer treat a seed phrase as proof that everything restores. MetaMask: the guide now says the SRP restores only accounts derived from that phrase — imported private-key/JSON accounts, hardware-wallet accounts, additional SRPs and some newer login-based setups may need separate recovery material, and every expected address must be verified before deleting the vault (guide, JSON-LD, FAQ, find-file page and identifier verdict; EN + NL). Blockchain.com: the 12-word phrase restores only the addresses derived from it — imported addresses are not backed up by the Recovery Phrase, so verify every expected address and balance before discarding anything (guide intro, answer box, generation list, common mistakes, FAQ, verdict, without-file page; EN + NL). Armory: the identifier no longer calls the paper backup a "12-word seed" — Armory's paper backup is its own Root Key / chain-code format — and the site no longer claims the current maintained btcrecover fork supports Armory: older Armory-specific tooling existed, so it is a legacy specialist workflow (identifier row, glossary, master list + FAQ; EN + NL).
• Corrected: the BIP39 passphrase backup rule no longer says "if one is lost, the other still unlocks the wallet" — a different passphrase (including an empty one) derives a different wallet, so both the seed and the passphrase are required to restore the same passphrase-protected wallet. The section keeps the separate-storage security advice while stating honestly that losing either may mean permanent loss of access (EN + NL).
• Corrected: the Monero guide no longer calls pre-2017 binary-format .keys wallets a "practical dead end" — John the Ripper's jumbo build added legacy Monero support (wallets that predate the JSON format), so the guide now says to run monero2john.py on the actual file first and treat extraction failure as format-/version-specific rather than assuming the file is unsupported (EN + NL).
• Corrected: the old-phone guide no longer routes Exodus Mobile through the desktop seed.seco / hashcat 28200 path — the table now separates Exodus Desktop (seed.seco → exodus2hashcat → 28200) from Exodus Mobile (app vault, no seed.seco assumption; the mobile-specific recovery path via the 12-word secret key / passkey) (EN + NL).
• Corrected: the password-manager guide no longer says to "point hashcat at the keychain files directly" for 1Password — for agilekeychain (6600) and cloudkeychain (8200), hashcat's own guidance points to 1password2john.py first; 31800 is a separate local mobilekeychain format (1Password 8). Updated in the visible guide, the mode table and the JSON-LD (EN + NL).
• Corrected: the Blockchain.com guide no longer treats the legacy blockchain.info mnemonic (6–25+ words) as a modern seed. That mnemonic is a password-recovery mechanism: a tool that supports the legacy format uses it to reveal the wallet password from the time the phrase was created — if the password was changed later, only that earlier password comes back. It does not regenerate keys and does not restore the wallet like a 12-word BIP39 Recovery Phrase. Updated on the guide (intro, answer box, generation list, common mistakes, FAQ — visible + JSON-LD, EN + NL); the "recovery without the wallet file" page already had the correct framing and was verified.
• Corrected: the Exodus guide no longer claims "GPUs barely help / tens to low hundreds of guesses per second" for hashcat mode 28200. Published benchmarks on high-end cards report roughly 5,000–10,000 guesses/sec (RTX 3090 Ti ~5,229/s; RTX 6000 Ada ~10,187/s). The guide now explains that scrypt makes each guess more expensive than simple hash formats, that mode 28200 has a working GPU path reaching thousands of guesses per second on modern GPUs, and that speed varies by hardware — benchmark your own machine (EN + NL). The Ethereum-keystore, BIP38 and VeraCrypt rows were left unchanged: those are different scrypt parameters where the "GPU barely helps" note is accurate.
• Fixed: site-wide Dutch nav and footer misalignment — the "By file format"/"By wallet / app" headings were rendering as list items (and vice versa) on every page. Root cause: the translation rebuild's difflib paired similar texts from different sections (nav vs footer) and shifted every following slot by one. The rebuild now uses positional pairing when the EN and NL structures match (they always do — NL is generated from the EN templates), and inner_to_text escapes literal asterisks inside code spans so values like *2john.py, UTC--*.json and $ethereum$p*… no longer mangle on the way back into HTML. All 60 NL translation files re-synced; 0 shifted slots, 0 markup corruption.
• Fixed: pre-existing content drift on 13 Dutch pages — the wallet guides (wallet.dat, Electrum, MultiBit, Coinomi, BIP38, brain wallet, forks), Ethereum keystore, "how to find your wallet file", reported-services, search checklist, strength calculator and the hashcat walkthrough's structured data had heading texts in paragraph slots and fragments in list items. All restored to match the English structure 1:1.
• Corrected: the encryption timeline no longer tells people to read seed_version from the wallet JSON to pick the Electrum hashcat mode — electrum2john.py detects the format itself (for fully encrypted 2.8+ wallets it processes the encrypted container, base64 BIE1, not the JSON), and the mode follows the generated $electrum$N prefix (1/2/3 → 16600, 4 → 21700, 5 → 21800). The same prefix-based guidance now appears on the Electrum guide FAQ, the extraction guide and the cheat sheet, with the two-layer note (internally encrypted seed + optional ECIES whole-file encryption since 2.8).
• Corrected: a leftover claim in the hashcat walkthrough's structured data said you can "pass Ethereum keystore JSON files directly" to hashcat — that now points to the ethereum2john.py conversion step (hashcat does not read the raw JSON).
• Corrected: the Ethereum keystore → hashcat workflow now runs through ethereum2john.py — hashcat does not read the raw UTC JSON; the script produces the $ethereum$p*…/$ethereum$s*… line for modes 15600/15700 (and the $ethereum$w*… line for the pre-sale format, mode 16300). Updated on the extraction guide, cheat sheet, hashcat walkthrough, encryption explainer, glossary, Ethereum guide, online-cracking page and the services FAQ.
• Corrected: every hashcat command on the site now uses rules/best66.rule — the current hashcat rules file, renamed from best64.rule — with a compatibility note for older installs.
• Corrected: the site no longer claims extracted hashes contain "no private keys" — an extract is not normally a plaintext private key, but it can contain sensitive encrypted wallet material, so it is treated as sensitive as the wallet file (extraction guide, encryption explainer, online-cracking page, services FAQ).
• Removed: the domain-check tool on the reported-services page — the searchable list is now the only check.
• Removed: the "Cite this page" box from non-reference pages — it now appears only on the wallet guides, tool walkthroughs and reference pages where a citation genuinely makes sense.
• Fixed: alignment and spacing of the correction line and the "helpful" card on every page; callout, title, table and KDF-diagram layouts on tablet and mobile.
• Fixed: dark-mode readability — guide navigation, table labels, inline code, verdict badges and checklist chips now use light text on dark surfaces.
• Expanded: the "never lose access" prevention guide now covers the wallet-file rule and the seed passphrase (13th/25th word) — not just the seed.
• Corrected: the "never lose access" guide no longer claims you must back up all three layers — which layers you need depends on the wallet; a multisig note was added.
• Corrected: the Dutch translation slots realigned site-wide — step numbers and FAQ summaries were being applied to the wrong elements on some pages.
• Corrected: MetaMask is now described version-aware — legacy vaults use 10,000 PBKDF2 iterations, newer vaults store their own KDF parameters (900,000 default) and need hashcat modes 26610/26620. Updated on the MetaMask guide, master list, homepage, cheat sheet, calculator, glossary and FAQ.
• Corrected: imToken is no longer described as part of the "MetaMask family" — it uses a modified Ethereum keystore (identity.json) and follows the Ethereum keystore guide.
• Corrected: the Blockchain.com guide now separates the three generations clearly: modern 12-word BIP39 seeds, legacy blockchain.info mnemonic phrases of 6–25+ words, and the wallet.aes.json v0/v2/v3 export formats.
• Corrected: Monero seed types are now explicit across the site — 25-word legacy, 16-word Polyseed, 13-word MyMonero.
• Corrected: "random 12+ characters = impossible" is reworded to an entropy-based framing (roughly 80+ bits of entropy) on the master list, FAQ and feasibility guide.
• Corrected: "proof of ownership" wording site-wide — a wallet address helps identify a case and verify results, but an address alone never proves ownership.
• Rewritten: the "should you pay a recovery service?" guide now separates three material levels — seed phrase/private keys (never share, under any contract), the full encrypted wallet file (sensitive, only under a written offline process), and the password-verification extract / hash line (designed to be shareable for cloud-GPU testing). Paying for GPU capacity is covered honestly; "restore from seed" is explicitly distinguished as wallet restoration, not password recovery.
• Reduced: "honest"-wording across the site — from 573 visible uses to a keep-list of "honest odds" and "honest limits" (26 remaining in English, 21 in Dutch). The tone now states facts directly instead of asserting honesty.
• Corrected: the About page now says technical claims are checked against primary sources, instead of claiming the site is "technically correct information".
• Reframed: the lost-crypto statistics page and homepage card now distinguish "lost Bitcoin" from "forgotten passwords" in title, meta and headline — there is no reliable global figure for forgotten passwords alone, and the page says so.
• Corrected: the "why online crackers can't work" page was too absolute — it claimed remote cracking was impossible while the extract/cloud-GPU route was described elsewhere. It now explains the consistent hierarchy: never your wallet file, never your seed; a password-verification extract (hash line) can legitimately leave you for remote compute. Title, meta, nav label and FAQ updated in both languages.
• Corrected: the recovery-service page's red flags and checklist no longer treat an extracted hash line as an automatic scam signal — they now match the three material levels (seed never, full file sensitive, extract suitable for cloud-GPU work).
• Corrected: the MetaMask guide now shows the mode per vault generation (26600 legacy, 26610 for newer dynamic-iteration vaults, 26620 in recent/development hashcat builds — not every stable release has it), instead of one command for everything.
• Corrected: the hashcat guide no longer claims it handles "every major wallet format" — it supports a wide range of common wallet-password formats.
• Corrected: the About page no longer calls the site "technically correct information" — it now states that technical claims aim to be based on primary sources and that corrections are documented.
• Corrected: "Most wallet passwords are recoverable" on the DIY page is now "Many" — the homepage's defensible framing, applied consistently.
• Corrected: homepage entropy claims now use "80+ bits of entropy" instead of "16 characters", and the changelog's own "last reviewed" date was set to 14 August.
• Corrected: Armory is no longer listed as IMPOSSIBLE in the master list — btcrecover documents an Armory password-recovery path (roughly 15k–200k candidates per 0.2–3 hours), so it is "crackable offline, very slow, clues essential"; the glossary and FAQ now say the same.
• Corrected: the KeePass table no longer maps Argon2 to hashcat mode 13400 — 13400 covers KeePass 1 and KeePass 2 with AES-KDF (KDBX ≤ 3); KDBX 4 (Argon2) is a different hash, so the page now says to identify the database version/KDF first.
• Corrected: the BIP39 passphrase guide no longer claims "no match = a passphrase was used" — a mismatch can also mean a different derivation path or wallet type, so the page now says to verify wallet type and derivation settings first. The "never stored anywhere" claim is softened to "not part of the mnemonic".
• Corrected: the Geth Windows path on the file-finder is now %LOCALAPPDATA%\Ethereum\keystore (per go-ethereum docs), not %APPDATA%.
• Corrected: the old-phone guide now says ADB backups "may work" — inclusion depends on the app's backup configuration (allowBackup/backup rules) and Android version — and that an encrypted iPhone backup may restore app data, but wallet secrets depend on how the app stores them (some keychain classes are device-bound).
• Corrected: the file-finder no longer calls MetaMask "a seed problem, not a file problem" — it is a browser-vault case: with the seed, restore; without it but with the encrypted vault, offline password recovery may be possible.
• Corrected: the FAQ no longer says a seed phrase recreates the wallet "on any device" — it can usually be restored in a compatible wallet that supports the same recovery standard and derivation scheme.
• Corrected: the Dutch FAQ JSON-LD was rebuilt from the visible Dutch FAQ items on 22 pages (English answers and an orphan English question removed) — question names and answers now match the visible content 1:1 in both languages.
• Corrected: the Bitcoin Core wallet.dat pages now reflect that 0.21 introduced SQLite-backed descriptor wallets as experimental — legacy BDB wallets remained common, and descriptor wallets only became the default for new wallets in Bitcoin Core 23.0.
• Corrected: the Electrum timeline years now match the releases — 2.0–2.7 (2015–early 2017) and 2.8+ (2017–present), since 2.8 shipped in March 2017.
• Corrected: the encryption table no longer summarizes Electrum 1.x–4.x as one scheme — it now splits legacy 1.x–2.7 (double-SHA-256 family, hashcat 16600 by salt type) from 2.8+ (ECIES/BIE1 keystore, PBKDF2-SHA512 + ECC, hashcat 21700/21800 by salt type).
• Corrected: the extraction guide no longer claims every *2john output works in both John and hashcat — Ethereum keystores are the explicit exception: ethereum2john.py converts the UTC JSON to the $ethereum$p*…/$ethereum$s*… line that both hashcat (15600/15700) and John consume.
• Corrected: the Monero guide now distinguishes "you still know the password" (opening the old wallet in a modern client may migrate it) from a forgotten password (not a workaround — preserve the files, treat pre-2017 binary wallets as a legacy-support problem).
• Corrected: the Electrum seed-restore bullet now notes that if old funds do not appear, check wallet type, seed type and Electrum's gap limit before assuming the seed or password is wrong.
• Corrected: the BIP38 guide no longer claims a printed public address proves ownership (it helps identify funds and verify results only), and it now advises an exact offline transcription of the 6P string instead of a cloud-synced photo — the BIP38 string contains everything needed to rebuild the private key except the passphrase.
• Corrected: the Blockchain.com guide now mentions the legacy exception that the wallet file may still be retrievable with the Wallet ID plus account/2FA checks (btcrecover's download-blockchain-wallet.py), hedged as an exception rather than a guarantee.
• Corrected: the Blockchain.com v0 row no longer says "a strong password is crackable in days" — it is extremely weak by wallet standards, so human-patterned passwords can be reachable, but a genuinely random strong password is still not realistically brute-forceable.
• Corrected: the Blockchain.com second-password explanation now says the path is not parallel — in many workflows you must first recover or know the main password before attacking the second-password hash.
• Corrected: MultiBit no longer claims btcrecover "reads all three variants directly" — the Classic .key backup is btcrecover's direct/data-extract path, the Classic .wallet uses hashcat 27700 or the John/multibit2john route, and HD uses a btcrecover extract/direct workflow with hashcat 22700 also applying (cheat sheet + guide + FAQ).
• Corrected: Bitcoin-family file locations now show both legacy %APPDATA% and current %LOCALAPPDATA% defaults, with wallets in the datadir's wallets/ folder or directly in the datadir on older/single-wallet setups (file finder, identifier and fork pages).
• Corrected: the "how long to crack" page no longer claims blind brute force over 10 full-alphabet characters takes "weeks" — at wallet.dat GPU rates that is on the order of a hundred million years, so it is already unrealistic for wallet formats; smart attacks only work when memory clues collapse the search space.
• Corrected: the btcrecover install guide now uses a virtual environment instead of suggesting --break-system-packages as a routine fix — that flag bypasses Python's protection for externally managed environments and is now only mentioned as a last resort in a disposable VM/container (with exact commands for macOS/Linux and Windows).
• Corrected: the encrypted-file page now lists the separate RAR modes — RAR3-hp 12500, RAR3-p compressed 23800, RAR3-p uncompressed 23700, RAR5 13000 — with the note that the right mode depends on what rar2john produces.
• Corrected: the Exodus guide now separates desktop from mobile — seed.seco and hashcat 28200 apply to Exodus Desktop; mobile's documented recovery path for a forgotten passcode/device unlock is the official 12-word phrase or passkey restore, not the same file attack.
• Corrected: the first-24-hours page no longer says "wallets wipe after repeated failures" broadly — that applies to hardware wallets and self-wiping devices; for wallet files, make a forensic copy and test offline against the copy.
• Corrected: the troubleshooting page now says to open only a duplicate copy in an isolated matching client version and keep the original untouched and backed up before any migration, repair or client launch.
• Corrected: the old-passwords page no longer claims a search resolves "more cases than all cracking tools combined" — it is now phrased as faster and safer in many real cases.
• Corrected: the lost-Bitcoin statistics page now notes that the High Court dismissed James Howells's claim in January 2025, effectively ending that legal route.
• Corrected: the Coinomi guide no longer says the 24-word phrase restores "on any BIP39 wallet" — it now says the wallet can usually be restored in Coinomi or another compatible BIP39 wallet, provided the same coin, account, passphrase setting and derivation path are supported.
• Corrected: the Ethereum keystore guide no longer claims "almost every Ethereum wallet" can produce or open a keystore JSON — it now names the tools that do (geth, MyEtherWallet, MyCrypto, some legacy wallets) and warns that modern wallets often use seed phrases, browser vaults or hardware-wallet flows instead.
• Corrected: the benchmark/calculator tables no longer present BIP39 and Electrum passphrases as "KDF + ECC" — they now read as PBKDF2-HMAC-SHA512 with the iteration count, and note that candidates are verified by deriving target addresses (BIP39) or keys (Electrum ECIES/BIE1).
• Corrected: the password-vs-seed-phrase page no longer lumps PIN and passphrase together as "solvable" — a forgotten PIN is usually bypassed by restoring on a new device, while a forgotten extra passphrase still has to be remembered or reconstructed (the seed alone may open a different wallet).
• Corrected: the annual restore-test on the never-lose-access page now separates software-wallet backups (test in an isolated/offline environment) from hardware-wallet backups (use the manufacturer's on-device recovery check or dry-run, or a spare/wiped compatible hardware wallet) — it explicitly warns not to enter a hardware-wallet seed into a software wallet on an ordinary computer merely to test the backup.
• Corrected: the 1Password table is no longer presented as "8200 = newer format" — it now lists 6600 (agilekeychain, legacy), 8200 (cloudkeychain, legacy/later) and 31800 (mobilekeychain, 1Password 8), and notes that modern accounts also use a Secret Key alongside the account password.
• Corrected: the Bitwarden entry no longer implies every modern data.json simply maps to hashcat mode 23400 — it now says to determine the account's KDF first, that mode 23400 and the standard bitwarden2hashcat workflow cover the format they were designed for, and not to assume an Argon2id-configured vault follows the same route.
• Corrected: the Ethereum keystore guide no longer presents 262,144 as a spec-mandated PBKDF2 default — keystore files are self-describing, geth commonly uses scrypt N=262,144, and for PBKDF2 the file's own c value applies (Web3 Secret Storage prescribes no universal count).
• Corrected: the John the Ripper guide no longer tells Debian/Ubuntu users to run "sudo apt install john" as the jumbo build — that package is the core build without wallet formats or *2john.py scripts; the guide now points to Openwall's official jumbo releases/source builds and verifies with "john --list=formats" and "ls run/*2john.py".
• Corrected: the John restore command is now "john --restore=wallet1" (Openwall's documented syntax), and the hashcat resume command is now "hashcat --session wallet1 --restore" instead of the invalid "hashcat --restore wallet1".
• Corrected: John the Ripper is no longer described as architecturally CPU-only — jumbo runs on CPUs and, for supported formats, can also use OpenCL/GPU acceleration; for many wallet workflows CPU remains the practical path.
• Corrected: the benchmark methodology no longer claims "three runs with the spread shown is a measurement" while publishing single values — it now advises repeating tests on your own hardware to estimate variance, and the page's "every number is a real run" claim now distinguishes tabulated measurements from labelled estimates (the MetaMask 90× figure is explicitly an extrapolation).
• Corrected: the hybrid-attack command on the cheat sheet now uses hashcat's documented argument order for -a 7 — mask first, then the dictionary (hashcat -m 11300 -a 7 wallet.hash '?u?l' words.txt).
• Corrected: Yoroi is no longer listed under the "same command for every one" btcrecover block — it now points to BTCRecover's dedicated --yoroi-master-password workflow after extracting the encrypted master-password value from the wallet data.
• Corrected: the "no wallet file" page now separates current Blockchain.com wallets (12-word Recovery Phrase) from legacy pre-2016 Blockchain.info wallets (recovery mnemonic with fewer or more than 12 words, which may reveal the wallet password from the time the phrase was created).
• Corrected: the encrypted-documents table now splits TrueCrypt (6211–6243 legacy / 29311–29343 current), VeraCrypt (13711–13783 legacy / 29411–29483 current) and LUKS (14600 legacy v1 / 29511–29543 newer) with their correct current extractors (truecrypt2hashcat.py / veracrypt2hashcat.py / luks2hashcat.py).
• Corrected: the custodial-reset table no longer claims self-custody 2FA is always "the same no-reset situation" — recovery depends on the wallet architecture, and some self-custody 2FA wallets such as Electrum 2FA can be restored from the wallet seed without the second factor.
• Corrected: the calculator page's password-space definition is now mathematically correct — character-set size raised to the password length (not length × character set).
• Corrected: the encryption page no longer claims "6 or fewer characters, even random, is usually crackable within days" — feasibility depends on the candidate space and the wallet's per-guess cost; memory-hard formats like BIP38 make even short random passwords expensive to exhaust.
• Corrected: the fork-wallet page now scopes its claims to Bitcoin Core-derived fork clients (Litecoin Core, Dogecoin Core, Core-codebase Bitcoin Cash node wallets, Dash Core) — non-Core wallets such as Electron Cash use different wallet formats.
• Corrected: the "Token length exception" entry no longer blames long wordlist candidates — the real cause is a hash line that does not match the token structure expected by the selected mode (wrong mode, malformed hash, truncation, extra fields, prefixes or separators).
• Corrected: the troubleshooting page no longer claims memory-hard modes are CPU-bound — they can be memory-limited and may perform better on CPU for some parameter sets, but hashcat can run parts of scrypt on the GPU; check mode/GPU support and device memory instead of dismissing 0 H/s.
• Corrected: the master list no longer says the "24-word phrase" is Yoroi's faster path — wallets created directly in Yoroi use a 15-word recovery phrase; Yoroi can also restore compatible 24-word Cardano wallets created elsewhere.
• Corrected: the identifier page now notes that traditional MetaMask wallets are SRP-based, while wallets created with Google, Apple or Telegram login use a different recovery model in which the password can also be required.
• Corrected: the MetaMask guide now states explicitly that you can copy or export the extension's vault data (the app does not need to be open or logged in) and use that copied data offline with metamask2hashcat.py or btcrecover's extract-metamask-vaults.py.
• Corrected: Keplr is no longer classified as universally supported by keplr2john.py — the legacy extension format is, while Keplr v2/current formats should not be assumed compatible until the vault format is identified (openwall/john issue #5481).
• Corrected: Dogechain.info is no longer lumped into the bitcoinj scrypt group with Litecoin/Dogecoin Android wallets — it is listed as its own workflow (wallet.aes.json / extract-dogechain-privkey.py).
• Corrected: the Bitcoin Wallet Android/BlackBerry entry no longer presents a fixed "4-digit PIN" — the numeric spending PIN is a small search space when its approximate length is known, and the length varies (btcrecover searches 1–6 digits).
• Corrected: the encrypted-file page no longer maps all .zip files to hashcat 13600 — WinZip AES is 13600, while PKZIP/ZipCrypto uses 17200/17210/17220/17225 depending on the extracted hash.
• Corrected: the glossary no longer presents Phantom as universally a 12-word seed-based wallet — traditional Phantom wallets use a 12-word recovery phrase, while Google/Apple account-based Phantom wallets with a PIN follow a different recovery model.
• Corrected: the password-vs-seed-phrase table no longer lumps BIP38 into the plain private-key row — a BIP38 string is a passphrase-protected private key (6P…) recoverable by testing candidate passphrases offline, now listed as its own row.
• Corrected: the protect-your-files rule no longer says "never enter your seed phrase into an app, ever" — it now distinguishes the official software-wallet restore flow from websites/chats/unknown tools, and says hardware-wallet seeds go only into the device itself or the manufacturer's approved on-device recovery flow.
• Corrected: the password-vs-seed-phrase page no longer presents "seed phrase = 12–24 words" as universal — BIP39 seeds are usually 12–24 words, but families such as Monero (25-word legacy / 16-word Polyseed) differ; the page now says to identify the wallet family before judging by word count.
• Corrected: the PIN/device-code row is split into hardware-wallet PIN/phone passcode (a local device lock, usually not a cracking case) and wallet-app spending PIN (app-level, may be recoverable for supported formats such as Bitcoin Wallet for Android/BlackBerry via btcrecover's numeric PIN search).
• Corrected: the btcrecover wildcard example no longer says %1,6a means "one to six letters" — it is one to six lowercase ASCII letters, with %ia noted for positions that could be lower- or uppercase; the wildcard legend now lists %a/%A/%ia correctly.
• Corrected: the wallet.dat FAQ no longer says "opens without asking for a password = never encrypted" — an encrypted Bitcoin Core wallet can load and display information while locked, with the passphrase required only for private-key operations; check the wallet's lock/encryption state instead. The same correction was applied to the troubleshooting entry that repeated the claim.
• Corrected: the password-vs-seed-phrase page no longer says legitimate password recovery "never needs your seed phrase" without exception — wallet-file recovery does not need it, but BIP39/SLIP39 extra-passphrase recovery tests candidates locally using the seed/mnemonic or required shares; those still never go into a website, form, email, chat or unknown tool.
• Corrected: the BIP39 passphrase benchmark no longer shows a GPU rate — GPU acceleration exists for BIP39 seed recovery, but not for passphrase recovery in the documented btcrecover workflow, so the CPU rate is the one to use (benchmarks table + calculator + calculator widget notes).
• Corrected: the calculator's GPU column now shows the real measured GPU rates for BIP38 (43/s, slower than CPU 72/s) and Electrum 2.8+ (4,300/s, slower than CPU 29,670/s) instead of copying the CPU rate into the GPU cell, with notes explaining the GPU path is slower for those formats.
• Corrected: the encrypted-file page no longer says modern LUKS2 has "no official mode — treat as unrecoverable" — current hashcat versions support some LUKS2 Argon2 configurations (e.g. mode 34100, argon2id + SHA-256 + AES), while other variants may still be unsupported or impractical; identify the exact KDF/hash/cipher parameters first.
• Corrected: the Electrum guide no longer says to restore a fork seed in "any fresh Electrum install" — restore in the matching Electrum-family wallet for that coin (Electrum for Bitcoin, Electron Cash for Bitcoin Cash, Electrum-LTC for Litecoin, etc.), and do not assume a fork seed belongs in ordinary Bitcoin Electrum.
• Corrected: the Blockchain.com guide no longer calls v3 "genuinely slow" while its own table shows v3 (5,450/s) faster than v2 (2,770/s) — it now says v0 is extremely fast, v2/v3 are much slower than v0 but still weak versus modern formats, and v3 is faster than v2 in the shown benchmark.
• Corrected: the MultiBit page now gives the official end-of-support date — both MultiBit Classic and MultiBit HD were discontinued, with support and maintenance ending on 26 July 2017 (previously listed as 2016 / "around 2017").
• Corrected: the central what-to-do decision tree no longer says "a wallet that opens without asking for a password was never encrypted" — an encrypted wallet can load and show public data while locked, so check the wallet's encryption/lock state instead (same correction as the wallet.dat FAQ).

13 August 2026

• New: live search and filter in the glossary — type a term and the matching definitions stay; the counter shows how many of the 30 terms match.
• New: KDF flow diagram on how wallet encryption works — password → key derivation → encryption key → encrypted file.
• New: candidate count and time estimate in the offline token list builder (per wallet format and hardware).
• New: "When you only remember part of it" section in the password hint list guide — the four partial-memory patterns with btcrecover and hashcat syntax.
• Expanded: FAQ from 11 to 15 questions, including "no wallet file?", "do I need a GPU?" and "is it legal?" — in English and Dutch.
• New pages: anti-scam guide (should you pay a recovery service?), the reported-services list, how scammers find you, when it is not a password problem, the offline recovery toolkit, and the offline file detector.
• Corrections: MetaMask speed claim aligned with the measured benchmarks; Monero KDF naming unified across guides and glossary; Office hashcat modes corrected on the encrypted-file page; the Blockchain.com "email reset" claim removed — the wallet password cannot be reset by the provider, only the account.
• Corrections (Dutch site): the Dutch FAQ, token builder and hint-list pages caught up with the English versions; the translation pipeline now regenerates the Dutch LLM export after translating, so the Dutch version can no longer ship the English intermediate state.
• Corrections (diagnosis quiz): answering "I don't know where the wallet file is" now stops the quiz immediately with the find-the-file verdict and a seed-phrase check — instead of continuing with questions that only matter once the file exists.

10 August 2026

• Full site audit: every page checked for structure, internal links, JSON-LD validity, search-index completeness and thin content.
• Rich schema strengthened site-wide: Organization, Person, WebSite, speakable answer boxes and FAQPage schema on every matching page.
• Mobile tables restacked with column labels so every table reads top-to-bottom on a phone; navigation rebuilt (light theme, clean dropdowns, works on all breakpoints); dark mode added.
• Core Web Vitals: layout shift reduced to zero via a font-loading fix; reading-progress bar and print stylesheet added so guides print cleanly.
• New walkthroughs and guides: btcrecover, hashcat and John the Ripper step-by-step pages, the per-wallet guides (Monero, MetaMask, old phones), and the "no wallet file" answer.

6–9 August 2026

• Site launched: the diagnosis quiz, the nine-step recovery path, per-wallet guides, the master list of wallets, benchmarks, calculators and the offline-first tool set.
• All "last reviewed" dates are shown per page; technical claims carry sources from official repositories and documentation.

Subscribe to updates via Atom feed — or bookmark this page; corrections are logged the same way as additions.

This page lists user-visible changes. The full verification log (every correction and why) lives in the project documentation; contact us if you spot anything that should be here.