Storage of SECP256k1 public keys in ENS

[Arachnid]

This EIP defines a resolver profile for ENS that permits the lookup of SECP256k1 public keys. This is necessary in order to facilitate ENS lookup for applications such as Whisper.

[gluk256]

This is not suitable for Whisper as long as there is no mechanism to prevent involuntary loss of key/name.

[Arachnid]

@gluk256 Can you expand on that so that people who weren't privy to our conversation have some context?

[gluk256]

It will be a big disaster for Whisper project in general and for individual people in particular, if the key/name would change without consent of the previous owner. The reason for this is quite obvious, but of course I will be happy to answer any specific questions.

[0xc1c4da]

In Status we inject a child derived key in a HD wallet into Whisper, so we have the ability to recover. in the Whisper gitter channel there were also discussions and agreement to natively support adding keys into the Whisper memory store.

Nevertheless I'm not sure why storing SECP256k1 public keys in ENS should be blocked by how Whisper currently functions, when this proposals applications are broader?

[Arachnid]

As I outlined on our call, I believe this is a red herring:

• Any name system that requires names to be updated is vulnerable to issues relating to change of ownership.
• Systems such as Whisper where changes of ownership are important events should handle this appropriately regardless of the system, rather than relying on names never changing ownership.
• Mechanisms are available in ENS to allow you to react to these changes; the best in my opinion is to store the owner of a name on first lookup, and check that owner each time you look up a user's public key. Any change in owner can be reacted to appropriately by either prompting the user or just removing the contact and requiring them to readd them.

[gluk256]

@Arachnid it seems you are deliberately trying to blur the difference between voluntary and involuntary change of ownership. I am not talking about "issues relating to change of ownership", I am just saying that any possibility of COERSIVE change of ownership is absolutely not acceptible for Whisper.

[Arachnid]

@Arachnid it seems you are deliberately trying to blur the difference between voluntary and involuntary change of ownership.

No, not at all; I'm trying to point out that you can't eliminate involuntary transfer of ownership with a name system that has permanent names. No name system will protect someone who loses their laptop on a train, for instance.

I also find it disingenuous that your definition of "coercion" includes "I forgot to renew my domain", but excludes "someone threatened to break my kneecaps unless I gave them my domain".

[gluk256]

By "disingenuous" you probably mean that I pretend not to know about criminals, torture and related risks? You probably wonder, why I am trying to protect users from the vulnerabilities of our system, but do not care so much about criminals and torture? Well, because it is not in my power to protect the users from criminals. But it is in my power, and indeed my responsibility to fix the known vulnerabilities in our system.

[Arachnid]

No, I'm just critiquing your use of the word "coercion" to mean something that does not mean what most people would associate with the word. When you say "coercive change of ownership" and that includes things such as someone forgetting to renew their name, but excludes things that most people would construe as coercion, that is misleading.

[Arachnid]

This is a courtesy notice to let you know that the format for EIPs has been modified slightly. If you want your draft merged, you will need to make some small changes to how your EIP is formatted:

• Frontmatter is now contained between lines with only a triple dash ('---')
• Headers in the frontmatter are now lowercase.

If your PR is editing an existing EIP rather than creating a new one, this has already been done for you, and you need only rebase your PR.

In addition, a continuous build has been setup, which will check your PR against the rules for EIP formatting automatically once you update your PR. This build ensures all required headers are present, as well as performing a number of other checks.

Please rebase your PR against the latest master, and edit your PR to use the above format for frontmatter. For convenience, here's a sample header you can copy and adapt:

---
eip: <num>
title: <title>
author: <author>
type: [Standards Track|Informational|Meta]
category: [Core|Networking|Interface|ERC] (for type: Standards Track only)
status: Draft
created: <date>
---

[axic]

@Arachnid are you still pursuing this ERC?

[futjrn]

so what's the status here @Arachnid ? im sure we could lend a hacky hand to pursue as it would be opportune for Herc user experience

[axic]

@Arachnid are you still considering this to be merged? If not, can you close both this and #620 ?

[axic]

Needs to be filled out.

[axic]

Need to be lowercase.

[axic]

@Arachnid are you still pursuing this?

[github-actions]

There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.