1. Set a spare pubk B using secret key A
2. In case the secret key A is stolen, use secret B to publish a special event that says "B is now the secret key replacing A"
3. Clients show a warning that A is stolen and B is the new one. Clients update the follows. Relays can't do much..
Super interesting, hope others comment on the feasibility of this
This. A revoke key. That allows old key to be marked as old a set a new one.
And possibly copy everything from the old key to the new one, including followers and following.
The problem with having a backup key to revoke your private key is that you have to keep it somewhere. We're already discussing an event where your private key has been stolen. Chances are you kept your revoke key in the same place as your private key: on the computer that was just hacked.
Everyone will say, "Nooo, we'll keep the revoke key in an super-duper extra-special place where it will be safe!"
But that's what they were supposed to do with the original private key, and didn't.
The problem lies with the users, not the technology.
I get what you're saying and you're right that the problem is people, but you need not only a way to delete your old npub but also claim your new npub, the revoke key could be a password chosen by you, like in bitcoin, you can have your seed phrase+pass. Another option could be social recovery but you would have to prove it out of band, and not everyone has known people in the network.
What blocks the attacker to go back in time and publish a second pubk B? How do you know which event to trust if you have two of them?
Couple of solutions could be
1 Relays relaying meta data about when they received it. Means bigger nips.
2 Relays not accepting 'declaration of successor' more than 7 days old. Not sure if this needs a nip.
What if you are using the Gossip Model (Auto finding relays) and the attacker gets a hold of your keys, changes your relay to their custom relay and remove those protections?
I think easiest is to block successor events that are older than 7 days. I could do this on nos.lol with plugin. Anybody can query it then to find the earliest successor event for a given pub.
NIP-03: OpenTimestamps Attestations for Events
"While OpenTimestamps can create timestamps without a local Bitcoin node, to verify timestamps you need a local Bitcoin Core node (a pruned node is fine)."
OpenTimestamps looks like overkill.
What do you think of 'declaration of successor' events to be blocked by relays when they are older than lets say 7 days?
Relays shouldn't have to be trusted.
It's not really true that you need a full node to verify OTS timestamps, you can use an SPV-like trust model where you just have the Bitcoin block headers and check their POW. The headers are just 80 bytes per block.
Argh, referencing is difficult. Here‘s the link again: #[4]
