Stealth Meta-Address Registry

EIPs
6

It seems there are two questions that we’re blending together:

  1. Given a recipient’s ordinary wallet address, how is the stealth-meta address (SMA) and it’s corresponding private keys derived?
  2. Given a recipient’s ordinary wallet address, what are a sender’s options for sending them funds via a stealth address, i.e. how does the sender compute the stealth address and how does the recipient decrypt Announcement logs?

This ERC provides an answer to question 2 by mapping an address to a scheme ID to an SMA, this way a sender can look up all the scheme IDs available for a recipient and choose one to use. How the SMA was derived for the recipient doesn’t matter much from the sender’s perspective. Given that you know how to find/derive your own private keys, it also doesn’t matter from a scanning perspective.

But it does matter so a new app can help you scan for and withdraw funds—your comment does raise two good questions around this that the ERCs don’t currently address:

  1. Should we standardize the options for deriving an SMA and its private keys from a wallet address?
  2. The registry only supports a 1:1 mapping of address to SMA, but this doesn’t necessarily have to be the case—a user can have multiple SMAs for a given address. Should the ERCs support a 1:n mapping here, or stick with 1:1?

For question 3, we probably should, but this feels like a separate ERC since it’s a different scope. This is arguably not specific to just stealth addresses, as the ERC can answer the generic question of “how to generate app-specific private keys for a user”. Then, all apps and stealth address wallets—even wallets with native stealth address support—can use the same approach. Perhaps it’s something like “Sign this message to generate app-specific private keys for [APP_NAME] on chain [CHAIN ID]. Only sign this message for a trusted client”. (TBD how to robustly expand this to contract wallet users). It would also need to address how to mark a set of keys as compromised and generate new case.

For question 4, it sounds like you want to support a 1:n mapping, but I’d push back that. In my opinion a 1:1 mapping is the most common use case, and I can’t think of a compelling reason to use a 1:n mapping:

  • If a user’s wallet does not have native stealth address support, then to avoid copying private keys into applications, signing a message to generate their keys and provide them to a trusted client to scan for/withdraw funds is the best approach. Signing multiple messages to generate multiple SMAs doesn’t add any privacy benefits (unless keys are leaked, but I don’t think that threat vector should be in scope for the ERCs).
  • If a user’s wallet does have native stealth address support, and does not use the same signature to derive the SMA, then the wallet should expose RPC methods for apps to scan and withdraw funds. If the user wants to migrate to a new wallet that no longer has native stealth address support, they can sign a message to generate new keys and overwrite the old wallet-generated keys in the registry.

Deriving keys for the user in question 1 feels similar to hardware wallet derivation paths: Different apps may have different default derivation paths, and when you connect your hardware wallet to an app, you have to choose one or more derivation paths to show accounts for. It can be similar here, where you have to choose a message to sign, and/or choose to use the wallet’s regular public key, and/or choose an approach to derive it for contract wallets. In any of those cases, an app that wants you to scan for funds can support one or more of these key-derivation approaches, and may ask you choose one more approaches so it knows how to get your keys.