New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Storage of SECP256k1 public keys in ENS #619

Open
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@Arachnid
Collaborator

Arachnid commented May 1, 2017

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.

@Arachnid Arachnid referenced this pull request May 3, 2017

Closed

ERC: Ethereum Name Service #137

@gluk256

This comment has been minimized.

Contributor

gluk256 commented May 4, 2017

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

@Arachnid

This comment has been minimized.

Collaborator

Arachnid commented May 4, 2017

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

@gluk256

This comment has been minimized.

Contributor

gluk256 commented May 5, 2017

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.

@jarradh

This comment has been minimized.

jarradh commented May 5, 2017

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

This comment has been minimized.

Collaborator

Arachnid commented May 5, 2017

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

This comment has been minimized.

Contributor

gluk256 commented May 5, 2017

@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

This comment has been minimized.

Collaborator

Arachnid commented May 5, 2017

@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

This comment has been minimized.

Contributor

gluk256 commented May 5, 2017

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

This comment has been minimized.

Collaborator

Arachnid commented May 5, 2017

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 comment has been minimized.

Collaborator

Arachnid commented Mar 27, 2018

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>
---
@@ -0,0 +1,50 @@
## Preamble
EIP: <to be assigned>

This comment has been minimized.

@axic

axic Oct 16, 2018

Member

Needs to be filled out.

@axic

This comment has been minimized.

Member

axic commented Oct 16, 2018

@Arachnid are you still pursuing this ERC?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment