Zcash Address Rotation and Private Lookups

An address can expose information in two places: when its public key appears in a spend and when a wallet asks a service to search for its history. Zakura’s new engineering note treats those as separate problems. It combines frequent changes of transparent Zcash addresses with private information retrieval, commonly shortened to PIR.

The rotation part limits continued reliance on a key that has already been shown. A transparent address begins as a hash of its public key, while spending publishes the public key with the signature. Funds moved to another derived address sit behind another hash if that later key has not been exposed through a spend or shared account data.

Creating another address does not require a second seed phrase. A wallet can derive a sequence of key pairs from the same seed and recover that sequence from the same backup. Spending from one address reveals its own public key; it does not by itself reveal the other derived public keys or the seed.

That separation can be weakened by sharing broader derivation data. Zakura notes that an account extended public key can derive receiving and change public keys. Comparable information may appear in the transparent part of a Unified Full Viewing Key. Protecting those records is therefore part of the same threat model as avoiding repeated use of one exposed address.

Why fresh addresses do not solve lookup privacy

Generating fresh destinations does not remove the need to synchronize a wallet. It must still discover receipts, follow later spends and rebuild earlier activity after a seed is restored. When a light wallet submits each address in readable form, the RPC operator can group those searches even though encryption protects the connection from outside observers.

That association reveals information beyond the public ledger view. Several addresses may have no obvious link on-chain, yet a batch of queries can tell the service that one wallet is monitoring all of them. Address rotation alone can therefore reduce key reuse while leaving an off-chain profiling channel open.

In Zakura’s design, confirmed transparent activity is divided into ranges served as shards. The wallet hashes its payment script locally, calculates candidate positions and retrieves records through PIR. The issuer says the server then handles the retrieval without learning which positions the wallet selected.

Small public activity filters reduce unnecessary private requests. The wallet downloads a filter for a range and tests its addresses locally. Only a possible match leads to a PIR retrieval. Zakura estimates that a range with 10,000 distinct payment scripts would need about 15 KB of filter data, presenting this as a way to keep the preliminary scan compact.

The returned history must include spent and zero-balance addresses, not only current holdings. A restored wallet may need an old receive record to reconstruct what happened before funds were moved or shielded. Once it knows a transaction identifier, the design also proposes private retrieval of details such as fees and output destinations rather than sending that identifier as a readable search.

A checklist for evaluating the proposal

Evaluate the design with two columns in mind. One column is the public chain, where transparent activity stays visible. The other is the conversation between a wallet and its data service. Zakura positions PIR in the second column: it conceals the selected database positions, while leaving the underlying transparent ledger unchanged.

Next examine which keys have already been exposed. A fresh derived address can reduce reuse of the public key revealed by an earlier spend, but sharing an extended public key or related viewing material may expose a larger set of public keys. The benefit depends on both address behavior and protection of derivation information.

Finally distinguish available experiments from future protocol work. Zakura says an experimental transparent PIR implementation can be tested through a Private queries setting in Vizor. It also says its team plans post-quantum signature opcodes for January. A plan and an experimental option are not the same as a completed network-wide deployment or an independently proven security guarantee.

Zakura presents hash-based signatures such as WOTS as an additional spending route in its post-quantum design. Readers should treat claims about post-quantum safety as the issuer’s engineering position and examine later specifications, audits and activation decisions before assuming production protection. The current article is most useful as a map of the privacy problems the design attempts to separate.

• Record which addresses have revealed a public key through spending.
• Treat account-level derivation and viewing data as sensitive key information.
• Check whether a remote service receives literal addresses during synchronization.
• Keep experiments and announced January work distinct from activated protocol protection.

Эта статья носит информационный характер и не является инвестиционной рекомендацией.

admin_wcContributor · World-CryptMore from