Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable address rotation for Zashi #38

Open
nuttycom opened this issue Apr 8, 2024 · 2 comments
Open

Enable address rotation for Zashi #38

nuttycom opened this issue Apr 8, 2024 · 2 comments
Labels
P-high High priority
Milestone

Comments

@nuttycom
Copy link
Contributor

nuttycom commented Apr 8, 2024

Is your feature request related to a problem? Please describe.

Reusing addresses can be harmful to a user's privacy, because counterparties can compare data to get a more complete view of a user's behavior.

Describe the solution you'd like

Each time the user shares a diversified address with a counterparty, or when a previously-un-seen diversifier index is detected in wallet recovery, that address is marked as used and will not be shown again as a receiving address for the wallet (modulo possibilities related to the "reverse address book" functionality discussed below.)

One possible feature would be to make it possible to request an address for a specific named counterparty. This would enable a sort of "reverse address book" that makes it possible to identify which counterparty an address corresponds to when receiving a transaction. This was suggested here

@nuttycom nuttycom added this to the Zashi 1.1 milestone Apr 8, 2024
@true-jared true-jared added the P-high High priority label Apr 16, 2024
@true-jared true-jared modified the milestones: Zashi 1.1, Zashi 1.2 Apr 17, 2024
@daira
Copy link
Contributor

daira commented Apr 27, 2024

Note that although the description focuses on diversified addresses, the effect will also be to generate distinct Transparent P2PKH Receivers, because UAs generated according to ZIP 316 use the same index within an account for Sapling, Orchard, and P2PKH.

@daira
Copy link
Contributor

daira commented Apr 29, 2024

As @nuttycom points out, to maintain the greatest possible unlinkability (subject to other parties' behaviour), UTXOs received on different transparent addresses need to be tracked separately and not conmingled when they are shielded. This also makes the assumption that Zashi does not directly support transactions that have both transparent inputs and transparent outputs, i.e. it continues to require shielding of all received transparent funds before they can be further spent. (The implementation of ZIP 320 in Zashi will not contradict this, because it will always send via a distinct ephemeral t-address.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P-high High priority
Projects
None yet
Development

No branches or pull requests

3 participants