EIP: Global address to pubkey service

[Ethernian]

Forked from GraphQL interface to Ethereum node data - #9 by Arachnid :

@Ethernian

RFE: I would like to have an ability to get a public key for address (without intermediary explicit tx lookup and ecrecover call).

@Arachnid

Sure, that’s possible, but:

1. It would require new index datastructures on disk.
2. It wouldn’t work for transactions sent before the node was fast-synced without changes to the fast-sync protocol.
3. It wouldn’t work for light nodes without changes to the LES protocol.

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?

[Amxx]

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

[Ethernian]

Great!
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.

[Amxx]

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

[Ethernian]

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.

[ssh]

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.

[Ethernian]

@ssh

would let me add accounts of mine which don’t have any eth

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

[Ethernian]

@Amxx

I’ll be at the hackathon in paris next week, maybe this could be a good project

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

[Amxx]

@ssh

would let me add accounts of mine which don’t have any eth.

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 !

[Ethernian]

@Amxx

would let me add accounts of mine which don’t have any eth.

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)?

[Amxx]

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”