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.