Ah I misunderstood then, I thought it was a generic stealth address EIP with contract wallet support as part of it. But I see now the actual EIP title is “Stealth addresses for smart contract wallets” and not “Stealth addresss wallets” as shown above. Though that raises the question: why limit the EIP to just contract wallets?
Could you expand more on the rationale for preferring generateStealthAddress
over something like the StealthKeyRegistry
? It does seems more simpler and flexible to have the pubkeys stored outside of the wallet since it doesn’t require upgrades to each contract wallet implementation. This also makes it easier to allow someone to set keys on your behalf—the current registry’s setStealthKeysOnBehalf
only supports EOAs, but you can imagine extending it to support EIP-1271.
With either approach, a registry contract or generateStealthAddress
you locally generate the stealth address anyway.
A few things worth considering based on how StealthKeyRegistry
works:
- By storing a compressed pubkey as
bytes32
instead of the full key asbytes
, you cut down from 2-4 slots (depending on how you choose to encode the full pubkey) to 1 slot. To use just one slot, the prefix can be a key in a mapping so it doesn’t actually need to be stored, and a getter method checks the slots of each prefix and returns the nonzero one. - Viewing keys. The
StealthKeyRegistry
supports storing two keys: a spending key and a viewing key. Users can give the viewing key to a trusted third party / have it live on a server and scan for funds. If the key is compromised, you lose privacy, but not your tokens, since withdrawals require the spending key. We generate stealth addresses a bit differently (sender also generates a random number) to help support this. With compressed keys, this only needs 2 slots, with uncompressed keys you’d need 4-8 slots.
Yep, this is how Umbra behaves too! This requires two elliptic curve multiplications: one to compute the shared secret, and a second to compute the stealth address. My understanding (which could be wrong) is that computationally elliptic curve multiplication is the slowest operation involved here. Using view tags replaces one of these with a hash and should help reduce scanning time.