EIP-5630: Encryption and Decryption

[firnprotocol]

@Oli-art

Receivers should not have to do any dedicated action on-chain like posting their public key on a ENS, as it would be a massive barrier for the protocol. I’m sure other usecases for this EIP feel the same way. Is it possible to get the key from a transaction signed by the receiver in the past?

yes, it is possible. this fact is made explicit in the latest version of the EIP; see the below direct quote:

On-chain public key discovery. Our proposal has an important feature whereby an encryption to some account can be constructed whenever that account has signed at least one transaction. Indeed, it is possible to recover an account’s secp256k1 public key directly from any signature on behalf of that account.

@Oli-art

If so, I would like to collaborate on an MVP to showcase both EIP-5630 and EIP-7017 so as to get wallets to implement them.

cool, would be happy to collab.

[firnprotocol]

btw, upon reviewing @Oli-art’s EIP-7017, I think i can clarify its role, for the edification of this thread. cc. @friedtrout @Weiji

that EIP standardizes how the actual blockchain should be used as a distribution mechanism for messages, over and above how they actually get encrypted (that’s our job). specifically, it describes a way to pack encrypted messages into events, and signatures for these events, so that consumers can subscribe to them.

this very problem—i.e., on-chain distribution—has come up a few times in the above thread, so i am glad to see that @Oli-art has proposed a solution for it. In my view, our EIPs are very complementary, and we should put our full support behind EIP-7017.

[firnprotocol]

glad to hear it—let us know how we can help.

[firnprotocol]

@yisiliu

However, I don’t actually think these messages need to be stored in a smart contract. Instead, a standardized payload format is needed to be defined and we can easily include them in the data field of each transaction to minimize the gas cost.

btw, @yisiliu, it looks like i may have misunderstood your messages above. the idea of @Oli-art—and it seems your idea too—is to use a smart contract for delivery, but not for storage. i.e., the smart contract handles routing, mechanized using event subscriptions. but all the message info lives in calldata/event logs alone, and never in contract storage.

so my message above didn’t make sense; sorry. i agree with you that this is the right approach!

[jdbertron]

Can we please get an update on the status of this proposal ? Like RequestNetwork, I’m also using the technique MantisClone spelled out to encrypt local cookies, but now that eth_getEncryptionPublicKey is deprecated, I’m not sure what to do. Even using the node crypto library, you would still need some way to encrypt using the wallet. The EIP page says it’s stagnant.

[firnprotocol]

@SamWilsn can you please advise on the “Stagnant” status? what is the proper way to get it out of that status? thanks in advance.

@jdbertron the main thing we need is for community members to apply pressure on wallets (e.g., MetaMask) to actually implement this… you are very welcome to raise an issue on any wallet.

[SamWilsn]

@firnprotocol

can you please advise on the “Stagnant” status? what is the proper way to get it out of that status? thanks in advance.

Open a pull request to change the status back to whatever it was previously.

[jdbertron]

Thanks. Done: MetaMask/core/issues/4509

[edyth933]

Which wallet providers have already implemented this?