# A Privacy Layer for Transparent Wallets

Anyone worrying about [AI-assisted advancements in cryptography](https://openai.com/index/sharing-ai-progress-in-mathematics/) is careful to keep public keys hidden. This means posting only the address, which contains a *hash* of the public key, and rotating transparent addresses on every transaction. Then you add a hash-based spending signature escape hatch, such as [WOTS](https://www.rfc-editor.org/rfc/rfc8391.html#section-3.1), alongside your elliptic-curve public key.

There is no integrated UX flow for this, and ordinary wallet lookups undermine your privacy. The RPC server learns which addresses belong to the same client. [Private information retrieval (PIR)](https://en.wikipedia.org/wiki/Private_information_retrieval) removes this lookup leak, letting wallets monitor rotating addresses without revealing which ones they are checking. Using WOTS, this is deployable today, yielding post-quantum-safe, private rotating transparent addresses.

**Our team plans for post-quantum signature opcodes to land in Zcash in January.**

In this post, we’ll explain the PIR techniques that let a wallet recover its transparent history and balances without revealing the addresses it queries to the RPC server. Transparent transactions remain public on-chain; PIR protects the lookups needed to manage them.

## How Rotation Helps

Each standard Zcash `t1…` transparent address contains a hash of a public key. The address and its transaction history are public, but the address alone does not disclose the underlying public key. Spending from it publishes that public key alongside the signature. [Zcash address encoding](https://zips.z.cash/protocol/protocol.pdf), [P2PKH transaction mechanics](https://developer.bitcoin.org/devguide/transactions.html#p2pkh-script-validation).

This distinction has enormous implications for address reuse. Once a public key is exposed, any funds remaining at that address—or arriving there later—remain controlled by the same key. Moving the remaining funds to a fresh address places them behind a different public-key hash. That offers additional protection under the scenario where public-key recovery becomes practical but the relevant hashes remain secure.

Creating a fresh address does not require a new wallet or seed phrase. Standard wallet derivation produces a tree of distinct key pairs from one seed. Here is a simplified view:

```text
One seed phrase
    └── Master key
          └── Transparent account
                ├── Private key A → Public key A → Hash → Address A
                ├── Private key B → Public key B → Hash → Address B
                ├── Private key C → Public key C → Hash → Address C
                ├── Private key D → Public key D → Hash → Address D
                └── Private key E → Public key E → Hash → Address E
```

Spending from A reveals public key A. It does not automatically reveal public keys B–E or the seed.

```text
offset A = HMAC-SHA512(parent chain code, parent public key + index 0)
offset B = HMAC-SHA512(parent chain code, parent public key + index 1)

private key A = parent private key + offset A
private key B = parent private key + offset B
```

If those other public keys have never been disclosed, they retain the protection of their hashes. The same backup can regenerate the sequence of addresses. [Zcash transparent key derivation](https://zips.z.cash/zip-0316#deriving-unified-addresses).

An extended public key needs separate care. An account’s extended public key contains enough information to derive its receiving and change public keys. Equivalent information can also appear in the transparent component of a Unified Full Viewing Key. Sharing it therefore exposes more public keys than an ordinary spend.

If an attacker obtains the account’s extended public key and recovers one of its transparent private keys, they can also recover the account’s private key and derive its other transparent private keys. Keeping the wallet secure requires protecting this key derivation information as well. [Zcash transparent key derivation](https://zips.z.cash/zip-0316#deriving-internal-keys), [BIP 32 key derivation](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#implications).

## What else can go wrong?

Generating fresh addresses is only part of making privacy work. The wallet must continue checking them for payments, tracking their spends and reconstructing their history after a restore.

Ordinary transparent lightwallet requests make those checks using readable addresses. The wallet effectively asks, “Show me transactions for A, then B, then C.” The receiving server sees each address and can associate the searches with the same client. Encrypting the connection protects the requests in transit; the server can still read them. [Zcash lightwallet protocol](https://github.com/zcash/lightwallet-protocol/blob/main/walletrpc/service.proto).

That creates a privacy leak beyond what the blockchain already reveals. Separate addresses may appear unrelated on-chain, but sending a batch of address queries to the server tells it that they are all owned by the same user.

## Addressing the “Lookup Leak”

PIR stands for *private information retrieval*: retrieving a selected database record while cryptographically hiding which record was selected. Confirmed transparent activity is divided into block-range shards. Because PIR retrieves records by position, the wallet hashes the address’s payment script locally to calculate candidate positions in the shard’s directory, then retrieves those records using PIR. The server does not learn which positions were selected.

To avoid making private lookups in every range, each shard also provides a compact public activity filter (think [Bloom filters](https://en.m.wikipedia.org/wiki/Bloom_filter)). The wallet downloads these filters and checks its addresses against them locally, without sending its addresses to the PIR server. Each range with 10,000 distinct payment scripts needs roughly 15 KB of filter data. When a filter indicates a possible match, the wallet makes a private lookup.

The records describe confirmed receives and spends. Short histories fit in the initial response; longer histories continue in privately retrieved additional pages. The article’s private-lookup diagram illustrates this flow. The wallet does not submit its addresses as plaintext search terms.

The same history is needed for recovery from a mnemonic. An old address may have received funds that were later spent or shielded. Its current balance is zero, but its history still needs to be retrieved so the wallet knows the address was used. PIR lets the wallet fetch that history without revealing the address it is checking.

Once the wallet has reconstructed its transparent ledger and checked which funds are spendable, it can optionally retrieve more transaction details using PIR. This lookup starts from a transaction ID (txid) the wallet already knows and returns additional details, such as fees and transparent output destinations and amounts—including outputs outside its own address set—without submitting the txid as a plaintext search term. If the optional lookup is unavailable, the recovered activity, balance and spendability evidence remain usable, while the additional details stay incomplete. The article’s diagram shows this as an optional stage after recovery.

This is how PIR enables rotating transparent addresses: it provides the private monitoring and recovery foundation that wallets can combine with fresh address creation. Rotation limits public-key exposure and address reuse. PIR protects the searches needed to manage the resulting address set.

These protections address different risks. Learning that several addresses belong to one wallet does not itself reveal their hidden public keys. The benefits are complementary: rotation reduces exposure to a potential key-recovery attack, while PIR reduces information available for profiling and targeting.

Overall security benefits from addressing each of these exposures. This is yet another example of how Zcash's clever early protocol design and continuous investment in updating the security stack keep it reliable, even in an age of rapid algorithmic improvement.

## Closing Thoughts

Post-quantum-safe rotating transparent addresses are achievable today. The transparent PIR component is rolling out in [Vizor](https://vizor.cash/get), and its experimental deployment can already be tested by toggling "Private queries" in settings. It uses the same conservative lattice parameters documented at [PIR security parameters](https://zakura.com/engineering/pir-security-parameters/).

**Our team plans to bring full post-quantum safety to transparent pools with hash-based signatures in January.**

---

Canonical HTML version: https://zakura.com/engineering/transparent-pir-rotating-addresses/