Mixnet to a service-provider-integrated lightwalletd

A forked lightwalletd embeds a Nym service provider and receives requests as Sphinx messages, replying through SURBs. No client IP exists at the destination, and all users form one anonymity set. The strongest configuration — but very slow and needs client/server changes.

IP hidden · P1@L2Req-unlink · P2@L2Local net · P1@L3LGlobal net · P1@L3GFast sync
Mixnet (5-hop)SURB reply
Mix L1+50 msMix L2+50 msMix L3+50 msClientEntry GWExit GWSP-integrated lightwalletd

Forward: client → entry → 3 mix layers → exit → the SP-integrated lightwalletd. It replies via SURBs (pre-computed return paths back through the mixnet), so it never learns the client address; packets arrive from all last-layer mix nodes.

ClientEntry GWMixExit GWService provider
Mixnet (5-hop) (mixing delays)

Per-actor assessment & trade-offs

Sees

  • Block requests from many users, with timing delays

Can't see

  • Client IP or location (packets arrive from all last-layer mix nodes; replies via SURBs)

Residual / countermeasure

  • Application-layer session state is not automatically eliminated today: the fix is a fresh sender tag per request, each provisioned with its own SURBs. With that fix, P2 holds at the transport level by construction rather than through client-side rotation.
  • All users of the provider share one anonymity set (perfect crowding and splitting); low usage shrinks it.

Sees

  • Constant-size packets at a Poisson rate with cover traffic

Can't see

  • Reliable destination, volume or activity

Sees

  • Nothing reliable — the actual packet flow is never seen

Can't see

  • The client↔lightwalletd link

Residual / countermeasure

  • Strongest option against a global observer: cover traffic and multiplexing on all mixnet links, including traffic arriving at the integrated lightwalletd, hide the flow.

Pros

  • lightwalletd cannot learn client identity or location (SURB replies)
  • Even a global passive adversary cannot link client to lightwalletd — strongest of the set

Cons / mitigations

  • Very slow (5-hop + mixing delays)
  • Requires a lightwalletd fork + client changes to Nym addressing
  • Needs many users for cover

Fit

  • Client identity + IP heavily hidden from lightwalletd
  • Block sync very slow

Latency model

Regional (40)Continental (120)Intercontinental (300)
Mixnet (5-hop)1.6 s (6 hops, 3 mix layers)
Geographic propagation (speed-of-light)Per-hop mixing delayReliable-channel ACK (return, geographic only)Fragmentation (bounded send rate)

Fragmentation latency shown for SendTransaction (2.1 KB): a larger message splits into more Sphinx packets, metered onto the mixnet at a bounded rate, adding latency.

Baseline hygiene applies here tooWhatever the transport, the wallet still owes the same Layer-2 discipline: randomize request times, obfuscate the start height, and never broadcast on reaching the tip.Full detail →

Content from the Nym × Zcash reference doc. Latency figures are an illustrative model (not measured).