From c24a1514bf8ffff091d0505066b0bd0fd17eccfc Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Tue, 16 Jul 2024 02:06:18 +0100 Subject: [PATCH] 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 --- zip-0315.rst | 33 ++++++++++++++++++++++++--------- 1 file changed, 24 insertions(+), 9 deletions(-) diff --git a/zip-0315.rst b/zip-0315.rst index 6abe6f9a..5b93a331 100644 --- a/zip-0315.rst +++ b/zip-0315.rst @@ -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.