SNIP-20/25 upgrade ( adress shielder ) discussion

Secret Contracts and Secret Apps
1

Hi everyone,

I got an idea to create an address shielder to accept SNIP-20/25 tokens, after a discussion with @SecretSaturn on ETHRome I decided to publish it, I would like to start a discussion for this potential upgrade.

Abstract:
One of the problems of receiving SNIP-20/25 tokens is the visibility of the receiver’s address by the sender, this can lead to the disclosure of certain sensitive information ( such as the number of SCRTs stacked, participation in governance, … )
The goal is to eliminate this problem by sharing an encrypted address that can only be decrypted inside the contract, so the sender never knows what address the tokens ( e.g. sSCRT ) are sent to.

How:
My original concept ( I will be glad if it will be extended ) was to create a standardized decryption key ( for decentralization it can be generated by SecretVRF ) which will be used to decrypt the recipient’s address, the encryption key will then be public and will be used to encrypt the classical secret1… address ( encryption will be done by the recipient )

Add a heading (8)
Add a heading (8)1920×1080 112 KB

What if my shielded address is linked to the real one?
By creating a standardized public encryption key, we can ensure that the recipient will not be forced to pay gas.

The problem of a single standardized encryption key can be a potential doxx, the solution to this problem can be either to add the ability to generate the encryption and decryption key itself ( you have to pay gas ), the other option is to create multiple pairs of encryption and decryption keys ( gas-less ) which the frontends could randomly select.

Problems:

  • Each SNIP-20/25 would have to be upgraded to support the address shielder

  • Need to ensure that each SNIP uses the same decryption key, otherwise the receiver would have to share a different address for each asset

  • There will be a problem with implementation in wallets ( it is very unlikely that wallets like Keplr will ever add support for this solution )

  • The decryption process will make it slightly more expensive to send tokens

FaQ:

Q: Is the goal to eliminate sending to classic addresses?
A: No, the goal is to add another option for accepting payments

Q: Will every SNIP automatically support Address Shielder
A: No, every SNIP that wants to add support will be forced to upgrade their contract

Q: Will Address Shielder protect the sender
A: No, the sender will still be doxxable ( this problem would be hard to solve, because TX is sending onchain at a given time )

I will be glad for comments, opinions, improvements, …, and support from SLabs.
Have a good discussion :slight_smile:

3 Likes
2

Unfortunately this design folds to spicy printf also (since the decrypted address gets written to, access patterns leak recipients)–youd need to bucket multiple addresses together under one hashmap key to solve this (or go full oram)

4 Likes
3

Thanks @Jiricepelka for this write-up! It would be awesome to have shielded recipients in the SNIP-20 standard. I agree with @Avret that this doesn’t help against a spicy print attack, but these things are orthogonal IMO and can be addressed with different solutions. I see this as a way to protect the recipient’s address from the sender, and ORAM as a way to protect against a spicy print attack.

2 Likes
4

This is exactly the reason I wanted to open the discussion, is there any way to protect the recipient’s address against decryption after computation? Would it be possible to make a major change to SNIP-20 that would eliminate this problem?

in the case of this computation, would it be possible to keep the real address encrypted and let the sender see only the encrypted address?