Threat model

The shared vocabulary the rest of the site is threaded through: who can attribute a request to a person, who can link requests to each other, and what counters each. Drawn from §2–§3 of the network privacy analysis.

Threat actors

L1Chain-only observer

Knows only what is publicly visible on the chain.

Observes

Public on-chain data (including public migration amounts)

Cannot observe

Anything off-chain

Cost

Free — the public chain.

L2Compromised lightwalletdPrimary adversary

Controls or has compromised the lightwalletd used by the wallet (or, for full-node wallets, a peer).

Observes

Source IP of incoming connections
Fine-grained arrival timing of every request
Complete request contents: block ranges fetched (GetBlockRange), transactions retrieved (GetTransaction), transactions broadcast (SendTransaction)

Cannot observe

Only what the client never sends it

Cost

Cheap to instantiate — run a popular lightwalletd — at a privileged vantage point.

L3LLocal network observer

On the client's access network (Wi-Fi, ISP). Knows the user's IP.

Observes

Where the user's traffic goes, and its timing and volume
Timing and type of activity via traffic fingerprinting

Cannot observe

TLS-protected contents

Cost

Whoever runs the access network or ISP.

L3GGlobal network observer

Simultaneously observes both ends of the communication and all intermediate hops.

Observes

Flow correlation (timing, volume, size of a sequence of packets) at the input and output of every hop, or end-to-end

Cannot observe

TLS-protected contents

Cost

A powerful adversary with global visibility.

Adversaries at every level may hold auxiliary information: stolen KYC records, records from compromised exchanges, previously deanonymized transactions.

Invariants

Invariant A — Linkage between identity and approximate balance

The adversary cannot link a user identifier (e.g., client IP address) to a balance, even approximately. Since migration amounts are public, the invariant survives only as long as no migration transaction, and no group of them, is attributable to the user.

Depends on: P1 at every actor plus V2/V3 discipline — attribution can be direct (a broadcast from the user's home IP) or transitive (a broadcast linkable to attributable activity such as a sync session).

Invariant B — Linkage between transactions

The adversary must not be able to group the migration transactions of a single wallet. Grouped amounts sum to the starting balance and feed subset-sum linkage against known amounts.

Depends on: P2 plus V3 content discipline.

Unlinkability properties

P1 — Request-identity unlinkability

The adversary cannot attribute a given request to the user (e.g., via the client IP address).

P2 — Request-request unlinkability

The adversary cannot determine that two requests originate from the same client. A request is any protocol interaction: a block-range fetch, a transaction fetch, a broadcast.

The two properties are asymmetric. If requests are attributable to an identity, they are thereby linkable to each other, so a P1 failure across requests implies a P2 failure; the converse does not hold. Pseudonymous profiles are the intermediate state most configurations land in, and they are fragile: one attributed request anywhere in the profile retroactively attributes the whole profile.

Vectors & countermeasures

Vector	Consists of	Observable from	Countermeasures
V1 Session state	Source IP observed by the destination, TCP/TLS connection state, tunnel session, application-layer session identifiers.	L2	Layer 1 · vs L2 Relaying (hides the client IP) Layer 1 · vs L2 Short-lived connections (a new connection per request) Layer 1 · vs L2 Exit rotation per connection (in dVPN and mixnet alike)
V2 Timing	At the destination, the arrival times of requests; on network links, the timing, size and volume of packets.	L2, L3L, L3G	Layer 2 · vs L2 Client-side: randomized request times; broadcast scheduling (§5) — against the destination Layer 1 · vs L3L/L3G In transit: mixing delays, Poisson sending, cover traffic — against network observers
V3 Content	Requested heights and ranges, fetched txids, queried t-addresses and UTXOs, broadcast payloads.	L2	Layer 2 · vs L2 Start-height obfuscation: randomized overlap, checkpoint snapping (§5)

A common category error is crediting in-transit V2 mixing as protection against the destination (L2). Mixing delays and cover traffic change what a network observer can infer; the destination sees only what arrives and when it arrives. No amount of mixing protects a user against the server they are talking to — what protects them is the absence of V1 state, plus V2/V3 discipline on the requests themselves.

The two-layer model

Layer 1 — Transport

What the scenario chooses. Provides V1 identity protection and V2 in-transit timing protection against network observers.

V1 (identity) vs L2: relay + short-lived connections + exit rotation
V2 (in-transit timing) vs L3L/L3G: mixing, Poisson sending, cover traffic (mixnet only)

Layer 2 — Baseline hygiene

Transport-independent client discipline (§5), owed by every wallet regardless of which scenario is chosen.

V2 (timing) vs L2: randomized request times; broadcasts decorrelated from sync milestones
V3 (content) vs L2: start-height obfuscation (randomized overlap / checkpoint snapping)

A note on Tor

Tor hides the client IP from the destination (P1 via V1). In its default configuration it behaves like dVPN single-exit — long-lived circuits from the same exit IP leave requests linkable at L2 — while with a fresh circuit per unlinkability domain it behaves like the multi-exit case, restoring P2. Its three hops ensure no single relay sees both ends, but it provides no in-transit V2 protection against L3L/L3G.