This section states what the server of “The light-client service” (§5) learns about a light wallet. It defines payment-detection privacy and unlinkability as indistinguishability games against the server of Assumption 5.2 and the view on which the server decides; proves that the view is a deterministic function of the chain, a tuple of schedule parameters and transport metadata, never of the wallet’s keys; derives the leakage of range queries, transaction queries, transparent-address queries and submission as instances of that theorem; and closes with a table of the server’s observables and the class of each mitigation.
The server is the node and the proxy together (Definition 5.1), under Assumption 5.2: clause (a) makes the response to each query a function of the server state and the query, and clause (b) is the power of the adversary. No second adversary is defined. The server state at time is the server’s best chain at together with the state of its node’s transaction pool; the latter enters only the responses of and (Definition 5.9). An evolution is a family up to a horizon . A wallet configuration is a pair : is the wallet’s key material, the spending, full viewing, incoming viewing, outgoing viewing and nullifier deriving keys of every account; is every other input of the wallet, namely the birthdays, the user’s actions and their times, the scheduling policy’s configuration, any state retained from earlier sessions, and the law from which the network endpoint of each connection is drawn.
The view of a wallet is the record of clause (b) of Assumption 5.2: the transcript
of the wallet’s queries in the order issued, each with its connection , its query name of Definition 5.10, its argument tuple , its time and its response ; and, for each connection , the transport metadata , the network endpoint that the server sees and the open and close times. Times are recorded at a finite resolution, and a run up to a horizon issues finitely many queries, so every view ranges over a countable set.
Let be a scheduling policy, a public randomised rule that emits the wallet’s queries, made precise in “Key independence of queries” (§8.2). The payment-detection privacy game is the following indistinguishability game, with the advantage of a distinguishing game of the Crypto Guide, §“Security as a game”, Definition “Security game and advantage”; the adversary is not restricted to polynomial time.
The adversary fixes an evolution , whose chain may contain outputs to either key set, and two configurations and with the same .
The challenger draws a uniform bit , runs the wallet under against a server with evolution up to , and hands the adversary the view of that run (Definition 8.1).
The adversary outputs and wins if and only if ; its advantage is .
Network privacy holds when the endpoint of each connection is drawn afresh, independently of everything else, from a law that does not depend on which wallet opens the connection. The unlinkability game , under network privacy, differs in two points: the adversary fixes and two configurations and ; and the challenger runs two consecutive synchronisation sessions, both of wallet when , the second resuming from the state in which the first ends, and a session of wallet followed by a session of wallet when . The adversary receives the views of both sessions. Policy provides payment-detection privacy (respectively unlinkability) if every adversary has advantage zero in (respectively ), and provides it within if every advantage is at most .
ZIP 307, “Security Model”, states the goal informally and with a lowercase “should”: the proxy should not learn which transactions received from the chain are addressed to a given light wallet, and, assuming network privacy (“via Tor or similar”), should not be able to link different connections or queries as deriving from the same wallet. It takes the node and proxy combination to be honest but curious, trusted to provide a correct view of the current best chain and to transmit queries and responses faithfully. Game formalises the first sentence and game the second; the trust clause is clause (a) of Assumption 5.2, an assumption distinct from the goal. The chain is common to both worlds of each game. What the chain itself reveals to a party without keys is the subject of the Ironwood Guide, §“Privacy”, Theorem “Privacy of an Action”, whose Remark “Non-claims” excludes wallet and network metadata, the subject of this section.
ZIP 307, “Security Model”, does not address how to spend notes privately. Submission through the same server is nevertheless part of the view of Definition 8.1 and is analysed in “The submission channel” (§8.5). The status of ZIP 307 and of ZIP 314 is that of Table 1. ZIP 314, titled “Privacy upgrades to the Zcash light client protocol”, carries no specification text, so a specified successor to the privacy treatment of ZIP 307 is an open problem (Definition 1.1).
ZIP 307 makes two statements about its interaction of phases A to D (“Scan order”, §6.4). First, since synchronisation proceeds over a broadcast medium, it leaks no information about which transactions interest the client (“Transaction privacy”). Second, the start of each of phases B and D reveals the height to which the client last synchronised, an information leak under the security model, assuming network privacy (“Block privacy via bucketing”). The two statements hold together: the first concerns the content of the responses, the second the bounds of the queries, two components of the view that Theorem 8.8 separates. The second is a leak in , since the resume height links a session to the session that reached it; both are made precise in “Key independence of queries” (§8.2) and “Leakage of range queries” (§8.3).
A light wallet delegates the storage and filtering of the chain to the server and keeps its keys; its note state (Definition 6.7) is rebuilt on the device. What reaches the server is its query schedule, recorded as in Definition 8.1.
Every argument of every query of Definition 5.10 is one of the following: a block identifier, a height or a block hash (, ); a pair of heights with a pool set (); a shielded pool with a subtree index (); a transaction identifier (, ); a set of transparent addresses (); the bytes of a transaction (). Query takes none. No argument is a spending, full viewing, incoming viewing, outgoing viewing or nullifier deriving key, and no argument other than that of is a nullifier of a note that the wallet holds unspent. The argument of carries the nullifiers of the notes it spends; it is a component of (“transactions submitted”) whose law depends on , so submission is not covered by (“The submission channel”, §8.5). Against adversaries restricted to polynomial time, what the public data of its Ironwood-pool bundle reveal of its keys is bounded by the Ironwood Guide, §“Privacy”, Theorem “Privacy of an Action”, under the preconditions and assumptions named there; that theorem claims nothing for an Orchard-pool bundle (its Remark “Non-claims”) and does not treat Sapling components. A transparent address is a receiver, disclosed by declaration (the Remark “Transparent boundary” below). Which arguments the wallet chooses may depend on its keys; that dependence is carried by the schedule parameters of Theorem 8.8.
Trial decryption and acceptance (Construction 4.8, Definition 4.9), nullifier matching and the search of retained unlinked nullifiers (Construction 6.8), and the assembly of authentication paths from retained information (Definition 7.12, Proposition 7.13) take as inputs the wallet’s keys, responses already received and retained data, and issue no query.
By inspection of the cited definitions. The underlying procedures are the Ironwood Guide’s, §“Trial decryption and note acceptance” (Construction “Trial decryption”) and §“Authentication paths” (Lemma “Authentication paths from public data”), both computed from data already held. □
A scheduling policy is a public randomised rule that, from the responses received so far and a tuple , emits the next query with its argument, its connection and its time. The schedule parameters collect every other input on which the emitted schedule depends: the wallet birthday (Definition 6.2) and the resume heights; the bounds, the pool sets and the order of range queries; the subtree extents requested (Definition 7.16); the transaction identifiers fetched or queried; the transactions submitted; the sets of transparent addresses queried; and the policy’s random coins, a finite bit string that fixes times, orders and connection choices. Every component takes values in a countable set. Keys enter the schedule only through (Lemmas 8.5 and 8.6). Given , the law of is induced by the configuration . The endpoints are drawn from the law that fixes, independently of ; without network privacy that law may be a single point.
For random variables and with values in a countable set, is their statistical distance.
Assume Assumption 5.2, and let be a scheduling policy. There is a deterministic function with
Hence:
two wallets with equal and equal endpoints produce the same view, whatever their keys;
in , with the schedule parameters of wallet and , every adversary that fixes has
and the first bound is attained by an adversary that is not restricted in time; in particular provides payment-detection privacy if and only if, for every , , and , the view has the same law for and , which holds whenever the law of given is the same for both;
the bounds of (ii) hold for with the pair of the two sessions’ parameter tuples in place of , the endpoints being independent of under network privacy.
Privacy holds exactly when the view has the same law for both key sets, and in particular whenever the law of given does not depend on the wallet’s receipts, its detected notes and spends, or the transparent addresses it watches; each leak of “Leakage of range queries” (§8.3) to “The submission channel” (§8.5) is an instance.
Induction on the transcript. Query , with its name, argument, connection and time, is emitted by from and responses . Response is, by clause (a) of Assumption 5.2, a function of and query . The metadata is with open and close times that the schedule fixes. So is a function of the three inputs, which gives (i).
For (ii), fix . An adversary is, after its choice, a randomised decision rule; write for the probability that it outputs on view . By the Crypto Guide’s Definition “Security game and advantage” (§“Security as a game”), , and
where is the set of with (or its complement, for the opposite sign); equality holds for the indicator of . For the second bound, is independent of with the same law in both worlds, so ; and for a deterministic , , since is the sum of over the preimage of and the triangle inequality applies term by term. An adversary that chooses at random has an advantage at most the maximum over its choices. The characterisation follows, since the advantage of the optimal adversary is . For (iii), apply the same argument to the pair of sessions; under network privacy is independent of and of the parameter tuples. □
The response to , , and is the same for every wallet that issues the same query at the same time. Let a policy’s shielded synchronisation consist of , for each shielded pool, , queries that cover in increasing height with bounds fixed by , the resume heights, the returned tips and the policy’s coins and one pool set in every query, fixed independently of receipts, and the queries of Construction 7.24, with the retained boundaries and the heights at which block hashes are recorded fixed by , the resume heights, the responses and the policy’s coins; and let its query times be fixed by its coins and the responses, not by the duration of local computation. Its is then a function of , the resume heights, the pool set and the coins, none a function of receipts, so its compact-block phase leaks no receipt. The commitment recomputation that replaces the discarded AEAD tag as the integrity check of compact decryption (Definition 4.9, Proposition 4.10) is local by Lemma 8.6. Requesting every complete subtree root from index is independent of the positions of the wallet’s notes; requesting a particular extent is not (Proposition 8.15). A policy that drops the Orchard pool from once rule (R5) of Definition 6.4 stops its scanning reveals the height at which the Orchard-pool balance became known to be zero; keeping the pool in and omitting only the trial decryption avoids this.
The first sentence is clause (a) of Assumption 5.2. The rollback heights of Construction 7.24 are functions of , the stored block hashes and the responses, hence, by the hypothesis on and on the recorded heights, of , , the resume heights and the coins. The remainder is Theorem 8.8(i) and (ii) with the listed , whose law given does not depend on . □
The hypothesis on times is necessary: a policy that issues its next query when the processing of a range ends, when that processing takes longer for a range with detected notes, puts a function of receipts into the times of .
Query puts the addresses of into and into the view in the clear, by declaration, not by inference, and a query with presents the members of as one requester’s. The addresses are derived from , so in a policy that queries its watched transparent addresses has advantage against the adversary that reads . The guarantee of Corollary 8.9 is a property of the shielded layer only.
Let a wallet watch transparent addresses and query them one address per query, in rounds that visit every address once in a uniformly random order, at times whose successive gaps are independent draws of law with seconds, of mean , one expected query per address per day (Math Guide, §“Beyond finite spaces: countable additivity, limits, and densities”, Example “A jittered schedule”). Then no query argument contains two addresses, and the server cannot link two addresses by co-occurrence in one query. It can still link them through the connection and its endpoint when their queries share either, and through the times in : per-address randomised timing does not unlink addresses queried over one connection. The schedule removes one linking channel, not linkability. The schedule is designed but unspecified (Definition 1.1); ZIP 318, “Transfer scheduling”, specifies an analogous schedule, a uniformly random shuffle and independent exponential delays, for its migration transactions.
The arguments are singletons by construction. The remaining channels are the connection, endpoint and time components of the view, which Theorem 8.8 retains unchanged. The law of the gaps is cited, not derived. □
Let be the least height of any block that the wallet requests, where requests the heights of , the height , and the height whose chain state below it is fetched. A policy that requests no block below the wallet birthday (Definition 6.2, the minimum of its accounts’ birthdays) reveals , and when it requests a range that starts at , which need not be its first range under a prioritised order. Since lower-bounds the first block in which any account could have received funds (ZIP 326, “Terminology”), the server learns the upper bound on the height below which the wallet expects no receipt; once the wallet requests a range that starts at , so that , it learns that bound exactly. Adding an account with an earlier birthday lowers later. A policy that starts at Sapling activation, as ZIP 307 prescribes for a seed that the client did not generate (“Importing a pre-existing seed”), and as this volume does for a seed restored without a recorded birthday (Definition 6.2), reveals only that constant. The birthday is a component of , common to both worlds of ; its disclosure is a disclosure of and, where birthdays differ, a linking component in .
The birthday is a component of and a function of the view; the statement is an instance of Theorem 8.8. □
In the interaction of ZIP 307, “Client-server interaction”, the range of phase B starts at the height that the previous synchronisation reached, and that of phase D at the height that phase B reached. Each start therefore reveals the previous synchronisation height, the tip at the time of the previous session, and so links consecutive sessions: in an adversary that chooses with a resume height other than the tip returned to the first session wins with probability . Under a prioritised policy the bounds are those of the policy’s ranges (verification ranges near the stored tip, extents of subtrees, historic ranges); they reveal the scan state, the maximum and fully scanned heights of Definition 6.11, to the extent that the ranges are functions of it, and need not equal the previous synchronisation height.
The bounds are components of , and the statement is an instance of Theorem 8.8(ii) and (iii). For the adversary: when the second session starts at the tip returned to the first, when at the resume height of , and the two differ with probability . □
Let a policy, on detecting a note at position of pool , always request the block extent of subtree (Definition 7.16) as a query that the in-order schedule would not issue at that time. The extent starts at and ends at the completing height , or at the anchor height for the incomplete last subtree; the server knows every completing height from the responses to , so it learns and that the wallet holds a detected note among the at most leaves of subtree . Against such a policy, an adversary in that places an output to alone in a subtree outside both wallets’ in-order schedule at that time, and chooses with no receipt in , wins with probability . The statement is an inference over the abstract policy of “Witness readiness” (§7.5), not a measurement of any deployment; no mitigation is specified, and one is an open problem (Definition 1.1).
The requested extent is a function of , a receipt, and a component of ; the map from extent bounds to is public. Wallet issues the extent query and wallet does not, so the adversary that outputs exactly when the view contains that query wins with probability , an instance of Theorem 8.8(ii). □
Fix a bucket size and let . Phase B requests in place of , and phase D requests in place of . The blocks from to are checked, height by height, to carry the block hash of the wallet’s chain view, and are then discarded without further processing. On a mismatch at height the wallet rolls back (Definition 7.23) to if it holds . Otherwise it obtains , compares hashes as in step (3) of Construction 7.24, takes its frontiers and rolls back to . Both chains then agree at , and it sets . A mismatch at goes to Construction 7.24 with . In phase D, replaces throughout this check. Most reorganisations are thereby handled within the same range. The construction is specified, as the modification of phases B and D in ZIP 307, “Block privacy via bucketing”, which the ZIP describes as a proposed enhancement.
Under Construction 8.16 the start of a range of phase B or D reveals and no more of the resume height : two wallets whose resume heights share a bucket and whose parameter tuples agree elsewhere issue ranges with equal starts. The ends of the ranges, their order and their timing are unchanged, and so is their leakage. The gain is in the set of resume heights consistent with a start, from one height to one bucket of heights; it is not an advantage bound of , in which an adversary that chooses with a resume height in another bucket still wins with probability .
A query or issued without cover puts that transaction into and reveals it as one that the wallet is fetching or tracking: a received transaction whose memo or outgoing plaintext the wallet recovers (the enhancement of Construction 6.8), a sent one, or a transparent dependency. This is the set that payment-detection privacy protects. Against a policy that fetches exactly its wallet-relevant transactions, an adversary in that places an output to alone, at a height that the common schedule scans before the horizon, and chooses with no receipt in , wins with probability . A transaction identifier queried in two sessions links them in .
The fetched set is a function of receipts and a component of . Wallet fetches the transaction of the output and wallet does not; the statement is an instance of Theorem 8.8(ii) and (iii). □
ZIP 307, “Transaction privacy”, states the following interoperability rules. A light client needs full transactions for the memo fields of received notes and for outgoing ciphertexts, to recover spend information when a seed is imported. It SHOULD obscure the exact transactions of interest by also downloading numerous uninteresting transactions; it SHOULD download all transactions of any block from which it fetches a single full transaction; and it MUST convey to the user that fetching full transactions reduces privacy. The MUST is unconditional, not a fallback for omitting the SHOULDs. Under the second SHOULD the fetched set reveals the blocks that hold a transaction of interest, not the transactions. The rules are specified (Definition 1.1).
No query of Definition 5.10 returns the full transactions of a block, since returns the compact block; the second SHOULD therefore costs one query per transaction of the block.
A query issued at a time fixed by the completion of the range in which its transaction was detected is correlated in time with that range; under network privacy with separate connections, the times in still link the two (Theorem 8.8(iii)). A delay drawn independently of that completion time would remove the correlation. No ZIP specifies one for transaction queries, and no stated design fixes its law: an open problem (Definition 1.1).
Let the wallet submit a transaction by on a connection to its synchronisation server. The server then holds the complete transaction before it is broadcast, at a time in , on a connection with endpoint . Without separation at the network layer it links the transaction to that endpoint and to the other queries of the same connection or endpoint, among them the birthday bound, the range bounds and the transaction queries of the session. The disclosure lies outside the goal of ZIP 307 and inside the view of Theorem 8.8.
The transaction, its time and its connection are components of the view; the statement is an instance of Theorem 8.8(i). □
The server’s operator terminates the transport, so channel encryption such as TLS protects queries from third parties and not from the server. Every connection exposes to the server its endpoint and its open and close times, the endpoint being the wallet’s network address or that of an exit of an anonymity network or of a proxy. Without network privacy is a component common to all sessions of one wallet, which is why the unlinkability goal of ZIP 307, “Security Model”, assumes network privacy.
Let submission and synchronisation use connections whose endpoints are drawn independently, as separate anonymity-network circuits give; or let submission go to a server that does not share its view with the synchronisation server, in which case the query is absent from that server’s view and the separation rests on that non-collusion assumption. Then the endpoint no longer links the query to the synchronisation session. Correlation remains through the times in ; through content, the anchor and expiry heights of the transaction against the range bounds of the session; and through application-level identifiers, such as a later query for the submitted transaction identifier on the synchronisation connection. For payments the separation is designed but unspecified (Definition 1.1). For migration transactions ZIP 318 specifies the network-privacy step (“Network-layer privacy”: the wallet MUST offer Tor and, where available, Nym, and MAY broadcast through a server other than the synchronisation server) and the separation in time of synchronisation from broadcast (“Decoupling synchronization from broadcast”).
The endpoint components of the two connections are independent, so their joint law is the same whether or not the connections belong to one wallet; every other component of is unchanged, and the remaining channels are those components (Theorem 8.8(iii)). In the second case the synchronisation server’s view contains no query, and under non-collusion the other server’s view is not joined to it. □
Table 5 lists the observables of the server, what each reveals, its mitigation and the class of that mitigation (Definition 1.1). The interface of Definition 5.10 omits mempool queries, so no row concerns the mempool.
| Observable | Reveals | Mitigation | Class |
|---|---|---|---|
| Network endpoint and connection times | network location and activity windows | network anonymity (Proposition 8.22) | designed but unspecified; specified for migration broadcasts (ZIP 318) |
| Least requested height | an upper bound on the birthday (Proposition 8.12) | a start at Sapling activation, at the cost of Proposition 6.17 | specified for an imported seed (ZIP 307) |
| Range bounds and order | resume height and scan state (Proposition 8.13) | bucketing of the start (Construction 8.16) | specified (ZIP 307) |
| Out-of-order completion ranges | the subtree of a detected note (Proposition 8.15) | none | open problem; the leak is inferred |
| Transaction queries | the transactions of interest (Proposition 8.18) | decoys and whole-block fetches (SHOULD) | specified (ZIP 307) |
| Submission | the transaction before broadcast, linked to its session (Proposition 8.21) | separate circuits | designed but unspecified |
| Transparent-address queries | the addresses, by declaration (§8.2) | one address per query at exponential times in random order (Proposition 8.11); linkage by connection and timing remains | designed but unspecified |
| Pool sets of range queries | if narrowed by wallet state, the height at which the Orchard-pool balance became known to be zero (Corollary 8.9) | one pool set fixed independently of receipts; only trial decryption omitted | designed but unspecified |
Every row of Table 5 is a component of or of the transport metadata (Theorem 8.8); none is a function of the content of compact blocks (Corollary 8.9). The size of each leak depends on policies that the protocol leaves open: beyond the rules of ZIP 307 and the migration schedule of ZIP 318, no ZIP fixes the scheduling policy of a wallet.