ENS Payment Privacy

🏛️ Public Goods General Discussion
#1

Receiving payments to human-readable addresses is part of the attraction and core value propositions of using ENS names as a universal web3 identity. Today, those payments are made to static addresses written into the text records associated with ENS names. Changes to those addresses are expensive and require an on-chain transaction and all current and past text records are in the immutable, historical record of the blockchain forever.

I would like to start a discussion with the community and get a temperature check on the idea of exploring alternatives to static payment addresses, such as allowing users to set an optional outside server (and creating the voluntary standards to support it) that would allow wallets that support the standard to resolve the server location from the ENS name and request payment addresses using existing HD wallet technology in order to provide greater payment privacy while using an ENS identity. Static payment addresses would remain for users not interested in the additional privacy features and could also be used as a fall-back in the event that no response was received from the payment server.

Note, I am not proposing that we discuss the technology behind the payment servers themselves, but assuming that such a tool was possible and that ENS provided the capability to resolve the connection details to them, I think it would really spur some innovation in that area. I also think that greater payment privacy is part of the long-term success of users and businesses adopting ENS names to be used as universal Web3 identities.

EDIT: This isn’t a claim that this would provide absolute protection of user privacy, it would just make it mostly infeasible for a casual observer to view a user’s payment history, but a malicious actor wanting to snoop could still do so.

4 Likes
#2

Are you talking about ZK rollups? If so implementing as an user option would foster a broader adoption of ENS. People want privacy options that are outside the current payment infrastructures. I believe this is the future. If this is what you are talking of?

3 Likes
#3

No, I wasn’t thinking in that direction, but it sounds interesting and I’d like to learn more. I was talking about having a server address in the ENS text records that a wallet could ping to receive back a payment address.

That keeps the payment address between the payer and payee and doesn’t allow casual snoopers to just check a user’s payment address in the ENS records. The payment addresses would be kept out of the text record entirely if a user opted for this feature.

1 Like
#4

The ability to set external url is part of CCIP read standard but that’s not designed for privacy purpose but rather for scalability purpose. I am not sure how this approach preserve privacy as people can trace the transaction histories between names unless you have proxy address between (as what most CEX does) or mix with multiple transactions (which is what Tornado does).

2 Likes
#5

It doesn’t guarantee absolute privacy, but it would require effort to snoop on a user’s payment history.

The process would be a (hypothetical) future compatible wallet using the developed standard resolving the payee server location from the ENS records. Then, the wallet pings the payee server to retrieve a payment address. The payee server, in theory, is running software that operates just like an HD wallet by returning the next available, unused payment address to the wallet in order to allow the payer’s wallet to complete the transaction.

In this scenario, the payer knows the address they sent a payment to, but they do not know any other address other payers have sent payments to. And any third party, casual observers would have no knowledge of anyone’s payments just by looking at the ENS record.

This could be foiled with a little effort by a malicious observer creating a bot that regularly pings the payment server listed in the ENS record, obtains next available address, and makes no payment but logs it instead. But this is a risk to be mitigated by the wallet software provider, not ENS.

#6

I hear what your are proposing to the community. Your thoughts are valid and without doubting, you are not the first to think about this aspect of anonymity and blockchain identity protection. That being said, the brilliant minds of those who have developed this tech have already implemented solutions for what you seek in of itself.

Anonymity exposure on the blockchain is your responsibility. You have the option to on ramp your fiat and off ramp your fiat in whichever way you so please. The availability of those services are more abundant today than yesterday. The solution to this is already in your hands.

You can create a new wallet with a new address, you can register a new name or not register a name at all. Names have more of a chance to be recognized than an 0x hash. Funds coming in to your wallet from a hot wallet are pretty anonymous. You will always expose the data to the blockchain at some point and both the caller and sender will be published to a certain degree. Essentially that is the idea of the blockchain–accountability and transparency. I can sit here and make new addresses all day and call transactions from any address and nobody will know who it is. If these sort of privacy ideas are implemented more and more on top of each other then we are kind of like back to square one with the problems we have now with currency fraud, laundering and so on and so forth. Use the tools you have right now. It can be more anonymous than you think. Other than that, I’m not sure what you are proposing. Just make a new address.

1 Like
#7

I disagree. What you’re suggesting is sufficient for those who want to remain private, anonymous users of Ethereum, but this is a public goods discussion. We need ways for public individuals, entities, institutions, etc. to be able to adopt ENS names and conduct financial transactions using those names without sacrificing privacy.

A company won’t accept payments at their .eth address if they can’t keep sales and revenue data private and that will limit its adoption and use as a payment address.

#9

Couldn’t a non-static payment address be achieved through an on-chain protocol like
Umbra.cash?

I would much prefer integration with something trustless like that instead of referring to a “centralised-web” method of address generation, which could be prone to attacks such as hijacking to redirect funds.