zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

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:
Jack Grigg 2024-07-16 02:06:18 +01:00
parent e7418d3dd2
commit c24a1514bf
1 changed files with 24 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
zip-0315.rst
View File

@ -25,10 +25,6 @@ Auto-shielding
The process of automatically transferring transparent funds to the most recent
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
The process of automatically transferring shielded funds from older pools to the
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;
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
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
individual privacy, by maximizing the size of the note anonymity set over time.
A shielding transaction is always linked to the transparent addresses it
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
recommendation, except where explicitly noted.
Despite the fact that it is not possible to achieve strong privacy guarantees
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.