EIP: Global address to pubkey service

Forked from GraphQL interface to Ethereum node data :

I need to know a public key for address to send a encrypted message to recipient. Currently I need to communicate in advance with the recipient to get a pubkey for address. For some use cases like “Stealth transactions” it is discouraged.

As stated before by @Arachnid, default implementation address=> pubkey by clients is not easy.
A simple workaround suitable for many cases could be a trivial contract with a mapping inside deployed at well known address.

Is there such contract address=> pubkey already deployed?
If not: may be we should do it?

1 Like

We had the same discussion in our project and were considering writing such contract.


Please publish it before use to collect public feedback. May be there are more hidden UseCases.

I would glad to see it as a public service.

1 Like

Our approach is pretty simple for now Code is here

If you have any better idea, I’ll be happy to discuss that… I’ll be at the hackathon in paris next week, maybe this could be a good project

1 Like

Yeah! Thank you!

One objection for public discussion:

  • I would let only account owner create/update their own records.

Reason: preventing unexpected hostile deletion/alternation of entries.
It will simplify the contract greatly because the setter logic can be implemented in the default function and getter can be default public accessor.

I’m not sure if that is what you implied but taking a signature as an argument instead of just using the owner of the account that sent the transaction would let me add accounts of mine which don’t have any eth.

1 Like

valid argument. Anyway it could be done in fallback function with pubkey as payload.

I’ll be both at Council and at hackathon. Would you have a talk before hackathon (at Council)?

That was exactly my idea. I beleive at some point most wallets won’t hold any assets (ether/tokens) and will only be used to sign orders that will be relayed (meta transaction) to multisig identity smart contracts. Therefore I think anyone capable of paying a transaction should be able to register a public key for another account (provided it’s done right → computing the address from the key)

In my opinion, the next step is to allow identity contracts’ owners to setup a key for their contract … which could be done in a number of (bad) ways … we have to find the right one !

There is another aspect:
Is someone publish his public key, he commits himself to listen and receive encrypted messages.
Is someone commits my public key, I am not aware of it and thus I will not check it for messages sent to me.

The question is: is sending a encrypted message to address essentially the same use case as sending the payment (which requires no pre-confirmation from owner)?

I guess that is one way of seeing it.

My stance on that was more like “if this account ever participated in a procole that require you to send an encrypted message to it, here is the public key, but that doesn’t imply the account owner will actively be looking for any message”