I proposed this in March. Would be neat if there was a more elegant/smooth way to do it:
——
Subject: Suggestion on a method to ensure continuity of your identity if your nsec is ever compromised, without relying on 3rd party verification
Problem: Unless your Nostr npub is tied to an external identity (ie you have a podcast, website, twitter handle, etc) that can be used to re-validate your identity, compromise of your nsec means there is no reliable way to confirm that another npub is actually yours. You can’t use the old keys to confirm its you using the new keys because it could be anyone using your compromised key to pose as the new you.
Solution: I think a simple way to solve this is to pre-verify that you own a particular npub (a set of backup keys) that can be used in the future to reestablish your identity. In the event your nsec in compromised at a future time, you can use the uncompromised backup nsec to point people to your new pubkey.
Example sequence of events:
Event 1: Publish note from npub1: “npub2 is my backup npub. I confirm I own it and will only use it to inform of my new npub3 in the future if nsec1 is compromised”
Event 2 (future/eventual possibility): nsec1 is accidentally compromised, user initiates switch protocol
Event 3: publish note from npub2: “npub1 is compromised, I am moving to npub3 which is___”
Event 4: publish note from npub1 (compromised but followed by others) and npub3: “I am back on Nostr. You can confirm npub3 is a continuation of npub1 by referencing npub1 note ___ and npub2 note___. Please follow me at npub3 and stop following me on the compromised npub1” No one else can use npub1 to claim a fake new account because they can’t publish to npub2 and you can use npub2 to deny any imposters claims.
Conclusion: Not super elegant but it works without relying on 3rd parties like twitter accounts. Obviously your nsec2 needs to be kept away from all systems that use nsec1 so it doesn’t get compromised in whatever compromised nsec1.
That wouldn’t work; you need anchoring to something that can’t be trivially reordered. I am proposing to use NIP-03 stamping for event ordering.
D’oh!
I guess I’m not technically competent enough to know that you’d be able to reorder what was previously published on others relays. I didn’t think fully deleting or changing past notes was fully possible on this protocol.
Is that even true if I ran my own relay?
Same, confused about relays
Want good relays
Then you could hash everyone’s backup npub using a merkle tree and publish the final/top level hash to the Bitcoin blockchain a la open timestamps?