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.

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.

I guess stateless is the wrong word, the state is linear in the amount of meta addresses the server knows. The resolver could point to many URLs, and those which a user doesn't trust can return a 5XX (502?) error that says to look at other gateways.

Responding to these requests in a TEE is pretty simple, right?

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