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.

Sign up for GitHub

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

Jump to bottom

Zebra Client RFC: add mandatory sweep fast startup option #1969

Merged
merged 1 commit into from
Apr 1, 2021
Merged

Zebra Client RFC: add mandatory sweep fast startup option #1969

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions book/src/dev/rfcs/0009-zebra-client.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -296,6 +296,20 @@ Supporting a wallet assumes risk. Effort required to implement wallet functiona
# Future possibilities
[future-possibilities]: #future-possibilities

- mandatory sweeps for legacy keys
- blazingly fast wallet startup, to match `zebrad`'s blazingly fast sync
- generate unified address from a new seed phrase (or one provided by the user)
- user can just backup seed phrase rather than a set of private keys
- handles arbitrary keys from `zcashd` and other wallets, even if they weren't generated from a seed phrase
- handles Sprout funds without `zebra-client` having to support Sprout balances
- startup is incredibly fast
- sweep takes a few minutes to be confirmed
- scanning the entire chain could take hours
- if we know when the seed phrase was created, we can skip millions of blocks during scanning
- sweeps can also be initiated by the user for non-linkability / performance / refresh
- sweeps should handle the "block reward recipient" case where there are a lot of small outputs
- initial release could support mandatory sweeps, and future releases could support legacy keys

- split `Client` component into subprocess
- this helps somewhat but the benefit is reduced by our prexisting memory safety, thanks to Rust
- not meaningful without other isolation (need to restrict `zebrad` from accessing viewing keys on disk, etc)
Expand Down