# ZIP 315 draft

Definitions:
* Auto-shielding: Transparent funds are automatically transferred to the most recent shielded pool on receipt.
* Auto-migration: Shielded funds from older pools are automatically transferred to the most pool on receipt.
* TODO: add definitions of opportunistic shielding and migration.

Auto-shielding MUST be one of:
* "must opt in or out" (zcashd will do this -- i.e. refuse to start unless the option is configured), or
* always on.

Allowed transfers:
* Sprout -> transparent or Sapling
* Sapling -> transparent or Sapling or Orchard
* Orchard -> transparent or Sapling or Orchard
* if auto-shielding is off:
* transparent -> transparent or Sapling or Orchard

Wallets MUST report at least separate shielded and transparent balance.

If auto-shielding or auto-migration is off, then wallets SHOULD report separate balances for each shielded pool and for transparent balance.

(If the wallet never supports a given pool, it can obviously omit balances for that pool.)

If auto-shielding is on, transparent funds should be reported in "balance unavailable to spend".

If no auto-migration, if you can satisfy a transfer request to Sapling from your Sapling funds, do so.

The user's consent is needed to reveal amounts. Therefore, there should be per-transaction opt-in for any amount-revealing transfer.
* there may be a compatibility issue for amount-revealing cross-pool txns that were previously allowed without opt-in

Don't automatically combine funds across pools to satisfy a transfer (since that could reveal the total funds in some pool).

In order to maintain the integrity of IVK guarantees, wallets should not generate unified addresses that contain internal receivers, nor expose internal receivers (such as those used for auto-shielding and change outputs) in any way.

Open questions:
* should there be an auto-migration option from Sapling to Orchard?

# str4d notes

If we want to have both automatic and opportunistic shielding, and keep the two indistinguishable, then we can't auto-shield when the transparent balance reaches some threshold (otherwise opportunistic would either never be used, or would be identifiable when it uses the balance below the threshold).

Instead, a proposition: we define a distribution of "time since last payment to the address" from which we sample the time at which the auto-shielding transaction will be created. This distribution is weighted by the balance in the address, so as more funds accrue, the auto-shielding transaction is more likely to be created.
- It ensures that all funds will eventually be auto-shielded, while preventing fee-dusting attacks (where dust is sent in order to repeatedly consume fees from the wallet), as the auto-shielding transaction is not directly triggered by payment receipt.
- If the user makes a shielding transaction in the meantime, we opportunistically shield, without it being clearly not an auto-shielding transaction.
- If a wallet is offline for a long time, then it would likely auto-shield as soon as it finishes syncing. This maybe isn't enough to reveal that the wallet came online, except that it _might_ result in auto-shielding transactions for multiple transparent addresses being created at the same time. So we might want to special-case this?

Properties we want from auto-shielding:
- Auto-shielding transactions MUST NOT shield from multiple transparent receivers in the same transaction.
- Doing so would trivially link diversified UAs containing transparent receivers.

Properties we want from auto-migration:
- Receipt of a shielded payment MUST NOT trigger any on-chain behaviour (as that reveals transaction linkability).

Both auto-shielding and auto-migration are time-triggered actions, not receipt-triggered actions. An auto-shielding or auto-migration transaction MUST NOT be created as a direct result of a payment being received.

Both of these are opportunistic: if the user's wallet is making a transaction in which one of these actions would occur anyway, then the wallet takes the opportunity to migrate as much as it would do if it were generating an autoshielding transaction. This both saves on a transaction, and removes the need for any kind of transparent change address within UAs.

TODO: what pool should change go to?
* Proposal: the most recent pool already involved in the transaction.