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 (Ironwood: including the public migration amounts)

Cannot observe

Anything off-chain

Cost

Free — the public chain.

L2Compromised lightwalletdA primary 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 (direct connection)

Client connections to other destinations

Cannot observe (mixnet)

Client IP (it sees the IP of the exit gateway instead)
Client connections to other destinations
Traffic in the mixnet

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

Direct connections of the user, including packet sizes, timing, and sources/destinations

Cannot observe (direct connection)

Encrypted packet payloads

Cannot observe (mixnet)

Encrypted packet payloads
Packet routes or traffic source/destination beyond the user link (due to multi-hop routing)
Whether the user is at all engaged in communication at a given time (due to cover traffic)

Cost

Whoever runs the access network or ISP.

L3GGlobal network observer

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

Observes

All packets sent and received by all entities in the network

Cannot observe (direct connection)

Encrypted packet payloads

Cannot observe (mixnet)

Encrypted packet payloads
The source and destination of packets routed via the mixnet (Sphinx packets cannot be traced through a mix node)
Which packets are real traffic and which are cover traffic
Whether a client that continuously sends traffic is communicating at a given moment

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. Ironwood-specific: because the migration turnstile makes every migration amount 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 a single wallet's transactions with each other. Ironwood-specific: during the migration this bites hardest, because migration amounts are public, so 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 quantization: grid snapping of requested ranges (§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 quantization (grid snapping)