mirror of https://github.com/zcash/zips.git
Recommend against opportunistic shielding
The recipient in an opportunistic shielding transaction learns a transparent address that they can assume is associated with the transaction sender. While the transparent protocol does not attempt to hide this information, and it might be learnable from other sources, we don't need to make it easy. Co-authored-by: Daira-Emma Hopwood <daira@jacaranda.org>
This commit is contained in:
parent
e7418d3dd2
commit
c24a1514bf
33
zip-0315.rst
33
zip-0315.rst
|
@ -25,10 +25,6 @@ Auto-shielding
|
||||||
The process of automatically transferring transparent funds to the most recent
|
The process of automatically transferring transparent funds to the most recent
|
||||||
shielded pool on receipt.
|
shielded pool on receipt.
|
||||||
|
|
||||||
Opportunistic shielding
|
|
||||||
The process of transferring previously received transparent funds to the most
|
|
||||||
recent shielded pool as part of a user-initiated transaction.
|
|
||||||
|
|
||||||
Auto-migration
|
Auto-migration
|
||||||
The process of automatically transferring shielded funds from older pools to the
|
The process of automatically transferring shielded funds from older pools to the
|
||||||
most preferred (usually the most recent) pool on receipt.
|
most preferred (usually the most recent) pool on receipt.
|
||||||
|
@ -121,13 +117,32 @@ Long-term storage of funds
|
||||||
It is RECOMMENDED that wallets only hold funds as shielded in the long term;
|
It is RECOMMENDED that wallets only hold funds as shielded in the long term;
|
||||||
that is, if a wallet supports receiving transparent funds (or supports
|
that is, if a wallet supports receiving transparent funds (or supports
|
||||||
importing a seed from another wallet that might have done so), then it SHOULD
|
importing a seed from another wallet that might have done so), then it SHOULD
|
||||||
either auto-shield or opportunistically shield such funds by default.
|
auto-shield such funds by default.
|
||||||
|
|
||||||
Following this recommendation improves both collective privacy and the user's
|
A shielding transaction is always linked to the transparent addresses it
|
||||||
individual privacy, by maximizing the size of the note anonymity set over time.
|
spends from. This can cause undesirable information leaks:
|
||||||
|
a) if there are multiple transparent addresses, they will be linked to each
|
||||||
|
other;
|
||||||
|
b) a link between the input transparent address(es) and the payment will be
|
||||||
|
visible to the recipient(s), or to any other holder of an Incoming Viewing
|
||||||
|
Key for the destination address(es).
|
||||||
|
|
||||||
The remainder of this specification assumes a wallet that follows the above
|
Despite the fact that it is not possible to achieve strong privacy guarantees
|
||||||
recommendation, except where explicitly noted.
|
from *any* use of transparent addresses, it is undesirable to reveal this
|
||||||
|
additional information. In particular, issue b) motivates ruling out the use
|
||||||
|
of "opportunistic shielding", i.e. shielding previously received transparent
|
||||||
|
funds as part of a user-initiated transaction.
|
||||||
|
|
||||||
|
Wallets SHOULD NOT auto-shield from multiple transparent addresses in the
|
||||||
|
same transaction, and SHOULD NOT use opportunistic shielding.
|
||||||
|
|
||||||
|
Following all of the recommendations in this section improves both collective
|
||||||
|
privacy and the user's individual privacy, by maximizing the size of the note
|
||||||
|
anonymity set over time and minimizing the potential linkage of shielding
|
||||||
|
transactions to other transactions.
|
||||||
|
|
||||||
|
The remainder of this specification assumes a wallet that follows all of these
|
||||||
|
recommendations, except where explicitly noted.
|
||||||
|
|
||||||
A wallet MAY allow users to disable auto-shielding.
|
A wallet MAY allow users to disable auto-shielding.
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue