Summary
Add a local alias book exclusively for Silent Payment addresses, allowing users to associate a human-readable name with every sp1... they want to reuse as a recipient.
Motivation
SP addresses are ~117 characters in bech32m and visually indistinguishable from each other. When someone sends you their sp1..., or you obtain it from a website or any other medium, there is currently no way in Sparrow to:
- save it under a name ("Alice", "Bob")
- verify at a glance that the address pasted into Send matches the one stored months ago
- avoid having to request or look it up again each time
Why this does not overlap with existing solutions
vs. issue #511 (closed): the stated reason for closing was "encourages address reuse, unconditionally bad". That argument does not apply to SP by design: the sender derives a fresh output on every payment from the same sp1.... There is no onchain address reuse.
UX benefit
A local alias reduces the risk of sending to the wrong destination: instead of comparing two near-identical sp1... strings, the user picks "Alice" from a list and confirms the recipient is correct before signing.
Proposed minimum scope
- A "Silent Payment Contacts" tab/section inside the wallet (SP wallets only)
- Basic CRUD: add, rename, delete
- Autocomplete in the Pay to field of the send dialog when the user starts typing an alias
- Persistence inside the wallet file, with an optional password-based encryption option
Summary
Add a local alias book exclusively for Silent Payment addresses, allowing users to associate a human-readable name with every
sp1...they want to reuse as a recipient.Motivation
SP addresses are ~117 characters in bech32m and visually indistinguishable from each other. When someone sends you their
sp1..., or you obtain it from a website or any other medium, there is currently no way in Sparrow to:Why this does not overlap with existing solutions
vs. issue #511 (closed): the stated reason for closing was "encourages address reuse, unconditionally bad". That argument does not apply to SP by design: the sender derives a fresh output on every payment from the same
sp1.... There is no onchain address reuse.UX benefit
A local alias reduces the risk of sending to the wrong destination: instead of comparing two near-identical
sp1...strings, the user picks "Alice" from a list and confirms the recipient is correct before signing.Proposed minimum scope