fluidkey

Haven't seen any public conversation on it yet, but who's been thinking about privacy preserving receiver address generation/indexing?

Would building bloom filters of receiver addresses over block ranges make sense, as these could be stored in ORAM and have a TEE provide privacy on queries?

Building pods.media to help you collect conversations.

Great point. This has been a debate we had, and a crucial point around even better privacy. So far we favor UX (with ENS returning a different address each time). The big question is: how to keep the same UX with a decentralized ENS Offchain resolver, bringing even better privacy?

Hands-On Privacy | Crafting fluidkey.com - /fluidkey | Builder | Solidity developer | Engineer.

If we don't want to generate sudo-random addresses like we're doing, then we need to store the ephemeral public key associated to a generated address, necessary to retrieve the associated private key. Unless we set up an L2 where secrets are published, we need to coordinate that in a decentralized ENS Offchian resolver

Are name resolution and indexing coupled out of necessity, or only because it means 1 external party holding a view key rather than 2?

Name resolution can be stateless, but has to be fast. Indexing can trade off some liveness by batching, which could increase the anonymity set of recipients as viewed by the indexer.