From d3e70c3dceebdc25ab2a9d38f48c5b9253c659fd Mon Sep 17 00:00:00 2001
From: etemiz <etemiz@consala.com>
Date: Tue, 21 Mar 2023 21:38:13 -0500
Subject: [PATCH] NIP-101 Fix for stolen secret key problem

NIP-101 Fix for stolen secret key problem
---
 101.md | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 67 insertions(+)
 create mode 100644 101.md

diff --git a/101.md b/101.md
new file mode 100644
index 00000000..73bf6062
--- /dev/null
+++ b/101.md
@@ -0,0 +1,67 @@
+NIP-101
+=======
+
+Fix for stolen secret key problem
+----------------------------------
+
+This NIP defines a solution that may be implemented by clients and relays for stolen keys problem. Lets say owner O owns two keys, uses A actively but wants to switch to B in case A is stolen.
+
+
+- Secret key A sets a 'successor' pub B by storing an event with a new kind in a relay. Kind may be 101.
+
+```json
+{
+    "id": "...",
+    "pubkey": ".......AAAA........",
+    "created_at": 1669695536,
+    "kind": 101,
+    "tags": [
+        ["successor", "...........BBBBBBBBB......."]
+    ],
+    "content": "",
+    "sig": "...signature.by.AAAA........"
+}
+```
+
+
+- In case secret key A is stolen, the owner of A uses secret B to start simply creating notes of any kind, or create one event with a new kind that says "B is now succeeding A". First option is easier, second is more elegant.
+
+
+```json
+{
+    "id": "...",
+    "pubkey": ".......BBBB........",
+    "created_at": 1769695536,
+    "kind": 1,
+    "tags": [],
+    "content": "Hey I am the owner of AAA and my secret key was stolen. This is my new account",
+    "sig": "...signature.by.BBBB........"
+}
+```
+
+OR
+
+```json
+{
+    "id": "...",
+    "pubkey": ".......BBBB........",
+    "created_at": 1769695536,
+    "kind": 102,
+    "tags": ["p",".........AAAAAAAAAA..............."],
+    "content": "Hey I am the owner of AAA and my secret key was stolen. This is my new account!",
+    "sig": "...signature.by.BBBB........"
+}
+```
+
+
+- Clients see B is active and show a warning that A is now stolen and B is the new one. Clients update the follows.
+
+- Relays MUST block 101 events that are older than X days for this to work properly.  X may be 7.  Clients MUST fetch ONLY the first 101 from a relay that supports this.
+
+
+What will happen if only a few relays implement this NIP?
+---------------------------------------------------------
+
+The attacker will use secret A to create a 101 with an older created_at. Clients will think the successor of A is actually was C..
+
+The clients will see both B and C coming from relays. At this moment the client may choose to 'honor' the relays that implemented this NIP and choose B as the successor instead of C.