ERC721 Extension for zk-SNARKs

[mds1]

@Nero_eth

The goal of this EIP is the pure implementation into SM wallets so that it depends only on the upgradable SM wallet which assets to support

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?

@Nero_eth

Therefore a standardized generateStealthAddress function is implemented. This EIP won’t have a contract acting as a registry but put the publicly visible public keys directly into the individual SM wallets. This then allows senders to locally execute the generateStealthAddress function on the recipient’s wallet to retrieve a stealth address (for every kind of assets possible).

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.

@Nero_eth

Check out the latest version of this EIP?

A few things worth considering based on how StealthKeyRegistry works:

• By storing a compressed pubkey as bytes32 instead of the full key as bytes, 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.

@Nero_eth

In the current implementation, recipients would only have to compare the computed (…derived from S) stealth Address with the address logged in the same topic to check if they were the recipient. This can be done fully off-chain. A single, immutable contract can be used to broadcast the Event.

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.