Basic

Address per customer

One key gives many addresses. Give each customer or each order its own address. The shop knows which address got each payment. Outsiders see unrelated addresses.

Use

• a deposit address for each user of an exchange or a game;
• an address for each invoice;
• an address for each place where you publish a donation link.

The address identifies the payment. Thus, the payer can send a payment with no memo, and the shop still finds the order.

Mechanism

full viewing key ──→ diversifier key dk ──→ d_j = FF1(dk, j) ──→ address j
                                      ↑                             │
incoming viewing key ── dk ───────────┴──── j = FF1⁻¹(dk, d_j) ←────┘

1. The shop gives each customer a number j, the diversifier index.
2. The key encrypts j into an 11-byte diversifier d_j.
3. The diversifier and the key give a receiver. The receiver goes in a unified address.
4. A payment arrives. The wallet decrypts the note with its incoming viewing key, one key for all addresses.
5. The wallet decrypts the diversifier of the note to get j again.

Each index from 0 to 2⁸⁸ − 1 gives a valid Orchard address. The wallet scans one time for all addresses. Thus, many addresses cost the same scan work as one address.

The shop keeps a table of j and the customer. The table is the only shop data that this pattern needs.

Limits

• Transparent receivers. A unified address with a transparent receiver shows that receiver on the chain. Use addresses with shielded receivers only.
• Viewing keys. A holder of the incoming viewing key can link all the addresses. Keep the key secret.
• Wallet support. Wallet apps make a new address on request and select the index themselves. A server selects the index with a library such as orchard or zcash_keys.

Demo: a demo shop

The demo uses the orchard crate, compiled to WebAssembly. It makes addresses of the demo shop key from a first index. Copy an address into the second field. The shop key finds the index of the address.