45 min read

> Where you are: Part V, Chapter 33 of 40. Chapter 32 taught you to analyze malware after an incident — including the ransomware that increasingly ends with a demand for payment "in Bitcoin to the address below." This chapter follows that money. It...

In This Chapter

Exercises Quiz Case Study 01 Case Study 02 Key Takeaways Further Reading

Chapter 33: Cryptocurrency Investigation — Tracing Bitcoin, Ethereum, and Digital Assets on the Blockchain

Where you are: Part V, Chapter 33 of 40. Chapter 32 taught you to analyze malware after an incident — including the ransomware that increasingly ends with a demand for payment "in Bitcoin to the address below." This chapter follows that money. It is also where the book's foundations come full circle: a blockchain is the strangest evidence source you will ever meet, because it is public, permanent, and global, yet built on addresses that belong to no name. This is the home chapter for the financial-tracing thread of anchor case #3 (the ransomware recovery), and it touches anchor case #4 (the court case) strictly clinically — financial tracing is one of the most powerful tools for identifying offenders and rescuing victims, and we will treat that capability as procedure and ethics only.

Learning paths: This chapter belongs first to the 🔍 Forensic Examiner and 🛡️ Incident Response analyst — ransomware, fraud, business email compromise, and theft now run on rails of crypto, and tracing is a core DFIR skill. 📜 Legal/eDiscovery practitioners need the exchange-subpoena, KYC/AML, sanctions, and seizure material, because the trail almost always ends at a legal process served on an exchange. 💾 Data Recovery technicians have a real stake too: "I forgot my wallet password and there is $80,000 of Bitcoin behind it" is a recovery job, and wallet-file recovery is the dual-purpose artifact at the center of this chapter.

The ledger that never forgets

Imagine an accounting ledger with three properties that no paper ledger and no bank database has ever combined. First, it is public: anyone, anywhere, can download the entire thing and read every entry ever made. Second, it is permanent: entries are append-only, cryptographically chained, and replicated across tens of thousands of independent computers, so no entry can be quietly altered or deleted after the fact. Third, it is pseudonymous: the entries name accounts — long strings of characters called addresses — but never people. That ledger is a blockchain, and it inverts almost everything else in this book.

Throughout these chapters the first recurring theme has been deleted ≠ destroyed — deletion removes a pointer, but the data persists until overwritten. On a blockchain there is no deletion to undo, because there is no deletion at all. Nothing is ever overwritten. The transaction Laszlo Hanyecz made in May 2010 — paying 10,000 BTC for two pizzas — is still right there in block 57,043, exactly as it was, and it will be there as long as the network exists. For an investigator this is extraordinary: the financial record you most want is not in a bank's archive that might be purged, not on a drive that might be wiped, but in a public database that physically cannot forget. The hard problem is never "is the transaction still there." The hard problem is "who is bc1qf7v9d2k5s3n8…?"

That is the work of cryptocurrency investigation, and it is the bridge from the previous chapter. In Chapter 32 — Malware Forensics you reverse-engineered a ransomware sample and pulled, among its configuration, the Bitcoin address hard-coded into its ransom note. On its own that address is a meaningless string. By the end of this chapter you will know how to turn it into a cluster of related addresses, follow the funds through the laundering that follows almost every ransom, find the exchange where the criminal tried to cash out, and serve the legal process that converts a pseudonym into a name on a know-your-customer file.

Pseudonymous, not anonymous

This distinction is the single most important idea in the chapter, and the public misunderstands it constantly. Bitcoin is frequently called "anonymous money." It is not. It is pseudonymous: your identity is replaced by a pseudonym (an address), but every action that pseudonym takes is recorded forever in a graph that everyone can analyze. Anonymity means your actions cannot be linked to each other or to you. Pseudonymity means your actions are all linked to each other — to the pseudonym — and the entire edifice of blockchain forensics is the science of linking the pseudonym to you.

The asymmetry favors the investigator more than the criminal expects. A bank protects your transaction history behind law, contract, and access control; subpoena it and you get your records. A blockchain protects nothing behind anything; the history is already public, for every address, forever. The criminal's only protection is the gap between the address and the name — and that gap is bridged the moment funds touch a regulated exchange, a merchant, an identified counterparty, or a seized device. One link is often enough, because once a single address is tied to a person, clustering radiates that identity across every address the person controls.

Why This Matters. Most violent and acquisitive crime now has a financial dimension that runs through crypto: ransomware, business email compromise, romance and investment scams that drain retirees' life savings, sanctions evasion, darknet markets, and the financing of exploitation. The blockchain is, for the investigator, the most complete and most permanent financial evidence ever created — and unlike a wiretap or a bank's cooperation, it requires no one's permission to read. Theme four of this book is technology changes, principles don't: coins, tokens, and chains proliferate endlessly, but the method is constant — understand the technology, follow the money to where it touches the regulated world, get the legal process, and document every step.

A blockchain in one diagram

Strip away the jargon and a blockchain is a chain of blocks, each block a batch of transactions, each transaction a movement of value between addresses. For Bitcoin:

BITCOIN: BLOCKS → TRANSACTIONS → INPUTS/OUTPUTS
┌─ block 812,042 ─┐   ┌─ block 812,043 ─┐   ┌─ block 812,044 ─┐
│ prev: 0000…a91c │◄──│ prev: 0000…7d30 │◄──│ prev: 0000…4e8b │   each block points
│ merkle root     │   │ merkle root     │   │ merkle root     │   BACK to the prior
│ time, nonce     │   │ time, nonce     │   │ time, nonce     │   block's hash →
│ ── txns ──      │   │ ── txns ──      │   │ ── txns ──      │   tamper-evident chain
│  tx, tx, tx …   │   │  tx, TX*, tx …  │   │  tx, tx, tx …   │   (~10 min/block)
└─────────────────┘   └────────┬────────┘   └─────────────────┘
                               ▼
                       TX*  (one transaction)
                       INPUTS  ── consume previous outputs (must be signed)
                       OUTPUTS ── create new spendable outputs to addresses

A new block is mined roughly every ten minutes on Bitcoin (about every twelve seconds on Ethereum), and each block's header contains the cryptographic hash of the previous block. Change one byte of one old transaction and every subsequent block hash changes, which the network instantly rejects — that is what "immutable" means in practice. The deep mechanics of consensus, Merkle trees, the secp256k1 elliptic curve, and ECDSA signatures belong to the DataField series' companion volume on blockchain technology; here we need only the forensic surface: blocks contain transactions, transactions move value between addresses, and all of it is public and permanent.

How Bitcoin actually records value: UTXOs, addresses, and transactions

To trace funds you must understand how Bitcoin represents them, because it is not how a bank account works. There is no "balance" stored anywhere for an address. Instead, Bitcoin tracks unspent transaction outputs — UTXOs — and your "balance" is simply the sum of all UTXOs your keys can spend. This model shapes every tracing heuristic in the chapter, so internalize it before you trace.

Addresses are not identities

A Bitcoin address is a fingerprint of a public key, encoded for humans. The lineage runs: a private key (a 256-bit secret) generates a public key on the secp256k1 curve; the public key is hashed with SHA-256 and then RIPEMD-160 (together called HASH160, producing 20 bytes); those 20 bytes are wrapped with a version byte and a checksum and encoded for display. The encoding determines the address's leading characters, and recognizing the format on sight is a basic field skill:

BITCOIN ADDRESS FORMATS (mainnet)
1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa   P2PKH  (legacy)   Base58Check, version 0x00 → starts "1"
3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy   P2SH               Base58Check, version 0x05 → starts "3"
bc1qar0srrr7xfkvy5l643lydnw9re59gtzz…  P2WPKH (SegWit)  Bech32,   "bc" + "1" + data → starts "bc1q"
bc1p5cyxnuxmeuwuvkwfem96l…             P2TR  (Taproot)  Bech32m,            … → starts "bc1p"

Two practical points fall out of this. First, Base58 deliberately omits the characters 0 (zero), O (capital o), I (capital i), and l (lower L) to prevent transcription errors — so a "Bitcoin address" containing a zero or a capital O is malformed, a useful sanity check when a witness hands you a hand-copied string. Bech32 uses its own restricted character set and a strong error-detecting code, which is why a bech32 address can often be repaired from a near-miss. Second, and crucial for tracing: a single person routinely controls thousands of addresses. Modern wallets are hierarchical-deterministic (HD) — from one secret seed they derive an effectively unlimited tree of addresses (more on this under wallet forensics), generating a fresh one for every receipt and every change output. The naive idea that one person equals one address is wrong by orders of magnitude, and clustering exists precisely to collapse that explosion back down to entities.

The UTXO model and the anatomy of a transaction

A Bitcoin transaction consumes one or more existing UTXOs as inputs and creates one or more new UTXOs as outputs. To spend an input you must provide a signature proving you hold the private key for the address that received it. The sum of input values must be at least the sum of output values; the difference is the miner fee. Amounts are denominated in satoshis, where 1 BTC = 100,000,000 satoshis (10⁸) — always reason in satoshis when the arithmetic matters, because floating-point BTC will betray you.

A transaction is identified by its TXID, the double-SHA-256 hash of its serialized bytes, displayed as 64 hexadecimal characters. Here is how one reads in a block explorer:

TRANSACTION  4b8e7c2af19d0653a1f8c4e90b7d2a3f6e5c8b1029d4a7f63e0c5b8a1d2f3049
mined:  block 812,043   2024-09-18 14:22 UTC   confirmations: 6,400
size:   223 vbytes      fee: 6,000 sat (≈ 26.9 sat/vByte)

INPUTS (1)
  #0   bc1qf7v9d2k5s3n8…q2wd     0.82000000 BTC     (spends 9a1c…:1)

OUTPUTS (2)
  #0 → bc1q3kd9w5x7sla…7m6n      0.75000000 BTC     ◄ payment
  #1 → bc1qm4t2v8h9wzr…0p3e      0.06994000 BTC     ◄ likely change (fresh, non-round)

  inputs 0.82000000 − outputs 0.81994000 = 0.00006000 BTC miner fee

Read it as money. Someone holding a UTXO worth 0.82 BTC paid 0.75 BTC to one address and sent 0.06994 BTC to another, burning 0.00006 BTC in fees. Which output is the payment and which is the change returning to the sender? Answering that question, billions of times, is the engine of transaction tracing — and the next section is built on it.

Tool Tip. You do not need a commercial platform to start. Free, public block explorers — blockchair.com, mempool.space, blockstream.info, and for clustering history the venerable walletexplorer.com — let you paste any address or TXID and read its complete history, inputs, outputs, and links. For Ethereum, Etherscan is indispensable. Every illustrative output in this chapter is the kind of thing these tools show you for free; the commercial suites add scale and attribution, not visibility. The full tool landscape is catalogued in Appendix C — Tool Reference.

Chain of Custody. The blockchain is evidence, and you must preserve which view of it you relied on. You do not "seize" a public ledger, but you do record, for every on-chain fact in your report, the TXID, the block height and time, the address(es), and the source and timestamp of your query. Best practice for consequential cases is to run your own full node so your evidence does not depend on a third party's website that could change or disappear, and to export and hash your findings (a CSV of the relevant transactions plus its SHA-256). "Confirmed against a self-hosted Bitcoin Core full node at block height 812,400 on 2024-09-20; export trace-acme.csv SHA-256 e3a1…" is a sentence that survives cross-examination. The acquisition and hashing discipline is the same one from Chapter 14 — Forensic Acquisition; only the evidence medium has changed.

Address clustering: turning addresses into entities

A raw blockchain is a graph of pseudonyms. Clustering is the process of grouping addresses that are controlled by the same entity, collapsing thousands of pseudonyms into one actor you can reason about. Two heuristics do most of the work, and you must understand both their power and their failure modes — because in court you will be asked to defend each grouping you assert.

The common-input-ownership heuristic

This is the foundation, and it follows directly from the UTXO model. To spend a transaction's inputs you must sign each one with the private key that controls it. Therefore, when a transaction has multiple inputs, the same entity almost always controls all of them — because only that entity holds all the necessary keys. This is the common-input-ownership heuristic, also called the multi-input or co-spend heuristic, and it was formalized in the field-defining 2013 study by Meiklejohn and colleagues, A Fistful of Bitcoins.

COMMON-INPUT-OWNERSHIP HEURISTIC
  inputs                         outputs
  addr_A ─┐
  addr_B ─┼──►  one transaction  ──►  addr_X (payment)
  addr_C ─┘                           addr_Y (change)
   ▲▲▲
   all three inputs had to be signed by the SAME keyholder
   ⇒ addr_A, addr_B, addr_C are clustered as ONE entity

Apply it transitively across the whole chain and clusters grow rapidly: if A and B co-spend here, and B and D co-spend there, then A, B, and D are one entity. Exchanges, which constantly consolidate thousands of customer deposits, end up as enormous clusters — which is exactly what lets a commercial tool label an address "Binance hot wallet" or "Coinbase deposit cluster." The heuristic is strong, but it has a deliberate nemesis: CoinJoin, a privacy technique in which many unrelated users co-sign one transaction precisely so that co-spending no longer implies common ownership. A naive application of the heuristic to a CoinJoin produces a false cluster, merging strangers. Recognizing CoinJoin structure (many equal-valued inputs and outputs, characteristic of Wasabi or Samourai/Whirlpool) is therefore essential, and we return to it under tracing and limitations.

Change detection

The second heuristic identifies which output of a transaction is the change returning to the sender, so the cluster can be extended forward through time. In the UTXO model, when you spend a 0.82 BTC input to pay 0.75 BTC, the leftover 0.06994 BTC must go somewhere — to a change address you control. Identify that change output and you have found another address in the sender's cluster. A bundle of signals points to the change:

  • The fresh-address signal. A modern HD wallet derives a brand-new, never-before-seen address for change. An output paying an address with no prior history, while the other output pays an address that has been used before, suggests the new one is change.
  • The round-number signal. Humans pay round amounts (0.75 BTC); wallets compute change to the satoshi (0.06994000 BTC). The non-round, "odd" output is often the change.
  • The address-type signal. Wallets typically generate change of the same script type they spend. If the inputs are bech32 (bc1q…) and one output is bech32 while the other is legacy (1…), the matching-type output is more likely change.
  • The behavioral signal. The output that is re-spent together with other addresses you already attribute to the entity confirms itself retroactively via the common-input heuristic.
CHANGE DETECTION (which output returns to the sender?)
  input: 0.82 BTC  (bech32, from cluster A)
     ├─► OUTPUT #0  0.75000000 BTC  → reused legacy addr  ── looks like the PAYMENT
     └─► OUTPUT #1  0.06994000 BTC  → fresh bech32 addr   ── looks like CHANGE → add to cluster A
                    ^non-round       ^never seen before    ^same type as input

No single signal is decisive; you weigh them together, and you state your reasoning. Change detection is more error-prone than the common-input heuristic — a wrong change attribution sends your trace down a stranger's address tree — which is why careful examiners corroborate it and why commercial clustering engines blend dozens of signals and continuously correct themselves as the chain grows.

Recovery vs. Forensics. Clustering is usually framed as a forensic offense, but it has a quieter, benevolent use. A 💾 recovery-minded professional helping a client account for scattered self-custodied funds can use the same common-input and change heuristics to reconstruct the client's own wallet history — discovering forgotten change addresses, mapping which of a dozen wallet apps produced which outputs, and assembling a complete picture of holdings for estate settlement or tax reconstruction. The 🔍 examiner clusters a suspect's addresses to prove control of criminal proceeds; the recovery professional clusters a client's addresses to prove ownership of their own assets. Same graph mathematics; one purpose is attribution against someone, the other is restoration for someone.

Transaction tracing: following the money

With clustering to define entities, tracing follows value as it moves between them. In a simple case this is trivial — funds hop from address to address and you read them off the explorer. Criminals know this, so real traces run through deliberate obfuscation. Your job is to follow the money far enough to reach a point where pseudonymity breaks, and to recognize honestly when the trail has gone cold.

Peeling chains and the shape of laundering

A signature laundering pattern is the peeling chain. A large sum sits at one address; the launderer sends a small "peel" to a cash-out destination (often an exchange deposit address) and the large remainder to a fresh change address, then repeats — peeling off small amounts again and again down a long chain. The pattern is visually distinctive and, ironically, easy to follow precisely because the change heuristic stitches the chain together:

PEELING CHAIN
big pot ──►●──► change ──►●──► change ──►●──► change ──►●──►  …  (dozens–hundreds of hops)
          │peel          │peel          │peel          │peel
          ▼              ▼              ▼              ▼
       exchange       exchange       another        mixer
       deposit        deposit        wallet        deposit
   (small cash-out)  (small cash-out)              (obfuscation)

The peels are small to stay under exchange reporting thresholds and to look like ordinary activity; the chain is long to exhaust an investigator's patience. Automated tracing tools collapse the tedium, but the conceptual move is simple: keep following the change, and watch where the peels land.

Mixers, tumblers, and CoinJoin

A mixer (or tumbler) pools coins from many users and pays out from the pool, severing the direct link between deposit and withdrawal. Centralized custodial mixers (historical examples include Helix, Bitcoin Fog, and ChipMixer, all the subject of major law-enforcement actions) take custody of your coins and return "clean" ones; CoinJoin implementations (Wasabi, Samourai/Whirlpool) are non-custodial, combining many users into single transactions with uniform output sizes so no input maps to a particular output. On Ethereum, Tornado Cash used zero-knowledge proofs to break the link between deposit and withdrawal; it was sanctioned by the U.S. Treasury's OFAC in August 2022, a designation later narrowed by federal litigation over whether immutable, ownerless smart-contract code can be "property" subject to sanctions — a reminder that the law here is young and moving.

Mixers are powerful but not magic. Their use is itself a loud signal (theme three: every action leaves a trace) — a transfer into a known mixer cluster is a flashing indicator of intent to obscure, and commercial tools flag it instantly. Custodial mixers kept records that were later seized. CoinJoins can sometimes be partially de-mixed when users are careless (consolidating mixed and unmixed coins, withdrawing recognizable amounts, or timing patterns). And the funds must still leave the mixer eventually, usually toward an exchange, where the trail can pick back up. The honest truth is that a well-used mixer can genuinely break a trace — that belongs in this chapter's Limitations — but it raises, not lowers, the suspicion attached to the funds.

Chain-hopping

Where a mixer obscures within one chain, chain-hopping moves value between chains to break continuity: BTC swapped to Monero, then to Ether, then to a stablecoin, via exchanges or instant-swap services (ShapeShift historically, and a long tail of "no-KYC" swappers). Each hop is a discontinuity in the on-chain graph — the Bitcoin trail simply ends at a swap service's deposit address, and a separate, seemingly unrelated trail begins on another chain. Following a chain-hop requires either the swap service's records (legal process) or the analytic correlation that commercial tools perform across chains (matching amounts and timing across the deposit on chain A and the withdrawal on chain B). When the intermediate hop is a privacy coin like Monero, chain-hopping is the hardest problem in the chapter, for reasons we cover below.

The choke points: on-ramps and off-ramps

Here is the strategic insight that organizes every trace. Crypto is pseudonymous in the middle, but value must enter from and exit to the regulated financial world, and those boundaries are choke points where pseudonymity collapses:

        FIAT  ── on-ramp ──►  [  CRYPTO: pseudonymous, fully traceable graph  ]  ── off-ramp ──►  FIAT
     (bank, card, cash)            addresses · mixers · chain-hops · DeFi              (bank, card, cash)
            │                                                                                  │
      KYC CHOKE POINT                                                                    KYC CHOKE POINT
   exchange holds the buyer's                                                       exchange holds the casher's
   ID, bank link, IP, device                                                        ID, bank acct, withdrawal
            └────────────────── this is where the pseudonym becomes a NAME ──────────────────┘

You do not have to de-anonymize every hop in the middle. You have to follow the funds to a choke point — an exchange, a payment processor, a regulated custodian — and then let the law do what cryptography cannot. The entire art of practical tracing is getting the funds to a chokepoint and identifying which one. That is why the next section is not about cryptography at all. It is about subpoenas.

Exchange cooperation: where pseudonymity meets KYC

When a trace reaches an exchange deposit address, the on-chain investigation hands off to the legal one. Regulated exchanges are, under U.S. law, money services businesses (MSBs) registered with FinCEN and subject to the Bank Secrecy Act. They are required to perform Know Your Customer (KYC) identity verification at account opening, run Anti-Money-Laundering (AML) monitoring, file Suspicious Activity Reports (SARs) and Currency Transaction Reports (CTRs), and, under the Travel Rule (FinCEN's threshold of $3,000; FATF Recommendation 16 sets $1,000 for virtual-asset transfers internationally), pass originator and beneficiary information alongside transfers between regulated providers. The upshot for you: a regulated exchange that received your traced funds knows who controls the receiving account — name, government ID, bank account, IP and device history, and the full internal ledger of deposits and withdrawals.

Obtaining that data is a legal act, not a technical one. Depending on jurisdiction and posture it is a grand-jury subpoena, a court order, a search warrant, or — when the exchange is overseas — a request through a Mutual Legal Assistance Treaty (MLAT) or comparable channel. The substantive law of compelled production, the constitutional limits, and the cross-border mechanics are the domain of Chapter 25 — The Legal Framework; the templates live in Appendix E — Legal Frameworks Reference. What you contribute as the technical examiner is the precise predicate: the specific deposit addresses, TXIDs, dates, and amounts that let the exchange identify the exact account, and the explanation of why your trace ties those deposits to the offense.

Legal Note. A blockchain address by itself supports no demand on anyone — it is public data. Authority attaches at the chokepoint, against a specific provider, for specific account records tied to specific transactions, under a specific legal instrument. Two failure modes end cases here. First, scope: a subpoena for "all records of any account associated with this address" may be quashed as overbroad; "the account(s) that received deposits via TXIDs X, Y, Z on these dates" is enforceable. Second, jurisdiction: an exchange incorporated abroad may not answer U.S. process at all, requiring an MLAT that can take months. Identify the exchange's jurisdiction early — it determines whether your trace is hours or quarters from a name.

Tool Tip. Sanctions screening is part of the workflow. OFAC publishes specific crypto addresses on its SDN (Specially Designated Nationals) list; a trace that touches a sanctioned address (a designated mixer, a sanctioned exchange, a terrorist-financing wallet) changes the legal landscape and the urgency. Commercial tools screen against these lists automatically; if you work cases by hand, check the published SDN crypto entries before you conclude.

Wallet forensics: finding the keys and the artifacts

On-chain analysis tells you what addresses did. Wallet forensics is what you do with the device in front of you — the suspect's laptop, the seized phone, the dead client's hard drive — to recover the keys, the addresses, the transaction history, and the human context. This is where cryptocurrency investigation rejoins the rest of the book, because a wallet is just a set of files and artifacts in the file systems and registries you already know from Part III, and the principles of imaging, hashing, and working on a copy apply without exception.

A foundational clarification first: whoever controls the private keys controls the coins. A wallet does not "contain" Bitcoin — the coins are UTXOs on the public ledger. A wallet contains the keys that authorize spending those UTXOs. So the prize of wallet forensics is keys (or the seed that derives them), and the secondary prize is the metadata — addresses, labels, and history — which lets you trace and attribute even when the keys themselves are locked away.

wallet.dat (Bitcoin Core)

The classic artifact is wallet.dat, the wallet file of the original Bitcoin Core client. Legacy versions store it as a Berkeley DB file; recent Core versions default to descriptor wallets in SQLite. You will meet both. The on-disk locations:

Bitcoin Core wallet locations
  Windows : C:\Users\<user>\AppData\Roaming\Bitcoin\wallet.dat      (or \wallets\<name>\)
  macOS   : ~/Library/Application Support/Bitcoin/wallet.dat
  Linux   : ~/.bitcoin/wallet.dat

Identify the file by its header. A legacy Berkeley DB B-tree wallet carries the BDB magic number 0x00053162 at offset 12, little-endian on a typical x86 system:

LEGACY wallet.dat (Berkeley DB, B-tree)
Offset    00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F   notes
00000000  00 00 00 00 00 00 00 00  00 00 00 00 62 31 05 00   BDB magic 0x00053162 @0x0C (LE)
00000010  09 00 00 00 00 10 00 00  ...                       DB version 9, pagesize 0x1000=4096

A newer descriptor wallet is SQLite:
00000000  53 51 4C 69 74 65 20 66  6F 72 6D 61 74 20 33 00   "SQLite format 3\0"

Inside a legacy wallet.dat, key records use named entries — key and keymeta for unencrypted private keys, ckey for encrypted private keys, mkey for the encrypted master key, name and purpose for address labels, and tx for cached transaction records. The presence of mkey/ckey strings tells you the wallet is passphrase-encrypted: Bitcoin Core encrypts the private keys with AES-256-CBC under a key stretched from the user's passphrase via many SHA-512 rounds (the iteration count is stored in the wallet and was tuned to roughly 0.1 seconds on the machine that created it). That structure is exactly what password-recovery tooling targets, below.

Seed phrases and HD wallets (BIP32/39/44)

Most modern wallets are hierarchical-deterministic: a single random secret (the seed) deterministically generates an entire tree of keys and addresses. The standards you must know by number:

  • BIP32 defines the HD tree — one master key spawns a hierarchy of child keys.
  • BIP39 encodes the seed's entropy as a human-friendly mnemonic phrase: 12 or 24 words drawn from a fixed 2,048-word list (128 bits of entropy plus a 4-bit checksum for 12 words; 256 bits plus an 8-bit checksum for 24). The last word encodes a checksum, so not every random word sequence is valid.
  • BIP44 standardizes the derivation path, e.g., m/44'/0'/0'/0/0 for the first Bitcoin account's first receiving address (coin_type 0 = Bitcoin, 60 = Ethereum).

The forensic consequence is enormous and bears repeating in bold: the seed phrase IS the wallet. Twelve or twenty-four ordinary English words, written on a sticky note, photographed "for safekeeping," pasted into a Notes app, emailed to oneself, or stored in a password manager, are complete control of every coin the wallet will ever hold, across every derived address, on every chain that wallet supports. Recovering a seed phrase from a device is the single most decisive outcome in cryptocurrency forensics — and because people store these words so carelessly, it happens often. You search for them in plaintext, in document and notes-app stores, in browser-saved data, in photographs (run them through OCR), and in unallocated space and slack, where a deleted note or screenshot may survive (theme one: deleted ≠ destroyed).

# Illustrative: detect a possible BIP39 seed phrase in extracted text.
# 12 or 24 consecutive words, ALL from the 2,048-word list, is almost never an
# accident. A single hit in a notes export, a chat log, or carved unallocated
# space can be the entire case: the seed is the wallet.
import re

WORDLIST = set(open("english.txt", encoding="utf-8").read().split())  # the 2048 BIP39 words

def find_seed_phrases(text: str):
    words = re.findall(r"[a-z]+", text.lower())
    for n in (24, 12):                                  # check 24-word, then 12-word windows
        for i in range(len(words) - n + 1):
            window = words[i:i + n]
            if all(w in WORDLIST for w in window):
                yield n, " ".join(window)               # validate the checksum before relying on it

You can scan a whole image for addresses the same way, treating every hit as a lead to validate, never a finding on its own:

# Illustrative carving aid: find likely crypto addresses in an EXTRACTED copy.
# These regexes over-match (random Base58 strings exist); validate checksums and
# corroborate before reporting. Never run against the original evidence.
import re
PATTERNS = {
    "btc_legacy": re.compile(r"\b[13][1-9A-HJ-NP-Za-km-z]{25,34}\b"),   # Base58: no 0 O I l
    "btc_bech32": re.compile(r"\bbc1[02-9ac-hj-np-z]{8,87}\b"),          # bech32 charset (no 1 b i o)
    "eth":        re.compile(r"\b0x[a-fA-F0-9]{40}\b"),
    "xmr":        re.compile(r"\b[48][0-9A-Za-z]{94}\b"),                # Monero standard/subaddress
}
def scan(buf: bytes):
    text = buf.decode("latin-1", errors="ignore")
    for kind, rx in PATTERNS.items():
        for m in rx.finditer(text):
            yield kind, m.group(0), m.start()

Browser and app wallets: MetaMask, Electrum, Exodus

Beyond Bitcoin Core, the wallets you will actually encounter on suspects' machines are lighter clients and browser extensions, each with its own artifact:

WALLET ARTIFACT LOCATIONS (Windows; see Appendix D for macOS/Linux)
Electrum   %APPDATA%\Electrum\wallets\<name>        seed/keys, encrypted if a password is set
Exodus     %APPDATA%\Exodus\exodus.wallet\          seed.seco (encrypted), passphrase-protected
Bitcoin Core %APPDATA%\Bitcoin\wallet.dat            BDB or SQLite (above)
MetaMask   %LOCALAPPDATA%\Google\Chrome\User Data\Default\Local Extension Settings\
             nkbihfbeogaeaoehlefnkodbefgpgknn\       LevelDB (*.ldb,*.log) — encrypted "vault"
Ledger Live %APPDATA%\Ledger Live\                    accounts/xpubs + history — NO private keys

MetaMask deserves special attention because it is everywhere. The extension stores an encrypted vault — a JSON blob {"data":…,"iv":…,"salt":…} (AES-GCM, key derived via PBKDF2-SHA-256) — inside its LevelDB store under the well-known extension ID nkbihfbeogaeaoehlefnkodbefgpgknn. Extract the vault from the .ldb/.log files and you have a self-contained target for lawful password recovery; the seed phrase it protects unlocks the user's Ethereum and EVM-chain assets. The browser-artifact handling that makes this possible — profiles, extension storage, LevelDB — is the subject of Chapter 18 — Browser and Internet Forensics.

A PowerShell triage sweep over a mounted, read-only Windows image collects these in one pass:

# Triage a mounted READ-ONLY Windows image (here drive F:) for wallet artifacts.
$root = 'F:\Users'

# Known wallet files
Get-ChildItem -Path $root -Recurse -File -ErrorAction SilentlyContinue -Include `
  'wallet.dat','default_wallet','seed.seco' |
  Select-Object FullName, Length, LastWriteTimeUtc

# Wallet application data folders
'AppData\Roaming\Bitcoin','AppData\Roaming\Electrum\wallets',
'AppData\Roaming\Exodus','AppData\Roaming\Ledger Live' | ForEach-Object {
  Get-ChildItem -Path (Join-Path $root "*\$_") -ErrorAction SilentlyContinue
}

# MetaMask vault (Chrome): LevelDB under the fixed extension ID
$mm = 'AppData\Local\Google\Chrome\User Data\Default\Local Extension Settings\' +
      'nkbihfbeogaeaoehlefnkodbefgpgknn'
Get-ChildItem -Path (Join-Path $root "*\$mm") -Include *.ldb,*.log -Recurse -ErrorAction SilentlyContinue

Hardware wallets: Ledger, Trezor, and the limits of the device

A hardware wallet (Ledger, Trezor, KeepKey) keeps the private keys inside a dedicated device — often a secure element — and signs transactions internally so the keys never reach the connected computer. For the examiner this is mostly a wall: you generally cannot extract keys from the device itself, especially Ledger's secure-element models, and the device enforces a PIN with a strict retry limit and a wipe-on-failure policy (older Trezors imposed escalating delays; Ledger wipes after three wrong PINs). Brute-forcing the PIN on the device is a non-starter, and trying it can destroy the evidence — the strongest possible expression of theme two, the original is sacred: with a hardware wallet you may get only one careful pass.

But the device is not the only artifact. The companion application on the paired computer or phone — Ledger Live, Trezor Suite — stores the wallet's extended public keys (xpubs), account names, address labels, and a full local copy of the transaction history. With the xpub you can derive and monitor every address the wallet uses, watch-only, without ever holding a private key — which means you can trace and attribute the suspect's entire on-chain activity from the companion-app data even when the device stays locked. The physical presence of a hardware wallet (and its recovery sheet, if seized) is itself powerful evidence of significant self-custodied holdings, and the recovery sheet — those 24 words — is, once again, the whole wallet.

Recovery vs. Forensics. The encrypted wallet file is the book's signature dual-purpose artifact, and password recovery is the technique that serves both disciplines with the same command. A 💾 recovery engagement: a client who genuinely owns the wallet has forgotten the passphrase to their wallet.dat or MetaMask vault, with a life-changing sum behind it; you crack their own wallet to restore their access. A 🔍 forensic seizure: under a warrant, you crack a suspect's wallet to access and seize criminal proceeds. The artifact is identical, the tooling is identical (hashcat -m 11300 for wallet.dat), and the only difference is authority — consent of the true owner, or a court's order. That is the entire ethical and legal weight of this work, riding on one piece of paper.

# LAWFUL wallet access ONLY: (a) a seizure authorized by warrant, or (b) helping
# the verified legitimate owner recover THEIR OWN funds. Work on a COPY extracted
# from the verified image — never the original wallet file or device.

sha256sum ./work/wallet.dat >> chain-of-custody.txt      # hash the working copy first

file   ./work/wallet.dat                                  # "Berkeley DB (Btree…)" or "SQLite 3.x"
strings ./work/wallet.dat | grep -E "mkey|ckey"          # mkey/ckey ⇒ the wallet is encrypted

# Extract the crackable hash (John the Ripper "jumbo" ships bitcoin2john.py):
python3 bitcoin2john.py ./work/wallet.dat > wallet.hash
#   → $bitcoin$… (encrypted master key + salt + iteration count)

# Attack with hashcat: -m 11300 = Bitcoin/Litecoin wallet.dat.
# A TARGETED wordlist from the custodian's OWN artifacts (saved browser creds,
# password manager, sticky notes, prior known passwords) beats brute force.
hashcat -m 11300 -a 0 wallet.hash custodian_wordlist.txt -r rules/best64.rule
# Other modes you will meet: 16600 = Electrum, 26600 = MetaMask vault.

The connection to whole-disk and volume encryption is direct: the key-derivation-and-crack workflow here is the same family of problem as BitLocker, FileVault, and VeraCrypt in Chapter 29 — Encrypted Device Forensics, and the defensive-framing rule from this book's bible applies — we teach lawful access and detection, never theft.

Ethereum, tokens, and smart contracts

Ethereum is the second pillar of any modern crypto investigation, and it differs from Bitcoin in ways that change your method. Ethereum uses an account model, not UTXOs: each account simply has a balance that goes up and down, like a bank account. Accounts come in two kinds — externally owned accounts (EOAs), controlled by a private key, and contract accounts, controlled by code. Addresses are 20 bytes shown as 40 hexadecimal characters with a 0x prefix (e.g., 0x4e8b…7f80), with an optional mixed-case EIP-55 checksum.

The account model has a profound consequence for tracing: the common-input-ownership heuristic does not apply. An Ethereum transaction has exactly one sender, so there is no co-spend to cluster on, and no change output to detect. Clustering Ethereum relies on different signals — deposit-address reuse at exchanges, funding patterns, gas-payment relationships, and behavioral fingerprints — and tracing follows account-to-account transfers and the internal transfers that contracts make. Etherscan is the workhorse explorer here, exposing not just direct transfers but internal transactions (value moved by contracts), ERC-20 token transfers, ERC-721 NFT movements, and the decoded inputs to contract calls.

Tokens add both complexity and leverage. Most "crypto" laundering today moves stablecoins — USDT (Tether) and USDC (Circle) — as ERC-20 tokens, because they hold a steady dollar value. The leverage is that these are centralized tokens: the issuers can freeze and blacklist addresses. Tether and Circle have frozen hundreds of millions of dollars at law-enforcement request, which is a tracing endpoint Bitcoin has no equivalent to — a trace that reaches a stablecoin sometimes ends not at an exchange subpoena but at an issuer freeze. DeFi protocols (decentralized exchanges, lending pools) and the Ethereum mixer Tornado Cash (sanctioned in 2022, as noted above) complicate the middle of the graph, but the choke-point logic still holds: value that becomes spendable in the real world generally passes through an identifiable provider.

Why This Matters. The proliferation of chains, tokens, Layer-2 networks, and DeFi protocols can make crypto investigation feel like an endless game of catch-up — and in detail it is. But theme four holds firm: the principles do not change with each new token standard. Identify the asset and its ledger, cluster or follow accounts to define entities, trace to the chokepoints where the regulated world touches the chain, and convert pseudonyms to names with legal process. A USDT-on-Tron case in 2026 and a Bitcoin case in 2014 are the same investigation wearing different clothes.

Privacy coins: harder, not always impossible

Some cryptocurrencies are engineered specifically to defeat the analysis this chapter has described. They are the practical frontier of theme five — know your limitations — and you must understand both why they are hard and where they still leak.

Monero (XMR)

Monero is the most serious privacy challenge in routine casework. It combines three technologies that attack the three things a transaction normally reveals:

  • Ring signatures hide the sender. The real input being spent is mixed with a set of decoy inputs (the "ring"); a verifier confirms the signature is valid for one of the ring members without learning which. Current Monero mandates a ring size of 16, so each real spend hides among fifteen decoys.
  • Stealth addresses hide the recipient. Every payment is sent to a fresh one-time address derived from the recipient's keys, so a recipient's published address never appears on-chain and payments to them cannot be linked together.
  • RingCT (Ring Confidential Transactions) hides the amount, using cryptographic commitments and range proofs.

The combination means the basic moves of Bitcoin tracing — read the inputs, follow the outputs, cluster the co-spends — simply do not work. That said, "hard" is not "impossible," and Monero's history is instructive. The 2018 study by Möser and colleagues showed that early Monero leaked badly: when ring members could be zero (no decoys) or chosen poorly, a chain-reaction deduction could strip decoys away, and a temporal heuristic (the real spend is usually the newest output in the ring) succeeded most of the time. Protocol upgrades — mandatory RingCT, a minimum ring size, and a smarter decoy-selection algorithm — closed those gaps for present-day transactions. So Monero from 2016 may be partially traceable in ways that Monero from 2024 is not.

Against modern Monero you pivot off-chain. You target the boundaries and the endpoints: exchange records where a subject bought or sold XMR (KYC at the chokepoint still works); the BTC↔XMR swap points in a chain-hop, where the Bitcoin side is fully traceable up to the swap; network-level leakage if the subject did not use Tor (Dandelion++ obscures transaction origin at the protocol level, but operational mistakes happen); and, above all, wallet artifacts on a seized device — a Monero wallet's keys and history on a suspect's laptop reveal everything the chain conceals. The on-chain trail may be dark, but people are not airtight.

Zcash (ZEC)

Zcash offers zk-SNARK-based shielded transactions that hide sender, recipient, and amount inside a "shielded pool." It has two address types: transparent addresses (t1…/t3…), which behave like Bitcoin and are fully traceable, and shielded addresses (zs…), which are private. The forensic saving grace is adoption: historically the majority of Zcash value has moved transparently (t-to-t), because shielded transactions were less convenient and many exchanges only support transparent addresses. So most Zcash activity is as traceable as Bitcoin, and the genuine privacy lives only in fully shielded transactions. Risk concentrates at the boundaries — the deshielding moment when value leaves the shielded pool to a transparent address (often en route to an exchange) is where amounts and timing can betray a flow. Zcash also supports viewing keys, which permit selective disclosure; a cooperating party (or one compelled by court order) can hand over a viewing key that reveals their shielded activity.

Limitation. State privacy-coin findings with rigorous honesty. For modern Monero the defensible report sentence is frequently "the funds were converted to Monero on [date]; on-chain tracing of Monero is not reliably feasible with current methods, and the investigation continues via [exchange records / device artifacts / the Bitcoin side of the swap]." That is not a failure — it is professional candor (theme five). Overstating what you can do with a privacy coin is how an examiner gets impeached; underusing the off-chain pivots is how an investigation gives up too early. Both are mistakes.

Tool demonstration: from a free explorer to a commercial platform

A real workflow blends free and commercial tools. You can — and for small matters should — work entirely with public explorers. For scale, attribution, and court-tested reporting, commercial platforms dominate.

The commercial suites are Chainalysis (the Reactor investigation tool and KYT compliance product), CipherTrace (Mastercard-owned), Crystal (Bitfury), TRM Labs, and Elliptic. What you pay for is not visibility — the chain is public — but three things: massive attribution databases that label clusters as known exchanges, mixers, darknet markets, scams, sanctioned entities, and ransomware operators; automated cross-chain tracing that follows peeling chains and chain-hops in seconds instead of days; and defensible, visual reporting designed for investigators and courts. Their attribution has been accepted in numerous prosecutions, but — a point for Chapter 27 — Expert Testimony — the underlying heuristics (common-input, change detection) are what you must be able to explain and defend under Daubert, not just "the tool said so."

A typical Reactor-style trace, conceptually, looks like this:

CHAINALYSIS REACTOR — trace from ransom address (illustrative)
START  bc1qf7v9d2k5s3n8…q2wd    [unattributed]   received 0.82 BTC  2024-09-18
  └► consolidated → bc1qm4t2…0p3e (cluster "ACTOR-1", 214 addresses, common-input)
       └► peeling chain, 37 hops, 2024-09-18 → 2024-10-02
            ├► 0.07–0.12 BTC peels → cluster "ChipMixer-type" [MIXER]  ⚠ obfuscation
            └► remainder → bc1q3kd9w5x7sla…7m6n
                 └► deposit to cluster "Exchange-X hot wallet" [EXCHANGE, KYC] ◄ CHOKE POINT
                      attribution: Exchange-X (reg. MSB) · jurisdiction: US · subpoena ready

For hands-on work without a license, the same path is walkable on blockchair.com or mempool.space (follow each transaction's outputs by clicking through), walletexplorer.com (legacy clustering labels for many exchanges), OXT.me (Bitcoin analytics), and Etherscan (Ethereum). Reusable scripted helpers for batch tracing and address extraction live in Appendix B — Python Forensics Toolkit, and command-line references for the supporting tools are in Appendix H.

Tool Tip. Whatever your primary platform, corroborate load-bearing findings with an independent source — confirm a key TXID and amount directly on a public explorer (ideally your own full node), and reproduce a critical attribution by a second method. "Chainalysis attributed the deposit to Exchange-X, and I independently confirmed the same deposit address in Exchange-X's published hot-wallet set and on a public explorer" is far stronger than a single tool's verdict, and it is the habit that holds up on cross-examination.

Worked example: tracing a ransomware payment

Return to anchor case #3 — the small business hit by ransomware in Chapter 12 — Ransomware Recovery, whose malware you dissected in Chapter 32. Recovery from backups was only partial, and the business reported the crime. From the malware's configuration you recovered the ransom address bc1qf7v9d2k5s3n8…q2wd, and from the victim's exchange you have the withdrawal confirming they paid 0.82 BTC on 18 September. Now you trace it.

1 — Anchor the payment on-chain. On a public explorer (verified against your full node) you confirm TXID 4b8e…3049: 0.82 BTC paid from the victim's exchange-withdrawal address into the ransom address bc1qf7v9…q2wd, in block 812,043. This is the start of the trail and the first line of your evidence log: TXID, block height, time, amount, both addresses.

2 — Cluster the actor. Within an hour the ransom address co-spends with other addresses in a consolidation transaction, and the common-input heuristic groups them: bc1qf7v9…q2wd, bc1qm4t2…0p3e, and 212 others form one entity — call it ACTOR-1 — across which this and prior ransoms were collected. The cluster's history shows multiple victim-shaped deposits over the preceding months: corroboration that this is an operating ransomware wallet, not a one-off.

3 — Follow the peeling chain. From the consolidation address, a textbook peeling chain unspools over two weeks — 37 hops, small peels of 0.07–0.12 BTC breaking off at each step toward various destinations, the large remainder advancing via fresh change addresses (which the change heuristic stitches together). You follow the change.

4 — Hit the mixer (and read the gap). A branch of the peels flows into a cluster the platform attributes to a custodial-mixer service. This is both an obstacle and evidence: the deliberate use of a mixer is a strong indicator of laundering intent, and you report it as such (theme three — the absence of a clean trail is itself a trace). Part of the value genuinely goes dark here. You do not pretend otherwise.

5 — Reach the chokepoint. The remainder of the chain, however, terminates in deposits to an address cluster attributed to Exchange-X, a registered MSB. This is the off-ramp — the moment pseudonymity breaks. You record the exact deposit TXIDs, dates, and amounts.

RANSOMWARE TRACE — summary (UTC)
2024-09-18 14:22  victim pays 0.82 BTC → ransom addr bc1qf7v9…q2wd   [TXID 4b8e…3049]
2024-09-18 15:05  ransom addr co-spends → ACTOR-1 cluster (214 addrs) [common-input]
2024-09-18 → 10-02  peeling chain, 37 hops, change-followed             [change heuristic]
   ├─ ~0.30 BTC → custodial-mixer cluster                              [obfuscation — partial dead end]
   └─ ~0.46 BTC → Exchange-X deposit addrs bc1q3kd9…7m6n et al.        [OFF-RAMP / KYC chokepoint]
2024-10-05  subpoena predicate prepared: Exchange-X, deposit TXIDs + dates

6 — Convert pseudonym to name. With the precise deposit TXIDs as the predicate, investigators serve legal process on Exchange-X (a U.S.-registered MSB, so a domestic subpoena/order rather than an MLAT). Exchange-X returns the KYC identity, bank linkage, and login IP/device history of the account that received the traced deposits. The pseudonym bc1q3kd9…7m6n becomes a person — or, just as usefully, a money mule whose cooperation leads further up the chain. The on-chain evidence (yours) and the account records (the exchange's) are correlated in the report, each finding stated with its limits: the mixed portion is acknowledged as untraced, and the attribution of the exchange account to the ransomware operator (versus a mule) is stated as the inference it is.

War Story. This is not hypothetical. In June 2021, after the DarkSide ransomware attack on Colonial Pipeline, the U.S. Department of Justice traced the ransom across the blockchain and recovered roughly 63.7 of the ~75 BTC paid, by obtaining the private key to a subject wallet. In February 2022, the DOJ traced and seized about 94,000 BTC connected to the 2016 Bitfinex hack — then worth about $3.6 billion, the largest financial seizure in its history at the time — and arrested two individuals who had spent years trying to launder it through exactly the mixers, peeling chains, and chain-hops described above. The launderers' sophistication did not save them; the ledger remembered every move, and the funds had to touch the regulated world to become useful. The blockchain never forgets, and laundering raises suspicion rather than removing it.

Ethics Note. Financial tracing is also one of the most powerful tools ever built for protecting the vulnerable, and that is where this capability touches anchor case #4. In the 2019 "Welcome to Video" investigation, agents traced Bitcoin payments to a darknet site, followed the funds to exchanges, served legal process for KYC records, and from those identities rescued victims and arrested offenders worldwide — an investigation conducted, like all such work, by following money and metadata, never by viewing or describing content. Handled this clinically and only this way: the procedure is trace the payment → cluster → reach the chokepoint → subpoena the identity; the law includes the mandatory-reporting duty under 18 U.S.C. §2258A the instant such material is encountered; and the examiner's own well-being matters, because this work carries real secondary trauma. The ethics, the reporting duty, and examiner well-being are the subject of Chapter 28 — Ethics. Theme six is never more concrete than here: the human cost is real, and the technical skill exists to serve human needs.

Common mistakes

  • Calling cryptocurrency "anonymous." It is pseudonymous. Every transaction is public and permanent; the only secret is the link between address and identity, and that link breaks at every chokepoint. Telling a client, a court, or yourself that "Bitcoin can't be traced" is both wrong and a missed investigation.
  • Operating the live wallet or the original device. Opening a software wallet can broadcast or rewrite state; entering a wrong PIN on a hardware wallet can wipe it; importing a seized seed into a hot wallet can let an adversary's watch-only monitor race you to drain it. Image first, work on the copy, and for hardware wallets assume you get one careful attempt (theme two).
  • Trusting a change-address attribution without corroboration. Change detection is heuristic and error-prone; a wrong call sends your trace down a stranger's addresses. Weigh multiple signals (fresh, non-round, matching type, behavioral) and corroborate before extending a cluster on the strength of change.
  • Misapplying the common-input heuristic across a CoinJoin. Co-spending in a CoinJoin does not imply common ownership — that is the whole point of the technique. Cluster a CoinJoin naively and you merge unrelated people, a serious and impeachable error. Learn to recognize CoinJoin structure first.
  • Asserting an over-broad subpoena, or ignoring jurisdiction. "All accounts associated with this address" invites a motion to quash; tie the demand to specific deposit TXIDs and dates. And confirm the exchange's jurisdiction early — a foreign exchange may require an MLAT that changes your timeline from hours to months.
  • Treating commercial-tool attribution as self-proving. A platform's label is a lead and a strong one, but in court you must defend the underlying heuristics, not "the tool said so." Corroborate load-bearing attributions independently, ideally against your own full node and a second method.
  • Botching a seizure transaction. Crypto transfers are irreversible — there is no chargeback. A mistyped destination address sends seized funds into the void forever. Verify destination addresses character-by-character, test the process on testnet where feasible, and treat the broadcast as a one-way door.
  • Giving up at the mixer or the privacy coin. A mixer or a Monero hop may darken the on-chain trail, but the off-chain pivots — exchange records, the traceable other side of a swap, seized-device artifacts — often carry the case. Conversely, do not overstate what you recovered; state the dark portion as untraced.

Limitations: knowing when to stop

Cryptocurrency tracing is unusually powerful, and precisely for that reason its limits must be stated with discipline. The blockchain's permanence cuts both ways: it preserves the evidence forever, but it cannot, by itself, name anyone.

The hardest limit is the chokepoint that never comes. If funds are traced to a cluster but never move to a regulated, identifiable provider — held in self-custody indefinitely, spent only with privacy-respecting counterparties, or cashed out through a truly non-compliant exchange beyond any legal reach — then you have a complete flow and no identity. "The funds were traced to cluster ACTOR-1 and remain unspent / were cashed out via an exchange that has not responded to legal process" is the honest finding. Pseudonymity is not anonymity, but a careful holder who never touches the regulated world can keep the gap open for a long time.

Mixers and CoinJoins can genuinely break a trace. A well-used custodial mixer, or disciplined CoinJoin practice with no consolidation errors, can sever the link between input and output beyond reconstruction with on-chain analysis alone. Report the portion of value that entered the mixer as obscured, and resist the temptation to "reconnect" it on weak timing coincidences you could not defend under cross-examination.

Modern privacy coins resist on-chain tracing outright. Present-day Monero, with mandatory RingCT and a minimum ring size, is not reliably traceable on-chain with current public methods, and you should say so plainly rather than imply a precision you do not have. Zcash's fully shielded transactions are similarly opaque, though most Zcash value moves transparently. The professional move is to pivot off-chain and to state the on-chain limit honestly.

Heuristics are probabilistic, not proof. Common-input ownership is strong but defeated by CoinJoin; change detection is weaker still. Clustering produces high-confidence groupings, not certainties, and your report language must reflect that — "addresses clustered by the common-input heuristic, which is defeated by CoinJoin transactions; I confirmed no CoinJoin structure in the relevant transactions" is defensible; "these addresses are definitely the same person" is not.

And the oldest limit in this book applies to keys as to drives: if the keys are gone, the coins are gone. A seed phrase that was never written down, a wallet.dat whose passphrase cannot be recovered and whose owner is dead or silent, a hardware wallet that wiped itself — these are unrecoverable in the same final sense as a securely-erased disk or a physically destroyed platter. "The available evidence is insufficient to access the wallet" and "the funds cannot be traced beyond [point]" are valid, professional findings (theme five). Forcing a conclusion the cryptography will not support is how examiners lose cases and credibility.

Progressive project: trace the cryptocurrency in your case

This is an optional thread in your Forensic Case File — engage it only if your case involves cryptocurrency (a ransom demand, a fraudulent payment, a wallet on the suspect device). If it does, add the financial-tracing layer now; if it does not, note "no cryptocurrency artifacts identified" and move on. The deliverable, as always, is evidence sourced to artifacts and stated with limits.

  1. Find the wallet artifacts. Sweep your verified image for wallet files and app data (wallet.dat, Electrum/Exodus stores, the MetaMask LevelDB vault, Ledger Live/Trezor Suite data), and search documents, notes, browser data, photographs (OCR), and unallocated space for addresses and BIP39 seed phrases. Hash every extracted artifact into your chain-of-custody worksheet (template in Appendix F).
  2. Recover the on-chain identifiers. From the artifacts (and from any ransom note, invoice, or chat in the case), list the relevant addresses and TXIDs. Where a wallet is encrypted, note whether lawful password recovery is authorized by your engagement or warrant — and do only what you are authorized to do.
  3. Trace on a public explorer. Using blockchair, mempool.space, or Etherscan (verified against a full node for any load-bearing fact), follow the funds: cluster with the common-input heuristic, follow change through any peeling chain, and note where the trail reaches a mixer, a chain-hop, or — the goal — an exchange chokepoint. Record every TXID, block height, time, and amount.
  4. Identify the legal next step. For each chokepoint, identify the exchange and its jurisdiction, and draft the predicate a subpoena would need: the specific deposit addresses/TXIDs and dates tying the deposits to your offense. Flag anything requiring an MLAT.
  5. Write findings with limits. Add a cryptocurrency section to your case file: what was traced, what reached an identifiable provider, what entered a mixer or privacy coin and is therefore obscured, and what each clustering attribution rests on (which heuristic, and its known failure mode). The capstone in Chapter 38 — The Capstone Investigation folds this into the master report.

Save your trace export (and its SHA-256) and the artifact hashes into the case-file folder. As with every chapter, do not let this evidence live only in your head.

Summary

Cryptocurrency turns one of this book's foundational ideas inside out: where deleted ≠ destroyed describes data that persists until overwritten, a blockchain is a ledger where nothing is ever deleted or overwritten at all — public, permanent, and global. The catch is that it records addresses, not names: Bitcoin and its kin are pseudonymous, not anonymous, and the whole discipline is the science of bridging the gap between pseudonym and person. You learned Bitcoin's UTXO model and the anatomy of a transaction — inputs that must be signed, outputs measured in satoshis (10⁸ per BTC), identified by a double-SHA-256 TXID — and how to read one in a block explorer. You learned the two heuristics that turn addresses into entities: the strong common-input-ownership heuristic (multiple inputs share one owner, because all must be signed) and the weaker, signal-blended change detection that extends a cluster forward, along with their nemesis, CoinJoin. You learned to trace value through peeling chains, mixers and tumblers, and chain-hops, and the strategic truth that organizes it all: pseudonymity breaks at the on-ramp/off-ramp chokepoints, where regulated exchanges hold KYC/AML identity that legal process — subpoena, order, or MLAT — converts into a name. You learned wallet forensics: wallet.dat (Berkeley DB or SQLite, magic 0x00053162 or SQLite format 3), the decisive power of a recovered BIP39 seed phrase (the seed is the wallet), browser and app wallets like MetaMask (the LevelDB vault under extension ID nkbihfbeogaeaoehlefnkodbefgpgknn), Electrum, and Exodus, and the hard wall — and the metadata leverage — of hardware wallets, whose companion-app xpubs let you trace watch-only even when the device stays locked. You saw how Ethereum's account model breaks the common-input heuristic and shifts tracing to accounts, tokens, and the centralized-stablecoin freeze as an endpoint. And you met the frontier of theme five in privacy coins — Monero's ring signatures, stealth addresses, and RingCT, and Zcash's shielded pools — honestly hard, sometimes leaky at the edges and in older data, and best attacked off-chain. You ran the whole method against the ransomware anchor, following a payment from the ransom address through a cluster, a peeling chain, a mixer, and an exchange chokepoint to a subpoena predicate — and you touched, clinically, the way the same tracing identifies offenders and rescues victims. The coins and chains will keep multiplying; the method will not change.

You can now: - Explain why cryptocurrency is pseudonymous (not anonymous) and read a Bitcoin transaction's inputs, outputs, satoshi amounts, and TXID in a block explorer. - Cluster addresses into entities using the common-input-ownership and change-detection heuristics, and recognize where CoinJoin defeats them. - Trace funds through peeling chains, mixers, and chain-hops to the on-ramp/off-ramp chokepoints, and identify the legal process (subpoena/order/MLAT) that turns an exchange deposit into a KYC identity. - Locate and identify wallet artifacts — wallet.dat, BIP39 seed phrases, MetaMask/Electrum/Exodus stores, and hardware-wallet companion data — and frame lawful password recovery for either an owner (recovery) or a seizure (forensics). - Adapt the method to Ethereum and tokens (account model, stablecoin freezes) and assess privacy coins (Monero, Zcash) with honest limits, pivoting off-chain when the chain goes dark. - State every clustering, tracing, and attribution finding with its underlying heuristic and known failure mode, and preserve on-chain evidence (TXID, height, time, hashed export, ideally a self-hosted full node) to chain-of-custody standards.

What's next. Chapter 34 — IoT, Vehicle, and Embedded Device Forensics — leaves the ledger for the physical world of tiny computers everywhere: smart-home devices, infotainment and telematics in cars, wearables, and embedded flash — where the artifacts are weirder, the storage is rawer, and, once again, technology changes, principles don't.

Practice in exercises.md, test yourself with the quiz, apply it in the case studies, review the key takeaways, and go deeper with further reading.