Content
@
https://warpcast.com/~/channel/fluidkey
0 reply
0 recast
0 reaction
Drew Fisher
@drewf.eth
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?
1 reply
1 recast
1 reaction
MeTony 💧🔑
@metony
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?
1 reply
0 recast
1 reaction
Drew Fisher
@drewf.eth
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.
1 reply
0 recast
1 reaction
MeTony 💧🔑
@metony
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
2 replies
0 recast
1 reaction
MeTony 💧🔑
@metony
To be more precise on your question: name resolution cannot be stateless as Stealth Addresses are always difference cause each one is generated from a different shared secret, that needs to be know by the address owner (so stored) in order to reconstruct the private key
0 reply
0 recast
1 reaction
Drew Fisher
@drewf.eth
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?
1 reply
0 recast
1 reaction
